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

Re: [Pharo-project] Unicode test II

by Igor Stasenko

2009/3/4 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: >> 2009/3/4 Igor Stasenko <siguctua(a)gmail.com>: >>> Michael, i got an in MultiCompositionScanner. >> i mean error... :) >> >>> I can't mail out a bug report, because when doing it, i again get the >>> same error. > > bummer > Hmm, shouldn't there be a SqueakDebug.log file though? > > at least the method in question and a brief description of what you did > would help :-) i changed default font to Arial , to see russian letters while i typing.. then i typed some of them in transcript window.. then i tried to copy/paste text - it works well.. but then at some point it throws me an error subscript out of bounds: 1075 in scanMultiCharactersCombiningFrom: startIndex to: stopIndex in: sourceString rightX: rightX stopConditions: stops kern: kernDelta method near following statement: (encoding = 0 and: [(stopConditions at: charCode + 1) ~~ nil]) ifTrue: [ more precisely (stopConditions at: charCode + 1) okay, i closed debugger, closed transcript, opened a fresh new one, and tried again.. and was unable to reproduce the error. Then i decided to go to preferences and change the freetype hinting options.. once i clicked on it i got the same error. a transcript window contains following chars: ÑÑÐ²ÑÑ Ð²ÑÑ Ð²ÑÑ Ð²ÑÑ Ð¹Ñ ÑÑÐ¾ÑÐ¹Ð²ÑÑÑÐ¾Ð²Ñ Ð¾ÑÐ¾Ð¾ÑÐ¹Ð² Ð¹ÑÐ¾ÑÐ¾ÑÑÑÐ¾Ð²ÑÑÐ²Ð¹ÑÐ¾Ð²ÑÐ¹ÑÐ¾ÑÐ¹ÑÐ¾Ð²ÑÐ²Ð¹ÑÐ¾Ð²ÑÐ¹Ð² > - Show quoted text - > 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.

March 4, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Michael Rueger

Giovanni Corriga wrote: > I gave a look at Micheal fix, and have integrated it into > KomHttpServer-gc.45.mcz available in the main KomHttpServer repository ( > http://www.squeaksource.com/KomHttpServer/ ). Still need to be tested > though. Thank you! :-) Michael

March 4, 2009

Re: [Pharo-project] Unicode test II

by Michael Rueger

Igor Stasenko wrote: > 2009/3/4 Igor Stasenko <siguctua(a)gmail.com>: >> Michael, i got an in MultiCompositionScanner. > i mean error... :) > >> I can't mail out a bug report, because when doing it, i again get the >> same error. bummer Hmm, shouldn't there be a SqueakDebug.log file though? at least the method in question and a brief description of what you did would help :-) Michael

March 4, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Giovanni Corriga

StÃ©phane Ducasse ha scritto: >>> Those versions should work on both Squeak and Pharo. > > Cool > Excellent >> >> Very well then. Can you contact Giovanni to have your changes >> integrated at: >> >> http://www.squeaksource.com/KomHttpServer.html > > Giovanni we need your help so get the changes that are in the PharoInbox > repository on > squeaksource in KomHttpServer. > > Can you help us? > Hi Stef, I gave a look at Micheal fix, and have integrated it into KomHttpServer-gc.45.mcz available in the main KomHttpServer repository ( http://www.squeaksource.com/KomHttpServer/ ). Still need to be tested though. Giovanni

March 4, 2009

Re: [Pharo-project] Unicode test II

by Igor Stasenko

2009/3/4 Igor Stasenko <siguctua(a)gmail.com>: > Michael, i got an in MultiCompositionScanner. i mean error... :) > > I can't mail out a bug report, because when doing it, i again get the > same error. > > Can i send an image.zip to you, so you can take a look at it? > > 2009/3/4 Michael Rueger <m.rueger(a)acm.org>: > - Show quoted text - >> Rob Rothwell wrote: >>> Long ago when I thought I was going to be writing Operating Systems in >>> Assembly Language, I had a raw keyboard driver interpreting the key >>> codes from various keyboards. >>> >>> TERRIBLE to debug (though not as bad as debugging a display driver). >>> >>> Is that what all this is like? >>> >>> Ugh... >>> >>> Do you use lookup tables for all the various keyboard types and >>> operating systems? >>> >>> It seems like you almost need a matrix of all the supported systems vs. >>> all the possible keyboards, with a table for each one...it could just be >>> a file in the image directory and get loaded at startup. >>> >>> Then, if someone has some weird keyboard, they could just edit the file... >>> >>> But then, I probably have no idea what I'm talking about!!! >> >> Well, at some level that is what the OS is doing. Fortunately the VMs >> can work on a slightly higher level. >> But... >> >> Although all VMs now deliver unicode values in slot 6 of the input >> event, getting composing keyboards and latin1 based shortcut keys to >> work is still tricky. And I still haven't tested all the important >> combinations of OS and keyboard layouts yet. >> >> The Windows VM does a good job delivering composed sequences, you get >> all the intermediate keys (e.g. " and u), but only one keystroke event >> for the composed character. >> The Linux VM however delivers keystrokes for the intermediate keys, so I >> need to figure out, if there is a single key or a composing sequence >> coming up. That's where the ugly hack comes in, peeking for the next >> event etc. >> >> Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so >> far only tested and probably only there working on Windows. It works by >> looking at the scancode of the key, which is only delivered on the key >> down and up events. Then, in dispatch, I need to look at the unicode >> value delivered, but also at the scan code and if a modifier is pressed. >> The problem is that dispatching of key commands is implemented >> differently all over the system and in no place used the event, but >> simply the character. I refactored it for paragraph editor, but not all >> the other places. >> >> In Sophie we got around that by hacking the Tweak widgets to use >> factored out lookup tables, so there was only one place to deal with that. >> - Show quoted text - >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > - Show quoted text - > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

March 4, 2009

Re: [Pharo-project] Unicode test II

by Igor Stasenko

Michael, i got an in MultiCompositionScanner. I can't mail out a bug report, because when doing it, i again get the same error. Can i send an image.zip to you, so you can take a look at it? 2009/3/4 Michael Rueger <m.rueger(a)acm.org>: > Rob Rothwell wrote: >> Long ago when I thought I was going to be writing Operating Systems in >> Assembly Language, I had a raw keyboard driver interpreting the key >> codes from various keyboards. >> >> TERRIBLE to debug (though not as bad as debugging a display driver). >> >> Is that what all this is like? >> >> Ugh... >> >> Do you use lookup tables for all the various keyboard types and >> operating systems? >> >> It seems like you almost need a matrix of all the supported systems vs. >> all the possible keyboards, with a table for each one...it could just be >> a file in the image directory and get loaded at startup. >> >> Then, if someone has some weird keyboard, they could just edit the file... >> >> But then, I probably have no idea what I'm talking about!!! > > Well, at some level that is what the OS is doing. Fortunately the VMs > can work on a slightly higher level. > But... > > Although all VMs now deliver unicode values in slot 6 of the input > event, getting composing keyboards and latin1 based shortcut keys to > work is still tricky. And I still haven't tested all the important > combinations of OS and keyboard layouts yet. > > The Windows VM does a good job delivering composed sequences, you get > all the intermediate keys (e.g. " and u), but only one keystroke event > for the composed character. > The Linux VM however delivers keystrokes for the intermediate keys, so I > need to figure out, if there is a single key or a composing sequence > coming up. That's where the ugly hack comes in, peeking for the next > event etc. > > Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so > far only tested and probably only there working on Windows. It works by > looking at the scancode of the key, which is only delivered on the key > down and up events. Then, in dispatch, I need to look at the unicode > value delivered, but also at the scan code and if a modifier is pressed. > The problem is that dispatching of key commands is implemented > differently all over the system and in no place used the event, but > simply the character. I refactored it for paragraph editor, but not all > the other places. > > In Sophie we got around that by hacking the Tweak widgets to use > factored out lookup tables, so there was only one place to deal with that. > - Show quoted text - > 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.

March 4, 2009

Re: [Pharo-project] SortedCollection>>median

by Chris Cunningham

On Sun, Mar 1, 2009 at 4:34 PM, Rob Rothwell <r.j.rothwell(a)gmail.com> wrote: > I notice that the current median is: > > median > "Return the middle element, or as close as we can get." > > ^ self at: self size + 1 // 2 > > Any reason not to make that accurate and return the average of the middle > two values for collections containing an even number of items? > One nice thing about the existing definition is that you can use #median on collections that are numeric based. So, median of: #( 'Ford' 'Audi' 'Nissan' 'Hyundai' ) median would actually return in the current definition, but not in a 'statistical' definition. Similarly, #max and #min and #size would work for this, although #sum wouldn't. Chris

March 4, 2009

Re: [Pharo-project] Unicode test II

by Michael Rueger

Rob Rothwell wrote: > Long ago when I thought I was going to be writing Operating Systems in > Assembly Language, I had a raw keyboard driver interpreting the key > codes from various keyboards. > > TERRIBLE to debug (though not as bad as debugging a display driver). > > Is that what all this is like? > > Ugh... > > Do you use lookup tables for all the various keyboard types and > operating systems? > > It seems like you almost need a matrix of all the supported systems vs. > all the possible keyboards, with a table for each one...it could just be > a file in the image directory and get loaded at startup. > > Then, if someone has some weird keyboard, they could just edit the file... > > But then, I probably have no idea what I'm talking about!!! Well, at some level that is what the OS is doing. Fortunately the VMs can work on a slightly higher level. But... Although all VMs now deliver unicode values in slot 6 of the input event, getting composing keyboards and latin1 based shortcut keys to work is still tricky. And I still haven't tested all the important combinations of OS and keyboard layouts yet. The Windows VM does a good job delivering composed sequences, you get all the intermediate keys (e.g. " and u), but only one keystroke event for the composed character. The Linux VM however delivers keystrokes for the intermediate keys, so I need to figure out, if there is a single key or a composing sequence coming up. That's where the ugly hack comes in, peeking for the next event etc. Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so far only tested and probably only there working on Windows. It works by looking at the scancode of the key, which is only delivered on the key down and up events. Then, in dispatch, I need to look at the unicode value delivered, but also at the scan code and if a modifier is pressed. The problem is that dispatching of key commands is implemented differently all over the system and in no place used the event, but simply the character. I refactored it for paragraph editor, but not all the other places. In Sophie we got around that by hacking the Tweak widgets to use factored out lookup tables, so there was only one place to deal with that. Michael

March 4, 2009

Re: [Pharo-project] Unicode test II

by Igor Stasenko

Great, keyboard shortcuts now is working under russian keyboard layout in windoze! 2009/3/3 Michael Rueger <m.rueger(a)acm.org>: > 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. > > > Happy testing > > 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.

March 4, 2009

Re: [Pharo-project] Unicode test II

by Rob Rothwell

Long ago when I thought I was going to be writing Operating Systems in Assembly Language, I had a raw keyboard driver interpreting the key codes from various keyboards. TERRIBLE to debug (though not as bad as debugging a display driver). Is that what all this is like? Ugh... Do you use lookup tables for all the various keyboard types and operating systems? It seems like you almost need a matrix of all the supported systems vs. all the possible keyboards, with a table for each one...it could just be a file in the image directory and get loaded at startup. Then, if someone has some weird keyboard, they could just edit the file... But then, I probably have no idea what I'm talking about!!! Rob On Tue, Mar 3, 2009 at 7:27 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Tue, Mar 3, 2009 at 10:24 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > >> Mariano Martinez Peck wrote: >> > It doesn't work for me. I am using Ubuntu 8.04 with latin american >> > distribution. I am trying yo type "Ã©", "Ãº", and so on, but with no luck. >> > >> > The problem is: I open a workspace. I type "Ã¡" and works fine. I try to >> > type "Ã¡" again and I have this error: "'subscript is out of bounds: >> -60'" >> > >> > It is very strange because only the first time work. >> >> What kind of keyboard are you using? >> >> I had to do an incredibly ugly hack because of the way the Linux VM >> deals with composing key sequences, so it could be that I messed up the >> normal keyboard input. Sigh... >> > > Dell 101-key PC with Latin American Layout. > > cheers > > >> >> Michael >> >> _______________________________________________ >> 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 4, 2009