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

Re: [Pharo-project] Metacello bleedingEdge question

by StÃ©phane Ducasse

sven christophe is restarting to work on versioner and we hope to get a first version out. The idea is that versioner should help people producing and managing configurations Stef > Hi Dale, > > Thanks a lot for the quick and helpful reply. > > Adding > > spec blessing: #release > > to all explicit versions did indeed do the trick. > > Now I have to update all my configs ;-) > > I have still much to learn. > > Thx again, > > Sven > > On 27 Sep 2012, at 18:46, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> Sven, >> >> The versions in ConfigurationOfZTimestamp aren't quite defined correctly ... bleedingEdge defaults to loading the latest baseline version. A baseline version is declared by setting the blessing to #baseline: >> >> spec blessing: #baseline. >> >> Your versions in ConfigurationOfZTimestamp are importing from the '1-baseline' but are not changing the blessing, so Metacello doesn't know that 1, 2, and 3 are literal versions and not baselines. So version 3 looks like the "latest baseline version".. >> >> To fix, this remember to set the blessing in your literal version specifications setting the blessing to something other that #baseline like #development: >> >> spec blessing: #development. >> >> while the version is under development or #release: >> >> spec blessing: #release. >> >> when the version is released (i.e., you will not be changing it any more). >> >> Dale >> >> ----- Original Message ----- >> | From: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> | To: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> >> | Sent: Thursday, September 27, 2012 8:31:47 AM >> | Subject: [Pharo-project] Metacello bleedingEdge question >> | >> | Hi, >> | >> | I have a question. >> | >> | The following works as expected and loads the latest versions of the >> | code: >> | >> | ConfigurationOfZincHTTPComponents project bleedingEdge load. >> | >> | The following does not and keeps loading only the #stable one and not >> | the latest one. >> | >> | ConfigurationOfZTimestamp project bleedingEdge load. >> | >> | I can't see any difference, but I am a Metacello newbie. >> | >> | Has anyone any idea where I should look ? >> | >> | Thx, >> | >> | Sven >> | >> | -- >> | Sven Van Caekenberghe >> | http://stfx.eu >> | Smalltalk is the Red Pill >> > >

Sept. 27, 2012

Re: [Pharo-project] Metacello bleedingEdge question

by Sven Van Caekenberghe

Hi Dale, Thanks a lot for the quick and helpful reply. Adding spec blessing: #release to all explicit versions did indeed do the trick. Now I have to update all my configs ;-) I have still much to learn. Thx again, Sven On 27 Sep 2012, at 18:46, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Sven, > > The versions in ConfigurationOfZTimestamp aren't quite defined correctly ... bleedingEdge defaults to loading the latest baseline version. A baseline version is declared by setting the blessing to #baseline: > > spec blessing: #baseline. > > Your versions in ConfigurationOfZTimestamp are importing from the '1-baseline' but are not changing the blessing, so Metacello doesn't know that 1, 2, and 3 are literal versions and not baselines. So version 3 looks like the "latest baseline version".. > > To fix, this remember to set the blessing in your literal version specifications setting the blessing to something other that #baseline like #development: > > spec blessing: #development. > > while the version is under development or #release: > > spec blessing: #release. > > when the version is released (i.e., you will not be changing it any more). > > Dale > > ----- Original Message ----- > | From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > | To: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> > | Sent: Thursday, September 27, 2012 8:31:47 AM > | Subject: [Pharo-project] Metacello bleedingEdge question > | > | Hi, > | > | I have a question. > | > | The following works as expected and loads the latest versions of the > | code: > | > | ConfigurationOfZincHTTPComponents project bleedingEdge load. > | > | The following does not and keeps loading only the #stable one and not > | the latest one. > | > | ConfigurationOfZTimestamp project bleedingEdge load. > | > | I can't see any difference, but I am a Metacello newbie. > | > | Has anyone any idea where I should look ? > | > | Thx, > | > | Sven > | > | -- > | Sven Van Caekenberghe > | http://stfx.eu > | Smalltalk is the Red Pill >

Sept. 27, 2012

Re: [Pharo-project] Metacello bleedingEdge question

by Dale Henrichs

Sven, The versions in ConfigurationOfZTimestamp aren't quite defined correctly ... bleedingEdge defaults to loading the latest baseline version. A baseline version is declared by setting the blessing to #baseline: spec blessing: #baseline. Your versions in ConfigurationOfZTimestamp are importing from the '1-baseline' but are not changing the blessing, so Metacello doesn't know that 1, 2, and 3 are literal versions and not baselines. So version 3 looks like the "latest baseline version".. To fix, this remember to set the blessing in your literal version specifications setting the blessing to something other that #baseline like #development: spec blessing: #development. while the version is under development or #release: spec blessing: #release. when the version is released (i.e., you will not be changing it any more). Dale ----- Original Message ----- | From: "Sven Van Caekenberghe" <sven(a)stfx.eu> | To: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Thursday, September 27, 2012 8:31:47 AM | Subject: [Pharo-project] Metacello bleedingEdge question | | Hi, | | I have a question. | | The following works as expected and loads the latest versions of the | code: | | ConfigurationOfZincHTTPComponents project bleedingEdge load. | | The following does not and keeps loading only the #stable one and not | the latest one. | | ConfigurationOfZTimestamp project bleedingEdge load. | | I can't see any difference, but I am a Metacello newbie. | | Has anyone any idea where I should look ? | | Thx, | | Sven | | -- | Sven Van Caekenberghe | http://stfx.eu | Smalltalk is the Red Pill | | | | |

Sept. 27, 2012

[Pharo-project] Metacello bleedingEdge question

by Sven Van Caekenberghe

Hi, I have a question. The following works as expected and loads the latest versions of the code: ConfigurationOfZincHTTPComponents project bleedingEdge load. The following does not and keeps loading only the #stable one and not the latest one. ConfigurationOfZTimestamp project bleedingEdge load. I can't see any difference, but I am a Metacello newbie. Has anyone any idea where I should look ? Thx, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 27, 2012

Re: [Pharo-project] Roassal Survey

by Ben Coman

Ciprian Teodorov wrote: > Another feature that I think it is missing in most (if not all) graph > viewers/layout systems/editors is the possibility to have connection ports > on the hierarchical nodes in order to preserve the connections passing > through the hierarchy. > > some pointers: > > http://www.slideshare.net/teodorov/tools-and-crossbarbased-nanocmos-archite… > > http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf > > > Cheers, > > Ciprian Teodorov > > > On Sep 26, 2012 6:16 PM, "Vanessa PeÃ±a Araya" <van.c.pena(a)gmail.com> wrote: > > Ciprian, I have skimmed through those links but can't quite understand your comment "in order to preserve the connections passing through the hierarchy" Can you expand some more on that - perhaps with a mock up in a paint program? If you are interested in following the development of Roassal, perhaps move your follow up to https://www.iam.unibe.ch/mailman/listinfo/moose-dev. <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> I have been very encouraged by the clean architecture and the responsiveness of the main developers to feature suggestions. cheers, Ben

Sept. 27, 2012

Re: [Pharo-project] Learnable Programming

by Fernando Olivero

AWESOME! its nice to hear that most of the ideas in Dan's article from the 81: Design principles behind Smalltalk [1], finally made it elsewhere. The first paragraph resembles the first part of the article. Goubier: Athens needs Cairo, which needs NB. Cairo can be compiled for 32/64 bits, i belive Igor ships VMs with Cairo built as an universal library. NB, works for 32 and 64 bits (i've believe Camilo was working on this). The problem is the Cog VM, its only 32 bits. Fernando [1]http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html On Thu, Sep 27, 2012 at 10:12 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > It's a bit out of subject, but does Athens works on a Linux 64bits system ? > > Thierry > > Le 27/09/2012 09:59, StÃ©phane Ducasse a Ã©crit : >> Indeed the key point for our community is how can we create the infrastructure to >> be able to provide nice output and interactive. >> >> This is why Athens needs clients. >> Now if nobody cares about Athens then it will get out slower than we want. >> >> Beside the text everything else is working. >> I'm trying to understand how I can help igor and one task is to convert the current morph drawOn: on athensDrawOn: method. >> I will keep the examples we will produce once I will sit with igor. >> >> Stef >> >> >> On Sep 27, 2012, at 9:22 AM, Goubier Thierry wrote: >> >>> Cool! >>> >>> There are some very nice program flow representations in them. I'll have a look if I can display Jejak traces that way, and maybe explore the use of Roassal for this. >>> >>> Thierry >>> >>> Le 26/09/2012 21:59, Sven Van Caekenberghe a Ã©crit : >>>> This is _very_ interesting and _very_ welll presented: >>>> >>>> http://worrydream.com/LearnableProgramming/ >>>> >>>> Keep on reading, it keeps on getting better towards the end. >>>> >>>> Sven >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> http://stfx.eu >>>> Smalltalk is the Red Pill >>>> >>>> >>>> >>> >>> >>> -- >>> 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 >>> >> >> >> >> > > > -- > 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 >

Sept. 27, 2012

Re: [Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window

by Fernando Olivero

thanks for the info igor. maybe we could plug customized UI handlers for different devices, with different "raw" events. It would make coding and managing each of them, a lot simpler than now. Fernando On Wed, Sep 26, 2012 at 2:14 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 September 2012 13:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Igor, i agree 100% percent with you! >> >> VM shouldn't have all the responsibility of handling a "single UI window". >> >> I've tried in the past to look at VM code, which handles this >> responsibility and change it, (no UI handling in the VM) ..but it >> proved to be a difficult task! We need a simpler, >> cleaner VM, pluggable UI handling would be awesome!. >> >> Do we need the pointer or Null at all in the VM? Cant the io handling >> be done completely separate from the VM? A native app for each >> platform, or something built using NB. >> > > This is highly platform-specific. > The ioProcessEvents called by VM during interrupt , so, > platform-specific code can > use it to signal any pending external events. > Interrupts is also used by scheduler to switch to another process when > something happens (like socket has new data to read, semaphore > signaled etc). > So, if VM won't support interrupts it will be highly problematic to > support green threading execution model. > And, of course, an interrupt is naturally a well-defined safe point in > VM execution. > So it is logical to have an entry point there, where plugin(s) can > hook-in and add own custom event handling procedure, > without need for patching a single global ioProcessEvents() function > over and over again. > > If at some point you'll have two independent modules (plugins) in VM > which want to put own custom handling code there, > you can always do it like following pseudocode: > > (during plugin initialization) > oldHandler := ioProcessEvents. > ioProcessEvents := &myHandler. > > (during call ) > myHandler > self doMyHandling. > call oldHandler > > > Now, of course it is a question, how often you may need that: a module > which adds own custom handler for VM interrupt. > Maybe we don't need that much flexibility? But do others see other way > of freeing VM from assumptions and tight coupling with > different parts of system? > > -- > Best regards, > Igor Stasenko.

Sept. 27, 2012

Re: [Pharo-project] Learnable Programming

by Goubier Thierry

It's a bit out of subject, but does Athens works on a Linux 64bits system ? Thierry Le 27/09/2012 09:59, StÃ©phane Ducasse a Ã©crit : > Indeed the key point for our community is how can we create the infrastructure to > be able to provide nice output and interactive. > > This is why Athens needs clients. > Now if nobody cares about Athens then it will get out slower than we want. > > Beside the text everything else is working. > I'm trying to understand how I can help igor and one task is to convert the current morph drawOn: on athensDrawOn: method. > I will keep the examples we will produce once I will sit with igor. > > Stef > > > On Sep 27, 2012, at 9:22 AM, Goubier Thierry wrote: > >> Cool! >> >> There are some very nice program flow representations in them. I'll have a look if I can display Jejak traces that way, and maybe explore the use of Roassal for this. >> >> Thierry >> >> Le 26/09/2012 21:59, Sven Van Caekenberghe a Ã©crit : >>> This is _very_ interesting and _very_ welll presented: >>> >>> http://worrydream.com/LearnableProgramming/ >>> >>> Keep on reading, it keeps on getting better towards the end. >>> >>> Sven >>> >>> -- >>> Sven Van Caekenberghe >>> http://stfx.eu >>> Smalltalk is the Red Pill >>> >>> >>> >> >> >> -- >> 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 >> > > > > -- 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

Sept. 27, 2012

Re: [Pharo-project] Learnable Programming

by StÃ©phane Ducasse

Indeed the key point for our community is how can we create the infrastructure to be able to provide nice output and interactive. This is why Athens needs clients. Now if nobody cares about Athens then it will get out slower than we want. Beside the text everything else is working. I'm trying to understand how I can help igor and one task is to convert the current morph drawOn: on athensDrawOn: method. I will keep the examples we will produce once I will sit with igor. Stef On Sep 27, 2012, at 9:22 AM, Goubier Thierry wrote: > Cool! > > There are some very nice program flow representations in them. I'll have a look if I can display Jejak traces that way, and maybe explore the use of Roassal for this. > > Thierry > > Le 26/09/2012 21:59, Sven Van Caekenberghe a Ã©crit : >> This is _very_ interesting and _very_ welll presented: >> >> http://worrydream.com/LearnableProgramming/ >> >> Keep on reading, it keeps on getting better towards the end. >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> > > > -- > 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 >

Sept. 27, 2012

[Pharo-project] Welcome to newcomers

by StÃ©phane Ducasse

Hi guys Since there are regularly new comers, here is a little ad-hoc welcome message :). First: Welcome! welcome and welcome Second: our goal is to create an ecosystem around pharo: if you need material to teach, if you have idea or needs for business or anything else just let us know. Our goal is to be able to reinvent our system and at the same time make sure that we can all create wealth at all levels. Third: we are working hard to get our vision: a nice, little and powerful reflective system. If you want to understand what we are doing please read the document Pharo vision on http://www.pharo-project.org/community/consortium You will understand our current effort. Four: you can get an impact on Pharo :) There are a lot of different ways to contribute. - feedback - bugs idea for enhancements see http://code.google.com/p/pharo/issues/list - book participation (we are working on deep into pharo http://rmod.lille.inria.fr/pbe2/ - translation - adding comments - building great stuff - using packagesâ¦. So welcome. Stef PS: Pharo is not the end, Pharo is the mean to create a powerful clean, lean system with a great community.

Sept. 27, 2012