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, hh2@lexdb.net wrote:
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
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
Hannes Hirzel
References: http://wiki.squeak.org/squeak/5646
- 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
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.
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 [http://wiki.squeak.org/squeak/5646]
A follow up question:
What do the icons in front of certain method names mean?
- green cross
- green up arrow
- orange triangle facing upwards
- orange triangle facing downwards
- 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:
What do the icons in front of certain method names mean?
- green cross
- green up arrow
- orange triangle facing upwards
- orange triangle facing downwards
- red flag
Answering my own question:
Through http://wiki.squeak.org/squeak/5646
I found
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
"hh2@lexdb" == hh2@lexdb net hh2@lexdb.net 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".
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 squeak@webcitas.ch 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" merlyn@stonehenge.com hat am 25. September 2008 um 16:51 geschrieben:
"David" == David Röthlisberger squeak@webcitas.ch 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, hh2@lexdb.net wrote:
"Randal L. Schwartz" merlyn@stonehenge.com hat am 25. September 2008 um 16:51 geschrieben:
> "David" == David Röthlisberger squeak@webcitas.ch 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 newwith the following method WAhtmlCanvas>>br
br "Inserts a single line break."
^ self brush: WABreakTag newYes, 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)
Probably lineBreak is a better selector than br
Norbert
2008/9/25 Randal L. Schwartz merlyn@stonehenge.com:
"David" == David Röthlisberger squeak@webcitas.ch 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.
No way. Fix your tools.
Cheers Philippe
On Tue, 2008-09-30 at 13:38 +0200, Philippe Marschall wrote:
2008/9/25 Randal L. Schwartz merlyn@stonehenge.com:
> "David" == David Röthlisberger squeak@webcitas.ch 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.
No way. Fix your tools.
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
On Tue, Sep 30, 2008 at 11:37 AM, David Röthlisberger squeak@webcitas.ch 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
On 30-Sep-08, at 11:43 AM, Avi Bryant wrote:
On Tue, Sep 30, 2008 at 11:37 AM, David Röthlisberger squeak@webcitas.ch 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.
The original issue was that OB uses a flag icon to call attention to senders of #halt and #break. In rendering methods, that's a false alarm.
It seems like #break is only used by the tools, so it would better to change that than Seaside.
Colin
2008/10/1, Colin Putney cputney@wiresong.ca:
On 30-Sep-08, at 11:43 AM, Avi Bryant wrote:
On Tue, Sep 30, 2008 at 11:37 AM, David Röthlisberger squeak@webcitas.ch 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.
The original issue was that OB uses a flag icon to call attention to senders of #halt and #break. In rendering methods, that's a false alarm.
It seems like #break is only used by the tools, so it would better to change that than Seaside.
Or just change the detection code to check if the receiver of #break is a variable or argument called html or renderer.
Cheers Philippe
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.
The original issue was that OB uses a flag icon to call attention to senders of #halt and #break. In rendering methods, that's a false alarm.
It seems like #break is only used by the tools, so it would better to change that than Seaside.
Or just change the detection code to check if the receiver of #break is a variable or argument called html or renderer.
yes, I also wanted to go for that. In that case you confirm that almost all Seaside applications either use 'html' or 'renderer' as a name for the receiver of #break?
David
2008/10/1 David Röthlisberger squeak@webcitas.ch:
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.
The original issue was that OB uses a flag icon to call attention to senders of #halt and #break. In rendering methods, that's a false alarm.
It seems like #break is only used by the tools, so it would better to change that than Seaside.
Or just change the detection code to check if the receiver of #break is a variable or argument called html or renderer.
yes, I also wanted to go for that. In that case you confirm that almost all Seaside applications either use 'html' or 'renderer' as a name for the receiver of #break?
or simply r, yes.
Cheers Philippe
h too.
-- Hwee-Boon
On Wed, Oct 1, 2008 at 7:11 PM, Philippe Marschall philippe.marschall@gmail.com wrote:
2008/10/1 David Röthlisberger squeak@webcitas.ch:
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.
The original issue was that OB uses a flag icon to call attention to senders of #halt and #break. In rendering methods, that's a false alarm.
It seems like #break is only used by the tools, so it would better to change that than Seaside.
Or just change the detection code to check if the receiver of #break is a variable or argument called html or renderer.
yes, I also wanted to go for that. In that case you confirm that almost all Seaside applications either use 'html' or 'renderer' as a name for the receiver of #break?
or simply r, yes.
Cheers Philippe
David Röthlisberger a écrit :
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
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
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?)
Certainly you don't have to adhere to these conventions, but then you might have to accept that the tool doesn't do what it is intended to do. Every tool has some conventions it relies on, in particular code browsers. It's difficult, in particular in Smalltalk, to build a useful code browser that does not rely on any conventions... You don't have to organize methods in protocols, but then you have to accept that you just get one category 'unclassified', rendering the whole method protocol column useless. The same with #break: if you re-implement that method in your subclasses of Object, then you give this method (probably) a different meaning than Object did. A code browser typically goes for the default behavior in a Squeak image, it can't (and IMHO doesn't have to) assume that other applications shadow behavior of #break, #halt, whatever. I really don't see anything intrusive or tyrannic here. In the end, all you get when you re-implement #break is a (possibly) wrong icon for a method invoking your #break implementation. Things could be worse...
- let the browser inferring receiver type (after all, most usages are
probably self break, so that might be a hint),
Was also thinking about this first. But here you rely on even more unsure conventions...
- or using a statically typed language (oh no!)
Better not. ;)
the last alternative I see is to add yet another Preference...
Evil, evil. ;)
... or maybe make the tools more general? Like:
This would certainly be interesting to have.
- 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...
Cheers, David
On Thu, Sep 25, 2008 at 10:05 AM, hh2@lexdb.net hh2@lexdb.net 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 damien.cassou@gmail.com hat am 25. September 2008 um 11:14 geschrieben:
On Thu, Sep 25, 2008 at 10:05 AM, hh2@lexdb.net hh2@lexdb.net 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... (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...
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
Hi Hannes,
On Tue, Sep 30, 2008 at 11:29 AM, hh2@lexdb.net hh2@lexdb.net wrote:
Thank you, Damien, for your hint. But I prefer loading only a few packages through the package Universe.
When you do that, you use the main part of my work, i.e., maintaining the 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... (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...
Because Laurent Laffont does this for me :-) (thank you Laurent).
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.
I agree, it should be put on the Squeak release team and I guess they agree. I can't fix Squeak. The dev images are not a fork, it's only packages put into a base image.
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.
I attached the script to this email. This script uses Universe to load the different things including the package ImageForDevelopers comming from SqueakSource. This package configure the image (documentation, omnibrowser by default, clean tools flap, icon...). If you need more info please tell me.
On Wed, Oct 1, 2008 at 8:36 AM, Damien Cassou damien.cassou@gmail.com wrote:
I attached the script to this email.
There is a small typo in the name of the generate-squeak-dev method.
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
Colin Putney -
Damien Cassou -
David Röthlisberger -
hh2＠lexdb.net -
Hwee-Boon Yar -
merlyn＠stonehenge.com -
nicolas cellier -
Norbert Hartl -
Philippe Marschall -
Ramon Leon