- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Unicode test II

by Michael Rueger

Yoshiki Ohshima wrote: > On Windows Vista in Japanese, the system seems to get the unicode > values from keyboard but doesn't display them correctly. For short Any idea why? I'm pretty sure I'm going through the correct process for the leading char. Is there any glyph translation needed for the rendering or the font import? Michael

March 3, 2009

Re: [Pharo-project] Unicode test II

by Yoshiki Ohshima

At Mon, 02 Mar 2009 23:11:00 -0800, Michael Rueger wrote: > > Hi all, > > after some interesting adventures in Unicode land here's a second > version of the unicode test image/app: > > http://impara.de/~michael/unicode-test.zip > > Things that I think should work: > - unicode text input on all platforms including support of composing > character sequences (.eg. US international keyboards) > - unicode clipboard handling > - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking > about it, only tested on Windows so far) > > Mostly untested: > - unicode filename handling > > Known not to work: > - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards. > That would take another major refactoring of handling shortcuts. > > Once I know this version works reasonable well I'll package everything > up for inclusion in the updates. Right now it is pretty much a mess. On Windows Vista in Japanese, the system seems to get the unicode values from keyboard but doesn't display them correctly. For short cut keys, when MS IME is enabled and in the Roma-ji input mode, it does work. -- Yoshiki

March 3, 2009

Re: [Pharo-project] Fwd: about adding chasing pointers and friends in the debug menu

by Alexandre Bergel

I agree. Oddly enough, the (w) shortcut was bound to tallyIt. Anyway, I changed the labels. a New version of Kernel is in Inbox. Alexandre On 3 Mar 2009, at 20:45, Adrian Lienhard wrote: > I don't think these two items need a keyboard shortcut. It's not > something you do all the time and would learn a shortcut for, I think. > > Adrian > > On Mar 3, 2009, at 19:11 , Alexandre Bergel wrote: > >>> BTW, the keyboard shortcut (w) indicated with "tally it" and also >>> with >>> "watch it" does not work; it closes the window! >> >> I was not aware of this. What would be a good keybinding? Maybe I can >> suppress the keybidding for tallyIt. >> >> Cheers, >> Alexandre >> >> >>> >>> >>> On Mar 3, 2009, at 12:30 , StÃ©phane Ducasse wrote: >>> >>>>> >>>>> >>>>> From: stÃ©phane ducasse <ducasse(a)iam.unibe.ch> >>>>> Date: March 2, 2009 11:00:09 PM CEST >>>>> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >>>>> Subject: about adding chasing pointers and friends in the debug >>>>> menu >>>>> >>>>> >>>>> Hi >>>>> >>>>> we can only access pointer finder and chase pointer from the >>>>> inspector menu and it would be nice to >>>>> have that much more accessible. >>>>> What do you think? >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by Marcus Denker

On 03.03.2009, at 20:47, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> Keith we understand your point. This is why I proposed to clean >> Installer and run SmallLint on it. >> and clean it again (no subclass references in superclass and other). >> >> Now did you said the same to Croquet, Sophie, Etoy people? >> why only to us? Then we have the right not to be happy with your >> infrastructural choices. >> > The croquet people namely (andreas) are on my case, and he clearly > gets > this concept since he based his "running for the board" email on it. > > The cobalt people = matthew and others, they "get it", and are using > some of the tools, and proposing common libraries. > > Bertf has expressed an interest in etoys moving up to 3.10+ if the > transition can be eased. So interestingly, all these peope never had *any* interest in cooperating on anything. Etoys ignored 3.9 *completely*. (and all my activity to merge etoys back before that was always done not with that much enthusiasm from their side. I got some bit of help from Bert and Michael, but the activity always came from my side). Andreas disapeared for years (just to pee on us for a good laugh on and off). So I really wonder why they all changed their mind suddenly. Seriously. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

March 3, 2009

Re: [Pharo-project] Fwd: about adding chasing pointers and friends in the debug menu

by Adrian Lienhard

Sorry for the multiple mails. I forgot to mention that it would be much better if "tally it" shows the actual tally output (i.e., what you get with MessageTally spyOn: [...]) instead of just measuring the time it requires to compile and run the code. Adrian On Mar 3, 2009, at 20:45 , Adrian Lienhard wrote: > I don't think these two items need a keyboard shortcut. It's not > something you do all the time and would learn a shortcut for, I think. > > Adrian > > On Mar 3, 2009, at 19:11 , Alexandre Bergel wrote: > >>> BTW, the keyboard shortcut (w) indicated with "tally it" and also >>> with >>> "watch it" does not work; it closes the window! >> >> I was not aware of this. What would be a good keybinding? Maybe I can >> suppress the keybidding for tallyIt. >> >> Cheers, >> Alexandre >> >> >>> >>> >>> On Mar 3, 2009, at 12:30 , StÃ©phane Ducasse wrote: >>> >>>>> >>>>> >>>>> From: stÃ©phane ducasse <ducasse(a)iam.unibe.ch> >>>>> Date: March 2, 2009 11:00:09 PM CEST >>>>> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >>>>> Subject: about adding chasing pointers and friends in the debug >>>>> menu >>>>> >>>>> >>>>> Hi >>>>> >>>>> we can only access pointer finder and chase pointer from the >>>>> inspector menu and it would be nice to >>>>> have that much more accessible. >>>>> What do you think? >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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

March 3, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by Keith Hodges

StÃ©phane Ducasse wrote: > Keith we understand your point. This is why I proposed to clean > Installer and run SmallLint on it. > and clean it again (no subclass references in superclass and other). > > Now did you said the same to Croquet, Sophie, Etoy people? > why only to us? Then we have the right not to be happy with your > infrastructural choices. > The croquet people namely (andreas) are on my case, and he clearly gets this concept since he based his "running for the board" email on it. The cobalt people = matthew and others, they "get it", and are using some of the tools, and proposing common libraries. Bertf has expressed an interest in etoys moving up to 3.10+ if the transition can be eased. The gjallar people use an Installer build script and are likely to be among the third project to be using bob So that leaves Sophie which I have no clue about. cheers Keith

March 3, 2009

Re: [Pharo-project] Fwd: about adding chasing pointers and friends in the debug menu

by Adrian Lienhard

I don't think these two items need a keyboard shortcut. It's not something you do all the time and would learn a shortcut for, I think. Adrian On Mar 3, 2009, at 19:11 , Alexandre Bergel wrote: >> BTW, the keyboard shortcut (w) indicated with "tally it" and also >> with >> "watch it" does not work; it closes the window! > > I was not aware of this. What would be a good keybinding? Maybe I can > suppress the keybidding for tallyIt. > > Cheers, > Alexandre > > >> >> >> On Mar 3, 2009, at 12:30 , StÃ©phane Ducasse wrote: >> >>>> >>>> >>>> From: stÃ©phane ducasse <ducasse(a)iam.unibe.ch> >>>> Date: March 2, 2009 11:00:09 PM CEST >>>> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >>>> Subject: about adding chasing pointers and friends in the debug >>>> menu >>>> >>>> >>>> Hi >>>> >>>> we can only access pointer finder and chase pointer from the >>>> inspector menu and it would be nice to >>>> have that much more accessible. >>>> What do you think? >>>> >>>> Stef >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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

March 3, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by StÃ©phane Ducasse

Keith we understand your point. This is why I proposed to clean Installer and run SmallLint on it. and clean it again (no subclass references in superclass and other). Now did you said the same to Croquet, Sophie, Etoy people? why only to us? Then we have the right not to be happy with your infrastructural choices. Consider Pharo as insignificant and that squeak is the future. This way you do not have to blame us and we are happy. Stef On Mar 3, 2009, at 2:06 AM, Keith Hodges wrote: > Michael Roberts wrote: >> Keith, your email implies that you believe Pharo should be backwards >> compatible at some level with Squeak. Part of the Pharo manifesto is >> not to be compatible. So if you want to write code or have apis that >> work in a backwards direction from Pharo to Squeak, that's great. I >> don't believe it's a goal for Pharo though. The pharo process >> doesn't >> need a rethink at all as far as I'm concerned. >> >> thanks, >> >> Mike >> > No that is not what I am saying at all. Perhaps examples would help. > > Take Rio. Rio was designed from ground up to be a replacement for a > the > present non-modular kernel facility FileDirectory. It is a discrete > loadable module. > > Wild and horrible uses of FileDirectory are spread around the image in > lots of places, so one thing that Rio tries to do is to anticipate use > cases, so that the users of Rio dont have to implement File handling > code in their stuff, and so we help to keep the module boundary clear. > For example you can ask Rio to get you the next version of a file - > 'myfile.2.txt' asFile nextVersion = 'myFile.3.txt. That facility in > itself potentially lightens SmalltalkImage. If you want to read Xml > files, you can subclass File, with FileXML, define the > #validExtensions > that it handles, and implement contents/contents: This means that your > code only needs to send, 'myfile.xml' asFile contents, to get the > model. > There are all sorts of things like that. > > With Rio as a front end to File and Socket streams it is perfectly > possible to innovate on them without users of Rio being any the wiser. > If I do 'myFile.3.txt' asFile contents, it wouldn't care whether it > was > Squeak streams Nile or Flow behind the scenes. 'http://www.google.com' > asFile contents, now means that I dont have to care about whether > HttpSocket is doing the work with a RWBinaryOrTextStream in 3.7 or > HTTPClient returning a MultiByteStream thingy in 3.8 or some other new > facility. > > So, Rio demonstrates that it is possible to innovate, on a kernel > module, and you dont need to break anything to do it. Secondly by > thinking about APIs and module interface abstractions in this way, you > can define specific interfaces and bottlenecks, that potentially turn > the ball of tangled string into something designed and architected. > There are perhaps hundreds of other modules that could use the same > treatment. > > Rio loads into all squeak images I have tried it in, so this then > means > that any of my file handling code will work in all images. This > benefit > comes from managing Rio as module external to the main image. Rio also > comes in two sizes, a Rio-Kernel, and a Rio-Base, with smaller > images in > mind. > > Having done this, the question of moving the kernel over to make use > of > the new code arises, this also can be achieved without breaking > anything > for users that have had Rio available for 2 years in every image that > their code was running in. I.e. Sophie, Croquet, Seaside, Gjallar, > Magma, Etoys, can all migrate their file handling code to the new Rio > API now, even if they are using Squeak 3.7/3.8, without having to > upgrade to the latest squeak. When they do update, they will be > pleased > to find that their file handling code works, as well as their > gzipping/archiving/remote file handling/and website accessing code. > > Installer follows the same principles, abstracting an api, freeing the > backend to be either old code or new code. If you dont have Universes > loaded, then defining Installer>>#universes to call #sake as a fall > back > would use Sake/Packages and get identical results, your users would be > none the wiser. If you dont have SqueakMap loaded, then defining > Installer>>#squeakmap to call #websqueakmap instead, would again give > your users identical results. and you thought that Installer was just > for loading things. Edgar has pointed out that you could use > CodeLoader > for that, but thats not the point of installer, Installer is > providing a > DSL for loading things that provides an architectural layer of > isolation, and thus both inherrent forward and backward > compatibility. I > expect my image building scripts to work identically with > Monticello2 in > squeak 3.16 as they do now with Monticello 1.5 in Squeak 3.7. > > Scripter (who here even knows that Scripter exists?) does the same, if > you want to write code to close or tile all the windows, after the > installing process has left a mess. Scripter can be the interface to > whatever backend GUI there happens to be whether it is > ToolBuilder/Tweak/Morphic. > > Same again with Logging, is a front end abstraction to all of the > three+ > logging backends out there. I can remove the hardwired calls to > Transcript that scatter the image and replace them with a single api > to > multiple backends, both past (Transcript) present (Syslog) and future > (seaside per-user session logging framework). > > Oh, and again with Sake/Packages.... why does Sake/Packages define > class > tasks? You can write a task that depends upon a task which removes > certain method selectors. You could just call Behaviour direct. Its > another architectural layer, that frees up the back end to be old or > new code as far as Sake task writers are concerned. I can write a task > that says, "if you find this Class with a method categorised as so, > then > it needs to be recategorised as such", in such a way as this task > would > run in all images. > > Oh and again SystemEditor... another layer of abstraction for > compiling > and loading code atomically. > > So if you think about it, those who know about the compiler could be > considering how to write their stuff, so that it logs to the Kernel > Logging API (which is valid even if Logging isnt Loaded). They might > consider connecting to SystemEditor in preference to providing a > direct > api, and another abstracted pluggable Module is needed to handle > source > code files (replacing RemoteString/ChangeSets etc), with Rio as the > local/remote file API. > > Do you get the idea now? > > For the same treatment to be available for more significant chunks of > squeak, we would need atomic loading to work. Now the code to provide > atomic loading for everyone has been available for over a year, and it > works if you dont use traits. So where is the expertise to really > get it > working for everyone with traits? > > The only difficulty with this approach is that you might need slightly > different bits to make your NEW code load into older images. This > problem is reasonably easily addressed with Installer-Scripts > (LevelPlayingField+) and Sake/Packages. > > I fully agree with Matthew about core packages like Collections. BUT > and > this is the big but. If you are going to do that kind of thing, you > need > to think about it, plan it, and create and participate in a process > that > supports everyone is diverse images using and testing that package. > From > what I have seen there is only one person on the Pharo team that > understands what LevelPlayingField is for, and how to use it. > > The biggest risk to this approach is if some other folks decide to > fork > some significant architectural component in a completely incompatible > manner, without thinking about any bigger picture at all. > > Matthew's comment about how our tools are only just getting there isnt > that relevant to the point that I am making. I didnt need a test and > build server to innovate Rio for everyone rather than just for the > image > I am using (trouble was I was using 3 different images), all I needed > was an inclusive attitude rather than an exclusive attitude. > > cheers > > Keith > > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 3, 2009

Re: [Pharo-project] Universes question

by Alexandre Bergel

>> disable OB-debugger for now. > > the latest version is quite good. I would prefer you try it before I > remove it. What do you think? Few people around me were reluctant to use pharo-dev because of the debugger. I am for a new debugger, but maybe it was a bit premature. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2009

Re: [Pharo-project] Fwd: about adding chasing pointers and friends in the debug menu

by Alexandre Bergel

> BTW, the keyboard shortcut (w) indicated with "tally it" and also with > "watch it" does not work; it closes the window! I was not aware of this. What would be a good keybinding? Maybe I can suppress the keybidding for tallyIt. Cheers, Alexandre > > > On Mar 3, 2009, at 12:30 , StÃ©phane Ducasse wrote: > >>> >>> >>> From: stÃ©phane ducasse <ducasse(a)iam.unibe.ch> >>> Date: March 2, 2009 11:00:09 PM CEST >>> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >>> Subject: about adding chasing pointers and friends in the debug menu >>> >>> >>> Hi >>> >>> we can only access pointer finder and chase pointer from the >>> inspector menu and it would be nice to >>> have that much more accessible. >>> What do you think? >>> >>> Stef >>> >>> >>> >> >> _______________________________________________ >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2009