March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] List editor spec widget

by Yuriy Tymchuk

On 16 Mar 2014, at 00:37, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > On 15 Mar 2014, at 22:39, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Hi everyone. >> >> I wander if there is already something like the list editing buttons in OS X i.e. â+â and â-â buttons that either open a dialog with another list that allows to select what to add, or remove selected items from the list. (example on screenshot). > > I would answer ânot yetâ :) > > Feel free to submit one :P > If you have questions, I will be glad to answer them, and to help you to propose such a widget, Ok, now Iâm more confident with spec, so I have a couple of questions: Should this be an extension of List with buttons, of a buttons widget that has a setters for the list to modify and the block for retrieving the rest of items (during the addition action) Cheers. Uko > reusable enough so we can add it to the spec widgets :) > > Ben >

March 20, 2014

Morph class announcer. Huh?

by Igor Stasenko

Morph class instanceVariableNames: 'announcer' announcer ^ announcer ifNil: [ announcer := Announcer new ]. say whaaaat? -- Best regards, Igor Stasenko.

March 20, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Igor Stasenko

On 20 March 2014 17:04, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> Hi Eliot, >> >> Le 19 mars 2014 Ã 16:25, Eliot Miranda a Ã©crit : >> >> Hi Christophe, >> >> On Mar 19, 2014, at 1:45 AM, Christophe Demarey < >> Christophe.Demarey(a)inria.fr> wrote: >> >> >> Le 18 mars 2014 Ã 19:50, Eliot Miranda a Ã©crit : >> >> On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < >> Christophe.Demarey(a)inria.fr> wrote: >> >>> Why arguments should be read only? >>> They are just temporary variables with an initial value. >>> >> >> Read the blue book. It was a decision of the language designers to >> forbid assignment to arguments to allow debugging. The assignment to block >> arguments is a side-effect of the old BlockContext implementation of blocks >> where block arguments were mapped onto temporary variables of the home >> context. It is an anachronism and should be forbidden also. >> >> >> Thank you for the explanation. >> I'm just curious why it is so difficult to implement a debugger if >> arguments are assignable? >> If you need to restart the execution of a method, and so you need to get >> the initial value of the argument, I understand you cannot find the value >> anymore in the method context but it is available in the caller context, no? >> As I never implemented a debugger, I cannot figure out the difficulties. >> >> >> the args are no longer available; they get moved from the caller context >> to the callee. If you think about stack frames then what happens is that >> the slots containing the outgoing arguments are used as the slots for the incoming >> arguments. So if arguments are assigned to they are indeed lost. >> >> >> ok, I understand. Thank you for the explanation. >> >> >> But look at how many methods in the system (or in any system). The >> proportion of methods/functions/procedures that could be written to assign >> their arguments is very small so the Smalltalk trade off is a good one. >> >> >> I agree we don't really loose something. You can always assign arguments >> to temporary variables and update temporary variables. My point was just: >> if possible, why don't do it? >> > > It's that tricky trade-off between value and cost. Is it worth it? Does > doing it provide as much value as doing what it displaces (opportunity > cost). IMO it simply doesn't provide enough value, and there are different > priorities in the compiler. But if you disagree implement it your self and > then it'll be done. > > self := super agreed. > -- > best, > Eliot > -- Best regards, Igor Stasenko.

March 20, 2014

CFP: COP Workshop at ECOOP'14

by Marcus Denker

[Please accept our apologies if you receive multiple copies of this call] ========================================================================= Call for Papers COP'14 Sixth International Workshop on Context-Oriented Programming Worokshop in conjunction with ECOOP 2014 Uppsala, Sweden, 29 July, 2014 http://prg.is.titech.ac.jp/events/cop14/ Overview -------- Context information plays an increasingly important role in our information-centric world. Software systems must adapt to changing contexts over time and must change even while they are running. Unfortunately, mainstream programming languages and development environments do not support this kind of dynamic change very well, leading developers to implementing complex designs to anticipate various dimensions of variability. Starting from this observation, Context-Oriented Programming (COP) has emerged as a solution to directly support variability depending on a wide range of dynamic attributes, making it possible to dispatch run-time behavior on any property of the execution context. The goal of the 6th Workshop on Context-Oriented Programming (COP-14) is to further establish context orientation as a common thread to language design, application development, and system support. Topics of interest include but are not limited to: - Interesting application domains and scenarios - Programming language abstractions - Theoretical foundations - Configuration languages transformational approaches - Interaction between non-functional programming concerns and COP - Modularization approaches plugins - Programming guidelines and best practices - Runtime support - Tooling Important dates --------------- * Abstract submission: May 30, 2014 * Paper submission: June 6, 2014 * Notification: June 19, 2014 * Camera ready: June 27, 2014 * Workshop: July 29, 2014 Submission guidelines --------------------- COP-14 invites submissions of high-quality papers reporting original research, or describing innovative contributions to, or experience with COP, its implementation, and application. Papers that depart significantly from established ideas and practices are particularly welcome. Submissions must not have been published previously and must not be under review for any another refereed event or publication. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. It is planned to publish accepted papers in the ACM Digital Library, unless the authors choose not to. In case of publication in the ACM Digital Library, authors must transfer copyright to ACM upon acceptance (for government work, to the extent transferable), but retain various rights (see ACM Copyright Policy. Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Papers should be submitted electronically via EasyChair (https://www.easychair.org/conferences/?conf=cop14) in PDF format. Submissions must be written in English (the official language of the workshop) and must not exceed 6 pages. They should use the ACM SIGPLAN 10 point format, templates for which are available at http://www.acm.org/sigs/sigplan/authorInformation.htm Programming Committee ---------------------------------------- Tomoyuki Aotani, Tokyo Institute of Technology, Japan, chair Shigeru Chiba, The University of Tokyo, Japan Dave Clarke, Uppsala University, Sweden and KU Leuven, Belgium Marcus Denker, INRIA, France Richard P. Gabriel, IBM, United States SebastiÃ¡n GonzÃ¡lez, UC Louvain, Belgium Robert Hirschfeld, Hasso-Plattner-Institut Potsdam, Germany Tetsuo Kamina, The University of Tokyo, Japan Jens Lincke, Hasso-Plattner-Institut Potsdam, Germany Friedrich Steimann, FernuniversitÃ¤t in Hagen, Germany Eddy Truyen, K.U. Leuven, Belgium Organizing Committee -------------------- Tomoyuki Aotani, Tokyo Institute of Technology, Japan (primary organizer) Malte Appeltauer, SAP Innovation Center Potsdam, Germany Robert Hirschfeld, Hasso-Plattner-Institut Potsdam, Germany Atsushi Igarashi, Kyoto University, Japan Hidehiko Masuhara, Tokyo Institute of Technology, Japan

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Johan Brichau

Found it: Magritte3 references Grease1.1.5 explicitly MongoTalk references Grease #stable Looks more like a Metacello bug to me... there clearly is a load conflict and Metacello should decide on a version rather than load them both sequentially. But I have not looked any deeper.... Johan On 20 Mar 2014, at 17:02, Johan Brichau <johan(a)inceptive.be> wrote: > I can reproduce the problem. > For some strange reason, first Grease 1.1.5 is loaded and then 1.1.6 is loaded (in the same metacello load of VoyageMongo). > > The package becomes dirty because some classes changed from the Pharo20 package in 1.1.5 to the Core package in 1.1.6. > Because Metacello first loads the Core package, the Pharo20 package becomes dirty. When the new version of the Pharo20 package is loaded, Monticello raises the warning. > > I have noticed a similar issue when upgrading versions of Zinc in Pharo1.4 because significant package refactorings occurred. > So, this is nothing specific to Grease / Magritte / Seaside / ... > > I wonder if this can be simply fixed by changing the load type to #atomic. At least, that is how I fix those issues when loading Yesplan in Gemstone. > But clean builds work perfectly. And I would want to know why first version 1.1.5 is loaded in this load process. > > Johan > > On 20 Mar 2014, at 16:39, Johan Brichau <johan(a)inceptive.be> wrote: > >> Norbert, >> >> From your screenshot, I see that the Grease package you have loaded in your image is dirty. It is also the package version that gets loaded with Grease 1.1.5. >> My first question is: why is it dirty? Can you check that? >> >> The package version you are loading is the one that is referenced by Grease 1.1.6 >> >> I just tagged Grease 1.1.6 as #stable yesterday. So that probably triggers this. >> >> Though I cannot see any reason why this occurs and Seaside 3.1 is loading well here. >> >> Johan >> >> On 20 Mar 2014, at 15:47, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> I encountered a strange problem while loading voyage. It seems the configuration for magritte or grease is strange. If I load voyage from the configuration browser I get the following screen >>> >>> <Bildschirmfoto 2014-03-20 um 15.43.56.png> >>> >>> Any ideas? >>> >>> Norbert >>> >> >

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Norbert Hartl

Ok, I can load my own project now when I exchange the grease reference from 1.1.5 to stable. After a hint from Stephan Eggermont I changed the mongotalk build to include the right repo for grease. So this mismatch should have been gone. While Iâm able to build my own project I still cannot load voyage in a fresh 2.0 image. Norbert Am 20.03.2014 um 16:39 schrieb Johan Brichau <johan(a)inceptive.be>: > Norbert, > > From your screenshot, I see that the Grease package you have loaded in your image is dirty. It is also the package version that gets loaded with Grease 1.1.5. > My first question is: why is it dirty? Can you check that? > > The package version you are loading is the one that is referenced by Grease 1.1.6 > > I just tagged Grease 1.1.6 as #stable yesterday. So that probably triggers this. > > Though I cannot see any reason why this occurs and Seaside 3.1 is loading well here. > > Johan > > On 20 Mar 2014, at 15:47, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I encountered a strange problem while loading voyage. It seems the configuration for magritte or grease is strange. If I load voyage from the configuration browser I get the following screen >> >> <Bildschirmfoto 2014-03-20 um 15.43.56.png> >> >> Any ideas? >> >> Norbert >>

March 20, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Eliot Miranda

On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi Eliot, > > Le 19 mars 2014 Ã 16:25, Eliot Miranda a Ã©crit : > > Hi Christophe, > > On Mar 19, 2014, at 1:45 AM, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > > > Le 18 mars 2014 Ã 19:50, Eliot Miranda a Ã©crit : > > On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> Why arguments should be read only? >> They are just temporary variables with an initial value. >> > > Read the blue book. It was a decision of the language designers to forbid > assignment to arguments to allow debugging. The assignment to block > arguments is a side-effect of the old BlockContext implementation of blocks > where block arguments were mapped onto temporary variables of the home > context. It is an anachronism and should be forbidden also. > > > Thank you for the explanation. > I'm just curious why it is so difficult to implement a debugger if > arguments are assignable? > If you need to restart the execution of a method, and so you need to get > the initial value of the argument, I understand you cannot find the value > anymore in the method context but it is available in the caller context, no? > As I never implemented a debugger, I cannot figure out the difficulties. > > > the args are no longer available; they get moved from the caller context > to the callee. If you think about stack frames then what happens is that > the slots containing the outgoing arguments are used as the slots for the incoming > arguments. So if arguments are assigned to they are indeed lost. > > > ok, I understand. Thank you for the explanation. > > > But look at how many methods in the system (or in any system). The > proportion of methods/functions/procedures that could be written to assign > their arguments is very small so the Smalltalk trade off is a good one. > > > I agree we don't really loose something. You can always assign arguments > to temporary variables and update temporary variables. My point was just: > if possible, why don't do it? > It's that tricky trade-off between value and cost. Is it worth it? Does doing it provide as much value as doing what it displaces (opportunity cost). IMO it simply doesn't provide enough value, and there are different priorities in the compiler. But if you disagree implement it your self and then it'll be done. -- best, Eliot

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Johan Brichau

I can reproduce the problem. For some strange reason, first Grease 1.1.5 is loaded and then 1.1.6 is loaded (in the same metacello load of VoyageMongo). The package becomes dirty because some classes changed from the Pharo20 package in 1.1.5 to the Core package in 1.1.6. Because Metacello first loads the Core package, the Pharo20 package becomes dirty. When the new version of the Pharo20 package is loaded, Monticello raises the warning. I have noticed a similar issue when upgrading versions of Zinc in Pharo1.4 because significant package refactorings occurred. So, this is nothing specific to Grease / Magritte / Seaside / ... I wonder if this can be simply fixed by changing the load type to #atomic. At least, that is how I fix those issues when loading Yesplan in Gemstone. But clean builds work perfectly. And I would want to know why first version 1.1.5 is loaded in this load process. Johan On 20 Mar 2014, at 16:39, Johan Brichau <johan(a)inceptive.be> wrote: > Norbert, > > From your screenshot, I see that the Grease package you have loaded in your image is dirty. It is also the package version that gets loaded with Grease 1.1.5. > My first question is: why is it dirty? Can you check that? > > The package version you are loading is the one that is referenced by Grease 1.1.6 > > I just tagged Grease 1.1.6 as #stable yesterday. So that probably triggers this. > > Though I cannot see any reason why this occurs and Seaside 3.1 is loading well here. > > Johan > > On 20 Mar 2014, at 15:47, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I encountered a strange problem while loading voyage. It seems the configuration for magritte or grease is strange. If I load voyage from the configuration browser I get the following screen >> >> <Bildschirmfoto 2014-03-20 um 15.43.56.png> >> >> Any ideas? >> >> Norbert >> >

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Norbert Hartl

Am 20.03.2014 um 16:39 schrieb Johan Brichau <johan(a)inceptive.be>: > Norbert, > > From your screenshot, I see that the Grease package you have loaded in your image is dirty. It is also the package version that gets loaded with Grease 1.1.5. > My first question is: why is it dirty? Can you check that? > > The package version you are loading is the one that is referenced by Grease 1.1.6 > > I just tagged Grease 1.1.6 as #stable yesterday. So that probably triggers this. > > Though I cannot see any reason why this occurs and Seaside 3.1 is loading well here. > Me neither. The screenshot is from a an image that I downloaded freshly and used the configuration browser to initiate the load. I can see a reference to 1.1.5 grease as well but Iâm not sure where this comes from. Every configuration involved just references grease #stable. Norbert > Johan > > On 20 Mar 2014, at 15:47, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I encountered a strange problem while loading voyage. It seems the configuration for magritte or grease is strange. If I load voyage from the configuration browser I get the following screen >> >> <Bildschirmfoto 2014-03-20 um 15.43.56.png> >> >> Any ideas? >> >> Norbert >>

March 20, 2014

Re: [Pharo-dev] Voyage cannot be load

by Johan Brichau

Norbert, >From your screenshot, I see that the Grease package you have loaded in your image is dirty. It is also the package version that gets loaded with Grease 1.1.5. My first question is: why is it dirty? Can you check that? The package version you are loading is the one that is referenced by Grease 1.1.6 I just tagged Grease 1.1.6 as #stable yesterday. So that probably triggers this. Though I cannot see any reason why this occurs and Seaside 3.1 is loading well here. Johan On 20 Mar 2014, at 15:47, Norbert Hartl <norbert(a)hartl.name> wrote: > I encountered a strange problem while loading voyage. It seems the configuration for magritte or grease is strange. If I load voyage from the configuration browser I get the following screen > > <Bildschirmfoto 2014-03-20 um 15.43.56.png> > > Any ideas? > > Norbert >

March 20, 2014