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

Re: [Pharo-project] Problem with Demo mode [WAS] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Alain Plantec

Le 24/05/2010 16:53, Mariano Martinez Peck a Ã©crit : > > > On Mon, May 24, 2010 at 11:56 AM, Serge Stinckwich > <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>> wrote: > > When i switch to demo mode, method selector in System Browser are no > more bold in the bottom pane. > > > I didn't understand you. Could you please attach both screenshots: how > it should be and how is it ? > > Alain do you know about this ? Hi, Strange, I've tested and all is ok here. could you try with -------- StandardFonts setDemoFonts -------- Alain > > Cheers

May 24, 2010

Re: [Pharo-project] ClassTestCase

by StÃ©phane Ducasse

Mariano Some of the combinations are inlined automatically by the compiler as levente explained. The problems is that without a rule checking that for me, I cannot remember which one are optimized :) Now the cost is that if you have more inlined expressions, then the decompiler gets more complex. So having a good and flexible decompiler would be a way to favor optimization. For now the list of levente and a slow machine "So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible." is the one to use Now > > 2010/5/24 Levente Uzonyi <leves(a)elte.hu> > On Sun, 23 May 2010, Mariano Abel Coca wrote: > > There are few now, but it was done yesterday in a few hours. We will keep > adding new tests to that suites, so suggestions are welcome :). > > Actually there are only 3 tests there: > > - One that checks that all the methods in the image are categorized > - One that checks that never redefine #doesNotUnderstand: without redefining > #respondsTo: and vice versa. > - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= > nil, etc. as suggested in issue 1594 (Actually, after reading this issue is > that we started with this idea). > > "x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and > "== nil" is not less readable if you know what #== means (but that's basic smalltalk knowledge, so it's fair to assume that everybody knows it). > > Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible). > > So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should be used whenever possible. > > (*) Benchmarks on my slow machine: > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average asFloat. "===> 386.6" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average asFloat. "===> 586.4" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> 282.3" > > 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 393.6" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) average asFloat. "===> 585.2" > > 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584" > > > > I ask completely in ignorance, but can't we do some Compiler/Parser teaks so that allow us to write the more readable and nice but then it convert them to the fast ones? > > > > > > Levente > > > Cheers, > > Mariano. > > > On Sun, May 23, 2010 at 4:53 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > Sounds exciting can you tell us a bit more? > > On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote: > > If anyone want, can take a look at: > > http://www.squeaksource.com/CodeQualityTests > http://www.squeaksource.com/CodeStandardsTests > > And run the tests before committing the next version of their packages. > > We will try to help to pass the tests as soon as possible. > > Cheers, > > Mariano. > > > On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza < > patchinko(a)gmail.com> wrote: > We're working on it, making small changes and creating code standards > tests and code quality tests. > > It would be great to have a way of tracking the results of these tests > in a distant future and make them mandatory before integrate new > things into the image. > > Francisco > > On Sat, May 22, 2010 at 7:17 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > What I was thinking mariano is that we could move one class at a time > in classTests and make the tests green. > This way we do not have red tests and still make progress > Stef > > > On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: > > It is a must. We have to got all the tests in green. But actually that > isn't tested. > > I'll make the tests, I'll fix them, and then I'll send the whole > changes to merge in the baseline. > > Cheers, > > Mariano. > > > On Sat, May 22, 2010 at 2:58 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > the key point is that we would like to avoid to have red tests all the > time > so fixing the as yet unclassified should be done before. > > > BTW Does anybody use > BadEqualer > HashTester > PrototypeTester > > because so far I do not see anybody user of them. > They look like experiment code to me. > > Stef > > On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: > > Hi, I want to make global the checks included in ClassTestCase, and > remove it. That is because actually it's only being tested for it's > subclasses. And also, it's declaring that a subclass will be a class test > instead of just a test, but no one of it's subclasses actually test the > class, but the instances, therefore is a TestCase, not a ClassTestCase. See > TimespanTest as an example. > > What Im saying is that I'm trying to force a run of a suit of Code > Standards and Code Quality tests before sending something to merge to a > baseline of a project. > > What do you think? Are you agree with that? > > Cheers, > > Mariano. > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Levente Uzonyi

On Mon, 24 May 2010, Mariano Martinez Peck wrote: > 2010/5/24 Levente Uzonyi <leves(a)elte.hu> > >> On Sun, 23 May 2010, Mariano Abel Coca wrote: >> >> There are few now, but it was done yesterday in a few hours. We will keep >>> adding new tests to that suites, so suggestions are welcome :). >>> >>> Actually there are only 3 tests there: >>> >>> - One that checks that all the methods in the image are categorized >>> - One that checks that never redefine #doesNotUnderstand: without >>> redefining >>> #respondsTo: and vice versa. >>> - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= >>> nil, etc. as suggested in issue 1594 (Actually, after reading this issue >>> is >>> that we started with this idea). >>> >> >> "x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are >> usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and >> "== nil" is not less readable if you know what #== means (but that's basic >> smalltalk knowledge, so it's fair to assume that everybody knows it). >> >> Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same >> reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible). >> >> So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should >> be used whenever possible. >> >> (*) Benchmarks on my slow machine: >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average >> asFloat. "===> 386.6" >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average >> asFloat. "===> 586.4" >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> >> 282.3" >> >> 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908" >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average >> asFloat. "===> 393.6" >> >> ((1 to: 10) collect: [ :run | >> [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) >> average asFloat. "===> 585.2" >> >> 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584" >> >> > > I ask completely in ignorance, but can't we do some Compiler/Parser teaks so > that allow us to write the more readable and nice but then it convert them > to the fast ones? I think "== nil" is just as readable as "isNil" and "isNil ifTrue:" is less readable than "ifNil:". So I don't see what you're suggesting. Levente > > > > > >> >> Levente >> >> >>> Cheers, >>> >>> Mariano. >>> >>> >>> On Sun, May 23, 2010 at 4:53 AM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr >>> >>>> wrote: >>>> >>> >>> Sounds exciting can you tell us a bit more? >>>> >>>> On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote: >>>> >>>> If anyone want, can take a look at: >>>>> >>>>> http://www.squeaksource.com/CodeQualityTests >>>>> http://www.squeaksource.com/CodeStandardsTests >>>>> >>>>> And run the tests before committing the next version of their packages. >>>>> >>>>> We will try to help to pass the tests as soon as possible. >>>>> >>>>> Cheers, >>>>> >>>>> Mariano. >>>>> >>>>> >>>>> On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza < >>>>> >>>> patchinko(a)gmail.com> wrote: >>>> >>>>> We're working on it, making small changes and creating code standards >>>>> tests and code quality tests. >>>>> >>>>> It would be great to have a way of tracking the results of these tests >>>>> in a distant future and make them mandatory before integrate new >>>>> things into the image. >>>>> >>>>> Francisco >>>>> >>>>> On Sat, May 22, 2010 at 7:17 PM, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>> What I was thinking mariano is that we could move one class at a time >>>>>> >>>>> in classTests and make the tests green. >>>> >>>>> This way we do not have red tests and still make progress >>>>>> Stef >>>>>> >>>>>> >>>>>> On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: >>>>>> >>>>>> It is a must. We have to got all the tests in green. But actually that >>>>>>> >>>>>> isn't tested. >>>> >>>>> >>>>>>> I'll make the tests, I'll fix them, and then I'll send the whole >>>>>>> >>>>>> changes to merge in the baseline. >>>> >>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Mariano. >>>>>>> >>>>>>> >>>>>>> On Sat, May 22, 2010 at 2:58 PM, StÃ©phane Ducasse < >>>>>>> >>>>>> stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> the key point is that we would like to avoid to have red tests all the >>>>>>> >>>>>> time >>>> >>>>> so fixing the as yet unclassified should be done before. >>>>>>> >>>>>>> >>>>>>> BTW Does anybody use >>>>>>> BadEqualer >>>>>>> HashTester >>>>>>> PrototypeTester >>>>>>> >>>>>>> because so far I do not see anybody user of them. >>>>>>> They look like experiment code to me. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: >>>>>>> >>>>>>> Hi, I want to make global the checks included in ClassTestCase, and >>>>>>>> >>>>>>> remove it. That is because actually it's only being tested for it's >>>> subclasses. And also, it's declaring that a subclass will be a class test >>>> instead of just a test, but no one of it's subclasses actually test the >>>> class, but the instances, therefore is a TestCase, not a ClassTestCase. >>>> See >>>> TimespanTest as an example. >>>> >>>>> >>>>>>>> What Im saying is that I'm trying to force a run of a suit of Code >>>>>>>> >>>>>>> Standards and Code Quality tests before sending something to merge to >>>> a >>>> baseline of a project. >>>> >>>>> >>>>>>>> What do you think? Are you agree with that? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Mariano. >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >> >

May 24, 2010

Re: [Pharo-project] FFI Documentation

by HernÃ¡n Morales Durand

2010/5/20 Sean P. DeNigris <sean(a)clipperadams.com>: > > Â Â Â Â <apicall: long 'system' (char*) module: 'libSystem.dylib'> > Â Â Â Â Â Â Â Â Function specification > Â Â Â Â Â Â Â Â Â Â Â Â - should be the first line > Â Â Â Â Â Â Â Â Â Â Â Â - enclosed in angle brackets: < > containing: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 1. Calling Convention, either apicall: (Pascal convention) or cdecl: (C > convention) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Mac - use either one > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Unix - use cdecl > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â - Windows - use apical In Windows the cdecl calling convention may be used when you want your code interfacing the external library to be portable to other platforms. > Questions: > * why would you want to build the FFI plugin yourself? To provide better failure handlers. Most of the time writing an interface is lost decoding the type of failure description when calling external functions, specially the conversion of types from Smalltalk to C (coercion). > * why would a field description have three elements? I think this is the case when you have in C char myArray [8] then you would write in the fields description: (myArray 'char' 8) Cheers, HernÃ¡n

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by StÃ©phane Ducasse

>> > > I did this once for GLCanvas, and don't want to repeat that again :) > The Balloon canvas and its uses is too damn focused on blitting, which makes > it too hard to provide a backend which doing most things on GPU. > If you want to go into vector world, you should keep a distance from > any blitting operations. > Simply because they are ineffective, CPU hungry and don't scale well. In that case what would be the next generation API (call it Athens) that would make ROME getting better and that your code would propose an API compliant interface? You could that way have a class that implements the Athens interface and the system gets improved and you would not depend on Athens. Because we should not neglect that without common API change and adaptation is and will be a pain. Stef

May 24, 2010

Re: [Pharo-project] About the Pharo Issue tracker

by Adrian Lienhard

I couldn't figure how to change that. So it does not seem possible. Adrian On May 24, 2010, at 16:52 , Mariano Martinez Peck wrote: > On Mon, May 24, 2010 at 10:37 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> Hi Guille and Carla, >> >> Yes for certain actions you need to be a committer. I added you both. >> Please feel free to help maintaining the issue tracker :) >> >> > I don't like this setting. I rather pharo users (not necessary committers) > be able to directly tag. Google code doesn't allow us that or it is just our > configuration ? > > Cheers > > Mariano > > > >> If an issue is not clear and lacking information, please add a note and/or >> ask in the mailing list. If an issue cannot be reproduced and the creator >> does not provide details, we just switch to "won't fix". >> >> Another area that needs work is to identify which issues should still be >> tackled for 1.1. In the tracker we currently have over 200 issues for >> milestone 1.1. Many are of the form "we should do X" and are not critical >> for the 1.1 release. Others may be show stopper bugs that need to be fixed. >> Identifying the latter is important. >> >> Cheers, >> Adrian >> >> On May 24, 2010, at 07:10 , Carla F. Griggio wrote: >> >>> Hmm... if I wanted to change the status of an issue to Fixed (for >> example), >>> I think I'm not able to do that either. Are you? >>> >>> Should we be commiters to be able to do these things? >>> >>> On Mon, May 24, 2010 at 2:04 AM, Carla F. Griggio >>> <carla.griggio(a)gmail.com>wrote: >>> >>>> Welcome, Guille :) It was very cool to have you in the Sprint :) >>>> >>>> I notice that if I try to post a new issue, I can't categorize it. Who >> is >>>> able to categorize issues? >>>> >>>> Carla. >>>> >>>> 2010/5/23 Guillermo Polito <guillermopolito(a)gmail.com> >>>> >>>>> Hi! >>>>> >>>>> First I may introduce myself. My name is Guillermo Polito and I'm from >>>>> Argentina. I've been using Pharo for several months with some >> colleagues >>>>> that are already here to teach OOP in the UTN university, and i've been >>>>> suscribed to this mailing list for some time. But it's my first mail >> here >>>>> :P. >>>>> >>>>> I participated yesterday in the Pharo Sprint in Argentina and there I >> had >>>>> my first look at the issue tracker. And well, it seemed to me to be a >>>>> little messy. There are lots of issues that aren't properly explained, >> some >>>>> of them are duplicated, and they are not well organized. >>>>> It would be nice to use the labels googlecode provides to give them >> some >>>>> categorization, so we can browse them in a more intelligent way. Maybe >> we >>>>> can split the issues in "modules" (like Collection issues, Compiler >> Issues, >>>>> Closures Issues, Networking Issues...) or something like that. That >> will >>>>> help in avoiding duplications and looking for issues to solve (because >> I can >>>>> look for issues in the modules I know the most). >>>>> >>>>> At the moment I will stay looking for issues i can fix or commenting >> the >>>>> ones that lacks information :). >>>>> >>>>> Regards, >>>>> Guille >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Mariano Martinez Peck

2010/5/24 Levente Uzonyi <leves(a)elte.hu> > On Sun, 23 May 2010, Mariano Abel Coca wrote: > > There are few now, but it was done yesterday in a few hours. We will keep >> adding new tests to that suites, so suggestions are welcome :). >> >> Actually there are only 3 tests there: >> >> - One that checks that all the methods in the image are categorized >> - One that checks that never redefine #doesNotUnderstand: without >> redefining >> #respondsTo: and vice versa. >> - And one that checks that never sent = nil, ==nil, nil =, or nil ==, ~= >> nil, etc. as suggested in issue 1594 (Actually, after reading this issue >> is >> that we started with this idea). >> > > "x = nil", "nil = x", "x ~= nil", "nil ~= x", "x ~~ nil" and "nil ~~ x" are > usually bad ideas, but #isNil is 2.9x(*) slower than "== nil" and > "== nil" is not less readable if you know what #== means (but that's basic > smalltalk knowledge, so it's fair to assume that everybody knows it). > > Also "foo isNil ifTrue:" is 2.7x(*) slower than "foo ifNil:" for the same > reasons (#ifNil: will be compiled as "== nil ifTrue:" if possible). > > So "== nil" #ifNil:, #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: should > be used whenever possible. > > (*) Benchmarks on my slow machine: > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 == nil ] ] timeToRun ]) average > asFloat. "===> 386.6" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 isNil ] ] timeToRun ]) average > asFloat. "===> 586.4" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | ] ] timeToRun ]) average asFloat. "===> > 282.3" > > 586.4 - 282.3 / (386.6 - 282.3) "===> 2.915627996164908" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 ifNil: [ 2 ] ] ] timeToRun ]) average > asFloat. "===> 393.6" > > ((1 to: 10) collect: [ :run | > [ 1 to: 10000000 do: [ :i | 1 isNil ifTrue: [ 2 ] ] ] timeToRun ]) > average asFloat. "===> 585.2" > > 585.2 - 282.3 / (393.6 - 282.3). "===> 2.7214734950584" > > I ask completely in ignorance, but can't we do some Compiler/Parser teaks so that allow us to write the more readable and nice but then it convert them to the fast ones? > > Levente > > >> Cheers, >> >> Mariano. >> >> >> On Sun, May 23, 2010 at 4:53 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr >> >>> wrote: >>> >> >> Sounds exciting can you tell us a bit more? >>> >>> On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote: >>> >>> If anyone want, can take a look at: >>>> >>>> http://www.squeaksource.com/CodeQualityTests >>>> http://www.squeaksource.com/CodeStandardsTests >>>> >>>> And run the tests before committing the next version of their packages. >>>> >>>> We will try to help to pass the tests as soon as possible. >>>> >>>> Cheers, >>>> >>>> Mariano. >>>> >>>> >>>> On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz Pe?aloza < >>>> >>> patchinko(a)gmail.com> wrote: >>> >>>> We're working on it, making small changes and creating code standards >>>> tests and code quality tests. >>>> >>>> It would be great to have a way of tracking the results of these tests >>>> in a distant future and make them mandatory before integrate new >>>> things into the image. >>>> >>>> Francisco >>>> >>>> On Sat, May 22, 2010 at 7:17 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> What I was thinking mariano is that we could move one class at a time >>>>> >>>> in classTests and make the tests green. >>> >>>> This way we do not have red tests and still make progress >>>>> Stef >>>>> >>>>> >>>>> On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: >>>>> >>>>> It is a must. We have to got all the tests in green. But actually that >>>>>> >>>>> isn't tested. >>> >>>> >>>>>> I'll make the tests, I'll fix them, and then I'll send the whole >>>>>> >>>>> changes to merge in the baseline. >>> >>>> >>>>>> Cheers, >>>>>> >>>>>> Mariano. >>>>>> >>>>>> >>>>>> On Sat, May 22, 2010 at 2:58 PM, StÃ©phane Ducasse < >>>>>> >>>>> stephane.ducasse(a)inria.fr> wrote: >>> >>>> the key point is that we would like to avoid to have red tests all the >>>>>> >>>>> time >>> >>>> so fixing the as yet unclassified should be done before. >>>>>> >>>>>> >>>>>> BTW Does anybody use >>>>>> BadEqualer >>>>>> HashTester >>>>>> PrototypeTester >>>>>> >>>>>> because so far I do not see anybody user of them. >>>>>> They look like experiment code to me. >>>>>> >>>>>> Stef >>>>>> >>>>>> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: >>>>>> >>>>>> Hi, I want to make global the checks included in ClassTestCase, and >>>>>>> >>>>>> remove it. That is because actually it's only being tested for it's >>> subclasses. And also, it's declaring that a subclass will be a class test >>> instead of just a test, but no one of it's subclasses actually test the >>> class, but the instances, therefore is a TestCase, not a ClassTestCase. >>> See >>> TimespanTest as an example. >>> >>>> >>>>>>> What Im saying is that I'm trying to force a run of a suit of Code >>>>>>> >>>>>> Standards and Code Quality tests before sending something to merge to >>> a >>> baseline of a project. >>> >>>> >>>>>>> What do you think? Are you agree with that? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Mariano. >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >

May 24, 2010

[Pharo-project] Problem with Demo mode [WAS] Re: [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Mariano Martinez Peck

On Mon, May 24, 2010 at 11:56 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > When i switch to demo mode, method selector in System Browser are no > more bold in the bottom pane. > I didn't understand you. Could you please attach both screenshots: how it should be and how is it ? Alain do you know about this ? Cheers > > 2010/5/21 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Pharaoers. I am pleased to announce the first Pharo 1.1 beta based on > > PharoCore-1.1-11367-Beta. It is the first time we build a Pharo 1.1 dev > > image with PharoCore 1.1 so the image may be not 100% stable. However, we > > think it is good to release it so that people can start to test it, load > > their own packages, adapt them, etc. We would like to receive feedback > about > > it. It (yet) has failing and error tests. > > > > The main changes with Pharo 1.0 is that of course, it is based on a > > PharoCore 1.1 with all that it means. We started to write down some of > the > > actions done in PharoCore 1.1. The list so far can be found here: > > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotOne > > Of course, for the stable releae of Pharo 1.1 we will do a clear list in > the > > website as we did for 1.0. > > > > Regarding the included packages in 1.1 we added ScriptManager (a tool to > > manage and persist workspaces), ProfStefBrowser, ArchiveViewer, > > MethodWrappers and ObjectMetaTools (which includes things like > > ProtocolCatcher, ObjectTracer, ObjectViewer, etc). > > > > Another difference is the font. In Pharo 1.0 we used TrueType fonts by > > default. In Pharo 1.1 we use StrikeFonts (no need of TrueType plugin, > > netiher to have the fonts). However, of course, you can disable > StrikeFonts > > and put TrueType like in 1.0. > > > > That's all. We would really appreciate you use it, test it, report > issues, > > provide fixes, etc. It is important also that you start to use your own > > packages/applications. There have been several changes in 1.1 that may > > require change in your code. > > > > Ahh if you want to create the image yourself, check as usually the > > installScript.st file to see how to do it. Actually, you can just take a > > PharoCore-1.1-11367-Beta image and evaluate (the same procedure as 1.0): > > > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfPharo'; > > load. > > > > ((Smalltalk at: #ConfigurationOfPharo) project version: > '1.1-beta1.10517') > > load. > > > > Here is the link to the image: > > > > > https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05… > > > > Cheers > > > > Mariano > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2010

Re: [Pharo-project] About the Pharo Issue tracker

by Mariano Martinez Peck

On Mon, May 24, 2010 at 10:37 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Guille and Carla, > > Yes for certain actions you need to be a committer. I added you both. > Please feel free to help maintaining the issue tracker :) > > I don't like this setting. I rather pharo users (not necessary committers) be able to directly tag. Google code doesn't allow us that or it is just our configuration ? Cheers Mariano > If an issue is not clear and lacking information, please add a note and/or > ask in the mailing list. If an issue cannot be reproduced and the creator > does not provide details, we just switch to "won't fix". > > Another area that needs work is to identify which issues should still be > tackled for 1.1. In the tracker we currently have over 200 issues for > milestone 1.1. Many are of the form "we should do X" and are not critical > for the 1.1 release. Others may be show stopper bugs that need to be fixed. > Identifying the latter is important. > > Cheers, > Adrian > > On May 24, 2010, at 07:10 , Carla F. Griggio wrote: > > > Hmm... if I wanted to change the status of an issue to Fixed (for > example), > > I think I'm not able to do that either. Are you? > > > > Should we be commiters to be able to do these things? > > > > On Mon, May 24, 2010 at 2:04 AM, Carla F. Griggio > > <carla.griggio(a)gmail.com>wrote: > > > >> Welcome, Guille :) It was very cool to have you in the Sprint :) > >> > >> I notice that if I try to post a new issue, I can't categorize it. Who > is > >> able to categorize issues? > >> > >> Carla. > >> > >> 2010/5/23 Guillermo Polito <guillermopolito(a)gmail.com> > >> > >>> Hi! > >>> > >>> First I may introduce myself. My name is Guillermo Polito and I'm from > >>> Argentina. I've been using Pharo for several months with some > colleagues > >>> that are already here to teach OOP in the UTN university, and i've been > >>> suscribed to this mailing list for some time. But it's my first mail > here > >>> :P. > >>> > >>> I participated yesterday in the Pharo Sprint in Argentina and there I > had > >>> my first look at the issue tracker. And well, it seemed to me to be a > >>> little messy. There are lots of issues that aren't properly explained, > some > >>> of them are duplicated, and they are not well organized. > >>> It would be nice to use the labels googlecode provides to give them > some > >>> categorization, so we can browse them in a more intelligent way. Maybe > we > >>> can split the issues in "modules" (like Collection issues, Compiler > Issues, > >>> Closures Issues, Networking Issues...) or something like that. That > will > >>> help in avoiding duplications and looking for issues to solve (because > I can > >>> look for issues in the modules I know the most). > >>> > >>> At the moment I will stay looking for issues i can fix or commenting > the > >>> ones that lacks information :). > >>> > >>> Regards, > >>> Guille > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 >

May 24, 2010

Re: [Pharo-project] [BUG] VM crash during debbuging some code by Through button with Transcript>>show: in deepest inner methods

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=2469 Stef On May 23, 2010, at 4:18 PM, Denis Kudriashov wrote: > I found more bad cases with code simulation. And I think any manipulations with context (errors signals, simaphore, ...) not work in simulation mode. Transcript printing failed because of simaphore accessing (for thread safety) > > I create CodeSimulationTests (see attachement) with some tests which not work and which crash VM. > > Maybe this tests not correct. But I hope it helps to indicate and solve issues > > 2010/5/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Thanks! > > Stef > > On May 23, 2010, at 11:13 AM, Denis Kudriashov wrote: > > > And If you replace Transcript code with > > > > self halt. > > > > You will see that debugging with through button does not work. Code simulation failure raised (but without VM crash) > > > > 2010/5/23 Denis Kudriashov <dionisiydk(a)gmail.com> > > I has Pharo1.0 one click, Windows 7. > > I attach class ClassWithTranscriptPrinting. > > see class side method #debug > > > > > > > > > > > > 2010/5/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > > Hi denis > > > > can you report clearly your bug > > - image > > - vm > > - os > > - scenario > > > > I could not compile > > Transcript>>show:'something' > > > > so I do not know how you did it. > > > > > > > > On May 23, 2010, at 10:11 AM, Denis Kudriashov wrote: > > > > > Hello > > > > > > Just insert > > > Transcript>>show:'something' > > > at any method begin. > > > > > > Now debug sender of your method by debugger Through button. > > > > > > If no Transcript opened VM will crash! > > > _______________________________________________ > > > 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 > > <CodeSimulationTests.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010