[Pharo-project] [update 2.0] #20358
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
[Pharo-project] pharo-2.0-tests » win - Build # 431 - Still Failing!
BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/pharo-2.0-tests/./label_exp=win/431/Project:label_exp=winDate of build:Mon, 22 Oct 2012 08:55:59 +0200Build duration:17 minCHANGESNo ChangesJUnit TestsName: AST.Tests.Core Failed: 0 test(s), Passed: 79 test(s), Skipped: 0 test(s), Total: 79 test(s)Name: AST.Tests.Semantic Failed: 0 test(s), Passed: 25 test(s), Skipped: 0 test(s), Total: 25 test(s)Name: Announcements.Tests.Core Failed: 0 test(s), Passed: 29 test(s), Skipped: 0 test(s), Total: 29 test(s)Name: BalloonTests.Collections Failed: 0 test(s), Passed: 34 test(s), Skipped: 0 test(s), Total: 34 test(s)Name: CollectionsTests.Arrayed Failed: 0 test(s), Passed: 553 test(s), Skipped: 0 test(s), Total: 553 test(s)Name: CollectionsTests.Atomic Failed: 0 test(s), Passed: 12 test(s), Skipped: 0 test(s), Total: 12 test(s)Name: CollectionsTests.Sequenceable Failed: 0 test(s), Passed: 912 test(s), Skipped: 0 test(s), Total: 912 test(s)Name: CollectionsTests.SplitJoin Failed: 0 test(s), Passed: 27 test(s), Skipped: 0 test(s), Total: 27 test(s)Name: CollectionsTests.Stack Failed: 0 test(s), Passed: 16 test(s), Skipped: 0 test(s), Total: 16 test(s)Name: CollectionsTests.Streams Failed: 0 test(s), Passed: 37 test(s), Skipped: 0 test(s), Total: 37 test(s)Name: CollectionsTests.Strings Failed: 0 test(s), Passed: 606 test(s), Skipped: 0 test(s), Total: 606 test(s)Name: CollectionsTests.Support Failed: 0 test(s), Passed: 12 test(s), Skipped: 0 test(s), Total: 12 test(s)Name: CollectionsTests.Unordered Failed: 0 test(s), Passed: 1954 test(s), Skipped: 0 test(s), Total: 1954 test(s)Name: CollectionsTests.Weak Failed: 0 test(s), Passed: 739 test(s), Skipped: 0 test(s), Total: 739 test(s)Name: CompilerTests Failed: 0 test(s), Passed: 180 test(s), Skipped: 0 test(s), Total: 180 test(s)Name: CompressionTests.Archive Failed: 2 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 7 test(s)Failed: CompressionTests.Archive.ZipArchiveTest.testCreateWithRelativeNamesFailed: CompressionTests.Archive.ZipArchiveTest.testZipName: Deprecated20 Failed: 0 test(s), Passed: 7 test(s), Skipped: 0 test(s), Total: 7 test(s)Name: FileSystem.Tests.Core Failed: 0 test(s), Passed: 185 test(s), Skipped: 0 test(s), Total: 185 test(s)Name: FileSystem.Tests.Disk Failed: 0 test(s), Passed: 53 test(s), Skipped: 0 test(s), Total: 53 test(s)Name: FileSystem.Tests.Memory Failed: 0 test(s), Passed: 50 test(s), Skipped: 0 test(s), Total: 50 test(s)Name: FreeTypeTests.cache Failed: 0 test(s), Passed: 23 test(s), Skipped: 0 test(s), Total: 23 test(s)Name: FuelMetalevelTests Failed: 0 test(s), Passed: 155 test(s), Skipped: 0 test(s), Total: 155 test(s)Name: FuelTests Failed: 0 test(s), Passed: 246 test(s), Skipped: 0 test(s), Total: 246 test(s)Name: FuelTests.Collections Failed: 0 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 5 test(s)Name: FuelTests.Streams Failed: 0 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 3 test(s)Name: Gofer.Tests Failed: 0 test(s), Passed: 43 test(s), Skipped: 0 test(s), Total: 43 test(s)Name: Graphics.Tests.Files Failed: 0 test(s), Passed: 47 test(s), Skipped: 0 test(s), Total: 47 test(s)Name: Graphics.Tests.Primitives Failed: 0 test(s), Passed: 57 test(s), Skipped: 0 test(s), Total: 57 test(s)Name: HelpSystem.Tests.Builders Failed: 0 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 5 test(s)Name: HelpSystem.Tests.Core.Model Failed: 0 test(s), Passed: 4 test(s), Skipped: 0 test(s), Total: 4 test(s)Name: HelpSystem.Tests.Core.UI Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: HelpSystem.Tests.Core.Utilities Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s)Name: KernelTests.Chronology Failed: 1 test(s), Passed: 582 test(s), Skipped: 0 test(s), Total: 583 test(s)Failed: KernelTests.Chronology.TimeTest.testGeneralInquiriesName: KernelTests.Classes Failed: 0 test(s), Passed: 68 test(s), Skipped: 0 test(s), Total: 68 test(s)Name: KernelTests.Exception Failed: 0 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 3 test(s)Name: KernelTests.Methods Failed: 0 test(s), Passed: 180 test(s), Skipped: 0 test(s), Total: 180 test(s)Name: KernelTests.Numbers Failed: 0 test(s), Passed: 276 test(s), Skipped: 0 test(s), Total: 276 test(s)Name: KernelTests.Objects Failed: 0 test(s), Passed: 87 test(s), Skipped: 0 test(s), Total: 87 test(s)Name: KernelTests.Pragmas Failed: 0 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 3 test(s)Name: KernelTests.Processes Failed: 0 test(s), Passed: 37 test(s), Skipped: 0 test(s), Total: 37 test(s)Name: Keymapping.Tests Failed: 0 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 38 test(s)Name: MorphicTests.Basic Failed: 0 test(s), Passed: 16 test(s), Skipped: 0 test(s), Total: 16 test(s)Name: MorphicTests.Event Failed: 0 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 9 test(s)Name: MorphicTests.Kernel Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 test(s)Name: MorphicTests.Text Support
[Pharo-project] Deltas / Change file + log / Undoing
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
[Pharo-project] [update 2.0] #20359
20359 - Issue 6860: Improve TransferMorph UI http://code.google.com/p/pharo/issues/detail?id=6860 Issue 6819: We should add Pharo14 as MC repository for 20 to support merging and monkey work http://code.google.com/p/pharo/issues/detail?id=6819 Issue 6726: Stream Number Printing Protocol http://code.google.com/p/pharo/issues/detail?id=6726 Issue 5238: LinkedList select: is not linear time http://code.google.com/p/pharo/issues/detail?id=5238 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.959.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.727.diff http://ss3.gemstone.com/ss/Pharo20/NautilusCommon-MarcusDenker.101.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1266.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.726.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1222.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.86.diff http://ss3.gemstone.com/ss/Pharo20/Collections-Unordered-MarcusDenker.144.diff http://ss3.gemstone.com/ss/Pharo20/Collections-Sequenceable-MarcusDenker.124.diff http://ss3.gemstone.com/ss/Pharo20/Collections-Abstract-MarcusDenker.191.diff -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] Yet another Notation format: Object literals
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-tp4651943p4652492.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Deltas / Change file + log / Undoing
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 Deltaundo 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 ChangeasAntiChange - 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 :)
[Pharo-project] BlockClosureensure: implementation
Hello, I don't understand something on BlockClosureensure:. Why does it use 'self valueNoContextSwitch' and not 'self value' ? In which case is there an issue ? Thank you for any answers BlockClosureensure: 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
[Pharo-project] [Call for Participation] Pharo Sprint Nov 2
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
[Pharo-project] [Jenkins] Windows build fixed.
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
Re: [Pharo-project] Deltas / Change file + log / Undoing
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 Deltaundo 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 ChangeasAntiChange - 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
Re: [Pharo-project] NativeBoost FFI
On 22.10.2012 02:37, Igor Stasenko wrote:
On 22 October 2012 01:59, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
2012/10/22 Igor Stasenko siguc...@gmail.com:
On 22 October 2012 01:20, Nicolas Cellier
nicolas.cellier.aka.n...@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
Re: [Pharo-project] [Pharo-users] [Call for Participation] Pharo Sprint Nov 2
i'm going 2012/10/22 Marcus Denker marcus.den...@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
Re: [Pharo-project] Deltas / Change file + log / Undoing
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 Deltaundo 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 ChangeasAntiChange - 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
Re: [Pharo-project] NativeBoost FFI
On 22 October 2012 12:00, Henrik Sperre Johansen
henrik.s.johan...@veloxit.no wrote:
On 22.10.2012 02:37, Igor Stasenko wrote:
On 22 October 2012 01:59, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
2012/10/22 Igor Stasenko siguc...@gmail.com:
On 22 October 2012 01:20, Nicolas Cellier
nicolas.cellier.aka.n...@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!
Yes, it looks familiar, but cannot tell where i seen it.
Gah.. how i could forget about it?
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.
keyword message syntax is bad for many arguments..
for such cases i find a positional argument notation more appeal
because it is more compact.
In any case, a complex math formulas smell equally bad in any
programming language
(sometime even if written by hand on paper using math notation(s) ;)
Cheers,
Henry
--
Best regards,
Igor Stasenko.
[Pharo-project] [update 2.0] #20360
20360 - Issue 6862: Configation CLI should not distinguish between symbol and strings as version names http://code.google.com/p/pharo/issues/detail?id=6862 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.45.diff -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] NativeBoost FFI
Hi guys,
First of all sorry for not saying anything the whole day ... but I don't
have internet connection at work. I hope I'll be excused though ;)
Now it will be a difficult for me to address all the issues raised ...
however I will try
First of all, IMHO any FFI should facilitate the task of the person writing
the library wrapper.
This comes the issue of (hopefully automatically) parsing C headers and
generating the calls.
Why?... well because if I take for instance the BLAS/LAPACK case (which was
cited today) have over 1000 functions exported.
Even if it is not 1000 lets say that you have a smaller library from which
you want to use only one function X but in order to use that precise
function you will maybe have to initialize some C context data, or a
specific data structure.
Of course you can do that by hand, but what if you really want to benefit
from the library without diving into the details... well in that case you
are a little bit stuck, either you write by hand a bunch of wrappers or you
quit.
The problem is that nice libraries that you want to use they usually have
horrible data structures behind that you cannot set up easily. This
happened to me several times in the future while trying to use different
external library calls (graphviz http://www.graphviz.org/,
metishttp://www.cs.umn.edu/~metis,
abc http://www.eecs.berkeley.edu/~alanmi/abc/,
vprhttp://www.eecg.toronto.edu/~vaughn/vpr/vpr.htmlto name a few) in
Pharo (with FFI, with Alien, etc). In almost all cases I
ended up generating text files and calling some bloody c program using
these files as input. The problem is that has a huge impact on
performances...
Now with nativeboost I found it pretty easy to automatically generate some
usable binding... I parsed the C headers with
srcmlhttp://www.sdml.info/projects/srcml/,
the I have parsed the XML looking for function definitions... For these
definitions I've generated the wrappers. Only that for over 15 argument
functions that did not work.
Now, I do not like the idea of hacking the compiler, or even subclassing it
like Nicolas did for Smallapack. And luckily we do not need to do that with
the arguments in an array trick... Moreover, I completely agree with Igor
on the fact that 15 arguments are to many, however Pharo really needs to
have an automatable FFI generation.
Igor, I have seen that you have mentioned some work-arounds using instance
variables, and/or NBExternalStructures. Both these ideas are great,
especially the use of the NBExternalStructure, however in my opinion if you
want to generate them automatically you've got yourself an even bigger
problem.
Will you generate a new class for each function call that you have?
What about the FFI being a wormhole to an ugly and mean world?
I think we should try to reduce the size of that hole ;)
Though, you have a point with using named arguments, and I think that is a
cool solution too. That is why I was speaking about directly accessing the
instance variables by name.
I simply didn't know enough about the hidden powers of NBExternalStructure.
;)
As for extending the nativeboost signatures and accessing object fields by
name, I completely agree with you that it is not a good idea.
However, using the indices of arrays I think is only a small addition that
can have a huge impact on the way people use NativeBoost FFI without adding
to much extra-overhead.
By the way, I think we definitely have to do the bound-checking trick by
default.
Moreover, having the NBSTInObjectArgument as a wrapper over another loader
is a great idea, giving us another degree of controlled freedom. ;)
Thanks Henrik for the good joke (I didn't see it coming :)), It makes me
hate this idea now. :P
self callFn: {x . y}
Looks kinda familiar doesnt it? (hint: swap { for ( and . for , )
I for one welcome our new syntactic overlords!
As for supporting or not more than 15 arguments for typical method calls...
I don't know... maybe is good maybe is bad, but I think there are other
things that need to be done before making a fuss about it. By the way is it
an arbitrary limit, or it is imposed by the use of 4 bytes for storing the
number of arguments?
Now let me come back to practical issues. My squeaksource id is cip.t (you
can find me searching ciprian in the members list).
Cheers,
Ciprian Teodorov
On Mon, Oct 22, 2012 at 1:09 PM, Igor Stasenko siguc...@gmail.com wrote:
On 22 October 2012 12:00, Henrik Sperre Johansen
henrik.s.johan...@veloxit.no wrote:
On 22.10.2012 02:37, Igor Stasenko wrote:
On 22 October 2012 01:59, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
2012/10/22 Igor Stasenko siguc...@gmail.com:
On 22 October 2012 01:20, Nicolas Cellier
nicolas.cellier.aka.n...@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
Re: [Pharo-project] [Pharo-users] [Call for Participation] Pharo Sprint Nov 2
Yes. We'll be 6 from Ecole des Mines : Santiago, Nick, Mariano, Jannik (yes he's back :-), Luc, and me. Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury On 22 oct. 2012, at 12:08, Santiago Bragagnolo wrote: i'm going 2012/10/22 Marcus Denker marcus.den...@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 Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Re: [Pharo-project] Hello + postgresql
On Fri, Oct 19, 2012 at 7:47 PM, Yanni Chiu ya...@rogers.com wrote: On 19/10/12 12:38 PM, roberto.minelli-BHDiRLqP7qo@**public.gmane.orgroberto.minelli-bhdirlqp...@public.gmane.orgwrote: I managed to have Pharo 1.4 with a working version of PostgresV2 native driver. I'll try with a fresh image and dbxtalk and let you guys know. If the native Postgres driver is good enough for now, there's no need to bother getting hardware specific opendbx libraries to work. However, the dbxtalk configuration includes Glorp, which you might want to try out. Yes, but still, you can also use Glorp with the native postgres driver if you want. (((Smalltalk at: #ConfigurationOfGlorpDBX) perform: #project) perform: #version: with: #stable) load: 'GlorpPostgresV2Native' If you have more questions/problems, please ask :) -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] Hello + postgresql
Thank you for the answer. Actually I put Pharo in standby for a while (deadlines are coming!) The last thing I tried to do, was a query on a relatively big database (~10m entries) and every time I issued the query, Pharo quitted unexpectedly. As soon as I resume my tests with Pharo, Postgres, OpenDBX, and Glorp I'll for sure get back to you! By now thanks for your answer. Anyway, did someone manage to install OpenDBX on a Mac running Mountain Lion (and Pharo 2.0)? As far as I rememer I had problems in compiling and installing OpenDBX native driver. However, I'll post more detailed question as soon as I resume my tests :) Cheers, Roberto Il giorno 22-ott-2012, alle ore 22:42, Mariano Martinez Peck marianop...@gmail.commailto:marianop...@gmail.com ha scritto: On Fri, Oct 19, 2012 at 6:38 PM, roberto.mine...@usi.chmailto:roberto.mine...@usi.ch roberto.mine...@usi.chmailto:roberto.mine...@usi.ch wrote: I managed to have Pharo 1.4 with a working version of PostgresV2 native driver. I'll try with a fresh image and dbxtalk and let you guys know. You can see our set of tools here: http://dbxtalk.smallworks.com.ar/tools Il giorno 19-ott-2012, alle ore 18:05, Yanni Chiu ya...@rogers.commailto:ya...@rogers.com ha scritto: On 19/10/12 4:05 AM, roberto.mine...@usi.chmailto:roberto.mine...@usi.ch wrote: I already received some answers, but further hints are appreciated. Just download a Pharo-1.4 one-click, and proceed to install and setup up dbxtalk (see: http://dbxtalk.smallworks.com.ar/). The dbxtalk stuff has the option to use the native PostgreSQL driver. IMHO, further up front investigation is going to be of limited value. I already tried, tried and tried. I just wrote in the mailing list after severa trials. However next time I'll write when I encounter specific problems ;) Just dive in, and ask specific questions as you work through it (e.g. where do I find ...? Is ... supposed to be working, because I did ..., and it didn't work). Thank you, Roberto -- Mariano http://marianopeck.wordpress.com
[Pharo-project] zero conf build
I finally managed to create a zero conf pharo image build setup: # === curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | sh ./vm.sh Pharo.image save $JOB_NAME REPO=http://smalltalkhub.com/mc/dh83/nabujito/main ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfNabujito --install=development ./vm.sh $JOB_NAME.image test --junit-xml-output Nabujito zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes # === ./ciPharo20Cog.sh --help This is an entry point script for any Pharo image CI This script will download the latest Pharo 2.0 image and the latest VM Result in the current directory: vm directory containing the VM vm.shscript forwarding to the VM inside vm/ Pharo.image The latest pharo image Pharo.changesThe corresponding pharo changes # === have fun!
Re: [Pharo-project] zero conf build
Camillo Bruni-3 wrote curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | sh If on a system where bash is not the default shell (e.g. Ubuntu 12.04) that line should be: curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | bash -- View this message in context: http://forum.world.st/zero-conf-build-tp4652566p4652567.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] zero conf build
the scripts starts with #!/bin/bash so IMO you're fine, no? well definitely won't harm to pass it on directly to bash ;) thanks On 2012-10-23, at 00:47, Paul DeBruicker pdebr...@gmail.com wrote: Camillo Bruni-3 wrote curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | sh If on a system where bash is not the default shell (e.g. Ubuntu 12.04) that line should be: curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | bash -- View this message in context: http://forum.world.st/zero-conf-build-tp4652566p4652567.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] zero conf build
Camillo Bruni-3 wrote the scripts starts with #!/bin/bash so IMO you're fine, no? well definitely won't harm to pass it on directly to bash ;) thanks You'd think that were true and I did see that you had the #!/bin/bash but it still died when it hit the '[[' on line 8. Ubuntu uses dash as default shell and dash doesn't have the '[[]]' compound conditional statements. It could be that I've done something stupid to my system to cause it to break but maybe not. -- View this message in context: http://forum.world.st/zero-conf-build-tp4652566p4652570.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] zero conf build
Very cool ! Thanks a lot for all the work. On 23 Oct 2012, at 00:28, Camillo Bruni camillobr...@gmail.com wrote: I finally managed to create a zero conf pharo image build setup: # === curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | sh ./vm.sh Pharo.image save $JOB_NAME REPO=http://smalltalkhub.com/mc/dh83/nabujito/main ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfNabujito --install=development ./vm.sh $JOB_NAME.image test --junit-xml-output Nabujito zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes # === ./ciPharo20Cog.sh --help This is an entry point script for any Pharo image CI This script will download the latest Pharo 2.0 image and the latest VM Result in the current directory: vm directory containing the VM vm.shscript forwarding to the VM inside vm/ Pharo.image The latest pharo image Pharo.changesThe corresponding pharo changes # === have fun!
