[squeak-dev] [Question] How do I use the OmniBrowser?

Hello

How do I open an OmniBrowser?

- There is no entry in the "World menu", entry "open..."
- OBBrowser open
     gives a Walkbalk window



- I use Squeak 3.10.2
- I have installed OmniBrowser-Morphic version 0.5 through the package "Universe".
- Is the version installed the correct one - there are many to choose from - the one I have chosen seems attractive because of the high version number.


Thank you in advance for any suggestions


Hannes Hirzel


References:
http://wiki.squeak.org/squeak/5646
1. Meta-Driven Browsers (2007) http://www.iam.unibe.ch/~scg/Archive/Papers/Berg07cOmnibrowser.pdf
2. The OmniBrowser Reference (2007) http://bergel.eu/download/OmnibrowserReference.pdf* (an extension of 1)

Question: Is there other documentation on the OmniBrowser available? (The documentation above is comprehensive, it describes the design of the OmniBrowser framework and three applications. So in particular some installation notes would be appreciated.)


Remark: I like the ObjectFinder http://decomp.ulb.ac.be/frdricpluquet/personalstuff/theobjectfinder/ which is a different package but based on the OmniBrowser framework and seems to be useful as it shows fields and methods. It replaces the standard inspector. So inspecting an object brings up an ObjectFinder.

Hi Hannes,

> - I use Squeak 3.10.2
> - I have installed OmniBrowser-Morphic version 0.5 through the package
> "Universe".

Better load OmniBrowser-Full version 0.24, it contains all packages you need to start
and use OmniBrowser. OmniBrowser-Morphic is just one of three required packages:
OmniBrowser, OmniBrowser-Standard and OmniBrowser-Morphic. You might also want to
load OB-Enhancements, but this is not required.

When you have loaded these package, you can open an OmniBrowser with World -> open ->
class browser.
Or by executing this code:
OBSystemBrowser open.


> Question: Is there other documentation on the OmniBrowser available?
> (The documentation above is comprehensive, it describes the design of
> the OmniBrowser framework and three applications. So in particular some
> installation notes would be appreciated.)

There is some little additional information available at various places, but it's
probably not update...
So currently the best is to ask in the mailing list...
We indeed need to write better documentation about OB, this is very true.

Cheers,
David

On Wed, 2008-09-24 at 11:21 +0200, [hidden email] wrote: Open a class brower from the menu. Press the menu icon in the window
title between "x" and the title "System Browser". The last entry is
called "Choose new default Browser"

hope that helps.

Norbert

Thank you Norbert and David for your answers.

OmniBrowser (OmniBrowser-Full version 0.24) works now in my 3.10.2 image as you describe. There is a version 0.25 in the Package Universe of 3.10 but I went for 0.24 as you recommended.

A follow up question:

What do the icons in front of certain method names mean?


1) green cross
2) green up arrow
3) orange triangle facing upwards
4) orange triangle facing downwards
5) red flag

Hannes Hirzel


P.S. I will put the answer on

http://wiki.squeak.org/squeak/5646

> A follow up question:
>
> What do the icons in front of certain method names mean?
>
>
> 1) green cross
> 2) green up arrow
> 3) orange triangle facing upwards
> 4) orange triangle facing downwards
> 5) red flag
>


Answering my own question:

Through http://wiki.squeak.org/squeak/5646

I found

http://smallwiki.unibe.ch/hermion/icons/


In particular: the red flag means that there is a 'self halt' in the method. Nifty.

However more pointers to OmniBrowser documentation are still welcome.

Hannes

    > A follow up question:
btw, in the very latest version of OB you also get an explaining label for the icon
on mouse-over.
This version is to be committed soon to the Universe.

David

On Thu, Sep 25, 2008 at 10:05 AM, [hidden email] <[hidden email]> wrote:
> OmniBrowser (OmniBrowser-Full version 0.24) works now in my 3.10.2 image as
> you describe. There is a version 0.25 in the Package Universe of 3.10 but I
> went for 0.24 as you recommended.

You could have used the dev images which already included the latest
OB version: http://damien.cassou.free.fr/squeak-dev.html

--
Damien Cassou
Peter von der Ahé: «I'm beginning to see why Gilad wished us good
luck». (http://blogs.sun.com/ahe/entry/override_snafu)

>>>>> "hh2@lexdb" == hh2@lexdb net <[hidden email]> writes:

hh2@lexdb> In particular: the red flag means that there is a 'self halt' in the method.

Sadly, it's also true when there's a "break" message sent to anything.
Which means some of my seaside methods that want a <br> get flagged,
because they have "html break".

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

> hh2@lexdb> In particular: the red flag means that there is a 'self halt' in the method.
>
> Sadly, it's also true when there's a "break" message sent to anything.
> Which means some of my seaside methods that want a <br> get flagged,
> because they have "html break".

yeah, this is bad, but unfortunately there is no easy way to avoid that, except
excluding #break from the list of "dangerous" senders. But this doesn't really make
sense as it is as important to know if a method sends #break or #halt.

David

>>>>> "David" == David Röthlisberger <[hidden email]> writes:

>> hh2@lexdb> In particular: the red flag means that there is a 'self halt' in the method.
>> Sadly, it's also true when there's a "break" message sent to anything.
>> Which means some of my seaside methods that want a <br> get flagged,
>> because they have "html break".

David> yeah, this is bad, but unfortunately there is no easy way to avoid that,
David> except excluding #break from the list of "dangerous" senders. But this doesn't
David> really make sense as it is as important to know if a method sends #break or
David> #halt.

Maybe the seaside folks can add a new method for #br and deprecate
#break or something in 2.9.


--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Damien Cassou <[hidden email]> hat am 25. September 2008 um 11:14 geschrieben:

> On Thu, Sep 25, 2008 at 10:05 AM, [hidden email] <[hidden email]> wrote:
> > OmniBrowser (OmniBrowser-Full version 0.24) works now in my 3.10.2 image as
> > you describe. There is a version 0.25 in the Package Universe of 3.10 but I
> > went for 0.24 as you recommended.
>
> You could have used the dev images which already included the latest
> OB version: http://damien.cassou.free.fr/squeak-dev.html
>
> --
> Damien Cassou


Thank you, Damien,  for your hint. But I prefer loading only a few packages through the package Universe.

DEVELOPER IMAGES
You load quite a number of packages into the dev images as you write in
http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131354.html
(list of installed packages in the dev images)

But you write that you do not run the tests in the images
http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131371.html

I appreciate the work you are doing (keeping track of interesting packages to load, know where to get them from, communicate with package developers) but the work is not complete.
My understanding of a distribution is that the burden of the _tests_ is not put onto the consumer.

However what I am interested in are the "loading scripts" to avoid having to click around in the UniverseBrowser. This means having a kind of loading script I can adapt to my needs.





TESTS

Here the test results I obtained:



Squeak 3.10.2 (pristine image, out of the box)
----------------------------------------------

2255 run, 2250 passes, 2 failures, 3 errors

The errors and failures originate from the two following TestCases

DebuggerUnwindBug (in category Tools-Debugger-Tests)
StringSocketTestCase (in category Nebraska-Network-Objects; 3 tests in the TestCase; on repetion any number of passes between 0 and 3 is possible; doesn't seem to be a good test)


Squeak 3.10.2 (with OmniBrowser, Seaside and TinyWiki installed)
----------------------------------------------------------------

Installed versions through Package Universe
* OmniBrowser Full version 0.24
* Seaside 2.8.2.563
* TinyWiki version 1.0.1

2440 tests,   2428 passes  , 9 failures and 3 errors


So not having too many packages keeps the whole thing manageable from the testing side.


Kind regards

Hannes Hirzel

"Randal L. Schwartz" <[hidden email]> hat am 25. September 2008 um 16:51 geschrieben:

> >>>>> "David" == David Röthlisberger <[hidden email]> writes:
>
> >> hh2@lexdb> In particular: the red flag means that there is a 'self halt' in the method.
> >> Sadly, it's also true when there's a "break" message sent to anything.
> >> Which means some of my seaside methods that want a <br> get flagged,
> >> because they have "html break".
>
> David> yeah, this is bad, but unfortunately there is no easy way to avoid that,
> David> except excluding #break from the list of "dangerous" senders. But this doesn't
> David> really make sense as it is as important to know if a method sends #break or
> David> #halt.
>
> Maybe the seaside folks can add a new method for #br and deprecate
> #break or something in 2.9.
>

So the proposal is to replace the method WAhtmlCanvas>>break


  break
      "Inserts a single line break."

      ^ self brush: WABreakTag new


with the following method WAhtmlCanvas>>br

   br
    "Inserts a single line break."

    ^ self brush: WABreakTag new


Yes, I second this, because the break method has another meaning as

  Object>>break
      "This is a simple message to use for inserting breakpoints during debugging.
      The debugger is opened by sending a signal. This gives a chance to restore
      invariants related to multiple processes."

      BreakPoint signal.

      "nil break."


Where can I file this Seaside change request? (Maybe it is already filed)


Kind regards

Hannes Hirzel

On Tue, 2008-09-30 at 11:35 +0200, [hidden email] wrote: Probably lineBreak is a better selector than br


Norbert

2008/9/25 Randal L. Schwartz <[hidden email]>: No way. Fix your tools.

Cheers
Philippe

On Tue, 2008-09-30 at 13:38 +0200, Philippe Marschall wrote: I thought that at first, too. But then break is a method
in Object and the seaside stuff changes semantics for that
call. So the decision would be that there is no need for
setting breakpoints while dealing with the canvases. I
doubt that.
The funny thing here is that if seaside would remove that
selector, a lot of seaside apps will literally break :))

Norbert

> > Maybe the seaside folks can add a new method for #br and deprecate
> > #break or something in 2.9.
>
> No way. Fix your tools.
>
> Cheers
> Philippe

Ditto.  #br is a horrible selector, we're not suffering from a shortage of
vowels, #br stands for break, the selector should be #break just as "a"
means anchor.

Ramon Leon
http://onsmalltalk.com

> Ditto.  #br is a horrible selector, we're not suffering from a shortage of
> vowels, #br stands for break, the selector should be #break just as "a"
> means anchor.

yeah, but there's no #a method implemented in Object that has a
particular meaning as #break has, right?

David

On Tue, Sep 30, 2008 at 11:37 AM, David Röthlisberger
<[hidden email]> wrote:
>
>> Ditto.  #br is a horrible selector, we're not suffering from a shortage of
>> vowels, #br stands for break, the selector should be #break just as "a"
>> means anchor.
>
> yeah, but there's no #a method implemented in Object that has a particular
> meaning as #break has, right?

Is Object>>break mentioned anywhere in Squeak documentation? I never
knew about it until now.  It also has no senders (for somewhat obvious
reasons), so there would be no problem changing it to something else
like #breakpoint.

Even without that, though, I don't think there's a real issue here.
If you're inside canvas code and want a breakpoint, use some other
receiver - the comment in the #break method itself uses "nil break" as
an example.

Avi

> Is Object>>break mentioned anywhere in Squeak documentation? I never
> knew about it until now.  It also has no senders (for somewhat obvious
> reasons), so there would be no problem changing it to something else
> like #breakpoint.

That's true.
btw, the browser uses it when choosing 'toggle break on entry' for a method.

> Even without that, though, I don't think there's a real issue here.
> If you're inside canvas code and want a breakpoint, use some other
> receiver - the comment in the #break method itself uses "nil break" as
> an example.

Right, but still, the two methods shouldn't have the same name. I look
at #break as at #halt which I can also send to any receiver to get what
I want.
But sending #breakpoint instead of #break would be fine for me.

David

David Röthlisberger a écrit :
That's the price to pay for having an intrusive browser....
Browser assumptions about the semantics of #break #halt or any other
messages cannot be more than speculation...
...Speculation that we all agreed on some conventions that certainly are
not part of Smalltalk.

Apart
- adhering these conventions (but we should not take this decision for
the sole reason of conforming to a tool, why let a Browser be that
tyrannic?),
- let the browser inferring receiver type (after all, most usages are
probably self break, so that might be a hint),
- or using a statically typed language (oh no!),
the last alternative I see is to add yet another Preference...


... or maybe make the tools more general? Like:
- let user peek some lint rules (eventually by package or class)
- process these rules and mark all methods using a questionable
   message/pattern
   (using a Wrapper, like a QuestionableCompiledMethod,
   or adding yet another CompiledMethod attribute).
- let the browser lazily highlight such marked methods,
- and in a greater effort let it explain which part of code is
   questionable and why (require using more details....)
- let the user provide hints for immunizing some known_to_be_ok methods
   against pedantic warnings (using annotations or method attributes?)
   Beware, such hint should survive code externalization...

It sounds like I already eared about such features or project...
Where was it?

Nicolas