- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Tests are back to dark red :(

by StÃ©phane Ducasse

yes me too :) Stef On Feb 10, 2009, at 9:24 AM, Marcus Denker wrote: > On Tue, Feb 10, 2009 at 9:17 AM, Damien Cassou <damien.cassou(a)gmail.com > > wrote: >> On Mon, Feb 9, 2009 at 9:03 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >>> An interesting test failure is [Wide]StringTest>>#testAsInteger >>> '-94' asInteger --> 94. I could trace this back to a change in >>> PositionableStream>>#back by Damien Cassous. Damien, could you >>> have a >>> look? >> >> Fixed, see: >> http://code.google.com/p/pharo/issues/detail?id=518 >> > what is bad with the google bug-tracker is that "verified" issues > are not shown > anymore. One needs to explicitly search for them, wich in turn means > they > are overlooked very quickly (I always forget to search for them). > > Marcus > > > -- > > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 10, 2009

Re: [Pharo-project] Tests are back to dark red :(

by Marcus Denker

On Tue, Feb 10, 2009 at 9:17 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Mon, Feb 9, 2009 at 9:03 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> An interesting test failure is [Wide]StringTest>>#testAsInteger >> '-94' asInteger --> 94. I could trace this back to a change in >> PositionableStream>>#back by Damien Cassous. Damien, could you have a >> look? > > Fixed, see: > http://code.google.com/p/pharo/issues/detail?id=518 > what is bad with the google bug-tracker is that "verified" issues are not shown anymore. One needs to explicitly search for them, wich in turn means they are overlooked very quickly (I always forget to search for them). Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 10, 2009

Re: [Pharo-project] Tests are back to dark red :(

by Damien Cassou

On Mon, Feb 9, 2009 at 9:03 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > An interesting test failure is [Wide]StringTest>>#testAsInteger > '-94' asInteger --> 94. I could trace this back to a change in > PositionableStream>>#back by Damien Cassous. Damien, could you have a > look? Fixed, see: http://code.google.com/p/pharo/issues/detail?id=518 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Plugin organization

by StÃ©phane Ducasse

> When I mentioned Seaside I was not thinking explicitly in terms of Top- Purpose... What I like is that you have package but you have a kind of modules = object-oriented I would like to have Collections-Kernel Collections-Kernel-Tests Collections-Arrayed Collections-Arrayed-Tests Network-Kernel Network-Kernel-Tests ... So that I can get all the packages with their tests if I want. Also when I browse the package I see the tests and the other points grouped togethe > > (Purpose-)Rest > > where > > Purpose = Tests, Examples, .. > Rest = Kernel, Collections, Network, ... > > Note that this is the *package* structure (what you see in MC), not > the class category structure. The latter could be more fine grained at > the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is > structured now). > > The consequence would be that we have packages like > > Kernel > Collections > Tools > ... > Tests-Kernel > Tests-Collections > Tests-Tools > > I'm not convinced that this is the right structure, though, as we end > up with lots of Test-xyz packages. > > As an alternative, I can imagine the package scheme > > Top-Rest > > where we have a very coarse grained Top level. For instance, we would > have the following Top items: > > Kernel > Graphics > Libraries > Tools > Tests > > This means, we would have packages like > > Kernel-Numbers > Kernel-Traits > Kernel-Compiler > ... > Libraries-Collections > Libraries-Regex > Libraries-Network > ... > Tests-Kernel > Tests-Libraries > ... > > I'm curious if there are other ideas around. One way or the other, we > need to clean this up. Right now it is a mess. E.g., there is a top > level package MethodFinder, while all other tools are in the Tools > package. INdEeD :) > > > Cheers, > Adrian > > >> >> >> stef >> >> On Jan 31, 2009, at 10:51 AM, StÃ©phane Ducasse wrote: >> >>> I like the seaside organization >>> >>> Top-(Purpose-)(Platform-)Rest >>> >>> * Seaside-Canvas contains he canvas implementation. >>> * Seaside-Squeak-Canvas contains the platform specific code of >>> the canvas implementation. >>> * Seaside-Examples-Canvas contains example code showing off the >>> canvas implementation. >>> * Seaside-Tests-Canvas contains the tests for the canvas >>> implementation. >>> * Seaside-Tests-Squeak-Canvas contains the platform specific >>> tests of the canvas implementation. >>> >>> On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote: >>> >>>> >>>> On Jan 30, 2009, at 15:33 , Michael Rueger wrote: >>>> >>>>> StÃ©phane Ducasse wrote: >>>>> >>>>>> so what are the organizations we can use? >>>>>> Ideally I would like to have the test associated with their >>>>>> packages. >>>>>> >>>>>> XXX >>>>>> XXXTests >>>>> >>>>> The problem with that naming scheme is that then the tests would >>>>> always >>>>> be loaded together with their tests because of the simple string >>>>> matching Monticello does. >>>>> Which isn't something you want when doing application/runtime >>>>> builds. >>>>> >>>>> That's why I proposed the Plugin-* and Tests-* naming schemes. >>>> >>>> +1 >>>> >>>> Adrian >>>> _______________________________________________ >>>> 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 >

Feb. 10, 2009

Re: [Pharo-project] looking for Unicode testers

by Igor Stasenko

2009/2/10 Michael Rueger <m.rueger(a)acm.org>: > On Mon, Feb 9, 2009 at 10:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> 2009/2/9 Michael Rueger <m.rueger(a)acm.org>: >>> Igor Stasenko wrote: > > >> I think that shortcuts should be bound to meta-keys (or hardware key >> scan code), so then regardless of keyboard layout, pressing alt-c >> should be understood as a 'copy' action. > > That's actually what the key even logic (at least on Windows) does. > > But, looking beyond Squeak, how are things like common shortcuts (cut, > copy, paste, print, quit etc) handled for all the different keyboard > layouts? > - in FF3 i pressing same keys on keyboard for copy/paste/find regardless of current layout. - notepad too - wordpad too i think its a good practice, saving you from extra typing compare when you typing text in non-english lang and need to copy part of it: switch-copy-paste-swith back vs just copy-paste and most of people in Ukraine using even 3 keyboard layouts: - english - russian - ukrainian so, imagine how painful it could be when you need to copy text, but shortcuts working only in english layout.. you need to press languag switch keys 1 or 2 times (depending on settings), and look at a language indicator to check that now you in english. Very distracting and very inconvenient. > I remember early Smalltalk code using the scan code only, so ctrl-" > translated to ctrl-u-Umlaut on German keyboards, not a really > intuitive thing for a user ;-) > keyboards having different layouts (i mean physical) , and placing shortcut on keys which may differ on different keyboards is not good practice. But i think, for any keyboard which allows entering latin letters, using latin alphabet keys for shortcuts is safe. P.S. it seems that VM does not transfers key scan codes to image side :( > michael > > _______________________________________________ > 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.

Feb. 10, 2009

Re: [Pharo-project] looking for Unicode testers

by Michael Rueger

On Mon, Feb 9, 2009 at 10:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/2/9 Michael Rueger <m.rueger(a)acm.org>: >> Igor Stasenko wrote: > I think that shortcuts should be bound to meta-keys (or hardware key > scan code), so then regardless of keyboard layout, pressing alt-c > should be understood as a 'copy' action. That's actually what the key even logic (at least on Windows) does. But, looking beyond Squeak, how are things like common shortcuts (cut, copy, paste, print, quit etc) handled for all the different keyboard layouts? I remember early Smalltalk code using the scan code only, so ctrl-" translated to ctrl-u-Umlaut on German keyboards, not a really intuitive thing for a user ;-) michael

Feb. 10, 2009

Re: [Pharo-project] looking for Unicode testers

by Igor Stasenko

2009/2/9 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: > >> what is not very convenient is that copy/paste (as well as the rest of >> keyboard shortcuts ) is not working when keyboard layout not english. > > You mean you are typing the equivalent of alt-c etc on the Russian > keyboard/layout? Or how do the ASCII short cuts map? > Didn't someone create a mapping that would work? > I think that shortcuts should be bound to meta-keys (or hardware key scan code), so then regardless of keyboard layout, pressing alt-c should be understood as a 'copy' action. I'm not sure if VM passing enough information in keyboard event to image side to use keyboard scan codes, instead of converted to ASCII/Unicode character values. Of course one could always create a mapping for own keyboard layout.. But this leads to situation that it will require to provide mappings for all existing languages in the world :) > Michael > > _______________________________________________ > 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.

Feb. 9, 2009

Re: [Pharo-project] Tests are back to dark red :(

by StÃ©phane Ducasse

I could help a bit to get all the test green But I'm buzzy. Stef On Feb 9, 2009, at 9:03 PM, Adrian Lienhard wrote: > Thanks for looking into this. > > There were two problems. First the TestMethodsAsObjects did not clean > up correctly as you noted. Second, TestCase>>#methodChanged: did not > expect an object as a method---neither did the PCC tests. > > I committed the following two changes to the Inbox to fix this: > > Name: Tests-al.40 > Clean up TestObjectsAsMethods (do a proper tearDown) > > Name: SUnit-al.59 > Make edge case where method is an object work. > > ---- > > Now we are back to 13 failures and 4 errors. That's already much > better. > > An interesting test failure is [Wide]StringTest>>#testAsInteger > '-94' asInteger --> 94. I could trace this back to a change in > PositionableStream>>#back by Damien Cassous. Damien, could you have a > look? > > Cheers, > Adrian > > BTW: I'm just the author of #methodChanged: because I had fixed > another problem in this method ;) > > > > On Feb 9, 2009, at 19:33 , Lukas Renggli wrote: > >>> Many of the errors and failures are from PCCByLiteralsTest. Was this >>> introduced recently? Are these tests supposed to run green? >> >> I already thought that this was because of my ByteArray patch ;-) >> >> However, if you individually run the PCC tests in a clean image they >> all pass. It is the side-effect of another test, presumably >> TestObjectsAsMethods that fails and does not clean-up after itself. >> >> Now why does TestObjectsAsMethods fail? It looks like this is related >> to a change in TestCase>>#methodChanged: that hooks into the change >> notification system. Looks like you did that change yourself ;-) >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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 >

Feb. 9, 2009

Re: [Pharo-project] Tests are back to dark red :(

by Adrian Lienhard

Thanks for looking into this. There were two problems. First the TestMethodsAsObjects did not clean up correctly as you noted. Second, TestCase>>#methodChanged: did not expect an object as a method---neither did the PCC tests. I committed the following two changes to the Inbox to fix this: Name: Tests-al.40 Clean up TestObjectsAsMethods (do a proper tearDown) Name: SUnit-al.59 Make edge case where method is an object work. ---- Now we are back to 13 failures and 4 errors. That's already much better. An interesting test failure is [Wide]StringTest>>#testAsInteger '-94' asInteger --> 94. I could trace this back to a change in PositionableStream>>#back by Damien Cassous. Damien, could you have a look? Cheers, Adrian BTW: I'm just the author of #methodChanged: because I had fixed another problem in this method ;) On Feb 9, 2009, at 19:33 , Lukas Renggli wrote: >> Many of the errors and failures are from PCCByLiteralsTest. Was this >> introduced recently? Are these tests supposed to run green? > > I already thought that this was because of my ByteArray patch ;-) > > However, if you individually run the PCC tests in a clean image they > all pass. It is the side-effect of another test, presumably > TestObjectsAsMethods that fails and does not clean-up after itself. > > Now why does TestObjectsAsMethods fail? It looks like this is related > to a change in TestCase>>#methodChanged: that hooks into the change > notification system. Looks like you did that change yourself ;-) > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 9, 2009

Re: [Pharo-project] a question about method browsers in pharo

by Oscar Nierstrasz

I just checked -- you are right, I got it backwards. A change set would be great. Is there a real reason to keep the OBMethodListBrowser? What is it good for? Cheers, - on On Feb 9, 2009, at 16:12, David RÃ¶thlisberger wrote: > Hi Oscar, > >> If I enable halos and explore the morphs, I see that the first one >> has >> as its model an OBImplementorsBrowser, and the second an >> OBMethodListBrowser. Why not simply use the latter? I searched for >> references to both, but did not immediately see how to change the >> behaviour on <cmd>-m. > > I think it is the other way around: In the workspace you get the > OBMethodListBrowser > and in the class browser the OBImplementorsBrowser? > > The reason for this is that the workspace passes the request to the > SystemNavigation > class. After this class has gathered the set of messages to display, > it passes this > set to a method opening the so called message set browser which can > only reason about > a set of methods, not about whether these are senders or > implementors. That's why we > get a generic message list browser there but a dedicated > implementors browser in OB. > > So we need to change SystemNavigation to achieve the same result in > both scenarios. I > can propose a change set. > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 9, 2009