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

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

by Eliot Miranda

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-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 <+33%206%2052%2070%2066%2013> >>> >>> >> >> >> -- >> Pablo Tesone. >> tesonep(a)gmail.com >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- _,,,^..^,,,_ best, Eliot

Aug. 1, 2017

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

by tesonep＠gmail.com

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. So the answer is that is not using Parcels or Fuel architecture because they are intended for different uses. 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-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 <+33%206%2052%2070%2066%2013> >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com > > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 1, 2017

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

by Eliot Miranda

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/lastSuccessfulBuild… >>>>> > >>>>> > Cheers, >>>>> > -- Pavel >>>>> > >>>>> >>> >>> -- >>> >>> Guille Polito >>> >>> Research Engineer >>> French National Center for Scientific Research - http://www.cnrs.fr >>> >>> >>> Web: http://guillep.github.io >>> Phone: +33 06 52 70 66 13 > > > > -- > Pablo Tesone. > tesonep(a)gmail.com

Aug. 1, 2017

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

by tesonep＠gmail.com

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-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 <+33%206%2052%2070%2066%2013> > > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 1, 2017

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

by Eliot Miranda

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/lastSuccessfulBuild… >>> > >>> > Cheers, >>> > -- Pavel >>> > >>> > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr > > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Aug. 1, 2017

Re: [Pharo-dev] Lots of "UTF8InvalidText: Invalid utf8 input detected" from OMBU

by Martin Dias

Hello: So, is this patch working fine? Cheers Martin On Thu, Jul 27, 2017 at 10:17 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Wed, Jul 26, 2017 at 6:36 AM, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> There's https://pharo.fogbugz.com/f/cases/20112/, your error could be the >> same. >> (a multibyte character crossing the initial-guess block boundary) >> >> As outlined there, the (temp) fix is to put an error handler around the >> nextEntryPositionIfFound:ifNone: call in refreshNewBlocksFrom: >> >> > Hi Henry, > > Thanks for the pointer. I patched my images with your workaround. I will > use it for a couple of days and I will later tell if you it seems to fix it > or not. > > Cheers, > > > >> Cheers, >> Henry >> >> >> >> -- >> View this message in context: http://forum.world.st/Lots-of- >> UTF8InvalidText-Invalid-utf8-input-detected-from-OMBU-tp4956 >> 734p4956805.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 1, 2017

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

by Denis Kudriashov

And I released new version with all fixes 2017-08-01 14:56 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Also try alt+left to navigation back in such cases. >> >> >> > I wasn't aware of those shortcuts. *Is there a list somewhere of all >> available shortcuts in Calypso? * I mean, those that are not obviously >> displayed on right click menu. >> > > There is no special tool for this. But you can browse all references to CmdShortcutCommandActivator. > It will gives you list of command classes which can be accessed by > shortcut. And in every found method you will see keymap. > > >> Maybe there are shortcuts for moving across panes? I always wanted >> that... say I am in the code area of a method and I would like to move to >> the package panel, or the class panel.. with the keyboard... > > > I not implemented it. If you know how to do it in Morphic with given morph > instance then you can try implement it by yourself. Look at > ClyShowMessageSenderCommand as example of command which interact with > browser. You can ask it for methodView, classView, packageView and so on. > They are all just morphs. > > > 2017-08-01 14:26 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Tue, Aug 1, 2017 at 9:10 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> >>> 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 >>> >> >> >> Well, I use it quite frequently. Whenever I am done with implementing a >> given feature, or fixing a given bug, I close everything, I evaluate a >> workspace that I always have at hand that does some cleanup, and I am ready >> to go to the next task. So I hate when I cannot easily close all windows. >> >> >> >>> >>> >>>> * 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. >>> >> >> >> mmmm weird. I tried again and I failed to reproduce it hahah. Ok..... >> ignore it... unless I find a reproducible case. >> >> >> >>> Also try alt+left to navigation back in such cases. >>> >>> >> >> I wasn't aware of those shortcuts. *Is there a list somewhere of all >> available shortcuts in Calypso? * I mean, those that are not obviously >> displayed on right click menu. >> Maybe there are shortcuts for moving across panes? I always wanted >> that... say I am in the code area of a method and I would like to move to >> the package panel, or the class panel.. with the keyboard... >> >> >> >> >>> * 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) >>> >> >> >> Awesome. Thanks. >> >> >> >>> >>> >>>> >>>> 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 >>>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Aug. 1, 2017

Re: [Pharo-dev] Epicea: Revert the removal of a class

by Martin Dias

Hi Cyril, This behavior comes from a lack of information in the system announcement. When Epicea recieves a ClassRemoved announcement, it comes with an "obsolete class" (whose method dictionary has been emptied before). I agree with you. So, the first step to announce a class removal with the required information. Solution 1: Announce ClassRemoved before converting the class in obsolete. One objection: then, the announcement's classname will be wrong because, when announced, the class wasn't removed yet. Another objection but less important is that it my be inconsistent with other related system announcements (e.g. ClassModifiedClassDefinition) because they are announced after the action was performed. Other objection also not very important is that is can have impact with current users of ClassRemoved, which already expect the class converted in obsolete. Solution 2: do not change anything in ClassRemoved but add a new announcement like ClassWillBeRemoved (or RemovingClass). Solution 3: add to ClassRemoved something like "nonMetaClassMethods" and "metaClassMethods" instance variables. This is kind of workaround but has no impact in users of ClassRemoved. Solution 4: before making the class obsolete, do self methodsDo: [:each | each removeFromSystem ]. Then a MethodRemoved will be announced for each method. I think this will have performance impact since Nautilus and other subscriptors to MethodRemoved will refresh their UI many times (for each method). But subscriptors can be adapted... or should... a similar scenario with many changes announced in a small time window occurs when Monticello loads a version (and I guess Iceberg too): each method loaded triggers UI refresh in tools. However, I can say the Epicea changes browser is prepared to this scenario because it delays its UI refresh some milliseconds after a change announcement happened. Sorry if too long. Cheers. Martin On Fri, Jul 28, 2017 at 1:14 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Hi, > > Today I tried to remove a class, go in Epicea and revert the removal of > the class. > > At the end the class was here but with no methods. Is that the normal > behaviour? I think it is a bug but since I don't really use Epicea a lot > for know I am not sure. > > Have a nice day. > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Aug. 1, 2017

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

by Denis Kudriashov

> > Also try alt+left to navigation back in such cases. > > > I wasn't aware of those shortcuts. *Is there a list somewhere of all > available shortcuts in Calypso? * I mean, those that are not obviously > displayed on right click menu. > There is no special tool for this. But you can browse all references to CmdShortcutCommandActivator. It will gives you list of command classes which can be accessed by shortcut. And in every found method you will see keymap. > Maybe there are shortcuts for moving across panes? I always wanted that... > say I am in the code area of a method and I would like to move to the > package panel, or the class panel.. with the keyboard... I not implemented it. If you know how to do it in Morphic with given morph instance then you can try implement it by yourself. Look at ClyShowMessageSenderCommand as example of command which interact with browser. You can ask it for methodView, classView, packageView and so on. They are all just morphs. 2017-08-01 14:26 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Tue, Aug 1, 2017 at 9:10 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> >> 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 >> > > > Well, I use it quite frequently. Whenever I am done with implementing a > given feature, or fixing a given bug, I close everything, I evaluate a > workspace that I always have at hand that does some cleanup, and I am ready > to go to the next task. So I hate when I cannot easily close all windows. > > > >> >> >>> * 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. >> > > > mmmm weird. I tried again and I failed to reproduce it hahah. Ok..... > ignore it... unless I find a reproducible case. > > > >> Also try alt+left to navigation back in such cases. >> >> > > I wasn't aware of those shortcuts. *Is there a list somewhere of all > available shortcuts in Calypso? * I mean, those that are not obviously > displayed on right click menu. > Maybe there are shortcuts for moving across panes? I always wanted that... > say I am in the code area of a method and I would like to move to the > package panel, or the class panel.. with the keyboard... > > > > >> * 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) >> > > > Awesome. Thanks. > > > >> >> >>> >>> 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 >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 1, 2017

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

by Mariano Martinez Peck

On Tue, Aug 1, 2017 at 9:10 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 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 > Well, I use it quite frequently. Whenever I am done with implementing a given feature, or fixing a given bug, I close everything, I evaluate a workspace that I always have at hand that does some cleanup, and I am ready to go to the next task. So I hate when I cannot easily close all windows. > > >> * 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. > mmmm weird. I tried again and I failed to reproduce it hahah. Ok..... ignore it... unless I find a reproducible case. > Also try alt+left to navigation back in such cases. > > I wasn't aware of those shortcuts. *Is there a list somewhere of all available shortcuts in Calypso? * I mean, those that are not obviously displayed on right click menu. Maybe there are shortcuts for moving across panes? I always wanted that... say I am in the code area of a method and I would like to move to the package panel, or the class panel.. with the keyboard... > * 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) > Awesome. Thanks. > > >> >> 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 >> > > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2017