March 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Polymorph

by Gary Chambers

Just a heads up. I'll be making some time next week for reintegrating various fixes and improvements to mostly Polymorph related things. Whilst based on 1.4, it has been some time since I've updated my happily stable image and the changes have accumulated to be fairly extensive, all driven by business needs of course ;-) (no reason that nice stuff can be done in that remit!). The changes will hopefully not break anyone's parallel efforts, likely, though is going to be painful to resynchronise as the community has been doing plentiful excellent work in improvement. I humbly ask that fixes/changes to Morphic/Polymorph could be put on hold in terms of submissions whilst I integrate as a stable baseline will be necessary. I'll post again on the list next week as to when I start on the reintegration so I can hopefully get a clear few days of stability, along with letting you all know preliminary details of the effects of changes (won't know full repurcussions until analysed). In addition to fixes etc. I can make available a couple of UI themes suitable for touchscreen devices (Android Gingerbread style basically, in HDPI and MDPI) and a few other goodies. Hopefully all for the better as discovered through using things to produce business applications. Videos to come based on the products we are developing with Pharo. Regards, Gary Sent from my iPad

March 3, 2012

Re: [Pharo-project] pharo-seed and pharo

by Igor Stasenko

On 3 March 2012 01:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 2, 2012, at 11:11 PM, Marcus Denker wrote: > >> >> On Mar 2, 2012, at 9:21 PM, Tudor Girba wrote: >>> >>> Ok. So I downloaded the first Pharo Core 1.4: >>> https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip >>> >>> but, I still do not know what packages to load. Is there an easy way to figure these ones out (and in particular the loading order)? > > > The update is done by ScriptLoaders #update* methods. > > e.g. one of the first ones: > > update14002 > Â Â Â Â "self new update14002" > Â Â Â Â self withUpdateLog: '- remove ToolBuilder'. > Â Â Â Â self loadTogether: self script267 merge: false. > Â Â Â Â (MCPackage named: 'ToolBuilder-Morphic') unload. > Â Â Â Â (MCPackage named: 'ToolBuilder-Kernel') unload. > Â Â Â Â self flushCaches. > > > #script267 defines which MC packages are to be loaded for 14002. The list of packages slowly changes... > (e.g. in 14003 there will be no ToolsBuilder anymore, as we removed it here). > > The #loadTogether:merge: shows that there is actually no load order... the changes are loaded together as > if it would be one package. So we just have the load-order of MC to worry about, which can be wrong... > In that case, one has split the update in two: first add the classes/methods, then change the calling code. > If everything fails, we do have changesets where we can hard-reorder stuff. > > Besides that, there is the proble of object migration. E.g. we removed things from the startuplist, the specialObjectArray... > e.g. in MorphicUIManager there is class var with the UI process. This used to be in Project, which is not there anymore... > > I think what one could do is to combine updates of the simple kind. E.g. if we would have atomic loading, load order > problems would disapear. Then one could batch all updates together where there is no reflective change done in a postscript > (which happens, but not that often). > well, atomic loading helps, except from cases when you deal with external resources or VM contracts. fortunately there are not so many of them. > Another thing that one would need to do is to destinguish between "hot" code that is run when updating and the other. > One could structure the system in a way that the "active" code when updating is well known and controlled, and the non-active > one could be done in a way that state manipulations are part of a general inialization scheme and expicit... > > There are lots of things to think about for the problem of updating a running system... difficult problem. Nice research area. > Indeed. And largely unknown, since most people living in edit-compile-run world :) > Â Â Â Â Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > -- Best regards, Igor Stasenko.

March 2, 2012

Re: [Pharo-project] pharo-seed and pharo

by Marcus Denker

On Mar 2, 2012, at 11:11 PM, Marcus Denker wrote: > > On Mar 2, 2012, at 9:21 PM, Tudor Girba wrote: >> >> Ok. So I downloaded the first Pharo Core 1.4: >> https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip >> >> but, I still do not know what packages to load. Is there an easy way to figure these ones out (and in particular the loading order)? The update is done by ScriptLoaders #update* methods. e.g. one of the first ones: update14002 "self new update14002" self withUpdateLog: '- remove ToolBuilder'. self loadTogether: self script267 merge: false. (MCPackage named: 'ToolBuilder-Morphic') unload. (MCPackage named: 'ToolBuilder-Kernel') unload. self flushCaches. #script267 defines which MC packages are to be loaded for 14002. The list of packages slowly changes... (e.g. in 14003 there will be no ToolsBuilder anymore, as we removed it here). The #loadTogether:merge: shows that there is actually no load order... the changes are loaded together as if it would be one package. So we just have the load-order of MC to worry about, which can be wrong... In that case, one has split the update in two: first add the classes/methods, then change the calling code. If everything fails, we do have changesets where we can hard-reorder stuff. Besides that, there is the proble of object migration. E.g. we removed things from the startuplist, the specialObjectArray... e.g. in MorphicUIManager there is class var with the UI process. This used to be in Project, which is not there anymore... I think what one could do is to combine updates of the simple kind. E.g. if we would have atomic loading, load order problems would disapear. Then one could batch all updates together where there is no reflective change done in a postscript (which happens, but not that often). Another thing that one would need to do is to destinguish between "hot" code that is run when updating and the other. One could structure the system in a way that the "active" code when updating is well known and controlled, and the non-active one could be done in a way that state manipulations are part of a general inialization scheme and expicit... There are lots of things to think about for the problem of updating a running system... difficult problem. Nice research area. Marcus -- Marcus Denker -- http://marcusdenker.de

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Frank Shearar

On 2 March 2012 22:18, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Frank, > > Â I see no problem with saying "Monticello package Foo-fbs.2 means > Â that you have this class with this definition and that method with > Â that definition". > > Okay I don't have a problem with that sentence. > > Â That's pretty much the same thing as saying "git commit > Â id deadbeef means that you have this file with these contents and that > Â file with those contents". > > If you are implying that a single package version can be versioned in git with same semantics as Monticello, then I will agree. > > Again, where git and Monticello differ is that one can version multiple packages with git (same version/same commit) and one cannot with Monticello (different files for each package and no shared commit history)... Yes. No argument here! Especially when one wants to have a project split up into sub-packages - test, core, extension packages - and you have to do a bit of extra work. frank > Dale > > ----- Original Message ----- > | From: "Frank Shearar" <frank.shearar(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, March 2, 2012 9:46:39 AM > | Subject: Re: [Pharo-project] Monticello Version Info > | > | On 2 March 2012 17:32, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > Frank, > | > > | > That's right ... the major difference between the two is that git > | > manages multiple files ... > | > | Well, kind've. A blob usually does contain the contents of a file. > | (http://book.git-scm.com/1_the_git_object_model.html) That is, when > | you checkout some branch you end up with a directory structure > | containing files, which is what you're talking about. It's probably > | better not to think of them as files: the blobs might look like files > | in your working copy, but they're just, well, blobs. Chunks of binary > | stuff that, for versioning software, happens to be UTF-8 encoded > | plain > | text (or whatever). > | > | (This is exactly why, from standing inside an image, mapping a method > | to a file makes sense: a method's a single unit of stuff.) > | > | Which is probably why you express yourself this way: Monticello turns > | a whole bunch of methods + comments + class definitions into a big > | snapshot.st - a single file in the zip - and a corresponding list of > | changes to an image - "add this, remove that". > | > | Both are still versioning a collection of things together, though: I > | see no problem with saying "Monticello package Foo-fbs.2 means that > | you have this class with this definition and that method with that > | definition". That's pretty much the same thing as saying "git commit > | id deadbeef means that you have this file with these contents and > | that > | file with those contents". > | > | frank > | > | > Dale > | > > | > ----- Original Message ----- > | > | From: "Frank Shearar" <frank.shearar(a)gmail.com> > | > | To: Pharo-project(a)lists.gforge.inria.fr > | > | Sent: Friday, March 2, 2012 9:27:39 AM > | > | Subject: Re: [Pharo-project] Monticello Version Info > | > | > | > | On 2 March 2012 17:02, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > | > Sven, > | > | > > | > | > A Monticello mcz file is a version data base for a single > | > | > package > | > | > .... Git is a version data base for a directory structure ... > | > | > > | > | > Monticello has branching by convention (change the name of a > | > | > file > | > | > to create the branch), although the mcz ancestry handles > | > | > branches > | > | > just fine. In Git branches are first class objects ... it is > | > | > difficult to do things in git if you are not on one branch or > | > | > another ... > | > | > | > | Bearing in mind that a branch is just a pointer to a commit: look > | > | in > | > | your blah/.git/refs/heads/ and each file is a branch containing > | > | the > | > | SHA1 id of the head of that branch. (And each commit knows its > | > | ancestor/s, just like an mcz file, except that the hash means the > | > | relationship's based on the commit's _contents_, not its _name_.) > | > | > | > | frank > | > | > | > | > You can merge with Monticello and you can merge with Git ... > | > | > > | > | > The big difference is that Git allows you to version a bunch of > | > | > files together and with Monticello you are versioning a single > | > | > file. > | > | > > | > | > Part of what Metacello was invented to do was to create a "data > | > | > base" of versioned collections of mcz files ... Git was > | > | > designed > | > | > to manage collections of files... > | > | > > | > | > Is this what you were asking? > | > | > > | > | > Dale > | > | > > | > | > ----- Original Message ----- > | > | > | From: "Sven Van Caekenberghe" <sven(a)beta9.be> > | > | > | To: Pharo-project(a)lists.gforge.inria.fr > | > | > | Sent: Friday, March 2, 2012 12:31:42 AM > | > | > | Subject: Re: [Pharo-project] Monticello Version Info > | > | > | > | > | > | > | > | > | On 02 Mar 2012, at 01:52, Chris Cunningham wrote: > | > | > | > | > | > | > The issue is that Monticello is setup for distributed > | > | > | > processing, > | > | > | > and > | > | > | > allowing for multiple repositories, some of which may not > | > | > | > be > | > | > | > available > | > | > | > to all of the users for a project. Â For instance, a project > | > | > | > might > | > | > | > be > | > | > | > developed internally (or on the developers hard-drive) > | > | > | > until > | > | > | > they > | > | > | > feel > | > | > | > comfortable distributing the code later. Â So, publicly, you > | > | > | > get > | > | > | > version 12, 17, 34, and 37. Â There is no access to the > | > | > | > intermediate > | > | > | > ones (unless you happen to be the one that created them and > | > | > | > didn't > | > | > | > release them). Â The 'whole ancestry' let's you do diffs off > | > | > | > of > | > | > | > a > | > | > | > version derived from 37 against one derived from 34 - the > | > | > | > ancestry > | > | > | > can > | > | > | > determine that version 34 if 'common', and work from there. > | > | > | > Â [Note > | > | > | > that just numbers aren't enough - the original developer, > | > | > | > say, > | > | > | > cbc > | > | > | > could have version cbc.34, while you could have, say, > | > | > | > CamilloBruni.34, > | > | > | > but yours is based off of 17 (since you picked up that > | > | > | > verison > | > | > | > and > | > | > | > started working there). Â So, merging cbc.37 with > | > | > | > CamilloBruni.34 > | > | > | > would > | > | > | > need to pull down cbc.17 for a good merge to work.] > | > | > | > > | > | > | > At least, that's my understanding from long ago > | > | > | > discussions. > | > | > | > | > | > | This makes sense, but how is this handled with git ? > | > | > | > | > | > | Sven > | > | > > | > | > | > | > | > > | > | >

March 2, 2012

Re: [Pharo-project] Alien signature: first attempt

by Eliot Miranda

On Thu, Mar 1, 2012 at 7:01 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Eliot, > > Thanks for the help. I'm not as convinced as you that I have it<g>, but > I'm getting there. > Alien subclasses per struct - interesting! > There are some Win32 examples in the Alien-Win32 package, LOGFONTA, ENUMLOGFONTEXA and OPENFILENAME. But my favourite is the BochsIA32Alien the the Cog VMMaker. It is an interface to Bochs' x86 processor simulator, written in C++, upon which the Cog JIT simulates its machine code when developing the Cog JIT in Smalltalk. It has methods such as eax ^self unsignedLongAt: 469 eax: anUnsignedInteger ^self unsignedLongAt: 469 put: anUnsignedInteger and the accessing methods get generated via C code [ :) ]: #define stoffsetof(type,field) (offsetof(type,field)+1) #define print(r,n) \ printf("!BochsIA32Alien methodsFor: 'accessing' stamp: 'eem %d/%d/%d %d:%02d'!\r"\ "%s\r\t^self unsignedLongAt: %ld! !\r", m,d,y,h,i, lower(#r), \ stoffsetof(BX_CPU_C,gen_reg[n].dword.erx));\ printf("!BochsIA32Alien methodsFor: 'accessing' stamp: 'eem %d/%d/%d %d:%02d'!\r"\ "%s: anUnsignedInteger\r\t^self unsignedLongAt: %ld put: anUnsignedInteger! !\r", m,d,y,h,i, lower(#r), \ stoffsetof(BX_CPU_C,gen_reg[n].dword.erx)) print(EAX,BX_32BIT_REG_EAX); print(EBX,BX_32BIT_REG_EBX); print(ECX,BX_32BIT_REG_ECX); print(EDX,BX_32BIT_REG_EDX); print(ESP,BX_32BIT_REG_ESP); print(EBP,BX_32BIT_REG_EBP); print(ESI,BX_32BIT_REG_ESI); print(EDI,BX_32BIT_REG_EDI); print(EIP,BX_32BIT_REG_EIP); see http://www.squeakvm.org/svn/squeak/branches/Cog/processors/IA32/bochs/explo… > > Bill > > > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [ > eliot.miranda(a)gmail.com] > *Sent:* Thursday, March 01, 2012 9:56 PM > > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Alien signature: first attempt > > > > On Thu, Mar 1, 2012 at 6:45 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> Eliot, >> >> I've unearthed some code from Dolphin, and might want to use something >> like this: >> >> vectorStarVoidStarMatrixStarRetInt: callbackContext sp: spAlien >> <signature: 'int (*) (Gsl_vector *, void *, Gsl_matrix *)' abi: >> 'IA32'> >> ^callbackContext wordResult:( >> block >> value: (Alien forPointer:( spAlien unsignedLongAt: 1)) >> value: (Alien forPointer: (spAlien unsignedLongAt: 5)) >> value: (Alien forPointer:( spAlien unsignedLongAt: 9)) >> ). >> >> Am I at all on the right track? The vector and matrix are structs. >> > > Yes, exactly. The next level is to create Alien subclasses for > Gsl_vector and Gsl_matrix and use these in place of the simple Aliens. > These e.g. GslMatrixIA32Alien and GslVectorIA32Alien classes would define > higher-level accessors so that your callback can access their members by > name, not by offset. Of course these classes should be auto-generated by > parsing e.g. a C header file using the rules of the platform's ABI. > > You've got it. > > > >> Bill >> >> >> >> >> ------------------------------ >> *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [ >> eliot.miranda(a)gmail.com] >> *Sent:* Thursday, March 01, 2012 5:38 PM >> >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Subject:* Re: [Pharo-project] Alien signature: first attempt >> >> >> >> On Thu, Mar 1, 2012 at 1:52 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: >> >>> Eliot, >>> >>> That helps a bit; it's still unfamiliar territory. I am a little >>> bothered by #wordResult: and #floatResult. There are times when one is >>> expected to return 16 bit values (rare) and either a float or a double >>> (common). Does that flexibility exist? >>> >> >> Yes, the flexibility exists. But the mechanism needed to provide the >> flexibility is less than one might expect. For example, on x86 there are >> three fundamental return conventions, one for integral values, one for >> floating-point values, and one for structure values. See e.g. chapter 3 of >> the Sys V ABI for 386 (in my reply to Nicolas). Read it; it's good for the >> soul; makes one value Smalltalk's simplicity. >> >> Integral values are returned in %eax, %edx. edx is not used if the >> value fits in 32-bits. So the same sequence can be used to answer all >> integral values from 1 byte to 8 bytes, irrespective of sign. That said, I >> use two sequences, one for 32-bits or less and one for 33 to 64 bits. In >> your example of answering 16 bits one simply answers either the >> sign-extension of 16-bits (if signed) to 32-bits or the zero-extension of >> 16-bits to 32-bits (if unsigned). In any case, the result is answered in >> %eax, and it is up to the caller to access the result correctly. >> >> Float values are returned on the top of the floating point register >> stack (%st(0)). The same machine-code sequence can be used to answer >> single, double and extended precision floats, since on the fp stack, they >> are all represented in the same extended format. >> >> So on x86 the callback implementation supports 4 return mechanisms, >> retword, retword64, retdouble and retstruct. So far only two of these are >> fleshed out in Smalltalk code. But look at >> http://www.squeakvm.org/svn/squeak/branches/Cog/src/vm/vmCallback.h & >> http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/IA32ABI/ia32ab… you'll see the other two. >> >> cheers, >> Eliot >> >> >>> >>> Bill >>> >>> >>> >>> >>> ------------------------------ >>> *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ >>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda >>> [eliot.miranda(a)gmail.com] >>> *Sent:* Thursday, March 01, 2012 3:26 PM >>> *To:* Pharo-project(a)lists.gforge.inria.fr >>> *Subject:* Re: [Pharo-project] Alien signature: first attempt >>> >>> >>> >>> On Thu, Mar 1, 2012 at 10:57 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu >>> > wrote: >>> >>>> Esteban, >>>> >>>> Will this work? Even if so, is there a better way to define it? >>>> >>> >>> No it won't work, because you don't understand what it does. >>> >>> >>>> >>>> longVoidStarLongRetInt: callbackContext sp: spAlien >>>> <signature: 'int (*) (long, void *, long)' abi: 'IA32'> >>>> ^callbackContext wordResult: >>>> (block >>>> value: (Alien newC:4) >>>> value: (Alien forPointer: (spAlien >>>> unsignedLongAt: 5)) >>>> value: (Alien newC:4) >>>> ) >>>> >>> >>> The above takes only one parameter's value from the spAlien (the void >>> * value) and passes garbage for the other parameters. The spAlien is a >>> pointer to the incoming C callback stack frame, i.e. a pointer to the >>> callback's parameters. So spAlien unsignedLongAt: 5 gets the four-byte >>> pointer for the void * parameter, wraps it up in a convenient pointer Alien >>> (so the callback block can e.g. indirect through it to get at the data the >>> pointer is pointing to), and passes it as the second argument of the >>> callback block. But the two Alien newC: 4's are entirely bogus, passing >>> effectively uninitialized data for the first and third parameters of the >>> callback block. They're just empty Aliens, when in fact you want to pass >>> two longs to the block for the first and third parameters. >>> >>> So to pass values in you need something like: >>> >>> longVoidStarLongRetInt: callbackContext sp: spAlien >>> <signature: 'int (*) (long, void *, long)' abi: 'IA32'> >>> ^callbackContext wordResult: >>> (block >>> value: (spAlien signedLongAt: 1) >>> value: (Alien forPointer: (spAlien >>> unsignedLongAt: 5)) >>> value: (spAlien signedLongAt: 9) >>> ) >>> >>> You might also need to consider passing the result of the block back >>> out. If you only want to use it to answer integers then the above is fine. >>> But take a look at the intcharstarRetint:sp: signature: >>> >>> intcharstarRetint: callbackContext sp: spAlien >>> <signature: 'int (*)(int, char *)' abi: 'IA32'> >>> ^callbackContext wordResult: >>> ((block >>> value: (spAlien signedLongAt: 1) ~= 0 >>> value: (Alien forPointer: (spAlien unsignedLongAt: 5)) strcpyUTF8) >>> ifNil: [0] >>> ifNotNil: >>> [:result| >>> result isInteger >>> ifTrue: [result] >>> ifFalse: [result == true ifTrue: [1] ifFalse: [0]]]) >>> >>> Analogously it passes a signed integer as the first argument and a >>> UTF8 string derived from the second char * parameter. (The method should >>> probably be called intcharstarasUTF8Retint:sp: or some such; forgive me, >>> we're getting there). >>> >>> But on return it takes the result of the callback block and passes it >>> to the ifNil:ifNotNil: which >>> - maps a nil result form the block to 0 (ifNil: [0]) >>> - maps integers to integers (which will only deal correctly with >>> integers in the 32-bit range), and >>> - maps true to 1, mapping all other results to 0. >>> >>> Does what's going on now make more sense? >>> >>> HTH, >>> Eliot >>> >>> >>>> Bill >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of >>>> Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] >>>> Sent: Thursday, March 01, 2012 12:15 AM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>> >>>> thanks!!!!! >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >>>> Lorenzano [estebanlm(a)gmail.com] >>>> Sent: Wednesday, February 29, 2012 10:18 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>> >>>> you need to define a signature... not at home now, but wait 'til >>>> tomorrow and I'll send an example >>>> >>>> best, >>>> Esteban >>>> >>>> El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribiÃ³: >>>> >>>> > What does "cannot find callback signature" mean from >>>> #signature:block:? I'm stuck. >>>> > >>>> > >>>> > >>>> > >>>> > ________________________________________ >>>> > From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >>>> Lorenzano [estebanlm(a)gmail.com] >>>> > Sent: Wednesday, February 29, 2012 6:54 PM >>>> > To: Pharo-project(a)lists.gforge.inria.fr >>>> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>> > >>>> > yeah... sorry about that >>>> > is a bug on FFI... I managed to worked around it for HPDF, for a >>>> customer's project... but of course is not a good and definitive solution. >>>> > >>>> > best, >>>> > Esteban >>>> > >>>> > El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribiÃ³: >>>> > >>>> >> This is gonna take a while... I had structs flying around as void* >>>> and was moderately happy. Nonetheless, your suggestion worked, provided I >>>> add a lot getHandle asInteger and change the void* to long :( >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> ________________________________________ >>>> >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban >>>> Lorenzano [estebanlm(a)gmail.com] >>>> >> Sent: Wednesday, February 29, 2012 6:23 PM >>>> >> To: Pharo-project(a)lists.gforge.inria.fr >>>> >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>> >> >>>> >> I also found some problems using void* in linux... maybe you want to >>>> use long (which has same size)... I "fixed" my problems that way. >>>> >> >>>> >> yes... maybe we need to look at FFI to see why void* has problems >>>> some times, but well, that can help you atm (sorry for not having a better >>>> answer) >>>> >> >>>> >> Esteban >>>> >> >>>> >> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribiÃ³: >>>> >> >>>> >>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>>> wrote: >>>> >>>> Another glitch: is there any problem passing things as void*? I'm >>>> getting failure to coerce errors that did not arise before. >>>> >>>> >>>> >>> No idea. As you may suspect, i stopped using FFI/Alien once i got >>>> >>> NativeBoost toy to play with. >>>> >>> >>>> >>> Please file the issue, describing the problem. so we can look over >>>> it >>>> >>> and fix it. >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor >>>> Stasenko [siguctua(a)gmail.com] >>>> >>>> Sent: Wednesday, February 29, 2012 5:51 PM >>>> >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> >>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>> >>>> >>>> >>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>>> wrote: >>>> >>>>> Does 1.3 by default not create field accessors? Why is that? I >>>> thought >>>> >>>>> nothing was happening. >>>> >>>>> >>>> >>>> >>>> >>>> Good question, i'd like to know the answer too. >>>> >>>> It is related to MC final 'installation' phase, >>>> >>>> where it initializing all classes. >>>> >>>> >>>> >>>> In NativeBoost i was also using >>>> >>>> >>>> >>>> noteCompilationOf: aSelector meta: isMeta >>>> >>>> "A hook allowing some classes to react to recompilation of >>>> certain selectors" >>>> >>>> >>>> >>>> but there was a big question, at which point this hook is >>>> triggered, >>>> >>>> and looks like some changes in MC stop triggering it/triggering at >>>> >>>> wrong time (not all methods get into a class/ class not initialized >>>> >>>> etc), >>>> >>>> which makes it not very useful. >>>> >>>> >>>> >>>> So i ended up creating a DNU handler on instance side, then on DNU >>>> i >>>> >>>> check if i have field accessors and if not, >>>> >>>> compile them on the fly. >>>> >>>> >>>> >>>> >>>> >>>>> Bill >>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> >>>> Igor Stasenko. >>>> >>>> >>>> >>>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Best regards, >>>> >>> Igor Stasenko. >>>> >>> >>>> >> >>>> >> >>>> >> >>>> > >>>> > >>>> > >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >> >> >> -- >> best, >> Eliot >> >> > > > -- > best, > Eliot > > -- best, Eliot

March 2, 2012

Re: [Pharo-project] pharo-seed and pharo

by Marcus Denker

On Mar 2, 2012, at 11:11 PM, Marcus Denker wrote: > > On Mar 2, 2012, at 9:21 PM, Tudor Girba wrote: >> >> Ok. So I downloaded the first Pharo Core 1.4: >> https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip >> >> but, I still do not know what packages to load. Is there an easy way to figure these ones out (and in particular the loading order)? > > > It's not possible to turn 1.4000 into the current one by loading packages in one step. > because there are lots of objects that need to be migrated... it's a living system. > > There was *a lot* of manual fiddling involved, even just from one step to the next. > As a very simple example of a change that will be integrated soon: http://code.google.com/p/pharo/issues/detail?id=5217 An example of a *single* change that is not loadable with monticello. For a slighlty more complex one: http://code.google.com/p/pharo/issues/detail?id=5290 This one will be loaded as a hand-orderd changeset... There are many, many examples... changes to MC, replacing the EventSensor classes (and removing the old ones later...), changes in collections.... Marcus -- Marcus Denker -- http://marcusdenker.de

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Dale Henrichs

Frank, I see no problem with saying "Monticello package Foo-fbs.2 means that you have this class with this definition and that method with that definition". Okay I don't have a problem with that sentence. That's pretty much the same thing as saying "git commit id deadbeef means that you have this file with these contents and that file with those contents". If you are implying that a single package version can be versioned in git with same semantics as Monticello, then I will agree. Again, where git and Monticello differ is that one can version multiple packages with git (same version/same commit) and one cannot with Monticello (different files for each package and no shared commit history)... Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, March 2, 2012 9:46:39 AM | Subject: Re: [Pharo-project] Monticello Version Info | | On 2 March 2012 17:32, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Frank, | > | > That's right ... the major difference between the two is that git | > manages multiple files ... | | Well, kind've. A blob usually does contain the contents of a file. | (http://book.git-scm.com/1_the_git_object_model.html) That is, when | you checkout some branch you end up with a directory structure | containing files, which is what you're talking about. It's probably | better not to think of them as files: the blobs might look like files | in your working copy, but they're just, well, blobs. Chunks of binary | stuff that, for versioning software, happens to be UTF-8 encoded | plain | text (or whatever). | | (This is exactly why, from standing inside an image, mapping a method | to a file makes sense: a method's a single unit of stuff.) | | Which is probably why you express yourself this way: Monticello turns | a whole bunch of methods + comments + class definitions into a big | snapshot.st - a single file in the zip - and a corresponding list of | changes to an image - "add this, remove that". | | Both are still versioning a collection of things together, though: I | see no problem with saying "Monticello package Foo-fbs.2 means that | you have this class with this definition and that method with that | definition". That's pretty much the same thing as saying "git commit | id deadbeef means that you have this file with these contents and | that | file with those contents". | | frank | | > Dale | > | > ----- Original Message ----- | > | From: "Frank Shearar" <frank.shearar(a)gmail.com> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Friday, March 2, 2012 9:27:39 AM | > | Subject: Re: [Pharo-project] Monticello Version Info | > | | > | On 2 March 2012 17:02, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > | > Sven, | > | > | > | > A Monticello mcz file is a version data base for a single | > | > package | > | > .... Git is a version data base for a directory structure ... | > | > | > | > Monticello has branching by convention (change the name of a | > | > file | > | > to create the branch), although the mcz ancestry handles | > | > branches | > | > just fine. In Git branches are first class objects ... it is | > | > difficult to do things in git if you are not on one branch or | > | > another ... | > | | > | Bearing in mind that a branch is just a pointer to a commit: look | > | in | > | your blah/.git/refs/heads/ and each file is a branch containing | > | the | > | SHA1 id of the head of that branch. (And each commit knows its | > | ancestor/s, just like an mcz file, except that the hash means the | > | relationship's based on the commit's _contents_, not its _name_.) | > | | > | frank | > | | > | > You can merge with Monticello and you can merge with Git ... | > | > | > | > The big difference is that Git allows you to version a bunch of | > | > files together and with Monticello you are versioning a single | > | > file. | > | > | > | > Part of what Metacello was invented to do was to create a "data | > | > base" of versioned collections of mcz files ... Git was | > | > designed | > | > to manage collections of files... | > | > | > | > Is this what you were asking? | > | > | > | > Dale | > | > | > | > ----- Original Message ----- | > | > | From: "Sven Van Caekenberghe" <sven(a)beta9.be> | > | > | To: Pharo-project(a)lists.gforge.inria.fr | > | > | Sent: Friday, March 2, 2012 12:31:42 AM | > | > | Subject: Re: [Pharo-project] Monticello Version Info | > | > | | > | > | | > | > | On 02 Mar 2012, at 01:52, Chris Cunningham wrote: | > | > | | > | > | > The issue is that Monticello is setup for distributed | > | > | > processing, | > | > | > and | > | > | > allowing for multiple repositories, some of which may not | > | > | > be | > | > | > available | > | > | > to all of the users for a project. Â For instance, a project | > | > | > might | > | > | > be | > | > | > developed internally (or on the developers hard-drive) | > | > | > until | > | > | > they | > | > | > feel | > | > | > comfortable distributing the code later. Â So, publicly, you | > | > | > get | > | > | > version 12, 17, 34, and 37. Â There is no access to the | > | > | > intermediate | > | > | > ones (unless you happen to be the one that created them and | > | > | > didn't | > | > | > release them). Â The 'whole ancestry' let's you do diffs off | > | > | > of | > | > | > a | > | > | > version derived from 37 against one derived from 34 - the | > | > | > ancestry | > | > | > can | > | > | > determine that version 34 if 'common', and work from there. | > | > | > Â [Note | > | > | > that just numbers aren't enough - the original developer, | > | > | > say, | > | > | > cbc | > | > | > could have version cbc.34, while you could have, say, | > | > | > CamilloBruni.34, | > | > | > but yours is based off of 17 (since you picked up that | > | > | > verison | > | > | > and | > | > | > started working there). Â So, merging cbc.37 with | > | > | > CamilloBruni.34 | > | > | > would | > | > | > need to pull down cbc.17 for a good merge to work.] | > | > | > | > | > | > At least, that's my understanding from long ago | > | > | > discussions. | > | > | | > | > | This makes sense, but how is this handled with git ? | > | > | | > | > | Sven | > | > | > | | > | | > | |

March 2, 2012

Re: [Pharo-project] pharo-seed and pharo

by Marcus Denker

On Mar 2, 2012, at 9:21 PM, Tudor Girba wrote: > > Ok. So I downloaded the first Pharo Core 1.4: > https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip > > but, I still do not know what packages to load. Is there an easy way to figure these ones out (and in particular the loading order)? It's not possible to turn 1.4000 into the current one by loading packages in one step. because there are lots of objects that need to be migrated... it's a living system. There was *a lot* of manual fiddling involved, even just from one step to the next. Marcus -- Marcus Denker -- http://marcusdenker.de

March 2, 2012

Re: [Pharo-project] creating new projects on ss

by Usman Bhatti

On Fri, Mar 2, 2012 at 7:52 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > use gemstone :) no? > > http://ss3.gemstone.com/ Thanx cami. I'm using it and It has a better interface... > > > best > cami > > > On 2012-03-02, at 19:50, Usman Bhatti wrote: > > > I'm not sure if its Friday evening fatigue that is hitting me or a > change in the server policy, squeak server is not allowing me to create new > projects and giving me this message: > > > > On this server, only the administrator can create new projects! > > > > Is there an alternative for creating projects? > > thanx > > usman > > >

March 2, 2012

[Pharo-project] About stable and problem of high expectations. (Was: Re: [Bug Tracker] Issues tagged 1.3)

by Igor Stasenko

First i'd like to make 1 thing clear, stable term used in two, completely different contexts, and it is easy to confuse: 1. stable as not crashing 2. stable as not evolving/developing The release are stable, first of all, in terms of 2. Not in terms of 1. Because there can be problems which were lying hidden etc etc. Of course one should try to get release meet both characteristics. Now about expectations. i wrote a long mail explaining this and that.. but then i decided to remove everything. Personally, I failing many expectations of many people. But it doesn't means that a) i don't want make things better b) i do it intentionally. yes, sometimes i do it intentionally. but then usually i letting those people know why i doing that. Second, what i did learnt using electronic communications is that when you got no response, it doesn't means that you completely ignored. In opposite to real life, when you say something face to face. Third. Put your anger towards fighting with bugs, not people who are you working with. -- Best regards, Igor Stasenko.

March 2, 2012