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

Re: [Pharo-dev] Calypso browser and categories?

by Denis Kudriashov

2017-07-31 23:50 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Jul 31, 2017 at 6:15 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi Mariano. >> >> You right. Method for this was implemented but I forgot to use it in >> #selectClass: logic. >> I committed fix to dev branch. I will realze new version soon. >> >> > OK, great. Let me know when you want me to test it. I am glad it was a > "bug". I thought it might have been some "decision". > It was not a bug but missing feature :) > > >> But I am not sure that it is only issue you are talking about. >> > > Yeah, I figured I can see it elsewhere. But I will find them if there are > other places... > > > BTW, I also found some other small issues which I comment below. Do you > want me to open issues on github for them? > Yes, please :) > > * "Windows" -> "Delete all windows discarding edits" -> does not close > Calypso windows with none saved edits > Never use it. Now I look at implementation and it is super naive. Not sure that we should modify Calypso to satisfy this approach. I thing there are other tools which will be not closed by this command > * When I have a class opened, with a method opened, then I go to the class > comment tab and I save the class comment, calypso automatically gives me > focus > back to the "method tab" rather than staying in the class comment. This is > annoying as i like to save my class comment frequently and not they flip to > another tab. > Strangely I can not reproduce it. Do you see this all the time? Try open new browser and repeat it. Also try alt+left to navigation back in such cases. > * I wish the "new protocol" offers me the existing ones as I type...as I > normally re-use existing protocols (on purpose) and its easy to make small > typos or differences with the original ones. > Done. Use Iceberg to update SystemCommands project (metacello script could not work) > > Thoughts? > > Thanks! > > >> >> 2017-07-31 18:25 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> Hi Denis, >>> >>> I wanted to give a serious test to Calypso, that is, start using it all >>> day long. However, there is a critical thing I am missing, which is the >>> grouping of categories (inside packages). >>> >>> I do not want to start discussing again packages vs categories and what >>> are good and bad practices. I do have a few packages and each package may >>> have several categories inside. So... seeing all classes together inside a >>> package is not nice for me. >>> >>> Is there a way in calypso to auto-escope to category level? I mean... >>> say my package is XXX and I have categories XXX-A and XXX-B. I know I can >>> go to left side column and with the tree, I can go to XXX-A and I get what >>> I want. But, for example, when I browse a class of XXX-A, the "focus" of >>> the left side column is XXX and not XXX-A. So I am wondering if we can >>> make it auto-scope to the category everywhere in Calypso. >>> >>> Thanks in advance, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 1, 2017

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

by Stephane Ducasse

Hi phil We will see for hermes. Because we have to pay attention when loading binary and changing the code we may end up with desynchronised situation. But this opens a lot of possibilities. We could deploy a PharoApp as a mini image and a set of binary files. I want a process where we can write an application (not just a bunch of classes) and get a process until a full deploy. Esteban confirmed to me that he wants to push the desktop deploy front in this iteration. Stef 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? > > 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/lastSuccessfulBuild… >> > >> > Cheers, >> > -- Pavel >> > >> >

Aug. 1, 2017

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

by Stephane Ducasse

260k is really nice for a small kernel! On Tue, Aug 1, 2017 at 1:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2017-08-01 12:57 GMT+02:00 philippe.back(a)highoctane.be > <philippe.back(a)gmail.com>: >> >> Massive. >> >> What is in the super small image? > > > It is not super small. Currently it has about 5.3MB but it can be probably > less if we will do some cleaning before the image saving. The size was not > the priority but we are getting there. > We already have an experimental reduced image with Hermes that is able to be > bootstrapped under 2 minutes. The minimal system based on the current > code-base that is able to be bootstrapped has about 260kB. > > -- Pavel > > >> >> Is Hermes going to be a generic binary content loader? >> >> 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/lastSuccessfulBuild… >>> > >>> > Cheers, >>> > -- Pavel >>> > >>> >

Aug. 1, 2017

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

by Guillermo Polito

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. > > 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-9c0691d.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

Aug. 1, 2017

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

by Pavel Krivanek

The main credits go to Guille and Pablo. My role in this was very tiny. -- Pavel 2017-08-01 12:35 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > 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/ > lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-9c0691d.zip > > > > Cheers, > > -- Pavel > > > >

Aug. 1, 2017

Re: [Pharo-dev] Catalog down

by Stephane Ducasse

Tx christophe. On Tue, Aug 1, 2017 at 11:23 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Thanks! > > > Gesendet: Dienstag, 01. August 2017 um 10:48 Uhr > Von: "Christophe Demarey" <christophe.demarey(a)inria.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Catalog down > > It is nows back on line! > > Christophe > > > Le 1 aoÃ»t 2017 Ã 08:40, Torsten Bergmann <astares@gmx.de[mailto:astares@gmx.de]> a Ã©crit : > > It is still down. > Am 31.07.2017, 19:55, Esteban Lorenzano <estebanlm@gmail.com[mailto:estebanlm@gmail.com]> schrieb:It will be restarted at midnight > >> On 31 Jul 2017, at 19:51, Torsten Bergmann <astares@gmx.de[mailto:astares@gmx.de]> wrote: >> >> http://catalog.pharo.org/catalog/json[http://catalog.pharo.org/catalog/json] responds with "Service Temporarily Unavailable". >> Sabine already reported it this morning on Discord. >> >> Any idea? >> >> > >

Aug. 1, 2017

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

by Pavel Krivanek

2017-08-01 13:13 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > 2017-08-01 12:57 GMT+02:00 philippe.back(a)highoctane.be < > philippe.back(a)gmail.com>: > >> Massive. >> >> What is in the super small image? >> > > It is not super small. Currently it has about 5.3MB but it can be probably > less if we will do some cleaning before the image saving. The size was not > the priority but we are getting there. > the raw bootstrapped image has 3.6MB. > We already have an experimental reduced image with Hermes that is able to > be bootstrapped under 2 minutes. The minimal system based on the current > code-base that is able to be bootstrapped has about 260kB. > > -- Pavel > > > >> Is Hermes going to be a generic binary content loader? >> >> 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-9c0691d.zip >>> > >>> > Cheers, >>> > -- Pavel >>> > >>> >>> >

Aug. 1, 2017

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

by Pavel Krivanek

2017-08-01 12:57 GMT+02:00 philippe.back(a)highoctane.be < philippe.back(a)gmail.com>: > Massive. > > What is in the super small image? > It is not super small. Currently it has about 5.3MB but it can be probably less if we will do some cleaning before the image saving. The size was not the priority but we are getting there. We already have an experimental reduced image with Hermes that is able to be bootstrapped under 2 minutes. The minimal system based on the current code-base that is able to be bootstrapped has about 260kB. -- Pavel > Is Hermes going to be a generic binary content loader? > > 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-9c0691d.zip >> > >> > Cheers, >> > -- Pavel >> > >> >>

Aug. 1, 2017

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

by phil＠highoctane.be

Massive. What is in the super small image? Is Hermes going to be a generic binary content loader? Phil On Aug 1, 2017 11:58, "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/ lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-9c0691d.zip Cheers, -- Pavel

Aug. 1, 2017

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

by philippe.back＠highoctane.be

Massive. What is in the super small image? Is Hermes going to be a generic binary content loader? 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/ > lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-9c0691d.zip > > > > Cheers, > > -- Pavel > > > >

Aug. 1, 2017