March 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] using spotter to navigate through the file system

by Tudor Girba

Hi, On Thu, Mar 12, 2015 at 10:59 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > "Images should appear fine. What images are you missing?" > > hmm it looks like I am missing the preview panel altogether. Is this > committed to Pharo 4 ? I got the latest Pharo 4 image just now. > No, it's not yet. I made some changes recently and they are not yet in Pharo :). You can find them in the moose image. "In the meantime, you can add a simple presentation that allows you to > change the file in your packages :)" > > ok then I will look into that. > Ok. Doru -- www.tudorgirba.com "Every thing has its own flow"

March 12, 2015

Re: [Pharo-users] using spotter to navigate through the file system

by kilon alios

"Images should appear fine. What images are you missing?" hmm it looks like I am missing the preview panel altogether. Is this committed to Pharo 4 ? I got the latest Pharo 4 image just now. "In the meantime, you can add a simple presentation that allows you to change the file in your packages :)" ok then I will look into that.

March 12, 2015

Re: [Pharo-users] using spotter to navigate through the file system

by Tudor Girba

Hi, On Thu, Mar 12, 2015 at 10:38 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > Really impressive stuff. Looks like GTSpotter does not understand "~" for > home folder. It also does not preview images > Images should appear fine. What images are you missing? > as gtinspector can and also fails to preview text files that dont have a > .txt extension like for example .profile again GTInspector has no problem > previewing. > This should work as well. Could you point me to the file? > Is it possible to modify the contents of a text file from inside > GTInspector and save that file ? > You could, but the problem is that at this point it is too expensive to show the contents of large files, so we are only showing trimmed contents and that is why you do not have the option of saving right now. This will change in Pharo 5. In the meantime, you can add a simple presentation that allows you to change the file in your packages :) Cheers, Doru > On Wed, Mar 11, 2015 at 11:55 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> Hi, >> >> Here is a little post that describes how you can use GTSpotter to >> navigate through the file system: >> >> http://www.humane-assessment.com/blog/searching-file-system-with-gtspotter/ >> >> If you combine this with the GTInspector ability of allowing you interact >> with the file references, you get a pretty powerful tool: >> http://www.humane-assessment.com/blog/browsing-files-with-gtinspector/ >> >> This is probably the simplest 3-minute demo you can give to a newcomer :). >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 12, 2015

Re: [Pharo-users] Native language support

by Thierry Goubier

Hi Nick, Ben, 2015-03-12 10:17 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > 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. > I've created an issue: https://pharo.fogbugz.com/default.asp?15121 > 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] using spotter to navigate through the file system

by kilon alios

Really impressive stuff. Looks like GTSpotter does not understand "~" for home folder. It also does not preview images as gtinspector can and also fails to preview text files that dont have a .txt extension like for example .profile again GTInspector has no problem previewing. Is it possible to modify the contents of a text file from inside GTInspector and save that file ? On Wed, Mar 11, 2015 at 11:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Here is a little post that describes how you can use GTSpotter to navigate > through the file system: > http://www.humane-assessment.com/blog/searching-file-system-with-gtspotter/ > > If you combine this with the GTInspector ability of allowing you interact > with the file references, you get a pretty powerful tool: > http://www.humane-assessment.com/blog/browsing-files-with-gtinspector/ > > This is probably the simplest 3-minute demo you can give to a newcomer :). > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 12, 2015

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