- Pharo-users - lists.pharo.org

Re: [Pharo-users] Iceberg and git workflow

by stepharo

Hi Holger I will let nicolas reply detail. Now Iceberg is not equals to git. For that you can already take gitfiletree (whatever is its name) and your command line tool and do what you want. What would be the reason to duplicate git in Pharo? Exposing all the complexity of git to pharo? Iceberg is an abstraction over a distribution source versioning system looking like git. And it offers a process and workflow to manage projects stored in git. Now iceberg should cover main and common scenario. And one complex scenario we have is how to manage changes that cross cut several projects (pharo / RB / GT...). Stef > Hi, > > I am a heavy git user with languages like C, C++, Python, Ruby and even GNU Smalltalk and I hope iceberg will bring the same powerful experience to Pharo. > > Last Friday I started to add a bigger refactoring for a new feature to my software and didn't finish. Sadly today an issue in the code was found and I would like to fix this before fixing my code. I use this as opportunity to ask if Iceberg has some answers for that. > > > With a non-Pharo project I would do: > > a.) If current HEAD is same as origin/master > > $ git stash (stash away my not finished changes) > $ vi code.c fix.. > $ git commit -a -c "subject > > long explanation of fix > reference to bug" > $ git stash apply (and go back to working on my feature) > > > b.) E.g. if I finished n-commits but I am not fully done > > # store my work > $ git commit -a -m "Work In Progress hack.." > $ git checkout -b new-feature-branch > > # go back to master > $ git checkout master > $ git reset --hard origin/master (to restore) > > # work on the fix > $ vi code.c fix.. > $ git commit -a -c "fix..." > > # go back and continue on my fix > $ git checkout new-feature-branch > $ git rebase origin/master > $ git reset HEAD^1 > .. continue to work > > > >

Sept. 12, 2016

Iceberg and git workflow

by Holger Freyther

Hi, I am a heavy git user with languages like C, C++, Python, Ruby and even GNU Smalltalk and I hope iceberg will bring the same powerful experience to Pharo. Last Friday I started to add a bigger refactoring for a new feature to my software and didn't finish. Sadly today an issue in the code was found and I would like to fix this before fixing my code. I use this as opportunity to ask if Iceberg has some answers for that. With a non-Pharo project I would do: a.) If current HEAD is same as origin/master $ git stash (stash away my not finished changes) $ vi code.c fix.. $ git commit -a -c "subject long explanation of fix reference to bug" $ git stash apply (and go back to working on my feature) b.) E.g. if I finished n-commits but I am not fully done # store my work $ git commit -a -m "Work In Progress hack.." $ git checkout -b new-feature-branch # go back to master $ git checkout master $ git reset --hard origin/master (to restore) # work on the fix $ vi code.c fix.. $ git commit -a -c "fix..." # go back and continue on my fix $ git checkout new-feature-branch $ git rebase origin/master $ git reset HEAD^1 .. continue to work

Sept. 12, 2016

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

by Ben Coman

On Mon, Sep 12, 2016 at 6:08 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On 07 Sep 2016, at 5:38 , Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > On Wed, Sep 7, 2016 at 10:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > > On Wed, Sep 7, 2016 at 9:09 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > On 07 Sep 2016, at 14:56, Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > Hi, > > sorry for arriving so late to this, but I was on holidays :) > this is how autoRelease works: > > 1) #autoRelease of an object registers object for finalisation with a > particular executor. Then behaviour is divided: > > 2.1.1) for ExternalAddresses, it just registers in regular way, who will > call #finalize on GC > 2.1.2) finalize will just call a free assuming ExternalAddress was > allocated > (which is a malloc) > > 2.2.1) for all FFIExternalReference, it will register for finalisation what > #resourceData answers (normally, the handle of the object) > 2.2.2) finalisation process will call the object > class>>#finalizeResourceData: method, with the #resourceData result as > parameter > 2.2.3) each kind of external reference can decide how to free that data (by > default is also just freeing). > > An example of this is how CairoFontFace works (or AthensCairoSurface). > > > > At the bottom of FFIExternalResourceExecutor class comment I read... > "Note that in #finalizeResourceData: you cannot > access any other properties of your instance, > since it is already garbage collected." > > But in my experiments it seems okay to access instance variables in > #finalize. > For example... > > CXString >> autoRelease > self class finalizationRegistry add: self > > CXString >> finalize > Transcript crShow: 'Finalizing CXString ' ; show: self private_flags. > self dispose. > Transcript show: ', done!'. > > CXString >>private_flags > "This method was automatically generated" > ^handle unsignedLongAt: 5 > > Libclang getClangVersion autoRelease. > Smalltalk garbageCollect. > "==> Finalizing CXString 1, done! " > > > Is this an unlucky coincidence? Or maybe something changed from NB > to UFFI? (There is a reference to NB there) > > > yes, is a coincidence. > the idea of using #finalizeResourceData: is that you keep minimal > information (in general, just the handle)â¦ this way we ensure instances > will > be collected because we will not have circular references (preventing the > weakregistry to work). > > In general, you can always implement as you did it, but I would prefer the > #finalizeResourceData: approach, even for structures. > The only reason it is not implemented is because I didnât reach the > necessity, then I just skipped it (not in purpose, it was not in my head > :P), but now is a good moment to implement itâ¦ if you want it :) > > > Thanks for the offer, but hold off for the moment. I think I actually > need more than just finalization session management. To get a real > displayable string requires calling the clang_getCString() library > function. I imagine I'd like to call this from CXString>>printOn: -- > but this of course this would break after restarting the image. > > extern "C" { > const char *clang_getCString(CXString string) { > .... > return static_cast<const char *>(string.data); > }} > > typedef struct { > const void *data; > unsigned private_flags; > } CXString; > > So I think I need to register CXString with SessionManager to set *data > <-- 0 > on startup. > > An alternative might be adding a session variable to CXString, > FFIExternalStructure subclass: #CXString > instanceVariableNames: 'session' > classVariableNames: '' > poolDictionaries: 'CXStringFlag' > package: 'Libclang' > > except doing so crashes when calling.... > getClangVersion > ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang > > > So this worked... > > CXString >> resetData > handle unsignedLongAt: 1 put: 0. > > CXString class >> startUp: resuming > resuming > ifTrue: [ self allInstances do: [ :cxs | cxs resetData ] ]. > > CXString class >> initialize > "self initialize" > SessionManager default registerSystemClassNamed: self name > > > Now immediate after a save/restart, doing... > CXString allInstances first getString "==> UndefinedObject(nil)" > instead of crashing the VM. > > Can you see/guess any traps hidden from me? Now I wonder early it is > practical to prioritise such a reset. My first thought is at least > before #printString starts getting called ?? > > > For traps, there's the assumption in resetData that pointer stored in > handle is unsignedLong-sized. > Shouldn't there be auto-generated accessors for #data you can use instead > to change the value to Pointer void? > > Cheers, > Henry > Good point. This is the auto-generated accessor... data: anObject handle pointerAt: 1 put: anObject getHandle. However getHandle is only understood by ExternalObject and FFIExternalArray, and it seems a bit awkward to create a null on of those just to zero the handle. Actually your comment lead me to dicover ExternalAddress>>beNull, which looked promising. However the /handle/ of a FFIExternalStructure is a ByteArray rather than an ExternalAddress (which I guess makes sense). So... 1. maybe push beNull up to ByteArray, and maybe also isNull 2. #beNull implementation is 'self atAllPut: 0' which is understood by ByteArray. In my case I don't care if private_flags is also cleared, so maybe... CXString >> beNull handle atAllPut: 0. cheers -ben

Sept. 12, 2016

Re: [Pharo-users] Cryptography packages

by phil＠highoctane.be

FYI there is a binding to NaCl in ApplicationSecurity. http://80738163270632.blogspot.be/2014/03/application-security-presentation… It is Pharo 3 (maybe is ok for other versions but I use it on Pharo 3). https://nacl.cr.yp.to/index.html Best, Phil On Mon, Sep 12, 2016 at 2:42 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2016-09-11 14:26 GMT-03:00 Paul DeBruicker <pdebruic(a)gmail.com>: > > > > Years ago when Squeaksource was "going away" I made a copy of its > > Cryptography repo here: > > http://smalltalkhub.com/#!/~Cryptography/Cryptography > > I saw it before posting to the list, but the latest commit is from > three years go. > > I'm reading a book about Bitcoin/Blockchains and I want to follow the > examples using my favorite language instead of Python. > Probably not all the algorithms will be there, particularly ECC, but > at least the ones for hashing should. > > Regards! > > > Esteban A. Maringolo > > >

Sept. 12, 2016

Re: [Pharo-users] Cryptography packages

by Esteban A. Maringolo

2016-09-11 14:26 GMT-03:00 Paul DeBruicker <pdebruic(a)gmail.com>: > > Years ago when Squeaksource was "going away" I made a copy of its > Cryptography repo here: > http://smalltalkhub.com/#!/~Cryptography/Cryptography I saw it before posting to the list, but the latest commit is from three years go. I'm reading a book about Bitcoin/Blockchains and I want to follow the examples using my favorite language instead of Python. Probably not all the algorithms will be there, particularly ECC, but at least the ones for hashing should. Regards! Esteban A. Maringolo

Sept. 12, 2016

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

by Henrik Johansen

> On 07 Sep 2016, at 5:38 , Ben Coman <btc(a)openInWorld.com> wrote: > > On Wed, Sep 7, 2016 at 10:42 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> On Wed, Sep 7, 2016 at 9:09 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> On 07 Sep 2016, at 14:56, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>> Hi, >>> >>> sorry for arriving so late to this, but I was on holidays :) >>> this is how autoRelease works: >>> >>> 1) #autoRelease of an object registers object for finalisation with a >>> particular executor. Then behaviour is divided: >>> >>> 2.1.1) for ExternalAddresses, it just registers in regular way, who will >>> call #finalize on GC >>> 2.1.2) finalize will just call a free assuming ExternalAddress was allocated >>> (which is a malloc) >>> >>> 2.2.1) for all FFIExternalReference, it will register for finalisation what >>> #resourceData answers (normally, the handle of the object) >>> 2.2.2) finalisation process will call the object >>> class>>#finalizeResourceData: method, with the #resourceData result as >>> parameter >>> 2.2.3) each kind of external reference can decide how to free that data (by >>> default is also just freeing). >>> >>> An example of this is how CairoFontFace works (or AthensCairoSurface). >>> >>> >>> >>> At the bottom of FFIExternalResourceExecutor class comment I read... >>> "Note that in #finalizeResourceData: you cannot >>> access any other properties of your instance, >>> since it is already garbage collected." >>> >>> But in my experiments it seems okay to access instance variables in >>> #finalize. >>> For example... >>> >>> CXString >> autoRelease >>> self class finalizationRegistry add: self >>> >>> CXString >> finalize >>> Transcript crShow: 'Finalizing CXString ' ; show: self private_flags. >>> self dispose. >>> Transcript show: ', done!'. >>> >>> CXString >>private_flags >>> "This method was automatically generated" >>> ^handle unsignedLongAt: 5 >>> >>> Libclang getClangVersion autoRelease. >>> Smalltalk garbageCollect. >>> "==> Finalizing CXString 1, done! " >>> >>> >>> Is this an unlucky coincidence? Or maybe something changed from NB >>> to UFFI? (There is a reference to NB there) >>> >>> >>> yes, is a coincidence. >>> the idea of using #finalizeResourceData: is that you keep minimal >>> information (in general, just the handle)â¦ this way we ensure instances will >>> be collected because we will not have circular references (preventing the >>> weakregistry to work). >>> >>> In general, you can always implement as you did it, but I would prefer the >>> #finalizeResourceData: approach, even for structures. >>> The only reason it is not implemented is because I didnât reach the >>> necessity, then I just skipped it (not in purpose, it was not in my head >>> :P), but now is a good moment to implement itâ¦ if you want it :) >> >> Thanks for the offer, but hold off for the moment. I think I actually >> need more than just finalization session management. To get a real >> displayable string requires calling the clang_getCString() library >> function. I imagine I'd like to call this from CXString>>printOn: -- >> but this of course this would break after restarting the image. >> >> extern "C" { >> const char *clang_getCString(CXString string) { >> .... >> return static_cast<const char *>(string.data); >> }} >> >> typedef struct { >> const void *data; >> unsigned private_flags; >> } CXString; >> >> So I think I need to register CXString with SessionManager to set *data <-- 0 >> on startup. >> >> An alternative might be adding a session variable to CXString, >> FFIExternalStructure subclass: #CXString >> instanceVariableNames: 'session' >> classVariableNames: '' >> poolDictionaries: 'CXStringFlag' >> package: 'Libclang' >> >> except doing so crashes when calling.... >> getClangVersion >> ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang > > So this worked... > > CXString >> resetData > handle unsignedLongAt: 1 put: 0. > > CXString class >> startUp: resuming > resuming > ifTrue: [ self allInstances do: [ :cxs | cxs resetData ] ]. > > CXString class >> initialize > "self initialize" > SessionManager default registerSystemClassNamed: self name > > > Now immediate after a save/restart, doing... > CXString allInstances first getString "==> UndefinedObject(nil)" > instead of crashing the VM. > > Can you see/guess any traps hidden from me? Now I wonder early it is > practical to prioritise such a reset. My first thought is at least > before #printString starts getting called ?? For traps, there's the assumption in resetData that pointer stored in handle is unsignedLong-sized. Shouldn't there be auto-generated accessors for #data you can use instead to change the value to Pointer void? Cheers, Henry

Sept. 12, 2016

Re: [Pharo-users] Problem cleaning up image

by stepharo

Ok may be this is just an endless loop :) Le 12/9/16 Ã 10:22, Marcus Denker a Ã©crit : > Hello, > > Yes, this is a bug that we really need to fix. > (sadly no information to add other thant that). > >> On 09 Sep 2016, at 15:16, Vitor Medina Cruz <vitormcruz(a)gmail.com >> <mailto:vitormcruz@gmail.com>> wrote: >> >> Hello, >> >> Isn't cleanup the headless image working right now? I know it has >> some problems, but I tried to: >> >> curl get.pharo.org <http://get.pharo.org/> | bash >> ./pharo Pharo.image clean --production >> >> It runs for hours and don't complete. Last time I leave it for about >> 5 hours before I cancelled. >> >> Regards, >> Vitor >

Sept. 12, 2016

Re: [Pharo-users] Problem cleaning up image

by Marcus Denker

Hello, Yes, this is a bug that we really need to fix. (sadly no information to add other thant that). > On 09 Sep 2016, at 15:16, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > Hello, > > Isn't cleanup the headless image working right now? I know it has some problems, but I tried to: > > curl get.pharo.org <http://get.pharo.org/> | bash > ./pharo Pharo.image clean --production > > It runs for hours and don't complete. Last time I leave it for about 5 hours before I cancelled. > > Regards, > Vitor

Sept. 12, 2016

Re: [Pharo-users] limits on number of instance variables and class variables

by ClÃ©ment Bera

Hello Ben, The limit you see for instance variables is due to: - Class format encoding (Memory manager dependent) - Bytecode set encoding (Bytecode set dependent) The 255 inst var limit is enforced both by: - the V3 Memory manager - the SqueakV3PlusClosures bytecode set. Now we have Spur instead of V3 as a memory manager, which allows up to 65535 instance variables. The SistaV1 bytecodeset should reach production in Pharo 6 alpha any time soon, and combined with the Spur memory manager, it enforces a limit of 65535 instance variables instead of 255. Class variables are indeed a dictionary so there's no hard limit. On Mon, Sep 12, 2016 at 4:51 AM, Ben Coman <btc(a)openinworld.com> wrote: > Minor curiosity... I was wondering about the limits on the number of > instance variables and class variables (particularly the latter regarding > large FFI enumerations), so I produced a script to experiment with. > > Results: > * Class Variables seem to have no practical limit. Although running 6C > experiment a second time locks the image for about 3 minutes, but > eventually completes. > * Instance Variables limit is 255 or 256. This not clear since 256 works, > but the error message** for 257 says the limit is 255. > ** Error: genStorePopInstVarLong: index index 256 is out of range 0 > to 255 > > cheers -ben > > Here is the fun script... > "================================================" > "The experiment has two parameters (select by changing the #at: index): > _RANGE - Range of variables assigned. Note variables are declared > starting from 0001. > _TYPE - (i)instance variable or (C)lass variable" > > _RANGE := { > 1->9. "1. code validation" > 201->256. "2. instance variables limit" > 201->257. "3. instance variables Error: genStorePopInstVarLong: index > index 256 is out of range 0 to 255" > 201->299. "4. class variables keep going" > 901->999. "5. class variables go extreme" > 9901->9999. "6. class variables go ultra extreme" > } at: 1. > _TYPE := { > 'i'. "1. instance variables" > 'C' "2. class variables" > } at: 1. > > "Choose experiment parameters above" > > start := _RANGE key. > end := _RANGE value. > > "DECLARE VARIABLES" > vars := ''. > 1 to: end do: [:n| vars := vars, _TYPE, (n printPaddedWith: $0 to: 4), ' > ' ]. > vars. > Object subclass: #Test > instanceVariableNames: ((_TYPE = 'i') ifTrue: [vars] ifFalse: [ '' ]) > classVariableNames: ((_TYPE = 'C') ifTrue: [vars] ifFalse: [ '' ]) > poolDictionaries: '' > package: 'aaaa'. > > "First run needs to execute above separately to create the class referred > below" > > "ASSIGN VARIABLES" > body := ' > '. > start to: end do: [ :n| body := body , _TYPE, (n printPaddedWith: $0 to: > 4), ':=' , n printString , '. > ' ]. > body. > #Test asClass compile: 'assign ' , body. > > "INSPECT VARIABLES" > body := ' > ^{'. > start to: end do: [ :n| body := body , _TYPE, (n printPaddedWith: $0 to: > 4) , '. ' ]. > body. > Test compile: 'inspect ' , body , '} inspect'. > > Test new assign ; inspect. > >

Sept. 12, 2016

limits on number of instance variables and class variables

by Ben Coman

Minor curiosity... I was wondering about the limits on the number of instance variables and class variables (particularly the latter regarding large FFI enumerations), so I produced a script to experiment with. Results: * Class Variables seem to have no practical limit. Although running 6C experiment a second time locks the image for about 3 minutes, but eventually completes. * Instance Variables limit is 255 or 256. This not clear since 256 works, but the error message** for 257 says the limit is 255. ** Error: genStorePopInstVarLong: index index 256 is out of range 0 to 255 cheers -ben Here is the fun script... "================================================" "The experiment has two parameters (select by changing the #at: index): _RANGE - Range of variables assigned. Note variables are declared starting from 0001. _TYPE - (i)instance variable or (C)lass variable" _RANGE := { 1->9. "1. code validation" 201->256. "2. instance variables limit" 201->257. "3. instance variables Error: genStorePopInstVarLong: index index 256 is out of range 0 to 255" 201->299. "4. class variables keep going" 901->999. "5. class variables go extreme" 9901->9999. "6. class variables go ultra extreme" } at: 1. _TYPE := { 'i'. "1. instance variables" 'C' "2. class variables" } at: 1. "Choose experiment parameters above" start := _RANGE key. end := _RANGE value. "DECLARE VARIABLES" vars := ''. 1 to: end do: [:n| vars := vars, _TYPE, (n printPaddedWith: $0 to: 4), ' ' ]. vars. Object subclass: #Test instanceVariableNames: ((_TYPE = 'i') ifTrue: [vars] ifFalse: [ '' ]) classVariableNames: ((_TYPE = 'C') ifTrue: [vars] ifFalse: [ '' ]) poolDictionaries: '' package: 'aaaa'. "First run needs to execute above separately to create the class referred below" "ASSIGN VARIABLES" body := ' '. start to: end do: [ :n| body := body , _TYPE, (n printPaddedWith: $0 to: 4), ':=' , n printString , '. ' ]. body. #Test asClass compile: 'assign ' , body. "INSPECT VARIABLES" body := ' ^{'. start to: end do: [ :n| body := body , _TYPE, (n printPaddedWith: $0 to: 4) , '. ' ]. body. Test compile: 'inspect ' , body , '} inspect'. Test new assign ; inspect.

Sept. 12, 2016