October 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Phobos

by Pavel Krivanek

Hi all, I would like to introduce you Phobos - the XULRunner based Smalltalk framework for development of native GUI with standard look&feel for Linux, Mac OS X and Windows. It is based on Zinc, WebSockets and Seaside continuations. For more information including more screenshots see the project page: http://code.google.com/p/phobos-framework/ You should pay attentions to FAQ too: http://code.google.com/p/phobos-framework/wiki/FAQ Phobos has Seaside-like components and rendering style, can combine XUL with HTML or SVG, supports printing etc. Cheers, -- Pavel

Oct. 9, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

In this case, would it make sense to have a global "external handles registry" so, that during image boot it does: clearExternalObjects and booting ifTrue: [ registry := registry reject: [:each | each invalidate ] ]. (where registry is WeakIdentitySet , and #invalidate should answer true if object wants to remove itself (deregister) after invalidating external handle). and only then doing startup as usual. like that, then we could have better guarantee that nothing will go wrong, and things like FreeType won't require own startup procedure at all. -- Best regards, Igor Stasenko.

Oct. 9, 2012

[Pharo-project] [update 2.0] #20332

by Marcus Denker

20332 ----- Issue 6780: Nautilus Issue creation Menu is confusing http://code.google.com/p/pharo/issues/detail?id=6780 Issue 6779: MCSmalltalkhubRepository sends wrong instance creation message http://code.google.com/p/pharo/issues/detail?id=6779 -- Marcus Denker -- http://marcusdenker.de

Oct. 9, 2012

[Pharo-project] [update 2.0] #20330

by Marcus Denker

20330 ----- Issue 6778: [Enh] Session object http://code.google.com/p/pharo/issues/detail?id=6778 (some packages are now dirty, this will be be fixed later) -- Marcus Denker -- http://marcusdenker.de

Oct. 9, 2012

[Pharo-project] [update 2.0] #20329

by Marcus Denker

20329 ----- Issue 5874: [ENH]: Notify progress with Announcements instead of Exceptions http://code.google.com/p/pharo/issues/detail?id=5874 (some packages are now dirty, this will be be fixed later) -- Marcus Denker -- http://marcusdenker.de

Oct. 9, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

On 9 October 2012 14:45, drush66 <davorin.rusevljan(a)gmail.com> wrote: > Igor Stasenko wrote >> On 9 October 2012 14:28, drush66 < > >> davorin.rusevljan@ > >> > wrote: >>> Igor Stasenko wrote >> run levels just adding another dimension into dependency soup. >> they don't solve the dependency problem.. >> when you say "i run at level 5, so everything which runs at level 4 >> will be initialized first" >> which is equal to saying " Facility A (level 5) should not be used >> before facility B (level 4) is >> initialized. > > They do not solve them, but they make i ta bit les fragile, since you do not > specify all facilities that have to run before your own, but you say, any > facility from some class (run level), should run before mine. So one can > write such rule without knowing explicit list of all facilities that need to > run before mine. > right, it is just grouping. > But anyway, I have just posted this as an food for thoughts, if it helps or > not you decide. > imo, it would make sense, if we would have that many services as linux has. > > > > ----- > http://www.cloud208.com/ > -- > View this message in context: http://forum.world.st/Global-session-object-tp4650371p4650580.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Oct. 9, 2012

Re: [Pharo-project] Global session object?

by drush66

Igor Stasenko wrote > On 9 October 2012 14:28, drush66 < > davorin.rusevljan@ > > wrote: >> Igor Stasenko wrote > run levels just adding another dimension into dependency soup. > they don't solve the dependency problem.. > when you say "i run at level 5, so everything which runs at level 4 > will be initialized first" > which is equal to saying " Facility A (level 5) should not be used > before facility B (level 4) is > initialized. They do not solve them, but they make i ta bit les fragile, since you do not specify all facilities that have to run before your own, but you say, any facility from some class (run level), should run before mine. So one can write such rule without knowing explicit list of all facilities that need to run before mine. But anyway, I have just posted this as an food for thoughts, if it helps or not you decide. ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Global-session-object-tp4650371p4650580.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 9, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 396 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Oct. 9, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

On 9 October 2012 14:28, drush66 <davorin.rusevljan(a)gmail.com> wrote: > Igor Stasenko wrote >> 1. during startup, you have to be very careful about dependencies >> between services, >> the errors like using uninitialized service(s) makes image >> unrecoverable (because VM crashing). >> For example , putting 'Transcript show: ' before freetype initialized >> may kill an image, >> beyond the point of recovery. The hardest part in it, that since >> everything is late bound, it sometimes really hard to put >> initialization in right order. And loading any new code in image will >> also contribute to chaos >> of interdependencies, unless all developers know that they should not >> use facility A before facility B is properly initialized. And the only >> way to do it is to add own checks and one more #startup method, >> which 'enabling' your service after all dependencies initialized. >> But the problem is that the longer chain of initialization gets, the >> more chances that something will go wrong (as well as getting lost in >> order of dependencies). > > Just shooting from the hip, isn't that the same problem that more or less > all unix os-es have on start up, what parts of systems are alive at > particular moment and which ones are not. Instead of hard wiring all > dependencies, maybe introduce different run levels, and roughly divide > registered start up actions based on the run level? > > run levels just adding another dimension into dependency soup. they don't solve the dependency problem.. when you say "i run at level 5, so everything which runs at level 4 will be initialized first" which is equal to saying " Facility A (level 5) should not be used before facility B (level 4) is initialized. > > > ----- > http://www.cloud208.com/ > -- > View this message in context: http://forum.world.st/Global-session-object-tp4650371p4650576.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Oct. 9, 2012

Re: [Pharo-project] Global session object?

by drush66

Igor Stasenko wrote > 1. during startup, you have to be very careful about dependencies > between services, > the errors like using uninitialized service(s) makes image > unrecoverable (because VM crashing). > For example , putting 'Transcript show: ' before freetype initialized > may kill an image, > beyond the point of recovery. The hardest part in it, that since > everything is late bound, it sometimes really hard to put > initialization in right order. And loading any new code in image will > also contribute to chaos > of interdependencies, unless all developers know that they should not > use facility A before facility B is properly initialized. And the only > way to do it is to add own checks and one more #startup method, > which 'enabling' your service after all dependencies initialized. > But the problem is that the longer chain of initialization gets, the > more chances that something will go wrong (as well as getting lost in > order of dependencies). Just shooting from the hip, isn't that the same problem that more or less all unix os-es have on start up, what parts of systems are alive at particular moment and which ones are not. Instead of hard wiring all dependencies, maybe introduce different run levels, and roughly divide registered start up actions based on the run level? ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Global-session-object-tp4650371p4650576.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 9, 2012