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

[Pharo-project] Deltas / Change file + log / Undoing

by Goubier Thierry

Hi all, I'd like to ask if I understood correctly this part of the discussion. With a suitable log/change format as Deltas propose and Igor is thinking of implementing, we could undo any changes done on the image (such as method creation, modification, class add/remove, etc...). How does this relates with the undo/redo facility in RefactoringBrowser? And a question which is nagging me regularly when I try to get my head around it: could we unify change sets and packages? I'm just regularly lost when I try to play with the change set tools. Thierry Le 22/10/2012 00:23, GÃ¶ran Krampe a Ã©crit : > Hi! > > On 10/21/2012 11:46 PM, Igor Stasenko wrote: >> To me the one of important part of this story is to have better code >> reuse. >> I like the idea of (re)using regular smalltalk parser to do >> heavylifting, while rest >> is built on top of it. > > (I presume regarding external serialization format, anyway, you might > note that having "full Smalltalk" is a security issue also, and a speed > issue) > >> I like the idea with Deltas that you can rewind them or play them. >> Now the problem is that it will require substantial effort to adopt it >> to Pharo. >> Not long ago, we introduced SystemAnnouncer, and if you look at >> announces (SystemAnnouncement subclasses) you can see that it very >> closely resembling >> delta records. > > I would suspect, yes. But still different since I presume a > SystemAnnouncement does NOT capture enough to enable undo, so they are > still "different beasts". Also, (without having looked) I guess a > SystemAnnouncement is not a "standalone object" like a Change in Deltas > is. I mean, it probably references the class, or a new method etc - and > doesn't actually contain a full copy of all state of the actual change. > >> I dont think that it will be clever to have two classes per each >> system event, i.e. >> ClassRemoved and then ClassRemovedDelta. It would be much nicer to >> have a single one. > > See above. Different responsibilities, right? But I agree with the > "itch", not sure if it can be fully helped though. > >> Another thing is what to do with SystemEditor? My main problem with >> it, that it is gone too far, >> trying to resemble many Class/Behavior protocols. > > Personally I thought it looked "awful" - but I just wanted to be a user > and get "atomicity". IMHO one should be able to get atomicity using > become tricks instead, IIRC Henrik Gedenryd (bless his soul) did > atomicity in his old 3.3modules code using such a trick (building new > classes and then at end - do a "sweep become-replace" operation of all > the modified classes) > >> That means that any change/extension in Class/Behavior will have >> potential risk breaking >> SystemEditor, if we forget to sync changes there as well. >> And the last time we did pass on SystemEditor, if i remember, there >> was still no support for traits. >> >> But sure thing, i should not forget to say about what SystemEditor >> gives: atomic updates. >> My only concern is that price for having such feature is a bit too >> high as to me: >> - big and complex (okay, non-trivial ;) ) logic >> - a maintenance needed if we go and hack Class/Behavior/Traits etc). >> >> for the other features, i don't see significant advantage of using it >> over something else (less complex >> and more compact). > > Final comment on SystemEditor - it is not hardwired into Deltas, in fact > it is kept separate and the idea was to be able to have different > "Applier" classes using different mechanisms. > > regards, GÃ¶ran > > > > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 22, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 431 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Oct. 22, 2012

[Pharo-project] [update 2.0] #20358

by Marcus Denker

20358 ----- Issue 6856: Further Completion Window Improvement http://code.google.com/p/pharo/issues/detail?id=6856 Issue 4958: inheritance does not browse subclasses http://code.google.com/p/pharo/issues/detail?id=4958 Issue 6859: Fix SourceCode refactoring: rename temporary http://code.google.com/p/pharo/issues/detail?id=6859 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.958.diff http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-MarcusDenker.713.diff http://ss3.gemstone.com/ss/Pharo20/NECompletion-MarcusDenker.58.diff -- Marcus Denker -- http://marcusdenker.de

Oct. 22, 2012

Re: [Pharo-project] Mariano's VM-building instructions don't seem to work

by Igor Stasenko

On 22 October 2012 04:24, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi: > > On 19 Oct 2012, at 09:49, Camillo Bruni wrote: > >> Did you check the HOWTOBUILD file in the gitorious repository? > > Is it just me or should the following patch be applied? (the order of the steps seems to be wrong and extracting commit infos should be done in the build folder, no?) > yes > Best regards > Stefan > > diff --git a/HOWTOBUILD b/HOWTOBUILD > index c6554f1..a34ffb9 100644 > --- a/HOWTOBUILD > +++ b/HOWTOBUILD > @@ -65,8 +65,8 @@ Pick or edit the configuration you want, then evaluate it. > # as of 10.7 llvm is the default but incompatible compiler > export CC='/usr/bin/gcc-4.2' > export MACOSX_DEPLOYMENT_TARGET=10.5 > - sh ../codegen-scripts/extract-commit-info.sh > cd build > + sh ../codegen-scripts/extract-commit-info.sh > cmake . > make > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Best regards, Igor Stasenko.

Oct. 22, 2012

Re: [Pharo-project] Mariano's VM-building instructions don't seem to work

by Stefan Marr

Hi: On 19 Oct 2012, at 09:49, Camillo Bruni wrote: > Did you check the HOWTOBUILD file in the gitorious repository? Is it just me or should the following patch be applied? (the order of the steps seems to be wrong and extracting commit infos should be done in the build folder, no?) Best regards Stefan diff --git a/HOWTOBUILD b/HOWTOBUILD index c6554f1..a34ffb9 100644 --- a/HOWTOBUILD +++ b/HOWTOBUILD @@ -65,8 +65,8 @@ Pick or edit the configuration you want, then evaluate it. # as of 10.7 llvm is the default but incompatible compiler export CC='/usr/bin/gcc-4.2' export MACOSX_DEPLOYMENT_TARGET=10.5 - sh ../codegen-scripts/extract-commit-info.sh cd build + sh ../codegen-scripts/extract-commit-info.sh cmake . make -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Oct. 22, 2012

Re: [Pharo-project] NativeBoost FFI

by Igor Stasenko

Also, to generalize the concept i would allow @<index> syntax for all arguments (except from constants of course). (Btw, is everyone ok with '@' syntax?) - first change parser's #parseArgument to pass additional argument to requestor, i.e. send #argName: indirectIndex: type: ptrArity: instead of #argName:type:ptrArity: Like that , you won't need to parse it again in NBFFICallout but just check index for being not-nil. Second, refactor NBSTInObjectArgument to be a wrapper around another loader, i.e: NBFnArgument subclass: #NBSTInObjectArgument instanceVariableNames: 'argumentLoader elementIndex' classVariableNames: '' poolDictionaries: '' category: 'NativeBoost-Core-FFI' NBSTInObjectArgument>>emitLoad: gen | baseAddress | argumentLoader emitLoad: gen to: gen asm EAX. gen proxy fetchPointer: elementIndex - 1 ofObject: gen asm EAX. ^ gen asm EAX Like that , a @<index> syntax can be used not just for method arguments but for any other, e.g. self@<index> , ivar@<index> -- Best regards, Igor Stasenko.

Oct. 22, 2012

Re: [Pharo-project] NativeBoost FFI

by Igor Stasenko

Ciprian, i took a look at your code. And I like it, except some naming choices, but that is not a big deal. :) There's one thing is missing in NBSTInObjectArgument: bounds checking. I would also add an option to control generating code for bounds checking for indirect arguments, turned on by default. Mainly this is all about following method: NBSTInObjectArgument>>emitLoad: gen | baseAddress | gen proxy stackValue: stackIndex. + gen optCheckIndirectArgBounds ifTrue: [ + "generate code here to check that index is valid for passed argument, otherwise fail the primitive" + ] gen proxy fetchPointer: elementIndex - 1 ofObject: gen asm EAX. ^ gen asm EAX May i ask you to give me your nickname on squeaksource, so i will add you as developer, so you can upload code there? -- Best regards, Igor Stasenko.

Oct. 22, 2012

Re: [Pharo-project] NativeBoost FFI

by Igor Stasenko

On 22 October 2012 01:59, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2012/10/22 Igor Stasenko <siguctua(a)gmail.com>: >> On 22 October 2012 01:20, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> 5 parameters???? Igor, you're a dictator ;) >>> Those theories are nice, but unhelpfull when applied to FFI >>> Pragmatically there's not any chance I rewrite LAPACK+BLAS for the >>> sake of purity. >>> >>> And your workaround (creating a class) is very poor, because maybe >>> classes themselves should not have more than 5 instance variables ;) >>> >> Hehe. >> This is same thing like increasing number of literals for methods (and >> max distances between jumps). >> It just makes sense where you deal with external chaotic world. >> My ideology is simple: prevent that chaos from entering our little peaceful bay. >> > > That's not exactly the philosophy behind FFI. > FFI is here to let the user manage the external chaotic world. > OK, external peels of the onion should have 5 parameters or less. > Near the sprout, you can't raise such barriers, or there is no onion at all. > Well, that's part of developer's responsibility, how to prevent chaos. Needless to say, nobody wants to deal with so many arguments at once (too much space for mistakes). As for my workaround: this mainly, how you tame the complexity in case it is inevitable? Look how code to call that function will look like: 1. passing as array args := Array new: 100. args at:1 put: x; at:2 put: y; ... at: 100 put: zork self callFn: args. 2. passing as instance of class, or external structure: args := MyFunctionArgs new. args firstArgumentName: x; secondArgumentName: y; ... hundrethArgumentName: zork. self callFn: args. admit that dealing with names instead of numbers leaves much less space for mistakes and serves for better clarity at same time. So, even if it is more cumbersome because requires defining extra class, at the end you win much more. Anyways, if people think it is worth adding indirect argument loader ( in form of param@<index>, but not param@ivar), we can introduce that. > Otherwise, the alternative would be to write all interfacing code in C > (Slang would not be an option with 5 parameters) and create new > primitives/plugins. > The exact opposite of FFI. > > Or even worse in terms of costs/benefits, rewrite LAPACK+BLAS. > >> Because first, you introduce it because you need it to deal with >> external world (only for 1% of cases, and in 0% of cases for good >> written smalltalk code). >> But that's only at beginning. >> Once people discover that they have no limits, i bet they will start >> abusing it in most horrible manner you ever seen. >> > > With such arguments you will soon want to protect us against some evil > super powers like become: thisContext etc... ;) > Don't castrate us and let us manage the risk of having 15+ parameters. > Yes, you are right. Another philosophy of mine is that system should not put artificial barriers for developer. He should be able to choose what is good for him, not system nor its authors. So i have two contradicting philosophies :) I think we can easily have more than 15 args with Opal compiler. And i will gladly add support for that in NativeBoost. Fixing existing compiler is a waste of time as to me. > Nicolas -- Best regards, Igor Stasenko.

Oct. 22, 2012

Re: [Pharo-project] NativeBoost FFI

by Nicolas Cellier

2012/10/22 Igor Stasenko <siguctua(a)gmail.com>: > On 22 October 2012 01:20, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 5 parameters???? Igor, you're a dictator ;) >> Those theories are nice, but unhelpfull when applied to FFI >> Pragmatically there's not any chance I rewrite LAPACK+BLAS for the >> sake of purity. >> >> And your workaround (creating a class) is very poor, because maybe >> classes themselves should not have more than 5 instance variables ;) >> > Hehe. > This is same thing like increasing number of literals for methods (and > max distances between jumps). > It just makes sense where you deal with external chaotic world. > My ideology is simple: prevent that chaos from entering our little peaceful bay. > That's not exactly the philosophy behind FFI. FFI is here to let the user manage the external chaotic world. OK, external peels of the onion should have 5 parameters or less. Near the sprout, you can't raise such barriers, or there is no onion at all. Otherwise, the alternative would be to write all interfacing code in C (Slang would not be an option with 5 parameters) and create new primitives/plugins. The exact opposite of FFI. Or even worse in terms of costs/benefits, rewrite LAPACK+BLAS. > Because first, you introduce it because you need it to deal with > external world (only for 1% of cases, and in 0% of cases for good > written smalltalk code). > But that's only at beginning. > Once people discover that they have no limits, i bet they will start > abusing it in most horrible manner you ever seen. > With such arguments you will soon want to protect us against some evil super powers like become: thisContext etc... ;) Don't castrate us and let us manage the risk of having 15+ parameters. Nicolas > Copy-paste is worst enemy of programmer. But usually not to one who > using it, but one who needs to maintain the code after :) > >> Nicolas >> > > > -- > Best regards, > Igor Stasenko. >

Oct. 21, 2012

Re: [Pharo-project] Doits not logged to .changes file

by Igor Stasenko

On 21 October 2012 18:26, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > It's a very old issue. Older than Pharo itself. > well, in 1.4 simple doits are logged. at least we should not make it worse than it was. > Noury > On 21 oct. 2012, at 12:02, Igor Stasenko wrote: > >> just found that they are not logger.. >> is it known issue of i am lucky one >> (Pharo2.0a Latest update: #20267) >> >> (tried 20351 image, same story) >> -- >> Best regards, >> Igor Stasenko. >> > > Noury Bouraqadi > Ecole des Mines de Douai > http://car.mines-douai.fr/noury > -- > > > > -- Best regards, Igor Stasenko.

Oct. 21, 2012