- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Evaluate command handler broken because of AnObsoleteZnCrPortableWriteStream

by Marcus Denker

> On 13 Mar 2018, at 08:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 13 Mar 2018, at 08:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >>> On 13 Mar 2018, at 07:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> You probably loaded Zinc #stable which does not yet include ZnCrPortableWriteStream. Load #bleedingEdge instead. >>> >>> This has bitten me as well a couple of times, I will promote a new stable Zinc later today. >>> >> we need to really see how to get synced in Pharo7. >> >> Marcus > > Yes, but the sync has to happen both ways: I first have to pick up all the changes that we done directly in Pharo 7 as not to overwrite anybody's work. That is tedious, delicate work. We need to find a way that porting is not neededâ¦ that the changes are done directly in Zinc. Marcus

March 13, 2018

Re: [Pharo-dev] Evaluate command handler broken because of AnObsoleteZnCrPortableWriteStream

by Marcus Denker

> On 13 Mar 2018, at 08:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 13 Mar 2018, at 08:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >>> On 13 Mar 2018, at 07:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> You probably loaded Zinc #stable which does not yet include ZnCrPortableWriteStream. Load #bleedingEdge instead. >>> >>> This has bitten me as well a couple of times, I will promote a new stable Zinc later today. >>> >> we need to really see how to get synced in Pharo7. >> >> Marcus > > Yes, but the sync has to happen both ways: I first have to pick up all the changes that we done directly in Pharo 7 as not to overwrite anybody's work. That is tedious, delicate work. Indeedâ¦ I just saw that one change I wanted to do since years (moving #asUrl to Zinc) has been done. (we had a whole package just for these extension methods). This was a change I wanted to do since years, but as Zinc is backward compatible, doing cleanups like this are very very difficultâ¦ and in the end, as a single change this is of course not importantâ¦ but the mistake is to therefore conclude to never do these tiny changesâ¦ as it is a number game: for 1 itâs not important, but if you manage to do 10000 or 20000 of these tiny changes, where the trivial later cleanups depend on the earlierâ¦ and are only trivial because the earlier were doneâ¦ Marcus

March 13, 2018

Re: [Pharo-dev] Evaluate command handler broken because of AnObsoleteZnCrPortableWriteStream

by Sven Van Caekenberghe

> On 13 Mar 2018, at 08:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 13 Mar 2018, at 07:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> You probably loaded Zinc #stable which does not yet include ZnCrPortableWriteStream. Load #bleedingEdge instead. >> >> This has bitten me as well a couple of times, I will promote a new stable Zinc later today. >> > we need to really see how to get synced in Pharo7. > > Marcus Yes, but the sync has to happen both ways: I first have to pick up all the changes that we done directly in Pharo 7 as not to overwrite anybody's work. That is tedious, delicate work.

March 13, 2018

Something is happening...

by Marcus Denker

Hi, There is something odd happeningâ¦ or better: There is *a lot* happening. Just one example: for the Newsletter, the original idea was to send out once a month a post with 3 things, some of them recycled (e.g. pointers to existing projects, re-use âsuccess storiesâ, things like that. Now already some months ago I had to add âand here are some other interesting announcements, blog posts, videosâ. But this month, the list of things for the newsletter TODO list contains over 60 entries. With the exception of maybe 5, these are just things that happened between sending the February newsletter and today. Newsletter March should be ready till this thursday, I hope, subscribe or read the oder ones here: http://newsletter.pharo.org <http://newsletter.pharo.org/> Marcus

March 13, 2018

Re: [Pharo-dev] Evaluate command handler broken because of AnObsoleteZnCrPortableWriteStream

by Marcus Denker

> On 13 Mar 2018, at 07:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > You probably loaded Zinc #stable which does not yet include ZnCrPortableWriteStream. Load #bleedingEdge instead. > > This has bitten me as well a couple of times, I will promote a new stable Zinc later today. > we need to really see how to get synced in Pharo7. Marcus

March 13, 2018

Re: [Pharo-dev] Evaluate command handler broken because of AnObsoleteZnCrPortableWriteStream

by Sven Van Caekenberghe

You probably loaded Zinc #stable which does not yet include ZnCrPortableWriteStream. Load #bleedingEdge instead. This has bitten me as well a couple of times, I will promote a new stable Zinc later today. > On 13 Mar 2018, at 00:34, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Hello! > > I have a Jenkins build for MaterialDesignLite and the Pharo 7 build > never end. > > I load the code via the command line "eval" with the "--save" parameter > and a Metacello command. > > While adding some log I found the problem. > > It comes from this method: > > EvaluateCommandLineHandler>>evaluate: aStream > | result | > [ > result := Smalltalk compiler evaluate: aStream. > self hasSessionChanged > ifFalse: [ > self stdout > print: result; > lf ] ] > on: Error > do: [ :error | self handleError: error ] > > In Pharo 6 it ends perfectly. > > In Pharo 7 there is an error and we end up in the catch. > > Here is the stack I could isolate: > > > MessageNotUnderstood(Exception)>>signal > UndefinedObject(Object)>>doesNotUnderstand: #'>=' > AnObsoleteZnCrPortableWriteStream(WriteStream)>>nextPut: > [ :v | self nextPut: v ] in > AnObsoleteZnCrPortableWriteStream(Stream)>>nextPutAll: > ByteSymbol(SequenceableCollection)>>do: > AnObsoleteZnCrPortableWriteStream(Stream)>>nextPutAll: > AnObsoleteZnCrPortableWriteStream(WriteStream)>>nextPutAll: > MultiByteFileStream(StandardFileStream)>>printOn: > AnObsoleteZnCrPortableWriteStream(Stream)>>print: > VTermOutputDriver>>print: > > I have no idea how to correct this and it's pretty late now. Maybe > someone will know :) > > https://pharo.fogbugz.com/f/cases/21566/EvaluateCommandLineHandler-is-broke… > > -- > Cyril Ferlicot > https://ferlicot.fr >

March 13, 2018

Evaluate command handler broken because of AnObsoleteZnCrPortableWriteStream

by Cyril Ferlicot D.

Hello! I have a Jenkins build for MaterialDesignLite and the Pharo 7 build never end. I load the code via the command line "eval" with the "--save" parameter and a Metacello command. While adding some log I found the problem. It comes from this method: EvaluateCommandLineHandler>>evaluate: aStream | result | [ result := Smalltalk compiler evaluate: aStream. self hasSessionChanged ifFalse: [ self stdout print: result; lf ] ] on: Error do: [ :error | self handleError: error ] In Pharo 6 it ends perfectly. In Pharo 7 there is an error and we end up in the catch. Here is the stack I could isolate: MessageNotUnderstood(Exception)>>signal UndefinedObject(Object)>>doesNotUnderstand: #'>=' AnObsoleteZnCrPortableWriteStream(WriteStream)>>nextPut: [ :v | self nextPut: v ] in AnObsoleteZnCrPortableWriteStream(Stream)>>nextPutAll: ByteSymbol(SequenceableCollection)>>do: AnObsoleteZnCrPortableWriteStream(Stream)>>nextPutAll: AnObsoleteZnCrPortableWriteStream(WriteStream)>>nextPutAll: MultiByteFileStream(StandardFileStream)>>printOn: AnObsoleteZnCrPortableWriteStream(Stream)>>print: VTermOutputDriver>>print: I have no idea how to correct this and it's pretty late now. Maybe someone will know :) https://pharo.fogbugz.com/f/cases/21566/EvaluateCommandLineHandler-is-broke… -- Cyril Ferlicot https://ferlicot.fr

March 12, 2018

Re: [Pharo-dev] Loading configuration of spur

by Stephane Ducasse

I was reading the medium article of andrei and just discussing with clement on how can we improve the tooling for the VM bug chasing and other activities and this would be a really great improvement. I should watch the videos of clement on debugging the JIT first. On Mon, Mar 12, 2018 at 8:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 12 Mar 2018, at 19:50, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Sven, >> >>> On Mar 12, 2018, at 10:46 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>> >>>> On 12 Mar 2018, at 17:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> Hi Javier, >>>> >>>> >>>>> On Mar 11, 2018, at 11:14 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: >>>>> >>>>> Ok, now I moved forward but cannot load vmmaker sources into a pharo 61 image, is that supported? >>>> >>>> Both ClÃ©ment and I use Squeak for vm development at the moment. We don't have the cycles to keep it working in both as yet. >>> >>> Which is a pity for a VM that is called Open Smalltalk. >>> >>> The net result is that you are missing out on a much larger base of curious developers and potential contributors. >> >> Agreed. But it is hopefully only temporary. The package did load in Pharo a few years ago, and the prospect of using GT tools is an incentive for getting this working again. As the multiple bytecode set support stabilizes in both Squeak and Pharo I expect it to get easier to maintain VMMaker.oscog in both dialects. VMMaker.oscog had to contain many patches to support the CM development of the SistaV1 bytecode set, and the load failure Javier is seeing is related to this. As time allows I am eliminating these patches. So hopefully it'll load in Pharo soon. > > That would be really great. > >>>>> I have this snippet that doesn't work: >>>>> >>>>> Metacello new >>>>> filetreeDirectory: '../VMMaker/mc'; >>>>> baseline: 'Spur'; >>>>> load >>>>> >>>>> where ../VMMaker/mc is a clone of the official pharo repo at github. >>>>> >>>>> Cheers, >>>>> pocho >>>>> >>>>> -- >>>>> Javier PimÃ¡s >>>>> Ciudad de Buenos Aires > >

March 12, 2018

Re: [Pharo-dev] Loading configuration of spur

by Sven Van Caekenberghe

> On 12 Mar 2018, at 19:50, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Sven, > >> On Mar 12, 2018, at 10:46 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 12 Mar 2018, at 17:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi Javier, >>> >>> >>>> On Mar 11, 2018, at 11:14 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: >>>> >>>> Ok, now I moved forward but cannot load vmmaker sources into a pharo 61 image, is that supported? >>> >>> Both ClÃ©ment and I use Squeak for vm development at the moment. We don't have the cycles to keep it working in both as yet. >> >> Which is a pity for a VM that is called Open Smalltalk. >> >> The net result is that you are missing out on a much larger base of curious developers and potential contributors. > > Agreed. But it is hopefully only temporary. The package did load in Pharo a few years ago, and the prospect of using GT tools is an incentive for getting this working again. As the multiple bytecode set support stabilizes in both Squeak and Pharo I expect it to get easier to maintain VMMaker.oscog in both dialects. VMMaker.oscog had to contain many patches to support the CM development of the SistaV1 bytecode set, and the load failure Javier is seeing is related to this. As time allows I am eliminating these patches. So hopefully it'll load in Pharo soon. That would be really great. >>>> I have this snippet that doesn't work: >>>> >>>> Metacello new >>>> filetreeDirectory: '../VMMaker/mc'; >>>> baseline: 'Spur'; >>>> load >>>> >>>> where ../VMMaker/mc is a clone of the official pharo repo at github. >>>> >>>> Cheers, >>>> pocho >>>> >>>> -- >>>> Javier PimÃ¡s >>>> Ciudad de Buenos Aires

March 12, 2018

Re: [Pharo-dev] Loading configuration of spur

by Eliot Miranda

Hi Sven, > On Mar 12, 2018, at 10:46 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 12 Mar 2018, at 17:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Javier, >> >> >>> On Mar 11, 2018, at 11:14 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: >>> >>> Ok, now I moved forward but cannot load vmmaker sources into a pharo 61 image, is that supported? >> >> Both ClÃ©ment and I use Squeak for vm development at the moment. We don't have the cycles to keep it working in both as yet. > > Which is a pity for a VM that is called Open Smalltalk. > > The net result is that you are missing out on a much larger base of curious developers and potential contributors. Agreed. But it is hopefully only temporary. The package did load in Pharo a few years ago, and the prospect of using GT tools is an incentive for getting this working again. As the multiple bytecode set support stabilizes in both Squeak and Pharo I expect it to get easier to maintain VMMaker.oscog in both dialects. VMMaker.oscog had to contain many patches to support the CM development of the SistaV1 bytecode set, and the load failure Javier is seeing is related to this. As time allows I am eliminating these patches. So hopefully it'll load in Pharo soon. > >>> I have this snippet that doesn't work: >>> >>> Metacello new >>> filetreeDirectory: '../VMMaker/mc'; >>> baseline: 'Spur'; >>> load >>> >>> where ../VMMaker/mc is a clone of the official pharo repo at github. >>> >>> Cheers, >>> pocho >>> >>> -- >>> Javier PimÃ¡s >>> Ciudad de Buenos Aires >> > >

March 12, 2018