July 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Iceberg 0.5 released

by Esteban Lorenzano

> On 3 Jul 2017, at 13:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi all, > Iâm releasing 0.5 version of iceberg. > This is the changelog: > > Major changes: > ---- > - works on 64bits > - adds cheery-pick > > Other: > ---- > This version also includes a list of fixes, most important one is this: > > - branchs are kept inline with local working copy (so if you change a branch in command line or in another image it will indicate it correctly) > > But there are many others, next version will have a full list, I promise :) > > Now, to actually use it you will need to accomplish several steps (until I update the image) > > 1) You need to download the new stable VM for P7 (it does not matters if you are on P6). > Zeroconf: > > 64bits: > wget -O- get.pharo.org/64/vm70 <http://get.pharo.org/vm70> | bash > wget -O- get.pharo.org/ <http://get.pharo.org/vm70>64/ <http://get.pharo.org/vm70>vmT70 <http://get.pharo.org/vm70> | bash #If you are on linux > > 32bits: > wget -O- get.pharo.org/vm70 <http://get.pharo.org/vm70> | bash > wget -O- get.pharo.org/vmT70 <http://get.pharo.org/vm70> | bash #If you are on linux > > then, to update, execute this (sorry, this is like that because we have still an older Metacello version): > > #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration' 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core' 'BaselineOfLibGitâ) > do: [ :each | each asPackage removeFromSystem ]. > > Metacello new > baseline: 'Iceberg'; > repository: 'github://pharo-vcs/iceberg <github://pharo-vcs/iceberg>'; > load. Maybe I was not clearâ¦ this script works also for P6 (*if * you have the new VM) :) > > cheers! > Esteban

July 3, 2017

[ANN] Iceberg 0.5 released

by Esteban Lorenzano

Hi all, Iâm releasing 0.5 version of iceberg. This is the changelog: Major changes: ---- - works on 64bits - adds cheery-pick Other: ---- This version also includes a list of fixes, most important one is this: - branchs are kept inline with local working copy (so if you change a branch in command line or in another image it will indicate it correctly) But there are many others, next version will have a full list, I promise :) Now, to actually use it you will need to accomplish several steps (until I update the image) 1) You need to download the new stable VM for P7 (it does not matters if you are on P6). Zeroconf: 64bits: wget -O- get.pharo.org/64/vm70 <http://get.pharo.org/vm70> | bash wget -O- get.pharo.org/ <http://get.pharo.org/vm70>64/ <http://get.pharo.org/vm70>vmT70 <http://get.pharo.org/vm70> | bash #If you are on linux 32bits: wget -O- get.pharo.org/vm70 <http://get.pharo.org/vm70> | bash wget -O- get.pharo.org/vmT70 <http://get.pharo.org/vm70> | bash #If you are on linux then, to update, execute this (sorry, this is like that because we have still an older Metacello version): #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration' 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core' 'BaselineOfLibGitâ) do: [ :each | each asPackage removeFromSystem ]. Metacello new baseline: 'Iceberg'; repository: 'github://pharo-vcs/iceberg'; load. cheers! Esteban

July 3, 2017

[ANN] New stable VM for P7

by Esteban Lorenzano

Hi all, I declared a new stable VM for Pharo 7. This VM includes a new version of libgit2 and because of that *it cannot be used on Pharo 6 (if you are using Iceberg)* Just that :) cheers! Esteban

July 3, 2017

Re: [Pharo-dev] Pharo Launcher

by Serge Stinckwich

On Thu, Jun 29, 2017 at 2:32 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > where can I find the pharo launcher for the latest version of Pharo? > > âI'm still fighting to use Pharo Launcher in Cameroon with very low bandwidth ... Most of the time I have an error: can't find EOCD position. What is the meaning of this error ? a latency problem ? â Stef > > -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 3, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Christian Haider

I did Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Serge Stinckwich Gesendet: Montag, 3. Juli 2017 11:40 An: Pharo Development List <pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Hi Christian, interesting ! Maybe you can release your software with an MIT licence ? Regards, On Mon, Jul 3, 2017 at 10:06 AM, Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com> > wrote: I solved this with Values[1] for VW and I am very happy with it (using it intensively/routinely). Your example would look like: (PointCollection points: (Array with: (Point x: 10 y: 20) with: (Point x: 5 y: 8) )) As you see, it is the same except that lots of noise is gone. Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic structures (same with JSON etc.) and the order of arguments is fixed unlike JSON (but you can add constructors for every permutation :)). I think this is very clear and direct (no magic from parsers etc.). I like it most for configurations (see everything at a glance) and interface data. Best, Christian [1] https://wiki.pdftalk.de/doku.php?id=complexvalues Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org> ] Im Auftrag von Norbert Hartl Gesendet: Montag, 3. Juli 2017 10:28 An: Pharo Dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Eliot, Am 01.07.2017 um 20:22 schrieb Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com> >: Hi Norbert, On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> > wrote: Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com> >: But what is DataFrame? the new collection done by alesnedr from Lviv. It is really nice but does not solve the problem of the compact syntax. STON fromString: 'Point[10,20]' Same goes for JSON. We were brainstorming with marcus and we could have a first nice extension: { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. 10@20 Now in addition I think that there is a value in having an object literal syntax. I pasted the old mail of igor on object literals because I like the idea since it does not add any change in the parser. Do you remember what were the problem raised by this solution (beside the fact that it had too many # and the order was like in ston not explicit). I would love to have another pass on the idea of Igor. What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. Indeed this is why { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. could be more robust. We could extend the object literal syntax to use association for non collection. I think it is more robust and more explicit. I do not know what are the semantics of detecting something as #Point being a class name. Is it then forbidden to use symbols with uppercase letters? I think something like { #x -> 10 . #y -> 20} asObjectOf: #Point is handling the format with implicit knowledge of type. While the explicit version would be { #Point -> { #x -> 10 . #y -> 20}} asObject And then nested objects are as easy as {#PointCollection -> { #points -> { {#Point -> { #x -> 10 . #y -> 20} }. {#Point -> { #x -> 5 . #y -> 8} } } } asObject The -> messages are just noise and add additional processing for nothing. This is just as effective: { #Point. { #x. 10 . #y. 20}} asObject {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. {#Point. { #x. 5 . #y. 8} } } } asObject So an object is a pair of a class name and an array of slot specifier pairs, and a slot specifier is a pair of a slot band and a value. And of course that means that many object specs can be literal, which is useful for storing in pragmas etc: #(PointCollection (points ((Point (x 10 y 20)) ((Point (x 5 y 8)))) asObject Agreed. My first impression was it should be something like S-expression which your example is. I was misled by the idea it should be closer to the programming syntax. But a parser does not care if implemented properly, that's right. I like the compactness of that format but still find it a bit hard to read if there is only pairs. As this object literal syntax is meant to be written in code it is important that it reads well even if there are noisy characters. would give a PointCollection of two point objects. My future wish would be that there is an object literal parser that takes all of the information from the format. And then a object literal parser that is aware of slot information. Meaning that the type information can be gathered from the object class instead having it to write in the format. In the PointCollection the slot for points would have the type information #Point attached. The format goes then to { #points -> { { #x -> 10 . #y -> 20 }. { #x -> 5 . #y -> 8 } } which would then the equivalent to something like JSON { "points" : [ { "x" : 10, "y" : 20 }, { "x" : 5, "y" : 8 } ] } What I don't know is how to solve the difference between a dictionary and an collection of associations. That's incidental to the format, internal to the parser. If the parser chooses to build a dictionary as it parses so be it. The point is that the output is as you specify; a tree of objects. The thing to think about is how to introduce labels so that sub objects can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. I'm not sure this is necessary. It should be a format to easily instantiate a small tree of objects. Making it build a graph instead of a tree makes everything much more complicated. Either we decide that STON can do the full set and in that case it is probably less valuable to have a simple syntax to write in code. Or we need to break pairs rule. In that case an object definition can have an optional third argument which would be the label for the object. The draback is that the label needs to be before the array of slots { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} Or something like this. It would be in theory closer to STON using the @ reference. The difference is that STON has indexed object access and that variant would make it based on labels.Or something like this. Norbert Norbert As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. Yes after we should focus on the frequent cases. And may be having a literal syntax for dictionary would be good enough. I will do another version of igor's proposal with associations to see how it feels. my 2 cents, Norbert Stef ---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com> > Date: Fri, Oct 19, 2012 at 1:09 PM Subject: [Pharo-project] Yet another Notation format: Object literals To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> > Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that). The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example: (1@3) asObjectLiteral --> #(#Point 1 3) { 1@2. 3@4. true. false . nil } asObjectLiteral -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') Next thing, you can 'pretty-print' it (kinda): #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' and sure thing, you can do reverse conversion: '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral a Dictionary('foo'->'bar' 1->#(1 2 3) ) Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course. The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there. Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project.. So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project. -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 3, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Serge Stinckwich

Hi Christian, interesting ! Maybe you can release your software with an MIT licence ? Regards, On Mon, Jul 3, 2017 at 10:06 AM, Christian Haider < christian.haider(a)smalltalked-visuals.com> wrote: > I solved this with Values[1] for VW and I am very happy with it (using it > intensively/routinely). > > Your example would look like: > > > > (PointCollection points: (Array > > with: (Point x: 10 y: 20) > > with: (Point x: 5 y: 8) > > )) > > > > As you see, it is the same except that lots of noise is gone. > > Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic > structures (same with JSON etc.) > > and the order of arguments is fixed unlike JSON (but you can add > constructors for every permutation J). > > > > I think this is very clear and direct (no magic from parsers etc.). I like > it most for configurations (see everything at a glance) and interface data. > > > > Best, > > Christian > > > > [1] https://wiki.pdftalk.de/doku.php?id=complexvalues > > > > *Von:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *Im Auftrag > von *Norbert Hartl > *Gesendet:* Montag, 3. Juli 2017 10:28 > *An:* Pharo Dev <pharo-dev(a)lists.pharo.org> > *Betreff:* Re: [Pharo-dev] Reflecting on data (literal) object syntax > > > > Eliot, > > > > Am 01.07.2017 um 20:22 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > Hi Norbert, > > > > On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > But what is DataFrame? > > > the new collection done by alesnedr from Lviv. It is really nice but > does not solve the problem of the compact syntax. > > > > STON fromString: 'Point[10,20]' > > Same goes for JSON. > > > We were brainstorming with marcus and we could have a first nice extension: > > { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. > > 10@20 > > > Now in addition I think that there is a value in having an object > literal syntax. > > I pasted the old mail of igor on object literals because I like the > idea since it does not add any change in the parser. > Do you remember what were the problem raised by this solution (beside > the fact that it had too many # and the order was like in ston not > explicit). > > I would love to have another pass on the idea of Igor. > > > What I don't like about it is that the object literal exposes the internal > implementation of the object. Everything is based on index. So it could > suffer the same problem as fuel. When you don't have the exact same code > the deserialization fails. > > > Indeed this is why > { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. > could be more robust. > We could extend the object literal syntax to use association for non > collection. > > I think it is more robust and more explicit. I do not know what are the > semantics of detecting something as #Point being a class name. Is it then > forbidden to use symbols with uppercase letters? I think something like > > { #x -> 10 . #y -> 20} asObjectOf: #Point > > is handling the format with implicit knowledge of type. While the explicit > version would be > > { #Point -> { #x -> 10 . #y -> 20}} asObject > > And then nested objects are as easy as > > {#PointCollection -> { > #points -> { {#Point -> { #x -> 10 . #y -> 20} }. > {#Point -> { #x -> 5 . #y -> 8} } } } asObject > > > The -> messages are just noise and add additional processing for nothing. > This is just as effective: > > { #Point. { #x. 10 . #y. 20}} asObject > > {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. > {#Point. { #x. 5 . #y. 8} } } } asObject > > So an object is a pair of a class name and an array of slot specifier > pairs, and a slot specifier is a pair of a slot band and a value. And of > course that means that many object specs can be literal, which is useful > for storing in pragmas etc: > > #(PointCollection > (points ((Point (x 10 y 20)) > ((Point (x 5 y 8)))) asObject > > Agreed. My first impression was it should be something like S-expression > which your example is. I was misled by the idea it should be closer to the > programming syntax. But a parser does not care if implemented properly, > that's right. I like the compactness of that format but still find it a bit > hard to read if there is only pairs. As this object literal syntax is meant > to be written in code it is important that it reads well even if there are > noisy characters. > > > would give a PointCollection of two point objects. My future wish would be > that there is an object literal parser that takes all of the information > from the format. And then a object literal parser that is aware of slot > information. Meaning that the type information can be gathered from the > object class instead having it to write in the format. In the > PointCollection the slot for points would have the type information #Point > attached. The format goes then to > > { #points -> { > { #x -> 10 . #y -> 20 }. > { #x -> 5 . #y -> 8 } } > > which would then the equivalent to something like JSON > > { "points" : [ > { "x" : 10, "y" : 20 }, > { "x" : 5, "y" : 8 } ] } > > What I don't know is how to solve the difference between a dictionary and > an collection of associations. > > > That's incidental to the format, internal to the parser. If the parser > chooses to build a dictionary as it parses so be it. The point is that the > output is as you specify; a tree of objects. > > The thing to think about is how to introduce labels so that sub objects > can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. > > > > I'm not sure this is necessary. It should be a format to easily > instantiate a small tree of objects. Making it build a graph instead of a > tree makes everything much more complicated. Either we decide that STON can > do the full set and in that case it is probably less valuable to have a > simple syntax to write in code. Or we need to break pairs rule. In that > case an object definition can have an optional third argument which would > be the label for the object. The draback is that the label needs to be > before the array of slots > > > > { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} > > > > Or something like this. It would be in theory closer to STON using the @ > reference. The difference is that STON has indexed object access and that > variant would make it based on labels.Or something like this. > > > > Norbert > > > > > > > Norbert > > > > > As a dictionary is both, an array of associations and a key-value store, > it works perfectly there. But for other objects I have doubts. Especially > is in a lot of contexts you need to have a mapping of internal state to > external representation. It can be applied afterwards but I'm not sure that > can work all the time. > > > Yes after we should focus on the frequent cases. And may be having a > literal syntax for dictionary would be good enough. > > I will do another version of igor's proposal with associations to see > how it feels. > > > > my 2 cents, > > Norbert > > > > Stef > > > > > ---------- Forwarded message ---------- > From: Igor Stasenko <siguctua(a)gmail.com> > Date: Fri, Oct 19, 2012 at 1:09 PM > Subject: [Pharo-project] Yet another Notation format: Object literals > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > > > Hi, > as i promised before, here the simple smalltalk-based literal format. > It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to > have separate parser (a normal smalltalk parser used for that). > > The idea is quite simple: > you can tell any object to represent itself as an 'object literal' , > for example: > > (1@3) asObjectLiteral > --> #(#Point 1 3) > > { 1@2. 3@4. true. false . nil } asObjectLiteral > > -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) > > (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral > -> > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') > > Next thing, you can 'pretty-print' it (kinda): > > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' > > > and sure thing, you can do reverse conversion: > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' parseAsObjectLiteral > > a Dictionary('foo'->'bar' 1->#(1 2 3) ) > > Initially, i thought that it could be generic (by implementing default > Object>>#asObjectLiteral), > but then after discussing it with others, we decided to leave > > Object>>#asObjectLiteral to be a subclass responsibility. > So, potentially the format allows to represent any object(s) as > literals, except from circular referencing objects, of course. > > The implementation is fairly simple, as you may guess and contains no > new classes, but just extension methods here and there. > > Take it with grain and salt, since it is just a small proof of > concept. (And if doing it for real it may need some changes etc). > Since i am far from areas right now, where it can be used, i don't > want to pursue it further or advocate if this is the right way to do > things. > Neither i having a public repository for this project.. > > So, if there anyone who willing to pick it up and pursue the idea > further, please feel free to do so and make a public repository for > project. > > > -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 3, 2017

Re: [Pharo-dev] git, packages, and package dependencies (also migration from sthub to git)

by Luke Gorrie

On 3 July 2017 at 11:09, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > People are already complaining (for whatever reason that I do not > understand) that git is too complex. And doing this kind of shenanigans > with branches will certainly add extra complexity. Could be simpler to think of it as each package having a separate repository with an independent history. Then you cannot have any conflicts from one package on another. This is equivalent to Monticello, right? Then if you want to combine multiple packages together then you would create a new repo that merges each package that you care about. Once you update packages this repo could either be updated (add more merge commits) or replaced (recreate from scratch with the versions you really want.) This is equivalent to Metacello, right? The orphan commit trick is then simply a way to multiplex as many "logical" repos (for Monticello packages or Metacello configurations) into the same actual Git repo (as branches with separate roots.) However -- Can still be that I am misunderstanding the overall goal here. Or maybe I am really overthinking this and nobody actually cares about > proper migration of their history. :) > One thing that I care about, and am a bit surprised that nobody else apparently cares about (?), is being able to snapshot all sources/dependencies in one file/directory/repo/etc that can be loaded from a local file without crawling the internet. Could importing projects into a Git repo that Metacello accesses be a solution? (Or is there already a way today that I am missing?)

July 3, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Serge Stinckwich

On Fri, Jun 30, 2017 at 11:03 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > recently I started to read a book on machine learning and they > manipulate dictionary of dictionary. (So I started my own > implementation and I will switch to DataFrame). > > Now it occurred to me that when we program complex objects we do not > need a compact literal syntax for our objects. But when we manipulate > data objects it is super handy. > > I ended up doing a lot of > > self new > addRow: 'Claudia Puig' > withTaggedValues: > {('Snakes on a Plane' -> 3.5). ('Just My Luck' -> 3.0). > ('The Night Listener' -> 4.5). ('Superman Returns' -> 4.0). ('You, Me > and Dupree' -> 2.5)}. > > And I was not in the mood to write a class for the taggedValues and > writing a class would not have really help me. > > > Now we also have STON but STON is not yet part of the language > grammar. So we have to have an explicit conversion call. > > STON fromString: 'Point[10,20]' > > We were brainstorming with marcus and we could have a first nice extension: > > { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. > >>> 10@20 > > Now in addition I think that there is a value in having an object > literal syntax. > > I pasted the old mail of igor on object literals because I like the > idea since it does not add any change in the parser. > Do you remember what were the problem raised by this solution (beside > the fact that it had too many # and the order was like in ston not > explicit). > > I would love to have another pass on the idea of Igor. > > âThank you StÃ©phane for having this kind of discussion. This is quite important to have a compact literal notations for tables or dataframes in Pharo, if we want to be able to manipulate data like they are doing in Python or R. I'm not sure we should have a literal notations for all kind of objects. -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 3, 2017

Re: [Pharo-dev] git, packages, and package dependencies (also migration from sthub to git)

by Peter Uhnak

Hi Luke, On Sat, Jul 01, 2017 at 03:43:35PM +0200, Luke Gorrie wrote: > > > In mcz/monticello, every package has an independent history and can change > > independently of each other. > > In git, this history is merged into a single hierarchy, therefore: > > > > Git does not strictly require you to put all of your commits into a single > hierarchy. You can also have multiple root commits in the same repository > i.e. multiple parallel hierarchies of commits. Then you can combine these > together with merge commits if/when you want to have them in the same tree > (afaik.) > > See 'git commit --orphan' for introducing a new root commit into the repo. I don't really see a difference between having orphaned branches and regular branches starting from the initial commit. > > So thinking aloud... > > Perhaps for each package could you create a dedicated branch (A, B, ...) > with its own root commit? This way each package would have a distinct > history on its private branch and not be prone to collisions. If you want > to combine multiple packages into one tree then you could create a new > branch (A+B) that merges the required per-package branches (which remain > isolated and pristine.) > > Just an idea -- sorry if I have misunderstood your use case, and let me > know if this idea requires more explanation. I do understand what you have in mind, however one aspect I didn't mention is usability. People are already complaining (for whatever reason that I do not understand) that git is too complex. And doing this kind of shenanigans with branches will certainly add extra complexity. Also as I've mentioned neither of workflows (MCZ or git) are best. With git having packages depend on commits of another packages can be a good thing (because realistically packages in a project do depend on each other). But maybe a solution for migration itself would be to strictly separate the package histories, and then in master branch perform merges based on ConfigurationOf versions... and the last commit on master would merge all the branches according the the current dev state. Or maybe I am really overthinking this and nobody actually cares about proper migration of their history. :) Peter > > Cheers, > -Luke

July 3, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Christian Haider

I solved this with Values[1] for VW and I am very happy with it (using it intensively/routinely). Your example would look like: (PointCollection points: (Array with: (Point x: 10 y: 20) with: (Point x: 5 y: 8) )) As you see, it is the same except that lots of noise is gone. Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic structures (same with JSON etc.) and the order of arguments is fixed unlike JSON (but you can add constructors for every permutation :)). I think this is very clear and direct (no magic from parsers etc.). I like it most for configurations (see everything at a glance) and interface data. Best, Christian [1] https://wiki.pdftalk.de/doku.php?id=complexvalues Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl Gesendet: Montag, 3. Juli 2017 10:28 An: Pharo Dev <pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Eliot, Am 01.07.2017 um 20:22 schrieb Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com> >: Hi Norbert, On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> > wrote: Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com> >: But what is DataFrame? the new collection done by alesnedr from Lviv. It is really nice but does not solve the problem of the compact syntax. STON fromString: 'Point[10,20]' Same goes for JSON. We were brainstorming with marcus and we could have a first nice extension: { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. 10@20 Now in addition I think that there is a value in having an object literal syntax. I pasted the old mail of igor on object literals because I like the idea since it does not add any change in the parser. Do you remember what were the problem raised by this solution (beside the fact that it had too many # and the order was like in ston not explicit). I would love to have another pass on the idea of Igor. What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. Indeed this is why { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. could be more robust. We could extend the object literal syntax to use association for non collection. I think it is more robust and more explicit. I do not know what are the semantics of detecting something as #Point being a class name. Is it then forbidden to use symbols with uppercase letters? I think something like { #x -> 10 . #y -> 20} asObjectOf: #Point is handling the format with implicit knowledge of type. While the explicit version would be { #Point -> { #x -> 10 . #y -> 20}} asObject And then nested objects are as easy as {#PointCollection -> { #points -> { {#Point -> { #x -> 10 . #y -> 20} }. {#Point -> { #x -> 5 . #y -> 8} } } } asObject The -> messages are just noise and add additional processing for nothing. This is just as effective: { #Point. { #x. 10 . #y. 20}} asObject {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. {#Point. { #x. 5 . #y. 8} } } } asObject So an object is a pair of a class name and an array of slot specifier pairs, and a slot specifier is a pair of a slot band and a value. And of course that means that many object specs can be literal, which is useful for storing in pragmas etc: #(PointCollection (points ((Point (x 10 y 20)) ((Point (x 5 y 8)))) asObject Agreed. My first impression was it should be something like S-expression which your example is. I was misled by the idea it should be closer to the programming syntax. But a parser does not care if implemented properly, that's right. I like the compactness of that format but still find it a bit hard to read if there is only pairs. As this object literal syntax is meant to be written in code it is important that it reads well even if there are noisy characters. would give a PointCollection of two point objects. My future wish would be that there is an object literal parser that takes all of the information from the format. And then a object literal parser that is aware of slot information. Meaning that the type information can be gathered from the object class instead having it to write in the format. In the PointCollection the slot for points would have the type information #Point attached. The format goes then to { #points -> { { #x -> 10 . #y -> 20 }. { #x -> 5 . #y -> 8 } } which would then the equivalent to something like JSON { "points" : [ { "x" : 10, "y" : 20 }, { "x" : 5, "y" : 8 } ] } What I don't know is how to solve the difference between a dictionary and an collection of associations. That's incidental to the format, internal to the parser. If the parser chooses to build a dictionary as it parses so be it. The point is that the output is as you specify; a tree of objects. The thing to think about is how to introduce labels so that sub objects can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. I'm not sure this is necessary. It should be a format to easily instantiate a small tree of objects. Making it build a graph instead of a tree makes everything much more complicated. Either we decide that STON can do the full set and in that case it is probably less valuable to have a simple syntax to write in code. Or we need to break pairs rule. In that case an object definition can have an optional third argument which would be the label for the object. The draback is that the label needs to be before the array of slots { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} Or something like this. It would be in theory closer to STON using the @ reference. The difference is that STON has indexed object access and that variant would make it based on labels.Or something like this. Norbert Norbert As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. Yes after we should focus on the frequent cases. And may be having a literal syntax for dictionary would be good enough. I will do another version of igor's proposal with associations to see how it feels. my 2 cents, Norbert Stef ---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com> > Date: Fri, Oct 19, 2012 at 1:09 PM Subject: [Pharo-project] Yet another Notation format: Object literals To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> > Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that). The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example: (1@3) asObjectLiteral --> #(#Point 1 3) { 1@2. 3@4. true. false . nil } asObjectLiteral -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') Next thing, you can 'pretty-print' it (kinda): #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' and sure thing, you can do reverse conversion: '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral a Dictionary('foo'->'bar' 1->#(1 2 3) ) Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course. The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there. Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project.. So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project.

July 3, 2017