May 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] More relicensing

by Gabriel Cotelli

Ok, I would try to rewrite then BlockContext>>argumentCount Character class>>codePoint: Character>>codePoint and the following: 'DictionaryTest' >> testOccurrencesOf 'DictionaryTest' >> testIncludesAssociationNoValue 'HeapTest' >> testAdd 'HeapTest' >> testFirst 'HeapTest' >> testSortBlock 'HeapTest' >> testHeap 'HeapTest' >> testDo 'HeapTest' >> testRemove DependentsArray size I'm stills doubtful about asFloatD/E/Q. Anyone has the ANSI Standard specification?, I don't want to look at the old code to implement the new and from the message names isn't clear to me what is supposed to do. Thanks, Gabriel On Sun, May 24, 2009 at 4:35 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > BlockContext>>argumentCount > > Character class>>codePoint: > > Character>>codePoint > > Number>>asFloatD > > Number>>asFloatE > > Number>>asFloatQ > > > > In the last Pharo-Dev there's no senders of that methods. > > Can I remove them? Or there's something else I should check? > > These methods are all part of the ANSI standard. Seaside requires the first > 3. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2009

Re: [Pharo-project] [ANN] Reciprocal related methods relicensing

by Gabriel Cotelli

Hi Stef, On Sun, May 24, 2009 at 4:49 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi gabriel > > I checked your code and what would be good is to do the following: > > Float class>>one > could be > ^ 1.0 That was the first thing I do... but later i noticed that the code would remain the same that the older... If it's not a problem I changed that again to this implementation. > > > It would be nice if nicolas could have a look at them before I push > them in the release stream > > Then it would be good to profile a bit them because with numbers it > would be good to have > the fastest we can. > > Stef > > > > On May 24, 2009, at 2:29 AM, Gabriel Cotelli wrote: > > > Hi, > > > > I re-implemented > > Number>>reciprocal > > Float>>reciprocal > > Fraction>>reciprocal > > Fraction>>one > > Integer>>one > > Float>>one > > > > so now are license clean. > > > > I push the changes on Pharo-Inbox (I hope, if I do the right > > procedure) and open the Issue 843 in the tracker. According with the > > instructions in the "How to contribute" wiki page I need to change > > the state of issue to "Fixed", however I can't find that option. > > Maybe I need to be a member of the project in google code?... > > > > Just in case find attached the.cs and Monticello packages generated. > > Please somebody must review the changes.. > > > > Thanks, > > Gabriel > > <MonticelloPackages.zip><RelicensingNumberRelated. > > 1.cs>_______________________________________________ > > 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 >

May 24, 2009

[Pharo-project] BytecodeAgnosticMethodNode ???

by Carlos Crosetti

while evaluating | table1 | table1 := GridMorph withColumns: #(one two). table1 addNewRow: #('uk' 'london'). table1 openInWorld. got a DNU notifier with BytecodeAgnosticMethodNode(Object)>>doesnotUderstand: #geherate Compiler>>evaluate:in:to:notifying:iffail:logged: what`s that??

May 24, 2009

Re: [Pharo-project] [ANN] Reciprocal related methods relicensing

by Nicolas Cellier

Oh, If my blessing is required, then I would do what anyother would do: - look at tests results, - then at implementation. I see ZeroDivide exceptions are raised. They are raised a little later with different stack depth and different dividend, but I don't know specifications about that. I see implementation is simple and hard to attack (in a hacker's POV). So please proceed and include this changes. And post a copy of the .cs at http://bugs.squeak.org/view.php?id=6989 Just one remark about tests: self assert: Float one = 1.0. might be completed with: self assert: Float one isFloat. But personnally, I would not even include this in tests because I don't really care of #one specification: IMO, this is an implementation detail, not a usefull API, and has few value per se. The essential reason for that behavior, and that should be in tests is: self assert: (2.0 raisedTo: 0.0) = 1.0; assert: (2.0 raisedTo: 0.0) isFloat. I also see this test is missing, but behavior is correct: self should: [SmallInteger maxVal + 1 / 0] raise: ZeroDivide. Last, there are some IEEE 754 behaviors I will always find surprising, like (0.0 raisedTo: Float infinity) and the like - see http://bugs.squeak.org/view.php?id=6781 , but that was not the subject :) Don't know if we should write tests to document that behaviour... Nicolas 2009/5/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi gabriel > > I checked your code and what would be good is to do the following: > > Float class>>one > could be > ^ 1.0 > > It would be nice if nicolas could have a look at them before I push > them in the release stream > > Then it would be good to profile a bit them because with numbers it > would be good to have > the fastest we can. > > Stef > > > > On May 24, 2009, at 2:29 AM, Gabriel Cotelli wrote: > >> Hi, >> >> I re-implemented >> Number>>reciprocal >> Float>>reciprocal >> Fraction>>reciprocal >> Fraction>>one >> Integer>>one >> Float>>one >> >> so now are license clean. >> >> I push the changes on Pharo-Inbox (I hope, if I do the right >> procedure) and open the Issue 843 in the tracker. According with the >> instructions in the "How to contribute" wiki page I need to change >> the state of issue to "Fixed", however I can't find that option. >> Maybe I need to be a member of the project in google code?... >> >> Just in case find attached the.cs and Monticello packages generated. >> Please somebody must review the changes.. >> >> Thanks, >> Gabriel >> <MonticelloPackages.zip><RelicensingNumberRelated. >> 1.cs>_______________________________________________ >> 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 >

May 24, 2009

[Pharo-project] Could not load VMMaker in 10315

by StÃ©phane Ducasse

Hi I did ScriptLoader loadFFI Then loaded VMMaker-dtl.122 Then proceeded when asked about klatt. And I got Cannot compile -- stack including temps is too deep what did I miss? Stef

May 24, 2009

Re: [Pharo-project] [ANN] Reciprocal related methods relicensing

by StÃ©phane Ducasse

Hi gabriel I checked your code and what would be good is to do the following: Float class>>one could be ^ 1.0 It would be nice if nicolas could have a look at them before I push them in the release stream Then it would be good to profile a bit them because with numbers it would be good to have the fastest we can. Stef On May 24, 2009, at 2:29 AM, Gabriel Cotelli wrote: > Hi, > > I re-implemented > Number>>reciprocal > Float>>reciprocal > Fraction>>reciprocal > Fraction>>one > Integer>>one > Float>>one > > so now are license clean. > > I push the changes on Pharo-Inbox (I hope, if I do the right > procedure) and open the Issue 843 in the tracker. According with the > instructions in the "How to contribute" wiki page I need to change > the state of issue to "Fixed", however I can't find that option. > Maybe I need to be a member of the project in google code?... > > Just in case find attached the.cs and Monticello packages generated. > Please somebody must review the changes.. > > Thanks, > Gabriel > <MonticelloPackages.zip><RelicensingNumberRelated. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2009

Re: [Pharo-project] More relicensing

by Lukas Renggli

> This is probably because now we have BlockClosure (Eliot closure changes). > Actually BlockContext>>argumentCount was copied and added recently to > BlockClosure. I don't know if BlockContext is still used. It shouldn't be in use anymore, unless there are old methods in your image (for example compiled by the "New Compiler"). Please don't remove BlockContext yet, having it present (even as an empty class) makes it possible that code can be packaged and loaded for closure and non-closure images. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

May 24, 2009

Re: [Pharo-project] More relicensing

by Lukas Renggli

> BlockContext>>argumentCount > Character class>>codePoint: > Character>>codePoint > Number>>asFloatD > Number>>asFloatE > Number>>asFloatQ > > In the last Pharo-Dev there's no senders of that methods. > Can I remove them? Or there's something else I should check? These methods are all part of the ANSI standard. Seaside requires the first 3. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

May 24, 2009

Re: [Pharo-project] More relicensing

by StÃ©phane Ducasse

On May 24, 2009, at 2:43 AM, Gabriel Cotelli wrote: > I noticed the following methods in the dirty list: > > BlockContext>>argumentCount > Character class>>codePoint: > Character>>codePoint I would not remove the previous one but rewrite them. > > Number>>asFloatD > Number>>asFloatE > Number>>asFloatQ > > In the last Pharo-Dev there's no senders of that methods. > Can I remove them? Or there's something else I should check? > > Gabriel > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2009

Re: [Pharo-project] [ANN] Reciprocal related methods relicensing

by StÃ©phane Ducasse

yes this is the right process. Thanks stef On May 24, 2009, at 2:29 AM, Gabriel Cotelli wrote: > Hi, > > I re-implemented > Number>>reciprocal > Float>>reciprocal > Fraction>>reciprocal > Fraction>>one > Integer>>one > Float>>one > > so now are license clean. > > I push the changes on Pharo-Inbox (I hope, if I do the right > procedure) and open the Issue 843 in the tracker. According with the > instructions in the "How to contribute" wiki page I need to change > the state of issue to "Fixed", however I can't find that option. > Maybe I need to be a member of the project in google code?... > > Just in case find attached the.cs and Monticello packages generated. > Please somebody must review the changes.. > > Thanks, > Gabriel > <MonticelloPackages.zip><RelicensingNumberRelated. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2009