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

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

by Stephane Ducasse

Yes I agree with Norbert. I will implement the proposal of eliot because it should be slight variation of what I implemented already. Christian we have immutable objects in Pharo and we plan to clean the system to use them more and more :) I hope that people will join to port your pdf framework from Gemstone to Pharo :). Stef On Tue, Jul 4, 2017 at 9:20 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Hi Christian, > > thanks for the explanation. I see that Values serve a different purpose. We > are looking for a compact form of object literal, the is not bound to the > external interface and does not need to be subclassed. > I'm interested how the printing of Values is different to #storeString. > > Norbert > > Am 04.07.2017 um 09:05 schrieb Christian Haider > <christian.haider(a)smalltalked-visuals.com>: > > Hi Norbert, > > yes, that is the point: it is a normal Smalltalk expression. > It is trivial and every Smalltalk understands it. > No need for special parsers; you just have class names and constructor > methods. > I believe this is a very compact and simple representation of Smalltalk > objects. > > The Values package contains mainly the machinery to print an object (aka > Value) as String so that it can be reconstructed from it. > Exactly like Smalltalk prints literal objects like Array, Integer, > Character, String, Symbol etc. > The superclass Value makes sure that the object tree (remember â no cycles > or references) will print properly (under consideration of namespaces). > Also, many âsimpleâ base objects can be turned into Values by implementing > constructors and the printer (like Date, Timestamp, Point, Rectangle, > ColorValue etc.). > > Additionally, Values allow to declare optional instVars, so that the > representation does not get too cluttered with boilerplate arguments. > In the dev tools, there is a generator which produces the proper > constructors (2**<number of defaults>). > > There is really not much to it, technically. Maybe it is just too simple. > I would be interested in the differences to the other proposals â what > should be achieved and what may be missing? > > HTH, > Christian > > Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von > Norbert Hartl > Gesendet: Dienstag, 4. Juli 2017 08:14 > An: Pharo Development List <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax > > Hi Christian, > > > Am 03.07.2017 um 11:06 schrieb Christian Haider > <christian.haider(a)smalltalked-visuals.com>: > > 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) > )) > > > I do not understand your point. Above is a normal smalltalk expression. I > skimmed through the Values document and I do not get how this is related to > a discussion about > compact object literal syntax. > Can you elaborate a bit more? How do Values help here? > > Norbert > > 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. > >

July 5, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Luke Gorrie

JFYI: My conclusion is that there is too much friction when building Pharo images under Nix. Nix and Pharo seem to make opposite trade-offs on the reproducibility-vs-convenience axis. Pharo hackers seem to expect a lot of freedom during builds, like unrestricted internet access, and that doesn't really fit with Nix's goal of referentially transparent builds. Damien Cassou tried to tell me that I was on the wrong track from the beginning but I was too stubborn to listen :). https://github.com/NixOS/nixpkgs/issues/21715#issuecomment-271239370 So I reckon that I will fall back to using two parallel build/CI systems. I'll build the Pharo images using Jenkins and then import them into Nix as binary blobs. This should work fine. Just means that I depend on two CI systems instead of one and I'll need to maintain my image builds using different tools that my other software builds. (I will stick with Nix for building the VM for now...) On 30 June 2017 at 14:27, Luke Gorrie <luke(a)snabb.co> wrote: > I have done some work on packaging up pharo projects for Nix so that > images can be created in the sandboxed build environment. I am a bit stuck > though. > > I have a script that takes a project named and creates a specification of > all the required mcz files, recursing into dependencies: > > Here is the spec for a small project, NeoJSON: > > [ > { name = "ConfigurationOfNeoJSON-SvenVanCaekenberghe.20"; > package = "ConfigurationOfNeoJSON-SvenVanCaekenberghe.20"; > url = "http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main/ > /ConfigurationOfNeoJSON-SvenVanCaekenberghe.20.mcz"; > sha256 = "0y5yqmb2hjfya2s4a8pkrz0q6pdm01vrfhvfj5knk6slgsy8c2my"; } > { name = "Neo-JSON-Core-SvenVanCaekenberghe.37"; > package = "Neo-JSON-Core-SvenVanCaekenberghe.37"; > url = "http://mc.stfx.eu/Neo/Neo-JSON-Core-SvenVanCaekenberghe. > 37.mcz"; > sha256 = "054hcp1lcriby5a8gpc54gcrd9agbpjv6f0n81bk7f091n9m01z0"; } > { name = "Neo-JSON-Tests-SvenVanCaekenberghe.36"; > package = "Neo-JSON-Tests-SvenVanCaekenberghe.36"; > url = "http://mc.stfx.eu/Neo/Neo-JSON-Tests- > SvenVanCaekenberghe.36.mcz"; > sha256 = "1c3nxi09l785npjypjmzcn5bhy5sswp1agj7pfqs640vg7l80l4k"; } > ] > > Nix then uses this to construct a package cache directory with a local > copy of each mcz file: > > $ ls -1 /nix/store/41jbwrsdpcvh684ll3qqk9lcfrrvxy59-pharo-package-cache/ > ConfigurationOfNeoJSON-SvenVanCaekenberghe.20.mcz > Neo-JSON-Core-SvenVanCaekenberghe.37.mcz > Neo-JSON-Tests-SvenVanCaekenberghe.36.mcz > > So this looks promising: I have all the code and should be able to load it > without using the network. > > However - I do in practice get an error when I try to do this. I guess > Metacello wants to access the network for some reasons I have not > anticipated. > > Here is my script: > > Metacello new > configuration: 'NeoJSON'; > cacheRepository: '/nix/store/rdy7wp3cx4z86wy537idkhjb0q70xz > jp-pharo-package-cache/'; > ignoreImage; > load. > Smalltalk saveAs: 'pharo'. > Smalltalk exitSuccess. > > and my Metacello error here: https://gist.github.com/lukego/ > ab105c257457e7b9a53f6378425df9a8 > > Any advice to make this work? > > (Could I perhaps bypass Metacello entirely and just load the mcz files > directly? Guessing not...?) > >

July 5, 2017

Re: [Pharo-dev] [ANN] Pharo community addon for world menu

by Alexandre Bergel

I would also point to the issue tracker. In Roassal, I have a similar menu. And indeed, this is useful. Alexandre > On Jul 4, 2017, at 7:41 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > I added a small utility called "Community" to the catalog that allows you to quickly > access/browse the most prominent Pharo pages (Homepage, Discord, Mailinglist Archive, CI Server, > Books page, Association, Consortium, STHub) right from the world menu. Also in Spotter. > > Example: > ======== > Load Community from Pharo catalog. As the menu entries are mirrored also in Spotter you > can easily open Spotter, key in "Discord" hit enter and the local web browser should > open the Pharo chat. > > Attached is a screenshot. > > Maybe this is useful for others too. > > Have fun > T.<community.png>

July 4, 2017

[ANN] Pharo community addon for world menu

by Torsten Bergmann

Hi, I added a small utility called "Community" to the catalog that allows you to quickly access/browse the most prominent Pharo pages (Homepage, Discord, Mailinglist Archive, CI Server, Books page, Association, Consortium, STHub) right from the world menu. Also in Spotter. Example: ======== Load Community from Pharo catalog. As the menu entries are mirrored also in Spotter you can easily open Spotter, key in "Discord" hit enter and the local web browser should open the Pharo chat. Attached is a screenshot. Maybe this is useful for others too. Have fun T.

July 4, 2017

Pull requests reviews

by Pavel Krivanek

I prepared a script that should help you with the reviews of the pull requests on Pharo 7. We will later convert it into a more fancy tool. It does next steps: - sets the basic information: pull request number, path to your pharo repository clone, name of your fork. - registers the repository into Iceberg and sets pull and push target remotes - switches branch to a particular commit from which the Pharo image was bootstrapped - registers the repository into into Monticello packages to be able to do correct diffs - gets basic information about the pull request from GitHub (original repository, branch name) - registers the PR original repository into remotes if needed and fetches information from it - creates a new local branch to merge the PR - merges the PR branch - displays a simple tool that shows differences in done in this merged branch -------- pullRequest := 73. target := '/path/pharo' asFileReference. myForkName := 'myFork'. repository := IceRepositoryCreator new location: target; subdirectory:'src'; createRepository. repository register. fork := repository remotes detect: [ :remote | remote remoteName = myForkName ]. repository pushRemote: fork. repository pullRemote: repository origin. repository checkoutBranch: (SystemVersion current commitHash). fileTreeRepository := (MCFileTreeRepository new directory: target / #src; yourself). repositoryGroup := MCRepositoryGroup withRepositories: { fileTreeRepository. MCCacheRepository uniqueInstance. }. MCWorkingCopy allManagers select: [ :wc | (wc repositoryGroup repositories reject: [ :repo | repo isCache ]) isEmpty ] thenDo: [ :wc | wc repositoryGroup: repositoryGroup ]. stonString := (ZnEasy get: ' https://api.github.com/repos/pharo-project/pharo/pulls/', pullRequest asString) contents. head := (STONJSON fromString: stonString) at: 'head'. sshUrl := (head at: #repo) at: 'ssh_url'. branchName := head at: #ref. user := (sshUrl withoutPrefix: 'git(a)github.com:') withoutSuffix: '/pharo.git'. fork := repository remotes detect: [ :remote | remote remoteName = user ] ifNone: [ | newFork | newFork := (IceRemote name: user url: ('git@github.com:{1}/pharo.git' format: {user})). repository addRemote: newFork. newFork ]. repository fetchFrom: fork. prMergedBranchName := 'pr', pullRequest asString. repository createBranch: prMergedBranchName. repository checkoutBranch: prMergedBranchName. commit := repository revparse: user, '/', branchName. bootstrapCommit := repository revparse: (SystemVersion current commitHash). [ repository backend merge: commit id ] on: IceMergeAborted do: [ :error | repository mergeConflictsWith: commit ] . headCommit := repository revparse: 'HEAD'. browser := GLMTabulator new. browser row: [:row | row column: #commits span: 2; column: #changes span: 3]; row: #diff. browser transmit to: #commits. browser transmit to: #changes; from: #commits; andShow: [ :a :commitInfo | (IceDiffChangeTreeBuilder new entity: commitInfo; diff: (IceDiff from: commitInfo to: bootstrapCommit); buildOn: a) title: 'Changes'. ]. browser transmit from: #commits; from: #changes; to: #diff; andShow: [ :a | a diff title: 'Left: working copy / Right: incoming updates'; display: [ :commitInfo :change | { change theirVersion ifNil: ''. change myVersion ifNil: ''. }]]. browser openOn: {headCommit}. -------- The merge operation only changes the Git working copy, no code is loaded into the image. If you want to test the PR code, currently you need to open Iceberg and reload all packages in the Pharo repository (Packages tab, Reload all) Expect troubles :-) Cheers, -- Pavel

July 4, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60506 Home: https://github.com/pharo-project/pharo-core

July 4, 2017

[pharo-project/pharo-core] 9a3d58: 60506

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 9a3d58e0ee84d733c08f8447b05a946939337a5d https://github.com/pharo-project/pharo-core/commit/9a3d58e0ee84d733c08f8447… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-07-04 (Tue, 04 Jul 2017) Changed paths: M Collections-Streams.package/Stream.class/instance/accessing/next_put_.st A Collections-Streams.package/WriteStream.class/instance/accessing/crlf.st R Collections-Streams.package/WriteStream.class/instance/character writing/crlf.st M Collections-Streams.package/WriteStream.class/instance/character writing/crtab.st M Collections-Streams.package/WriteStream.class/instance/character writing/crtab_.st M Collections-Streams.package/WriteStream.class/instance/character writing/ensureNoSpace.st M Collections-Streams.package/WriteStream.class/instance/character writing/space_.st M Collections-Streams.package/WriteStream.class/instance/character writing/tab_.st A Collections-Tests.package/CharacterTest.class/instance/tests/testIsSeparator.st A Collections-Tests.package/WriteStreamTest.class/instance/tests/testEnsureNoSpace.st M Kernel.package/Character.class/instance/testing/isSeparator.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60505.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60506.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60505.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60506.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Text-Core.package/Text.class/class/instance creation/fromString_.st Log Message: ----------- 60506 20092 Improve speed of WriteStream>>tab: https://pharo.fogbugz.com/f/cases/20092 20088 Improve speed of Character>>isSeparator in when the separator is not a space https://pharo.fogbugz.com/f/cases/20088 20204 Text class>>#fromString https://pharo.fogbugz.com/f/cases/20204 http://files.pharo.org/image/60/60506.zip

July 4, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Pavel Krivanek

A small update: You are not forced to use a 'pharo-core' repository in your image folder if you provide a path to your own clone to the working copies of the bootstrapped packages. This way you can more easily share one local clone of the pharo-project/pharo repository. For the registration of your local repository use this script: target := 'path/to/my/local/repository' asFileReference. repository := IceRepositoryCreator new location: target; subdirectory:'src'; createRepository. repository register. fork := repository remotes detect: [ :remote | remote remoteName = #myFork ]. repository pushRemote: fork. repository pullRemote: repository origin. repository checkoutBranch: 'development'. repository backend pullFrom: repository origin. repository push. repository checkoutBranch: (SystemVersion current commitHash). fileTreeRepository := (MCFileTreeRepository new directory: target / #src; yourself). repositoryGroup := MCRepositoryGroup withRepositories: { fileTreeRepository. MCCacheRepository uniqueInstance. }. MCWorkingCopy allManagers select: [ :wc | (wc repositoryGroup repositories reject: [ :repo | repo isCache ]) isEmpty ] thenDo: [ :wc | wc repositoryGroup: repositoryGroup ] 2017-06-26 13:14 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > this mail describes how to start to send pull requests to Pharo 7 Github > repository from Pharo 7. > > Preparations > ===================== > > - you need to have a Github account and set SSH keys. See > https://help.github.com/articles/connecting-to-github-with-ssh/ > - create own pharo-project/pharo repository fork. Go to > https://github.com/pharo-project/pharo, click on "Fork" button and follow > the instructions > > Get Pharo 7 image > ===================== > > The CI jobs for the Pharo 7 defelopment are currently not fully set and we > still do not publish Pharo 7 image to files.pharo.org so you cannot get > it using zero-conf scripts. But we have a provisional CI job that > bootstraps the Pharo 7 image. > > https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ > > There download a file named like Pharo7.0-32bit-hash.zip and decompress > it. Unlike Pharo 6 images, the archive contains three files. Image, changes > and sources. In Pharo 7 you have the sources file for every bootstrapped > version. It has a commit hash in the name and it cannot be shared between > different Pharo 7 imges, however it can be shared between images that were > created as snapshots with the same bootstrapped image as ancestor. > > Create local clone > ===================== > > You need a local clone of the Pharo repository. Because it contains a lot > of small files, it is not a good idea to have own clone for every image. > You can have only one and share them between images. But because of some > current Monticello constraints you need to have the clone placed in the > image directory in a folder with name 'pharo-core'. > > In this step we will clone the Pharo repository from pharo-project/pharo > Github repository and add your fork as default pull target. We will update > your fork repository to contain all latest commits from the Pharo > repository in the branch named 'development'. For latest stable version > (Pharo 6) we use the master branch. > In the end we will checkout the repository to a particular commit from > which the downloaded Pharo 7 image was bootstrapped. Imagine that you have > a Pharo 7 image that is several days old and the development branch has > already some commits that change code. If you would take this older image, > checkout to the development branch and then do your commit, your would > revert all changes done in not-loaded commits. The other option is to > update your image to correspond to the repository latest commit which > requires packages reloading. > If you checkout to a particular commit, you are in detached HEAD state. In > this state you cannot do commits directly. You need to firstly create new a > new branch which we will do anyway. > > Evaluate the following code. This functionality will be later direct part > of Iceberg UI. Do not forget to change the user name. > > username := 'YOUR-USER-NAME'. > repository := IceRepositoryCreator new > url: 'git@github.com:pharo-project/pharo.git'; > location: ('pharo-core' asFileReference ensureCreateDirectory); > subdirectory:'src'; > createRepository. > repository checkoutBranch: 'development'. > repository register. > > fork := (IceRemote name: 'myFork' url: ('git@github.com:{1}/pharo.git' > format: {username})). > repository addRemote: fork. > repository pushRemote: fork. > repository pullRemote: repository origin. > > "update fork" > repository backend pullFrom: repository origin. "use this low-level form > to prevent packages reloading" > repository push. > > "checkout to the commit from which the image was bootstrapped" > repository checkoutBranch: (SystemVersion current commitHash). > > Use already created clone > ===================== > > This is alternative to the previous step. Let's suppose that you already > have your local clone. You take some Pharo 7 image and you want to create > commits. Then you need to create a symlink or move/copy the repository into > your image directory. Remember, it must be named pharo-core (we do not use > the name 'pharo' to avoid collision with VM executable). > > In this step we will register an existing Pharo repository clone, set your > fork as the push target, update your fork and then switch to the particular > commit. > > repository := IceRepositoryCreator new > location: ('pharo-core' asFileReference); > subdirectory:'src'; > createRepository. > repository register. > > fork := repository remotes detect: [ :remote | remote remoteName = #myFork > ]. > repository pushRemote: fork. > repository pullRemote: repository origin. > > repository checkoutBranch: 'development'. > repository backend pullFrom: repository origin. > repository push. > > repository checkoutBranch: (SystemVersion current commitHash). > > Issue processing > ===================== > > - create new case on FogBugz to get the issue number > - open Iceberg and from the context menu on the 'pharo' repository do: > Pharo - Create new branch from FogBugz issue, enter the issue ID and it > will fill the full branch name for you > - create your changes (you can do it before the creation of the branch too) > - commit and push your changes in Iceberg, this way you will commit your > branch to your fork repository. Remember that the Iceberg commit window has > two buttons, one for local commit, the second for commit with immediate > push. They can be very long because they contain the full branch (issue) > name > - in Iceberg in the 'pharo' repository context menu do: Pharo - Create > pull request, fill your > - fill your Github credentials > - leave the PR title, comment is not required, check the pull request head > and base. The base MUST be pharo-project/pharo development. Create the pull > requests > - go to https://github.com/pharo-project/pharo/pulls, check your pull > requests and put URL of it into the issue record on FogBugz (as a comment). > Resolve the issue as Fix review needed > > Cheers, > -- Pavel > >

July 4, 2017

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

by Christian Haider

Yes, Value (the superclass) is used for â Ã¤h :) - values, i.e. immutable literal objects, which aid me with a more functional programming style. The literal printing of Objects is possible for all objects, since the facilities are defined in Object (#asSource). And yes, it is the same as #storeString â in spirit and as fallback. But instead of using #instvarAt:put:, #asSource uses the constructor form instead. (I did not want to extend #storeString to not interfere with the systems use of it (lots).) So, instead of writing the infos (class names, selectors and arguments) in a new syntax, why not writing it as Smalltalk source? You just need to define a print method #printvalueWith: and implement the corresponding constructor(s). My question about the purpose was more from the user view. Is it for persisting settings or configurations outside an image? Or exchanging data between images / dialects? Or for interfacing with external systems? For these, I could recommend Values :). Cheers P.S. are you at ESUG? I could show you what I meanâ¦ Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl Gesendet: Dienstag, 4. Juli 2017 09:20 An: Pharo Dev <pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Hi Christian, thanks for the explanation. I see that Values serve a different purpose. We are looking for a compact form of object literal, the is not bound to the external interface and does not need to be subclassed. I'm interested how the printing of Values is different to #storeString. Norbert Am 04.07.2017 um 09:05 schrieb Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com> >: Hi Norbert, yes, that is the point: it is a normal Smalltalk expression. It is trivial and every Smalltalk understands it. No need for special parsers; you just have class names and constructor methods. I believe this is a very compact and simple representation of Smalltalk objects. The Values package contains mainly the machinery to print an object (aka Value) as String so that it can be reconstructed from it. Exactly like Smalltalk prints literal objects like Array, Integer, Character, String, Symbol etc. The superclass Value makes sure that the object tree (remember â no cycles or references) will print properly (under consideration of namespaces). Also, many âsimpleâ base objects can be turned into Values by implementing constructors and the printer (like Date, Timestamp, Point, Rectangle, ColorValue etc.). Additionally, Values allow to declare optional instVars, so that the representation does not get too cluttered with boilerplate arguments. In the dev tools, there is a generator which produces the proper constructors (2**<number of defaults>). There is really not much to it, technically. Maybe it is just too simple. I would be interested in the differences to the other proposals â what should be achieved and what may be missing? HTH, Christian Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl Gesendet: Dienstag, 4. Juli 2017 08:14 An: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Hi Christian, Am 03.07.2017 um 11:06 schrieb Christian Haider < <mailto:christian.haider@smalltalked-visuals.com> christian.haider(a)smalltalked-visuals.com>: 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) )) I do not understand your point. Above is a normal smalltalk expression. I skimmed through the Values document and I do not get how this is related to a discussion about compact object literal syntax. Can you elaborate a bit more? How do Values help here? Norbert 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> 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 < <mailto:pharo-dev@lists.pharo.org> 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 < <mailto:eliot.miranda@gmail.com> eliot.miranda(a)gmail.com>: Hi Norbert, On Jul 1, 2017, at 7:36 AM, Norbert Hartl < <mailto:norbert@hartl.name> norbert(a)hartl.name> wrote: Am 30.06.2017 um 21:14 schrieb Stephane Ducasse < <mailto:stepharo.self@gmail.com> 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 < <mailto:siguctua@gmail.com> 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 < <mailto:Pharo-project@lists.gforge.inria.fr> 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.

July 4, 2017

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

by Norbert Hartl

Hi Christian, thanks for the explanation. I see that Values serve a different purpose. We are looking for a compact form of object literal, the is not bound to the external interface and does not need to be subclassed. I'm interested how the printing of Values is different to #storeString. Norbert > Am 04.07.2017 um 09:05 schrieb Christian Haider <christian.haider(a)smalltalked-visuals.com>: > > Hi Norbert, > > yes, that is the point: it is a normal Smalltalk expression. > It is trivial and every Smalltalk understands it. > No need for special parsers; you just have class names and constructor methods. > I believe this is a very compact and simple representation of Smalltalk objects. > > The Values package contains mainly the machinery to print an object (aka Value) as String so that it can be reconstructed from it. > Exactly like Smalltalk prints literal objects like Array, Integer, Character, String, Symbol etc. > The superclass Value makes sure that the object tree (remember â no cycles or references) will print properly (under consideration of namespaces). > Also, many âsimpleâ base objects can be turned into Values by implementing constructors and the printer (like Date, Timestamp, Point, Rectangle, ColorValue etc.). > > Additionally, Values allow to declare optional instVars, so that the representation does not get too cluttered with boilerplate arguments. > In the dev tools, there is a generator which produces the proper constructors (2**<number of defaults>). > > There is really not much to it, technically. Maybe it is just too simple. > I would be interested in the differences to the other proposals â what should be achieved and what may be missing? > > HTH, > Christian > > Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl > Gesendet: Dienstag, 4. Juli 2017 08:14 > An: Pharo Development List <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax > > Hi Christian, > > Am 03.07.2017 um 11:06 schrieb Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com>>: > >> 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) >> )) >> > I do not understand your point. Above is a normal smalltalk expression. I skimmed through the Values document and I do not get how this is related to a discussion about > compact object literal syntax. > Can you elaborate a bit more? How do Values help here? > > Norbert > >> 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 <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.

July 4, 2017