January 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Next Pharo release moved to end of year

by phil＠highoctane.be

Sounds like a realistic plan. Good to read that. I have the impression that Pharo 3, Pharo 5, Pharo 7 will be the solid releases. Are we having a pattern here? Phil On Jan 23, 2018 14:20, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > Hi all, > > After some analysis of current condition of development, we decided to > move the upcoming release to end of the year (and not May, as usual). > The reason is that we are taking more time than expected to finish/polish > a quantity of things that needs to be finish to call this a âsuccessful > releaseâ to make us feel confortable with a release early this year. > > Thing isâ¦ we were very ambitious with this version, because a lot of small > pieces get into position and we decided to act. > Now, to deliver a good version, we need to finish them. > > For example, along with all the stabilisation phase we need to operate on > P7 (an usual task for every version), we still need to finish this > important changes: > > - fullblocks as default > - vm 64bits: stabilise and add win64 > - stateful traits > - calypso (and nautilus removal) > - iceberg: fix the UI > > We (the core team and the community) have a deep commitment with the > progress of Pharo, and we will continue get things right to make the > continue improvement a pleasant experience. > > Say that, expect new announcement of things finished and ready to test > next weeks :) > > cheers! > Esteban >

Jan. 25, 2018

Re: [Pharo-dev] [ANN] Next Pharo release moved to end of year

by philippe.back＠highoctane.be

Sounds like a realistic plan. Good to read that. I have the impression that Pharo 3, Pharo 5, Pharo 7 will be the solid releases. Are we having a pattern here? Phil On Jan 23, 2018 14:20, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: Hi all, After some analysis of current condition of development, we decided to move the upcoming release to end of the year (and not May, as usual). The reason is that we are taking more time than expected to finish/polish a quantity of things that needs to be finish to call this a âsuccessful releaseâ to make us feel confortable with a release early this year. Thing isâ¦ we were very ambitious with this version, because a lot of small pieces get into position and we decided to act. Now, to deliver a good version, we need to finish them. For example, along with all the stabilisation phase we need to operate on P7 (an usual task for every version), we still need to finish this important changes: - fullblocks as default - vm 64bits: stabilise and add win64 - stateful traits - calypso (and nautilus removal) - iceberg: fix the UI We (the core team and the community) have a deep commitment with the progress of Pharo, and we will continue get things right to make the continue improvement a pleasant experience. Say that, expect new announcement of things finished and ready to test next weeks :) cheers! Esteban

Jan. 25, 2018

Re: [Pharo-dev] [ANN] Next Pharo release moved to end of year

by philippe.back＠highoctane.be

Sounds like a realistic plan. Good to read that. I have the impression that Pharo 3, Pharo 5, Pharo 7 will be the solid releases. Are we having a pattern here? Phil On Jan 23, 2018 14:20, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > Hi all, > > After some analysis of current condition of development, we decided to > move the upcoming release to end of the year (and not May, as usual). > The reason is that we are taking more time than expected to finish/polish > a quantity of things that needs to be finish to call this a âsuccessful > releaseâ to make us feel confortable with a release early this year. > > Thing isâ¦ we were very ambitious with this version, because a lot of small > pieces get into position and we decided to act. > Now, to deliver a good version, we need to finish them. > > For example, along with all the stabilisation phase we need to operate on > P7 (an usual task for every version), we still need to finish this > important changes: > > - fullblocks as default > - vm 64bits: stabilise and add win64 > - stateful traits > - calypso (and nautilus removal) > - iceberg: fix the UI > > We (the core team and the community) have a deep commitment with the > progress of Pharo, and we will continue get things right to make the > continue improvement a pleasant experience. > > Say that, expect new announcement of things finished and ready to test > next weeks :) > > cheers! > Esteban >

Jan. 25, 2018

Re: [Pharo-dev] Moving from mc to tonel?

by Martin Dias

Hi, any news or experiences on the migration tools? I'd try again on next days. MartÃn On Sat, Dec 16, 2017 at 5:06 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > It would be great to be able to sanitize the files. > We should get a test about tonel misbehavior. > > Stef > > On Thu, Dec 14, 2017 at 3:11 PM, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: > > Stephan Eggermont-3 wrote > >> On 05-12-17 08:59, Peter UhnÃ¡k wrote: > >>> > In my case, it turned out to be a non-UTF8 encoded character in one > >>> of the commit messages. > >>> > >>> I've ran into this problem in a sister project (tonel-migration), and > do > >>> not have a proper resolution yet. I was forcing everything to be > >>> unicode, so I need a better way to read and write encoded strings. :< > >> > >> To be exact, exactly none of the older commits will be UTF8 encoded. For > >> most it doesn't matter as they are ASCII, but if we want to have a > >> change of converting older french or german code (or japanese), we need > >> support for what was done with WideString. That probably needs a look in > >> the squeak mailing list archives. > >> > >> Stephan > > > > The mcz reader used to import the .bin file (which contained correctly > > serialized WideStrings), only falling back to reading the .st file if > .bin > > was not present, has this changed? > > > > Or do these tools explicitly ignore the .bin file and try to read the .st > > file directly? > > If so, the MCDataStream class used to read .bin format still seems to be > in > > the image... > > > > One could also create a tool to check/convert all mcz in a repo as a > > preprocess; > > if .bin contents decode as WideString, > > check that .st starts with utf8 BOM, > > if not, convert. > > > > Cheers, > > Henry > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > > >

Jan. 25, 2018

Re: [Pharo-dev] FFI without the Pharo sources

by Vincent.Blondeau＠lamresearch.com

From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Eliot Miranda Sent: Wednesday, January 24, 2018 10:24 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] FFI without the Pharo sources On Wed, Jan 24, 2018 at 10:21 AM, Eliot Miranda <eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>> wrote: On Wed, Jan 24, 2018 at 9:26 AM, <Vincent.Blondeau(a)lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> wrote: -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Eliot Miranda Sent: Wednesday, January 24, 2018 8:09 To: Pharo Development List <pharo-dev(a)lists.pharo.org<mailto:pharo-dev@lists.pharo.org>> Subject: Re: [Pharo-dev] FFI without the Pharo sources Hi Vincent, > On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau(a)lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> <Vincent.Blondeau(a)lamresearch.com<mailto:Vincent.Blondeau@lamresearch.com>> wrote: > > Hi, > > I am working to be able to create some standalone apps in Pharo. And for this, I would like to remove of the .sources and .changes. But, by removing them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot be used anymore. > > Does someone (Esteban?) have a solution that I could implement to fix this issue? One avenue that should be easy to implement would be to modify the compiler to save the temporary names as a property of the method. Hi Eliot, Ok. That seems the better solution. But you have to do that for only the FFI methods? Right. It would be very wasteful to do it for everything. Also, if there is a Pragma for the FFI information then an even nicer way to do it would be to add a subclass of Pragma, FFIPragma?, and add the tempVars there-in. Sorry, I don't mean that. Pgarmas are created when one tries to access a method's pragmas; they are ephemeral. Instead one could add a subclass of AdditionalMethodState. AdditionalMethodState holds the messages for pragmas and the properties. You can use the properties directly; they're a dictionary. But if you added a subclass, AdditionalFFIMethodState?, it could hold the temp names in an inst var. Ok Eliot! I put the args in a variable of the additional state for ffi that is created when a ffiCall selector is detected in the method at compilation. I think I could finish tomorrow the accessing to the arguments names when the sources vanishes. Thanks! Vincent Vincent > > Thanks! > > Vincent _,,,^..^,,,_ (phone) -- _,,,^..^,,,_ best, Eliot -- _,,,^..^,,,_ best, Eliot

Jan. 25, 2018

Re: [Pharo-dev] FFI without the Pharo sources

by Eliot Miranda

On Wed, Jan 24, 2018 at 10:21 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Jan 24, 2018 at 9:26 AM, <Vincent.Blondeau(a)lamresearch.com> wrote: > >> >> >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org >> <pharo-dev-bounces(a)lists.pharo.org>] On Behalf Of Eliot Miranda >> Sent: Wednesday, January 24, 2018 8:09 >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] FFI without the Pharo sources >> >> Hi Vincent, >> >> > On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau(a)lamresearch.com> < >> Vincent.Blondeau(a)lamresearch.com> wrote: >> > >> > Hi, >> > >> > I am working to be able to create some standalone apps in Pharo. And >> for this, I would like to remove of the .sources and .changes. But, by >> removing them, the args names are reset to arg1, arg2, arg3, ... and the >> FFI cannot be used anymore. >> > >> > Does someone (Esteban?) have a solution that I could implement to fix >> this issue? >> >> One avenue that should be easy to implement would be to modify the >> compiler to save the temporary names as a property of the method. >> >> Hi Eliot, >> >> Ok. That seems the better solution. But you have to do that for only the >> FFI methods? >> > > Right. It would be very wasteful to do it for everything. Also, if there > is a Pragma for the FFI information then an even nicer way to do it would > be to add a subclass of Pragma, FFIPragma?, and add the tempVars there-in. > Sorry, I don't mean that. Pgarmas are created when one tries to access a method's pragmas; they are ephemeral. Instead one could add a subclass of AdditionalMethodState. AdditionalMethodState holds the messages for pragmas and the properties. You can use the properties directly; they're a dictionary. But if you added a subclass, AdditionalFFIMethodState?, it could hold the temp names in an inst var. > >> >> Vincent >> >> > >> > Thanks! >> > >> > Vincent >> >> _,,,^..^,,,_ (phone) >> >> > > > > -- > _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot

Jan. 24, 2018

Re: [Pharo-dev] FFI without the Pharo sources

by Eliot Miranda

On Wed, Jan 24, 2018 at 9:26 AM, <Vincent.Blondeau(a)lamresearch.com> wrote: > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] On Behalf Of Eliot Miranda > Sent: Wednesday, January 24, 2018 8:09 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] FFI without the Pharo sources > > Hi Vincent, > > > On Jan 23, 2018, at 4:54 PM, <Vincent.Blondeau(a)lamresearch.com> < > Vincent.Blondeau(a)lamresearch.com> wrote: > > > > Hi, > > > > I am working to be able to create some standalone apps in Pharo. And for > this, I would like to remove of the .sources and .changes. But, by removing > them, the args names are reset to arg1, arg2, arg3, ... and the FFI cannot > be used anymore. > > > > Does someone (Esteban?) have a solution that I could implement to fix > this issue? > > One avenue that should be easy to implement would be to modify the > compiler to save the temporary names as a property of the method. > > Hi Eliot, > > Ok. That seems the better solution. But you have to do that for only the > FFI methods? > Right. It would be very wasteful to do it for everything. Also, if there is a Pragma for the FFI information then an even nicer way to do it would be to add a subclass of Pragma, FFIPragma?, and add the tempVars there-in. > > Vincent > > > > > Thanks! > > > > Vincent > > _,,,^..^,,,_ (phone) > > -- _,,,^..^,,,_ best, Eliot

Jan. 24, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-01-15

by Stephane Ducasse

wow pavel! Thanks for your changelog! Stef On Mon, Jan 22, 2018 at 9:54 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > Getting the serialization working is a big step, good job. > > If you can get > > MaClientServerTestCase suite debug > > to pass, then you should be nearly home free; the rest is mostly just > high-level stuff that builds on that so the rest of the port should go > fairly smoothly. Wow. > > On Mon, Jan 22, 2018 at 2:47 AM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> - continuing on Ring 2 integration >> - work on Magma port to Pharo. It's very far from being in a usable >> state but some progress has been done: >> - make packages from the version 1.6-tests loadable, baseline >> - fix tests for collections (except two weak related) are green >> - fix indexing tests >> - object serialization tests are green except the tests for >> serialization of context >> >> Cheers, >> -- Pavel >> >

Jan. 24, 2018

[Pharo 7.0-dev] Build #446: 21046-small-speedup-for-reading-code-of-methods-with-EmbeddedSource

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

There is a new Pharo build available! The status of the build #446 was: SUCCESS. The Pull Request #709 was integrated: "21046-small-speedup-for-reading-code-of-methods-with-EmbeddedSource" Pull request url: https://github.com/pharo-project/pharo/pull/709 Issue Url: https://pharo.fogbugz.com/f/cases/21046 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 24, 2018

Re: [Pharo-dev] [ANN] Next Pharo release moved to end of year

by Stephane Ducasse

Hi Rafael Yes we will get such as list. Stef On Wed, Jan 24, 2018 at 10:21 AM, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > Hi Esteban, > > If it would possible to identify some tickets in FogBuz affordable for less > expererienced smalltalkers, > I think several devs here at Osoco (and other organizations) could > contribute with the Pharo development. > > I know It would be a small help, but it's better than nothing. > > Rafa > > 2018-01-23 18:54 GMT+00:00 Stephan Eggermont <stephan(a)stack.nl>: >> >> Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > Hi all, >> > >> > After some analysis of current condition of development, we decided to >> > move the upcoming release to end of the year (and not May, as usual). >> >> Thanks for the clear and timely decision. Having to delay is never nice, >> but with a high innovation rate comes a higher risk. Denial helps noone, >> keep up the good work! >> >> Stephan >> >> >> >> >> >

Jan. 24, 2018