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

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

Re: [Pharo-project] Swazoo 2.2beta3 with class variable patch

by Janko MivÅ¡ek

Hi Hilaire, Hilaire Fernandes pravi: > I am not sure to understand. Are you talking about something specific > to use Swazoo on Pharo? Yes, there is a loading problem we discussed in this list a while ago and it was caused by having one class variable mistakenly declared as class instance variable. And because it is named uppercase, the automatic code check before loading in Pharo failed (did I described correctly?) Best regards Janko > 2009/2/9 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: >> Hello, >> >> I just released new beta of Swazoo which has a problem with Singleton >> class variable solved. >> >> Note also that two classes are renamed: Site to SwazooSite and Resource >> to SwazooResource. I recommend to rename them manually before loading >> this new beta over. Just in case. >> >> New beta is published to http://www.swazoosource.com/Swazoo.html . >> >> This beta is the last before final 2.2. release. If it will prove >> reliable it will be released in few day. >> >> Best regards >> Janko >> >> >> -- >> Janko MivÅ¡ek >> AIDA/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Feb. 9, 2009

Re: [Pharo-project] looking for Unicode testers

by John M McIntosh

On 9-Feb-09, at 8:52 AM, Michael Rueger wrote: > John M McIntosh wrote: >> Well there are a number of questions here >> (a) by default the macintosh squeak VM is shipped setup for >> macintosh encoding of file names. >> I know other vertical app suppliers have set that to UTF8. However >> I'm wondering if Pharo is >> UTF8 aware or uses the macintosh subset thus not supporting all >> valid file names? >> http://code.google.com/p/pharo/issues/detail?id=513 > > UTF-8, at least with the unicode changes I'm currently working on. > > Where is this set? http://smalltalkconsulting.com/html/squeakinfoplist.html SqueakEncodingType > > >> (b) The macintosh VM always supplies slot six with unicode data, >> the unix vm, check with your support person? > > It's the Mac VM from Squeak.org. > > If you put a transcript show of the event buffer into the > handleKeyboard logic you can see that slot six is nil on meta keys. meta-keys not sure what you are refering to? How about an example? > >> (c) The clipboard logic in the macintosh VM is using the 1984 >> clipboard logic. >> We would need to bring in the extended clipboard support from >> Sophie to enable >> nice things like UTF-16 and ability to move pictures on the >> clipboard. >> http://code.google.com/p/pharo/issues/detail?id=514 > > Oh, I thought the new Mac VMs supported Unicode in the clipboard > logic as the other VMs now do. > How much effort would that be to add UTF-x support to the current > clipboard logic? Well that *is* the extended clipboard support. Just need the smalltalk code to make the proper primitive calls to the extended clipboard plugin. You need the ClipboardExtendedPlugin.bundle > > > Michael -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Feb. 9, 2009

Re: [Pharo-project] Swazoo 2.2beta3 with class variable patch

by Hilaire Fernandes

Hello Janko, I am not sure to understand. Are you talking about something specific to use Swazoo on Pharo? Hilaire 2009/2/9 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Hello, > > I just released new beta of Swazoo which has a problem with Singleton > class variable solved. > > Note also that two classes are renamed: Site to SwazooSite and Resource > to SwazooResource. I recommend to rename them manually before loading > this new beta over. Just in case. > > New beta is published to http://www.swazoosource.com/Swazoo.html . > > This beta is the last before final 2.2. release. If it will prove > reliable it will be released in few day. > > Best regards > Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://blog.ofset.org/hilaire

Feb. 9, 2009

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

by Lukas Renggli

> 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

Feb. 9, 2009