- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] New stable VM version.

by Esteban Lorenzano

> On 18 Jan 2019, at 15:57, Sean P. DeNigris via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: "Sean P. DeNigris" <sean(a)clipperadams.com> > Subject: Re: [ANN] New stable VM version. > Date: 18 January 2019 at 15:57:12 CET > To: pharo-dev(a)lists.pharo.org > > > EstebanLM wrote >> Enjoy > > Thanks! Which image versions does this affect? I want to clear my Launcher > cachesâ¦ Pharo 7.0 and Pharo 8.0 images. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > >

Jan. 18, 2019

[ Save The Date ] Pharo Days 2019: Thursday April 4 & Friday April 5 @ Lille, FR

by Sven Van Caekenberghe

[ Save The Date ] Pharo Days 2019: Thursday April 4 & Friday April 5 @ Lille, FR Dear members of the Pharo community, We are happy to announce that we will be organising Pharo Days this year, in Lille, France. This will be a two day event: Thursday April 4 & Friday April 5. The main venue will be the Amphitheatre of INRIA Lille - Nord Europe. Each day will consist of a number of short 20 to 30 minutes tech talks in the morning, with a more free format in the afternoon: general hacking space, pair programming, demos, side meetings, tutorials, coding sprints, Q&A's, shows us your projects - real life human interaction. Of course, there will be social events as well. Please join us to make this another successful edition, after Annecy (FR) 2011, Lille 2012, Bern (CH) & Lille 2013, Lille 2015, Namur (BE) 2016 and Lille 2017. Mark your calendars, we will provide more details when they become available. The Pharo Board, Association & Consortium http://pharo.org http://association.pharo.org http://consortium.pharo.org

Jan. 18, 2019

Re: [ANN] New stable VM version.

by Sean P. DeNigris

EstebanLM wrote > Enjoy Thanks! Which image versions does this affect? I want to clear my Launcher cachesâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 18, 2019

Re: [Pharo-dev] [ANN] New stable VM version.

by Alistair Grant

Hi Esteban, On Fri, 18 Jan 2019 at 14:49, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Yes, I needed to promote a new stable version because last weekâs was having a bug (which is not fixed). > This one is based on the build: > > 201901172323-5a38b34 On Linux (Ubuntu 16.04) it's still the old VM: $ curl get.pharo.org/64/vm70 | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5320 100 5320 0 0 37021 0 --:--:-- --:--:-- --:--:-- 37202 Downloading the latest pharoVM: http://files.pharo.org/get-files/70/pharo64-linux-stable.zip pharo-vm/pharo Creating starter scripts pharo and pharo-ui $ ./pharo --version 5.0-201901051900 Sat Jan 5 19:12:50 UTC 2019 gcc 4.8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b64 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-f22c8934-2412-48ed-8180-7a42b62c7389 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /dev/shm/vm/pharo-vm/lib/pharo/5.0-201901051900 [default: /dev/shm/vm/pharo-vm/lib/pharo/5.0-201901051900/] Cheers, Alistair > Enjoy (and please report problems) > > Esteban

Jan. 18, 2019

Re: [Pharo-dev] DebugSession>>activePC:

by ducasse

>> >> On my TODO is to make it stand-alone and provide is as a âcompatibility transformâ, too. > > I have to dig because I remember that I went over all the deprecation in Pharo 60 and started to look at the ones that I > could âtransformifiedâ so that we get a nice package that rewrite more :) > > >> So we can add it to methods that we want to keep for compatibility, but they will nevertheless transform the code automatically. >> (this then might be disabled in production to not transform) > > Yes I like that I will look for my code. Apparently I published under MCSmalltalkhubRepository owner: 'PharoExtras' project: âMigrator' Several packages MigratorPharo60 contains what I did for Pharo60 probably Migrator contains some of the Pharo70 Now I would like to understand how to organise it. I have the impression that we should keep the one that can be transformed. I do not think that we should go to Pharo50 because it is too old. Stef

Jan. 18, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by ducasse

>>> I think that will just overcomplicate things. Right now, all Strings in Pharo are unicode strings. >> >> Cool. I didn't realise that. But to be pedantic, which unicode encoding? >> Should I presume from Sven's "UTF-8 encoding step" comment below >> and the WideString class comment "This class represents the array of 32 bit wide characters" >> that the WideString encoding is UTF-32? So should its comment be updated to advise that? > > Not really, Pharo Strings are a collection of Characters, each of which is a Unicode code point (yes a 32 bit one). > > An encoding projects this rather abstract notion onto a sequence of bytes, > > UTF-32 (ZnUTF32Encoder, https://en.wikipedia.org/wiki/UTF-32 <https://en.wikipedia.org/wiki/UTF-32>) is for example endian dependent. > > Read the first part of > > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… <https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf…> I love that book :) This is too cool to have cool doc

Jan. 18, 2019

Re: [Pharo-dev] DebugSession>>activePC:

by ducasse

Hi marcus >> I simply love the dynamic rewriting this is just too cool. We should systematically use it. >> I will continue to use it in any deprecation. >> > > On my TODO is to make it stand-alone and provide is as a âcompatibility transformâ, too. I have to dig because I remember that I went over all the deprecation in Pharo 60 and started to look at the ones that I could âtransformifiedâ so that we get a nice package that rewrite more :) > So we can add it to methods that we want to keep for compatibility, but they will nevertheless transform the code automatically. > (this then might be disabled in production to not transform) Yes I like that I will look for my code. > >> Now I have a simple question (You can explain it to me over lunch one of these days). >> >> I do not get why RBAST would not be a good representation for the compiler? >> I would like to know what is the difference. >> > I think it is a good one. I have not yet seen a reason why not. But remember, Roel left Squeak because his visitor pattern for the compiler was rejected as a dumb ideaâ¦ so there are definitely different views on core questions. > > E.g. the RB AST is annotated and the whole things for sure uses a bit more memory than the compiler designed for a machine from 1978. > >> You mean that before going from BC to AST was difficult? > > You need to do the mapping somehow, the compiler needs to remember the BC offset in the code generation phase and the AST (somehow) needs to store that information (either in every node or some table). > >> How opal performs it? It does not use the source of the method to recreate the AST but he can do it from the BC? >> > > It uses the IR (which I still am not 100% sure about, it came from the old âClosureCompilerâ Design and it turned out to be quite useful, for example for the mapping: every IR node retains the offset of the BC it creates, then the IR Nodes > retain the AST node that created them. > > -> so we just do a query: âIRMethod, give me the IRInstruction that created BC offset X. then âIR, which AST node did create you? then the AST Node: what is your highlight interval in the source? > > The devil is in the detail as one IR can produce multiple byte code offsets (and byte codes) and one byte code might be created by two IR nodes, but it does seem to work with some tricks. ok I see. And all in all it is really nice. > Which I want to remove by improving the mapping and even the IR moreâ¦ there is even the question: do we need the IR? could we not do it simpler? > > The IR was quite nice back when we tried to do things with byte code manipulation (Bytesurgeon), now it feels a bit of an overkill. But it simplifies e.g. the bc mapping. We should document this because this is cool. Stef

Jan. 18, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Sven Van Caekenberghe

> On 18 Jan 2019, at 14:45, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Fri, 18 Jan 2019 at 21:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 18 Jan 2019, at 14:23, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > > > I think that will just overcomplicate things. Right now, all Strings in Pharo are unicode strings. > > Cool. I didn't realise that. But to be pedantic, which unicode encoding? > Should I presume from Sven's "UTF-8 encoding step" comment below > and the WideString class comment "This class represents the array of 32 bit wide characters" > that the WideString encoding is UTF-32? So should its comment be updated to advise that? Not really, Pharo Strings are a collection of Characters, each of which is a Unicode code point (yes a 32 bit one). An encoding projects this rather abstract notion onto a sequence of bytes, UTF-32 (ZnUTF32Encoder, https://en.wikipedia.org/wiki/UTF-32) is for example endian dependent. Read the first part of https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > cheers -ben > > Characters are represented with their corresponding unicode codepoint. > > If all characters in a string have codepoints < 256 then they are just stored in a bytestring. Otherwise they are WideStrings. > > > > I think assuming a single representation for strings, and then encode when interacting with external apps/APIs is MUCH simpler. > > Absolutely ! > > (and yes I know that for outgoing FFI calls that might mean a UTF-8 encoding step, so be it).

Jan. 18, 2019

[Pharo 7.0] Build #131: 22887-TonelWritercreateDefaultOrganizationFrom-can-return-string

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

There is a new Pharo build available! The status of the build #131 was: SUCCESS. The Pull Request #2267 was integrated: "22887-TonelWritercreateDefaultOrganizationFrom-can-return-string" Pull request url: https://github.com/pharo-project/pharo/pull/2267 Issue Url: https://pharo.fogbugz.com/f/cases/22887 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 18, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Guillermo Polito

On Fri, Jan 18, 2019 at 2:46 PM Ben Coman <btc(a)openinworld.com> wrote: > > > On Fri, 18 Jan 2019 at 21:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> >> > On 18 Jan 2019, at 14:23, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> > >> > >> > I think that will just overcomplicate things. Right now, all Strings in >> Pharo are unicode strings. > > > Cool. I didn't realise that. But to be pedantic, which unicode encoding? > Should I presume from Sven's "UTF-8 encoding step" comment below > and the WideString class comment "This class represents the array of 32 > bit wide characters" > that the WideString encoding is UTF-32? So should its comment be updated > to advise that? > None :D That's the funny thing, they are not encoded. Actually, you should see Strings as collections of Characters, and Characters defined in terms of their abstract code points. ByteStrings are an optimized (just more compact) version that stores codepoints that fit in a byte. > cheers -ben > > Characters are represented with their corresponding unicode codepoint. >> > If all characters in a string have codepoints < 256 then they are just >> stored in a bytestring. Otherwise they are WideStrings. >> > >> > I think assuming a single representation for strings, and then encode >> when interacting with external apps/APIs is MUCH simpler. >> >> Absolutely ! >> >> (and yes I know that for outgoing FFI calls that might mean a UTF-8 >> encoding step, so be it). >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Jan. 18, 2019