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

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

by Norbert Hartl

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 3, 2017

Esteban's ChangeLog week of 26 June 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 26 June 2017 to 2 July 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=26/6/2017&to=2/7/2017 ChangeLog ========= 29 June 2017: ------------- * ... and I spent some time figuring out why windows users have a persistent error about access files. We should always remember the windows path limitations (256) :) Now, the workaround for this is to execute this in command line: ---- git config --system core.longpaths true ---- but of course, this is just a workaround because people using Iceberg could not hava installed a command line git client. I will need to check in the future this :( * I spent some time trying to get [Iceberg version dev-0.5](https://github.com/pharo-vcs/iceberg/tree/dev-0.5) to load properly (yesterday's script is not working). The reason is that +Metacello+ fails to upgrade packages from a baseline. And there is no way (at least that I found) to force the upload. So this is the updated script to test dev-0.5: 1. Download latest vm and image. ---- wget -O- get.pharo.org/64/70+vmLatest | bash wget -O- get.pharo.org/64/70+vmTLatest | bash # for linux systems ---- 2. Execute this on your image ---- #('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:dev-0.5'; load. ---- This should actually remove old iceberg version then install new one. 28 June 2017: ------------- * Ok, I get the VM to compile correctly with the new libgit2 version, and now +latest vm+ comes with +libgit 0.25.1+ for both 32 and 64 bits versions. I also made some minor fixes to +iceberg dev-0.5+ and it should be ready to test and release. This version incorporates some important changes that will allow us to work with it to make changes to Pharo itself (and that will be noticed on big projects): * it has cherry-pick. * it speeds up sincronization by introducing more precise comparisons instead making a "full scan" * it keeps in sync branch on disk and branch on iceberg (before it was keeping them separately and it was very confusing) To test it, you can execute: ---- wget -O- get.files.org/64/70+vmLatest | bash wget -O- get.files.org/64/70+vmTLatest | bash # on linux systems ---- then you will need to load version +dev-0.5+ : ---- Metacello new baseline: 'Iceberg'; repository: 'github://pharo-vcs/iceberg:dev-0.5'; load. "And you will need to execute this... I will need to update the baseline with this, now that I think :)" LGitExternalStructure allSubclassesDo: #compileFields. ---- * I finished ensuring [iceberg](https://github.com/pharo-vcs/iceberg/tree/dev-0.5) will work on 64 bits. Now, I needed to make some fixes for UFFI, which I put in [case: 20198](https://pharo.fogbugz.com/f/cases/20198) (it is imperative to include this to be able to backport 0.5 into Pharo 6.0). Also, I will need to promote a new VM as stable. I'm not sure I want to backport this into Pharo 6. I know I promised but complications are... more than benefits, I think: You will need a new VM. People will not know that and they will download a P6 image with the older VM and this will cause problems. Maybe is better to move all this to P7? cheers! Esteban

July 3, 2017

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

by Stephane Ducasse

Back from paris ... Eliot I will implement your proposal I like it. Stef On Sun, Jul 2, 2017 at 3:33 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks all for the suggestions. > I did another version on the version of igor and I will do another > pass on the asObject package > and send it to you. > > > > On Sat, Jul 1, 2017 at 8:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> 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 >> >>> >>> 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. >> >>> >>> 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 2, 2017

P6 crashed image

by Hilaire

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 2, 2017

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

by Stephane Ducasse

Thanks all for the suggestions. I did another version on the version of igor and I will do another pass on the asObject package and send it to you. On Sat, Jul 1, 2017 at 8:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > 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 > >> >> 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. > >> >> 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 2, 2017

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

by Eliot Miranda

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 > > 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. > > 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 1, 2017

Re: [Pharo-dev] Baseline question

by Peter Uhnak

On Sat, Jul 01, 2017 at 02:35:07PM +0200, Stephane Ducasse wrote: > Hi > > I 'm trying to define a baseline for our project and I defined it as > > baseline: spec > <baseline> > spec for: #common do: [ spec > baseline: 'SmaCC' with: [ spec > repository: 'github://ThierryGoubier/SmaCC'; > loads: 'SmaCC-GLR-Runtime' ]; > > package: 'SmaCC-Solidity' > "we could say that SmaccSolidity depends on Smacc-Runtime but I do not > know how to say it" > ] > > Now I thought that I could try to load it using the following > > Metacello new > baseline: 'SmaccSolidity'; > repository: 'github://RMODINRIA-Blockchain/SmaCC-Solidity'; > load. > > > But I get an error telling me that the baseline constructor does not > understand load ;( It loaded ok for me in a fresh image (pharo 6), maybe local problem? As for dependency on a package, here's an older answer by Thierry: http://forum.world.st/How-to-depend-on-another-Github-repo-from-the-baselin… Peter

July 1, 2017

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

by Norbert Hartl

> 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 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. 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 1, 2017

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

by Luke Gorrie

On 1 July 2017 at 13:28, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > after many-o-hours spent on my git-migration tool ( > https://github.com/peteruhnak/git-migration ), I've concluded that the > migration cannot be properly done for packages. > Let us hope this effort can be salvaged! > 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. 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. Cheers, -Luke

July 1, 2017

Re: [Pharo-dev] Baseline question

by Julien Delplanque

Hello, To do my baselines I do the following: 1. I create a subclass of BaselineOf. 2. I create an instance method #baseline: baseline: spec <baseline> spec for: #common do: [ self defineDependencies: spec; definePackages: spec ] 3. I create the #defineDependencies: instance method (for example in SFDiff): defineDependencies: spec ^ spec project: 'ChangeModel' with: [ spec className: 'ConfigurationOfFamixDiff'; version: #development; repository: 'http://smalltalkhub.com/mc/Moose/FamixDiff/main'; loads: 'ChangeModel' ]; project: 'FamixDiff' with: [ spec className: 'ConfigurationOfFamixDiff'; version: #development; repository: 'http://smalltalkhub.com/mc/Moose/FamixDiff/main'; loads: 'Core' ]; yourself 4. I create the #definePackages: instance method (still for SFDiff): definePackages: spec ^ spec package: 'SimilarityFlooding' with: [ spec requires: #('ChangeModel') ]; package: 'SimilarityFlooding-Tests' with: [ spec requires: #('SimilarityFlooding') ]; package: 'SimilarityFlooding-Diff' with: [ spec requires: #('SimilarityFlooding') ]; package: 'SimilarityFlooding-Diff-Tests' with: [ spec requires: #('SimilarityFlooding-Diff') ]; package: 'SimilarityFlooding-Evaluator' with: [ spec requires: #('SimilarityFlooding' 'FamixDiff') ]; package: 'SimilarityFlooding-DiffOrion' with: [ spec requires: #('SimilarityFlooding-Diff') ]; yourself Separating the dependencies and package definitions allow me to modify it easily. I hope it helps. Julien PS: to make a baseline use on another baseline as dependency I put this kind of source code in #defineDependencies: spec baseline: 'DependenceName' with: [ spec repository: 'github://user/repositoryname/eventualdirectory' ]. On 01/07/17 14:35, Stephane Ducasse wrote: > Hi > > I 'm trying to define a baseline for our project and I defined it as > > baseline: spec > <baseline> > spec for: #common do: [ spec > baseline: 'SmaCC' with: [ spec > repository: 'github://ThierryGoubier/SmaCC'; > loads: 'SmaCC-GLR-Runtime' ]; > > package: 'SmaCC-Solidity' > "we could say that SmaccSolidity depends on Smacc-Runtime but I do not > know how to say it" > ] > > Now I thought that I could try to load it using the following > > Metacello new > baseline: 'SmaccSolidity'; > repository: 'github://RMODINRIA-Blockchain/SmaCC-Solidity'; > load. > > > But I get an error telling me that the baseline constructor does not > understand load ;( > > I read the blog of peter > https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… > > and I'm doing exactly the same so I wonder. > > Stef >

July 1, 2017