May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Nicolas Cellier

2012/5/8 Norbert Hartl <norbert(a)hartl.name>: > > Am 08.05.2012 um 15:37 schrieb Henrik Sperre Johansen: > > TLDR of non-bug related stuff; If it were up to me, I'd say nuke leadingChar > from orbit (which, as you say, is already done in most cases), > then find some other way than what is currently done in LanguageEnvironment > (if possible) to query the correct encoding of strings you pass to the > system. > > One thing is sure, both clean-up and fast-up would result from leadingChar removal, and Pharo is the perfect place where this should happen. The main question left is what support shall we provide to East-asian-users... I don't know what works or what is broken already, and what are the required features exactly to support asian usage. What are Pharo plans? Nicolas > + any number you can imagine > > It is easy to state that it is broken now and leadingChar causes harm. So > nuking it will probably just inverse the problem situation but then it can > be cured somehow by fixing the bugs. Handling the characters right in > encoding is only one side of the medal. Characters and strings are still > need to be comparable. To get this right it would mean to have support ICU > [1] in pharo which is a good idea anyway. Well, if it is doable in a > pluggable fashion of course. > > Norbert > > [1]Â http://site.icu-project.org/

May 8, 2012

Re: [Pharo-project] Improved version of StartupPreferences

by Damien Cassou

On Tue, May 8, 2012 at 3:54 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Oh, I see, thanks. I was thinking like ~/.jenkins, but I checked Ubuntu and > OS X and it looks like ~/.config is a well-known convention. This is part of a specification: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 8, 2012

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Sven Van Caekenberghe

Norbert, On 08 May 2012, at 16:52, Norbert Hartl wrote: > Am 08.05.2012 um 16:20 schrieb Sven Van Caekenberghe: > >> <rant>Notice how f*cked up TextConverters are: when given a binary stream, their natural input one would think, they just don't do any conversion!</rant> > > Isn't that obvious? In a time where there was text or binary and your biggest problem was line ending conversion it is normal to do not any processing on a binary stream. It is its definition. The world has changed since then and since we have encodings there is no such thing as a text/ascii stream anymore. I think we have to slowly convert those things to modern stuff. How hard that is? Look at Grease it is a piece of modern software but still encodes string -> string. There are always caveats not to ignore. Right! In the very latest Zn I added ZnCharacterReadStream and ZnCharacterWriteStream but I did not yet integrate/use them. These add character decoding and encoding to binary streams, here are some tests that show how to use them: testSimpleUTF8WriteStream | string bytes stream | string := 'Ã©lÃ¨ve en FranÃ§ais'. bytes := ZnUTF8Encoder new encodeString: string. stream := (ZnCharacterWriteStream on: #[] writeStream). stream nextPutAll: string. self assert: stream wrappedStream contents equals: bytes testSimpleUTF8ReadStream | string bytes | string := 'Ã©lÃ¨ve en FranÃ§ais'. bytes := ZnUTF8Encoder new encodeString: string. self assert: (ZnCharacterReadStream on: bytes readStream) upToEnd equals: string I think these could be useful in other places (FS) as well and help in getting rid of some old stuff. Mind you, these are currently still only experiments. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 8, 2012

Re: [Pharo-project] Running in background with OSProcess

by Sean P. DeNigris

Sean P. DeNigris wrote > > How do I circumvent all the processing and tell OSP what args to actually > pass to the underlying system? > I found a solution: env := CommandShell new environment. pwd := '/'. args := Array with: '-DJENKINS_HOME=/path with spaces/.jenkins' with: '-jar' with: '/path/with/another space/jenkins.war' with: '--httpPort=####' with: '--ajp13Port=####'. desc := (Array with: nil with: nil with: nil). p := PipeableOSProcess new: '/usr/bin/java' arguments: args environment: env descriptors: desc workingDir: pwd errorPipelineStream: nil. Since I'm not doing any redirecting, this works. If you have to redirect, it looks like the best move would be to go through ProxyPipeline, like Dave suggested, but define and plugin a custom ShellSyntax that does not do any string processing... Sean -- View this message in context: http://forum.world.st/Running-in-background-with-OSProcess-tp4615534p461779… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 8, 2012

Re: [Pharo-project] How to dispatch mouseWheel?

by Gary Chambers

Hi, Ideally we need to change EventHandler to support mouseWheel events and at the same time, perhaps, integrate EventHandlerPlus upwards too. Otherwise, you will need to do as you suggested, make a Morph subclass to handle stuff and use that as the in-betweener. Regards, Gary ----- Original Message ----- From: "Martin Drautzburg" <Martin.Drautzburg(a)web.de> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, May 05, 2012 7:49 PM Subject: Re: [Pharo-project] How to dispatch mouseWheel? > On Saturday, 5. May 2012 19:06:38 Martin Drautzburg wrote: > Sorry, that was a bit fuzzy. > > My Morph is in a GeneralScrollPane. The GeneralScrollPane first sends > mouseWheel event to the scroller (my Morph). My Morph can scroll > horizonally > infinitely and handles the horizontal scrolling itself. Its mouseWheel > method > makes sure this only happens when the mouse is over it. Otherwise the > event > remains unhandled and the GeneralScrollPane handles it and scrolls > vertically. > > Now I have another Morph (really just a plain Morph) in betwen. The > scroller > again sends it a mouseWheel, but its just a plain Morph and it does not > handle > it. The effect is that scrolling is always controlled by the scroll pane > (i.e. > vertically). I cannot seem to tell the scroll pane: don't ask your > scroller, > ask my Morph, nor can I tell this plain Morph: when someone asks you to > handle > a mouseWheel, don't just say no, ask my Morph instead. > > Of course I can just create another Morph Class which passes all events to > its > owner. Is there anything more elegant? > > -- > Martin >

May 8, 2012

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Norbert Hartl

Am 08.05.2012 um 16:20 schrieb Sven Van Caekenberghe: > <rant>Notice how f*cked up TextConverters are: when given a binary stream, their natural input one would think, they just don't do any conversion!</rant> Isn't that obvious? In a time where there was text or binary and your biggest problem was line ending conversion it is normal to do not any processing on a binary stream. It is its definition. The world has changed since then and since we have encodings there is no such thing as a text/ascii stream anymore. I think we have to slowly convert those things to modern stuff. How hard that is? Look at Grease it is a piece of modern software but still encodes string -> string. There are always caveats not to ignore. Norbert

May 8, 2012

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Sven Van Caekenberghe

Here is an example with the file out of the equation: | stream | stream := (ByteArray readHexFrom: '5465696c72fc636b7a61686c756e67') asString readStream. stream next: 5. (ISO885915TextConverter new nextFromStream: stream) codePoint. => 71303420 | stream | stream := (ByteArray readHexFrom: '5465696c72fc636b7a61686c756e67') readStream. stream next: 5. ((ZnCharacterEncoder newForEncoding: 'iso-8859-15') nextFromStream: stream) codePoint. => 252 <rant>Notice how f*cked up TextConverters are: when given a binary stream, their natural input one would think, they just don't do any conversion!</rant> On 08 May 2012, at 15:30, Norbert Hartl wrote: > Can you paste the code you used to come to this result? > > Norbert > > Am 08.05.2012 um 14:46 schrieb Torsten Bergmann: > >> Sven wrote >>> On my Mac I get: >>> ... >>> (stream contents at: 6) codePoint 71303420 >>> ('TeilrÃ¼ckzahlung' at: 6) codePoint 252 >> >> Hi Sven, >> >> on Windows I get: >> >> (stream contents at: 6) codePoint 252 >> ('TeilrÃ¼ckzahlung' at: 6) codePoint 252 >> >> For >> >> $Ã¼ codePoint I also get 252 >> >> So on Windows (at least for my test) it does >> not have the "leadingChar". >> >> Bye >> T. >> >> -- >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >> > >

May 8, 2012

Re: [Pharo-project] Running in background with OSProcess

by Sean P. DeNigris

David T. Lewis wrote > > I'm afraid that the simulation of unix shell behavior is far from perfect > ... > BTW, I would welcome patches to improve things like this, as long as > they are supported with unit tests. > I'd def be willing to take a look... But, for my current pressing problem, I'm looking for the opposite from OSP. Instead of being able to pass any valid Bash syntax and have OSP parse it, I'm willing to restrict myself as long as I can do the parse myself. I don't want globbing or any other fancy processing. I will do all that myself before hand and only be supplying absolute paths. How do I circumvent all the processing and tell OSP what args to actually pass to the underlying system? Thanks for all the help! Sean -- View this message in context: http://forum.world.st/Running-in-background-with-OSProcess-tp4615534p461759… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 8, 2012

Re: [Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Norbert Hartl

Am 08.05.2012 um 15:37 schrieb Henrik Sperre Johansen: > TLDR of non-bug related stuff; If it were up to me, I'd say nuke leadingChar from orbit (which, as you say, is already done in most cases), > then find some other way than what is currently done in LanguageEnvironment (if possible) to query the correct encoding of strings you pass to the system. + any number you can imagine It is easy to state that it is broken now and leadingChar causes harm. So nuking it will probably just inverse the problem situation but then it can be cured somehow by fixing the bugs. Handling the characters right in encoding is only one side of the medal. Characters and strings are still need to be comparable. To get this right it would mean to have support ICU [1] in pharo which is a good idea anyway. Well, if it is doable in a pluggable fashion of course. Norbert [1] http://site.icu-project.org/

May 8, 2012

Re: [Pharo-project] Improved version of StartupPreferences

by Sean P. DeNigris

Mariano Martinez Peck wrote > > No, the directory is actually /Users/mariano/.config/pharo/general > It seems in linux they are stored that way so to avoid lots of .xxx in the > $HOME. So you use one directory for all your conf ;) > Oh, I see, thanks. I was thinking like ~/.jenkins, but I checked Ubuntu and OS X and it looks like ~/.config is a well-known convention. Sean -- View this message in context: http://forum.world.st/Improved-version-of-StartupPreferences-tp4615713p4617… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 8, 2012