December 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] glamour and pharo
by Tudor Girba Jan. 4, 2012

Jan. 4, 2012

Hi, Let's take this on the Pharo mailing list. I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte). And I also think your analysis is not accurate. Here is why (I apologize for the long list): 1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more. 2. It is quite well tested. This part can be improved, but the core has some 80% coverage. 3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult. 4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes. 5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too. 6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes. 7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too. I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now. So, before dismissing Glamour, perhaps it would be useful to actually look into it. Cheers, Doru > On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote: > >> Hi Stef, >> >> You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo. > > Do you think so? > I do not think that we can base our infrastructure on something that only one person understand and can modify. > You will tell that this is the same for Morphic but this is not true. > > Stef > -- www.tudorgirba.com "Beauty is where we see it."

9 38

[Pharo-project] Monticello trickery: pointers needed
by Frank Shearar Jan. 4, 2012

Jan. 4, 2012

Hi, The background to the question is that I'm trying to repackage LanguageBoxes so that both the Squeak and Pharo community can use its features (or just parts of it). Cutie-Helvetia defines a class, CURaisedToExample. Among others, it defines two methods: CURaisedToExample class >> #raise:to and CURaisedToExample >> testSplice. The latter makes use of QQCompiler's splice operation (just like Common Lisp's) - @foo will replace 'foo' with whatever 'foo' evaluates to, so compiling 'a := @(3 + 4)' means the same thing as 'a := 7'. Now testSplice says self assert: `@(self raise: 2 to: -3) = (1/8). which means that, _at_compile_time_, testSplice will invoke #raise:to: (the self refers to the class-side method)... and at this point in time #raise:to: has been compiled, but not installed. Compiling #testSplice fails with a MessageNotUnderstood, and package loading aborts. My question is this: how can I work around this? Can I move the installation of #raise:to: to a preload step? Some hacks that spring to mind, and don't seem very pleasant, are: * introduce a new superclass defining the method, put that in a seperate package, and load that package before Cutie-Helvetia * move the definition of CURaisedToExample and #raise:to: to a separate package, and make all the tests extensions to that package. frank

1 1

[Pharo-project] TWM Bug - different world menu
by Sean P. DeNigris Jan. 4, 2012

Jan. 4, 2012

When I access the world menu through the TWM bar, some of the items I have registered do not show up. Maybe items added after TWM was loaded do not show up. Anyone else notice this? Sean -- View this message in context: http://forum.world.st/TWM-Bug-different-world-menu-tp4244649p4244649.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 2

[Pharo-project] [ VM ]Smalltalk getSystemAttribute:
by StÃ©phane Ducasse Jan. 3, 2012

Jan. 3, 2012

we will have to check if this impacts some of our parameter handling. Stef Begin forwarded message: > VM.r2518/. > > CogVM binaries as per VMMaker.oscog-eem.139/r2518. > > Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: > Smalltalk getSystemAttribute: > -1 => executable name > -2 .. -n => VM arguments *including* image (if explicitly supplied). > Replace win32 command line parsing with unixesque code using CommandLineToArgvW. > > linux launch script: > Cope with old linuxes use of /lib/tls hack for an optional thread-local-storage > version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: to > LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to /lib/tls/libc. > -- > best, > Eliot >

10 18

[Pharo-project] TWM bug when deleting a snapshot
by Sean P. DeNigris Jan. 3, 2012

Jan. 3, 2012

Snapshots are cool! But try this: 1. create two snapshots 2. navigate to the last one 3. delete it Although it is shown removed from the list (i.e. "1/1"), you are not automatically navigated back to the first one. You stay on the deleted one, and when you navigate back to the first with the arrow, the deleted one reappears in the list (i.e. "1/2") Sean -- View this message in context: http://forum.world.st/TWM-bug-when-deleting-a-snapshot-tp4243197p4243197.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 5

[Pharo-project] string hash collisions?
by Philippe Marschall Jan. 2, 2012

Jan. 2, 2012

Hi As you probably noted string hash collisions are all the rage these days [1]. Has anybody looked into whether this applies to Pharo as well? [1] http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html Cheers Philippe

4 6

[Pharo-project] seaside and pharo (was: glamour and pharo)
by Lukas Renggli Jan. 1, 2012

Jan. 1, 2012

Let's take this on the Pharo mailing list. I do think that Seaside should be considered for being part of the Pharo infrastructure. At least the Core and the basic HTML rendering (i.e., without JQuery, Magritte and Pier). And I also think your analysis is not accurate. Here is why (I apologize for the long list): 1. Seaside is quite well documented. There are two books describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are lots of comments. 2. It is quite well tested. This part can be improved, but the core has some 80% coverage. 3. I am not the only one that knows how to mingle with it. To give some examples, more than 30 people helped fixing some intricate bugs directly in the core (http://www.seaside.st/community/contributors) I would also mention that countless student projects are on Squeaksource. So, maybe it's not that difficult. 4. The core is quite stable since more than 10 years. There were changes, but they were mostly related to new features and bug fixes. 5. The main point of using this infrastructure is not to replace Morphic, and to empower more people to build more applications. For example, the Seaside counter has less than 5 lines of code in total (and one instance variable only). This is really tiny for the amount of things it offers (you can even step through it with a debugger). And it is highly extensible (subclassing), too. 6. It's actually not that large: the core has 152 classes, and if you consider all the other packages, helper classes and specialized frameworks (but without the example code), you get some 1162 classes. 7. But, perhaps the most important part is that there have been literally thousands of applications built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the web either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Pier (SmallWiki) is now using this infrastructure, too. I am not saying that Seaside is perfect. There are quite a couple of things I would like to enhance (for example, the AJAX ideas from Reef, or the components from ExtJS), but it has proved to be quite solid until now. So, before dismissing Seaside, perhaps it would be useful to actually look into it. Cheers, Lukas PS: If you don't like Seaside, I might have some other additions to pharo core ready that fit as well into the template ... On 31 December 2011 17:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Let's take this on the Pharo mailing list. > > I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte). > > And I also think your analysis is not accurate. Here is why (I apologize for the long list): > > 1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more. > > 2. It is quite well tested. This part can be improved, but the core has some 80% coverage. > > 3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult. > > 4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes. > > 5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too. > > 6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes. > > 7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too. > > > I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now. > > So, before dismissing Glamour, perhaps it would be useful to actually look into it. > > Cheers, > Doru > > >> On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote: >> >>> Hi Stef, >>> >>> You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo. >> >> Do you think so? >> I do not think that we can base our infrastructure on something that only one person understand and can modify. >> You will tell that this is the same for Morphic but this is not true. >> >> Stef >> > > -- > www.tudorgirba.com > > "Beauty is where we see it." > -- Lukas Renggli www.lukas-renggli.ch

6 7

[Pharo-project] feature request - undo closed tab
by btc＠openInWorld.com Jan. 1, 2012

Jan. 1, 2012

Neglecting that in 6 months I might be in a position try implementing this myself, here is a feature request in case anyone likes it enough to implement it in the meantime, or who can advise why it is a bad idea. Background: For me, one of the greatest most useful features of web browsers is the "Undo Close Tab." I browse almost exclusively opening all links as new tabs since I find this the fastest to follow diversions and then return to my previous place up the stack of tabs. I can get 20 or more odd tabs in a browser window. When I'm speedily closing tabs to backtrack my position, I find my recognition of content often lags my tab closing by a split second. Being able to un-close that last tab is a lifesaver. Now that I am getting into actual programming in Pharo, I have found that from time to time I've ended up with more than a dozen tabs in the "task bar" at the bottom of World. A few times already when I've flicking through these closing them after finish a line of thought, I have accidentally closed some tabs that I wanted to keep - like the Workspace I had been using as a bit of a history log. Perhaps my workflow is bad - but I really miss being able to Undo closing that last window. Features: 1. For a window that has a tab on the "task bar" at the bottom of World, when it is closed allow it to be reopened in the same state. 2. Clicking on the "Task bar" provides a menu item "Undo Close Tab" that either: 2a. Brings back the last closed tab. 2b. Provides a "restore list" of previously closed tabs sorted by time closed, which brings back that tab. Implementation Idea: 3. When closing a tab, rather than actually closing it, the window is just minimised but is removed from the tab and placed on the "restore list". 4a. The "restore list" is a certain length and when a tab is bumped off the end it is properly closed. 4b. Alternatively tabs may remove themselves from the "restore list" after a certain timeout eg 30 minutes. I'd appreciate your thoughts... cheers, Ben

3 2

[Pharo-project] System Browser - shifting class comments into pane beneath class definition
by Ben Coman Jan. 1, 2012

Jan. 1, 2012

I could not find any previous discussion of this so I'll just throw this out there... I find that I forget to click the "?" button to read the class comments as I browse around the system. They are "kind of" hidden. Perhaps also I stop looking because they are often empty. If others do the same then it is a downward spiral... if it seems no one looks at them then no one values writing them. (Except for the good work of the COTDC) However System Browser opens by default with 16 lines. Most class definitions (eg [1]) use 6 lines, which leaves a lot of unused whitespace. I wonder if the class comment was to appear (in a separate pane) beneath the class definition then the class definition would be filled out more often. Bring the class comments to the fore and perhaps they'll be valued more. At least for me, it will ensure that I don't miss where there are good comments I can learn from. Also more attention may focus on the poor comments due to being more exposed. just a random thought... cheers, Ben [1] Object subclass: #Behavior uses: TPureBehavior instanceVariableNames: 'superclass methodDict format' classVariableNames: 'ObsoleteSubclasses' poolDictionaries: '' category: 'Kernel-Classes'

4 4

[Pharo-project] Possible bug in FFI
by ncalexan Jan. 1, 2012

Jan. 1, 2012

Hello all, Long-time reader, first-time poster. Is FFI fully supported on Pharo? I installed into the 1.3 OneClick using Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFFI'; load. ConfigurationOfFFI load. All seems fine but ExternalAddress gcallocate: 128 fails in ExternalAddress>>shallowCopy, complaining that clone is not understood. Bug? Not supported? Misused? Best, Nick Alexander -- View this message in context: http://forum.world.st/Possible-bug-in-FFI-tp4241299p4241299.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 3