- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pull requests reviews

by Pavel Krivanek

So loading of the PR packages is very simple. Do at the end: diff := IceDiff from: headCommit to: bootstrapCommit. diff changedPackages do: #reload. 2017-07-04 17:33 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > 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 5, 2017

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

by Stephane Ducasse

Yes there will be a nice 6.1 because we care of people. Stef On Mon, Jul 3, 2017 at 4:39 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 03.07.2017 um 14:45 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 3 Jul 2017, at 13:32, Norbert Hartl <norbert(a)hartl.name> wrote: > > So it is decided there won't be an official pharo6 supporting iceberg? > > > not today :) > I will release Pharo 6.1 with updated icebergâ¦ because it requires a new VM > and I donât want to break current downloaded version. > Problem is: once we jump to 6.1, 6.0 will not be maintained anymoreâ¦ not > cool, maybe. But inevitable due the amount of effort we can put there. > > Ok, understood! And glad we will have 6.1. Great! > > Norbert > > Esteban > > > Norbert > > Am 03.07.2017 um 13:28 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > 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 | bash > wget -O- get.pharo.org/64/vmT70 | bash #If you are on linux > > 32bits: > wget -O- get.pharo.org/vm70 | bash > wget -O- get.pharo.org/vmT70 | 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. > > > Maybe I was not clearâ¦ this script works also for P6 (*if * you have the new > VM) :) > > > cheers! > Esteban > > > >

July 5, 2017

Re: [Pharo-dev] Pharo Launcher

by Stephane Ducasse

yes latency problem. We should improve on that front :( On Mon, Jul 3, 2017 at 12:35 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > > 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 5, 2017

Re: [Pharo-dev] [ANN] for P7, default VM for linux moved to threaded

by Stephane Ducasse

What are the implications? Stef On Mon, Jul 3, 2017 at 2:39 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I made default vm for linux (for P7) the default VM. > > I also updated zeroconf to add a new type of download for linux: the explicit iTimer heartbeat download. > > > So, for P7, if you download the default stable VMâ¦ it will be a threaded VM. Take that into account :) > > Esteban > >

July 5, 2017

Re: [Pharo-dev] P6 crashed image

by Stephane Ducasse

Hi hilaire We should throw away this plugin it is a bug nest. Sorry because it does not solve your problem and this is super annoying for us. Stef On Tue, Jul 4, 2017 at 3:07 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > Hi Hilaire, > > I do not know if it will help in this case, but sometimes I have recovered from > similar problems by temporarily deleting a problem plugin (probably FT2Plugin.so > in this case). Sometimes that will allow you to open the image and save it again. > After that, you may be able to put the plugin back and run the image again. > > Dave > > > On Sun, Jul 02, 2017 at 05:56:05PM +0200, Hilaire wrote: >> Hi, >> >> I got problem with my Pharo6 image when I save it, after some Glamour >> try out, don't know if it is related. >> >> When I saved the image, it grows to 292MB then stalled, with the mouse >> writing pointer. Then Pharo display became garbage. I have to kill the >> process. >> >> The image does not start anymore, get segmentation fault with Smalltalk >> stack dump, Freetype seems to be involved: >> >> Segmentation fault Sun Jul 2 17:52:39 2017 >> >> >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/lib/pharo/5.0-201705310241/pharo >> Pharo VM version: 5.0-201705310241 Wed May 31 04:43:29 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] >> Built from: CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 >> With: StackToRegisterMappingCogit VMMaker.oscog-eem.2227 uuid: 7ea146b4-39ce-4de7-afa3-a76ed1d1da35 May 31 2017 >> Revision: VM: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 30 19:41:27 2017 -0700 $ >> Plugins: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Build host: Linux testing-gce-7baaea33-cad4-44b6-b0e5-7ad5f93c3335 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux >> plugin path: /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241 [default: /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/lib/pharo/5.0-201705310241/] >> >> >> C stack backtrace & registers: >> rax 0x49063940 rbx 0x490637d0 rcx 0x490639f8 rdx 0x49063888 >> rdi 0x490635a8 rsi 0x490635a8 rbp 0x49063718 rsp 0x49063ab0 >> r8 0x49062fe8 r9 0x490630a0 r10 0x49063158 r11 0x49063210 >> r12 0x490632c8 r13 0x49063380 r14 0x49063438 r15 0x490634f0 >> rip 0x49063b68 >> *[0x7fff49063b68] >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x41cac1] >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x41ce4f] >> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f4e70d53330] >> /usr/lib/x86_64-linux-gnu/libfreetype.so.6(FT_Stream_ReadULong+0x78)[0x7f4e6cc9c168] >> /usr/lib/x86_64-linux-gnu/libfreetype.so.6(+0x52116)[0x7f4e6ccdb116] >> /usr/lib/x86_64-linux-gnu/libfreetype.so.6(+0x26742)[0x7f4e6ccaf742] >> /usr/lib/x86_64-linux-gnu/libfreetype.so.6(+0x152e3)[0x7f4e6cc9e2e3] >> /usr/lib/x86_64-linux-gnu/libfreetype.so.6(FT_Open_Face+0x2a0)[0x7f4e6cca0070] >> /usr/lib/x86_64-linux-gnu/libfreetype.so.6(FT_New_Memory_Face+0x39)[0x7f4e6cca0669] >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/FT2Plugin.so(primitiveNewMemoryFaceFromExternalMemoryAndIndex+0xea)[0x7f4e6cf309aa] >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x4572a7] >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo(interpret+0xbd80)[0x467d80] >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x468651] >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo(interpret+0x268)[0x45c268] >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo(main+0x2ab)[0x419d6b] >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4e70695f45] >> /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x41a055] >> [0x7fff49061d60] >> >> >> Smalltalk stack dump: >> 0x7fff490695d8 I FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: 0x4a83478: a(n) FreeTypeFace >> 0x7fff49069628 I FreeTypeFace>create 0x4a83478: a(n) FreeTypeFace >> 0x7fff49069668 I FreeTypeFace>validate 0x4a83478: a(n) FreeTypeFace >> 0x7fff490696a8 I FreeTypeFont>face 0x13c41758: a(n) FreeTypeFont >> 0x7fff490696e8 I FreeTypeFont>validate 0x13c41758: a(n) FreeTypeFont >> 0x7fff49069728 I LogicalFont>realFont 0x3015870: a(n) LogicalFont >> 0x7fff49069768 I LogicalFont>descent 0x3015870: a(n) LogicalFont >> >> >> -- >> Dr. Geo >> http://drgeo.eu >> >

July 5, 2017

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