- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Creating the smallest server runtime footprint

by Pavel Krivanek

2017-08-03 10:14 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > The easiest think you can do is to copy to your repository (or some other) > related packages from the Pharo repository (to do not have to clone it all): > > Metacello-GitBasedRepository.package > Metacello-GitHub.package > SUnit-Core.package > > and create baseline to load them. I already tried it so you can test it: > https://drive.google.com/open?id=0BzSsmZhqtUTeMVJacTZtdW5UQW8 > > Then you will do something like: > (accidental message send ;-) ) BASELINE=MetacelloGitBasedRepository pharo "$IMAGE_NAME.image" --no-default-preferences eval --save \ "Metacello new baseline: '$BASELINE'; repository: 'filetree://./PharoLambda/src'; load." BASELINE=Lambda pharo "$IMAGE_NAME.image" --no-default-preferences eval --save \ "Metacello new baseline: '$BASELINE'; repository: 'filetree://./PharoLambda/src'; load." As I tried that. The baseline of Lambda is then able to be loaded. -- Pavel > > > 2017-08-02 15:18 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > >> Ah, I think Iâm starting to get closer to what I needâ¦ >> >> So if I want to load in that last piece to enable more general remote >> loading - how do I figure out how to do that? Iâm trying to work out where >> the build steps for building up the image (can I see them in Jenkins? It >> wasnât clear to me if I can look it up? Or the BaselineOfIDE was mentioned >> - looking there I can see a few metacello and gofer packages - but then I >> guess Iâm looking for an easy Mcz I can use with the example below? >> >> Or do I just load Metacello as a git submodule and then it will be on my >> local filesystem to then bootstrap up? >> >> I guess Iâm trying to work out the best sustainable approach to getting >> to a good server based image that has minimal tools and the ability to >> easily load remote code for pre-req projects. >> >> Tim >> >> On 2 Aug 2017, at 07:05, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> Yes, you should be able to load an mcz in that image by doing: >> >> (MCDirectoryRepository new directory: 'where-your-mcz-is') >> loadVersionFromFileNamed: 'Metacello-GitBasedRepository-Author.1.mcz') >> load. >> >> Guille >> >> On Wed, Aug 2, 2017 at 7:57 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> >>> >>> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>> >>>> Hi Pavel - I tried it again and the problem is do with Metacello >>>> dependencies in your baseline. >>>> >>>> The SUnit baseline doesnât specify any additional dependencies to load >>>> (it just loads local packages), whereas my baseline that fails looks like >>>> this: >>>> >>>> baseline: spec >>>> <baseline> >>>> >>>> spec for: #common do: [ >>>> spec configuration: 'ZTimestamp' with: [ >>>> spec >>>> versionString: #stable; >>>> repository: 'http://mc.stfx.eu/Neo' ]. >>>> spec baseline: 'AWS' with: [ >>>> spec repository: 'github://newapplesho/aws-sdk- >>>> smalltalk:v1.10/pharo-repository' ]. >>>> spec >>>> package: 'Lambda' with: [ spec requires: {'ZTimestamp'. 'AWS'}]. >>>> ]. >>>> >>>> >>>> The âspec configuration: â¦.â Specifications cause the error: >>>> >>>> 25 UndefinedObject(Object)>>*doesNotUnderstand: #addTo:* >>>> 26 MCRepositoryGroup>>addRepository: >>>> >>>> If I remove those lines from my baseline above (as well the requires: >>>> reference to them) I can then successfully load my packages. >>>> >>>> So is this something the minimal image should support (otherwise how do >>>> you load external packages into your image without checking them in >>>> locally?) OR is there something simple I can checkin and load locally to >>>> return that behaviour? (Personally I think it would make sense to allow >>>> remote loading - Iâm guessing Pharo itself as a core has everything it >>>> needs - but if you want to do any experimentation on the core and need >>>> remote packages, you would hit this too - so it feels a bit limiting). >>>> >>> >>> The dependencies in th baseline are supported but the support for most >>> of external repositories (like package Metacello-GitBasedRepository) is >>> loaded at the end of bootstrapping process in BaselineOfIDE. We should >>> check/solve dependencies and move it into the minimal Pharo. For now you >>> can try to load it by yourself or work with already prepared local clones >>> of required repositories. >>> >>> -- Pavel >>> >>> >>> >>> >>>> >>>> Tim >>>> >>>> On 1 Aug 2017, at 10:06, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> wrote: >>>> >>>> >>>> >>>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>>> >>>>> I wasnât clear on which image to retry - the >>>>> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2- >>>>> Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip one still >>>>> shows as being last updated 7 days ago. >>>>> >>>>> The https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0 >>>>> -Step-04-01-ConfigurationOfMinimalPharo/ one gives me a mismatch >>>>> error: This interpreter (vers. 68021) cannot read image file (vers. 6521). >>>>> >>>>> The https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bi >>>>> t-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip one >>>>> gives me a walkback when trying to run my install script : >>>>> >>>>> 25 UndefinedObject(Object)>>*doesNotUnderstand: #addTo:* >>>>> 26 MCRepositoryGroup>>addRepository: >>>>> 27 createRepository >>>>> | repo | >>>>> repo := self project createRepository: self. >>>>> ^ MCRepositoryGroup default repositories >>>>> detect: [ :each | each = repo ] >>>>> ifNone: [ >>>>> MCRepositoryGroup default addRepository: repo. >>>>> repo ] in MetacelloRepositorySpec>>createRepository >>>>> >>>>> I think this is because the image doesnât support Metacello? As in: >>>>> >>>>> Metacello new >>>>> repository: 'filetree://../src'; >>>>> baseline: 'Lambda'; >>>>> load. >>>>> >>>>> >>>>> How do you guys load things into the minimal images (I thought you >>>>> used Metacello - but maybe you do it some other way?) >>>>> >>>>> I can use a big 6.1 image fine (as it has Metacello loaded) but Iâd >>>>> really like a minimal solution - that can load in libraries like AWS S3, or >>>>> XML parsing etc. and it seems like I should be a good customer for kicking >>>>> the tires on all of this. >>>>> >>>>> Tim >>>>> >>>>> >>>> I checked the 64-bit Pharo 7 minimal image and loading of baseline (of >>>> SUnit from pharo-project/pharo) works: >>>> >>>> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval --save "Metacello >>>> new baseline: 'SUnit'; repository: 'filetree://./pharo-core/src'; >>>> load." >>>> >>>> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval "TestCase suite run" >>>> >>>> Can you test it too? >>>> >>>> -- Pavel >>>> >>>> >>>> >>> >> >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr/> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io/> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> >> >> >

Aug. 3, 2017

Re: [Pharo-dev] Creating the smallest server runtime footprint

by Pavel Krivanek

The easiest think you can do is to copy to your repository (or some other) related packages from the Pharo repository (to do not have to clone it all): Metacello-GitBasedRepository.package Metacello-GitHub.package SUnit-Core.package and create baseline to load them. I already tried it so you can test it: https://drive.google.com/open?id=0BzSsmZhqtUTeMVJacTZtdW5UQW8 Then you will do something like: 2017-08-02 15:18 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > Ah, I think Iâm starting to get closer to what I needâ¦ > > So if I want to load in that last piece to enable more general remote > loading - how do I figure out how to do that? Iâm trying to work out where > the build steps for building up the image (can I see them in Jenkins? It > wasnât clear to me if I can look it up? Or the BaselineOfIDE was mentioned > - looking there I can see a few metacello and gofer packages - but then I > guess Iâm looking for an easy Mcz I can use with the example below? > > Or do I just load Metacello as a git submodule and then it will be on my > local filesystem to then bootstrap up? > > I guess Iâm trying to work out the best sustainable approach to getting to > a good server based image that has minimal tools and the ability to easily > load remote code for pre-req projects. > > Tim > > On 2 Aug 2017, at 07:05, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Yes, you should be able to load an mcz in that image by doing: > > (MCDirectoryRepository new directory: 'where-your-mcz-is') > loadVersionFromFileNamed: 'Metacello-GitBasedRepository-Author.1.mcz') > load. > > Guille > > On Wed, Aug 2, 2017 at 7:57 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> >> 2017-08-01 23:13 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> >>> Hi Pavel - I tried it again and the problem is do with Metacello >>> dependencies in your baseline. >>> >>> The SUnit baseline doesnât specify any additional dependencies to load >>> (it just loads local packages), whereas my baseline that fails looks like >>> this: >>> >>> baseline: spec >>> <baseline> >>> >>> spec for: #common do: [ >>> spec configuration: 'ZTimestamp' with: [ >>> spec >>> versionString: #stable; >>> repository: 'http://mc.stfx.eu/Neo' ]. >>> spec baseline: 'AWS' with: [ >>> spec repository: 'github://newapplesho/aws-sdk- >>> smalltalk:v1.10/pharo-repository' ]. >>> spec >>> package: 'Lambda' with: [ spec requires: {'ZTimestamp'. 'AWS'}]. >>> ]. >>> >>> >>> The âspec configuration: â¦.â Specifications cause the error: >>> >>> 25 UndefinedObject(Object)>>*doesNotUnderstand: #addTo:* >>> 26 MCRepositoryGroup>>addRepository: >>> >>> If I remove those lines from my baseline above (as well the requires: >>> reference to them) I can then successfully load my packages. >>> >>> So is this something the minimal image should support (otherwise how do >>> you load external packages into your image without checking them in >>> locally?) OR is there something simple I can checkin and load locally to >>> return that behaviour? (Personally I think it would make sense to allow >>> remote loading - Iâm guessing Pharo itself as a core has everything it >>> needs - but if you want to do any experimentation on the core and need >>> remote packages, you would hit this too - so it feels a bit limiting). >>> >> >> The dependencies in th baseline are supported but the support for most of >> external repositories (like package Metacello-GitBasedRepository) is loaded >> at the end of bootstrapping process in BaselineOfIDE. We should check/solve >> dependencies and move it into the minimal Pharo. For now you can try to >> load it by yourself or work with already prepared local clones of required >> repositories. >> >> -- Pavel >> >> >> >> >>> >>> Tim >>> >>> On 1 Aug 2017, at 10:06, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> wrote: >>> >>> >>> >>> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>> >>>> I wasnât clear on which image to retry - the https://ci.inria.fr/pharo/ >>>> job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccessfulBuild/ar >>>> tifact/Pharo-minimal-64.zip one still shows as being last updated 7 >>>> days ago. >>>> >>>> The https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0 >>>> -Step-04-01-ConfigurationOfMinimalPharo/ one gives me a mismatch >>>> error: This interpreter (vers. 68021) cannot read image file (vers. 6521). >>>> >>>> The https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bi >>>> t-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip one >>>> gives me a walkback when trying to run my install script : >>>> >>>> 25 UndefinedObject(Object)>>*doesNotUnderstand: #addTo:* >>>> 26 MCRepositoryGroup>>addRepository: >>>> 27 createRepository >>>> | repo | >>>> repo := self project createRepository: self. >>>> ^ MCRepositoryGroup default repositories >>>> detect: [ :each | each = repo ] >>>> ifNone: [ >>>> MCRepositoryGroup default addRepository: repo. >>>> repo ] in MetacelloRepositorySpec>>createRepository >>>> >>>> I think this is because the image doesnât support Metacello? As in: >>>> >>>> Metacello new >>>> repository: 'filetree://../src'; >>>> baseline: 'Lambda'; >>>> load. >>>> >>>> >>>> How do you guys load things into the minimal images (I thought you used >>>> Metacello - but maybe you do it some other way?) >>>> >>>> I can use a big 6.1 image fine (as it has Metacello loaded) but Iâd >>>> really like a minimal solution - that can load in libraries like AWS S3, or >>>> XML parsing etc. and it seems like I should be a good customer for kicking >>>> the tires on all of this. >>>> >>>> Tim >>>> >>>> >>> I checked the 64-bit Pharo 7 minimal image and loading of baseline (of >>> SUnit from pharo-project/pharo) works: >>> >>> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval --save "Metacello new >>> baseline: 'SUnit'; repository: 'filetree://./pharo-core/src'; load." >>> >>> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval "TestCase suite run" >>> >>> Can you test it too? >>> >>> -- Pavel >>> >>> >>> >> > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr/> > > > *Web:* *http://guillep.github.io* <http://guillep.github.io/> > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > > >

Aug. 3, 2017

Live Programming in Smalltalk development environments survey + raffle

by Juraj Kubelka

â âWe are apologize for multiple copies.â â Dear Smalltalker, Live programming frees developers from the "edit-compile-run" loop and allows people to interact with running programs very easily. Live programming is getting popular, but many of its features have been present in Smalltalk for a very long time. We want to understand how Smalltalk software developers use live programming features in practice. We would be grateful if you could participate in our 10-minute survey on this subject: http://bit.ly/2ufcg2D <http://bit.ly/2ufcg2D> As a thank you for your participation, you will be able to participate in a raffle to win a Smalltalk book of your choice. If you wish to participate, you will need to share your email with us, so that we can contact you. We will appreciate if you share the survey - Twitter post: https://twitter.com/JurajKubelka/status/893006267085709312 <https://twitter.com/JurajKubelka/status/893006267085709312> - Facebook post: https://www.facebook.com/juraj.kubelka/posts/10212505941300008 <https://www.facebook.com/juraj.kubelka/posts/10212505941300008> By participating in the survey you will: - help me to successfully finish my PhD, - push Smalltalk awareness in Live Programming research community, - bring new integrated electronic communication ideas, and - bring new ideas to improve our Smalltalk Live Programming experience :-) We will close the survey on Wednesday, August 9, 2017 AoE. Thank you and we really hope you enjoy participating in our survey! Juraj Kubelka, PhD Student at the University of Chile Romain Robbes, Professor at Free University of Bozen-Bolzano Alexandre Bergel, Professor at the University of Chile

Aug. 3, 2017

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

by Tudor Girba

Hi, > On Aug 2, 2017, at 5:53 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >>> - Deprecated FileStream & childs (Moved to Deprecated70) >> >> *Counts direct references to FileStream & subclasses in a 6.1 Moose image* >> Brave souls! > > It means that Moose will have to update. These classes are not gone > just deprecated. I am looking forward for moving to 7.0 and updating this part. Most people look at this type of upgrade like a chore, but I think it will be fun :) >> I hope the migration guide will be up to snuff, or I imagine a large >> percentage will be staying on 7.0 for a looong while :) > > Henrik did you mean 6.0? > We would to resurrect andre automatic evolver. But well this is work > when we do not know > how to set it up. This would be interesting. Doru >> >> Cheers, >> Henry >> >> >> >> -- >> View this message in context: http://forum.world.st/IMPORTANT-Following-changes-in-the-bootstrapping-proc… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

Aug. 3, 2017

Question about Bloc

by Alexandre Bergel

Hi! We were wondering whether someone did some workload with Bloc. How many elements can Bloc render, at the same time? Is there a support for Quad-Tree ? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 3, 2017

Re: [Pharo-dev] Creating the smallest server runtime footprint

by Tim Mackinnon

As an aside, Iâve just noticed that I get the same error in a normal 6.1 image when you try to load a baselineof package in Iceberg using the install menu option. So I wonder if this might actually be a bug in the image that the minimal version is getting as well? Tim > On 1 Aug 2017, at 22:13, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Pavel - I tried it again and the problem is do with Metacello dependencies in your baseline. > > The SUnit baseline doesnât specify any additional dependencies to load (it just loads local packages), whereas my baseline that fails looks like this: > > baseline: spec > <baseline> > > spec for: #common do: [ > spec configuration: 'ZTimestamp' with: [ > spec > versionString: #stable; > repository: 'http://mc.stfx.eu/Neo <http://mc.stfx.eu/Neo>' ]. > > spec baseline: 'AWS' with: [ > spec repository: 'github://newapplesho/aws-sdk-smalltalk:v1.10/pharo-repository <github://newapplesho/aws-sdk-smalltalk:v1.10/pharo-repository>' ]. > > spec > package: 'Lambda' with: [ spec requires: {'ZTimestamp'. 'AWS'}]. > > ]. > > > The âspec configuration: â¦.â Specifications cause the error: > > 25 UndefinedObject(Object)>>doesNotUnderstand: #addTo: > 26 MCRepositoryGroup>>addRepository: > > If I remove those lines from my baseline above (as well the requires: reference to them) I can then successfully load my packages. > > So is this something the minimal image should support (otherwise how do you load external packages into your image without checking them in locally?) OR is there something simple I can checkin and load locally to return that behaviour? (Personally I think it would make sense to allow remote loading - Iâm guessing Pharo itself as a core has everything it needs - but if you want to do any experimentation on the core and need remote packages, you would hit this too - so it feels a bit limiting). > > Tim > >> On 1 Aug 2017, at 10:06, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >> >> >> 2017-07-31 22:51 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> I wasnât clear on which image to retry - the https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccess… <https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccess…> one still shows as being last updated 7 days ago. >> >> The https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu… <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu…> one gives me a mismatch error: This interpreter (vers. 68021) cannot read image file (vers. 6521). >> >> The https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSu… <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSu…> one gives me a walkback when trying to run my install script : >> >> 25 UndefinedObject(Object)>>doesNotUnderstand: #addTo: >> 26 MCRepositoryGroup>>addRepository: >> 27 createRepository >> | repo | >> repo := self project createRepository: self. >> ^ MCRepositoryGroup default repositories >> detect: [ :each | each = repo ] >> ifNone: [ >> MCRepositoryGroup default addRepository: repo. >> repo ] in MetacelloRepositorySpec>>createRepository >> >> I think this is because the image doesnât support Metacello? As in: >> Metacello new >> repository: 'filetree://../src <>'; >> baseline: 'Lambda'; >> load. >> >> How do you guys load things into the minimal images (I thought you used Metacello - but maybe you do it some other way?) >> >> I can use a big 6.1 image fine (as it has Metacello loaded) but Iâd really like a minimal solution - that can load in libraries like AWS S3, or XML parsing etc. and it seems like I should be a good customer for kicking the tires on all of this. >> >> Tim >> >> >> I checked the 64-bit Pharo 7 minimal image and loading of baseline (of SUnit from pharo-project/pharo) works: >> >> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval --save "Metacello new baseline: 'SUnit'; repository: 'filetree://./pharo-core/src <filetree://./pharo-core/src>'; load." >> >> ./pharo Pharo7.0-minimal-64bit-b1625bf.image eval "TestCase suite run" >> >> Can you test it too? >> >> -- Pavel >

Aug. 2, 2017

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

by Henrik Sperre Johansen

Stephane Ducasse-3 wrote >>> - Deprecated FileStream & childs (Moved to Deprecated70) >> >> *Counts direct references to FileStream & subclasses in a 6.1 Moose >> image* >> Brave souls! > > It means that Moose will have to update. These classes are not gone > just deprecated. Not just Moose, also all the packages it depends on. Included in said image, at a cursory glance; - Metacello - Fuel - SmaCC - Beacon - Fame - Grease - PetitParser2 - Roassal2 - Rubric And that's just a quick count of the *direct* FileStream references, not including the majority of cases requiring rewrites as a result of FileHandle write/readStream now returning a pure binary stream / API of Zn stream being different from old File streams. Stephane Ducasse-3 wrote >> I hope the migration guide will be up to snuff, or I imagine a large >> percentage will be staying on 7.0 for a looong while :) > > Henrik did you mean 6.0? Deprecated in 70 means slated for removal in 80 / only deprecation warnings on use in 7.0, no? So going to 7.0 will still be possible in most cases, with warnings turned off. 8.0 is where the leap will be. Stephane Ducasse-3 wrote > We would to resurrect andre automatic evolver. But well this is work > when we do not know > how to set it up. Like I said, brave souls! Cheers, Henry -- View this message in context: http://forum.world.st/IMPORTANT-Following-changes-in-the-bootstrapping-proc… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 2, 2017

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

by Stephane Ducasse

>> - Deprecated FileStream & childs (Moved to Deprecated70) > > *Counts direct references to FileStream & subclasses in a 6.1 Moose image* > Brave souls! It means that Moose will have to update. These classes are not gone just deprecated. > I hope the migration guide will be up to snuff, or I imagine a large > percentage will be staying on 7.0 for a looong while :) Henrik did you mean 6.0? We would to resurrect andre automatic evolver. But well this is work when we do not know how to set it up. > > Cheers, > Henry > > > > -- > View this message in context: http://forum.world.st/IMPORTANT-Following-changes-in-the-bootstrapping-proc… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 2, 2017

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

by Stephane Ducasse

Thanks guille and pablo for the explanation. One day we will have to work on a fuel solution for binary code loading. On Wed, Aug 2, 2017 at 7:02 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > I think Pablo answered most of the questions. But there is another > important concern: Hermes is not designed to be a general purpose > serializer. So it not in it goals to be extensible or fast. The main goals > behind hermes are: > - to be small (actually smaller than the compiler) > - to have as few dependencies as possible > > This is because we want to have it in the first bootstrapped image to have > a small kernel with faster build time, and be able to load the compiler > afterwards using it. Concretely, after bootstrap we use Hermes to load only > four packages (Compiler + 3 dependencies). Once that is done, we can go > back into using the compiler to load the rest. > > We did not think about putting it at the level of monticello, that has to > be thought for the future. In any case, moving to git/filetree makes > sharing binary mcz more difficult. Another two points that hermes is not > managing so far to be a more general code loading solution is that it does > not manage source files (it installs methods without source) nor the > reloading/update of code. > > From an implementation/format point of view, Hermes writes something > somehow equivalent to a java .class file but with a package granularity. I > think it may be valuable to nicely document the format. That could allow > other dialects to have their implementation and share hermes files (delta > some runtime compatibility :) ). > > Guille > > On Tue, Aug 1, 2017 at 11:14 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> > wrote: > >> Hi Mariano, >> The definition is not serialized. What is serialized is all the >> information to regenerate the class (eg: superclass name, instance variable >> names, class variables names, share pool names, category, layout class, and >> so on). This information is later used to regenerate the class as it is >> created initially by the class builder and installer. The same happens with >> the methods, they are built up from scratch without using the compiler. The >> bytecode is stored, the literals are serialized and the information in the >> header is serialized, as it has to be rebuilt when install. >> >> The same is applicable to the traits and extension methods. >> >> Basically it can be seen as a class builder / installer, that get all the >> information from the serialized version and not from the text >> representation of the class or the methods. >> >> That's why I said Hermes is so couple with Pharo. >> >> Thanks for clarifying, I am starting to understand where yours doubts >> came from. >> >> Cheers, >> Pablo >> >> On Tue, Aug 1, 2017 at 10:52 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Tue, Aug 1, 2017 at 5:31 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> >>> wrote: >>> >>>> Hi, >>>> Yes for sure there are objects, and that is very powerful, but >>>> comparing the algorithm of serialization of Hermes with Fuel (I don't >>>> really know Parcels) is not possible. It is like comparing Filetree with >>>> Fuel, The problems they have to take care are completely different. >>>> >>>> Maybe I am not seeing the point. >>>> >>>> >>> Let me add one sentence that may explain Eliot questions... if you >>> serialize the class definition, then it means you would need the compiler. >>> I guess Eliot may be interested in NOT having the compiler at all and >>> instead bring classes directly from binary format (like Fuel / Tanker ) >>> >>> >>> >>> >>>> Cheers. >>>> >>>> On Tue, Aug 1, 2017 at 10:25 PM, Eliot Miranda <eliot.miranda(a)gmail.com >>>> > wrote: >>>> >>>>> Hi Pablo, >>>>> >>>>> On Tue, Aug 1, 2017 at 12:36 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Hi again, >>>>>> thanks for the clarification, I haven't understood the question >>>>>> initially, but now I think I can answer it. >>>>>> >>>>>> Hermes is only exporting the classes, not objects. so it does not >>>>>> have to handle complex graphs of objects. Basically it serializes the >>>>>> definition of the classes, traits and methods. Then they are loaded in >>>>>> sequence. The only caring during the generation is to serialize first the >>>>>> superclasses, and then the subclasses. There is no way of serializing >>>>>> objects outside the classes, methods, traits and literals in a method. >>>>>> >>>>> >>>>> Classes, traits, methods, literals *are* a graph of objects :-). The >>>>> Parcel architecture, from which Fuel derived its architecture, was designed >>>>> for loading code in VisualWorks. In fact, last time I looked Parcels were >>>>> used only to store code and not as a general purpose (de)serializer. >>>>> >>>>> So the answer is that is not using Parcels or Fuel architecture >>>>>> because they are intended for different uses. >>>>>> >>>>> >>>>> Well, I don't think that's the reason ;-), but fine. I understand >>>>> that it doesn't use this architecture. Thanks. >>>>> >>>>> >>>>>> Also the format itself has no special design or considerations to be >>>>>> fast to generate or fast to read (as It happens with Fuel) >>>>>> >>>>>> Cheers, >>>>>> Pablo >>>>>> >>>>>> On Tue, Aug 1, 2017 at 9:16 PM, Eliot Miranda < >>>>>> eliot.miranda(a)gmail.com> wrote: >>>>>> >>>>>>> Hi Pablo, >>>>>>> >>>>>>> I understand that Hermes has its own format. My question was >>>>>>> about architecture. The Parcels/Fuel architecture is, AFAIA, the best >>>>>>> architecture for binary storage because it is virtual, is fast to load and >>>>>>> cleanly separates loading from initialization. What do I mean? >>>>>>> >>>>>>> - concrete formats like ImageSegment are tied to internal >>>>>>> representations in the VM and do are difficult to read in forever FB >>>>>>> systems and very hard to write in foreign systems. So a virtual format >>>>>>> (like BOSS, Fuel, Parcels, etc) is better but unless done well can be slow >>>>>>> >>>>>>> - a first generation system like BOSS is a flattening of a graph >>>>>>> traversal using a simple grammar. Each phrase is either an object >>>>>>> reference (object id) or an object definition (object is followed by type >>>>>>> info and contents, contents being a sequence of phrases. This is slow to >>>>>>> parse (because each phrase must be decoded), and has invalid intermediate >>>>>>> states (e.g. a Set whose contents are not all present, hence whose external >>>>>>> hash may change during loading, etc). A second generation system like >>>>>>> Parcels and Fuel separates objects from references (nodes from arcs) and >>>>>>> batches object creation, grouping all instances of a given class for bulk, >>>>>>> and hence fast, instantiation. Following my the objects are the >>>>>>> references. So loading has three phases: >>>>>>> - instantiate the objects >>>>>>> - connect the graph by filling in object references >>>>>>> - initialize the objects that require it (e.g. rehash sets) >>>>>>> >>>>>>> Consequently the writer must be two pass, the first pass to collect >>>>>>> the objects in the graph and sort them by class, the second to write the >>>>>>> nodes followed by the references >>>>>>> >>>>>>> So let me ask again, does Hermes use the Parcels/Fuel architecture? >>>>>>> >>>>>>> _,,,^..^,,,_ (phone) >>>>>>> >>>>>>> On Aug 1, 2017, at 11:52 AM, "tesonep(a)gmail.com" <tesonep(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Eliot, >>>>>>> >>>>>>> The last version of Hermes, that I have generated today and have to >>>>>>> be tested for real yet, is able to load and save from and to 32 and 64 >>>>>>> bits, handling the conversion. Because the Hermes representation (if we can >>>>>>> call it like that, because is really simple, does not care about the >>>>>>> architecture). >>>>>>> >>>>>>> Hermes is using a custom format completely separated from Fuel or >>>>>>> any other tool. >>>>>>> >>>>>>> This is a consequence of the design of Hermes. Hermes has been >>>>>>> designed to only work as light way of loading code during the bootstrap. So >>>>>>> that, it is heavily coupled with Pharo (it can be changed, for example >>>>>>> implementing another loader / installer) and uses only really core classes. >>>>>>> >>>>>>> Of course it can be extended and used in another Smalltalk dialects, >>>>>>> but I am not sure if the tool can be useful for them, or even for the Pharo >>>>>>> community outside the Pharo bootstrap process. >>>>>>> >>>>>>> Today to be useful outside the bootstrap process, some work has to >>>>>>> be done (perhaps a lot), but mainly new use cases have to be thinked. Once >>>>>>> the Compiler, Monticello or Metacello is available, there is no need for >>>>>>> Hermes. It is only used to generate some binary loadable packages for the >>>>>>> compiler from the source code. >>>>>>> >>>>>>> Again, it was only thinked as a tool to improve the speed during the >>>>>>> bootstrap. However, if somebody has ideas to use it or want to collaborate >>>>>>> are of course welcomed. >>>>>>> >>>>>>> Hermes is actually in Github, because to me is more comfortable to >>>>>>> have it there, but if somebody is really wanting to use it.... we can >>>>>>> manage to have an export process to Smalltalkhub. >>>>>>> >>>>>>> I hope I have clarified a little the idea behind Hermes. >>>>>>> >>>>>>> Maybe you have better ideas of what can we do with it. >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 1, 2017 at 7:59 PM, Eliot Miranda < >>>>>>> eliot.miranda(a)gmail.com> wrote: >>>>>>> >>>>>>>> Hi Guille, >>>>>>>> >>>>>>>> On Aug 1, 2017, at 4:29 AM, Guillermo Polito < >>>>>>>> guillermopolito(a)gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 1, 2017 at 12:57 PM, philippe.back(a)highoctane.be < >>>>>>>> philippe.back(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> Massive. >>>>>>>>> >>>>>>>>> What is in the super small image? >>>>>>>>> Is Hermes going to be a generic binary content loader? >>>>>>>>> >>>>>>>> >>>>>>>> There is still work to do in this front. >>>>>>>> - Hermes only works for 32bits format. We should adapt it to 64 >>>>>>>> bits (immediate floats and so on...) >>>>>>>> - There is no format validation. We should add one for safety. >>>>>>>> >>>>>>>> >>>>>>>> Will Hermes be able to save on 32-bits and load on 64-bits and vice >>>>>>>> verse? >>>>>>>> >>>>>>>> Does Hermes use the Parcels/Fuel architecture of saving nodes, >>>>>>>> grouped by class, followed by the arcs? >>>>>>>> >>>>>>>> If yes to both of these, are you willing to keep it in Monticello >>>>>>>> and collaborate with the Squeak & Cuis communities in developing Hermes? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> On Aug 1, 2017 12:36, "Stephane Ducasse" <stepharo.self(a)gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Pavel >>>>>>>>>> >>>>>>>>>> This is super excellent! IMPRESSIVE. An image without the >>>>>>>>>> compiler and >>>>>>>>>> a reloadable compiler. >>>>>>>>>> Super cool. >>>>>>>>>> >>>>>>>>>> Stef >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Aug 1, 2017 at 11:57 AM, Pavel Krivanek >>>>>>>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>>>>>>> > Hello, >>>>>>>>>> > >>>>>>>>>> > we are checking a huge pull request #177 >>>>>>>>>> > (https://github.com/pharo-project/pharo/pull/177) that will >>>>>>>>>> change some >>>>>>>>>> > basics of the bootstrap process: >>>>>>>>>> > >>>>>>>>>> > Now we will bootstrap a smaller image that will not include >>>>>>>>>> compiler/parser. >>>>>>>>>> > Compiler and related packages are exported and loaded using a >>>>>>>>>> binary >>>>>>>>>> > exporter named Hermes. >>>>>>>>>> > The compiler is then used to load FileSystem and Monticello. >>>>>>>>>> The rest of the >>>>>>>>>> > bootstrap process will be the same as before. >>>>>>>>>> > As the result we will have faster bootstrap and better system >>>>>>>>>> modularization >>>>>>>>>> > and possibilities. >>>>>>>>>> > >>>>>>>>>> > It required some modularization efforts: >>>>>>>>>> > >>>>>>>>>> > - simplified initialization scripts >>>>>>>>>> > - Use Zinc converters and encoders instead of FilePathEncoder >>>>>>>>>> and old >>>>>>>>>> > TextConverter >>>>>>>>>> > - Use Stdio instead of FileStream >>>>>>>>>> > - Using File instead of FileSystem >>>>>>>>>> > - Deprecated FileStream & childs (Moved to Deprecated70) >>>>>>>>>> > - Extracted Path classes to their on package: FileSystem-Path >>>>>>>>>> > - Moved OpalEncoders to their own package. They are required by >>>>>>>>>> the runtime >>>>>>>>>> > (not only for compilation) >>>>>>>>>> > - Introduced AsciiCharset in the kernel to answer to #isLetter >>>>>>>>>> #isUppercase >>>>>>>>>> > and so on without requiring full Unicode tables from the >>>>>>>>>> beginning >>>>>>>>>> > - Cleaning up a bit the full exception logging infrastructure >>>>>>>>>> (streams, >>>>>>>>>> > transcript, files, stack printing...) >>>>>>>>>> > - Split Ring methods required for system navigation to the >>>>>>>>>> Ring-Navigation >>>>>>>>>> > package >>>>>>>>>> > - Remove usages of #translated in the kernel >>>>>>>>>> > - Refactored the bootstrapping classes to remove duplications >>>>>>>>>> > - Cleaning up dependencies in CompiledMethod>>printOn: >>>>>>>>>> > - fix path printing >>>>>>>>>> > >>>>>>>>>> > We need to merge these changes at once and of course it can >>>>>>>>>> cause some >>>>>>>>>> > conflicts with the existing pull requests or external code. >>>>>>>>>> Anyway, we need >>>>>>>>>> > to merge it as soon as possible. >>>>>>>>>> > >>>>>>>>>> > So please, try to look at the PR and test the resultant image >>>>>>>>>> [1] to avoid >>>>>>>>>> > some major problems. >>>>>>>>>> > >>>>>>>>>> > [1] >>>>>>>>>> > https://ci.inria.fr/pharo/view/7.0/job/70-PR-Check-Load/last >>>>>>>>>> SuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-9c06 >>>>>>>>>> 91d.zip >>>>>>>>>> > >>>>>>>>>> > Cheers, >>>>>>>>>> > -- Pavel >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Guille Polito >>>>>>>> >>>>>>>> >>>>>>>> Research Engineer >>>>>>>> >>>>>>>> French National Center for Scientific Research - >>>>>>>> *http://www.cnrs.fr* <http://www.cnrs.fr> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>>>> >>>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Pablo Tesone. >>>>>>> tesonep(a)gmail.com >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Pablo Tesone. >>>>>> tesonep(a)gmail.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> _,,,^..^,,,_ >>>>> best, Eliot >>>>> >>>> >>>> >>>> >>>> -- >>>> Pablo Tesone. >>>> tesonep(a)gmail.com >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Pablo Tesone. >> tesonep(a)gmail.com >> > > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Aug. 2, 2017

Re: [Pharo-dev] [IMPORTANT] Following changes in the bootstrapping process

by Henrik Sperre Johansen

Pavel Krivanek-3 wrote > - Deprecated FileStream & childs (Moved to Deprecated70) *Counts direct references to FileStream & subclasses in a 6.1 Moose image* Brave souls! I hope the migration guide will be up to snuff, or I imagine a large percentage will be staying on 7.0 for a looong while :) Cheers, Henry -- View this message in context: http://forum.world.st/IMPORTANT-Following-changes-in-the-bootstrapping-proc… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 2, 2017