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

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

by GÃ¶ran Krampe

On 10/22/2012 11:31 AM, Goubier Thierry wrote: > Le 22/10/2012 11:07, GÃ¶ran Krampe a Ã©crit : >> Hi! >> >> (not up to speed on Pharo "goals" in this area, but...) >> >> On 10/22/2012 09:45 AM, Goubier Thierry wrote: >>> 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...). >> >> Note - Deltas actually *exist* - it is not just a proposal. They work. >> >> And the answer is "yes", it enables full multilevel undo of *source* >> changes to the image. >> >> It does this by making sure each "Change": >> - Has captured enough state to reverse itself in full. >> - Knows how to create its "anti-Change". >> >> ...then the code in Delta>>undo basically ends up like: >> >> changes reversed do: [:each | each asAntiChange apply ] >> >> ...well, in fact - it is not written exactly like that - we create a >> full "anti-Delta" first, and then "apply" it. But anyway, you get my >> point. >> >> Major changes compared to the total misfit ChangeSet: >> >> - A Delta has *ordered* Changes, not a "Set". So we could call a >> Delta a "ChangeList" instead. :) >> >> - A Delta and its list of Changes is *completely* standalone from >> the rest of the image. Thus trivially serialized, thrown away etc. >> >> A ChangeSet is *not at all* standalone, which is the worst aspect of >> them. You can easily see this yourself by: >> >> - Create a ChangeSet and add a method (it gets recorded) >> - Create a new ChangeSet and modify same method (it gets recorded >> in the new ChangeSet) >> - Take a look in the previous ChangeSet, tada! The method there is >> now not at all what it was from the start... >> >> ...so a ChangeSet actually only "points" at methods, they do NOT contain >> the actual change! >> >> Now, coming back to Change>>asAntiChange - this is where the tricky part >> starts... >> >> First each SystemChangeAnnoncement MUST capture all state. For example, >> earlier a "new class comment" didn't send along the old comment! And it >> was fired *after* the change was done, so information was lost. Not sure >> how Pharo does on that exact example today - worth checking for fun! :) >> >> Secondly, the delete/remove Change objects end up to have to capture ALL >> state that was removed... So a "remove class X"-change must in fact >> capture enough information to be able to reconstruct it. Thus Deltas >> have CompositeChange which basically is a full list of smaller changes >> like create a class X, add n methods to it etc. > > Ok, then I could imagine having a system browser which is able to use > Deltas to show this ability to list changes and undo them. Yes, and while Matthew wrote one UI for Deltas (a system browser variant) I was not all too comfortable with that "view". I was more thinking of simply rewire Dual change sorter and friends to use Deltas instead. > Is there any provision to selectively undo changes and try to maintain > the system in a consistent state? For example, undo a class rename and > you may have to recompile / change methods which refer to that class > name to maintain the system in a consistent state. Well, I started on this idea of "condensing" a Delta which would remove all redundancy (changes shadowing other changes) and also typically "move" renames to the beginning or end (and adapt the other changes to that fact of course). This is a fun challenge - but I didn't finish it due to lack of time. And yes, this "shadowing analysis" would also come into play in your uses case. >>> How does this relates with the undo/redo facility in RefactoringBrowser? >> >> Dunno. > > Well, there are some commands such as RBRenameClassRefactoring, when > executed, which get stored in an undo/redo facility > (RBRefactoryChangeManager) where you can undo or redo the operation. > > So, as you can see, it is already a way to record user-made changes and > undo them, probably very cleanly, with a huge hierarchy of available > commands and ways to group them. Yeah, and at the moment I can't really comment on it - but it sure is something we would want to look into. Deltas operate on the lowest level - and was meant to do that by design. RB is on another higher level. regards, GÃ¶ran

Oct. 22, 2012

Re: [Pharo-project] [Pharo-users] [Call for Participation] Pharo Sprint Nov 2

by Santiago Bragagnolo

i'm going 2012/10/22 Marcus Denker <marcus.denker(a)inria.fr> > RMoD is organizing a Pharo Sprint > > â¢ When? Fr, Nov 2nd. Starting at 9am > â¢ Where? INRIA Lille, Building B. http://www.inria.fr/centre/lille > > The plan is to push together to evaluate which bugs need to be fixed > before a release (and of course fix as many as possible). > Please contact us if you plan to attend until 30/10! > > http://rmod.lille.inria.fr/web/pier/Events/PharoSprintNov12 > > -- > Marcus Denker -- http://marcusdenker.de > > >

Oct. 22, 2012

Re: [Pharo-project] NativeBoost FFI

by Henrik Sperre Johansen

On 22.10.2012 02:37, Igor Stasenko wrote: > 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. self callFn: {x . y} Looks kinda familiar doesnt it? (hint: swap { for ( and . for , ) I for one welcome our new syntactic overlords! > > 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. > While I often find this a good idea for maintainability, it sorta flies in the face of another of ST's strengths, iterative/exporatory programming. If you are forced to think up front about which parameter classes you need due to a small limit, rather than introduce them ad-hoc when the code really needs the refactoring to remain legible, it slows you down. Not thinking of FFI specifically, but I have seen lots of evolved mathematical models where a 5-parameter limit upfront would probably lead to either: a) *Really* bad code, ie. making the calculation object stateful by storing in instvars instead. (and in the process, make it really hard to know which instvars are actually part of object state and not temp vars of some calculation) b) Switching to another programming language out of frustration. Cheers, Henry

Oct. 22, 2012

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

by Goubier Thierry

Le 22/10/2012 11:07, GÃ¶ran Krampe a Ã©crit : > Hi! > > (not up to speed on Pharo "goals" in this area, but...) > > On 10/22/2012 09:45 AM, Goubier Thierry wrote: >> 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...). > > Note - Deltas actually *exist* - it is not just a proposal. They work. > > And the answer is "yes", it enables full multilevel undo of *source* > changes to the image. > > It does this by making sure each "Change": > - Has captured enough state to reverse itself in full. > - Knows how to create its "anti-Change". > > ...then the code in Delta>>undo basically ends up like: > > changes reversed do: [:each | each asAntiChange apply ] > > ...well, in fact - it is not written exactly like that - we create a > full "anti-Delta" first, and then "apply" it. But anyway, you get my point. > > Major changes compared to the total misfit ChangeSet: > > - A Delta has *ordered* Changes, not a "Set". So we could call a > Delta a "ChangeList" instead. :) > > - A Delta and its list of Changes is *completely* standalone from > the rest of the image. Thus trivially serialized, thrown away etc. > > A ChangeSet is *not at all* standalone, which is the worst aspect of > them. You can easily see this yourself by: > > - Create a ChangeSet and add a method (it gets recorded) > - Create a new ChangeSet and modify same method (it gets recorded > in the new ChangeSet) > - Take a look in the previous ChangeSet, tada! The method there is > now not at all what it was from the start... > > ...so a ChangeSet actually only "points" at methods, they do NOT contain > the actual change! > > Now, coming back to Change>>asAntiChange - this is where the tricky part > starts... > > First each SystemChangeAnnoncement MUST capture all state. For example, > earlier a "new class comment" didn't send along the old comment! And it > was fired *after* the change was done, so information was lost. Not sure > how Pharo does on that exact example today - worth checking for fun! :) > > Secondly, the delete/remove Change objects end up to have to capture ALL > state that was removed... So a "remove class X"-change must in fact > capture enough information to be able to reconstruct it. Thus Deltas > have CompositeChange which basically is a full list of smaller changes > like create a class X, add n methods to it etc. Ok, then I could imagine having a system browser which is able to use Deltas to show this ability to list changes and undo them. Is there any provision to selectively undo changes and try to maintain the system in a consistent state? For example, undo a class rename and you may have to recompile / change methods which refer to that class name to maintain the system in a consistent state. >> How does this relates with the undo/redo facility in RefactoringBrowser? > > Dunno. Well, there are some commands such as RBRenameClassRefactoring, when executed, which get stored in an undo/redo facility (RBRefactoryChangeManager) where you can undo or redo the operation. So, as you can see, it is already a way to record user-made changes and undo them, probably very cleanly, with a huge hierarchy of available commands and ways to group them. >> 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. > > IMHO they are in fact two different things - but of course can be made > to play better with each other. Also, one reason ChangeSets are hard is > probably because they are misunderstood (because of their bad design IMHO). > > Sorry for lengthy post. > > regards, GÃ¶ran > > PS. I presented and demoed Deltas at an ESUG a few years back, but > unfortunately most people attended a Seaside thing in parallell :) Thanks for the explanation, Thierry -- 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] [Jenkins] Windows build fixed.

by Marcus Denker

https://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/pharo-2.0-tests/ We are down to 5 failures on all architectures + 2 more on windows Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 22, 2012

[Pharo-project] [Call for Participation] Pharo Sprint Nov 2

by Marcus Denker

RMoD is organizing a Pharo Sprint â¢ When? Fr, Nov 2nd. Starting at 9am â¢ Where? INRIA Lille, Building B. http://www.inria.fr/centre/lille The plan is to push together to evaluate which bugs need to be fixed before a release (and of course fix as many as possible). Please contact us if you plan to attend until 30/10! http://rmod.lille.inria.fr/web/pier/Events/PharoSprintNov12 -- Marcus Denker -- http://marcusdenker.de

Oct. 22, 2012

[Pharo-project] BlockClosure>>ensure: implementation

by ClÃ©ment Bera

Hello, I don't understand something on BlockClosure>>ensure:. Why does it use 'self valueNoContextSwitch' and not 'self value' ? In which case is there an issue ? Thank you for any answers BlockClosure>>ensure: is implemented this way : ensure: aBlock "Evaluate a termination block after evaluating the receiver, regardless of whether the receiver's evaluation completes. N.B. This method is *not* implemented as a primitive. Primitive 198 always fails. The VM uses prim 198 in a context's method as the mark for an ensure:/ifCurtailed: activation." | complete returnValue | <primitive: 198> returnValue := *self valueNoContextSwitch*. complete ifNil:[ complete := true. aBlock value. ]. ^ returnValue

Oct. 22, 2012

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

by GÃ¶ran Krampe

Hi! (not up to speed on Pharo "goals" in this area, but...) On 10/22/2012 09:45 AM, Goubier Thierry wrote: > 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...). Note - Deltas actually *exist* - it is not just a proposal. They work. And the answer is "yes", it enables full multilevel undo of *source* changes to the image. It does this by making sure each "Change": - Has captured enough state to reverse itself in full. - Knows how to create its "anti-Change". ...then the code in Delta>>undo basically ends up like: changes reversed do: [:each | each asAntiChange apply ] ...well, in fact - it is not written exactly like that - we create a full "anti-Delta" first, and then "apply" it. But anyway, you get my point. Major changes compared to the total misfit ChangeSet: - A Delta has *ordered* Changes, not a "Set". So we could call a Delta a "ChangeList" instead. :) - A Delta and its list of Changes is *completely* standalone from the rest of the image. Thus trivially serialized, thrown away etc. A ChangeSet is *not at all* standalone, which is the worst aspect of them. You can easily see this yourself by: - Create a ChangeSet and add a method (it gets recorded) - Create a new ChangeSet and modify same method (it gets recorded in the new ChangeSet) - Take a look in the previous ChangeSet, tada! The method there is now not at all what it was from the start... ...so a ChangeSet actually only "points" at methods, they do NOT contain the actual change! Now, coming back to Change>>asAntiChange - this is where the tricky part starts... First each SystemChangeAnnoncement MUST capture all state. For example, earlier a "new class comment" didn't send along the old comment! And it was fired *after* the change was done, so information was lost. Not sure how Pharo does on that exact example today - worth checking for fun! :) Secondly, the delete/remove Change objects end up to have to capture ALL state that was removed... So a "remove class X"-change must in fact capture enough information to be able to reconstruct it. Thus Deltas have CompositeChange which basically is a full list of smaller changes like create a class X, add n methods to it etc. > How does this relates with the undo/redo facility in RefactoringBrowser? Dunno. > 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. IMHO they are in fact two different things - but of course can be made to play better with each other. Also, one reason ChangeSets are hard is probably because they are misunderstood (because of their bad design IMHO). Sorry for lengthy post. regards, GÃ¶ran PS. I presented and demoed Deltas at an ESUG a few years back, but unfortunately most people attended a Seaside thing in parallell :)

Oct. 22, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by drush66

Dale Henrichs wrote > If you guys are all fired up to write parsers:) writing a YAML parser for > Smalltalk would be very cool. There are yaml parsers for a bunch of > languages, but a Smalltalk parser is conspicuously absent ... > > YAML is very readable (all the extraneous gibberish has been removed from > the syntax)... YAML appears to be the format of choice when humans and > computers need to share the data file and would be not only work across > dialects... > > Dale > > [1] http://www.yaml.org/ Oh yes, YAML parser/writer is dearly really missing. Text format should be readable, if not, give me serialized byte stream please. And by readable, I think readable by any user of software written in Smalltalk, not the Smalltalk programmer himself. As for executing file format without parsing it and interpreting it - funny how this bad idea finds its way to reappear so many times in spite of how many people got burned with it. ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Yet-another-Notation-format-Object-literals-tp4651943… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 22, 2012

[Pharo-project] [update 2.0] #20359

by Marcus Denker

Oct. 22, 2012