- Pharo-dev - lists.pharo.org

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

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

by Eliot Miranda

On Mon, Oct 27, 2014 at 12:12 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > > On Mon, 27 Oct 2014, Eliot Miranda wrote: > > So you would set the bit for the CompiledMethod and all literals >>> (including sub-arrays, floats, integers, booleans etc)? >>> >> >> The literals, definitely. Whether the bit is set for compiled methods or >> not depends on things like how easy you want to be able to update the >> source pointer or add/delete properties. >> > > If the CompiledMethod itself is not immutable, then one can replace its > top level literals easily. > If it's immutable, then the system will face all kind of problems, like > adding the correct trailer during method installation. > You could say "no problem, I'll use #becomeForward: to do it, it's fast in > Spur", but that's what my other question is about. > > >> >>> Does the set immutability bit also mean that the object can't be >>> swapped with #become:? >>> >> >> That's debatable, but in VW we disallowed two-way become: and allowed >> one-way become: for immutables. I think that's right. one-way become is >> about references to objects, two-way become is about changing objects >> themselves. >> > > It's not about #become: vs #becomeForward:. If objects with the immutable > bit set can be replaced with #becomeForward:, then the literals are not > really immutable, because they can be changed. > If you also want to check if there are immutable objects pointing to the > object which is about to be replaced, then the performance of > #becomeForward: would become as slow as in the non-Spur VMs. > 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. -- best, Eliot

Oct. 27, 2014

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

by Levente Uzonyi

On Mon, 27 Oct 2014, Eliot Miranda wrote: >> So you would set the bit for the CompiledMethod and all literals (including sub-arrays, floats, integers, booleans etc)? > > The literals, definitely.Â Whether the bit is set for compiled methods or not depends on things like how easy you want to be able to update the source pointer or add/delete properties. If the CompiledMethod itself is not immutable, then one can replace its top level literals easily. If it's immutable, then the system will face all kind of problems, like adding the correct trailer during method installation. You could say "no problem, I'll use #becomeForward: to do it, it's fast in Spur", but that's what my other question is about. >Â >> Does the set immutability bit also mean that the object can't be swapped with #become:? > > That's debatable, but in VW we disallowed two-way become: and allowed one-way become: for immutables.Â I think that's right. Â one-way become is about references to objects, two-way become is about changing objects themselves.Â It's not about #become: vs #becomeForward:. If objects with the immutable bit set can be replaced with #becomeForward:, then the literals are not really immutable, because they can be changed. If you also want to check if there are immutable objects pointing to the object which is about to be replaced, then the performance of #becomeForward: would become as slow as in the non-Spur VMs. Levente

Oct. 27, 2014

Re: [Pharo-dev] Way to embed efficiently data?

by phil＠highoctane.be

Could be nice... http://blog.bittorrent.com/2013/05/23/how-i-created-my-own-personal-cloud-u… Phil On Mon, Oct 27, 2014 at 7:32 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > > > 2014-10-27 15:00 GMT-03:00 Andreas Wacknitz <a.wacknitz(a)gmx.de>: > >> >> Am 27.10.2014 um 02:01 schrieb phil(a)highoctane.be: >> >> I've seen a couple configurations retrieve tar files from DropBox. >> >> http://www.smalltalkhub.com/#!/~hernan/ApplicationSecurity loads NaCl >> library (libsodium) from Dropbox. >> >> See ConfigurationOfNacl>>preLoad >> >> | url fileRef response | >> >> url := self platformLibraryUrl asZnUrl. >> fileRef := FileSystem disk workingDirectory / url pathSegments last. >> (response := ZnEasy get: url) isSuccess >> ifTrue: [ fileRef writeStreamDo: [ : stream | stream nextPutAll: response >> contents ] ] >> ifFalse: [ self error: 'Cannot download compiled library file' ]. >> self uncompress: fileRef. >> >> >> platformLibraryUrl >> " Answer a download URL for the compiled version of library " >> >> Smalltalk os isWin32 >> ifTrue: [ ^ 'http://dl.dropboxusercontent.com/u/103833630/libsodium.zip' >> ]. >> Smalltalk os isUnix >> ifTrue: [ ^ 'http://dl.dropboxusercontent.com/u/103833630/libsodium.so.gz' >> ]. >> Smalltalk os isMacOSX >> ifTrue: [ ^ ' >> http://dl.dropboxusercontent.com/u/103833630/libsodium.dylib.gz' ]. >> self error: 'Cannot find library for your OS platform'. >> >> It looks like a good way to solve these things. Forget about Dropbox >> versioning. But with a proper naming scheme, it is doable. >> >> >> For me this sounds like a receipt for disaster in the long run. >> > > Is just a resource download, I am running an Iliad web site and two > applications for over a year downloading resources like that and never > failed, so no disasters. > > >> Version management is about to be able to reliably load versions. Moving >> parts outside of a controlled environment will make you unhappy sooner or >> laterâ¦ >> >> > > As Phil said, that is not suitable for versioning, but there is nothing > stopping you from implementing or adapting Monticello to the best version > management you can imagine. > > Cheers, > > HernÃ¡n > > >

Oct. 27, 2014