- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Nautilus load problem

by StÃ©phane Ducasse

On May 8, 2012, at 10:38 PM, Benjamin wrote: > I will try to maintain Nautilus for 1.4 as long as I can, but we have all to keep in mind that now the main goal for Nautilus is to make it the default browser for 2.0. > > So obviously, I will focus more on the integration in 2.0. > But as long as we fix the system and make Nautilus work on it (as an example, the last PluggableListMorph changes) it means that Nautilus for 1.4 and Nautilus for 2.0 are different. Thanks benjmain. Did you try the latest version in 20? because e thought it looks strange with esteban BTW do you know if the font problems in the pane was fixed? Because usman got problems but in 1.4. I thought I fixed all the text morph to use the settings and that it was in 1.4 Stef > > But for more Nautilus related bugs, I will try to fix them in both :) > > > Let's hope I can manage to do that ^^ > > Ben > > > On May 8, 2012, at 7:11 PM, StÃ©phane Ducasse wrote: > >> >> 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] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by StÃ©phane Ducasse

>>> >> >> :) 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. > > Mmm, well, if you rely on full Compiler to parse literals, it is a security problem. But if you use the technique Igor showed to only parse array literals - then yes, that's safe, I agree. I forgot about his post. Parsing and compiling + execution are three different actions. Parsing: stream -> tokens* but you know it. >>> - 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 > > I presume you are describing various conventions/tricks to represent a Dictionary in a literal array, right? > > My point is that it would be nice if we actually had proper syntax for Associations (and or Dictionaries). OK I see. But what I want to say is that then this is not a literal array anymore. Literal means that you only need a parser and no execution to get the information. Parse time. Now I would like to know the use case for a dictionary syntax or association. May be you mean that you want to have the equivalent of { } but for dictionary, why not. Having a syntax for a syntax is not really exciting. Now I think that the key problem is dealing with reference between elements. for that STON can be better because why stopping at dictionary? But then the next question if we go down this road is why don't we add this syntax to smalltalk so that we can create literals objects like in Javascript. I mean without message send because this is exactly that no? What is the difference between Dictionary new add: #flop put: 33 ;yourself and {|% flop : 33 %|} or Person { name : 'stef' } then this is not really Smalltalk anymore and we cannot say that we only have messages and the parser and â¦. have to be changedâ¦. This is why I asked what is the use case. Finally and I still did not get a clear answer: why there is a need for dictionary syntax to store method meta data. Ok if you need a ***syntax*** then this is another requirement. Stef

May 8, 2012

Re: [Pharo-project] Nautilus load problem

by Benjamin

I will try to maintain Nautilus for 1.4 as long as I can, but we have all to keep in mind that now the main goal for Nautilus is to make it the default browser for 2.0. So obviously, I will focus more on the integration in 2.0. But as long as we fix the system and make Nautilus work on it (as an example, the last PluggableListMorph changes) it means that Nautilus for 1.4 and Nautilus for 2.0 are different. But for more Nautilus related bugs, I will try to fix them in both :) Let's hope I can manage to do that ^^ Ben On May 8, 2012, at 7:11 PM, StÃ©phane Ducasse wrote: > > 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] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by GÃ¶ran Krampe

On 05/08/2012 09:01 PM, StÃ©phane Ducasse wrote: > > 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. Mmm, well, if you rely on full Compiler to parse literals, it is a security problem. But if you use the technique Igor showed to only parse array literals - then yes, that's safe, I agree. I forgot about his post. >> - 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 I presume you are describing various conventions/tricks to represent a Dictionary in a literal array, right? My point is that it would be nice if we actually had proper syntax for Associations (and or Dictionaries). regards, GÃ¶ran

May 8, 2012

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

by Dale Henrichs

Stef, To me your argument is equivalent to saying "we've got nails why do we need screws"...Where ever you use a screw you should be able to use a nail right? But screws have slightly different characteristics than nails and when those characteristics are called for you use a screw instead of a nail... right? STON, JSON, Tirade and literal arrays all perform the same basic function, but each have slightly different characteristics that make one better for some tasks and another better for other tasks ... right? 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 12:03:18 PM | Subject: Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation) | | | On May 8, 2012, at 8:32 PM, Dale Henrichs wrote: | | > :):):) for the correct definition of "works" I agree :):):) | | sorry but I did not get it funny at all. | But if you laugh even better. So far I do not understand but I'm | probably an idiot understand | why we need dictionary syntax. But again this should be that I'm | totally dull on that topics. | So I will not read mails about this topic anymore. | Too bad may be people could have gained from my idiot views. | | Stef | | > | > 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] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by StÃ©phane Ducasse

On May 8, 2012, at 8:32 PM, Dale Henrichs wrote: > :):):) for the correct definition of "works" I agree :):):) sorry but I did not get it funny at all. But if you laugh even better. So far I do not understand but I'm probably an idiot understand why we need dictionary syntax. But again this should be that I'm totally dull on that topics. So I will not read mails about this topic anymore. Too bad may be people could have gained from my idiot views. Stef > > 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] 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