- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Help fixing tests

by Damien Cassou

issue #727 On Fri, Apr 10, 2009 at 7:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > When running the kernelTest-Classes > testClassDescriptionallSubInstances is yellow but when run > individually green. > > Anybody want to look at it? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st

April 10, 2009

[Pharo-project] i can has TestCase>>#assert:equals: ?

by Oscar Nierstrasz

Hi folks, 90% of my tests just test equality of a result to an expected value, so I waste time trying to find out what the mismatch is. Would be nice to have this method in SUnit: assert: result equals: expected result = expected ifFalse: [self signalFailure: 'Assertion failed: (' , result asString , ') ~= (' , expected asString , ')'] Does anyone see a downside, or possible improvements? - on

April 10, 2009

Re: [Pharo-project] SUnit GUI

by Lukas Renggli

> is it normal that when one doubleclick on an yellow item in the list > it does not open a debugger? No, that's not normal. Right now I can think of two possible causes: - The test is not deterministic or has side effects that cause it to sometimes fail and sometimes pass. - Another reason that I recently noticed is related to exceptions and how SUnit runs the tests. When a test is run (when you click on run) the code is wrapped into an [ ... ] on: Error do: ..., thus catching all exceptions. When a test is debugged (when you click on an item on the list) the code is not wrapped in such a handler assuming that this would cause the system to open a debugger. However, depending on the exception raised this causes a custom default action to be evaluated and the test does not fail anymore. Many file-related exceptions have such a default behavior. Oscar recently reported an issue on this: <http://code.google.com/p/pharo/issues/detail?id=698>. I wonder why this only appeared now? Was there anything changed related to SUnit or Exceptions? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

April 10, 2009

[Pharo-project] SUnit GUI

by StÃ©phane Ducasse

lukas is it normal that when one doubleclick on an yellow item in the list it does not open a debugger? Stef

April 10, 2009

[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