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

[Pharo 8.0] Build #633: Delete warnings of references between classes that will be remove

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #633 was: FAILURE. The Pull Request #4295 was integrated: " Delete warnings of references between classes that will be remove" Pull request url: https://github.com/pharo-project/pharo/pull/4295 Issue Url: https://github.com/pharo-project/pharo/issues/Removeclasses Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 15, 2019

[Pharo 8.0] Build #632: 2540-self-theme-settings-fadedBackgroundWindows-is-overzealous-violation-of-LOD

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #632 was: FAILURE. The Pull Request #4312 was integrated: "2540-self-theme-settings-fadedBackgroundWindows-is-overzealous-violation-of-LOD" Pull request url: https://github.com/pharo-project/pharo/pull/4312 Issue Url: https://github.com/pharo-project/pharo/issues/2540 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 15, 2019

[Pharo 8.0] Build #631: Improve-stability-of-menubar

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #631 was: FAILURE. The Pull Request #4326 was integrated: "Improve-stability-of-menubar" Pull request url: https://github.com/pharo-project/pharo/pull/4326 Issue Url: https://github.com/pharo-project/pharo/issues/Improve Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 15, 2019

Re: [Pharo-dev] machine learning for code completion

by ducasse

hello miroslava you take a NLP approach and I do not know if it will be working Now people like proksch and mezini took a statiscal approach. I would really like to see if we can apply the same technics to Pharo completion and measure the difference. It could be a really nice master (even from a data scientist point of view) > On 15 Aug 2019, at 00:01, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> wrote: > > > From: Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> > Subject: machine learning for code completion > Date: 15 August 2019 at 00:01:23 CEST > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > for anyone interested, made a blog post about researching some of the existing approaches of combining ML to improve code completion. in pharo we want to try training the n-gram model. have a slight idea of how it might be implemented in practice but mostly still trying to figure it out, so if anyone else has some suggestions/ideas/tips that would be great > > link for the blog post : https://medium.com/@myroslavarm/machine-learning-for-code-completion-258379… <https://medium.com/@myroslavarm/machine-learning-for-code-completion-258379…> > > cheers, > myroslava > >

Aug. 15, 2019

machine learning for code completion

by Myroslava Romaniuk

for anyone interested, made a blog post about researching some of the existing approaches of combining ML to improve code completion. in pharo we want to try training the n-gram model. have a slight idea of how it might be implemented in practice but mostly still trying to figure it out, so if anyone else has some suggestions/ideas/tips that would be great link for the blog post : https://medium.com/@myroslavarm/machine-learning-for-code-completion-258379… cheers, myroslava

Aug. 14, 2019

[Pharo 7.0] Build #168: BackPort Pharo7: Moved becomeForward from Object to ProtoObject where it belongs

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #168 was: SUCCESS. The Pull Request #4084 was integrated: "BackPort Pharo7: Moved becomeForward from Object to ProtoObject where it belongs" Pull request url: https://github.com/pharo-project/pharo/pull/4084 Issue Url: https://pharo.fogbugz.com/f/cases/Pharo7.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

[Pharo 7.0] Build #167: BackPort Pharo7: Moved becomeForward from Object to ProtoObject where it belongs

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #167 was: FAILURE. The Pull Request #4084 was integrated: "BackPort Pharo7: Moved becomeForward from Object to ProtoObject where it belongs" Pull request url: https://github.com/pharo-project/pharo/pull/4084 Issue Url: https://pharo.fogbugz.com/f/cases/Pharo7.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

Re: [Pharo-dev] problem with pushing to github

by milton mamani

+1 MacOS pharo8x64 El mar., 13 ago. 2019 a las 13:31, Myroslava Romaniuk via Pharo-dev (< pharo-dev(a)lists.pharo.org>) escribiÃ³: > Hi > > saw there's a lot going on with iceberg and spec today so likely this is > related. Just created (20 mins ago) a new image to push a PR to pharo, and > usually in a new image you have to fill in your credentials and you had > 'accept' and 'ok' buttons (ok - to accept credentials, accept - to push). > Now there's no 'accept' button and it doesn't push my changes anymore. Am i > doing something wrong or is this a bug? > > P.S. i'm on windows, latest pharo 8. > > Best regards, > Myroslava >

Aug. 13, 2019

Re: [Pharo-dev] [Pharo-users] Information on Spec development

by Cyril Ferlicot

On Tue, Aug 13, 2019 at 3:25 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > No, you are not :) > #asSpAdapter will be removed. > > You are looking for SpMorphPresenter (and/or the method SpPresenter>>newMorph) > In the Spec repository I deprecated #asSpAdapter with a mesage explaining SpMorphPresenter should be used. It will be integrated in next Spec integration. > Esteban > > -- Cyril Ferlicot https://ferlicot.fr

Aug. 13, 2019

Re: [Pharo-dev] [Pharo-users] Information on Spec development

by Esteban Lorenzano

> On 13 Aug 2019, at 15:19, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Aug 13, 2019 at 2:59 PM Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> Ah yes, I just wrote on discord. I did a tool in spec2 which I cannot use in the newest pharo. The #asSpecAdapter uses still MorphicGenericAdapter instead of SpMorphicGenericAdapter. Iceberg needs the former, my tool the latter. What is the strategy for that. For now I did a #asSpec2Adapter in my image that return the SpMorphic.. class. >> > Hi, > > The extensions in Spec2 are renamed to not conflict with Spec 1. You > are looking for #asSpAdapter ;) No, you are not :) #asSpAdapter will be removed. You are looking for SpMorphPresenter (and/or the method SpPresenter>>newMorph) Esteban > >> Norbert >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Aug. 13, 2019

[Pharo 8.0] Build #630: 4302-Code-completion-fix-extended-completion-for-NECController

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #630 was: SUCCESS. The Pull Request #4303 was integrated: "4302-Code-completion-fix-extended-completion-for-NECController" Pull request url: https://github.com/pharo-project/pharo/pull/4303 Issue Url: https://github.com/pharo-project/pharo/issues/4302 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

Re: [Pharo-dev] [Pharo-users] Information on Spec development

by Cyril Ferlicot

On Tue, Aug 13, 2019 at 2:59 PM Norbert Hartl <norbert(a)hartl.name> wrote: > > > Ah yes, I just wrote on discord. I did a tool in spec2 which I cannot use in the newest pharo. The #asSpecAdapter uses still MorphicGenericAdapter instead of SpMorphicGenericAdapter. Iceberg needs the former, my tool the latter. What is the strategy for that. For now I did a #asSpec2Adapter in my image that return the SpMorphic.. class. > Hi, The extensions in Spec2 are renamed to not conflict with Spec 1. You are looking for #asSpAdapter ;) > Norbert > > -- Cyril Ferlicot https://ferlicot.fr

Aug. 13, 2019

Re: [Pharo-dev] [Pharo-users] Information on Spec development

by Torsten Bergmann

Cyril wrote > Until now, the T is before the prefix. (For example TIceXXX for > Iceberg). So I followed what was already done. But then IMHO Iceberg is wrong too and do not correctly and consistently use their own prefix in front of classes/traits. See other samples like traits in which are also there already: Epicea -> EpTEventVisitor Fuel -> FLTGlobalClassOrTraitSerializationTest Glamour -> GLMTBlockTags Moose Algos -> MalTEdgeNode ... and where "prefix" is first as it should be. There are several reasons why "prefix" should be first: 1. As the name says: it is a prefix - so it would be obvious to have it in front of the class or trait name. 2. Prefixes are a workaround because we do not have namespaces (yet). Following the "prefix" always first rule we could later have a separation into namespaces more easily later when migrating. 3. If someone uses a prefix starting with a "T" too, like "TPL" for Template library then people get easily confused with class/trait mix of "TTPL" and "TPLT" looking like a typo or thinking all are traits because "T" is the first. Therefore - Prefix should be two (as in Seaside), ideally three letters and ideally in uppercase IMHO we should define a rule to have three uppercase letters at least for the base image. - order should be "prefix" and then class or trait name (where trait names start with "T". Smalltalk provides lots of freedom. But without rules and discipline it easily ends up in inconsistencies, chaos, a mess... Looks like even Pharo engineers miss a code guide these days ... Bye T.

Aug. 13, 2019

Re: [Pharo-dev] [Pharo-users] Information on Spec development

by Norbert Hartl

> Am 13.08.2019 um 12:28 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Thanks for pushing this Cyril! > This will let us move forward with Iceberg too :) Ah yes, I just wrote on discord. I did a tool in spec2 which I cannot use in the newest pharo. The #asSpecAdapter uses still MorphicGenericAdapter instead of SpMorphicGenericAdapter. Iceberg needs the former, my tool the latter. What is the strategy for that. For now I did a #asSpec2Adapter in my image that return the SpMorphic.. class. Norbert > >> El 13 ago 2019, a las 12:15, Cyril Ferlicot <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> escribiÃ³: >> >> On Thu, Jun 20, 2019 at 5:29 PM Cyril Ferlicot <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: >>> >>> Hello everyone! >>> >>> This is an important update about the development of Spec. >>> >>> As you might have heard, we are working on Spec to release a new >>> version in Pharo 8. One goal is to unify all Pharo interfaces behind >>> one GUI framework and a second goal is to allow multiple back-ends >>> (Morphic but also GTK, Bloc, ...). To reach those goals we have been >>> updating the current version of Spec. We see now, however, that >>> updating Spec directly creates troubles with migration. For example, >>> we currently have a lot of deprecation warnings in Iceberg, because we >>> can't update it without breaking Pharo 7 compatibility. >>> >>> After some discussions between the engineers working on Spec, here is >>> our plan to improve the situation: We will copy all classes of Spec >>> and rename them with the "Sp" prefix. (We will also ensure that every >>> class of Spec started with the same prefix for consistency). For >>> extensions methods, we will rename them to have a version different >>> from Spec 1 (The spec from Pharo 7). Once done we will integrate this >>> new version in Pharo 8. From there we will wait some weeks to let >>> users who started to use the updated Spec change their projects to use >>> this new Spec2. Finally, we will revert all changes that happened on >>> Spec 1 and deprecate the packages. We hope this will make things >>> easier for everyone. >>> >>> Have a nice day! >> >> Hi, >> >> The revert of changes of Spec 1 is now done in Pharo 8. >> >> Spec 1 is now in the same state than in Pharo 7 and Spec2 can live next to it. >> All classes of Spec2 start with the Sp or TSp prefix. >> >> Have a nice day. >> >>> >>> -- >>> Cyril Ferlicot >>> https://ferlicot.fr <https://ferlicot.fr/> >> >> >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr <https://ferlicot.fr/>

Aug. 13, 2019

[Pharo 8.0] Build #629: 4280-Code-completion-DNU-inside-literal-array

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #629 was: FAILURE. The Pull Request #4301 was integrated: "4280-Code-completion-DNU-inside-literal-array" Pull request url: https://github.com/pharo-project/pharo/pull/4301 Issue Url: https://github.com/pharo-project/pharo/issues/4280 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

Re: [Pharo-dev] [Pharo-users] Information on Spec development

by Cyril Ferlicot

On Tue, Aug 13, 2019 at 1:35 PM Torsten Bergmann <astares(a)gmx.de> wrote: > > Cyril Ferlicot wrote: > >The revert of changes of Spec 1 is now done in Pharo 8. > > Nice - lots of work. Thanks!!! > > > All classes of Spec2 start with the Sp or TSp prefix. > > Maybe I'm wrong but: > > If "Sp" is the prefix for Spec2 and trait names start with "T" we should > used SpT... for traits, no? > Until now, the T is before the prefix. (For example TIceXXX for Iceberg). So I followed what was already done. > Otherwise it would not be a prefix ... > > Thanks > T. > -- Cyril Ferlicot https://ferlicot.fr

Aug. 13, 2019

Re: [Pharo-dev] [Pharo-users] Information on Spec development

by Torsten Bergmann

Cyril Ferlicot wrote: >The revert of changes of Spec 1 is now done in Pharo 8. Nice - lots of work. Thanks!!! > All classes of Spec2 start with the Sp or TSp prefix. Maybe I'm wrong but: If "Sp" is the prefix for Spec2 and trait names start with "T" we should used SpT... for traits, no? Otherwise it would not be a prefix ... Thanks T.

Aug. 13, 2019

problem with pushing to github

by Myroslava Romaniuk

Hi saw there's a lot going on with iceberg and spec today so likely this is related. Just created (20 mins ago) a new image to push a PR to pharo, and usually in a new image you have to fill in your credentials and you had 'accept' and 'ok' buttons (ok - to accept credentials, accept - to push). Now there's no 'accept' button and it doesn't push my changes anymore. Am i doing something wrong or is this a bug? P.S. i'm on windows, latest pharo 8. Best regards, Myroslava

Aug. 13, 2019

[Pharo 8.0] Build #628: Revert-Spec1-changes

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #628 was: FAILURE. The Pull Request #4278 was integrated: "Revert-Spec1-changes" Pull request url: https://github.com/pharo-project/pharo/pull/4278 Issue Url: https://github.com/pharo-project/pharo/issues/Revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

Re: [Pharo-dev] [Pharo-users] Information on Spec development

by Guillermo Polito

Thanks for pushing this Cyril! This will let us move forward with Iceberg too :) > El 13 ago 2019, a las 12:15, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> escribiÃ³: > > On Thu, Jun 20, 2019 at 5:29 PM Cyril Ferlicot <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: >> >> Hello everyone! >> >> This is an important update about the development of Spec. >> >> As you might have heard, we are working on Spec to release a new >> version in Pharo 8. One goal is to unify all Pharo interfaces behind >> one GUI framework and a second goal is to allow multiple back-ends >> (Morphic but also GTK, Bloc, ...). To reach those goals we have been >> updating the current version of Spec. We see now, however, that >> updating Spec directly creates troubles with migration. For example, >> we currently have a lot of deprecation warnings in Iceberg, because we >> can't update it without breaking Pharo 7 compatibility. >> >> After some discussions between the engineers working on Spec, here is >> our plan to improve the situation: We will copy all classes of Spec >> and rename them with the "Sp" prefix. (We will also ensure that every >> class of Spec started with the same prefix for consistency). For >> extensions methods, we will rename them to have a version different >> from Spec 1 (The spec from Pharo 7). Once done we will integrate this >> new version in Pharo 8. From there we will wait some weeks to let >> users who started to use the updated Spec change their projects to use >> this new Spec2. Finally, we will revert all changes that happened on >> Spec 1 and deprecate the packages. We hope this will make things >> easier for everyone. >> >> Have a nice day! > > Hi, > > The revert of changes of Spec 1 is now done in Pharo 8. > > Spec 1 is now in the same state than in Pharo 7 and Spec2 can live next to it. > All classes of Spec2 start with the Sp or TSp prefix. > > Have a nice day. > >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr <https://ferlicot.fr/> > > > > -- > Cyril Ferlicot > https://ferlicot.fr <https://ferlicot.fr/>

Aug. 13, 2019

[Pharo 8.0] Build #627: 4194-Missing-refactoring-Abstract-instance-variable

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #627 was: SUCCESS. The Pull Request #4199 was integrated: "4194-Missing-refactoring-Abstract-instance-variable" Pull request url: https://github.com/pharo-project/pharo/pull/4199 Issue Url: https://github.com/pharo-project/pharo/issues/4194 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

Re: [Pharo-dev] Information on Spec development

by Cyril Ferlicot

On Thu, Jun 20, 2019 at 5:29 PM Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hello everyone! > > This is an important update about the development of Spec. > > As you might have heard, we are working on Spec to release a new > version in Pharo 8. One goal is to unify all Pharo interfaces behind > one GUI framework and a second goal is to allow multiple back-ends > (Morphic but also GTK, Bloc, ...). To reach those goals we have been > updating the current version of Spec. We see now, however, that > updating Spec directly creates troubles with migration. For example, > we currently have a lot of deprecation warnings in Iceberg, because we > can't update it without breaking Pharo 7 compatibility. > > After some discussions between the engineers working on Spec, here is > our plan to improve the situation: We will copy all classes of Spec > and rename them with the "Sp" prefix. (We will also ensure that every > class of Spec started with the same prefix for consistency). For > extensions methods, we will rename them to have a version different > from Spec 1 (The spec from Pharo 7). Once done we will integrate this > new version in Pharo 8. From there we will wait some weeks to let > users who started to use the updated Spec change their projects to use > this new Spec2. Finally, we will revert all changes that happened on > Spec 1 and deprecate the packages. We hope this will make things > easier for everyone. > > Have a nice day! Hi, The revert of changes of Spec 1 is now done in Pharo 8. Spec 1 is now in the same state than in Pharo 7 and Spec2 can live next to it. All classes of Spec2 start with the Sp or TSp prefix. Have a nice day. > > -- > Cyril Ferlicot > https://ferlicot.fr -- Cyril Ferlicot https://ferlicot.fr

Aug. 13, 2019

[Pharo 8.0] Build #626: 4298-Calypso-does-not-show-empty-protocols

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #626 was: SUCCESS. The Pull Request #4299 was integrated: "4298-Calypso-does-not-show-empty-protocols" Pull request url: https://github.com/pharo-project/pharo/pull/4299 Issue Url: https://github.com/pharo-project/pharo/issues/4298 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

[Pharo 8.0] Build #625: Update-manually-resolved-dependencies

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #625 was: FAILURE. The Pull Request #4285 was integrated: "Update-manually-resolved-dependencies" Pull request url: https://github.com/pharo-project/pharo/pull/4285 Issue Url: https://github.com/pharo-project/pharo/issues/Update Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

Re: [Pharo-dev] Impossible to create new protocol?

by Cyril Ferlicot

On Tue, Aug 13, 2019 at 9:18 AM ducasse <stepharo(a)netcourrier.com> wrote: > > Tx pavel. > I ask cyril to fix it :) > https://github.com/pharo-project/pharo/pull/4299 > > -- Cyril Ferlicot https://ferlicot.fr

Aug. 13, 2019

[Pharo 8.0] Build #624: Update order of method list (RBPushDownPreview and RBPushUpPreview )

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #624 was: FAILURE. The Pull Request #4296 was integrated: "Update order of method list (RBPushDownPreview and RBPushUpPreview )" Pull request url: https://github.com/pharo-project/pharo/pull/4296 Issue Url: https://github.com/pharo-project/pharo/issues/ChangeToAlphabeticalOrder Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

Re: [Pharo-dev] Impossible to create new protocol?

by ducasse

Tx pavel. I ask cyril to fix it :) > On 13 Aug 2019, at 09:09, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > yes, the tagsForAllMethods method now hides protocols without methods: > allProtocols select: [ :each | each methods anySatisfy: ... > > Ãºt 13. 8. 2019 v 9:05 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> napsal: > introduced in build.613. This is probably the source of this issue: https://github.com/pharo-project/pharo/commit/a0706a080383be50fde8aa90d1709… <https://github.com/pharo-project/pharo/commit/a0706a080383be50fde8aa90d1709…> > Ãºt 13. 8. 2019 v 8:53 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> napsal: > on three days old image (build.610) it worked > > Ãºt 13. 8. 2019 v 8:50 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> napsal: > I'm confirming this issue > > po 12. 8. 2019 v 21:55 odesÃlatel ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> napsal: > Hi > > In latest pharo version (we broke a bit iceberg and it will be fixed) I cannot add a new protocol. > Nothing happen once I type a new name. > > Is it something that only happen to me? > > S > > >

Aug. 13, 2019

Re: [Pharo-dev] Impossible to create new protocol?

by Pavel Krivanek

yes, the tagsForAllMethods method now hides protocols without methods: allProtocols select: [ :each | each methods anySatisfy: ... Ãºt 13. 8. 2019 v 9:05 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com> napsal: > introduced in build.613. This is probably the source of this issue: > https://github.com/pharo-project/pharo/commit/a0706a080383be50fde8aa90d1709… > > Ãºt 13. 8. 2019 v 8:53 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com> > napsal: > >> on three days old image (build.610) it worked >> >> Ãºt 13. 8. 2019 v 8:50 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com> >> napsal: >> >>> I'm confirming this issue >>> >>> po 12. 8. 2019 v 21:55 odesÃlatel ducasse <stepharo(a)netcourrier.com> >>> napsal: >>> >>>> Hi >>>> >>>> In latest pharo version (we broke a bit iceberg and it will be fixed) I >>>> cannot add a new protocol. >>>> Nothing happen once I type a new name. >>>> >>>> Is it something that only happen to me? >>>> >>>> S >>>> >>>> >>>> >>>>

Aug. 13, 2019

[Pharo 8.0] Build #623: Do-not-flush-all-caches-when-a-class-is-removed

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #623 was: FAILURE. The Pull Request #4205 was integrated: "Do-not-flush-all-caches-when-a-class-is-removed" Pull request url: https://github.com/pharo-project/pharo/pull/4205 Issue Url: https://github.com/pharo-project/pharo/issues/Do Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

Re: [Pharo-dev] Impossible to create new protocol?

by Pavel Krivanek

introduced in build.613. This is probably the source of this issue: https://github.com/pharo-project/pharo/commit/a0706a080383be50fde8aa90d1709… Ãºt 13. 8. 2019 v 8:53 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com> napsal: > on three days old image (build.610) it worked > > Ãºt 13. 8. 2019 v 8:50 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com> > napsal: > >> I'm confirming this issue >> >> po 12. 8. 2019 v 21:55 odesÃlatel ducasse <stepharo(a)netcourrier.com> >> napsal: >> >>> Hi >>> >>> In latest pharo version (we broke a bit iceberg and it will be fixed) I >>> cannot add a new protocol. >>> Nothing happen once I type a new name. >>> >>> Is it something that only happen to me? >>> >>> S >>> >>> >>> >>>

Aug. 13, 2019

Re: [Pharo-dev] Impossible to create new protocol?

by Pavel Krivanek

on three days old image (build.610) it worked Ãºt 13. 8. 2019 v 8:50 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com> napsal: > I'm confirming this issue > > po 12. 8. 2019 v 21:55 odesÃlatel ducasse <stepharo(a)netcourrier.com> > napsal: > >> Hi >> >> In latest pharo version (we broke a bit iceberg and it will be fixed) I >> cannot add a new protocol. >> Nothing happen once I type a new name. >> >> Is it something that only happen to me? >> >> S >> >> >> >>

Aug. 13, 2019

Re: [Pharo-dev] Impossible to create new protocol?

by Pavel Krivanek

I'm confirming this issue po 12. 8. 2019 v 21:55 odesÃlatel ducasse <stepharo(a)netcourrier.com> napsal: > Hi > > In latest pharo version (we broke a bit iceberg and it will be fixed) I > cannot add a new protocol. > Nothing happen once I type a new name. > > Is it something that only happen to me? > > S > > > >

Aug. 13, 2019

[Pharo 8.0] Build #622: 4281-Deprecation-should-be-transitif

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #622 was: FAILURE. The Pull Request #4283 was integrated: "4281-Deprecation-should-be-transitif" Pull request url: https://github.com/pharo-project/pharo/pull/4283 Issue Url: https://github.com/pharo-project/pharo/issues/4281 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 13, 2019

[Pharo 8.0] Build #621: 4271-Trait-adding-duplicated-slot-error-is-not-explicit-enough

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #621 was: FAILURE. The Pull Request #4289 was integrated: "4271-Trait-adding-duplicated-slot-error-is-not-explicit-enough" Pull request url: https://github.com/pharo-project/pharo/pull/4289 Issue Url: https://github.com/pharo-project/pharo/issues/4271 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

[Pharo 8.0] Build #620: Commander-SpecSupport should be loaded

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #620 was: FAILURE. The Pull Request #4292 was integrated: "Commander-SpecSupport should be loaded" Pull request url: https://github.com/pharo-project/pharo/pull/4292 Issue Url: https://github.com/pharo-project/pharo/issues/commander Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

Impossible to create new protocol?

by ducasse

Hi In latest pharo version (we broke a bit iceberg and it will be fixed) I cannot add a new protocol. Nothing happen once I type a new name. Is it something that only happen to me? S

Aug. 12, 2019

[Pharo 8.0] Build #619: Quick-migration-of-Epicea-to-Spec2

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #619 was: FAILURE. The Pull Request #4288 was integrated: "Quick-migration-of-Epicea-to-Spec2" Pull request url: https://github.com/pharo-project/pharo/pull/4288 Issue Url: https://github.com/pharo-project/pharo/issues/Quick Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

[Pharo 8.0] Build #618: 4275-allInstVarNames-should-call-instVarNames

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #618 was: FAILURE. The Pull Request #4277 was integrated: "4275-allInstVarNames-should-call-instVarNames" Pull request url: https://github.com/pharo-project/pharo/pull/4277 Issue Url: https://github.com/pharo-project/pharo/issues/4275 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

[Pharo 8.0] Build #617: 4204-Should-SystemDictionary-sort-classes-by-name

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #617 was: FAILURE. The Pull Request #4274 was integrated: "4204-Should-SystemDictionary-sort-classes-by-name" Pull request url: https://github.com/pharo-project/pharo/pull/4274 Issue Url: https://github.com/pharo-project/pharo/issues/4204 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

[Pharo 8.0] Build #616: Go back to version Iceberg 1.6.1

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #616 was: FAILURE. The Pull Request #4284 was integrated: "Go back to version Iceberg 1.6.1" Pull request url: https://github.com/pharo-project/pharo/pull/4284 Issue Url: https://github.com/pharo-project/pharo/issues/fix/reverting Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

[Pharo 8.0] Build #615: 4017-tryning-to-add-an-ivar-to-UndefinedObject-crashes-the-VM

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #615 was: SUCCESS. The Pull Request #4279 was integrated: "4017-tryning-to-add-an-ivar-to-UndefinedObject-crashes-the-VM" Pull request url: https://github.com/pharo-project/pharo/pull/4279 Issue Url: https://github.com/pharo-project/pharo/issues/4017 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

by tesonep＠gmail.com

Hi, the repos is https://github.com/pharo-project/opensmalltalk-vm in the headless branch Cheers, Pablo On Mon, Aug 12, 2019 at 11:07 AM Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Thanks for the answers! > > Could you point me to where the platforms for minheadless are (which repository should we look at)? Also, to the build scripts that are used to build it? > > Cheers, > Doru > > > > On Aug 12, 2019, at 10:56 AM, tesonep(a)gmail.com wrote: > > > > Hi, > > The executables are not the same. > > We have 2 different now: the Stock VM (that is downloaded by the > > launcher, and it is the default download in Zero-conf), and the > > headless VM (this is downloaded by zero-conf when using > > vmLatestHeadless). > > > > Those platforms are not representative we currently have: OSX, > > Windows, and Linux all 64bits. We are working in ARM 32bits. > > In the near future, I will work on validating different flavors of > > Unix, but again It depends on the roadmap, and they are not there now. > > > > If someone requires some other platform we can talk to see how it > > can fit in the roadmap. > > > > Cheers, > > Pablo > > > > On Mon, Aug 12, 2019 at 10:03 AM Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi, > >> > >> Yes. We will be testing these days and we will come back with more details. > >> > >> Two more questions: > >> - Is minheadlessVM now integrated in the regular VM binary or are the two different artifacts? > >> - Also are the platforms from https://github.com/pharo-project/opensmalltalk-vm/tree/pharo/platforms representative for minheadlessVM? > >> > >> Cheers, > >> Doru > >> > >> > >> > >>> On Aug 12, 2019, at 9:11 AM, tesonep(a)gmail.com wrote: > >>> > >>> Hi Doru, > >>> can you give us more insight of the errors? Because there should > >>> not be changes in the behavior of the VM. Maybe there are issues, we > >>> have used the Pharo tests as a guarantee and we are laking some tests. > >>> > >>> Cheers, > >>> Pablo. > >>> > >>> On Sun, Aug 11, 2019 at 9:04 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>>> On Aug 11, 2019, at 5:29 PM, ducasse <stepharo(a)netcourrier.com> wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On 11 Aug 2019, at 13:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>>>>> > >>>>>> Excellent news! > >>>>>> > >>>>>> I should say that for GT we are currently using the minheadlessVM (Ronieâs work) out of the opensmalltalk-vm repo (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well. > >>>>>> > >>>>>> We started to play with your minheadlessVM. So far it looks like there are differences, although I am sure they are not large. > >>>>> > >>>>> like what? > >>>> > >>>> I do not know yet, but running GT in headless opens the window with the one from opensmalltalk-vm, but not with the new one. We did not yet look into details, but we will. > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>>>> So, what is the difference between the minheadlessVM built by you versus the one from opensmalltalk-vm? > >>>>>> > >>>>>> Cheers, > >>>>>> Doru > >>>>>> > >>>>>> > >>>>>>> On Aug 8, 2019, at 9:53 AM, tesonep(a)gmail.com wrote: > >>>>>>> > >>>>>>> TL;DR; > >>>>>>> ====== > >>>>>>> > >>>>>>> For the anxious, you can get real headless vm and image from zero-conf. > >>>>>>> > >>>>>>> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash > >>>>>>> > >>>>>>> Zero conf scripts remain unchanged for users. > >>>>>>> > >>>>>>> However, if you are launching the VM by hand from the executable > >>>>>>> instead of the launcher scripts (pharo and pharo-ui) as in > >>>>>>> > >>>>>>> $ ./pharoexecutable Pharo.image > >>>>>>> > >>>>>>> the image will launch in headless mode and will not open a window. > >>>>>>> To launch it in headfull, you can use the --interactive argument after > >>>>>>> the image, which will make the image open a window using SDL2. > >>>>>>> > >>>>>>> $ ./pharoexecutable Pharo.image --interactive > >>>>>>> > >>>>>>> Long version > >>>>>>> ============ > >>>>>>> > >>>>>>> Hi, this mail is the happy intermediate result of the work that us, > >>>>>>> the Pharo Consortium Team, has been doing in the last couple of > >>>>>>> months. > >>>>>>> Our main objective is to have a real headless implementation of Pharo > >>>>>>> where all the responsibility to open or not a World window (or other) > >>>>>>> is handled by the image. > >>>>>>> For doing so we have done a series of modifications in the image and > >>>>>>> the VM side. > >>>>>>> We consider this is the path that Pharo 8 and following versions > >>>>>>> should follow, as it will severely improve server-side and command > >>>>>>> line Pharo and in building custom desktop applications. > >>>>>>> > >>>>>>> These modifications are available only in 64-bits machines (Windows, > >>>>>>> OSX, and Linux). > >>>>>>> ARM32 and 64bits headless is in the roadmap, but it is delayed because > >>>>>>> we have prioritized our three major platforms for this first couple of > >>>>>>> months. > >>>>>>> > >>>>>>> All this work is based in Opensmalltalk-VM and Ronnie's initial work > >>>>>>> on headless. > >>>>>>> We are really grateful to all the contributors in the history of this > >>>>>>> nice product. > >>>>>>> To achieve a real headless VM we have brought modifications in the > >>>>>>> source tree because most of the platform code to open and manipulate > >>>>>>> windows is not required anymore. > >>>>>>> Instead, we use the SDL2 library that implements a nice layer on top > >>>>>>> of the OS and allows us to manage on the image side through FFI. > >>>>>>> > >>>>>>> So this mail is now an open call for (beta?)testing. > >>>>>>> The sources of the current VM we are building are in the headless branch in > >>>>>>> https://github.com/pharo-project/opensmalltalk-vm > >>>>>>> And we have set up a CI that is both building and testing the VM in > >>>>>>> https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ > >>>>>>> > >>>>>>> For the future we have a lot of ideas, that will wait for another long > >>>>>>> email or a beer-talk @ESUG. > >>>>>>> We want to hear your ideas!! > >>>>>>> > >>>>>>> Image-Side Improvements > >>>>>>> ======================= > >>>>>>> > >>>>>>> - The image handles the creation or not of the main world window. > >>>>>>> - We incorporated the idea of World renderer, where different backends > >>>>>>> are used to render the world. > >>>>>>> - We have 3 backends: VM support (compatibility with non-headless > >>>>>>> VMs), and OSWindow with two backends: SDL and GTK3+. > >>>>>>> - The modifications in the image are fully backward compatible with > >>>>>>> the non-headless VM and are pushed since weeks in the latest 8.0 > >>>>>>> image. > >>>>>>> - We move the handling of events to the image side when using SDL and > >>>>>>> GTK3+, opening the door to a richer set of events and finer-grained > >>>>>>> control over them. > >>>>>>> - SDL and GTK versions are implemented using FFI calls. > >>>>>>> > >>>>>>> VM-Side Improvements > >>>>>>> ==================== > >>>>>>> > >>>>>>> - VMMaker code migrated to Tonel thanks to Feenk and included in the > >>>>>>> repository of the VM. > >>>>>>> - Making VMMaker execute in Pharo 7 and 8. > >>>>>>> - Removing GPL code from the VM repository (GDB). > >>>>>>> > >>>>>>> - Slowly adding new tests for the JIT / Slang and VMGeneration. > >>>>>>> - Restructuring of the source code. > >>>>>>> - A new simpler CMake build. > >>>>>>> - Generate VM code from Slang on each build. > >>>>>>> - A CI process to validate (including the run of the tests in Pharo > >>>>>>> and the ones adding to the VM). > >>>>>>> - Simplification of the codebase. > >>>>>>> > >>>>>>> - Maximize the reuse of code between the platforms (preferring the > >>>>>>> standard versions over the platform-specific). > >>>>>>> - Cleaning up duplicated code. > >>>>>>> - All the plugins are now external plugins. > >>>>>>> - The VM is now a dynamic library. This is a first step towards > >>>>>>> embedding Pharo into other applications. > >>>>>>> - The main executable is a thin frontend (you can change it or > >>>>>>> implement your own). > >>>>>>> > >>>>>>> - Removing unused plugins. > >>>>>>> - Improved crash dump. Especially the crash dump works now in Windows 64bits. > >>>>>>> - Dummy implementation of Security plugin (it is going away.... eventually). > >>>>>>> - Cleanup of SSL, UUID, and Socket plugin. > >>>>>>> > >>>>>>> - Cleanup of conditional code (Still to improve). > >>>>>>> - Improving the types used in the functions (we have to be neat to be > >>>>>>> multiplatform/multi-arch). > >>>>>>> - Improving the lookup of modules > >>>>>>> - Improving the logging of the VM > >>>>>>> - Improving the handling of VM arguments > >>>>>>> > >>>>>>> > >>>>>>> Thanks a lot for reading so long!! > >>>>>>> We hope you enjoy the VM and please tell us all the problems you find!! > >>>>>>> > >>>>>>> Pablo, Guille, and Esteban > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> feenk.com > >>>>>> > >>>>>> "Being happy is a matter of choice." > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> -- > >>>> feenk.com > >>>> > >>>> "Speaking louder won't make the point worthier." > >>>> > >>>> > >>> > >>> > >>> -- > >>> Pablo Tesone. > >>> tesonep(a)gmail.com > >>> > >> > >> -- > >> feenk.com > >> > >> "What is more important: To be happy, or to make happy?" > >> > >> > > > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com > > > > -- > feenk.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > > > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 12, 2019

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

by Tudor Girba

Hi, Thanks for the answers! Could you point me to where the platforms for minheadless are (which repository should we look at)? Also, to the build scripts that are used to build it? Cheers, Doru > On Aug 12, 2019, at 10:56 AM, tesonep(a)gmail.com wrote: > > Hi, > The executables are not the same. > We have 2 different now: the Stock VM (that is downloaded by the > launcher, and it is the default download in Zero-conf), and the > headless VM (this is downloaded by zero-conf when using > vmLatestHeadless). > > Those platforms are not representative we currently have: OSX, > Windows, and Linux all 64bits. We are working in ARM 32bits. > In the near future, I will work on validating different flavors of > Unix, but again It depends on the roadmap, and they are not there now. > > If someone requires some other platform we can talk to see how it > can fit in the roadmap. > > Cheers, > Pablo > > On Mon, Aug 12, 2019 at 10:03 AM Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> Yes. We will be testing these days and we will come back with more details. >> >> Two more questions: >> - Is minheadlessVM now integrated in the regular VM binary or are the two different artifacts? >> - Also are the platforms from https://github.com/pharo-project/opensmalltalk-vm/tree/pharo/platforms representative for minheadlessVM? >> >> Cheers, >> Doru >> >> >> >>> On Aug 12, 2019, at 9:11 AM, tesonep(a)gmail.com wrote: >>> >>> Hi Doru, >>> can you give us more insight of the errors? Because there should >>> not be changes in the behavior of the VM. Maybe there are issues, we >>> have used the Pharo tests as a guarantee and we are laking some tests. >>> >>> Cheers, >>> Pablo. >>> >>> On Sun, Aug 11, 2019 at 9:04 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>>> On Aug 11, 2019, at 5:29 PM, ducasse <stepharo(a)netcourrier.com> wrote: >>>>> >>>>> >>>>> >>>>>> On 11 Aug 2019, at 13:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>> >>>>>> Excellent news! >>>>>> >>>>>> I should say that for GT we are currently using the minheadlessVM (Ronieâs work) out of the opensmalltalk-vm repo (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well. >>>>>> >>>>>> We started to play with your minheadlessVM. So far it looks like there are differences, although I am sure they are not large. >>>>> >>>>> like what? >>>> >>>> I do not know yet, but running GT in headless opens the window with the one from opensmalltalk-vm, but not with the new one. We did not yet look into details, but we will. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>>> So, what is the difference between the minheadlessVM built by you versus the one from opensmalltalk-vm? >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>>> On Aug 8, 2019, at 9:53 AM, tesonep(a)gmail.com wrote: >>>>>>> >>>>>>> TL;DR; >>>>>>> ====== >>>>>>> >>>>>>> For the anxious, you can get real headless vm and image from zero-conf. >>>>>>> >>>>>>> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash >>>>>>> >>>>>>> Zero conf scripts remain unchanged for users. >>>>>>> >>>>>>> However, if you are launching the VM by hand from the executable >>>>>>> instead of the launcher scripts (pharo and pharo-ui) as in >>>>>>> >>>>>>> $ ./pharoexecutable Pharo.image >>>>>>> >>>>>>> the image will launch in headless mode and will not open a window. >>>>>>> To launch it in headfull, you can use the --interactive argument after >>>>>>> the image, which will make the image open a window using SDL2. >>>>>>> >>>>>>> $ ./pharoexecutable Pharo.image --interactive >>>>>>> >>>>>>> Long version >>>>>>> ============ >>>>>>> >>>>>>> Hi, this mail is the happy intermediate result of the work that us, >>>>>>> the Pharo Consortium Team, has been doing in the last couple of >>>>>>> months. >>>>>>> Our main objective is to have a real headless implementation of Pharo >>>>>>> where all the responsibility to open or not a World window (or other) >>>>>>> is handled by the image. >>>>>>> For doing so we have done a series of modifications in the image and >>>>>>> the VM side. >>>>>>> We consider this is the path that Pharo 8 and following versions >>>>>>> should follow, as it will severely improve server-side and command >>>>>>> line Pharo and in building custom desktop applications. >>>>>>> >>>>>>> These modifications are available only in 64-bits machines (Windows, >>>>>>> OSX, and Linux). >>>>>>> ARM32 and 64bits headless is in the roadmap, but it is delayed because >>>>>>> we have prioritized our three major platforms for this first couple of >>>>>>> months. >>>>>>> >>>>>>> All this work is based in Opensmalltalk-VM and Ronnie's initial work >>>>>>> on headless. >>>>>>> We are really grateful to all the contributors in the history of this >>>>>>> nice product. >>>>>>> To achieve a real headless VM we have brought modifications in the >>>>>>> source tree because most of the platform code to open and manipulate >>>>>>> windows is not required anymore. >>>>>>> Instead, we use the SDL2 library that implements a nice layer on top >>>>>>> of the OS and allows us to manage on the image side through FFI. >>>>>>> >>>>>>> So this mail is now an open call for (beta?)testing. >>>>>>> The sources of the current VM we are building are in the headless branch in >>>>>>> https://github.com/pharo-project/opensmalltalk-vm >>>>>>> And we have set up a CI that is both building and testing the VM in >>>>>>> https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ >>>>>>> >>>>>>> For the future we have a lot of ideas, that will wait for another long >>>>>>> email or a beer-talk @ESUG. >>>>>>> We want to hear your ideas!! >>>>>>> >>>>>>> Image-Side Improvements >>>>>>> ======================= >>>>>>> >>>>>>> - The image handles the creation or not of the main world window. >>>>>>> - We incorporated the idea of World renderer, where different backends >>>>>>> are used to render the world. >>>>>>> - We have 3 backends: VM support (compatibility with non-headless >>>>>>> VMs), and OSWindow with two backends: SDL and GTK3+. >>>>>>> - The modifications in the image are fully backward compatible with >>>>>>> the non-headless VM and are pushed since weeks in the latest 8.0 >>>>>>> image. >>>>>>> - We move the handling of events to the image side when using SDL and >>>>>>> GTK3+, opening the door to a richer set of events and finer-grained >>>>>>> control over them. >>>>>>> - SDL and GTK versions are implemented using FFI calls. >>>>>>> >>>>>>> VM-Side Improvements >>>>>>> ==================== >>>>>>> >>>>>>> - VMMaker code migrated to Tonel thanks to Feenk and included in the >>>>>>> repository of the VM. >>>>>>> - Making VMMaker execute in Pharo 7 and 8. >>>>>>> - Removing GPL code from the VM repository (GDB). >>>>>>> >>>>>>> - Slowly adding new tests for the JIT / Slang and VMGeneration. >>>>>>> - Restructuring of the source code. >>>>>>> - A new simpler CMake build. >>>>>>> - Generate VM code from Slang on each build. >>>>>>> - A CI process to validate (including the run of the tests in Pharo >>>>>>> and the ones adding to the VM). >>>>>>> - Simplification of the codebase. >>>>>>> >>>>>>> - Maximize the reuse of code between the platforms (preferring the >>>>>>> standard versions over the platform-specific). >>>>>>> - Cleaning up duplicated code. >>>>>>> - All the plugins are now external plugins. >>>>>>> - The VM is now a dynamic library. This is a first step towards >>>>>>> embedding Pharo into other applications. >>>>>>> - The main executable is a thin frontend (you can change it or >>>>>>> implement your own). >>>>>>> >>>>>>> - Removing unused plugins. >>>>>>> - Improved crash dump. Especially the crash dump works now in Windows 64bits. >>>>>>> - Dummy implementation of Security plugin (it is going away.... eventually). >>>>>>> - Cleanup of SSL, UUID, and Socket plugin. >>>>>>> >>>>>>> - Cleanup of conditional code (Still to improve). >>>>>>> - Improving the types used in the functions (we have to be neat to be >>>>>>> multiplatform/multi-arch). >>>>>>> - Improving the lookup of modules >>>>>>> - Improving the logging of the VM >>>>>>> - Improving the handling of VM arguments >>>>>>> >>>>>>> >>>>>>> Thanks a lot for reading so long!! >>>>>>> We hope you enjoy the VM and please tell us all the problems you find!! >>>>>>> >>>>>>> Pablo, Guille, and Esteban >>>>>>> >>>>>> >>>>>> -- >>>>>> feenk.com >>>>>> >>>>>> "Being happy is a matter of choice." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> feenk.com >>>> >>>> "Speaking louder won't make the point worthier." >>>> >>>> >>> >>> >>> -- >>> Pablo Tesone. >>> tesonep(a)gmail.com >>> >> >> -- >> feenk.com >> >> "What is more important: To be happy, or to make happy?" >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- feenk.com "The coherence of a trip is given by the clearness of the goal."

Aug. 12, 2019

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

by tesonep＠gmail.com

Hi, The executables are not the same. We have 2 different now: the Stock VM (that is downloaded by the launcher, and it is the default download in Zero-conf), and the headless VM (this is downloaded by zero-conf when using vmLatestHeadless). Those platforms are not representative we currently have: OSX, Windows, and Linux all 64bits. We are working in ARM 32bits. In the near future, I will work on validating different flavors of Unix, but again It depends on the roadmap, and they are not there now. If someone requires some other platform we can talk to see how it can fit in the roadmap. Cheers, Pablo On Mon, Aug 12, 2019 at 10:03 AM Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Yes. We will be testing these days and we will come back with more details. > > Two more questions: > - Is minheadlessVM now integrated in the regular VM binary or are the two different artifacts? > - Also are the platforms from https://github.com/pharo-project/opensmalltalk-vm/tree/pharo/platforms representative for minheadlessVM? > > Cheers, > Doru > > > > > On Aug 12, 2019, at 9:11 AM, tesonep(a)gmail.com wrote: > > > > Hi Doru, > > can you give us more insight of the errors? Because there should > > not be changes in the behavior of the VM. Maybe there are issues, we > > have used the Pharo tests as a guarantee and we are laking some tests. > > > > Cheers, > > Pablo. > > > > On Sun, Aug 11, 2019 at 9:04 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi, > >> > >> > >> > >>> On Aug 11, 2019, at 5:29 PM, ducasse <stepharo(a)netcourrier.com> wrote: > >>> > >>> > >>> > >>>> On 11 Aug 2019, at 13:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>>> > >>>> Excellent news! > >>>> > >>>> I should say that for GT we are currently using the minheadlessVM (Ronieâs work) out of the opensmalltalk-vm repo (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well. > >>>> > >>>> We started to play with your minheadlessVM. So far it looks like there are differences, although I am sure they are not large. > >>> > >>> like what? > >> > >> I do not know yet, but running GT in headless opens the window with the one from opensmalltalk-vm, but not with the new one. We did not yet look into details, but we will. > >> > >> Cheers, > >> Doru > >> > >> > >>>> So, what is the difference between the minheadlessVM built by you versus the one from opensmalltalk-vm? > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>>> On Aug 8, 2019, at 9:53 AM, tesonep(a)gmail.com wrote: > >>>>> > >>>>> TL;DR; > >>>>> ====== > >>>>> > >>>>> For the anxious, you can get real headless vm and image from zero-conf. > >>>>> > >>>>> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash > >>>>> > >>>>> Zero conf scripts remain unchanged for users. > >>>>> > >>>>> However, if you are launching the VM by hand from the executable > >>>>> instead of the launcher scripts (pharo and pharo-ui) as in > >>>>> > >>>>> $ ./pharoexecutable Pharo.image > >>>>> > >>>>> the image will launch in headless mode and will not open a window. > >>>>> To launch it in headfull, you can use the --interactive argument after > >>>>> the image, which will make the image open a window using SDL2. > >>>>> > >>>>> $ ./pharoexecutable Pharo.image --interactive > >>>>> > >>>>> Long version > >>>>> ============ > >>>>> > >>>>> Hi, this mail is the happy intermediate result of the work that us, > >>>>> the Pharo Consortium Team, has been doing in the last couple of > >>>>> months. > >>>>> Our main objective is to have a real headless implementation of Pharo > >>>>> where all the responsibility to open or not a World window (or other) > >>>>> is handled by the image. > >>>>> For doing so we have done a series of modifications in the image and > >>>>> the VM side. > >>>>> We consider this is the path that Pharo 8 and following versions > >>>>> should follow, as it will severely improve server-side and command > >>>>> line Pharo and in building custom desktop applications. > >>>>> > >>>>> These modifications are available only in 64-bits machines (Windows, > >>>>> OSX, and Linux). > >>>>> ARM32 and 64bits headless is in the roadmap, but it is delayed because > >>>>> we have prioritized our three major platforms for this first couple of > >>>>> months. > >>>>> > >>>>> All this work is based in Opensmalltalk-VM and Ronnie's initial work > >>>>> on headless. > >>>>> We are really grateful to all the contributors in the history of this > >>>>> nice product. > >>>>> To achieve a real headless VM we have brought modifications in the > >>>>> source tree because most of the platform code to open and manipulate > >>>>> windows is not required anymore. > >>>>> Instead, we use the SDL2 library that implements a nice layer on top > >>>>> of the OS and allows us to manage on the image side through FFI. > >>>>> > >>>>> So this mail is now an open call for (beta?)testing. > >>>>> The sources of the current VM we are building are in the headless branch in > >>>>> https://github.com/pharo-project/opensmalltalk-vm > >>>>> And we have set up a CI that is both building and testing the VM in > >>>>> https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ > >>>>> > >>>>> For the future we have a lot of ideas, that will wait for another long > >>>>> email or a beer-talk @ESUG. > >>>>> We want to hear your ideas!! > >>>>> > >>>>> Image-Side Improvements > >>>>> ======================= > >>>>> > >>>>> - The image handles the creation or not of the main world window. > >>>>> - We incorporated the idea of World renderer, where different backends > >>>>> are used to render the world. > >>>>> - We have 3 backends: VM support (compatibility with non-headless > >>>>> VMs), and OSWindow with two backends: SDL and GTK3+. > >>>>> - The modifications in the image are fully backward compatible with > >>>>> the non-headless VM and are pushed since weeks in the latest 8.0 > >>>>> image. > >>>>> - We move the handling of events to the image side when using SDL and > >>>>> GTK3+, opening the door to a richer set of events and finer-grained > >>>>> control over them. > >>>>> - SDL and GTK versions are implemented using FFI calls. > >>>>> > >>>>> VM-Side Improvements > >>>>> ==================== > >>>>> > >>>>> - VMMaker code migrated to Tonel thanks to Feenk and included in the > >>>>> repository of the VM. > >>>>> - Making VMMaker execute in Pharo 7 and 8. > >>>>> - Removing GPL code from the VM repository (GDB). > >>>>> > >>>>> - Slowly adding new tests for the JIT / Slang and VMGeneration. > >>>>> - Restructuring of the source code. > >>>>> - A new simpler CMake build. > >>>>> - Generate VM code from Slang on each build. > >>>>> - A CI process to validate (including the run of the tests in Pharo > >>>>> and the ones adding to the VM). > >>>>> - Simplification of the codebase. > >>>>> > >>>>> - Maximize the reuse of code between the platforms (preferring the > >>>>> standard versions over the platform-specific). > >>>>> - Cleaning up duplicated code. > >>>>> - All the plugins are now external plugins. > >>>>> - The VM is now a dynamic library. This is a first step towards > >>>>> embedding Pharo into other applications. > >>>>> - The main executable is a thin frontend (you can change it or > >>>>> implement your own). > >>>>> > >>>>> - Removing unused plugins. > >>>>> - Improved crash dump. Especially the crash dump works now in Windows 64bits. > >>>>> - Dummy implementation of Security plugin (it is going away.... eventually). > >>>>> - Cleanup of SSL, UUID, and Socket plugin. > >>>>> > >>>>> - Cleanup of conditional code (Still to improve). > >>>>> - Improving the types used in the functions (we have to be neat to be > >>>>> multiplatform/multi-arch). > >>>>> - Improving the lookup of modules > >>>>> - Improving the logging of the VM > >>>>> - Improving the handling of VM arguments > >>>>> > >>>>> > >>>>> Thanks a lot for reading so long!! > >>>>> We hope you enjoy the VM and please tell us all the problems you find!! > >>>>> > >>>>> Pablo, Guille, and Esteban > >>>>> > >>>> > >>>> -- > >>>> feenk.com > >>>> > >>>> "Being happy is a matter of choice." > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> -- > >> feenk.com > >> > >> "Speaking louder won't make the point worthier." > >> > >> > > > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com > > > > -- > feenk.com > > "What is more important: To be happy, or to make happy?" > > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 12, 2019

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

by Tudor Girba

Hi, Yes. We will be testing these days and we will come back with more details. Two more questions: - Is minheadlessVM now integrated in the regular VM binary or are the two different artifacts? - Also are the platforms from https://github.com/pharo-project/opensmalltalk-vm/tree/pharo/platforms representative for minheadlessVM? Cheers, Doru > On Aug 12, 2019, at 9:11 AM, tesonep(a)gmail.com wrote: > > Hi Doru, > can you give us more insight of the errors? Because there should > not be changes in the behavior of the VM. Maybe there are issues, we > have used the Pharo tests as a guarantee and we are laking some tests. > > Cheers, > Pablo. > > On Sun, Aug 11, 2019 at 9:04 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> >> >>> On Aug 11, 2019, at 5:29 PM, ducasse <stepharo(a)netcourrier.com> wrote: >>> >>> >>> >>>> On 11 Aug 2019, at 13:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Excellent news! >>>> >>>> I should say that for GT we are currently using the minheadlessVM (Ronieâs work) out of the opensmalltalk-vm repo (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well. >>>> >>>> We started to play with your minheadlessVM. So far it looks like there are differences, although I am sure they are not large. >>> >>> like what? >> >> I do not know yet, but running GT in headless opens the window with the one from opensmalltalk-vm, but not with the new one. We did not yet look into details, but we will. >> >> Cheers, >> Doru >> >> >>>> So, what is the difference between the minheadlessVM built by you versus the one from opensmalltalk-vm? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Aug 8, 2019, at 9:53 AM, tesonep(a)gmail.com wrote: >>>>> >>>>> TL;DR; >>>>> ====== >>>>> >>>>> For the anxious, you can get real headless vm and image from zero-conf. >>>>> >>>>> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash >>>>> >>>>> Zero conf scripts remain unchanged for users. >>>>> >>>>> However, if you are launching the VM by hand from the executable >>>>> instead of the launcher scripts (pharo and pharo-ui) as in >>>>> >>>>> $ ./pharoexecutable Pharo.image >>>>> >>>>> the image will launch in headless mode and will not open a window. >>>>> To launch it in headfull, you can use the --interactive argument after >>>>> the image, which will make the image open a window using SDL2. >>>>> >>>>> $ ./pharoexecutable Pharo.image --interactive >>>>> >>>>> Long version >>>>> ============ >>>>> >>>>> Hi, this mail is the happy intermediate result of the work that us, >>>>> the Pharo Consortium Team, has been doing in the last couple of >>>>> months. >>>>> Our main objective is to have a real headless implementation of Pharo >>>>> where all the responsibility to open or not a World window (or other) >>>>> is handled by the image. >>>>> For doing so we have done a series of modifications in the image and >>>>> the VM side. >>>>> We consider this is the path that Pharo 8 and following versions >>>>> should follow, as it will severely improve server-side and command >>>>> line Pharo and in building custom desktop applications. >>>>> >>>>> These modifications are available only in 64-bits machines (Windows, >>>>> OSX, and Linux). >>>>> ARM32 and 64bits headless is in the roadmap, but it is delayed because >>>>> we have prioritized our three major platforms for this first couple of >>>>> months. >>>>> >>>>> All this work is based in Opensmalltalk-VM and Ronnie's initial work >>>>> on headless. >>>>> We are really grateful to all the contributors in the history of this >>>>> nice product. >>>>> To achieve a real headless VM we have brought modifications in the >>>>> source tree because most of the platform code to open and manipulate >>>>> windows is not required anymore. >>>>> Instead, we use the SDL2 library that implements a nice layer on top >>>>> of the OS and allows us to manage on the image side through FFI. >>>>> >>>>> So this mail is now an open call for (beta?)testing. >>>>> The sources of the current VM we are building are in the headless branch in >>>>> https://github.com/pharo-project/opensmalltalk-vm >>>>> And we have set up a CI that is both building and testing the VM in >>>>> https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ >>>>> >>>>> For the future we have a lot of ideas, that will wait for another long >>>>> email or a beer-talk @ESUG. >>>>> We want to hear your ideas!! >>>>> >>>>> Image-Side Improvements >>>>> ======================= >>>>> >>>>> - The image handles the creation or not of the main world window. >>>>> - We incorporated the idea of World renderer, where different backends >>>>> are used to render the world. >>>>> - We have 3 backends: VM support (compatibility with non-headless >>>>> VMs), and OSWindow with two backends: SDL and GTK3+. >>>>> - The modifications in the image are fully backward compatible with >>>>> the non-headless VM and are pushed since weeks in the latest 8.0 >>>>> image. >>>>> - We move the handling of events to the image side when using SDL and >>>>> GTK3+, opening the door to a richer set of events and finer-grained >>>>> control over them. >>>>> - SDL and GTK versions are implemented using FFI calls. >>>>> >>>>> VM-Side Improvements >>>>> ==================== >>>>> >>>>> - VMMaker code migrated to Tonel thanks to Feenk and included in the >>>>> repository of the VM. >>>>> - Making VMMaker execute in Pharo 7 and 8. >>>>> - Removing GPL code from the VM repository (GDB). >>>>> >>>>> - Slowly adding new tests for the JIT / Slang and VMGeneration. >>>>> - Restructuring of the source code. >>>>> - A new simpler CMake build. >>>>> - Generate VM code from Slang on each build. >>>>> - A CI process to validate (including the run of the tests in Pharo >>>>> and the ones adding to the VM). >>>>> - Simplification of the codebase. >>>>> >>>>> - Maximize the reuse of code between the platforms (preferring the >>>>> standard versions over the platform-specific). >>>>> - Cleaning up duplicated code. >>>>> - All the plugins are now external plugins. >>>>> - The VM is now a dynamic library. This is a first step towards >>>>> embedding Pharo into other applications. >>>>> - The main executable is a thin frontend (you can change it or >>>>> implement your own). >>>>> >>>>> - Removing unused plugins. >>>>> - Improved crash dump. Especially the crash dump works now in Windows 64bits. >>>>> - Dummy implementation of Security plugin (it is going away.... eventually). >>>>> - Cleanup of SSL, UUID, and Socket plugin. >>>>> >>>>> - Cleanup of conditional code (Still to improve). >>>>> - Improving the types used in the functions (we have to be neat to be >>>>> multiplatform/multi-arch). >>>>> - Improving the lookup of modules >>>>> - Improving the logging of the VM >>>>> - Improving the handling of VM arguments >>>>> >>>>> >>>>> Thanks a lot for reading so long!! >>>>> We hope you enjoy the VM and please tell us all the problems you find!! >>>>> >>>>> Pablo, Guille, and Esteban >>>>> >>>> >>>> -- >>>> feenk.com >>>> >>>> "Being happy is a matter of choice." >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> -- >> feenk.com >> >> "Speaking louder won't make the point worthier." >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- feenk.com "What is more important: To be happy, or to make happy?"

Aug. 12, 2019

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

by tesonep＠gmail.com

Hi Doru, can you give us more insight of the errors? Because there should not be changes in the behavior of the VM. Maybe there are issues, we have used the Pharo tests as a guarantee and we are laking some tests. Cheers, Pablo. On Sun, Aug 11, 2019 at 9:04 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > > > > On Aug 11, 2019, at 5:29 PM, ducasse <stepharo(a)netcourrier.com> wrote: > > > > > > > >> On 11 Aug 2019, at 13:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Excellent news! > >> > >> I should say that for GT we are currently using the minheadlessVM (Ronieâs work) out of the opensmalltalk-vm repo (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well. > >> > >> We started to play with your minheadlessVM. So far it looks like there are differences, although I am sure they are not large. > > > > like what? > > I do not know yet, but running GT in headless opens the window with the one from opensmalltalk-vm, but not with the new one. We did not yet look into details, but we will. > > Cheers, > Doru > > > >> So, what is the difference between the minheadlessVM built by you versus the one from opensmalltalk-vm? > >> > >> Cheers, > >> Doru > >> > >> > >>> On Aug 8, 2019, at 9:53 AM, tesonep(a)gmail.com wrote: > >>> > >>> TL;DR; > >>> ====== > >>> > >>> For the anxious, you can get real headless vm and image from zero-conf. > >>> > >>> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash > >>> > >>> Zero conf scripts remain unchanged for users. > >>> > >>> However, if you are launching the VM by hand from the executable > >>> instead of the launcher scripts (pharo and pharo-ui) as in > >>> > >>> $ ./pharoexecutable Pharo.image > >>> > >>> the image will launch in headless mode and will not open a window. > >>> To launch it in headfull, you can use the --interactive argument after > >>> the image, which will make the image open a window using SDL2. > >>> > >>> $ ./pharoexecutable Pharo.image --interactive > >>> > >>> Long version > >>> ============ > >>> > >>> Hi, this mail is the happy intermediate result of the work that us, > >>> the Pharo Consortium Team, has been doing in the last couple of > >>> months. > >>> Our main objective is to have a real headless implementation of Pharo > >>> where all the responsibility to open or not a World window (or other) > >>> is handled by the image. > >>> For doing so we have done a series of modifications in the image and > >>> the VM side. > >>> We consider this is the path that Pharo 8 and following versions > >>> should follow, as it will severely improve server-side and command > >>> line Pharo and in building custom desktop applications. > >>> > >>> These modifications are available only in 64-bits machines (Windows, > >>> OSX, and Linux). > >>> ARM32 and 64bits headless is in the roadmap, but it is delayed because > >>> we have prioritized our three major platforms for this first couple of > >>> months. > >>> > >>> All this work is based in Opensmalltalk-VM and Ronnie's initial work > >>> on headless. > >>> We are really grateful to all the contributors in the history of this > >>> nice product. > >>> To achieve a real headless VM we have brought modifications in the > >>> source tree because most of the platform code to open and manipulate > >>> windows is not required anymore. > >>> Instead, we use the SDL2 library that implements a nice layer on top > >>> of the OS and allows us to manage on the image side through FFI. > >>> > >>> So this mail is now an open call for (beta?)testing. > >>> The sources of the current VM we are building are in the headless branch in > >>> https://github.com/pharo-project/opensmalltalk-vm > >>> And we have set up a CI that is both building and testing the VM in > >>> https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ > >>> > >>> For the future we have a lot of ideas, that will wait for another long > >>> email or a beer-talk @ESUG. > >>> We want to hear your ideas!! > >>> > >>> Image-Side Improvements > >>> ======================= > >>> > >>> - The image handles the creation or not of the main world window. > >>> - We incorporated the idea of World renderer, where different backends > >>> are used to render the world. > >>> - We have 3 backends: VM support (compatibility with non-headless > >>> VMs), and OSWindow with two backends: SDL and GTK3+. > >>> - The modifications in the image are fully backward compatible with > >>> the non-headless VM and are pushed since weeks in the latest 8.0 > >>> image. > >>> - We move the handling of events to the image side when using SDL and > >>> GTK3+, opening the door to a richer set of events and finer-grained > >>> control over them. > >>> - SDL and GTK versions are implemented using FFI calls. > >>> > >>> VM-Side Improvements > >>> ==================== > >>> > >>> - VMMaker code migrated to Tonel thanks to Feenk and included in the > >>> repository of the VM. > >>> - Making VMMaker execute in Pharo 7 and 8. > >>> - Removing GPL code from the VM repository (GDB). > >>> > >>> - Slowly adding new tests for the JIT / Slang and VMGeneration. > >>> - Restructuring of the source code. > >>> - A new simpler CMake build. > >>> - Generate VM code from Slang on each build. > >>> - A CI process to validate (including the run of the tests in Pharo > >>> and the ones adding to the VM). > >>> - Simplification of the codebase. > >>> > >>> - Maximize the reuse of code between the platforms (preferring the > >>> standard versions over the platform-specific). > >>> - Cleaning up duplicated code. > >>> - All the plugins are now external plugins. > >>> - The VM is now a dynamic library. This is a first step towards > >>> embedding Pharo into other applications. > >>> - The main executable is a thin frontend (you can change it or > >>> implement your own). > >>> > >>> - Removing unused plugins. > >>> - Improved crash dump. Especially the crash dump works now in Windows 64bits. > >>> - Dummy implementation of Security plugin (it is going away.... eventually). > >>> - Cleanup of SSL, UUID, and Socket plugin. > >>> > >>> - Cleanup of conditional code (Still to improve). > >>> - Improving the types used in the functions (we have to be neat to be > >>> multiplatform/multi-arch). > >>> - Improving the lookup of modules > >>> - Improving the logging of the VM > >>> - Improving the handling of VM arguments > >>> > >>> > >>> Thanks a lot for reading so long!! > >>> We hope you enjoy the VM and please tell us all the problems you find!! > >>> > >>> Pablo, Guille, and Esteban > >>> > >> > >> -- > >> feenk.com > >> > >> "Being happy is a matter of choice." > >> > >> > >> > >> > >> > >> > >> > > > > > > > > -- > feenk.com > > "Speaking louder won't make the point worthier." > > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 12, 2019

[Pharo 8.0] Build #614: 4223-Lint-clean-RubCharacterBlockScanner-cr

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #614 was: SUCCESS. The Pull Request #4224 was integrated: "4223-Lint-clean-RubCharacterBlockScanner-cr" Pull request url: https://github.com/pharo-project/pharo/pull/4224 Issue Url: https://github.com/pharo-project/pharo/issues/4223 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

[Pharo 8.0] Build #613: Simplify Socket>>waitForAcceptFor:

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #613 was: FAILURE. The Pull Request #4190 was integrated: "Simplify Socket>>waitForAcceptFor: " Pull request url: https://github.com/pharo-project/pharo/pull/4190 Issue Url: https://github.com/pharo-project/pharo/issues/Socket_waitForAcceptFor_ Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

[Pharo 8.0] Build #612: 4229-Lint-clean-BehaviorallInstVarNames

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #612 was: SUCCESS. The Pull Request #4231 was integrated: "4229-Lint-clean-BehaviorallInstVarNames" Pull request url: https://github.com/pharo-project/pharo/pull/4231 Issue Url: https://github.com/pharo-project/pharo/issues/4229 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 12, 2019

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

by Tudor Girba

Hi, > On Aug 11, 2019, at 5:29 PM, ducasse <stepharo(a)netcourrier.com> wrote: > > > >> On 11 Aug 2019, at 13:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Excellent news! >> >> I should say that for GT we are currently using the minheadlessVM (Ronieâs work) out of the opensmalltalk-vm repo (https://bintray.com/opensmalltalk/vm/cog) and it works remarkably well. >> >> We started to play with your minheadlessVM. So far it looks like there are differences, although I am sure they are not large. > > like what? I do not know yet, but running GT in headless opens the window with the one from opensmalltalk-vm, but not with the new one. We did not yet look into details, but we will. Cheers, Doru >> So, what is the difference between the minheadlessVM built by you versus the one from opensmalltalk-vm? >> >> Cheers, >> Doru >> >> >>> On Aug 8, 2019, at 9:53 AM, tesonep(a)gmail.com wrote: >>> >>> TL;DR; >>> ====== >>> >>> For the anxious, you can get real headless vm and image from zero-conf. >>> >>> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash >>> >>> Zero conf scripts remain unchanged for users. >>> >>> However, if you are launching the VM by hand from the executable >>> instead of the launcher scripts (pharo and pharo-ui) as in >>> >>> $ ./pharoexecutable Pharo.image >>> >>> the image will launch in headless mode and will not open a window. >>> To launch it in headfull, you can use the --interactive argument after >>> the image, which will make the image open a window using SDL2. >>> >>> $ ./pharoexecutable Pharo.image --interactive >>> >>> Long version >>> ============ >>> >>> Hi, this mail is the happy intermediate result of the work that us, >>> the Pharo Consortium Team, has been doing in the last couple of >>> months. >>> Our main objective is to have a real headless implementation of Pharo >>> where all the responsibility to open or not a World window (or other) >>> is handled by the image. >>> For doing so we have done a series of modifications in the image and >>> the VM side. >>> We consider this is the path that Pharo 8 and following versions >>> should follow, as it will severely improve server-side and command >>> line Pharo and in building custom desktop applications. >>> >>> These modifications are available only in 64-bits machines (Windows, >>> OSX, and Linux). >>> ARM32 and 64bits headless is in the roadmap, but it is delayed because >>> we have prioritized our three major platforms for this first couple of >>> months. >>> >>> All this work is based in Opensmalltalk-VM and Ronnie's initial work >>> on headless. >>> We are really grateful to all the contributors in the history of this >>> nice product. >>> To achieve a real headless VM we have brought modifications in the >>> source tree because most of the platform code to open and manipulate >>> windows is not required anymore. >>> Instead, we use the SDL2 library that implements a nice layer on top >>> of the OS and allows us to manage on the image side through FFI. >>> >>> So this mail is now an open call for (beta?)testing. >>> The sources of the current VM we are building are in the headless branch in >>> https://github.com/pharo-project/opensmalltalk-vm >>> And we have set up a CI that is both building and testing the VM in >>> https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ >>> >>> For the future we have a lot of ideas, that will wait for another long >>> email or a beer-talk @ESUG. >>> We want to hear your ideas!! >>> >>> Image-Side Improvements >>> ======================= >>> >>> - The image handles the creation or not of the main world window. >>> - We incorporated the idea of World renderer, where different backends >>> are used to render the world. >>> - We have 3 backends: VM support (compatibility with non-headless >>> VMs), and OSWindow with two backends: SDL and GTK3+. >>> - The modifications in the image are fully backward compatible with >>> the non-headless VM and are pushed since weeks in the latest 8.0 >>> image. >>> - We move the handling of events to the image side when using SDL and >>> GTK3+, opening the door to a richer set of events and finer-grained >>> control over them. >>> - SDL and GTK versions are implemented using FFI calls. >>> >>> VM-Side Improvements >>> ==================== >>> >>> - VMMaker code migrated to Tonel thanks to Feenk and included in the >>> repository of the VM. >>> - Making VMMaker execute in Pharo 7 and 8. >>> - Removing GPL code from the VM repository (GDB). >>> >>> - Slowly adding new tests for the JIT / Slang and VMGeneration. >>> - Restructuring of the source code. >>> - A new simpler CMake build. >>> - Generate VM code from Slang on each build. >>> - A CI process to validate (including the run of the tests in Pharo >>> and the ones adding to the VM). >>> - Simplification of the codebase. >>> >>> - Maximize the reuse of code between the platforms (preferring the >>> standard versions over the platform-specific). >>> - Cleaning up duplicated code. >>> - All the plugins are now external plugins. >>> - The VM is now a dynamic library. This is a first step towards >>> embedding Pharo into other applications. >>> - The main executable is a thin frontend (you can change it or >>> implement your own). >>> >>> - Removing unused plugins. >>> - Improved crash dump. Especially the crash dump works now in Windows 64bits. >>> - Dummy implementation of Security plugin (it is going away.... eventually). >>> - Cleanup of SSL, UUID, and Socket plugin. >>> >>> - Cleanup of conditional code (Still to improve). >>> - Improving the types used in the functions (we have to be neat to be >>> multiplatform/multi-arch). >>> - Improving the lookup of modules >>> - Improving the logging of the VM >>> - Improving the handling of VM arguments >>> >>> >>> Thanks a lot for reading so long!! >>> We hope you enjoy the VM and please tell us all the problems you find!! >>> >>> Pablo, Guille, and Esteban >>> >> >> -- >> feenk.com >> >> "Being happy is a matter of choice." >> >> >> >> >> >> >> > > > -- feenk.com "Speaking louder won't make the point worthier."

Aug. 11, 2019