- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Can anyone provide me with clear, complete, and detailed instructions for loading PetitParser into Pharo 3.0?

by Richard Sargent

Sean P. DeNigris wrote > If you don't need the UI, just load the 'Core' group and you should be > fine. Thanks for replying, Sean. Unfortunately, I don't know how to process your answer. What actions do I need to do in what window or what expressions do I need to evaluate to achieve this? And likewise, if I do want to load the UI, what do I need to do? Thanks, Richard -- View this message in context: http://forum.world.st/Can-anyone-provide-me-with-clear-complete-and-detaile… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Eliot Miranda

On Mon, Oct 27, 2014 at 9:19 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Mon, 27 Oct 2014, ClÃ©ment Bera wrote: > > Hey guys, >> I was discussing about methods like that with Marcus: >> >> MyClass>>foo >> #(false) first >> ifFalse: [ >> 'first call since compilation' logCr. >> #(false) at: 1 put: true ] >> ifTrue: [ 'other calls' logCr ] >> >> DoIt: >> 4 timesRepeat: [MyClass new foo ] >> >> Transcript: >> 'first call since compilation' >> 'other calls' >> 'other calls' >> 'other calls' >> >> In the sista image/VM, we are most probably going with Eliot to implement >> a slow path when you edit the literal of a method (deoptimizing the method) >> so we can consider that the literals are immutable in the >> generic case (and if it's not true, execution falls back to a slow path). >> >> But I was thinking, does it worth it to implement the slow path ? >> Couldn't we just put literals as immutable all the time ? >> The methods as the one shown before would not work any more. But does >> someone use it ? >> > > This method was used in Seaside (or some Seaside extension) to cache the > contents of files in methods. > > By the way, how would you ensure immutability? > See my message earlier in the thread. Via a per-object isImmutable bit. > I mean, how would you prevent something like this? > > MyClass >> foo > > ^#('placeHolder') > > And then > > (((MyClass >> #foo) literalAt: 1) at: 1) becomeForward: Object new > > > Levente > > P.S.: why isn't this on the vm-dev list? > > >> ... >> >> >> -- best, Eliot

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Marcus Denker

> On 27 Oct 2014, at 17:16, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2014-10-27 17:03 GMT+01:00 Marcus Denker <marcus.denker(a)gmail.com <mailto:marcus.denker@gmail.com>>: > > > > > I could imagine cases where, in very tight memory situations or with very very large literals, we could make use of modifying literals. But I'm not sure this is a significant requirement, or that it couldn't be considered if there is a significant (and rich) use case to fund the development of the slow path. > > Pharos does not target classic âresource constraintâ embedded scenarios. > (else we would do many things a lot different) > Is there a critic rule catching that sort of thing? That we could run on Squeaksource / Smalltalkhub? > No, as you can hand a reference to a literal over to someone else who does not even know that it is a literalâ¦ this dreaded âam I going insane, itâs writing right hereâ bug where you change a string somewhere that actually is a string literal of some methodâ¦ > > You mean, as in: > > MyClass>>foo > #(false) first > ifFalse: [ > 'first call since compilation' logCr ] > ifTrue: [ 'other calls' logCr ]. > ^ #(false) > > in a workspace > > 4 timesRepeat: [MyClass new foo at: 1 put: true ] > Or even easierâ¦ someMethod ^âoohhhâ MyClass new someMethod at: 1 put: $N. the execute MyClass new someMethod and wonder where that string comes from. Marcus

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Levente Uzonyi

On Mon, 27 Oct 2014, ClÃ©ment Bera wrote: > Hey guys, > I was discussing about methods like that with Marcus: > > MyClass>>foo > #(false) firstÂ > ifFalse: [Â > 'first call since compilation' logCr.Â > #(false) at: 1 put: true ] > ifTrue: [ 'other calls' logCr ] > > DoIt: > 4 timesRepeat: [MyClass new foo ] > > Transcript: > 'first call since compilation' > 'other calls' > 'other calls' > 'other calls' > > In the sista image/VM, we are most probably going with Eliot to implement a slow path when you edit the literal of a method (deoptimizing the method) so we can consider that the literals are immutable in the > generic case (and if it's not true, execution falls back to a slow path). > > But I was thinking, does it worth it to implement the slow path ?Â > Couldn't we just put literals as immutable all the time ?Â > The methods as the one shown before would not work any more. But does someone use it ? This method was used in Seaside (or some Seaside extension) to cache the contents of files in methods. By the way, how would you ensure immutability? I mean, how would you prevent something like this? MyClass >> foo ^#('placeHolder') And then (((MyClass >> #foo) literalAt: 1) at: 1) becomeForward: Object new Levente P.S.: why isn't this on the vm-dev list? > > ... > > >

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Thierry Goubier

2014-10-27 17:03 GMT+01:00 Marcus Denker <marcus.denker(a)gmail.com>: > > > > > I could imagine cases where, in very tight memory situations or with very >> very large literals, we could make use of modifying literals. But I'm not >> sure this is a significant requirement, or that it couldn't be considered >> if there is a significant (and rich) use case to fund the development of >> the slow path. >> >> Pharos does not target classic "resource constraint" embedded scenarios. > (else we would do many things a lot different) > >> Is there a critic rule catching that sort of thing? That we could run on >> Squeaksource / Smalltalkhub? >> > No, as you can hand a reference to a literal over to someone else who does > not even know that it is a literal... this dreaded "am I going insane, it's > writing right here" bug where you change a string somewhere that actually > is a string literal of some method... > You mean, as in: MyClass>>foo #(false) first ifFalse: [ 'first call since compilation' logCr ] ifTrue: [ 'other calls' logCr ]. ^ #(false) in a workspace 4 timesRepeat: [MyClass new foo at: 1 put: true ] Thierry > > Marcus >

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Eliot Miranda

On Oct 27, 2014, at 8:48 AM, Craig Latta <craig(a)netjam.org> wrote: > > Hoi ClÃ©ment-- > > In keeping with the principle of least surprise (and least time > spent chasing strange bugs at 4am :), I would prefer that literals be > immutable. Sleep no sleep no sleep no sleep and no mad Video machine to eat time, a city scene I can't explain, strange bugs alone at 4am The insane alone at 4a.m, ... > > > thanks, > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Eliot Miranda

Hi ClÃ©ment, IMO literals should be immutable all the time, and IMO the best way is via a per-object isImmutable bit. We implemented this for VW in 7.0 and it was a positive experience. I've implemented the "create an immutable subclass for each literal class" and it has lots of problems (thing printString or storeString having to produce something like 'an immutable string' asMutableString for a normal string). The per-object bit has other uses too. Object databases such as GemStone can use it to make write-through scheme efficient. The only problem we had was dealing with broken user code that was depending on mutable literals. This is of course a bug, but folks thought we shouldn't just break user code so Alan Knight provided a system setting that write a warning to the transcript and updated the literal instead if raising an error. That's easy to do, if IMO dubious. Fixing the code is as easy as sending copy to the literal in question, the copy being mutable. Now I implemented the per-object bit for the Newspeak interpreter WM so you'll find lots of the necessary work is there waiting to be ported to the Stack and Cog VMs. I've not had the time to implement the JIT support to catch inst var and at:put: writes to immutables. But it shouldn't be too much work. Volunteers? Eliot (phone) On Oct 27, 2014, at 8:22 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hey guys, > > I was discussing about methods like that with Marcus: > > MyClass>>foo > #(false) first > ifFalse: [ > 'first call since compilation' logCr. > #(false) at: 1 put: true ] > ifTrue: [ 'other calls' logCr ] > > DoIt: > 4 timesRepeat: [MyClass new foo ] > > Transcript: > 'first call since compilation' > 'other calls' > 'other calls' > 'other calls' > > In the sista image/VM, we are most probably going with Eliot to implement a slow path when you edit the literal of a method (deoptimizing the method) so we can consider that the literals are immutable in the generic case (and if it's not true, execution falls back to a slow path). > > But I was thinking, does it worth it to implement the slow path ? > Couldn't we just put literals as immutable all the time ? > The methods as the one shown before would not work any more. But does someone use it ? > > ... >

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Marcus Denker

I could imagine cases where, in very tight memory situations or with very very large literals, we could make use of modifying literals. But I'm not sure this is a significant requirement, or that it couldn't be considered if there is a significant (and rich) use case to fund the development of the slow path. Pharos does not target classic âresource constraintâ embedded scenarios. (else we would do many things a lot different) Is there a critic rule catching that sort of thing? That we could run on Squeaksource / Smalltalkhub? No, as you can hand a reference to a literal over to someone else who does not even know that it is a literalâ¦ this dreaded âam I going insane, itâs writing right hereâ bug where you change a string somewhere that actually is a string literal of some methodâ¦ Â Â Marcus

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Thierry Goubier

2014-10-27 16:22 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hey guys, > > I was discussing about methods like that with Marcus: > > MyClass>>foo > #(false) first > ifFalse: [ > 'first call since compilation' logCr. > #(false) at: 1 put: true ] > ifTrue: [ 'other calls' logCr ] > What, you can do that? > > DoIt: > 4 timesRepeat: [MyClass new foo ] > > Transcript: > 'first call since compilation' > 'other calls' > 'other calls' > 'other calls' > > In the sista image/VM, we are most probably going with Eliot to implement > a slow path when you edit the literal of a method (deoptimizing the method) > so we can consider that the literals are immutable in the generic case (and > if it's not true, execution falls back to a slow path). > > But I was thinking, does it worth it to implement the slow path ? > Couldn't we just put literals as immutable all the time ? > I would do that, yes. > The methods as the one shown before would not work any more. But does > someone use it ? > I could imagine cases where, in very tight memory situations or with very very large literals, we could make use of modifying literals. But I'm not sure this is a significant requirement, or that it couldn't be considered if there is a significant (and rich) use case to fund the development of the slow path. Is there a critic rule catching that sort of thing? That we could run on Squeaksource / Smalltalkhub? Thierry > > ... > >

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Craig Latta

Hoi ClÃ©ment-- In keeping with the principle of least surprise (and least time spent chasing strange bugs at 4am :), I would prefer that literals be immutable. thanks, -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Oct. 27, 2014