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

[Pharo-project] MessageTally a bit broken due to closure

by StÃ©phane Ducasse

was working before closure MessageTally tallySends: [3.14159 printString]

April 10, 2009

[Pharo-project] Help fixing tests

by StÃ©phane Ducasse

When running the kernelTest-Classes testClassDescriptionallSubInstances is yellow but when run individually green. Anybody want to look at it? Stef

April 10, 2009

Re: [Pharo-project] question on traits

by Alexandre Bergel

Although this would be such a big problem, thanks for pointing this out. Cheers, Alexandre On 10 Apr 2009, at 17:35, Igor Stasenko wrote: > 2009/4/10 Adrian Lienhard <adi(a)netstyle.ch>: >> Great. I think the simplest thing to do is to check whether the two >> methods have the same origin (CompiledMethod>>#origin). If they have, >> they must be the same. So you don't need to compare their bytecode. >> > yeah, comparing bytecode is not solution, because > ^ 'foo' > and > ^ 'bar' > > having same bytecode, but different literals. > >> Adrian >> >> On Apr 10, 2009, at 14:48 , Alexandre Bergel wrote: >> >>> Copying methods is probably the right way to do regarding literals >>> and >>> properties. A comparison of the bytecodes may solve this issue >>> although. >>> I added an issue, #725. I will fix it soon. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 10 Apr 2009, at 14:32, Adrian Lienhard wrote: >>> >>>> Yes, this should not be a conflict. I think I had implemented it >>>> that >>>> way. Probably it was broken in the recent refactoring that I did >>>> for >>>> method sharing... >>>> >>>> Adrian >>>> >>>> On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote: >>>> >>>>> Hi All, >>>>> >>>>> Apparently, the way a conflict may be triggered is slightly >>>>> different >>>>> from what is described in the toplas paper. >>>>> in the paper, it is said that a compiled method that is inherited >>>>> from >>>>> more than one path does not trigger a conflict. With the current >>>>> implementation this trigger a conflict. >>>>> >>>>> For example: >>>>> T1 defines foo >>>>> T2 uses T1 >>>>> T3 uses T1 >>>>> T23 uses T2 + T3 >>>>> C uses T23 >>>>> >>>>> C new foo => conflict error. >>>>> >>>>> One would expect no conflict since there is only one definition of >>>>> foo >>>>> Just wondering... >>>>> >>>>> Alexandre >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 10, 2009

Re: [Pharo-project] question on traits

by Igor Stasenko

2009/4/10 Adrian Lienhard <adi(a)netstyle.ch>: > Great. I think the simplest thing to do is to check whether the two > methods have the same origin (CompiledMethod>>#origin). If they have, > they must be the same. So you don't need to compare their bytecode. > yeah, comparing bytecode is not solution, because ^ 'foo' and ^ 'bar' having same bytecode, but different literals. > Adrian > > On Apr 10, 2009, at 14:48 , Alexandre Bergel wrote: > >> Copying methods is probably the right way to do regarding literals and >> properties. A comparison of the bytecodes may solve this issue >> although. >> I added an issue, #725. I will fix it soon. >> >> Cheers, >> Alexandre >> >> >> On 10 Apr 2009, at 14:32, Adrian Lienhard wrote: >> >>> Yes, this should not be a conflict. I think I had implemented it that >>> way. Probably it was broken in the recent refactoring that I did for >>> method sharing... >>> >>> Adrian >>> >>> On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote: >>> >>>> Hi All, >>>> >>>> Apparently, the way a conflict may be triggered is slightly >>>> different >>>> from what is described in the toplas paper. >>>> in the paper, it is said that a compiled method that is inherited >>>> from >>>> more than one path does not trigger a conflict. With the current >>>> implementation this trigger a conflict. >>>> >>>> For example: >>>> T1 defines foo >>>> T2 uses T1 >>>> T3 uses T1 >>>> T23 uses T2 + T3 >>>> C uses T23 >>>> >>>> C new foo => conflict error. >>>> >>>> One would expect no conflict since there is only one definition of >>>> foo >>>> Just wondering... >>>> >>>> Alexandre >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel Â http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

April 10, 2009

Re: [Pharo-project] Multiple issues with class definition

by Igor Stasenko

2009/4/10 Marcus Denker <denker(a)acm.org>: > > On 10.04.2009, at 05:34, Igor Stasenko wrote: > >> Another funny thing that i found, that you can actually do: >> >> | string | >> string := 'Blabla'. >> Object subclass: string >> Â Â Â instanceVariableNames: '' >> Â Â Â classVariableNames: '' >> Â Â Â poolDictionaries: '' >> Â Â Â category: 'Whatever'. >> >> Smalltalk at: string " returns a class you just defined." >> > > Yes, reflectively generating classes is what the browser does. And in > addition, > it is useful for tests. Or in general meta-programming tricks of the > evil kind. > (e.g. eToys used it to create on-the-fly classes for it's prototype- > like object > model. In most of these cases, it is better to use anonymous > Behaviors, than you don't > see them in the browser at all). > Right, but for common case, this should be errorneous? No? At least Smalltalk>>#at:put: should check that key is symbol. >> Its fun, but having no sense. What is interesting that OB can display >> this class (but not in a regular way, you can find it in smart groups >> pane, after searching for 'Blabla'). > > > I think this is because the new class is not packaged. The old browser > shows > it in the class category 'Whatever', indistinguishable from a class > created with > the browser. I'm not sure what the difference from class created by browser.. A browser IMO should use very same message(s), sent to a class which should be a superclass for newly created new class(es). Doing otherwise would lead to multiple entry points into classes internals, which leads to exponential growth of complexity. > > Â Â Â Â Marcus > > -- > Marcus Denker Â -- Â denker(a)acm.org > http://www.marcusdenker.de > > > _______________________________________________ > 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.

April 10, 2009

Re: [Pharo-project] Fonts working great

by Damien Pollet

> Yep. How would we package the fonts for Unix and Windows VMs? For windows I'm not the one to ask :) For linux, dejavu is very often (on all main distros anyway) already available and used globally, so the only thing needed would be to make sure that the packagers add a dependancy in the squeak package to the dejavu and freetype packages. Otherwise, the linux-specific part of the one-click distribution can certainly deal with fonts located inside the one-click.app -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

April 10, 2009

Re: [Pharo-project] question on traits

by Adrian Lienhard

Great. I think the simplest thing to do is to check whether the two methods have the same origin (CompiledMethod>>#origin). If they have, they must be the same. So you don't need to compare their bytecode. Adrian On Apr 10, 2009, at 14:48 , Alexandre Bergel wrote: > Copying methods is probably the right way to do regarding literals and > properties. A comparison of the bytecodes may solve this issue > although. > I added an issue, #725. I will fix it soon. > > Cheers, > Alexandre > > > On 10 Apr 2009, at 14:32, Adrian Lienhard wrote: > >> Yes, this should not be a conflict. I think I had implemented it that >> way. Probably it was broken in the recent refactoring that I did for >> method sharing... >> >> Adrian >> >> On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote: >> >>> Hi All, >>> >>> Apparently, the way a conflict may be triggered is slightly >>> different >>> from what is described in the toplas paper. >>> in the paper, it is said that a compiled method that is inherited >>> from >>> more than one path does not trigger a conflict. With the current >>> implementation this trigger a conflict. >>> >>> For example: >>> T1 defines foo >>> T2 uses T1 >>> T3 uses T1 >>> T23 uses T2 + T3 >>> C uses T23 >>> >>> C new foo => conflict error. >>> >>> One would expect no conflict since there is only one definition of >>> foo >>> Just wondering... >>> >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 10, 2009

Re: [Pharo-project] about the closure

by Damien Pollet

2009/4/1 Lukas Renggli <renggli(a)gmail.com>: > #testToDoOutsideTemp and #testWhileModificationBefore are broken. I was going to say they happen to test the same behavior as the python blog post I sent yesterday, but I missed a pair of brackets :) The python thing is equivalent to #testDoArgument, which passes. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

April 10, 2009

Re: [Pharo-project] question on traits

by Alexandre Bergel

Copying methods is probably the right way to do regarding literals and properties. A comparison of the bytecodes may solve this issue although. I added an issue, #725. I will fix it soon. Cheers, Alexandre On 10 Apr 2009, at 14:32, Adrian Lienhard wrote: > Yes, this should not be a conflict. I think I had implemented it that > way. Probably it was broken in the recent refactoring that I did for > method sharing... > > Adrian > > On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote: > >> Hi All, >> >> Apparently, the way a conflict may be triggered is slightly different >> from what is described in the toplas paper. >> in the paper, it is said that a compiled method that is inherited >> from >> more than one path does not trigger a conflict. With the current >> implementation this trigger a conflict. >> >> For example: >> T1 defines foo >> T2 uses T1 >> T3 uses T1 >> T23 uses T2 + T3 >> C uses T23 >> >> C new foo => conflict error. >> >> One would expect no conflict since there is only one definition of >> foo >> Just wondering... >> >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 10, 2009

Re: [Pharo-project] Fonts working great

by Adrian Lienhard

On Apr 10, 2009, at 14:17 , Damien Pollet wrote: >> Why is this requiring a new VM? Or did you mean an updated .app >> structure? > > Yes, I should have said VM application. Point is, the .app bundle is > designed for this purpose, and images with preconfigured fonts will > break or look ugly if the fonts are not there. > > > The alternative possibilities are not very interesting: Yep. How would we package the fonts for Unix and Windows VMs? Adrian > > - use system fonts -> wrong, the fonts are only there by default on > (most) linuxes, so in practice, images will break until the user > manually installs the fonts > - distribute fonts in the image -> huge image > - distribute fonts besides the image -> it's already tedious to keep > .image and .changes > - distribute fonts besides the VM like the .sources -> I'm not sure if > that plays well with OS conventions for font installation > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 10, 2009