- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

salut nicolas > 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. Me too. > What are Pharo plans? We do not really know because we are not expert. Now I agree with you that making the system simpler would be better. Then once the system is cleaner we can probably find a solution. To me right now it looks complex and without test cases. Stef > 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] Unicode/Latin1 handling in Pharo 1.3

by StÃ©phane Ducasse

Thanks sven Indeed this would be good. Right now we will continue to fix the problems we are looking (event sensor, canvasâ¦.) at but this is good that people work on other parts of the system. Stef >>> <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] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by StÃ©phane Ducasse

for me I can understand that people want a format to exchange objects and that they want to use STON but I do not understand why we need that to store metadata when a simple array works. Probably we love to load our boat with extra readers and writers. Stef On May 8, 2012, at 2:05 PM, Sven Van Caekenberghe wrote: > (The paper was indeed just updated a couple of days ago). > > On 08 May 2012, at 13:29, GÃ¶ran Krampe wrote: > >> - In general I believe in 99% of the cases the parsing system has to know what it is parsing, how the JSON looks and how it should be mapped onto objects. Making the JSON parser itsy bitsy smarter with type annotations doesn't help me there, I still need to know that I want to instantiate a PDFPage and put this Rectangle into it - but oh, perhaps not as a Rectangle, but perhaps as two points sent into a class side instantiation message or something. >> >> My point being that the type annotations doesn't "buy me" enough. > > (Just for the sake of the argument, I don't want to convince you) > > STON *does* buy you that: as long as we are talking about 'domain level objects' (a vague notion I agree) your Smalltalk object will serialize without any extra effort (see the ZnResponse example in the paper). You can customize some objects if you want to (mostly for readability, sometimes to fix some issue). > > Object implements #toSton: and #fromSton: by iterating over the instances variables. > > The issues are: Blocks, Classes and the fact that ephemeral instances are always serialized. > > Sven > >

May 8, 2012

Re: [Pharo-project] Nested progress bars

by StÃ©phane Ducasse

Hi martin can you open a bug entry? Stef > I didn't mention that my question comes from trying and finding bugs > in the method BlockClosure>>silentlyValue, in Pharo 2.0 (should be in > 1.4 also): > > silentlyValue > "evaluates the receiver but avoiding progress bar notifications to show up." > > ^[ self value ] > on: ProgressInitiationException > do: [ :ex | > ex sendNotificationsTo: [ :min :max :curr | > self traceCr: min printString,' ',max printString,' ',curr printString; cr > ]. > ]. > > ----> "; cr" has to be removed from code. After this easy fix, the > other bug makes visible: #silentlyValue is not that silently with > nested progress bars. Try: > > [ > 'main task' > displayProgressFrom: 0 to: 5 > during: [ :bar | > 0 to: 5 do: [:x | bar value: x. > (Delay forMilliseconds: 200) wait. > > 'nested task ' , x printString > displayProgressFrom: 5 to: 10 > during: [ :bar2 | > 5 to: 10 do: [:x2 | bar2 value: x2. > (Delay forMilliseconds: 200) wait] ] ] ]. > > ] silentlyValue. > > > Cheers. > MartÃn > > > On Tue, May 8, 2012 at 12:28 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >> Hi all. >> >> Given the next code, could you explain me why nested progress bars are >> not handled by my #on:do:? >> How can I achieve that? >> >> [ >> 'main task' >> displayProgressFrom: 0 to: 5 >> during: [ :bar | >> 0 to: 5 do: [:x | bar value: x. >> (Delay forMilliseconds: 200) wait. >> >> 'nested task ' , x printString >> displayProgressFrom: 5 to: 10 >> during: [ :bar2 | >> 5 to: 10 do: [:x2 | bar2 value: x2. >> (Delay forMilliseconds: 200) wait] ] ] ] >> >> ] on: ProgressInitiationException >> do: [ :ex | >> ex sendNotificationsTo: [ :min :max :curr | >> self traceCr: curr ] ]. >> >> >> Thanks in advance. >> MartÃn >

May 8, 2012

Re: [Pharo-project] Improved version of StartupPreferences (+Windows)

by Ben Coman

Mariano Martinez Peck wrote: > Hi guys. After playing a little bit with StartupPreferences, and continuing > the effort of Ben (thanks Ben for yet another great tool), I generate a > improved (from my point of view) version of the tool. > > The main changes are: > > a) Previously the tool searched files 1) first in image directory, 2) then > in the preference folder and 3) finally in the general preference folder. > As soon as it found at least one file, I didn't continue with the rest of > the places. Now, it starts the other way around, from the most general to > the most spceific. Starts in 3), then 2) and finally 1) > Moreover, it does > not stop when it finds files in any of them. So all are searched and > executed. It works or or less the same way as variables in UNIX with > .bashrc /etc/envirorment, etc... > Did it actually work like that? I thought it had worked for me processing more than one file from each preferences folders. It seemed only the image folder was restricted to a single specific file 'startup.st' I assume this was to avoid processing any other random .st files that might happen appear in the image folder. I had been considering a refactoring like your #lookInFolder, but was concerned about picking up random .st files in the image folder. I haven't gone through the your new methods in detail, but I've expanded your changes to the existing architecture to also resolve the issue with Windows. Basically I've thrown away what I was trying to do putting the configs into standard Microsoft locations. That was mainly to deal the location of config folders being hardcoded at two level down from root, which I have now removed this constraint. The config folder can now be located anywhere in the parent path from the image up to root. The key addition is #ascendingSearchForDirectory for which you can try these out... FileDirectory default ascendingSearchForDirectory: 'mariano' FileDirectory default ascendingSearchForDirectory: 'Users' FileDirectory default ascendingSearchForDirectory: 'Contents' "Valid for one-click image" FileDirectory default ascendingSearchForDirectory: FileDirectory configFolderLocalName FileDirectory preferencesGeneralFolder FileDirectory preferencesFolder > b) I have created several class side methods (addAtStartup*) to create > given actions into the current directory. Previously, files were created in > 2 folders at the same time and there were only the possibility to create > only in one place. Now you can add startup actions in any of the 3 places > mentioned in a) > > c) Added a whole protocol (remove* and clean*) to remove script files from > all folders of a) and also to clean the internal stored actions. > > d) Lots of internal refactors to reuse code and less hardcoding. > > Does someone want to take a look to the slice ? > Slice in inbox: http://code.google.com/p/pharo/issues/detail?id=5835 > > Cheers, > >

May 8, 2012

Re: [Pharo-project] Nautilus load problem

by StÃ©phane Ducasse

On May 8, 2012, at 3:20 AM, Sean P. DeNigris wrote: > > Marcus Denker-4 wrote >> >> Nautilus... getting it ready will be double as hard if it has to run on >> both 1.4 and 2.0. >> > > Is Nautilus unsupported on 1.4? we should ask benjamin because he may fix the important problems. > There have been many suggestions to load it > in preference to the default browser in 1.4, so we should be clear whether > it will be expected to work. I guess then OB would be the only workable > option... but Nautilus is so cool - it's hard to go back, lol!! > > -- > View this message in context: http://forum.world.st/Nautilus-load-problem-tp4603363p4616242.html > 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 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