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

Re: [Pharo-project] Bug reports: 1 of 6: Damaged Window/ rectangles on Screen

by Sean P. DeNigris

S Krish wrote > > 1. Damaged Window rectangle painting all over.. as you drag the window > over > the World.. > Added info to issue 5013 and reopened. -- View this message in context: http://forum.world.st/Bug-reports-1-of-6-Damaged-Window-rectangles-on-Scree… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 3, 2012

Re: [Pharo-project] TWM bug when deleting a snapshot

by Sean P. DeNigris

laurent laffont wrote > > snapshot browser. From here you can browse and delete snapshot - with > thumbnails ! > Looks cool. I'll play with it today. -- View this message in context: http://forum.world.st/TWM-bug-when-deleting-a-snapshot-tp4243197p4257213.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 3, 2012

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

by Igor Stasenko

On 3 January 2012 14:06, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Ben, > > yes... to answer full file name is easy... my question is because the VM doesn't do that, and it has an explicit transformation to avoid answer that... then I wonder if that would be on purpose, and why. > One thing that comes to my mind is that, in macs, a program is a directory, for example, vm would be: /path/to/Cog.app/, then the real executable is placed inside this directory following a convention: MyApp.app/Contents/MacOS/MyApp > > So, question is: from mac point of view... which one is the "full path"? /path/to/Cog.app or /path/to/Cog.app/Contents/MacOS/Cog? > i vote for the full path to executable , i.e. /path/to/Cog.app/Contents/MacOS/Cog because you can always strip down unwanted information (just do regexp like '.app/Contents'), while it is much harder to reproduce original information if your source obscures it in that way. > cheers, > Esteban > > El 03/01/2012, a las 9:54a.m., Ben Coman escribiÃ³: > >> Esteban Lorenzano wrote: >>> El 02/01/2012, a las 4:39p.m., David T. Lewis escribiÃ³: >>> >>> >>>>> 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? >>>> >>> >>> I don't remember :) >>> so, how can we solve this? of course, it is not a problem to make getSystemAttribute: 0 answer argv[0], but that's not the expected behavior... we can be making a mistake, because it should answer vm path, no vm fullName. >>> I can add a 10XX number to answer vm full name, but that will lead to consistency problems inside the image... >>> I really don't know how to proceed :( >>> >>> Esteban >>> >>> >>> >> Esteban, >> I am not sure of the semantics within Smalltalk, but within both Windows & Linux "full path" includes the filename. Â Examples... >> >> Linux `which` command [1] >> Â "...printing the full path when used from a script" >> Â > echo `which q2` >> Â /home/carlo/bin/q2 >> >> Windows Path.GetFullPath method [2] >> Â "Returns the absolute path for the specified path string." >> Â // GetFullPath('mydir') returns 'C:\temp\Demo\mydir' >> Â // GetFullPath('myfile.ext') returns 'C:\temp\Demo\myfile.ext' >> >> From browsing around it does seem harder on OSX to determine the path to the current executable [3,4,5,6] but I'm not qualified to comment. >> >> cheers, Ben >> >> [1] http://linux.die.net/man/1/which >> [2] http://msdn.microsoft.com/en-us/library/system.io.path.getfullpath.aspx >> [3] http://stackoverflow.com/questions/799679/programatically-retrieving-the-ab… >> [4] http://stackoverflow.com/questions/1023306/finding-current-executables-path… >> [5] http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-e… >> [6] http://stackoverflow.com/questions/3200651/application-path-location-in-ms-… >> >> >> > > -- Best regards, Igor Stasenko.

Jan. 3, 2012

Re: [Pharo-project] glamour and pharo

by Igor Stasenko

On 3 January 2012 15:21, Ben Coman <btc(a)openinworld.com> wrote: > > I am reminded of an article "Things You Should Never Do" [1] by one of my > favourite authors. Â This is not to discourage the clean out and > re-architecture of Pharo which is overall a good thing, but just to consider > the downside and risk as a counter-point. Certainly Pharo is more evolving > than starting from scratch... > And then I got sucked into reading another (perhaps offtopic) article > "Painless Functional Specifications" [2] that some may find interesting > > [1] http://www.joelonsoftware.com/articles/fog0000000069.html > [2] http://www.joelonsoftware.com/articles/fog0000000036.html > > yes, a new is not necessary better than old. And if you ask me, i never throw away stuff, just because it is 'old'. if its in good condition and still can be used, why we should throw it away? To my experience, all code we thrown away in Pharo (where i participated) were because it is no longer used or was replaced with better , cleaner, simpler , more robust implementation. -- Best regards, Igor Stasenko.

Jan. 3, 2012

Re: [Pharo-project] glamour and pharo

by Ben Coman

Igor Stasenko wrote: > On 3 January 2012 14:35, Lukas Renggli <renggli(a)gmail.com> wrote: > >>>>> 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? >>>> >>> What coupling you are talking about? Can you give an example? >>> Instead we striving to decouple components of the system and improve >>> infrastructure. >>> If you speaking about announcements, so here the vision: >>> - there are tons of different event driving mechanisms in image >>> and we want to leave only one, replacing all of them with announcements. >>> Will this couple tools to announcements? Of course. >>> Will this add unnecessary coupling between layers? No. Because >>> announcements is inherently >>> serving for decoupling event source(s) from event consumers. >>> >> THis is not about announcements. I am talking about adding new UI, >> FileSystem, Refactoring, Compiler, Tools, ... frameworks. Any such >> addition will increase the coupling in Pharo because the core and >> external clients will start to slowly adapt these frameworks. This >> adaptation increases the coupling (to this particular framework) and >> means that it will be increasingly hard to unload or replace them in >> the future. >> >> Or shorter: What you add today, you cannot easily remove again tomorrow. >> >> > > i don't understand your concerns here. > if we replacing old compiler with a new one, should external clients > adapt new compiler? > sure they should. but they will only benefit from that. so i don't see > what are problem here? > > and about unloading.. do you think it will be worse than in existing system? > or you suspect that we're not caring about that in new frameworks design? > again, i don't really understand what is your concerns grounded on. > should we stop improving system because any change have a potential > risk of breaking someone's code? > > >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> > > I am reminded of an article "Things You Should Never Do" [1] by one of my favourite authors. This is not to discourage the clean out and re-architecture of Pharo which is overall a good thing, but just to consider the downside and risk as a counter-point. Certainly Pharo is more evolving than starting from scratch... And then I got sucked into reading another (perhaps offtopic) article "Painless Functional Specifications" [2] that some may find interesting [1] http://www.joelonsoftware.com/articles/fog0000000069.html [2] http://www.joelonsoftware.com/articles/fog0000000036.html

Jan. 3, 2012

Re: [Pharo-project] About announcements

by Igor Stasenko

On 3 January 2012 14:20, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> If everybody has its own version then we do not improve the infrastructure. >>> >>> Performance issues aside, the current implementation forces me to use >>> a different implementation because Pharo's announcements have a >>> different implementation of selecting the handler (point 7). However, >>> the really weird thing is that Pharo's announcements are now suddenly >>> inconsistent with the Pharo exceptions and how they select the >>> handler. Do you think this is better or worse? >>> >> you lost me here. why announcements have to be consistent with >> exceptions? something which is completely >> orthogonal to them? > > Exceptions and Announcements used to implement a very similar > protocol: see their implementation of X class>>#handles:, X>>on:do:, > XSet>>#handles:, XSet>>#, etc. > as well as it could serve as a source of confusion, because you using same protocol for different purposes in two different frameworks. A medal always has two sides :) > Consistency makes frameworks easy to understand and use. > >> it is like saying that apples are inconsistent with oranges. > > - Apples and oranges are inconsistent the way they are eaten (oranges > have to be piled first and come in slices). > > - Apples and pears are consistent the way they are eaten (even if they > taste very different). > > If that is too abstract replace > > Â Apples => Announcements > Â Oranges => change:/update: > Â Pears => Exceptions > your analogy having a small glitch: all those objects sharing common property - they can be eaten. now in smalltalk you can do anything, any object can be 'eaten'. but it doesn't means that they should, otherwise we're just put all behavior in Object class, and use subclasses as a dumb state holders (color, taste, hasToBePiled etc) Exceptions are conceptually different from Announcements in a way they should be used and handled, and i don't see a great value of having synergy between them. If we keep driving analogies, i think a more precise would be to tell that exceptions are to be 'eaten' and announcements are to be 'heard'. And in that way there is no consistency at all. Actually a logic with using inheritance chain to determine whether announcement should be delivered to subscription or not is IMO a major flaw, borrowed from Exceptions. Because testing a class membership is an expensive operation and if you are so concerned about performance, this is a first thing which you would be likely remove. > Lukas > > > >> >> aside of that, i added the changeset, so you can now choose whether >> your announcement subscription is handling >> announcement or not based on announcement object itself, not its class. >> see http://code.google.com/p/pharo/issues/detail?id=5145 >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Best regards, Igor Stasenko.

Jan. 3, 2012

Re: [Pharo-project] glamour and pharo

by Igor Stasenko

On 3 January 2012 14:35, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> 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? >> >> What coupling you are talking about? Can you give an example? >> Instead we striving to decouple components of the system and improve >> infrastructure. >> If you speaking about announcements, so here the vision: >> Â - there are tons of different event driving mechanisms in image >> and we want to leave only one, replacing all of them with announcements. >> Will this couple tools to announcements? Of course. >> Will this add unnecessary coupling between layers? No. Because >> announcements is inherently >> serving for decoupling event source(s) from event consumers. > > THis is not about announcements. I am talking about adding new UI, > FileSystem, Refactoring, Compiler, Tools, ... frameworks. Any such > addition will increase the coupling in Pharo because the core and > external clients will start to slowly adapt these frameworks. This > adaptation increases the coupling (to this particular framework) and > means that it will be increasingly hard to unload or replace them in > the future. > > Or shorter: What you add today, you cannot easily remove again tomorrow. > i don't understand your concerns here. if we replacing old compiler with a new one, should external clients adapt new compiler? sure they should. but they will only benefit from that. so i don't see what are problem here? and about unloading.. do you think it will be worse than in existing system? or you suspect that we're not caring about that in new frameworks design? again, i don't really understand what is your concerns grounded on. should we stop improving system because any change have a potential risk of breaking someone's code? > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Best regards, Igor Stasenko.

Jan. 3, 2012

Re: [Pharo-project] Bug reports: 2 of 6:

by S Krish

( SimpleButtonMorph new extent: 80@60 ; label: 'test' ; on:#click send: #value to:[ [UIManager default inform: 'test' ] fork]; color: Color red) openInWorld. the fork helps.. it simply lets the on:send:to: method continue to finish up the clean up and invoke the mouseUp... It is simply that this target code if it blocks.. it blocks the mouseUp call to the morph and thereby holds the morph as the clickClient... On Tue, Jan 3, 2012 at 5:05 PM, Ben Coman <btc(a)openinworld.com> wrote: > S Krish wrote: > >> 2. bug with mouseUp not passing through for event handling with >> on:send:to: target... >> >> click all over the World and you will keep getting the dialog though you >> are not clicking the morph. >> #clickClient in MouseClickState holds the morph as the recipient morph >> for >> clicks.. rather than the modal dialog.. >> >> ( SimpleButtonMorph new extent: 80@60 ; label: 'test' ; on:#click send: >> #value to:[ UIManager default inform: 'test']; color: Color red) >> openInWorld. >> >> >> > Replicated on: > Pharo-1.2.1-OneClick > Pharo-1.3-13315-OneCLick > Pharo-1.4-14263. Additional observation is that specifically clicking the > <OK> button on the dialog does not close it. > Right-clicking anywhere fixes the behaviour such that clicking <OK> does > close the dialog rather than creating a new one. > > >

Jan. 3, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

>>> 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? > > What coupling you are talking about? Can you give an example? > Instead we striving to decouple components of the system and improve > infrastructure. > If you speaking about announcements, so here the vision: > Â - there are tons of different event driving mechanisms in image > and we want to leave only one, replacing all of them with announcements. > Will this couple tools to announcements? Of course. > Will this add unnecessary coupling between layers? No. Because > announcements is inherently > serving for decoupling event source(s) from event consumers. THis is not about announcements. I am talking about adding new UI, FileSystem, Refactoring, Compiler, Tools, ... frameworks. Any such addition will increase the coupling in Pharo because the core and external clients will start to slowly adapt these frameworks. This adaptation increases the coupling (to this particular framework) and means that it will be increasingly hard to unload or replace them in the future. Or shorter: What you add today, you cannot easily remove again tomorrow. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 3, 2012

Re: [Pharo-project] Bug Report: 6 of 6: Settings

by S Krish

Thats already there.. it does show the highlighted background and also a tip on the text area below to accept on cr. But as lazy as we are we do not notice hints obvious in the face of habits. On Tue, Jan 3, 2012 at 6:27 PM, Ben Coman <btc(a)openinworld.com> wrote: > Mariano Martinez Peck wrote: > >> On Tue, Jan 3, 2012 at 1:11 PM, Alain Plantec <alain.plantec(a)yahoo.com>** >> wrote: >> >> >> >>> Le 03/01/2012 11:57, S Krish a Ã©crit : >>> >>> This works... >>> >>> >>>> Guess I should have tried that.. >>>> >>>> >>>> >>> thanks. >>> but you are not the first one to forget to enter a cr. >>> >>> >>> >> >> Yes, I was the first one!!! I remember I have reported the same ;) >> >> >> > A small thought - the field background might be made to change colour > during entry until it is accepted by <cr>. > >

Jan. 3, 2012