- Pharo-dev - lists.pharo.org

[Pharo-project] Hudson version 2.0 is available

by DougEdmunds

Pharo is being developed on a Hudson 1.358 server (2010/05/14). Hudson has recently released version 2.0 (2011/04/21). http://hudson-ci.org/ -- View this message in context: http://forum.world.st/Hudson-version-2-0-is-available-tp3475761p3475761.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2011

Re: [Pharo-project] What is a well documented class?

by Michael J. Forster

StÃ©phane Ducasse wrote: > > > yes but.... let us write more comments. > All the rest is arguments not to write them which is far easier as usual. > > Stef > Absolutely. Sorry, I didn't mean to imply otherwise. Mike -- View this message in context: http://forum.world.st/What-is-a-well-documented-class-tp3470956p3475730.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2011

Re: [Pharo-project] Better debugging...

by Toon Verwaest

> I am not sure if I understood correctly, but you may want to take a > look to Gemstone. As far as I remember they can have not only > different versions of a certain class at the same time, but also > instances of a specific class version all living together at the same > time. Thanks for the pointer, but yeah, I know about Gemstone. Our ideas are slightly different however... The idea is more to have multiple versions of the same live instance at the same time in memory; depending on the version of the code they are related to. This threads running in different versions can look at the same instances but have a slightly different view on the object graph. The only objects that will have different versions are global objects, hence the thread-local pools to avoid overhead when unnecessary. Then since threads are related to versions, we would have different heaps for the different versions of the global space. For example in the case of the alias debugger, the debugger has a view on the world that is completely aliased. Its version of the heap will look like that. The rest of the code would however immediately break if it would access the global state in that format since the alias-wrappers are unexpected. So we have 2 versions of the global heap, 1 with aliases and 1 without. For further reading, look at Erwann's active context. cheers, Toon

April 26, 2011

Re: [Pharo-project] Better debugging...

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 1:54 PM, Toon Verwaest <toon.verwaest(a)gmail.com>wrote: > I'm working on porting this idea already to the Glamour debugger. > > The idea is basically to use meta-circular interpreters as a way to specify > what semantics you want, but for speed reasons you might want to flatten out > the interpretation by combining both. This however should all be done behind > the scenes, independent of the definition of the debugger. > > More elaborate debuggers such as the alias debugger can be implemented but > there's no good way yet to separate the data spaces involved. That's where > me and Erwann are looking at how to maybe use a GC that can run multiple > different versions code at the same time while synchronizing the shared data > between the versions of the code. > I am not sure if I understood correctly, but you may want to take a look to Gemstone. As far as I remember they can have not only different versions of a certain class at the same time, but also instances of a specific class version all living together at the same time. > For example in the case of the alias debugger, that needs aliases > everwhere; but all the global data (classes, methods, ...) is not aliased. > To make this work you actually want to have a "copy" of the global data that > is aliased, but kept in sync with the original data. Here it starts making a > lot of sense to have thread-local heaps + a versioned but synced global > heap. > > Of course that's all still wishful thinking... step by step :) > > cheers, > Toon > > > On 04/25/2011 11:29 PM, Camillo Bruni wrote: > >> I think a nice way to have a decent debugger is to run the program on top >> of a changeable interpreter. Since a classical debugger is nothing else but >> an interpreter with slightly changed semantics. >> >> The object flow VM does a great job at tracing back stuff.. however it >> might pose a massive overhead since it collects tons and tons of data. >> >> In Pinocchio[1] we implemented very nice and simple debuggers by "just" >> changing the current interpreter to take a user-action into account on each >> message send. Since this is implemented on top of a metacircular interpreter >> this was quite simple to achieve. So the whole implementation of the known >> debugger functionality (step, over...) maybe took an afternoon. Since you >> have access to the full interpreter protocol it is very easy to intercept >> different sorts of actions. As described in the linked paper, it was very >> easy to implement the object-flow behavior in Pinocchio. >> >> So for me there is only one real way to have a decent debugger. And that >> means that it is a first-class interpreter whose semantics I can change at >> will. Thus I can create a specific debugger for my applications. >> >> But I guess that making the first-class interpreters work right away in >> Pharo will take a while to do, hence I propose the following additions to >> the current interpreter to make it partly useable: >> >> - interception of message sends >> - per thread [ok] >> - of specific classes [missing] >> - of specific instances [missing] >> >> - interception of instance variable access, read/write >> - per thread [missing] >> - of specific classes [missing] >> - of specific instances [missing] >> - of specific instance variables [missing] >> >> Furthermore I really want to be able to script all of that stuff, eg. >> provide a simple test block that gets invoked on each message send. >> Returning true => halt, Returning false => continue execution. >> >> >> [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf >> > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Henrik should we include Settings-Sound ?

by StÃ©phane Ducasse

On Apr 26, 2011, at 3:32 PM, Henrik Sperre Johansen wrote: > On 26.04.2011 15:27, StÃ©phane Ducasse wrote: >> but henrik I would not rever the change. >> If I remember correctly I change them because they were incorrect. >> >> Stef > No, they were not incorrect, you tried to sort out a dependency, which I tried to point out was just as well solved by changing the package structure. I'm not convinced and I do not have the time now to work on it. But I'm sure that this was not only the problem of the package structure. There was something fondamentally wrong in the way it was done. > For example, now: > - Changing "sound enabled" in the Settings Browser is now broken. > - Backwards compatability with 1.0 and 1.1 for new packages based on the changes in core was broken, due to moving API from instance to class side. > > Cheers, > Henry >

April 26, 2011

Re: [Pharo-project] Henrik should we include Settings-Sound ?

by Henrik Sperre Johansen

On 26.04.2011 15:27, StÃ©phane Ducasse wrote: > but henrik I would not rever the change. > If I remember correctly I change them because they were incorrect. > > Stef No, they were not incorrect, you tried to sort out a dependency, which I tried to point out was just as well solved by changing the package structure. For example, now: - Changing "sound enabled" in the Settings Browser is now broken. - Backwards compatability with 1.0 and 1.1 for new packages based on the changes in core was broken, due to moving API from instance to class side. Cheers, Henry

April 26, 2011

Re: [Pharo-project] About testing that ensure works

by StÃ©phane Ducasse

good suggestion. I will check that. Stef On Apr 26, 2011, at 3:11 PM, Henrik Sperre Johansen wrote: > On 24.04.2011 12:05, StÃ©phane Ducasse wrote: >>> i am puzzled. You wanna to be sure that ensure block are executed? >>> It is. >> I want to write a test that shows and tests the withOrganizer:do: semantics. >> In particular that the ensure is executed and that the context set by the withOrganizer: is only present >> in the do: block. >> > In other words, another use case probably written more cleanly using the non-existing > Announcer >> #suspend: subscriber while: aBlock > > ;) > > Cheers, > Henry >

April 26, 2011

Re: [Pharo-project] Error with latest ProfStef in Pharo 1.3

by Alexandre Bergel

Thanks Laurent & Patrick, it was cool! Alexandre On 25 Apr 2011, at 16:31, Alexandre Bergel wrote: > Ok, tomorrow at 13:20 - 13:30 (GMT+1) on skype > > Alexandre > > > On 25 Apr 2011, at 15:26, laurent laffont wrote: > >> >> On Mon, Apr 25, 2011 at 8:30 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> May be I can check this with my local developer group on Tuesday (we meet from 12:30 -> 13h30. If you wake up early :) >> >> 13:30 in france is 8:30 in Chile. I usually arrive at 8:20 at work. So, we meet on tomorrow? >> Using IRC? >> >> No problem. We can use skype. >> >> Laurent. >> >> >> >> Cheers, >> Alexandre >> >>> Laurent >>> >>> We could then write new tests, make sure ProfStef works for Pharo 1.3 and fix the bug found by Mariano. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 24 Apr 2011, at 12:33, laurent laffont wrote: >>> >>>> >>>> On Sun, Apr 24, 2011 at 6:43 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> ah ah! This is what we have changed during the pharo cast. >>>> Laurent, do you want that we have a look at it together? >>>> >>>> haha I won't be able to look at it until Tuesday. >>>> >>>> Laurent. >>>> >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 24 Apr 2011, at 11:30, Mariano Martinez Peck wrote: >>>> >>>>> "Error 'Please use buildTutorialTopicFor: instead'" >>>>> >>>>> when I try to open it from the menu. >>>>> >>>>> ProfStefHelpTutorialBuilder >> buildHelpTopicFrom: aHelpTopicDescription >>>>> "Start building from the given help topic description" >>>>> >>>>> ^(self new) >>>>> rootToBuildFrom: aHelpTopicDescription; >>>>> build; >>>>> topicToBuild >>>>> >>>>> the rpoblem is that #new >>>>> >>>>> I am using last versions of Pharo1.3 >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 26, 2011

Re: [Pharo-project] Henrik should we include Settings-Sound ?

by StÃ©phane Ducasse

but henrik I would not rever the change. If I remember correctly I change them because they were incorrect. Stef > On 24.04.2011 15:57, Mariano Martinez Peck wrote: >> I saw that package in PharoSound and I wonder if it should be added to the Metacello conf >> >> cheers >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > Yes, in a version 4.0 for 1.1 and 1.3 together with Sound-MarianoMartinezPeck.65 , as soon as we revert some stuff that was done in base which broke it. > IE. change registration back to working with instances, and soundEnabled to use a class var of SoundService rather than that of it's registered class. > > It will not work with the code based on branch from PharoTaskForces (Sound-MarianoMartinezPeck.64), as that one just deleted all preferences rather than preserve them in a functionally correct way. > > Cheers, > Henry >

April 26, 2011

Re: [Pharo-project] What is a well documented class?

by Alexandre Bergel

> What would be a "casual user" of a class in Smalltalk? Someone who does not care about the type of instances variables of that particular class :-) Alexandre > > > Em 25/04/2011 18:19, Alexandre Bergel < alexandre.bergel(a)me.com > escreveu: > Ok, focusing on the instance variables. I think there is two kind of documentation, one for the casual user, and another for the developers. > > Alexandre > > > On 25 Apr 2011, at 16:09, DougEdmunds wrote: > >> 2cents about "what is a well-documented class?": >> >> Information about the state variables (instance variables): what goes in the >> slot, and what it's for. >> >> Good examples (the layout gets skewed doing copy/paste) >> >> in RxsPredicate >> >> Instance Variables: >> >> predicate A one-argument block. If it evaluates to the value >> defined by >> when it is passed a character, the predicate is considered to >> match. >> >> negation A one-argument block that is a negation of >> . >> >> >> SMxMorph >> >> Structure: >> instance var Type Description >> bounds Rectangle A Rectangle indicating my position and a size that will >> enclose me. >> >> owner SMxMorph My parent SMxMorph, or nil for the top-level SMxMorph, >> which is a >> or nil world, typically a SMxPasteUpMorph. >> >> submorphs Array My child Morphs. >> >> fullBounds Rectangle A Rectangle minimally enclosing me and my >> submorphs. >> >> color Color My primary color. Subclasses can use this in different >> ways. >> >> extension SMxMorphExtension Allows extra properties to be stored without >> adding a >> or nil storage burden to all morphs. >> >> >> -- >> View this message in context: http://forum.world.st/What-is-a-well-documented-class-tp3470956p3474024.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 26, 2011