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

Re: [Pharo-project] roadmap

by StÃ©phane Ducasse

On Jan 2, 2012, at 8:42 PM, Lukas Renggli wrote: >>>> - beside RB and Announcements, are there other things that could be problematic >>> >>> Anything that is forked and changed, and that has existing could >>> become a potential problem: >>> >>> - AST-*: No changes at the moment. >> >> We plan to change it. >> I asked camillo to discuss the changes in the mailing-list because we want pinocchio >> analysis to be applied on Pharo and for that we need some extensions. >> So what is the process? >> >>> - Announcements-*: A big problem, but simple enough to work around. >>> - FileSystem-*: A big problem, the method renaming make it impossible >>> to use it with any code that depends on the official version. >> >> How can the core of pharo work with FS if FS is not loaded in Pharo? > > Then my question is: How can anybody use Pharo that does not want to > use your changes of AST and FS? Normally we talk and we reach a consensus. But it really looks that there is no possible discussion with you. Sadly. May be you should create your own smalltalk. Stef > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 2, 2012

Re: [Pharo-project] roadmap

by Lukas Renggli

>>> - beside RB and Announcements, are there other things that could be problematic >> >> Anything that is forked and changed, and that has existing could >> become a potential problem: >> >> - AST-*: No changes at the moment. > > We plan to change it. > I asked camillo to discuss the changes in the mailing-list because we want pinocchio > analysis to be applied on Pharo and for that we need some extensions. > So what is the process? > >> - Announcements-*: A big problem, but simple enough to work around. >> - FileSystem-*: A big problem, the method renaming make it impossible >> to use it with any code that depends on the official version. > > How can the core of pharo work with FS if FS is not loaded in Pharo? Then my question is: How can anybody use Pharo that does not want to use your changes of AST and FS? Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2012

Re: [Pharo-project] roadmap

by StÃ©phane Ducasse

On Jan 2, 2012, at 6:24 PM, Lukas Renggli wrote: >> - beside RB and Announcements, are there other things that could be problematic > > Anything that is forked and changed, and that has existing could > become a potential problem: > > - AST-*: No changes at the moment. We plan to change it. I asked camillo to discuss the changes in the mailing-list because we want pinocchio analysis to be applied on Pharo and for that we need some extensions. So what is the process? > - Announcements-*: A big problem, but simple enough to work around. > - FileSystem-*: A big problem, the method renaming make it impossible > to use it with any code that depends on the official version. How can the core of pharo work with FS if FS is not loaded in Pharo? > - Refactory-*: No big changes at the moment. > - SUnit: Some problems in the past. > - Shout: Some problems in the past. > - ... > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 2, 2012

Re: [Pharo-project] [ VM ]Smalltalk getSystemAttribute:

by David T. Lewis

On Mon, Jan 02, 2012 at 01:04:58PM -0300, Esteban Lorenzano wrote: > Hi, > > I was trying to fix this, but seems to be a problem (besides the "'-psn_0_528513'", which is an error). > According SmalltalkImage>>#getSystemAttribute: comment, getSystemAttribute: 0 shouldn't answer the executable name, but the VM path: > > 0 the full path name for currently executing VM > (or, on some platforms, just the path name of the VM's directory) > > ...so... getSystemAttribute: 0 is answering fine... and -1 should answer nil (or the vm parameters, if present), not the executable name. Real problem then is: > > we don't have a way to get the executable name > > or > > getSystemAttribute: comment is wrong :) > On a unix VM, it answers the full path to the executable, which is in agreement with the comment. For example: Smalltalk getSystemAttribute: 0 ==> '/usr/local/lib/squeak/4.7.18-2505/squeakvm' Maybe is is more complicated for Mac, but wasn't there some discussion about it on vm-dev a while back? Dave > what's the audience opinion? > > cheers, > Esteban > > > El 31/12/2011, a las 9:11p.m., Sean P. DeNigris escribi?: > > > The latest blessed cocoa build from Jenkins (12/11/11 #10) + 1.3-rc returns: > > > > SmalltalkImage current getSystemAttribute: -1."'-psn_0_528513'" > > SmalltalkImage current getSystemAttribute: 0 "'/Applications'" > > > > There does not seem to be a way to get the vm executable name. > > > > Sean > > > > -- > > View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4249718.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > >

Jan. 2, 2012

Re: [Pharo-project] About announcements

by StÃ©phane Ducasse

Can one of you turn the following list into bug entries? So that we can make progress by killing them one by one? Stef >>>> agreed here. I would even leave a semaphore. >>> I think it is overlooked by Henrik. >>> It also don't needs a lazy initialization in #protected: , since in >>> #initialize it can just create a ready for use fresh >>> synchronization object. > > A semaphore might block, because an announcement could register > another announcement. So probably the Mutex would be the right thing > to use. But apparently Mutex is broken :( > >>>> 4. It creates a copy of the collection of all the subscriptions: This >>>> is rarely useful and wouldn't be necessary if an immutable data >>>> structure was used. >>>> >>> propose better solution how to deal with situation when during >>> handling an announcement, >>> your handler unsubscribing from announcer. > > Array. Slower for registration, but faster at announcing (the common operation). > >>>> 5. It iterates over all announcements, it doesn't even try to group >>>> announcements of the same kind. >>>> >>> it is pointless to group them, and makes no real difference. >>> Because announcer doesn't knows what kinds of announcements will be >>> announcement, >>> and it knows only about subscriptions. >>> Suppose i have a subscription to Announcement. And i announcing >>> AnnouncementA (a subclass of it). > > Fair enough, probably it doesn't matter. > >>>> 7. It then tests each announcement if it matches, again it doesn't >>>> even try to group the announcements of the same kind. Aside, the match >>>> test was changed so that it doesn't allow instance-based announcements >>>> anymore, breaking some of my code. >>>> >>> what is instance-based announcements? > > If you have a client with 1000 different possibly dynamically changing > properties and you want a way to register for announcements of a > single property. The current implementation forces you to create a > class per property, previously you could fake a "kind of > announcements" with an instance. > >>> you can use any object as a subscription selector, just make sure it >>> understands #handles: message. >>> i.e. > > No, because the Announcement>>#handles: takes a class, not an instance. > >>>> 9. It then culls the announcement and announcer into the block. Not >>>> sure why the announcer is useful, after all the block was registered >>>> with the announcer at some point. >>>> >>> cull there is for passing optional arguments. > > I didn't complain about #cull:, but about the useless announcer passed in. > > Now for me you don't need to change the semantics of the Pharo > Announcements again. Now for my code I will just use my own > implementation that has exactly the behavior and performance > characteristics I need. Lukas our state of mind is that we want the infrastructure gets better so we like to change for a better one if this better one is better. If everybody has its own version then we do not improve the infrastructure. Stef

Jan. 2, 2012

Re: [Pharo-project] Experience with Monitor

by StÃ©phane Ducasse

Thanks mariano. Stef On Jan 2, 2012, at 3:49 PM, Mariano Martinez Peck wrote: > It was Mutex. http://forum.world.st/How-to-resurrect-an-unrepsonsive-image-tp4168518p4178… > > On Mon, Jan 2, 2012 at 3:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I remember reading somewhere that Monitor was broken in Pharo/Squeak? > I do not remember where. > Does anybody have experience with bad monitor behavior? > Because we got some bad experience with Monitor. > > THe funny part is that now doing self inform: freezes to death our image. > > Stef > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 2, 2012

Re: [Pharo-project] [ VM ]Smalltalk getSystemAttribute:

by Sean P. DeNigris

EstebanLM wrote > > Real problem then is: we don't have a way to get the executable name > That's the problem I ran into. I had to load OSProcess and have my code depend on it to get info that seemed basic to the system -- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4254002.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

> is not that *it can't* is that, as a development platform, Pharo needs to provide kernel+tools, not just kernel. > Anyway, I was not arguing against having a small kernel, I was arguing against pharo "just doing" the kernel. > Linux itself can't be distributed just as a kernel, it is distributed with a full set of different tools: GNU/Linux, Ubuntu Linux, etc. (btw... this is one of the arguments Stallman allways says about Linux: it was possible because there was already a lot of tools) And, in that case, just as Linux, we can't just do the kernel, we need to provide development tools... otherwise, people wont use it. I myself wont use it for my commercial applications if I do not have something like OmniBrowser to develop. I totally agree, the Pharo Kernel alone is not very useful for an end-user. However, with the emerging Pharo architecture you can hardly build a different distribution. To use the Linux analogy: You are trying to convince GNU/Linux to rebuild their system on top of a full-fledged Ubuntu distribution. > What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it) This coupling is exactly what is happening. How do you propose to build your kernel+other distribution? Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2012

Re: [Pharo-project] roadmap

by Lukas Renggli

> - beside RB and Announcements, are there other things that could be problematic Anything that is forked and changed, and that has existing could become a potential problem: - AST-*: No changes at the moment. - Announcements-*: A big problem, but simple enough to work around. - FileSystem-*: A big problem, the method renaming make it impossible to use it with any code that depends on the official version. - Refactory-*: No big changes at the moment. - SUnit: Some problems in the past. - Shout: Some problems in the past. - ... Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by Esteban Lorenzano

Hi Lukas, is not that *it can't* is that, as a development platform, Pharo needs to provide kernel+tools, not just kernel. Anyway, I was not arguing against having a small kernel, I was arguing against pharo "just doing" the kernel. Linux itself can't be distributed just as a kernel, it is distributed with a full set of different tools: GNU/Linux, Ubuntu Linux, etc. (btw... this is one of the arguments Stallman allways says about Linux: it was possible because there was already a lot of tools) And, in that case, just as Linux, we can't just do the kernel, we need to provide development tools... otherwise, people wont use it. I myself wont use it for my commercial applications if I do not have something like OmniBrowser to develop. What I'm saying: Pharo is not the Kernel, is the Kernel + Tools (we are not just linux... we are linux+eclipse, if you want) What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it) ...and I'm also saying that, at this stage (while we are achieving the "modularization phase") , it is ok that Tools are reduced to it's minimum... of course if I can load other dev tools, like ob or glamour). But we as Pharo community need to ensure there are a powerful set of tools that makes ppl happy. Cheers, Esteban El 02/01/2012, a las 1:41p.m., Lukas Renggli escribiÃ³: >> IMHO, Pharo can never be just what Lukas propose: just a kernel, like linux, allowing different distributions. > > Esteban, why not? Can you give one technical reason why what Linux > does cannot work for Pharo? > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 2, 2012