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

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

Re: [Pharo-dev] Loading configuration of spur

by Sven Van Caekenberghe

> 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. >> 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

> 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? 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. and vm development is in VMMaker.oscog in Monticello at source.squeak.org/VMMaker > > Cheers, > pocho > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires

March 12, 2018

Re: [Pharo-dev] Loading configuration of spur

by Eliot Miranda

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. > 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] [Pharo-users] feenk log

by Alistair Grant

On 11 March 2018 at 21:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Here is an update of the work on Bloc, Brick and GT. As always, please do let us know what you think. > > [snip/] > > - Andrei put together a beautiful description of a scenario in which an application is molded interactively in the Playground & Inspector. The subject is face recognition, and the resulting code is both functional and explainable. This is intended as a tutorial material that shows what moldable development means and how it changes the way we program: > https://twitter.com/feenkcom/status/972907051448979458 The GToolkit has certainly influenced how I program - and this is a great article that lays it out quite clearly. If I'm developing a new application the first few iterations of the UI are pretty much always extensions to the inspector. I also enjoyed Tudor's interview on No Fluff Just Stuff which discusses a real world use of this: - Podcast audio: https://player.fm/series/no-fluff-just-stuff/changing-the-way-we-code-w-tud… - No Fluff Just Stuff: https://nofluffjuststuff.com/home/main Thanks! Alistair

March 12, 2018