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

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by StÃ©phane Ducasse

Sven/Igor what is the difference with STON syntax? Stef

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by StÃ©phane Ducasse

Well we started with ezequiel to work on that. We took a look at Deltas: - any change is revertible and keeps it changes Ezequiel was planning to show to the group what he has friday but we were busy. he will show us that tomorrow. Now I would really like that we do not have hack change set, whateverâ¦. But write something new aside. And in addition I would like that we FINISH what we are doing before opening new projects. Stef On Oct 21, 2012, at 3:39 PM, Mariano Martinez Peck wrote: > > > On Sun, Oct 21, 2012 at 3:17 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 21, 2012, at 3:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > > > > On Sun, Oct 21, 2012 at 2:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 21 October 2012 13:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > Hello > > > > > > > > > 2012/10/21 Igor Stasenko <siguctua(a)gmail.com> > > >> > > >> i now modelling a system logger (to replace .changes file), and since > > >> i having no better idea, > > >> i'll try to use object literals for it. > > > > > > > > > Do you see Deltas project? > > > > Sure i know about deltas. I was hacking it. :) > > > > > I think one of the proposals was .changes file replacement > > > > not exactly. it is more changeset replacement. > > What i am doing is a bit orthogonal: it is a facility to recover lost changes. > > All of the sources will be held inside image. > > > > > > But one very common case to recover lost changes is when the image is broken... so if you store the stuff in the image... > > > The .changes right now has two duties > > 1) Be a log in case of crash. Like a transaction log in a database... > 2) the place where the sourcecode is because it is oh so large. > > So I vote for splitting "where source is stored" from the transaction log. > > The log file then will be just a log. e.g. the image that you download: the log will be empty. > The log can be deleted at any point, it is just a log. > > > +99999999 > music to my ears. I have been dreaming with this since a log long time > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by StÃ©phane Ducasse

> > i now modelling a system logger (to replace .changes file), and since > i having no better idea, > i'll try to use object literals for it. Igor do not open too many projects :). Please finish the others. We want athens We are working on that with ezequiel and martin will probably help to get started with his phd. It would be good if we could get rid of the ! !! delimiters for now ezequiel is just strong fuel objects but indeed having a textual format can be really important. Note that we will probably want to store complete refactorings so that we can reapply a logical changes or a set of physical modifications. Stef > > The idea is to preserve chunk format, but use object-literals for > meta-information: > > logEntryExamples > #(Method: ClassName instance "or class" 'category' 'author' > (DateAndTime 'xxx') 'priorsourceId' ). > #(TraitMethod: TraitName instance "or class" 'category' 'author' > (DateAndTime 'xxx') 'priorsourceId' ). > #(DoIt: 'author' (DateAndTime 'xxx') ). > #(ClassComment: ClassName 'author' (DateAndTime 'xxx') 'priorsourceId' ). > > So, in log, it will look like: > > !#(Method: Object instance 'testing' 'Super Mario' (DateAndTime ' > 2012-10-21T11:30:03.892+02:00') 'abra-ka-da-br-a' )! > testSequenceIfNotEmptyDo > > self empty ifNotEmptyDo: [:s | self assert: false]. > self assert: (self nonEmpty ifNotEmptyDo: [:s | self > accessValuePutInOn: s]) = self valuePutIn > ! ! > > Note the colon ':' in first literal. This is to prevent collision with > any existing (and future) class name. > As i suggested earlier, obj-literal can have name resolution logic in > front of basic one - (Smalltalk at: name) > and of course, there must be an extension mechanism, which can > register own resolvers. > > I think it would be easy to extend chunk reading logic to detect that > meta information stored as object-literal. > Searching whole .sources file, i found only one occurrence of '!#' sequence > and zero '!#(' > > If i do: > > '#( 1 2 3) yourself' in workspace, it writes: > > ! > > #(1 3 4 ) yourself! > > (an empty line between ! and #( ) > > > > -- > Best regards, > Igor Stasenko. >

Oct. 21, 2012

Re: [Pharo-project] Smart chars behavior

by StÃ©phane Ducasse

I was analyzing my frustration when I tyed since the email and I think that 90% of my problems are related to the space handling ie writiing () on when the (is not close to a character On Oct 21, 2012, at 2:46 PM, Guillermo Polito wrote: > > On Oct 19, 2012 10:29 PM, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > > > > > > > > > > ws contents: '|foo'' > > > type: $' > > > expected: ''|foo'' > > > current: '''|foo'' > > > > and then usually I have to remove the fucking extra ' that the system just blindly added :( > > This should be the same Damien pointed out for parenthesis :) > > Anyone else? I remember many complains on the subject... > > > > > Stef > > > >

Oct. 21, 2012

Re: [Pharo-project] Group metacello question

by StÃ©phane Ducasse

Ok thanks so what I wrote is correct and I should finish the configuration I'm writing - I got distracted by a bath tube that I had to destroy :) Stef > Stef, > > Yes... the specifications from each section are merged in order to produce the final set of specifications: > > for: #common do: [ > spec: 'package' with: [ > spec repository: 'http://example.com/repo' ]]. > for: #pharo do: [ > spec: 'package' with: [ > spec file: 'package.pharo-dkh.1' ]]. > for: #squeak do: [ > spec: 'package' with: [ > spec file: 'package.squeak-dkh.1' ]]. > > with the attributes #(common pharo) it resolves to: > > spec: 'package' with: [ > spec > file: 'package.pharo-dkh.1'; > repository: 'http://example.com/repo' ]. > > with the attributes #(common pharo) it resolves to: > > spec: 'package' with: [ > spec > file: 'package.squeak-dkh.1'; > repository: 'http://example.com/repo' ]. > > with the attributes #(common gemstone) it resolves to: > > spec: 'package' with: [ > spec repository: 'http://example.com/repo' ]. > > > and so on... > > Dale > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Saturday, October 20, 2012 2:10:03 PM > | Subject: Re: [Pharo-project] Group metacello question > | > | Hi dale > | > | it is correct that > | > | common > | squeakcommon > | pharo > | then pharoxxx > | sections are loaded all together? > | > | Stef > | > I'm updating the chapter > | > > | > > | > \paragraph{Loading order.} > | > \sd{dale is it correct?} Notice that if you > | > in a system where the platform attributes are (\ct{#common} > | > \ct{#squeakCommon} \ct{#pharo} \ct{#'pharo2.x'} > | > \ct{#'pharo2.0.x'}) (you can obtain this information doing > | > \ct{ConfigurationOf project attributes}) and you have specified > | > three sections such as \ct{#common}, \ct{#pharo} and > | > \ct{#pharo2.0.x}, these sections will loaded one after the other. > | > > | > \begin{code}{} > | > ConfigurationOfCoolBrowser>>baseline09: spec > | > <version: '0.9-baseline'> > | > > | > !\textbf{spec for: \#common do: [}! > | > spec blessing: #baseline. > | > spec repository: 'http://www.example.com/CoolBrowser'. > | > > | > spec > | > package: 'CoolBrowser-Core'; > | > package: 'CoolBrowser-Tests' with: [ spec > | > requires: 'CoolBrowser-Core' ]; > | > package: 'CoolBrowser-Addons' with: [ spec > | > requires: 'CoolBrowser-Core' ]; > | > package: 'CoolBrowser-AddonsTests' with: [ > | > spec requires: #('CoolBrowser-Addons' > | > 'CoolBrowser-Tests' ) ]. > | > spec > | > group: 'default' with: #('CoolBrowser-Core' > | > 'CoolBrowser-Addons' ); > | > group: 'Core' with: #('CoolBrowser-Core' > | > 'CoolBrowser-Platform' ); > | > group: 'Extras' with: #('CoolBrowser-Addon'); > | > group: 'Tests' with: #('CoolBrowser-Tests' > | > 'CoolBrowser-AddonsTests' ); > | > group: 'CompleteWithoutTests' with: #('Core', > | > 'Extras' ); > | > group: 'CompleteWithTests' with: > | > #('CompleteWithoutTests', 'Tests' )]. > | > > | > !\textbf{spec for: \#gemstone do: [}! > | > spec package: 'CoolBrowser-Platform' with: > | > 'CoolBrowser-PlatformGemstone']. > | > !\textbf{spec for: \#pharo do: [}! > | > spec package: 'CoolBrowser-Platform' with: > | > 'CoolBrowser-PlatformPharo']. > | > !\textbf{spec for: \#pharo2.0.x do: [}! > | > spec package: 'CoolBrowser-Addons' with: > | > 'CoolBrowser-Core20']. > | > > | > \end{code} > | > > | > > | > | > | >

Oct. 21, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Frank Shearar

On 20 October 2012 20:52, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 20 October 2012 10:49, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> >> Ruby: {:foo => 1, :bar => 2} >> Clojure: {:foo 1 :bar 2} >> Python: {'foo': 1, 'bar': 2} >> > > That's it? I can add some more :) I'm sure. These are just the ones I knew off the top of my head. I was too lazy to look up ML, Haskell, etc. syntax. > This is interesting actually.. how hard you must try in attempt to > make it look sane and readable. > Dicts is quite complex data structure for describing in text. > > Another thing is , how often you need something more complex than > dictionary where keys and values is both simple values? (i am talking > about literals , of course). > > Dictionaries as keys? > Just out of practical reasons #hash and #= is quite expensive to > calculate for dictionary, > for using them as keys. > In my practice, using dictionary as key/values in another dictionary > (or any other object) having sense only when you use identity > dictionary (to serve as cache) but not within regular dictionary. > And again, cache is usually constructed dynamically, not from literal(s). > > Also, how often you need more than two levels of nesting for > describing literal data structure? > Because, even if you will have nice syntax to denote dicts vs arrays vs lists, > if you start nesting them deeply, at some point you will find that it > is no longer readable, > because you will get lost in > [{() }]} maze very soon. > > And for shallow hierarchies, distinct syntax is not really important. > > >> frank >> >>> I do not see a need in having separate syntax for dictionary. >>> Because this goes to nowhere in form of never-ending story: >>> - tomorrow i want syntactic sugar for Sets >> >> Because with syntax for lists and dictionaries you can roll any kind >> of literal you might care for. >> >>> - then for Colors >> >> A dictionary with keys of 'r', 'g' and 'b', Or 'c', 'm', 'y', 'k'. Or >> anything else. >> > how you determine that this is Color but not dictionary which coincidentally has > same keys? There's a difference? :) I mean that only half in jest: it's idiomatic Clojure to do just this (use dictionaries to store structured data with named parts), and that's how CLOS works too. The only difference between the dictionary and the object is that the object also has keys pointing to methods. Most of the time though the source and target of the literal both have the same behaviour so there's not much need for transporting the methods. And you'd need much more machinery (well beyond the scope of this bikeshed) to permit the safe sending of data+code - capabilities, sandboxing, ... frank >>> - then for Points, Rectangles and Circles >> >> A dictionary with 'x' and 'y' keys (or 'rho' and 'theta'), a list of >> four dictionaries (for the points), and a list with two dictionaries >> for the points. >> > same again, list with 'x' and 'y' is not Point > list with 4 dictionaries is not Rectangle etc. > >>> ... >>> - and Pink Elephants >>> >>> one of the reasons, why i like smalltalk syntax, is small grammar, >>> minimal syntactic constructs, >>> yet high expressive power. >>> Smalltalk (and LISP) is a good demonstration that massive set of >>> different syntax sugars/rules and expressive power are not correlating >>> values. >> >> Ah, but it's precisely Lisp's uniformity in appearance that trips >> people up. And that's precisely why in Clojure a list is (1 2 3), a >> vector is [1 2 3] and a dictionary is {:a 1 :b 2} - different things >> are visually distinct. >> >> You don't need a _lot_ of difference, because a little goes a long way. >> >> frank > > -- > Best regards, > Igor Stasenko. >

Oct. 21, 2012

Re: [Pharo-project] For the Emacs fans: Shampoo

by Frank Shearar

On 20 October 2012 20:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > Begin forwarded message: > >> Subject: [Lsehub-staff] For the Emacs fans: Shampoo >> Date: October 20, 2012 9:45:14 PM GMT+02:00 >> >> http://dmitrymatveev.co.uk/shampoo/ Thanks, Marcus! I'm now torn between being happy that someone wrote such a thing, and being sad that I didn't write such a thing (first). And it's MIT-licenced! frank > -- > Marcus Denker -- http://marcusdenker.de > >

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by Mariano Martinez Peck

On Sun, Oct 21, 2012 at 3:17 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Oct 21, 2012, at 3:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > > On Sun, Oct 21, 2012 at 2:38 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > On 21 October 2012 13:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > Hello > > > > > > > > > 2012/10/21 Igor Stasenko <siguctua(a)gmail.com> > > >> > > >> i now modelling a system logger (to replace .changes file), and since > > >> i having no better idea, > > >> i'll try to use object literals for it. > > > > > > > > > Do you see Deltas project? > > > > Sure i know about deltas. I was hacking it. :) > > > > > I think one of the proposals was .changes file replacement > > > > not exactly. it is more changeset replacement. > > What i am doing is a bit orthogonal: it is a facility to recover lost > changes. > > All of the sources will be held inside image. > > > > > > But one very common case to recover lost changes is when the image is > broken... so if you store the stuff in the image... > > > The .changes right now has two duties > > 1) Be a log in case of crash. Like a transaction log in a database... > 2) the place where the sourcecode is because it is oh so large. > > So I vote for splitting "where source is stored" from the transaction log. > > The log file then will be just a log. e.g. the image that you download: > the log will be empty. > The log can be deleted at any point, it is just a log. > > +99999999 music to my ears. I have been dreaming with this since a log long time > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Mariano http://marianopeck.wordpress.com

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by Marcus Denker

On Oct 21, 2012, at 3:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Oct 21, 2012 at 2:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 October 2012 13:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello > > > > > > 2012/10/21 Igor Stasenko <siguctua(a)gmail.com> > >> > >> i now modelling a system logger (to replace .changes file), and since > >> i having no better idea, > >> i'll try to use object literals for it. > > > > > > Do you see Deltas project? > > Sure i know about deltas. I was hacking it. :) > > > I think one of the proposals was .changes file replacement > > not exactly. it is more changeset replacement. > What i am doing is a bit orthogonal: it is a facility to recover lost changes. > All of the sources will be held inside image. > > > But one very common case to recover lost changes is when the image is broken... so if you store the stuff in the image... > The .changes right now has two duties 1) Be a log in case of crash. Like a transaction log in a database... 2) the place where the sourcecode is because it is oh so large. So I vote for splitting "where source is stored" from the transaction log. The log file then will be just a log. e.g. the image that you download: the log will be empty. The log can be deleted at any point, it is just a log. Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by Sven Van Caekenberghe

On 21 Oct 2012, at 11:53, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 October 2012 10:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Yes, something is wrong with the ObjectLiterals repository on SmalltalkHub, but I have no clue what. >> >> I made a copy in another place >> >> http://mc.stfx.eu/ObjectLiterals >> > hmm.. how i can download it? when i press a link in browser it asks me for username/password? It worked/works fine when you define a regular Monticello repository on it: MCHttpRepository location: 'http://mc.stfx.eu/ObjectLiterals' user: '' password: '' There was indeed an error in the generated HTML that only affect humans clicking the link, I fixed it. Sorry about that. >> @Dale >> >> Of course ObjectLiteralsParser, is completely independent of any other code, that is the whole idea. >> And it is very small as well, it should be portable to any Smalltalk. >> >> @Igor >> >> The Symbol and Number syntax accepted by ObjectLiteralsParser is artificially limited right now, as it was copied from STON. As long as it is a proper subset of Smalltalk that does not strike me as a problem. >> >> Anyway, the goal of the code is to allow for a more precise discussion. >> >

Oct. 21, 2012