- Pharo-dev - lists.pharo.org

Re: [Pharo-project] We will not accept any changes using initials anymore

by StÃ©phane Ducasse

> I was looking around at the Author class when issue: 209 was created. > I noticed there was inconsistency with the way it tests whether the > initials were present or not (string vs nil). I have a changeset for > that which I was planning to upload. Are you going to deprecate the > whole class or just the use of initials? > > My thoughts were to deprecate the concept of initials, and just put > the full name in the same place in the method timestamp. That way you > would not impact too much at once. There is a full name, but from > what I saw that was only related to projects, and you're going to kill > projects right? > > what do you think? yes project out! we should not have initials anymore. The Author class should just be cleaned up a bit and its senders. We can enter first.name -> firstname / name in author and use full name the way we want (camel or not) what lukas did is to make sure that you cannot enter zork@@#$Plys and that MC gets dead because you cannot create a file with one of the given character. Stef > > > cheers > Mike > > On Fri, Oct 31, 2008 at 2:16 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Yes that too. >> but the interface of authors and the senders should be fixed too. >> On Oct 31, 2008, at 2:17 PM, Damien Pollet wrote: >> >>> On Fri, Oct 31, 2008 at 1:03 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> what lukas did is to make sure that MC convert any non letter >>>> into _ so >>>> that >>> >>> ok. I was thinking of validating what people enter in the dialog (a >>> simple regexp would do) >>> >>>> Now what would be good is to radically fix Author once for all: >>>> - do not use initials at all. >>>> - deprecate it >>>> - fix all the senders >>>> - offer a nice interface >>>> - requestName >>>> - getName (accessor) >>>> - name (with request if necessary) >>>> >>>> Stef >>>> >>>> >>>> On Oct 31, 2008, at 11:58 AM, Damien Pollet wrote: >>>> >>>>> I guess it's best to adopt CamelCase FirstnameLastname, because >>>>> the >>>>> firstname.lastname format conflicts with the naming of MC >>>>> branches. >>>>> I'll update the initials dialog and try to make a more complete >>>>> fix of >>>>> this >>>>> >>>>> On Sat, Oct 25, 2008 at 7:47 PM, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>> >>>>>> done! >>>>>> Stef >>>>>> >>>>>> On Oct 25, 2008, at 8:16 PM, Dan Corneanu wrote: >>>>>> >>>>>>> On Sat, Oct 25, 2008 at 8:08 PM, StÃ©phane Ducasse >>>>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>>>> >>>>>>>> ascii only no space >>>>>>>> >>>>>>> >>>>>>> Maybe we should state that too on page >>>>>>> http://code.google.com/p/pharo/wiki/HowToContribute >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Damien Pollet >>>>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> _______________________________________________ >>> 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 >

Nov. 1, 2008

Re: [Pharo-project] [update] #1025

by StÃ©phane Ducasse

What a good feeling to have methods that were obsolete since 10 years removed from the system (I was idiot to believe that they were used...) Marcus did you change the GC parameters as mentioned by john. Stef On Oct 31, 2008, at 8:23 PM, Marcus Denker wrote: > update1025 > --------- > > Issue 303: TODO: remove profiling methods > Issue 300: unimplemented call in > AlignmentMorphBob1>>acceptDroppingMorph:event: > Issue 299: Mantis 007007 and 007008 correct toggle break on entry > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2008

Re: [Pharo-project] mac menus in Pharo

by John M McIntosh

On Oct 31, 2008, at 1:28 PM, Marcus Denker wrote: > > On 31.10.2008, at 21:18, John McIntosh wrote: > >> I'm wondering if there is any interest in having mac menus in Pharo. >> This was done for Sophie >> and Scratch, and attempted for 3.10. I could drag the required change >> sets out of storage to >> implement the proper file/edit menu in Pharo and have it respond to >> cmd-Q etc if there is >> any interest... > > Yes! I want all the things that are in the new simple world-menu in > a "real" menu. > > Marcus Done (I think) Next time I'm at ESUG I must stay more than 5 hours so that people can buy me some beer. I've posted pharo10124WithMacMenus.1.image to my idisk in the /experimental/Pharo/ folder found via http://www.smalltalkconsulting.com/squeak.html Macintosh users can take it for a spin. I note we should have a more *generic* way to convert morphic menus to the structure needed for macintosh menus but it took me a couple of hours to figure out how to make the hierarchy mac menus since I've not done that before, plus I wasted some time looking at the complicated target, argument, selector mess on the morphic menu item before discovering *doButtonAction* did the required menu activation trick on the mophic menu item. Perhaps someone clever can figure out how to read all the morphic menus and build the require mac menus. I did a bit of hand coding instead. Once everyone is happy, could someone take the pharo10124WithMacMenus. 1.image and promote to the proper MC server, I'm not quite sure how that is done, and rather not risk screwing things up quite yet. Normally macintosh application also have Windows menu for multiple host windows. Once we actually get to having multiple host windows, why turning that menu on is lurking in the code base... disableHideMenuCmd disables the cmd-H for hide squeak VM. Some people might like that, personally in some images I prefer the hierarchy browser to come up... Anyway people can decide. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 1, 2008

Re: [Pharo-project] mac menus in Pharo

by John M McIntosh

For Scratch we made a change to terminate the VM if you logout There is an info.plist setting SqueakQuitOnQuitAppleEvent which if set to true terminates the VM at logout time, no save. Likely this is NOT what you want, we could {if people want} pass up an event for the logout, and see what happens. I think there is something maybe for closing the main window on Windows? Not sure about sleep tho, don't really reading anything about getting an event when the user sleeps the system. On Oct 31, 2008, at 4:13 PM, Michael Roberts wrote: > very much so yes! > > also, how hard would it be to hook into sleep and logout style events > on the mac? it would be nice if pharo was aware of that but I don't > know what is required. Did you need/solve that in Sophie? > > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 1, 2008

Re: [Pharo-project] We will not accept any changes using initials anymore

by Michael Roberts

I was looking around at the Author class when issue: 209 was created. I noticed there was inconsistency with the way it tests whether the initials were present or not (string vs nil). I have a changeset for that which I was planning to upload. Are you going to deprecate the whole class or just the use of initials? My thoughts were to deprecate the concept of initials, and just put the full name in the same place in the method timestamp. That way you would not impact too much at once. There is a full name, but from what I saw that was only related to projects, and you're going to kill projects right? what do you think? cheers Mike On Fri, Oct 31, 2008 at 2:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes that too. > but the interface of authors and the senders should be fixed too. > On Oct 31, 2008, at 2:17 PM, Damien Pollet wrote: > >> On Fri, Oct 31, 2008 at 1:03 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> what lukas did is to make sure that MC convert any non letter into _ so >>> that >> >> ok. I was thinking of validating what people enter in the dialog (a >> simple regexp would do) >> >>> Now what would be good is to radically fix Author once for all: >>> - do not use initials at all. >>> - deprecate it >>> - fix all the senders >>> - offer a nice interface >>> - requestName >>> - getName (accessor) >>> - name (with request if necessary) >>> >>> Stef >>> >>> >>> On Oct 31, 2008, at 11:58 AM, Damien Pollet wrote: >>> >>>> I guess it's best to adopt CamelCase FirstnameLastname, because the >>>> firstname.lastname format conflicts with the naming of MC branches. >>>> I'll update the initials dialog and try to make a more complete fix of >>>> this >>>> >>>> On Sat, Oct 25, 2008 at 7:47 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> done! >>>>> Stef >>>>> >>>>> On Oct 25, 2008, at 8:16 PM, Dan Corneanu wrote: >>>>> >>>>>> On Sat, Oct 25, 2008 at 8:08 PM, StÃ©phane Ducasse >>>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>>> >>>>>>> ascii only no space >>>>>>> >>>>>> >>>>>> Maybe we should state that too on page >>>>>> http://code.google.com/p/pharo/wiki/HowToContribute >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Damien Pollet >>>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> _______________________________________________ >> 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 >

Oct. 31, 2008

Re: [Pharo-project] mac menus in Pharo

by Michael Roberts

very much so yes! also, how hard would it be to hook into sleep and logout style events on the mac? it would be nice if pharo was aware of that but I don't know what is required. Did you need/solve that in Sophie? Mike

Oct. 31, 2008

Re: [Pharo-project] mac menus in Pharo

by Lukas Renggli

Yes, I would like to have that too. Lukas On Fri, Oct 31, 2008 at 9:28 PM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > > On 31.10.2008, at 21:18, John McIntosh wrote: > >> I'm wondering if there is any interest in having mac menus in Pharo. >> This was done for Sophie >> and Scratch, and attempted for 3.10. I could drag the required change >> sets out of storage to >> implement the proper file/edit menu in Pharo and have it respond to >> cmd-Q etc if there is >> any interest... > > Yes! I want all the things that are in the new simple world-menu in > a "real" menu. > > Marcus > > > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 31, 2008

[Pharo-project] [update] #10126

by Marcus Denker

-> Issue 248: SLICE-Mantis-ScaledDecimal-SqNumberParser-Fix-nice.1 -> Issue 295: #testSupplyAnswerUsingRegexMatchOfQuestion fails -> latest collection tests 248 is a collection of fixes (thanks to Nicolas Cellier). Here is the full description: GATHER SOME FIX FROM MANTIS CONCERNING SqNumberParser AND ScaledDecimal ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=6976 This changeSet makes SqNumberParser about twice and up to four times faster than it used to in Float Number crunching. Four improvements were proposed: 1) Inline digitValue when radix <= 10. This is the main gain. 2) Don't test 'NaN' and 'Infinity' in preamble. Test only in exceptional conditions (when no digit were found). 3) hack (aRadix raisedTo: exponent) with base 2 bitShift: arithmetic and use timesTwoPower: a posteriori to avoid some LargePositiveInteger. 4) hack PositionableStream>>position: replace & condition by and: which is inlined by Compiler"! NOTE: I did not load changes for the 3) item I find optimization hackish concerning gradual underflow, for marginal gains... It could eventually enhance greatly reading hex float... You can find it as file SqNumberParser_speedUp_Patch_M6976_nice.1.cs in mantis report. ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=7174 This change set enables a further speed up for number parsing - LargeInteger (like 20 factorial) - Float with large fractionPart (like Float pi). Note that this change introduces selector #isLarge (rather than testing isKindOf: LargePositiveInteger). ------------------------------------------------------------ Additional refactorings for SqNumberParser: 1) avoid using (self readSomethingIfFail: [aBlock]), and replace with (value := self readSomething ifNil: [aBlock]) This is for efficiency (up to +25%) 2) factor repeated code into smaller methods ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=7169 SqNumberParser does not parse a ScaledDecimal with trailing zeros correctly (like 0.50s2). ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=6779 ScaledDecimal readFrom: '5.3' would not answer a ScaledDecimal ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=6976 1.00s2 isLiteral used to answer false. ------------------------------------------------------------ http://bugs.squeak.org/view.php?id=4378 Some ScaledDecimal have more precision than they actually print. They should not use printOn: to storeOn: in this case. ------------------------------------------------------------ | report | report := (String new: 1024) writeStream. report nextPutAll: 'Timing SqNumberParser for some numbers:'; cr. {'0.0'. '0.0001'. '1.2000000'. '3.14159'. '-3.14159'. '314159.276'. '3.14159e10'. '3.14159e-10'. Float pi printString. 'NaN'. '-Infinity'. '1'. '-256'. SmallInteger maxVal printString. 20 factorial printString} do: [:e | | sqBench numBench speedFactor | sqBench := [SqNumberParser parse: e readStream] bench. numBench := [Number readFrom: e readStream] bench. speedFactor := (SqNumberParser on: sqBench) nextNumber / (SqNumberParser on: numBench) nextNumber. report nextPutAll: e , ' ' , sqBench , ' Speed Up factor vs Number readFrom: = x' , (speedFactor roundTo: 0.1) printString; cr]. report contents. 'Timing SqNumberParser for some numbers: 0.0 45454.10917816437 per second. Speed Up factor vs Number readFrom: = x2.9 0.0001 25432.51349730054 per second. Speed Up factor vs Number readFrom: = x2.3 1.2000000 24007.19856028794 per second. Speed Up factor vs Number readFrom: = x2.6 3.14159 23199.5600879824 per second. Speed Up factor vs Number readFrom: = x2.2 -3.14159 22635.6728654269 per second. Speed Up factor vs Number readFrom: = x2.1 314159.276 21928.81423715257 per second. Speed Up factor vs Number readFrom: = x2.4 3.14159e10 14818.03639272146 per second. Speed Up factor vs Number readFrom: = x2.4 3.14159e-10 11181.96360727855 per second. Speed Up factor vs Number readFrom: = x2.7 3.141592653589793 5472.50549890022 per second. Speed Up factor vs Number readFrom: = x1.5 NaN 23603.27606871754 per second. Speed Up factor vs Number readFrom: = x0.4 -Infinity 32998.200359928 per second. Speed Up factor vs Number readFrom: = x0.8 1 81118.776244751 per second. Speed Up factor vs Number readFrom: = x2.7 -256 70116.1767646471 per second. Speed Up factor vs Number readFrom: = x3.2 1073741823 42773.8452309538 per second. Speed Up factor vs Number readFrom: = x3.9 2432902008176640000 16934.01319736053 per second. Speed Up factor vs Number readFrom: = x4.0 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 31, 2008

Re: [Pharo-project] mac menus in Pharo

by Marcus Denker

On 31.10.2008, at 21:18, John McIntosh wrote: > I'm wondering if there is any interest in having mac menus in Pharo. > This was done for Sophie > and Scratch, and attempted for 3.10. I could drag the required change > sets out of storage to > implement the proper file/edit menu in Pharo and have it respond to > cmd-Q etc if there is > any interest... Yes! I want all the things that are in the new simple world-menu in a "real" menu. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 31, 2008

[Pharo-project] mac menus in Pharo

by John McIntosh

I'm wondering if there is any interest in having mac menus in Pharo. This was done for Sophie and Scratch, and attempted for 3.10. I could drag the required change sets out of storage to implement the proper file/edit menu in Pharo and have it respond to cmd-Q etc if there is any interest... -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Oct. 31, 2008