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

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

by Carla F. Griggio

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 >> > >

May 24, 2010

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

by Carla F. Griggio

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 >

May 24, 2010

Re: [Pharo-project] Metacello and SourceTalk ...

by Julian Fitzell

The fact that MC2 is still a moving target. Or at least it would be if it was moving. :) More to the point, the early releases had some problems that prompted further redesign and I'd recommend against creating large amounts of date in those versions that will need to be brought forward. In other words, I don't think it's ready for prime time in its current state. Julian On Mon, May 17, 2010 at 1:34 PM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > What would be the biggest challenges moving to MC2 and a MC2 Repository > like > SourceTalk? > > > Mariano Martinez Peck wrote: > > > > Hi Geert. I agree it would awesome to have Monticello 2 and SourcTalk for > > Pharo 1.2. I have not idea the status. I tested once (you can see > > squeakdbx there) but I have a lot of problems. And the project seems > > "dead". I mean, I don't think someone is working on it. That said, it > > would be great someone to work on it and maybe start to using it by Pharo > > 1.2 > > > -- > View this message in context: > http://forum.world.st/Metacello-and-SourceTalk-tp2219294p2219517.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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 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" 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 >> >

May 23, 2010

Re: [Pharo-project] [squeak-dev] runSimulated behaviour

by Eliot Miranda

Hi Michael, Michael, Dennis, Hi All, I think this is a simple bug in ContextPart >> #tryNamedPrimitiveIn:for:withArgs:, which neglects to flush the method cache for the method and/or selector used to simulate execution of a named primitive. With the relevant flushCacher calls added I no longer see any of the simulation failures recently experienced (someMethod getSourceFromFile, TimeStamp now). Please test the attached and let me know how you get on. The problem is caused by using the same method to invoke differet primitives in quick succession where, because the method cache is not flushed, the wrong primitive (a previous primitive) is left in the cache and invoked instead of the desired primitive. In Cog I added a primitive to directly evaluate a named primitive so the problem does not occur. Adding the two lines marked >> below fixes the problem. The line "theMethod flushCache" is probably more than we need, but does not harm. HTH Eliot !ContextPart methodsFor: 'private' stamp: 'eem 5/23/2010 14:13'! tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments "Hack. Attempt to execute the named primitive from the given compiled method" | selector theMethod spec | arguments size > 8 ifTrue:[^PrimitiveFailToken]. selector := #( tryNamedPrimitive tryNamedPrimitive: tryNamedPrimitive:with: tryNamedPrimitive:with:with: tryNamedPrimitive:with:with:with: tryNamedPrimitive:with:with:with:with: tryNamedPrimitive:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with:with:) at: arguments size+1. theMethod := aReceiver class lookupSelector: selector. theMethod == nil ifTrue:[^PrimitiveFailToken]. spec := theMethod literalAt: 1. spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) startingAt: 1. >> theMethod flushCache. >> selector flushCache. ^aReceiver perform: selector withArguments: arguments! ! On Thu, May 20, 2010 at 2:55 AM, Michael Haupt <mhaupt(a)gmail.com> wrote: > Dear all, > > we're observing some strange behaviour in simulated bytecode execution > in Squeak (4.1, on Macs). > > Printing this: > ContextPart runSimulated: [ TimeStamp now ] > will work once and then reproducibly fail with code simulation errors. > > This works well (also reproducibly): > ContextPart trace: [ TimeStamp now ] > > Going to more detail, we figured out that simulation reproducibly > works if things are written to the Transcript every now and then. > Printing this: > n:=0. thisContext runSimulated: [ TimeStamp now ] contextAtEachStep: [ > :c | n\\100=0 ifTrue: [ Transcript show: $. ] ] > works. > > We've tried to just insert some artificial delays (<someValue> > milliSeconds asDelay wait) in the block, but that will not > reproducibly work; it also leads to code simulation errors. So it > can't be just the time it takes to write to Transcript. Or so we > believe. > > Does anybody know the reason for this strange behaviour, or where in > the simulation logic to look? > > Best, > > Michael > >

May 23, 2010

Re: [Pharo-project] Rendering fonts on OpenGL

by Igor Stasenko

2010/5/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: > Hi, may I ask how you are rendering these fonts? You parse the glyphs and > then render lines with opengl or use freetype to render to a texture without > antialiasing or both? Squeak has already a TT font reader, so i just taking the data from there and piping to GPU. What you see here is freely scalable vector/curve rendering done completely on GPU. > If you asked me, I'd say I like the method but for > fonts they look a bit blury, I'd say too much for the smaller ones. I think this is best what you can achieve without hinting / subpixel AA. > Also, what are you working on? > I once did a GLCanvas, and now i want to reiterate and improve it using new callout mechanism (NativeBoost), and full coverage of OpenGL API, with all extensions available at your disposal. > Regards, > Â Â Â Â Â Â Â Â Â Â Â Javier. > > 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> -- Best regards, Igor Stasenko AKA sig.

May 23, 2010

Re: [Pharo-project] Rendering fonts on OpenGL

by Javier PimÃ¡s

Hi, may I ask how you are rendering these fonts? You parse the glyphs and then render lines with opengl or use freetype to render to a texture without antialiasing or both? If you asked me, I'd say I like the method but for fonts they look a bit blury, I'd say too much for the smaller ones. Also, what are you working on? Regards, Javier. 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> > Hello, > > This is a Tahoma font, rendered with OpenGL > > look how much difference between no-AA > and with enabled multisampling. > > I think that with multisampling, the quality is quite good to not > bother about sub-pixel AA. > Sub-pixel AA could be added later, if there's any brave soul who can > implement a fragment shader for it :) > > Moreover, with multisampling, all fragments on screen (lines, points, > polygons) will also be automatically antialiased. > This means no rigid edges for everything, not just for fonts :) > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

May 23, 2010

[Pharo-project] Rendering fonts on OpenGL

by Igor Stasenko

Hello, This is a Tahoma font, rendered with OpenGL look how much difference between no-AA and with enabled multisampling. I think that with multisampling, the quality is quite good to not bother about sub-pixel AA. Sub-pixel AA could be added later, if there's any brave soul who can implement a fragment shader for it :) Moreover, with multisampling, all fragments on screen (lines, points, polygons) will also be automatically antialiased. This means no rigid edges for everything, not just for fonts :) -- Best regards, Igor Stasenko AKA sig.

May 23, 2010

[Pharo-project] About the Pharo Issue tracker

by Guillermo Polito

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

May 23, 2010

Re: [Pharo-project] Cross-fork Metacello configurations

by Nicolas Cellier

2010/5/23 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: > El dom, 23-05-2010 a las 09:39 +0200, Nicolas Cellier escribiÃ³: >> Miguel, >> It sounds like a defensive attitude. What good can emerge from sharing >> such mood? >> You don't deliver any technical argumentation, but "I think it's >> wrong" and "it upsets me". >> I'm sure you have more rational reasons to dislike squeak usage, that >> would be interesting to expose. > > I don't dislike Squeak usage but changing a emerging technology that is > being used in a given way and that appears to be working (I've done the > Magma configuration and I tested it worked on Squeak and Pharo) but this > new Squeak usage of Metacello really discourages to try to keep the > Magma for other distros than Pharo. It really is a gratuitous change and > I don't really have the time to sync two ways to use the same > technology. > I would say then someone else should do it for Squeak, but that's a good question. How to reuse Pharo configuration in Squeak with minimum effort et vice et versa? > >> Squeak people are not going to rape your wife nor kill your children. > > Again, is not the people, is the gratuitous change for a perceived > problem with Metacello current usage. > >> Qu'un sang impur abreuve nos sillons > > No sÃ© que significa pero supongo que es relevante en esta discusiÃ³n. > > Cheers Absolutely irrelevant! It's extracted from french hymn "la marseillaise", as you may know, a rather beliquous song. That was my a-bit-exagerated-perception of your previous mail ;) Nicolas >> >> Nicolas >> >> 2010/5/22 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: >> > But, but... >> > >> > One thing that I really don't understand is this: >> > >> > Squeak people hasn't used the current Metacello "use-case". >> > Squeak people without use it and see if really has problems (nothing >> > that can't be solved when it appears) >> > Squeak people proposed a new way to use Metacello, completly different >> > than the one is being used >> > Squeak arguments were about some potential problems with having >> > configurations outside the image >> > Squeak arguments were abouth the potential advantages of having a >> > browser that browses locally (but as Mariano said, it must be updated >> > from net before having the very last package tested to work available in >> > the browser) instead of going to the network for the list. >> > >> > So, this, hey look what I found, they use it this way, but I think that >> > we should use it that other way, no matter if it is really a problem Â to >> > use it the way the other people use it really upsets me. >> > >> > Heck, Pharo even build the released dev images with Metacello. That is a >> > "real" world usage and not words. >> > >> > >> > El vie, 21-05-2010 a las 16:17 -0700, Dale Henrichs escribiÃ³: >> >> I had suggested that they not use the ConfigurationOf prefix for the Squeak configuration package so that cross platform configurations could continue to be used ... I would hope that folks continue to to create cross platform packages ... the onus on copying shouldn't be on the developer, but the folks that want a managed list of configs:) >> >> >> >> I would think that the managed list could be harvested from the ConfigurationOf configs without any direct developer involvement...afterall computers should be used for the things they are good at:) >> >> >> >> It will be interesting to see how the managed list idea evolves... >> >> >> >> Dale >> >> ________________________________________ >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez [miguel.coba(a)gmail.com] >> >> Sent: Friday, May 21, 2010 10:42 AM >> >> To: Pharo-project(a)lists.gforge.inria.fr >> >> Subject: Re: [Pharo-project] Cross-fork Metacello configurations >> >> >> >> El vie, 21-05-2010 a las 09:13 -0700, Sean P. DeNigris escribiÃ³: >> >> > I created a Squeak/Pharo SSpec, which puts the fork-specific world menu code >> >> > into a Platform package. >> >> > >> >> > As I work on the config, I came up against Pharo using Object as a subclass, >> >> > but the Squeak Inbox requiring (because of the browser tool) >> >> > MetacelloConfiguration. >> >> > >> >> > What would be the best/easiest way to deal with this? >> >> > >> >> > If the configs have to be forked, then Metacello really loses value (i.e. >> >> > #squeak and #pharo). Â And, I do a lot of work in both forks, so it would be >> >> > a shame to pick one to upload to and not share work that has already been >> >> > done with half the users. >> >> >> >> That was one of the problems of the Configuration Package proposed by >> >> Andreas. Promotes copy&paste of configurations (bad bad) and in the long >> >> term forks and completely rework to create configurations for Squeak and >> >> a different (although similar) for Pharo. >> >> As you say, it doesn't matter that Metacello is capable of installing >> >> cross-platform packages. With independently created configurations for >> >> the same packages, is has been stole of its usefulness and is >> >> discouraging Pharo users that have developed ConfigurationOfXXX that >> >> worked both in Squeak and Pharo in the past. >> >> >> >> >> >> >> >> > >> >> > Thanks. >> >> > Sean >> >> > >> >> >> >> -- >> >> Miguel CobÃ¡ >> >> http://miguel.leugim.com.mx >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >> > -- >> > Miguel CobÃ¡ >> > http://miguel.leugim.com.mx >> > >> > >> > _______________________________________________ >> > 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 > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 23, 2010