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

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

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

by phil＠highoctane.be

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. > We may want to have some Pharo-binary-bucket somewhere on the web, like we do have smalltalkhub. A kind of binary gist. For this to be a reference, we need to have a community shared solution. What does exists? (S3?) For huge resources, bittorrent-style would be nice too. Phil > > >> 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

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

by HernÃ¡n Morales Durand

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

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

by Richard Sargent

Paul DeBruicker wrote > If ConfigurationOfPetitParser is loaded in your image you should be able > run the following code in a workspace to load the 'Core' metacello group: > > ConfigurationOfPetitParser project stableVersion load: 'Core' > > > I'm not sure of the canonical location of the ConfigurationOfPetitParser > though, as I don't use it,. Thanks, Paul. The Configuration Browser is pre-configured with three repository locations. I was able to find PetitParser (TudorGirba.43) on the ss3 repository. Loading Core alone worked. That still leaves the question of loading the PetitParser UI stuff and its prerequisites. -- 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] Way to embed efficiently data?

by Andreas Wacknitz

> 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 <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 <http://dl.dropboxusercontent.com/u/103833630/libsodium.zip>' ]. > Smalltalk os isUnix > ifTrue: [ ^ 'http://dl.dropboxusercontent.com/u/103833630/libsodium.so.gz <http://dl.dropboxusercontent.com/u/103833630/libsodium.so.gz>' ]. > Smalltalk os isMacOSX > ifTrue: [ ^ 'http://dl.dropboxusercontent.com/u/103833630/libsodium.dylib.gz <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. 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â¦ Regards Andreas > > Phil > > On Mon, Oct 27, 2014 at 1:40 AM, Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: > > > On Oct 26, 2014, at 9:22 PM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > > > > 2014-10-26 20:14 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>>: > >> I donât think that storing binary files in git is good practice > >> > >> git shines on declarative content > >> > >> But Google about it and see how other people experiences resulted. Are they happy or not? > > > > It's not efficient in terms of storage, but I know of people who uses > > git to manage PSD files and other "non code" files. > > > > I'm particularly interested in git for Pharo for the same reason, I > > want to be able to commit everything (Pharo and static files) in a > > single command. > > Well, then you should use that in the exact same way you would commit in one command entire VirtualBox guests VMs > > git is a tool suposed to help in integrating work and not make your life too hard when solving merge conflicts when they happen. If you do things that diverge from that then, well.. then you start eroding the profit itâs trying to give you > > > > > Esteban A. Maringolo > > > > >

Oct. 27, 2014

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

by Eliot Miranda

On Mon, Oct 27, 2014 at 9:55 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > > On Mon, 27 Oct 2014, Eliot Miranda wrote: > > See my message earlier in the thread. Via a per-object isImmutable bit. >> > > 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. > > 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. -- best, Eliot

Oct. 27, 2014

Re: [Pharo-dev] How to add a trait to a class from an external package?

by phil＠highoctane.be

I've used the following approach for a couple methods I need in more than one place: - fileout the protocol from class A. - open filebrowser, find the fileout file. - search/replace in the bottom pane the class A by class B - fileIn Quick and works. Phil On Mon, Oct 27, 2014 at 1:49 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I wonder how JavaScript guys manage which behavior comes from base and > which from a mixin. :) > I used ExtJS, and you could do extensive use of mixins, but once they > were mixed, it's all the same piece of code. > > I started using Traits and then moved away back to good'ol > subclassification and, in some cases, code duplication. > > > Regards! > Esteban A. Maringolo > > > 2014-10-27 7:44 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > Basically, plugging a trait in a class dynamically should be doable. > > Especially with our beloved platform that can ;-) > > > > Otherwise, this reduces their usefulness quite a lot for composing things > > cleanly. > > > > Hey, Javascript people can do these things. Admittedly, all is dirty all > the > > time there .... :-p > > > > Phil > >

Oct. 27, 2014

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

by Paul DeBruicker

If ConfigurationOfPetitParser is loaded in your image you should be able run the following code in a workspace to load the 'Core' metacello group: ConfigurationOfPetitParser project stableVersion load: 'Core' I'm not sure of the canonical location of the ConfigurationOfPetitParser though, as I don't use it,. hth. Paul Richard Sargent wrote > > 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