- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Need someone to test if NBOpenGL works for you on win32

by HernÃ¡n Morales Durand

Hi Igor, I'm testing your work in Win32. Following instructions in this page http://code.google.com/p/nativeboost/wiki/Installation when evaluating NBInstaller install in PharoCore1.1ALPHA #11368 I receive: "You need to enable an underscore selectors in preferences first". I see no preference listed in the preferences browsers and didn't found the #allowUnderscoreSelectors for enabling this setting. Any idea? Cheers, HernÃ¡n 2010/5/24 Igor Stasenko <siguctua(a)gmail.com>: > Hi, > > i just snapshotted my stuff with various fixes, to make it load > cleanly on pharo and squeak images. > > I'd like you to ask to test and load it and tell me if it works for you. > > Currently it works only on win32 platform. It could work on Linux, but > i didn't had time to port it yet. > > There is no automatic installation procedure right now, so here what > you should try: > > - first, you need to have VM with NativeBoost plugin + NativeBoost > loaded into an image > (see http://code.google.com/p/nativeboost/wiki/Installation for instructions) > > > - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL > in following order: > > - NBOpenGL-Core > - NBOpenGL-Win > - NBOpenGL-TrueType > - NBOpenGL-Display > - NBOpenGL-Morphic > > i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were > released recently, > and it seems works ok. > on squeak/trunk it should also work without problems. > > Now, if everything went right, then we're ready to run a demo: > > GLViewportMorph new "useOwnForm: true;" openInWorld > > This thing should render a TrueType glyphs and animating a smooth zoom of it. > Nothing fancy, i just wanna know, if it works for you (and how well). Â :) > > As you may know, GPU/OpenGL implementations vary depending on vendor > and how old your hardware is, > and i don't have all of it at my disposal. > > Ok.. if you got it running, and it renders the glyphs.. there's one thing left: > Â - save your image and quit (without closing this morph) > Â - start image > > it should continue working as if nothing happens. > > -- > Best regards, > Igor Stasenko AKA sig. > >

May 24, 2010

Re: [Pharo-project] ClassTestCase

by Lukas Renggli

> 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 Please read my comments on the issue tracker. For *any practical* example it doesn't matter what to use speed wise: 1 = nil ifTrue: [ ] 2 == nil ifTrue: [ ] 3 isNil ifTrue: [ ] 4 ifNil: [ ] Personally I find 3 the most readable. 1 and 3 are the only practical ones if you use OODBs, because they are not shortcut by the compiler. I only use 4 for lazy initializers, it makes a good pattern. The use of #ifNil:ifNotNil:, #ifNotNil:, #ifNotNil:ifNil: is only practicable if you don't care about compatibility with other Smalltalk dialects. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 24, 2010

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

by Igor Stasenko

On 24 May 2010 18:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >> >> 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. > Yes. But i want to stress, what meaning we are putting into 'API'. API is protocols, not classes. So, a code which renders something using API, should use only messages sent to a canvas object. The difference could be illustrated by following: a) drawOn: aCanvas path := RomePath new. path moveTo: .. lineTo:... close. aCanvas strokePath: path b) drawOn: aCanvas path := aCanvas newPath. path moveTo: .. lineTo:... close. aCanvas strokePath: path In case a) you are introducing a dependency on a concrete path implementation(RomePath). in case b) you asking a canvas to provide a path instance, which conforms to a path protocol. Here lies the main difference, which either gives you a freedom of choice, or otherwise makes your code inflexible. That's what i mean by no dependecy. In case b), a rendering backend is free to use own data structures to optimally reify a path(s), while in case a) you forcing a canvas to have an intimate knowledge about RomePath - a concrete implementation, which may not fit best for canvas and hence it will waste cycles converting a path representation into more appropriate form, in order to render it. That's why, if we follow path b), then morphic rendering could be completely autonomous, and do not depend on concrete Rome API implementation. And enforcing it from a very starting, will make sure that we won't introduce unnecessary dependencies and inflexibility. > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

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