- Pharo-users - lists.pharo.org

Re: [Pharo-users] Native language support

by Thierry Goubier

Hi Nick, thanks for finding this. I can now, finally, use the compose key on my Linux keyboard to enter characters like Ã, Ã, Ã... Thierry 2015-03-12 8:48 GMT+01:00 Nick Doodka <nickdoodka(a)gmail.com>: > After series of trial and error methods I found acceptable solution of my > problem. That is chunk of code from Pharo 2.0 should be copy&paste to > appropriate place in method HandMorph>>generateKeyboardEvent. This way let > me to avoid problems with mouse wheel freezing or generating errors. > > i.e. > ..... > "Adjustments to provide consistent key value data for different VM's: > - charCode always contains unicode code point. > - keyValue contains 0 if input is outside legacy range" > "If there is no unicode data in the event, assume keyValue contains a > correct (<256) Unicode codepoint, and use that" > (charCode isNil or: [charCode = 0]) > ifTrue: [charCode := keyValue]. > "If charCode is not single-byte, we definately have Unicode input. Nil > keyValue to avoid garbage values from some VMs." > charCode > 255 ifTrue: [keyValue := 0]. > ..... > > Full version of patched method I attach as zip-archive for v3 and v4 > apart. I suppose developers should correct this method in next releases of > Pharo for the sake non-english users support. Thanks for helping and > advises. > > > 2015-03-10 16:10 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Now it is Pharo3.0 Latest update: #30862 and Pharo4.0 Latest update: >> #40474, but previous updates worked the same (ignore cyrillic capital >> letters ÐÐÐÐÐÐÐ) >> >>> What is the exact image version (incl. update number)? >>> >> I meant specifically regarding the #isArrow error. I donât think you can >> be having this in 3.0, so you mean #40474 correct? Is it only after you >> change the language? >> Cheers, >> Sean >> >> ------------------------------ >> View this message in context: Re: Native language support >> <http://forum.world.st/Native-language-support-tp4809392p4811000.html> >> >> Sent from the Pharo Smalltalk Users mailing list archive >> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at >> Nabble.com. >> > >

March 12, 2015

Re: [Pharo-users] Native language support

by Ben Coman

Hi Nick, The best way to ensure this will get included is log an issue and submit a code slice at pharo.fogbugz.com. Then your code can undergo review and be integrated in a managed way. Read the "How to Contribute" link from there, and if its not clear, please provide feedback so we can improve it. cheers -ben cheers -ben On Thu, Mar 12, 2015 at 4:37 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi Nick, > > Thanks for chasing the bug down. > > Since the code for event handling is probably going to change in favor of > SDL2 events soon, I think it should be good to also provide some tests for > this, to detect any regression or problem, or at least to document expected > behavior. Do you have any pointers of what should be tested? Which are the > cases that worked or not and in which keyboard layouts? > > Guille > > El jue., 12 de mar. de 2015 a la(s) 8:48 a. m., Nick Doodka < > nickdoodka(a)gmail.com> escribiÃ³: > > After series of trial and error methods I found acceptable solution of my >> problem. That is chunk of code from Pharo 2.0 should be copy&paste to >> appropriate place in method HandMorph>>generateKeyboardEvent. This way let >> me to avoid problems with mouse wheel freezing or generating errors. >> >> i.e. >> ..... >> "Adjustments to provide consistent key value data for different VM's: >> - charCode always contains unicode code point. >> - keyValue contains 0 if input is outside legacy range" >> "If there is no unicode data in the event, assume keyValue contains a >> correct (<256) Unicode codepoint, and use that" >> (charCode isNil or: [charCode = 0]) >> ifTrue: [charCode := keyValue]. >> "If charCode is not single-byte, we definately have Unicode input. Nil >> keyValue to avoid garbage values from some VMs." >> charCode > 255 ifTrue: [keyValue := 0]. >> ..... >> >> Full version of patched method I attach as zip-archive for v3 and v4 >> apart. I suppose developers should correct this method in next releases of >> Pharo for the sake non-english users support. Thanks for helping and >> advises. >> >> >> 2015-03-10 16:10 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >> >>> Now it is Pharo3.0 Latest update: #30862 and Pharo4.0 Latest update: >>> #40474, but previous updates worked the same (ignore cyrillic capital >>> letters ÐÐÐÐÐÐÐ) >>> >>>> What is the exact image version (incl. update number)? >>>> >>> I meant specifically regarding the #isArrow error. I donât think you can >>> be having this in 3.0, so you mean #40474 correct? Is it only after you >>> change the language? >>> Cheers, >>> Sean >>> >>> ------------------------------ >>> View this message in context: Re: Native language support >>> <http://forum.world.st/Native-language-support-tp4809392p4811000.html> >>> >>> Sent from the Pharo Smalltalk Users mailing list archive >>> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at >>> Nabble.com. >>> >> >>

March 12, 2015

Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

by Thierry Goubier

2015-03-12 9:46 GMT+01:00 kilon alios <kilon.alios(a)gmail.com>: > It would be nice to have a parser to rule them all. I am currently using > SmaCC and gets the job done. I really like its condense syntax and its > syntax tool but also love the smalltalky feel of pettit parser. > > > Maybe one must bite the bullet and write perfomance critical parts in C or > even use a C parsing engine as a back end of pettit parser ? > This would be overkill. Smalltalk is fast enough. >From what Doru was talking about, we should have at least some knowledge on what is slow in PetitParser by ESUG. I saw some things by just profiling it once. My position on that is that PetitParser reliance on PEG is a weakness, especially compared to the current state of competing tools (GLR in SmaCC, LL(*) in ANTLR, Parsing with Derivatives, GLL). And if you combine it with performance problems, then that doesn't look so good. On the other hand, PetitParser has a lot going for it: parser combinators (but PwD and GLL also have that), parser reuse, parsing debug. Now, if you tell me a Pillar based parser in SmaCC, I'd say: easy and fast. With a nice, formal grammar defining/documenting the Pillar as a side benefit, which would make maintaining Pillar parsing very easy for the long term. (and that formal grammar would make writing a PetitParser pillar parser a breeze :)). Thierry

March 12, 2015

Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

by kilon alios

It would be nice to have a parser to rule them all. I am currently using SmaCC and gets the job done. I really like its condense syntax and its syntax tool but also love the smalltalky feel of pettit parser. Maybe one must bite the bullet and write perfomance critical parts in C or even use a C parsing engine as a back end of pettit parser ? On Thu, Mar 12, 2015 at 12:39 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 11.03.2015 um 23:03 schrieb Damien Cassou <damien.cassou(a)gmail.com>: > > > > Hi, > > > > The current pillar parser has several problems: > > > > - it is hard to understand and change > > - it discards input locations > > > > I think a refactor or rewrite is necessary. What are the pros and cons > of using PetitParser to do that? > > > The cons are that petit parser is a heavier component and we should never > underestimate that (just a reaction to a notion on this list). So we should > avoid making things more complex, especially dependency wise. > The pros is that petit parser will make it easier to extend and maintain > the pillar parser. I've read something about a new version of petit parser > that has a speedup of aprox. 1.000.000x. If that is the case then it is no > downgrade speed wise :) Another pro is IMHO that are some people that would > like to move petit parser closer (not too close) to the core. That again > would make it a more standard component that makes it easy to write parsers > for everyone. A good companion if you have regex and you exceed to > possibilities it provides. > > I really have a bad feeling while saying: It would be good to have pillar > based on petit parser. > > Norbert > > > > >

March 12, 2015

Re: [Pharo-users] Native language support

by Guillermo Polito

Hi Nick, Thanks for chasing the bug down. Since the code for event handling is probably going to change in favor of SDL2 events soon, I think it should be good to also provide some tests for this, to detect any regression or problem, or at least to document expected behavior. Do you have any pointers of what should be tested? Which are the cases that worked or not and in which keyboard layouts? Guille El jue., 12 de mar. de 2015 a la(s) 8:48 a. m., Nick Doodka < nickdoodka(a)gmail.com> escribiÃ³: > After series of trial and error methods I found acceptable solution of my > problem. That is chunk of code from Pharo 2.0 should be copy&paste to > appropriate place in method HandMorph>>generateKeyboardEvent. This way let > me to avoid problems with mouse wheel freezing or generating errors. > > i.e. > ..... > "Adjustments to provide consistent key value data for different VM's: > - charCode always contains unicode code point. > - keyValue contains 0 if input is outside legacy range" > "If there is no unicode data in the event, assume keyValue contains a > correct (<256) Unicode codepoint, and use that" > (charCode isNil or: [charCode = 0]) > ifTrue: [charCode := keyValue]. > "If charCode is not single-byte, we definately have Unicode input. Nil > keyValue to avoid garbage values from some VMs." > charCode > 255 ifTrue: [keyValue := 0]. > ..... > > Full version of patched method I attach as zip-archive for v3 and v4 > apart. I suppose developers should correct this method in next releases of > Pharo for the sake non-english users support. Thanks for helping and > advises. > > > 2015-03-10 16:10 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Now it is Pharo3.0 Latest update: #30862 and Pharo4.0 Latest update: >> #40474, but previous updates worked the same (ignore cyrillic capital >> letters ÐÐÐÐÐÐÐ) >> >>> What is the exact image version (incl. update number)? >>> >> I meant specifically regarding the #isArrow error. I donât think you can >> be having this in 3.0, so you mean #40474 correct? Is it only after you >> change the language? >> Cheers, >> Sean >> >> ------------------------------ >> View this message in context: Re: Native language support >> <http://forum.world.st/Native-language-support-tp4809392p4811000.html> >> >> Sent from the Pharo Smalltalk Users mailing list archive >> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at >> Nabble.com. >> > >

March 12, 2015

Re: [Pharo-users] Native language support

by Nick Doodka

After series of trial and error methods I found acceptable solution of my problem. That is chunk of code from Pharo 2.0 should be copy&paste to appropriate place in method HandMorph>>generateKeyboardEvent. This way let me to avoid problems with mouse wheel freezing or generating errors. i.e. ..... "Adjustments to provide consistent key value data for different VM's: - charCode always contains unicode code point. - keyValue contains 0 if input is outside legacy range" "If there is no unicode data in the event, assume keyValue contains a correct (<256) Unicode codepoint, and use that" (charCode isNil or: [charCode = 0]) ifTrue: [charCode := keyValue]. "If charCode is not single-byte, we definately have Unicode input. Nil keyValue to avoid garbage values from some VMs." charCode > 255 ifTrue: [keyValue := 0]. ..... Full version of patched method I attach as zip-archive for v3 and v4 apart. I suppose developers should correct this method in next releases of Pharo for the sake non-english users support. Thanks for helping and advises. 2015-03-10 16:10 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Now it is Pharo3.0 Latest update: #30862 and Pharo4.0 Latest update: > #40474, but previous updates worked the same (ignore cyrillic capital > letters ÐÐÐÐÐÐÐ) > >> What is the exact image version (incl. update number)? >> > I meant specifically regarding the #isArrow error. I donât think you can > be having this in 3.0, so you mean #40474 correct? Is it only after you > change the language? > Cheers, > Sean > > ------------------------------ > View this message in context: Re: Native language support > <http://forum.world.st/Native-language-support-tp4809392p4811000.html> > > Sent from the Pharo Smalltalk Users mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com. >

March 12, 2015

Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

by Norbert Hartl

> Am 11.03.2015 um 23:03 schrieb Damien Cassou <damien.cassou(a)gmail.com>: > > Hi, > > The current pillar parser has several problems: > > - it is hard to understand and change > - it discards input locations > > I think a refactor or rewrite is necessary. What are the pros and cons of using PetitParser to do that? > The cons are that petit parser is a heavier component and we should never underestimate that (just a reaction to a notion on this list). So we should avoid making things more complex, especially dependency wise. The pros is that petit parser will make it easier to extend and maintain the pillar parser. I've read something about a new version of petit parser that has a speedup of aprox. 1.000.000x. If that is the case then it is no downgrade speed wise :) Another pro is IMHO that are some people that would like to move petit parser closer (not too close) to the core. That again would make it a more standard component that makes it easy to write parsers for everyone. A good companion if you have regex and you exceed to possibilities it provides. I really have a bad feeling while saying: It would be good to have pillar based on petit parser. Norbert

March 11, 2015

[ANN] TODO List of Requested Features

by Damien Cassou

I've just written a list of nice features we miss in Pillar: http://www.smalltalkhub.com/#!/~Pier/Pillar Please contribute by either making the list longer or, and I would prefer that, making it shorter.

March 11, 2015

Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

by Tudor Girba

I completely agree. I think there are mostly pros. It can be that the parsing will be slower, but I do not think this is a critical issue for Pillar. It would be more important to have an extensible parser. Cheers, Doru On Wed, Mar 11, 2015 at 11:03 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi, > > The current pillar parser has several problems: > > - it is hard to understand and change > - it discards input locations > > I think a refactor or rewrite is necessary. What are the pros and cons of > using PetitParser to do that? > > Best -- www.tudorgirba.com "Every thing has its own flow"

March 11, 2015

Pillar parser rewrite: PetitParser or not?

by Damien Cassou

Hi, The current pillar parser has several problems: - it is hard to understand and change - it discards input locations I think a refactor or rewrite is necessary. What are the pros and cons of using PetitParser to do that? Best

March 11, 2015