- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About not using full Pharo

by StÃ©phane Ducasse

Thanks for the help. I will do it incrementally. This is just that I should shake our infrastrcuture but since this is for the better :) > Stef, > > I don't have the time myself to take on the task of configuring the pharo core, but I _am_ willing to spend time on specific problems (they don't have to be hard ones either:) ... In other words, if you don't know how to do something in Metacello or the configuration isn't doing what you want, don't spend too much time debugging/figuring things out (unless you are enjoying it:) just shoot the problem to me and I'll take a crack at resolving the immediate problem ... > > The MetacelloBrowser toolset hasn't gotten to the point where they'd be useful ... it will be several weeks (at a minimum) before something useful along those lines appears... > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Monday, June 20, 2011 8:20:57 AM > | Subject: Re: [Pharo-project] About not using full Pharo > | > | I will check if I can start to use Metacello for the update but I > | will need time for that and I do not have time right now. > | > | > | Stef > | > | On Jun 20, 2011, at 4:09 PM, Torsten Bergmann wrote: > | > | > It's hard to work on core without good tools and this will > | > become more painfull the more we strip down core in the future. > | > > | > But we all agreed that we need a stable core to build on > | > top of it because there are also people who just require > | > a core Smalltalk and not a full developer IDE or people > | > who have their own IDE setup or want to do experiments. > | > > | > There is only one solution to this: > | > - repackage and introduce clean dependencies between > | > the packages > | > > | > If this is done it is much easier > | > - to build a dev on top of core by loading > | > - to build a core by stripping a dev > | > - to build a kernel from core > | > - to have a custom image with the packages you need > | > > | > And once we have done it we can extend our toolset not > | > only to build and test packages but also to check validness > | > and quality. > | > > | > My 0.02â¬ > | > T. > | > -- > | > NEU: FreePhone - kostenlos mobil telefonieren! > | > Jetzt informieren: http://www.gmx.net/de/go/freephone > | > > | > | > | >

June 20, 2011

Re: [Pharo-project] About not using full Pharo

by Dale Henrichs

Stef, I don't have the time myself to take on the task of configuring the pharo core, but I _am_ willing to spend time on specific problems (they don't have to be hard ones either:) ... In other words, if you don't know how to do something in Metacello or the configuration isn't doing what you want, don't spend too much time debugging/figuring things out (unless you are enjoying it:) just shoot the problem to me and I'll take a crack at resolving the immediate problem ... The MetacelloBrowser toolset hasn't gotten to the point where they'd be useful ... it will be several weeks (at a minimum) before something useful along those lines appears... Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Monday, June 20, 2011 8:20:57 AM | Subject: Re: [Pharo-project] About not using full Pharo | | I will check if I can start to use Metacello for the update but I | will need time for that and I do not have time right now. | | | Stef | | On Jun 20, 2011, at 4:09 PM, Torsten Bergmann wrote: | | > It's hard to work on core without good tools and this will | > become more painfull the more we strip down core in the future. | > | > But we all agreed that we need a stable core to build on | > top of it because there are also people who just require | > a core Smalltalk and not a full developer IDE or people | > who have their own IDE setup or want to do experiments. | > | > There is only one solution to this: | > - repackage and introduce clean dependencies between | > the packages | > | > If this is done it is much easier | > - to build a dev on top of core by loading | > - to build a core by stripping a dev | > - to build a kernel from core | > - to have a custom image with the packages you need | > | > And once we have done it we can extend our toolset not | > only to build and test packages but also to check validness | > and quality. | > | > My 0.02â¬ | > T. | > -- | > NEU: FreePhone - kostenlos mobil telefonieren! | > Jetzt informieren: http://www.gmx.net/de/go/freephone | > | | |

June 20, 2011

[Pharo-project] RecentMessageList gets troubled when we use version

by StÃ©phane Ducasse

Hi Ben When I open RecentMessageList and selection sorted by first I get a DNU. I fixed it, but I after building the list is quite slow. And also this is strange because under 1.4 I get a lot of 1.3 changes. Stef findIndexOfVersionOf: aMethodReference | list timeStamp| timeStamp := aMethodReference timeStamp. list := self versionsHistoryList. list size = 1 ifTrue: [^1]. 1 to: list size - 1 do: [:i || current next | current := list at: i. next := list at: (i+1). ((current value asDateAndTime <= timeStamp asDateAndTime) & (next value asDateAndTime> timeStamp asDateAndTime)) ifTrue: [^i]]. ^list size.

June 20, 2011

Re: [Pharo-project] About not using full Pharo

by StÃ©phane Ducasse

I will check if I can start to use Metacello for the update but I will need time for that and I do not have time right now. Stef On Jun 20, 2011, at 4:09 PM, Torsten Bergmann wrote: > It's hard to work on core without good tools and this will > become more painfull the more we strip down core in the future. > > But we all agreed that we need a stable core to build on > top of it because there are also people who just require > a core Smalltalk and not a full developer IDE or people > who have their own IDE setup or want to do experiments. > > There is only one solution to this: > - repackage and introduce clean dependencies between > the packages > > If this is done it is much easier > - to build a dev on top of core by loading > - to build a core by stripping a dev > - to build a kernel from core > - to have a custom image with the packages you need > > And once we have done it we can extend our toolset not > only to build and test packages but also to check validness > and quality. > > My 0.02â¬ > T. > -- > NEU: FreePhone - kostenlos mobil telefonieren! > Jetzt informieren: http://www.gmx.net/de/go/freephone >

June 20, 2011

Re: [Pharo-project] [ANN] humane-assessment.com

by GermÃ¡n Arduino

Very interesting. GermÃ¡n. 2011/6/20 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > I am happy to announce the new home for humane assessment: > http://humane-assessment.com > > Humane assessment is a new software engineering method for making the assessment of software systems practical and manageable. This is made possible by the Moose analysis platform. > > The core idea is quite simple: build custom analysis tools to analyze the contextual complexity of your software systems so that you can make better decisions. By decisions I mean anything that has to do with the system: it can be technical (such as, is this concept well encapsulated?, or is my component used the right way?), or it can be broad and strategic (such as, should I refactor my system?). > > To make it practical we need to be able to craft tools (sometimes complex tools) fast. This is made feasible by Moose, and in turn, Moose achieves this because of Smalltalk. > > The method also covers process and organization-related problems. If you wish, humane assessment is the coat that can place Moose and Smalltalk within any development team. > > If you want to promote Smalltalk, perhaps you might want to use this path. > > I would be happy to provide more information, support and even materials. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > >

June 20, 2011

Re: [Pharo-project] [ANN] humane-assessment.com

by Alexandre Bergel

I like the animation: http://bit.ly/mDsNRV Alexandre On 20 Jun 2011, at 10:24, Tudor Girba wrote: > Hi, > > I am happy to announce the new home for humane assessment: > http://humane-assessment.com > > Humane assessment is a new software engineering method for making the assessment of software systems practical and manageable. This is made possible by the Moose analysis platform. > > The core idea is quite simple: build custom analysis tools to analyze the contextual complexity of your software systems so that you can make better decisions. By decisions I mean anything that has to do with the system: it can be technical (such as, is this concept well encapsulated?, or is my component used the right way?), or it can be broad and strategic (such as, should I refactor my system?). > > To make it practical we need to be able to craft tools (sometimes complex tools) fast. This is made feasible by Moose, and in turn, Moose achieves this because of Smalltalk. > > The method also covers process and organization-related problems. If you wish, humane assessment is the coat that can place Moose and Smalltalk within any development team. > > If you want to promote Smalltalk, perhaps you might want to use this path. > > I would be happy to provide more information, support and even materials. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 20, 2011

Re: [Pharo-project] About not using full Pharo

by Douglas Brebner

On 20/06/2011 15:09, Torsten Bergmann wrote: > It's hard to work on core without good tools and this will > become more painfull the more we strip down core in the future. > > But we all agreed that we need a stable core to build on > top of it because there are also people who just require > a core Smalltalk and not a full developer IDE or people > who have their own IDE setup or want to do experiments. > > There is only one solution to this: > - repackage and introduce clean dependencies between > the packages > Or use something like Craigs Spoon to use the tools in one image to build a second customised image.

June 20, 2011

[Pharo-project] [ANN] humane-assessment.com

by Tudor Girba

Hi, I am happy to announce the new home for humane assessment: http://humane-assessment.com Humane assessment is a new software engineering method for making the assessment of software systems practical and manageable. This is made possible by the Moose analysis platform. The core idea is quite simple: build custom analysis tools to analyze the contextual complexity of your software systems so that you can make better decisions. By decisions I mean anything that has to do with the system: it can be technical (such as, is this concept well encapsulated?, or is my component used the right way?), or it can be broad and strategic (such as, should I refactor my system?). To make it practical we need to be able to craft tools (sometimes complex tools) fast. This is made feasible by Moose, and in turn, Moose achieves this because of Smalltalk. The method also covers process and organization-related problems. If you wish, humane assessment is the coat that can place Moose and Smalltalk within any development team. If you want to promote Smalltalk, perhaps you might want to use this path. I would be happy to provide more information, support and even materials. Cheers, Doru -- www.tudorgirba.com "Be rather willing to give than demanding to get."

June 20, 2011

[Pharo-project] About not using full Pharo

by Torsten Bergmann

It's hard to work on core without good tools and this will become more painfull the more we strip down core in the future. But we all agreed that we need a stable core to build on top of it because there are also people who just require a core Smalltalk and not a full developer IDE or people who have their own IDE setup or want to do experiments. There is only one solution to this: - repackage and introduce clean dependencies between the packages If this is done it is much easier - to build a dev on top of core by loading - to build a core by stripping a dev - to build a kernel from core - to have a custom image with the packages you need And once we have done it we can extend our toolset not only to build and test packages but also to check validness and quality. My 0.02â¬ T. -- NEU: FreePhone - kostenlos mobil telefonieren! Jetzt informieren: http://www.gmx.net/de/go/freephone

June 20, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Mariano Martinez Peck

One thing I do not see mentioned, and feel could use some attention, is thread safety. (aka other threads altering the graph you are serializing) > The classic answer would of course be "always run FUEL at highest > priority", but if we ever want to move to true multi-core, that's not > enough. > > Wow. Were you reading our minds?? hehehe. Yes, reading some of the related work papers while writing our own paper, we read about the "atomicy". How to be atomic while analyzing and serializing? Right now, if the graph changes between the first phase (analysis) and the second phase (serializating) you are screw :) I wonder if Eliot fixed that in Parcels? What would be neat is protecting all mutation of objects in the graph with a > Mutex/Monitor whose critical section covers the analysis and serialization, > i.e. blocking all other processes that wants to mutate objects in the graph > untill serialization is complete. > > yes, > Aside from the behaviour when a marked object is encountered, the process > is the same as for immutability, as discussed here: > http://forum.world.st/**immutability-and-become-Was-** > Re-squeak-dev-immutability-**td1597511.html<http://forum.world.st/immutability-and-become-Was-Re-squeak-dev-immutabilit…> > > You could do this image-side as part of the analyze phase, as Eliot's post > suggests, Ok, but in order to do I need the immutable bit in the ObjectHeader, right? > but it's not entirely safe when: > A child -> B > B parent -> A > > 1 . Process1 protects A with Mutex > 2. Process2 calls method on B which does: > a) B parent: C > b) (B's tmpRef to A) child: somethingElse *Wait for Mutex* > 3. Process 1 makes B, C immutable, serializes B with C as parent. > 4. Process2 changes A child. > > It could of course be argued that is a programming/logic error to update B > parent ref before child ref in A, (you'd actually have to do extra work to > get that order), still it's a hard one to debug if it does happen. > (Note to the thread: Following the same logic, I would also say it should > be considered an error to keep a mutable cache as part of an immutable > object :) ) > > In fact, you *could* implement it with immutability, injecting handler > contexts with behaviour as described above into existing/new processes for > any resulting immutability errors. > > wow. Seems a really complicated stuff to deal with :( Immutability is not yet present in default VMs -- Mariano http://marianopeck.wordpress.com

June 20, 2011