- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] List editor spec widget

by Christophe Demarey

Hello Did you check EditableList? Le 20 mars 2014 Ã 18:20, Benjamin a Ã©crit : > On 20 Mar 2014, at 18:13, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> 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) > > Sorry I do not understand your question :) > But I think the answer is > Make a complete new widget, with one list and two buttons, and enough methods > to tweak the buttons and the list :) > > You could even have a dedicated widget for the buttons, so one can replace them with a special new âbuttons toolbarâ widget > > Hope it helps, > Ben

March 20, 2014

Re: [Pharo-dev] List editor spec widget

by Yuriy Tymchuk

On 20 Mar 2014, at 18:20, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On 20 Mar 2014, at 18:13, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> 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) > > Sorry I do not understand your question :) > But I think the answer is > Make a complete new widget, with one list and two buttons, and enough methods > to tweak the buttons and the list :) > > You could even have a dedicated widget for the buttons, so one can replace them with a special new âbuttons toolbarâ widget Thanks Ben, Iâll try to do something tomorrow and share with you, to get some feedback. We will do something cool :). P.S. The thing that I was asking, is that as this widget will have a list inside, it will be probably useful to have all the list api there. And I donât think that duplicating all the methods and forwarding them to list will be good. > > Hope it helps, > Ben

March 20, 2014

[pharo-project/pharo-core] b19759: 30799

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: b197590350c1c7da5d6fdaf181ff7cdc9e8be4e6 https://github.com/pharo-project/pharo-core/commit/b197590350c1c7da5d6fdaf1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-03-20 (Thu, 20 Mar 2014) Changed paths: M Morphic-Base.package/MorphTreeListManager.class/instance/keyboard managing/arrowEvent_key_.st A Morphic-Base.package/MorphTreeModel.class/instance/keyboard managing/arrowEvent_key_target_.st A Nautilus.package/NautilusUI.class/instance/debugging actions/buildTestSuiteFor_.st A Nautilus.package/NautilusUI.class/instance/debugging actions/debugTest.st A Nautilus.package/NautilusUI.class/instance/debugging actions/debugTest_.st R Nautilus.package/NautilusUI.class/instance/system announcements/buildTestSuiteFor_.st R Nautilus.package/NautilusUI.class/instance/system announcements/debugTest.st R Nautilus.package/NautilusUI.class/instance/system announcements/debugTest_.st A Nautilus.package/PackageTreeModel.class/instance/keyboard managing/arrowEvent_key_target_.st A Nautilus.package/PackageTreeNautilusUI.class/instance/events handling/keyPressedOnList_shifted_.st A Nautilus.package/PackageTreeNautilusUI.class/instance/events handling/keyPressedOnTree_target_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/private/updateBothView.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script452.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30799.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Inspector.package/EyeTreeInspector.class/instance/api/expandRoots.st A Spec-Inspector.package/EyeTreeInspector.class/instance/event-handling/ownerChanged.st M Spec-Inspector.package/InspectorNavigator.class/instance/accessing/inspectorType_.st Log Message: ----------- 30799 13091 EyeInspector switching should preserve text area contents https://pharo.fogbugz.com/f/cases/13091 13100 right arrow in package tree on nautilus should select next panel https://pharo.fogbugz.com/f/cases/13100 13090 EyeTreeInspector should open with one level expanded https://pharo.fogbugz.com/f/cases/13090 13099 nautilus is not refreshing package tree panel on certain operations https://pharo.fogbugz.com/f/cases/13099 http://files.pharo.org/image/30/30799.zip

March 20, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30799 Home: https://github.com/pharo-project/pharo-core

March 20, 2014

Re: [Pharo-dev] List editor spec widget

by Benjamin

On 20 Mar 2014, at 18:13, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > 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) Sorry I do not understand your question :) But I think the answer is Make a complete new widget, with one list and two buttons, and enough methods to tweak the buttons and the list :) You could even have a dedicated widget for the buttons, so one can replace them with a special new âbuttons toolbarâ widget Hope it helps, Ben

March 20, 2014

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