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

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by StÃ©phane Ducasse

On May 8, 2012, at 8:33 PM, GÃ¶ran Krampe wrote: > On 05/08/2012 07:46 PM, StÃ©phane Ducasse wrote: >> 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. > > No, it was just a "trigger" for this discussion/comparison. > > BUT... I would like you to at least read the parts in my article which is about improving the literal support we have in Smalltalk/Pharo. The main "problem" with literals that I can see (compared to Tirade) are: > > - There is no restricted parser for them (as Tirade is), you need to use Compiler and that is a HUGE security problem. But of course, you are fixing that, right? :) :) there is no security problem just that gemstone does not have a parser. Because parsing cannot be a security hole this is blind data interpretation that is a problem. This is why Github got problems and I imagine that the code was probably passed in JSON or similar format. > - There is no support for Associations as literals which means there is no good support in literals to express Dictionaries/key-value-pairs (like JSON has). Tirade has that in the form of literal Associations. I think we should add something in this area to Pharo/Smalltalk in general, but for more thoughts on that, please see article. Ok let me try to understand what I do not get. Do you mean that we cannot distinguish between #((a 13) 'a' 'b' 1 ) and #(a -> 13 'a' 'b' 1 ) why #(Dictionary (a 13) (b 15)) or #(Dictionary ((a 13) (b 15))) is not the same as #(Dictionary a-> 13 b ->15) Now the problem is that a -> 13 is not created at parse time. So I do not get why > > regards, GÃ¶ran

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by GÃ¶ran Krampe

On 05/08/2012 07:46 PM, StÃ©phane Ducasse wrote: > 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. No, it was just a "trigger" for this discussion/comparison. BUT... I would like you to at least read the parts in my article which is about improving the literal support we have in Smalltalk/Pharo. The main "problem" with literals that I can see (compared to Tirade) are: - There is no restricted parser for them (as Tirade is), you need to use Compiler and that is a HUGE security problem. But of course, you are fixing that, right? :) - There is no support for Associations as literals which means there is no good support in literals to express Dictionaries/key-value-pairs (like JSON has). Tirade has that in the form of literal Associations. I think we should add something in this area to Pharo/Smalltalk in general, but for more thoughts on that, please see article. regards, GÃ¶ran

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by Dale Henrichs

:):):) for the correct definition of "works" I agree :):):) Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, May 8, 2012 10:46:08 AM | Subject: Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation) | | 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] Improved version of StartupPreferences (+Windows)

by Mariano Martinez Peck

On Tue, May 8, 2012 at 7:21 PM, Ben Coman <btc(a)openinworld.com> wrote: > 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? yes > I thought it had worked for me processing more than one file from each > preferences folders. No. See the previous version: PreferenceHandler >> perform actions do: [:each | each value ifNotNil: [:res | ^ res ] ]. ^#() then the value was not nil (therefore, when there were found files), the method just returned. > 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 copy paste here part of my future blog post (once this is integrated I will publish it). This is how it works NOW in ORDER: 1. The image folder: The startup only searches for a file called â startup.stâ. So if you have such a file in the same directory where the image is, then such script will be executed automatically. This type of startup is usually used to do something that is application-specific or something that only makes sense for the specific image you are using. 2. Preference folder: This is a specific folder for a specific Pharo version. This folder is in the $HOME (kind of) of the current OSâ user. Therefore, this folder is shared for all the images you open. To know the real value, print the result of âFileDirectory preferencesFolderâ. In my case (in MaxOSX) and Pharo 2.0, it is â/Users/mariano/.config/pharo/2.0â². In this place, StartupLoader will load ALL existing .st files. This type of startup is useful when we have something to execute for all images of a specific Pharo version. 3. General preferences folder: this is similar to the previous one with the difference that it is general for all Pharo versions. To know the value, print âFileDirectory preferencesGeneralFolderâ, which in my case is â/Users/mariano/.config/pharo/generalâ. This type of startup is useful when we have something to execute for all images of any Pharo version. > 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 > > Excellent. So it means that then it is working for Windows also? > > > 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<http://code.google.com/p/pharo/issues/detail?id=5835> >> >> Cheers, >> >> >> > > > -- Mariano http://marianopeck.wordpress.com

May 8, 2012

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