October 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40334 Home: https://github.com/pharo-project/pharo-core

Oct. 27, 2014

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

by Levente Uzonyi

On Mon, 27 Oct 2014, stepharo wrote: > Levente > > I think that the first step is not to make sure that you cannot hack inside literals like mad. But to make sure that in 99.99 % of the case, this assumption can hold. > > Stef Let me sum it up: - The question is (by Clement) if it's okay to not implement the slow path. - He assumes that he doesn't have to implement it if literals are immutable. - I showed that literal immutability is not enough to avoid impelemting the slow path. So immutability doesn't affect anything about the need for implementing of the slow path. If Clement decides to not implement it, then one will be able to get the system into an inconsistent state, no matter if literals are immutable or not. If you think that the inconsistent state can only be achieved by hacking, then here's another example without "hacks": SomeClass >> #someMethod ^someBoolean ifTrue: [ Array with: 1 with: 2 with: 3 ] ifFalse: [ Array empty "we don't have to create a new array for this, right? :)" ] SomeOtherClass >> #someOtherMethod: anArray | copy | anArray doSomething. "let's grow that array" copy := Array new: anArray size. copy replaceFrom: 1 to: anArray size with: anArray startingAt: 1. anArray becomeForward: copy. "this is really cheap in Spur (and in VW; even collections and streams use it)" ThirdClass >> #yetAnotherMethod: aSomeClass | x | x := aSomeClass someMethod. y someOtherMethod: x. ^x And now, when #yetAnotherMethod: is sent, we swap the literal in Array class >> #empty with another non-empty array. Based on Eliot's comment about VW, I'm pretty sure the VW guys had problems like this, despite of having immutable literals. Levente

Oct. 27, 2014

MC logic looks strange

by stepharo

Hi when I merge code I see repeated patterns of MC loading all the files from main or inbox. I have the impression that we query really a lot the same repo. Does anybody look at this part? Stef

Oct. 27, 2014

Re: [Pharo-dev] [pharo-dev] image size, Ubuntu

by Max Leske

> On 27.10.2014, at 23:11, Pierre CHANSON <chans.pierre(a)gmail.com> wrote: > > Hi ! > > anyone knows how to increase the disk allocation size for an image on Ubuntu ? I can't find the command line for that. What do you mean by âdisk allocationâ? Hereâs the --help: ./pharo --help Usage: [<option>...] [<imageName> [<argument>...]] [<option>...] -- [<argument>...] Common <option>s: --help print this help message, then exit --memory <size>[mk] use fixed heap size (added to image size) --headless run in headless (no window) mode (default: false) --nohandlers disable sigsegv & sigusr1 handlers Notes: <imageName> defaults to `Pharo.image'. If `--memory' is not specified then the heap will grow dynamically. <argument>s are ignored, but are processed by the Squeak image. The first <argument> normally names a Squeak `script' to execute. Precede <arguments> by `--' to use default image. You can set the memory for the VM with "--memory 2048mâ for instance. Cheers, Max > > Thanks !! > > Pierre Chanson

Oct. 27, 2014

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

by stepharo

Levente I think that the first step is not to make sure that you cannot hack inside literals like mad. But to make sure that in 99.99 % of the case, this assumption can hold. Stef On 27/10/14 15:46, Levente Uzonyi wrote: > > > > On Mon, 27 Oct 2014, Eliot Miranda wrote: > >> I disagree. It's about an incremental improvement. A per-object > immutability bit used to protect against direct alteration of literals > works. Right now there's nothing to stop one recompiling a method, and > per-object immutability doesn't change that. So mutable compiled > methods are tolerable (at least in VW we kept methods mutable). But > having the bit stop direct modification of literals is goodness, not to > be avoided because it doesn't prevent more exotic modification via > become. > > But if you allow mutable CompiledMethods, then Clement's example can > be rewritten as: > > MyClass >> #foo > > ^#(false) first > ifFalse: [ > 'first call since compilation' logCr. > thisContext method in: [ :method | > (method literalAt: (method literals indexOf: #(false)) > put: { true }) ] ] > ifTrue: [ 'other calls' logCr ] > > (#becomeForward: could also be used on the literal). > > How will you avoid implementing the deoptimization of the method (the > slow path) when this is possible? > > Levente

Oct. 27, 2014

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

by stepharo

I think that immutable literals is the way to go. > 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 Craig Latta

Craig> In keeping with the principle of least surprise (and least time Craig> spent chasing strange bugs at 4am :), I would prefer that Craig> literals be immutable. Eliot> Sleep no sleep no sleep no sleep and no mad Eliot> Video machine to eat time, a city scene Eliot> I can't explain, strange bugs alone at 4am Eliot> The Seine alone at 4a.m, ... Cool, King Crimson agrees with us. :) Tudor> Talking about 4 am, you should also watch the coolest talk about Tudor> it: [1]. And a beautiful follow up: [2] Thanks! I'll save these for 4am, not long now... -C [1] http://www.ted.com/talks/rives_on_4_a_m [2] http://www.ted.com/talk/rives_a_museum_of_4_o_clock_in_the_morning -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Oct. 27, 2014

[pharo-dev] image size, Ubuntu

by Pierre CHANSON

Hi ! anyone knows how to increase the disk allocation size for an image on Ubuntu ? I can't find the command line for that. Thanks !! Pierre Chanson

Oct. 27, 2014

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

by Levente Uzonyi

On Mon, 27 Oct 2014, Eliot Miranda wrote: > I disagree.Â It's about an incremental improvement.Â A per-object immutability bit used to protect against direct alteration of literals works.Â Right now there's nothing to stop one recompiling a method, and per-object immutability doesn't change that.Â So mutable compiled methods are tolerable (at least in VW we kept methods mutable).Â But having the bit stop direct modification of literals is goodness, not to be avoided because it doesn't prevent more exotic modification via become. But if you allow mutable CompiledMethods, then Clement's example can be rewritten as: MyClass >> #foo ^#(false) first ifFalse: [ 'first call since compilation' logCr. thisContext method in: [ :method | (method literalAt: (method literals indexOf: #(false)) put: { true }) ] ] ifTrue: [ 'other calls' logCr ] (#becomeForward: could also be used on the literal). How will you avoid implementing the deoptimization of the method (the slow path) when this is possible? Levente

Oct. 27, 2014

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

by Tudor Girba

Talking about 4 am, you should also watch the coolest talk about it: http://www.ted.com/talks/rives_on_4_a_m And a beautiful follow up: http://www.ted.com/talks/rives_a_museum_of_4_o_clock_in_the_morning Cheers, Doru On Mon, Oct 27, 2014 at 5:13 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > 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) > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 27, 2014