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

Re: [Pharo-project] [BUG] Issue 945 still can be reproduced

by Mariano Martinez Peck

Hi. I was who reported that issue. If you can see, on Dec 07, 2009 I commented: " yes, true. I would attach the fix in both 1.0 and 1.1 " I cannot do any more. I put it as Milestone-1.0 and fixed. Hope someone may integrate this so that it can be included in the next dev image I will build. Cheers Mariano On Mon, Jan 18, 2010 at 10:18 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Jan 18, 2010, at 10:13 AM, George Herolyants wrote: > > > Hi all, > > > > I've just checked in the latest dev image (10.01.1). The bug > > http://code.google.com/p/pharo/issues/detail?id=945 is still there > > despite it was marked as 'closed' in the tracker. > > Btw, Squeak Trunk incorporated not nil check as a workaround. I also > > did it in my working image (as many other people, I think). > > Did you publish a slice? or is it in your cs? > isNil is a way to often turn around the problem. > > > > So why > > doesn't Pharo do the same at least until the right fix will be > > proposed? > > time. time time time time time time time time > Probably and knowledge sometimes. This system is also complex :) > > > > I bother you with it because I believe it prevents Pharo to gain new > > users (at least those who mostly uses Windows platform). > > Thanks george we will have a look! > > > > > > George > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 18, 2010

Re: [Pharo-project] [BUG] Issue 945 still can be reproduced

by StÃ©phane Ducasse

On Jan 18, 2010, at 10:13 AM, George Herolyants wrote: > Hi all, > > I've just checked in the latest dev image (10.01.1). The bug > http://code.google.com/p/pharo/issues/detail?id=945 is still there > despite it was marked as 'closed' in the tracker. > Btw, Squeak Trunk incorporated not nil check as a workaround. I also > did it in my working image (as many other people, I think). Did you publish a slice? or is it in your cs? isNil is a way to often turn around the problem. > So why > doesn't Pharo do the same at least until the right fix will be > proposed? time. time time time time time time time time Probably and knowledge sometimes. This system is also complex :) > I bother you with it because I believe it prevents Pharo to gain new > users (at least those who mostly uses Windows platform). Thanks george we will have a look! > > > George > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 18, 2010

[Pharo-project] [BUG] Issue 945 still can be reproduced

by George Herolyants

Hi all, I've just checked in the latest dev image (10.01.1). The bug http://code.google.com/p/pharo/issues/detail?id=945 is still there despite it was marked as 'closed' in the tracker. Btw, Squeak Trunk incorporated not nil check as a workaround. I also did it in my working image (as many other people, I think). So why doesn't Pharo do the same at least until the right fix will be proposed? I bother you with it because I believe it prevents Pharo to gain new users (at least those who mostly uses Windows platform). George

Jan. 18, 2010

Re: [Pharo-project] CUIS new Text Editor Classes

by Tudor Girba

Hi Fernano, Any new development on this front? :) Cheers, Doru On 12 Jan 2010, at 16:40, Tudor Girba wrote: > Hi Fernando, > > This sounds really exciting :) > > Cheers, > Doru > > > On 12 Jan 2010, at 13:32, Fernando olivero wrote: > >> Stef, i've started from CUIS. >> >> This is what i have done so far. >> >> 1. Added the System-TextAttributes category >> 2. Moved the classes from Collections-Text to System-TextAttributes >> 3. Added System-Text category >> 4. Move Text from Collections-Text to System-Text. >> 5. File in CUIS new classes: Editor, SimpleEditor, TextEditor and >> SmalltalkEditor. >> 6. Removed Collections-Text category. >> >> Problems started here: >> >> >> 7. >> Merge CUIS Text class with Pharo Text class. >> >> (Cuis) Text has an attribute named initialStyle not present in >> (Pharo) Text. This is the main diff from both images. >> >> >> 8. Merge CUIS NewParagraph with Pharo NewParagraph >> >> (Pharo) NewParagraph has an attribute named textStyle not present >> in (Cuis) Pharo. >> >> In several NewParagraph methods CUIS doesn't care is some strings >> are isOctetString, and the Pharo NewParagraph does. For example >> #composeAll. >> I've preserved the Pharo behavior. >> >> >> Maybe i should start with the Squeak port then? >> >> >> Further steps: >> >> 9. Merge (cuis) TextMorph and (pharo) TextMorph, making it have a >> non-smalltalk,TextEditor. >> >> 10. Create (pharo) CodeMorph, replacing a TextMorph with a >> SmalltalkEditor. >> To my opinion , this will the major contribution, separating >> TextEditor and SmalltlakEditor concernes and their proper views , >> TextMorph and CodeMorph. >> >> >> Fernando >> >> >> On Jan 10, 2010, at 10:43 PM, StÃ©phane Ducasse wrote: >> >>> Excellent fernando! >>> Did you start from squeak or cuis >>> I was planning to start from Squeak since they ported back CUIS >>> code in the context >>> of WideStrings (CUIS is pre unicode support) >>> >>> Stef >>> >>>> Juan re-factored the smalltalk behavior in the editors, creating >>>> the following hierarchy >>>> >>>> Editor >>>> TextEditor SimpleEditor >>>> SmalltalkEditor >>>> >>>> >>>> See the comment in Editor class in Cuis image http://www.jvuletich.org/Cuis/Index.html >>>> . >>>> >>>> New text editors. >>>> TextEditor provides most of the functionality that used to be in >>>> TextMorphEditor. This class is no longer a Controller! >>>> >>>> SmalltalkEditor is has Smalltalk code specific features. >>>> >>>> SimpleEditor provides basic functionality for single line text >>>> editing. It does not handle fonts and styles, aligning and >>>> Smalltalk utilities. It handles one single line. >>>> >>>> Would be nice to adopt this refactoring into Pharo, i've started >>>> to port it and cleaning up the textmorph in the process. But it's >>>> still a work in progress. >>>> >>>> Fernando >>>> >>>> On Jan 10, 2010, at 3:09 PM, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>>> Gary and others >>>>>> >>>>>> I really think that we should do an audit of Morphic. In 1.1 we >>>>>> are >>>>>> going already faster but I'm sure that there is plenty >>>>>> of space for improvements. >>>>>> >>>>>> I see several actions >>>>>> - checking squeak toolbuilder enhancements and using it for >>>>>> the tools >>>>>> >>>>>> - checking CUIS >>>>>> - juan did an excellent job remocving a lot of unnecessary code >>>>>> - juan optimize scrollbar >>>>>> - juan did a new texteditor morph >>>>> >>>>> Indeed, a text editor that does not hardcode smalltalk specific >>>>> behavior would be great :). >>>>> >>>>>> - removing/cleaning extra widgets Pluggable/nonpluggable plague. >>>>>> - integrating better polymorph into the widgets layer. >>>>>> >>>>>> What do you think? >>>>> >>>>> >>>>> Doru >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Reasonable is what we are accustomed with." >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Jan. 18, 2010

[Pharo-project] worldMenu

by StÃ©phane Ducasse

in 1.0 PasteUpMorph>>worldMenu ^ TheWorldMenu new adaptToWorld: self was defined as service extension in 1.1 services have been removed Now HostSystemMenusMacOSX uses the following pattern ... self buildSubMenusFor: World worldMenu openMenu. ... We could either reintroduce PasteUpMorph>>worldMenu or in HostSystemMenusMac Does anybody have some criteria to differentiate the two places? Stef

Jan. 18, 2010

Re: [Pharo-project] PluggableTextMorph >> getText proposed modification

by StÃ©phane Ducasse

Gary ?? Alain?? do one of you have a feedback for this change. I would like to integrate it because it makes sense to me but I'm far from a UI expert Stef On Jan 12, 2010, at 6:14 AM, Ralph Boland wrote: > In my (Squeak) project I modified PluggableTextMorph >> getText to be > as follows: > > getText > "Retrieve the current model text" > > | newText | > getTextSelector isNil ifTrue: [^Text new]. > newText := (getTextSelector numArgs = 1) > ifTrue: [model perform: getTextSelector with: self] > ifFalse: [model perform: getTextSelector]. > newText ifNil: [^Text new]. > ^newText shallowCopy > > > The change allows the getTextSelector to pass an additional argument: self. > I made this change because I wanted to know which PluggableTextMorph > was asking for text. > This is useful when one has large numbers of similar PluggableTextMorphs. > Note that the method PluggableTextMorph >> acceptTextInModel > already does this so I didn't need to modify it. > Thus I think my change makes PluggableTextMorph more consistent. > > Any chance of this change being made a part of the Pharo image? > > Frankly, I would prefer that all the GUI objects that have get/set messages > had this capability. For CheckBoxes I earlier added the capability to return > either self or some arguments (by subclassing this time). > I am happy with the result. > > Another way I could do this would be to create a holder for the > PluggableTextMorph > (or other gui object) that would respond to the getText and > acceptTextInModel messages > and would know which PluggableTextMorph is speaking to it (since there > would be only one). > The holder would replace the model in the PluggableTextMorph and have > a reference to the original model to which it could forward messages. > Again this would allow me to have a large number of similar PluggableTextMorphs. > One could create a PluggableTextMorphHolder class for this or create > a single holder > class that could work with different Morph classes (only one at a timeof course) > (by responding to messages from all of them). It would be nice of > course if these > GUI holders already existed in Squeak/Pharo so I didn't have to invent them. > > Which approach do you think is better? > > Regards, > > Ralph Boland > > > -- > I've been middle class and I've been poor. > Middle class is better. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 18, 2010

Re: [Pharo-project] ConfigurationOfAlien

by Mariano Martinez Peck

Now it is MUCH better than the last version :) Very cool. And I even have the 37 tests in green :) Cheers Mariano 2010/1/18 Fernando olivero <oliverof(a)lu.unisi.ch> > You're absolutely right! > > I messed up the repositories in my gofer script. > > I'll fix this, and also merge my ConfigurationOfAlien with the latest one > Tudor published. > > Fernando > > > On Jan 16, 2010, at 4:43 PM, Mariano Martinez Peck wrote: > > Cool Fernando!!! But...ar you sure you commited ? ;) > > Because I don't see such methods like loadMacOSX loadLibC, etc... > > I checled in both urls: 'http://www.squeaksource.com/Alien' and > MetacelloRepository > > cheers > > Mariano > > On Sat, Jan 16, 2010 at 1:19 PM, Fernando olivero <oliverof(a)lu.unisi.ch>wrote: > >> Hi, i've updated the ConfigurationOfAlien. >> >> I've added groups and load shortcuts to the class. >> >> Thanks Mariano for the tips on metacello. >> >> >> John, I bother you once again, please put the new info on the page. >> >> >> >> To load Alien in a Pharo Dev image: >> >> Gofer new >> url: 'http://www.squeaksource.com/Alien' ; >> addPackage: 'ConfigurationOfAlien'; >> load. >> >> Then evaluate the desired group/s: >> >> ConfigurationOfAlien loadCore. >> >> ConfigurationOfAlien loadTests. >> >> ConfigurationOfAlien loadLibC. >> >> ConfigurationOfAlien loadMacOSX. >> >> ConfigurationOfAlien loadVMMaker. >> >> ConfigurationOfAlien loadWin32. >> >> > > >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > <ATT00001..txt> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 18, 2010

Re: [Pharo-project] ConfigurationOfAlien

by Fernando olivero

You're absolutely right! I messed up the repositories in my gofer script. I'll fix this, and also merge my ConfigurationOfAlien with the latest one Tudor published. Fernando On Jan 16, 2010, at 4:43 PM, Mariano Martinez Peck wrote: > Cool Fernando!!! But...ar you sure you commited ? ;) > > Because I don't see such methods like loadMacOSX loadLibC, etc... > > I checled in both urls: 'http://www.squeaksource.com/Alien' and MetacelloRepository > > cheers > > Mariano > > On Sat, Jan 16, 2010 at 1:19 PM, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > Hi, i've updated the ConfigurationOfAlien. > > I've added groups and load shortcuts to the class. > > Thanks Mariano for the tips on metacello. > > > John, I bother you once again, please put the new info on the page. > > > > To load Alien in a Pharo Dev image: > > Gofer new > url: 'http://www.squeaksource.com/Alien' ; > addPackage: 'ConfigurationOfAlien'; > load. > > Then evaluate the desired group/s: > > ConfigurationOfAlien loadCore. > > ConfigurationOfAlien loadTests. > > ConfigurationOfAlien loadLibC. > > ConfigurationOfAlien loadMacOSX. > > ConfigurationOfAlien loadVMMaker. > > ConfigurationOfAlien loadWin32. > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <ATT00001..txt>

Jan. 18, 2010

Re: [Pharo-project] Smalltalk (Pharo) and String equality

by Martin McClure

Nicolas Cellier wrote: > > Sure, object databases are more interesting applications, since you > generally make such mistake only once. > As a beginner, I put a halt in the method once identified as the > source of the problem, and did not understand my mistake at first shot > since it started working again (being recompiled). The good thing is > that it helped me learning some Smalltalk superpowers faster :). Yes, I love the way that you can come to understand Smalltalk through debugging it. Modification tracking is good for more than just object databases. Object-relational mapping, distributed object systems, debugging, analysis, probably more -- all benefit from being able to tell when an object is modified, and all care at a different level of abstraction from the application itself, so it's better if you don't have to put the modification-detection code in the application code. Regards, -Martin

Jan. 18, 2010

Re: [Pharo-project] Date fromString: '6-Jan-10'

by Schwab,Wilhelm K

80/20 is probably not unreasonable, but it cannot be based on the current date - it has to be based on the date the entry occurred. In short, it has to be specified separately; even then, it's still just a guess. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of dpharris(a)telus.net Sent: Sunday, January 17, 2010 5:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Date fromString: '6-Jan-10' Quoting csrabak(a)bol.com.br: > ... > > Python goes this way, for example. > > > - the date is assumed to be between 80 years in the past and 20 > > years in the future (eg Java's SimpleDateFormat, see > > http://java.sun.com/javase/7/docs/api/java/text/SimpleDateFormat.htm > > l) > > - allow the 100 year-period in which 2-digit years will be placed > > to be specified (eg the Java SimpleDateFormat also allows this) > > > > This an interesting advantage (at first) that uses some moving epoch > to compute the century, but has IMNHO a terrific disadvantage: it will > break unit tests as soon your code crosses the boundary of ten years > period (like some code done last year and tested in 2011). I think this is a *sliding* period: 80 years before the *current* year, and 20 years into the future from the *current* year. So, presently this would be from 1911 to 2030, next year it would be 1912-2031. I would suspect this would cover most uses, and is easy to specify. (Birth dates might be a common exception. ) I agree that using 4-digit years is best for user input. David _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 17, 2010