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

Re: [Pharo-dev] [ANN] Sparta v1.1

by Tudor Girba

Yes. At this point, there is no fallback implemented. Doru > On Oct 23, 2016, at 10:43 AM, stepharo <stepharo(a)free.fr> wrote: > > Doru > > does it mean that right now with Sparta we do not have any fallback? > > Stef > > > Le 21/10/16 Ã 15:41, Tudor Girba a Ã©crit : >> Hi Clement, >> >> Thanks for raising this question. >> >> In short, Sparta is inspired from Athens and it has a similar structure. So, there is an in-image interface of the canvas, and there is a concrete implementation through the plugin (based on Moz2D). To target a completely in-image rendering, it is certainly possible to implement a BitBlt backend of the Sparta canvas. To implement this part, we would need help. >> >> The goal is indeed to have only one canvas in the default Pharo distribution: Sparta. However, this will not happen suddenly. Ideally, when Pharo 6 will be released, there will be a beta version of Sparta + Bloc + some tools that will be loadable externally. Then my guess is that it will still take another year until we get the full development environment working on top of Sparta. So, it is to be expected that this transition will take at least 1.5 years during which time Athens will still provide the option of running on top of BitBlt. >> >> Does this answer the concern? >> >> But, now my question: Would it not be possible to get the VM to not open a window when in headless mode? >> >> Cheers, >> Doru >> >>> On Oct 21, 2016, at 2:23 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>> >>> >>> On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>> Hi StÃ©phane >>> >>> Indeed, build is broken :) >>> Yesterday I took a very brief look at bloc and can confirm that development version is loadable in Pharo 6 and is completely Sparta based. (all examples work for me) >>> >>> You are right, live environment on embedded systems is great goal to achieve. Sparta must not prevent pharo from getting there. It is true that plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it is all-in-one build and size can be reduced dramatically. >>> >>> As I understand, Pharo for PC should not make any assumptions about user's hardware. If gpu accelerated backend can not be used there should be still a performant fallback backend which also needs a fallback that is guaranteed to work even on Personal Calculators. (Taschenrechner). That is why library is so big. For example for mac and windows Sparta is shipped with 3 (!) backends that together build fallback chain, for instance on windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia reduces binary size from 15mb to 10mb. Removing GL package and leaving only software backends may reduce size even more. >>> >>> It is a bit different on embedded systems, since hardware configuration is already known and there is no need to have so many fallback backends. Library itself allows developers to add new exotic backends quite easily. >>> >>> Let's take Pharo6 for mac. It is shipped with the following libs: >>> Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb >>> >>> Moz2D is self contained and does not require any additional libs. >>> Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? (estimate around 6-7mb). >>> >>> As you can see we get almost the same numbers :) >>> >>> Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run Pharo, they're required only if you use them. I compile VMs without such libraires and Pharo works just fine as a development environment and for simple things like web servers. The Squeak VM for example have around 2Mb footprint in total, including 1Mb for the C runtime (initialized and uninitialized data, executable code) and 1 Mb for the machine code zone and can run most Pharo features just fine, including for examples web services and the IDE. >>> >>> Right now the VM cannot start completely headless, the headless mode just hides the main window, so if the main window start-up depends on Sparta, it's not possible to run Pharo headless without many Mb of memory footprint. >>> >>> Which leads the first question... >>> >>>>> Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? By asking this question, I imply, if there is no Cairo/Pixman/FreeType/Sparta plugin, can the image run headless and can it run UI applications ? >>> The last problem is that Pharo can currently run UI application like the IDE on a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. can be run either headless on a 2Mb memory footprint VM or with a UI on a 7Mb+ memory footprint VM. It means now people doing UI would need extra memory, for example, in the case of android deployment where the android app includes the VM and the image, the app memory consumption at runtime would be at least 5Mb bigger. >>> >>>>> Is the community ok with this or will we need to maintain both the Sparta back-end and a Bloc to BitBlt back-end as a fall-back to run on smaller VMs ? >>> >>> Cheers >>> Alex >>> >>> On Oct 19, 2016 22:16, "stepharo" <stepharo(a)free.fr> wrote: >>> Hi Aliaksei >>> >>> It looks gorgeous. >>> I tried to launch the Bloc image from the CI and it crashes during startup on my mac. I reported that to Glenn and Alain but so far I simply cannot see Bloc code. Is it working for you? I mean is it me that is using the wrong VM. >>> >>> Then I have a question: >>> >>> - do you think that we can have a fallback in terms of back end for the case where we could like to run Pharo on coffee machines but get a live environment on such machines? This is related to the discussions we got this summer about the memory footprint that Moz2D will put on us. >>> >>> I do not mean that we must have one but I think that this is important to check because we can say that Pharo is small but if we need 20 mb libraries for rendering there are some cases where this can kill its usage. >>> >>> Stef >>> >>> Le 19/10/16 Ã 18:06, Aliaksei Syrel a Ã©crit : >>>> Hi >>>> >>>> I am happy to announce the release of Sparta v1.1 for Pharo 6. >>>> https://github.com/syrel/Sparta/tree/v1.1 >>>> >>>> It can be bootstrapped with the following script: >>>> >>>> Metacello new >>>> >>>> baseline: 'Sparta' >>>> ; >>>> repository: 'github://syrel/sparta:v1.1/src' >>>> ; >>>> load: #file:core >>>> Examples are on class side of: MozExamples, MozTextExamples >>>> (for linux users: if you use 32bit pharo on 64bit linux, sparta will not work, since 32bit plugin depends on 32bit GTK which conflicts with 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with 64bit vm on mac and linux - it works, but some features fail because FFI is not ready) >>>> Release of v1.1 is focused on hardware acceleration, windows support and text rendering. >>>> What is new: >>>> - Default backends on all platforms changed from software to hardware accelerated. >>>> - Now also works on Windows! Default backend is Direct2D for drawings and DirectWrite for text. On multi-gpu machines per-app-default setting is respected. In case of Nvidia it can be changed in nvidia control panel. Sparta is x2 faster on discrete gpu than on integrated one. >>>> - Added initial text support, for instance rendering and high precision measurement. >>>> - Per-platform settings system is now image based. Allows to enable/disable hardware acceleration, change default backends, change font-mappings tables. >>>> Some text examples: >>>> (rendering) >>>> <Mail Attachment.png> >>>> (measurement) >>>> <Mail Attachment.png> >>>> Cheers, >>>> Alex >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "There are no old things, there are only old ways of looking at them." >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "Beauty is where we see it."

Oct. 23, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by stepharo

Doru does it mean that right now with Sparta we do not have any fallback? Stef Le 21/10/16 Ã 15:41, Tudor Girba a Ã©crit : > Hi Clement, > > Thanks for raising this question. > > In short, Sparta is inspired from Athens and it has a similar structure. So, there is an in-image interface of the canvas, and there is a concrete implementation through the plugin (based on Moz2D). To target a completely in-image rendering, it is certainly possible to implement a BitBlt backend of the Sparta canvas. To implement this part, we would need help. > > The goal is indeed to have only one canvas in the default Pharo distribution: Sparta. However, this will not happen suddenly. Ideally, when Pharo 6 will be released, there will be a beta version of Sparta + Bloc + some tools that will be loadable externally. Then my guess is that it will still take another year until we get the full development environment working on top of Sparta. So, it is to be expected that this transition will take at least 1.5 years during which time Athens will still provide the option of running on top of BitBlt. > > Does this answer the concern? > > But, now my question: Would it not be possible to get the VM to not open a window when in headless mode? > > Cheers, > Doru > >> On Oct 21, 2016, at 2:23 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> >> >> On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> Hi StÃ©phane >> >> Indeed, build is broken :) >> Yesterday I took a very brief look at bloc and can confirm that development version is loadable in Pharo 6 and is completely Sparta based. (all examples work for me) >> >> You are right, live environment on embedded systems is great goal to achieve. Sparta must not prevent pharo from getting there. It is true that plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it is all-in-one build and size can be reduced dramatically. >> >> As I understand, Pharo for PC should not make any assumptions about user's hardware. If gpu accelerated backend can not be used there should be still a performant fallback backend which also needs a fallback that is guaranteed to work even on Personal Calculators. (Taschenrechner). That is why library is so big. For example for mac and windows Sparta is shipped with 3 (!) backends that together build fallback chain, for instance on windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia reduces binary size from 15mb to 10mb. Removing GL package and leaving only software backends may reduce size even more. >> >> It is a bit different on embedded systems, since hardware configuration is already known and there is no need to have so many fallback backends. Library itself allows developers to add new exotic backends quite easily. >> >> Let's take Pharo6 for mac. It is shipped with the following libs: >> Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb >> >> Moz2D is self contained and does not require any additional libs. >> Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? (estimate around 6-7mb). >> >> As you can see we get almost the same numbers :) >> >> Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run Pharo, they're required only if you use them. I compile VMs without such libraires and Pharo works just fine as a development environment and for simple things like web servers. The Squeak VM for example have around 2Mb footprint in total, including 1Mb for the C runtime (initialized and uninitialized data, executable code) and 1 Mb for the machine code zone and can run most Pharo features just fine, including for examples web services and the IDE. >> >> Right now the VM cannot start completely headless, the headless mode just hides the main window, so if the main window start-up depends on Sparta, it's not possible to run Pharo headless without many Mb of memory footprint. >> >> Which leads the first question... >> >>>> Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? By asking this question, I imply, if there is no Cairo/Pixman/FreeType/Sparta plugin, can the image run headless and can it run UI applications ? >> The last problem is that Pharo can currently run UI application like the IDE on a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. can be run either headless on a 2Mb memory footprint VM or with a UI on a 7Mb+ memory footprint VM. It means now people doing UI would need extra memory, for example, in the case of android deployment where the android app includes the VM and the image, the app memory consumption at runtime would be at least 5Mb bigger. >> >>>> Is the community ok with this or will we need to maintain both the Sparta back-end and a Bloc to BitBlt back-end as a fall-back to run on smaller VMs ? >> >> Cheers >> Alex >> >> On Oct 19, 2016 22:16, "stepharo" <stepharo(a)free.fr> wrote: >> Hi Aliaksei >> >> It looks gorgeous. >> I tried to launch the Bloc image from the CI and it crashes during startup on my mac. I reported that to Glenn and Alain but so far I simply cannot see Bloc code. Is it working for you? I mean is it me that is using the wrong VM. >> >> Then I have a question: >> >> - do you think that we can have a fallback in terms of back end for the case where we could like to run Pharo on coffee machines but get a live environment on such machines? This is related to the discussions we got this summer about the memory footprint that Moz2D will put on us. >> >> I do not mean that we must have one but I think that this is important to check because we can say that Pharo is small but if we need 20 mb libraries for rendering there are some cases where this can kill its usage. >> >> Stef >> >> Le 19/10/16 Ã 18:06, Aliaksei Syrel a Ã©crit : >>> Hi >>> >>> I am happy to announce the release of Sparta v1.1 for Pharo 6. >>> https://github.com/syrel/Sparta/tree/v1.1 >>> >>> It can be bootstrapped with the following script: >>> >>> Metacello new >>> >>> >>> baseline: 'Sparta' >>> ; >>> >>> repository: 'github://syrel/sparta:v1.1/src' >>> ; >>> >>> load: #file:core >>> Examples are on class side of: MozExamples, MozTextExamples >>> (for linux users: if you use 32bit pharo on 64bit linux, sparta will not work, since 32bit plugin depends on 32bit GTK which conflicts with 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with 64bit vm on mac and linux - it works, but some features fail because FFI is not ready) >>> Release of v1.1 is focused on hardware acceleration, windows support and text rendering. >>> What is new: >>> - Default backends on all platforms changed from software to hardware accelerated. >>> - Now also works on Windows! Default backend is Direct2D for drawings and DirectWrite for text. On multi-gpu machines per-app-default setting is respected. In case of Nvidia it can be changed in nvidia control panel. Sparta is x2 faster on discrete gpu than on integrated one. >>> - Added initial text support, for instance rendering and high precision measurement. >>> - Per-platform settings system is now image based. Allows to enable/disable hardware acceleration, change default backends, change font-mappings tables. >>> Some text examples: >>> (rendering) >>> <Mail Attachment.png> >>> (measurement) >>> <Mail Attachment.png> >>> Cheers, >>> Alex > -- > www.tudorgirba.com > www.feenk.com > > "There are no old things, there are only old ways of looking at them." > > > > > >

Oct. 23, 2016

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

by stepharo

Note that all the work on making sure that the image is not writing files when it is on read only mode is part of making coral installable on unix. Now if people wants coral they can join the effort. stef

Oct. 23, 2016

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

by Esteban Lorenzano

> On 22 Oct 2016, at 20:16, stepharo <stepharo(a)free.fr> wrote: > > > > Le 22/10/16 Ã 17:21, phil(a)highoctane.be <mailto:phil@highoctane.be> a Ã©crit : >> The st command line handler is pretty much giving the same. >> >> I used scale, it works nicely indeed. >> >> But I want Coral reborn. > > me too. > Damien is working on a new command line parser. we can have one while we want for the other. as it is now, we do not have none :) Esteban > >> >> Phil >> >> On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> This link may interest you command line people , it basically what I proposed as an idea early on >> >> https://github.com/guillep/Scale <https://github.com/guillep/Scale> >> >> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> I was replying to Thierry saying that we had issues with Pharo mixing metarepo6 with metarepo5 >> On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> On 22 Oct 2016, at 12:00, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >>> >>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did. >> >> fixed in what sense? >> >> Esteban >> >> >

Oct. 23, 2016

Re: [Pharo-dev] MetaLink to conditionally skip a method execution based on an arg

by Yuriy Tymchuk

Iâve also described the question with examples on SO: https://stackoverflow.com/questions/40200546/conditionally-skip-a-method-wi… > On 22 Oct 2016, at 23:13, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi. > > Imagine I have method a: and I want to skip the execution (return self or nil or whatever) when a: is evaluated with parameter 0. I have tried to add a meta link which will run instead of the method with a condition, but the condition did not workâ¦ I have tried to implement the metallic method to do nothing if the arg is 0 otherwise to perform the method, but I end up with an infinite loopâ¦ > > Did anybody do something like that already? Any suggestions? > > Uko

Oct. 23, 2016

keeping threads on topic

by Tudor Girba

Hi, The communication traffic around Pharo is constantly increasing and it is harder and harder to keep up with everything that is happening. On the one hand this is great because it shows that our project is growing healthily. On the other hand, it makes it harder for people to find the relevant thread and participate in discussions. This is problematic given that this mailing list is for discussing development issues that require specific expertise. To address this, I kindly ask everyone to keep a thread as much as possible on the topic meant by the title of the thread. Cheers, Tudor -- www.tudorgirba.com www.feenk.com "Value is always contextual."

Oct. 23, 2016

new text model / TxText [was Re: [ANN] Sparta v1.1]

by Tudor Girba

Hi Stef, We are not throwing away anything. The goal is not to produce a new model, the goal is to find one that matches the requirements. We already learnt a lot from TxText, but it has limitations in how to deal with things that are not only text. We have no intention of producing an unfinished text model :). This is a critical component for us. Please let us work for a couple of months and we get back with news. Cheers, Doru > On Oct 22, 2016, at 8:31 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi aliaksei > > I thought that you were just changing the internal representation of txText to use Ropes > and building on top of / improving txText > I did not think that you were throwing away all the work igor did. Because he spent a lot of time > > designing the text model and making it is scalable - and now I read that apparently it was not scalable enough. > I'm wondering what will happen if suddenly you disappear: we will get two unfinished textmodel > and use an old one? When do you think that you will have a working usable by other for real text model? > Stef > > Le 22/10/16 Ã 12:29, Aliaksei Syrel a Ã©crit : >> As Doru already mentioned text editor is an important part of the tools. There are some requirements a text editor should fulfil. >> >> â¢ Support of large files ( >> 100mb) >> â¢ Support of large pieces of text located in memory >> â¢ Allow developers to embed visual elements (pictures, interactive elements, custom elements) >> â¢ Support of more sophisticated layouts rather than line-based. For example columns. >> â¢ Line breaking >> â¢ Text wrapping >> â¢ Hyphens >> â¢ Should be fast >> Tests show that TxText model is very nice for basic cases, works well for "normal" use. >> However, when it comes to extreme cases linked list of spans just fails, while rope shows great performance - and it also scales. >> >> Cheers, >> Alex >> >> On 19 October 2016 at 23:51, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >> - Added initial text support, for instance rendering and high precision measurement. >> >> I look at code and it seems you implemented another one new text model? Why you not use TxText? >> > -- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."

Oct. 23, 2016

MetaLink to conditionally skip a method execution based on an arg

by Yuriy Tymchuk

Hi. Imagine I have method a: and I want to skip the execution (return self or nil or whatever) when a: is evaluated with parameter 0. I have tried to add a meta link which will run instead of the method with a condition, but the condition did not workâ¦ I have tried to implement the metallic method to do nothing if the arg is 0 otherwise to perform the method, but I end up with an infinite loopâ¦ Did anybody do something like that already? Any suggestions? Uko

Oct. 22, 2016

Re: [Pharo-dev] Pharo behind ALLSTOCKER marketplace

by stepharo

> - Localization > Our business target is world-wide. So localization is very important > topic. Currently ALLSTOCKER supports 4 languages and we will add > Chinese languages soon. > Translation strings are not only in Smalltalk code, but also in > Mustache templates. So we selected Soup for extracting translatable > strings in those templates. > http://smalltalkhub.com/#!/~PharoExtras/Soup > For managing translations, we use Gettext package. > http://smalltalkhub.com/#!/~PharoExtras/Gettext Hi masashi I wrote an email and it got lost so I retyping it. What I would love is that we improve/clean the international support in Pharo. I have the impression that we should - remove the stream conversion and language encodings and use Zn - I remember that usman told us that the support for gettext had some problems but I forgot. So any input and code to help us on that front would be good. Stef

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Todd Blanchard

Pointer? Sent from the road > On Oct 22, 2016, at 11:39, stepharo <stepharo(a)free.fr> wrote: > > This is what christophe is doing in cargo. > > Stef > > > >> Le 22/10/16 Ã 17:29, phil(a)highoctane.be a Ã©crit : >> Looks like we are on the same wavelength but... >> >> Look how this is done in PHP with Composer: >> >> - simple Json file >> - declares repositories >> - requires and requiresdev >> - uses semver versions >> >> so, 'composer install' will fetch and install deps. >> >> composer update will update deps. >> >> composer.json >> { >> "name": "zendframework/skeleton-application", >> "description": "Skeleton Application for ZF2", >> "license": "BSD-3-Clause", >> "keywords": [ >> "framework", >> "zf2" >> ], >> "homepage": "http://framework.zend.com/", >> "repositories": [{ >> "type": "vcs", >> "url": "https://github.com/RobLoach/firephp-core" >> }], >> "require": { >> "php": ">=5.5", >> "zendframework/zendframework": "~2.5", >> "zendframework/zftool": "dev-master", >> "firephp/firephp-core": "dev-master", >> "videlalvaro/php-amqplib": "^2.5" >> }, >> "require-dev": { >> "snapshotpl/zf-snap-event-debugger": "1.*", >> "zendframework/zend-developer-tools": "dev-master", >> "phpunit/phpunit": "4.8.*" >> } >> } >> >> In the JS Ecosystem, eg. bower.json >> >> { >> "name": "adsdaq", >> "homepage": "https://github.com/anais-it/adsdaq", >> "authors": [ >> "Philippe Back <phil(a)highoctane.be>" >> ], >> "description": "adsdaq-frontend", >> "main": "", >> "moduleType": [], >> "license": "Adlogix", >> "private": true, >> "ignore": [ >> "**/.*", >> "node_modules", >> "bower_components", >> "vendor/bower_components", >> "test", >> "tests" >> ], >> "dependencies": { >> "angular": "~1.4.7", >> "restangular": "~1.5.1", >> "lodash": "~3.10.1", >> "angular-route": "~1.4.7", >> "angular-spinner": "~0.8.0", >> "angular-bootstrap": "~0.14.3", >> "typeahead.js": "~0.11.1" >> } >> } >> >> >> So, basic module names in deps and semver. >> >> The st code you show is more cryptic. >> >> Is there a sweet spot ? >> >> Ston is a great format and is Json compatible if we are careful (meaning I can actually use vim and json syntax checkers plugins) >> >> St code is indeed more powerful but it leaves a lot of people in the dust with configurations. >> >> What do you think? >> >> Phil >> >> >> >> >>> On Sat, Oct 22, 2016 at 3:17 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> >>> On 10/22/16 12:04 AM, phil(a)highoctane.be wrote: >>>> We need some easy to use gem-style installer on the command line. >>> Phil, >>> >>> Since I am not really familiar with ruby, I'm not sure what you mean by "gem-style installer on the command line"? >>> >>> Depending upon what you mean, I think I agree:) >>> >>> For GsDevKit_home[1], I have arranged for bash scripts that can be used for building both stones and clients for GemStone. Here are the example scripts for Tugrik[2]: >>> >>> # Create Tugrik stone >>> createStone -u http://gsdevkit.github.io/GsDevKit_home/Tugrik.ston -i Tugrik -l Tugrik Tugrik 3.3.0 >>> >>> # Create Tugrik Pharo5.0 client >>> createClient -t pharo tugrik -l -v Pharo5.0 -z $GS_HOME/shared/repos/Tugrik/.smalltalk.ston >>> The Tugrik.ston file is a tODE object looks like the following[1] when materialized (basically a Metacello load script with additional info): ^ TDProjectSpecEntryDefinition new baseline: 'Tugrik' repository: 'github://dalehenrich/Tugrik:master/repository' loads: #('default'); installScript: ' project install --local --url=http://gsdevkit.github.io/GsDevKit_home/MongoTalk.ston project clone --https --local Tugrik'; postLoadScript: 'mount @/sys/stone/dirs/Tugrik/gsdevkit/tode /home tugrik'; status: #(#'inactive'); locked: false; yourself Their are fields for comments and a project url as well ... obviously other fields are possible ... the cool thing about this is that is a specification for a load rather than a Smalltalk load expression ... which means the repository can easily be re-targetted or the loads list changed, etc. Since Pharo doesn't have tODE:), I leverage the SmalltalkCI[4] configuration file for Tugrik[5], which looks like this: SmalltalkCISpec { #loading : [ SCIMetacelloLoadSpec { #baseline : 'Tugrik', #load : [ 'CI' ], #onWarningLog : true, #directory : 'repository', #platforms : [ #gemstone, #pharo ] } ], #configuring : [ SCIGemStoneServerConfigSpec { #defaultSessionName : 'Tugrik', #platforms : [ #gemstoneClient ] } ] } Very similar information, but has the advantage of being usable in GemStone, Squeak and Pharo ... I have an option for creating stones using a SmalltalkCI configuration file as well ... I've been thinking that I could add a MetacelloProjectLoadSpecification class to Metacello that is meant to be passed around as an object in STON format that combines the good bits of the TDProjectSpecEntryDefinition with the good bits of the SCIMetacelloLoadSpec and be available in GemStone, Pharo and Squeak ... then you'd just send #load to the object to trigger the install ... Is there anything in the "gem-style installer on the command line"that I'm missing? Am I completely off-base? Dale [1] https://github.com/GsDevKit/GsDevKit_home#open-source-development-kit-for-g… [2] https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client [3] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston [4] https://github.com/hpi-swa/smalltalkCI#smalltalkci--- [5] https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston

Oct. 22, 2016