February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ||

by Stephan Eggermont

On 05/02/15 16:52, Frank Shearar wrote: > On 5 February 2015 at 15:35, Levente Uzonyi <leves(a)elte.hu> wrote: >> Rebuilding the whole AST after every keystroke is possible, but keeping it >> real-time is a bit challenging. >> >> I would love to see an editor, which works on the AST directly - aka it maps >> the source code to AST nodes, and just updates the smallest possible subtree >> at each keystroke. Implementing such editor has it's challenges ofc, like >> typing a single character can invalidate the whole code, but the editor >> should keep the AST somehow in that case too. > > C#'s Roslyn does this: > http://blogs.msdn.com/b/ericlippert/archive/2012/06/08/persistence-facades-… This is an interesting approach. Their problem is not just updating the AST after every keystroke but keeping usable performance when doing code rewriting/refactoring. My first Macintosh, a SE/30 with a 16 MHz 68030, was able to do this with Think Pascal (by Mel Conway) 25 years ago. On my next machine, a 25 MHz 68040LC was fast enough... Stephan

Feb. 7, 2015

Re: [Pharo-dev] ||

by Thierry Goubier

2015-02-06 22:00 GMT+01:00 stepharo <stepharo(a)free.fr>: > Really interesting discussion. I like pragmas but this is interesting to > see them challenged. > Thanks. It's a pleasure to discuss that way :) > Yes, but there end up being lots of naming conventions and they are >> non-obvious. Whereas pragmas, because they are in-your-face in the methods >> in question, don't need conventions. They just need documenting ;-). >> > Thierry I'm skeptical that multiple protocol will save the problem because > you will rely on coding conventions. > Pragma as well: just explain the conventions behind the gtInspector pragmas, for example. But give me multiple protocols and I'll show you the same conventions rewritten in less lines (and a slightly more efficient code). > And pragma is a clever tagging. > Then maybe we should remove protocols and replace them with pragmas :) Thierry > > Stef > > >

Feb. 7, 2015

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

by Ben Coman

On Sat, Feb 7, 2015 at 4:24 AM, stepharo <stepharo(a)free.fr> wrote: > > Would it be possible/desirable to have a system such that: > * bug fixes for external packages can be still be directly applied and > tested in the Pharo-integrated branch > * the CI workflow generates an updated ConfigurationOf{external package} > that it pushes back to the external package repository? > > Yes this is the process I had in mind but this is not that simple because > the configuration of the external package may also have changed > and a merge should be done in the external package. > I considered that, but unless our workflow is constrained to having only a single branch we need explore this space. Consider Package A has a core group of people working towards its next feature on its development branch, and a third-party submits a bug fix for Package A. Do we need to wait for the next feature to be ready for integration to get the bug fix, and in one hit get feature+fix (a), or do we want the fix integrated asap after suitable review, and integrate the feature separately in its own time (b). In either case there will be a PackageA-thirdparty.#.mcz that needs to merged. Its just a question of when its merged. Now if I am the third-party, the latter option (b) seems a faster and more transparent turnaround which is more motivational. So I haven't experienced much with distributed multi-party workflows. I only know the ones I read related to git. Here it seems the common workflow is for the feature branch to merge the master into itself before pushing itself to the master. This seems to align with option (b). I feel a bit that how we have a single versioned file for Configuration is the bottleneck for the workflow of managing develop paths outside the master image. Sure multiple branches can be defined within that file, but it seems awkward for multiple parties to manage those branches without stepping on toes. My musings lead me to the following analogy with git: * The way that multiple branches are defined within the Configuration file seems like the metadata defining a cloned git repository. It defines the versions for the heads of the various branches. * Multiple parties updating the single ConfigurationOfA-name.#.mcz file is like multiple parties working in the same cloned git repository. * Copying the ConfigurationOfA-name.#.mcz to ConfigurationOfA-Pharo-name.#.mcz would be like cloning a repository. Its a copy of the repository branch metadata. * These files ConfigurationOfA-name.#.mcz and ConfigurationOfA-Pharo-name.#.mcz could still be stored in the same server location, similar to how github holds multiple repository clones, but the heads of the branches could progress independently in each clone. * What we would need is a way to merge a Configuration's dependencies similar to how we merge and display a Slice's dependencies (making the workflow like merging a pull request between cloned repositories). What do we currently have like that? cheers -ben > Its a great idea to separate out Configurations to devolve > responsibility for sub-packages, but it adds some friction to bug fixing. > > Yes I always thought about it. > > > It "seems" we will have a single branch combining both feature > development and bug-fixing, but it would be nicer to have two branches. > > > > > --------------- > On another track, I wonder if it would be useful if a package which is > part of a Configuration is made dirty, the Configuration itself could also > be marked dirty? > > cheers -ben > > > > On Fri, Feb 6, 2015 at 4:36 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> 14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools >> #development >> "From this version onwards the development version should be integrated." >> >> Is this a good idea? Does the #development version always include *all* >> the latest >> changes, because after Andrei opened >> 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools >> (which got integrated in 40475) >> I uploaded some changes for issue >> 14608 <https://pharo.fogbugz.com/default.asp?14608> >> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to >> Spotter methods >> I set the status to "Fix Review needed", >> >> but my changes are integrated in 40475 too! >> >> I am not satisfied with the way external packages are handled. >> 1. if there is not one slice/changeset per issue, it is even less >> likely someone will >> review the changes. >> 2. you don't know who works when on a issue. They are solved in a bulk. >> 3. a new configuration might not only includes bugfixes but new >> features as well. >> 4. often we have unbound globals / undeclared references or other test >> failures. >> >> Can we use the build server for those external projects (like >> GToolkitCore, Athens, TxText), >> and that if a project makes a new configuration, it uses the same >> issue validator for loading and testing that configuration? >> >> >> nicolai >> >> >> > >

Feb. 7, 2015

Re: [Pharo-dev] ||

by Thierry Goubier

2015-02-06 18:41 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Or are you talking about the lack of class pragmas? This is a point. But > classes already have an executable hook they can use for system > modification, their class-side initialize and obsolete methods. That's > been used for a long time to address system modification needs on > installing and removing classes. So form that perspective there's less of > a need to class pragmas. Instead we're focussing on more specialised class > definition facilities such as slots, which are intrinsic to classes, i.e. > define the class itself, rather than pragmas, which are extrinsic to > methods in that they define how methods interact in the system outside > themselves. > Maybe what you are saying here holds what I am longing for. Something as simple and as well defined as aClass class>>initialize (simple, solve-it-all mechanism for all initialization needs in a class, full smalltalk based so easily discoverable) or now the class slots, but applied to methods and their metadata. Pragmas are a first step towards that, but I have a feeling we could do it better (and it seems, with some of the changes coming such as traces, in-image optimisations, breakpoints, etc... it may be usefull or overgrow the pragmas). Thierry

Feb. 6, 2015

Re: [Pharo-dev] ||

by Eliot Miranda

On Fri, Feb 6, 2015 at 2:12 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-02-06 18:29 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> Hi Eliot, >>> >>> maybe I'll frame the core question a bit differently, thanks to your >>> explanations. >>> >>> I see pragmas used mainly for two things: >>> >>> 1- expressing a link to some metadata used by low level tools: compiler, >>> C lang generator, etc... primitives for me are part of that. Kind of neat >>> to see that unified. >>> >> >> There's a third use that is, I think, the most powerful. Maybe you see >> this as the same as 1, but I don't. The method is a component to be >> included in some larger structure, e.g. it is an action method on a menu, >> or it is an implementation of a pane in an inspector. The pragma is the >> message to be sent to the object that manipulates that larger structure to >> add the method to it. This is how menu pragmas work in VW. There is an >> object called a MenuBuilder. To add a method to a menu (and which menu is >> described by the pragma) the menu builder sets the method as its current >> method and then performs the pragma. The parameters in the pragma allow >> the MenuBuilder to add the method in the right way to the menu. But the >> execution of the pragma is what actually adds the mehtod to the menu. So >> its a combination of specification and execution. >> > > You mean as a sort of lightweight command object? Pharo uses that for its > world menu, Nautilus for its menus, and probably in a few other places. I > also like to define command objects for that purpose, because it gives you > more flexibility and power while keeping all concerns together: complex > commands depending on the context of their creator, having both a menu > entry and a shortcut, controlling whether they are enabled or not... I also > like command objects because they usually force a bit of a dedicated > category for them, and may avoid a spread of pragmas tagged methods left > and right in the package. > Yes, a Message instance is a command object, pragmas are Message instances, therefore pragmas are command objects. So using pragmas to associate menu action methods with their menus embeds the relevant command objects in the menu action methods. I have no problem with your criticism of pragmas used for categorisation. >> Method categories are already there and sometimes much more appropriate >> than pragmas. For example, in the SPur bootstrap the methods to be added >> or modified in Spur are included in categories of SpurBootstrapPrototypes >> and its subclasses. If there were pragmas in these methods then the >> pragmas would be copied into Spur, which is not at all what I want. >> Instead I copy across the methods in the relevant categories. >> >> But this "not a complete solution" feels to me an unfair criticism. >> Pragmas are what they are and they can do a lot. But no part of the system >> does everything. A system is composed of components. >> > > I agree with that, and the fact that well, maybe, someone will come along > with something better :) > > Thierry > > -- best, Eliot

Feb. 6, 2015

Re: [Pharo-dev] ||

by Thierry Goubier

2015-02-06 18:29 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> Hi Eliot, >> >> maybe I'll frame the core question a bit differently, thanks to your >> explanations. >> >> I see pragmas used mainly for two things: >> >> 1- expressing a link to some metadata used by low level tools: compiler, >> C lang generator, etc... primitives for me are part of that. Kind of neat >> to see that unified. >> > > There's a third use that is, I think, the most powerful. Maybe you see > this as the same as 1, but I don't. The method is a component to be > included in some larger structure, e.g. it is an action method on a menu, > or it is an implementation of a pane in an inspector. The pragma is the > message to be sent to the object that manipulates that larger structure to > add the method to it. This is how menu pragmas work in VW. There is an > object called a MenuBuilder. To add a method to a menu (and which menu is > described by the pragma) the menu builder sets the method as its current > method and then performs the pragma. The parameters in the pragma allow > the MenuBuilder to add the method in the right way to the menu. But the > execution of the pragma is what actually adds the mehtod to the menu. So > its a combination of specification and execution. > You mean as a sort of lightweight command object? Pharo uses that for its world menu, Nautilus for its menus, and probably in a few other places. I also like to define command objects for that purpose, because it gives you more flexibility and power while keeping all concerns together: complex commands depending on the context of their creator, having both a menu entry and a shortcut, controlling whether they are enabled or not... I also like command objects because they usually force a bit of a dedicated category for them, and may avoid a spread of pragmas tagged methods left and right in the package. > I have no problem with your criticism of pragmas used for categorisation. > Method categories are already there and sometimes much more appropriate > than pragmas. For example, in the SPur bootstrap the methods to be added > or modified in Spur are included in categories of SpurBootstrapPrototypes > and its subclasses. If there were pragmas in these methods then the > pragmas would be copied into Spur, which is not at all what I want. > Instead I copy across the methods in the relevant categories. > > But this "not a complete solution" feels to me an unfair criticism. > Pragmas are what they are and they can do a lot. But no part of the system > does everything. A system is composed of components. > I agree with that, and the fact that well, maybe, someone will come along with something better :) Thierry

Feb. 6, 2015

CFP - IWST 2015

by jannik laval

[Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] ************************************************************************************************************ CALL FOR PAPERS IWST15 â International Workshop on Smalltalk Technologies Brescia, Italy; July 15, 2015 http://www.esug.org/wiki/pier/Conferences/2015/International-Workshop-IWST_… ************************************************************************************************************ ------------------- Goals and scopes ------------------- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: Short position papers describing emerging ideas Long research papers with deeper description of experiments and of research results. Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. -------------------- Important Dates -------------------- Submission deadline: April 10th, 2015 Notification deadline: May 20th, 2015 Workshop : July 15th, 2015 All accepted papers will be published in ACM DL (To be confirmed) ------------------- Topics ------------------- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: -Aspect-oriented programming, -Design patterns, -Experience reports, -Frameworks, -Implementation, new dialects or languages implemented in Smalltalk, -Interaction with other languages, -Meta-programming and Meta-modeling, -Tools ------------------- Best Paper Award ------------------- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank the Lam Research Corporation for its financial contribution which makes it possible for prizes for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. ------------------- Publication ------------------- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also contains links to useful informations on how to write effective submissions. ------------------- Submission ------------------- All submissions must be sent via easychair: https://easychair.org/conferences/?conf=iwst2015 ------------------- Program chairs ------------------- Anne Etien (UniversitÃ© de Lille 1, France) Jannik Laval (Ecole des Mines de Douai, France) -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

Feb. 6, 2015

CFP - IWST 2015

by jannik laval

[Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] ************************************************************************************************************ CALL FOR PAPERS IWST15 â International Workshop on Smalltalk Technologies Brescia, Italy; July 15, 2015 http://www.esug.org/wiki/pier/Conferences/2015/International-Workshop-IWST_… ************************************************************************************************************ ------------------- Goals and scopes ------------------- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: Short position papers describing emerging ideas Long research papers with deeper description of experiments and of research results. Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. -------------------- Important Dates -------------------- Submission deadline: April 10th, 2015 Notification deadline: May 20th, 2015 Workshop : July 15th, 2015 All accepted papers will be published in ACM DL (To be confirmed) ------------------- Topics ------------------- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: -Aspect-oriented programming, -Design patterns, -Experience reports, -Frameworks, -Implementation, new dialects or languages implemented in Smalltalk, -Interaction with other languages, -Meta-programming and Meta-modeling, -Tools ------------------- Best Paper Award ------------------- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank the Lam Research Corporation for its financial contribution which makes it possible for prizes for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. ------------------- Publication ------------------- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also contains links to useful informations on how to write effective submissions. ------------------- Submission ------------------- All submissions must be sent via easychair: https://easychair.org/conferences/?conf=iwst2015 ------------------- Program chairs ------------------- Anne Etien (UniversitÃ© de Lille 1, France) Jannik Laval (Ecole des Mines de Douai, France) -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

Feb. 6, 2015

Re: [Pharo-dev] [Slots] Invisible Slots

by stepharo

I want relationships for certain modeling purposes What I like is that we should arrive to get a collection of useful slots with optimal implementation instead all of us reinventing the wheel. Stef Le 6/2/15 18:15, Marcus Denker a Ã©crit : >> On 06 Feb 2015, at 11:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> Next: When building classes with Slots, the class builder need to call back on the slot and hand the class to each. Then the slot >>> can reflectively change the class, e.g. the PropertySlot will check if there is already a hidden property base slot and if not, add it >>> reflectively). >> This is now done: >> >> https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-ca… >> > For playing with this, in 479: > > InstanceVariableSlot subclass: #AccessorSlot > slots: { } > classVariables: { } > category: âPackage' > > two methods, #installingIn and #removingFrom:, which are called by the class builder: > > > installingIn: aClass > | reader writer | > > reader := String streamContents: [ :str | > str > nextPutAll: self name; > cr;tab; > nextPutAll: ' ^'; > nextPutAll: self name. > ]. > writer := String streamContents: [ :str | > str > nextPutAll: self name; > nextPutAll: ': anObject'; > cr;tab; > nextPutAll: self name; > nextPutAll: ':= anObject.'. > ]. > aClass compile: reader classified: 'accessing'. > aClass compile: writer classified: 'accessingâ. > > > removingFrom: aClass > > aClass removeSelector: self name. > aClass removeSelector: self name asMutator. > > > Now we can make a class and see how the accessors are automatically added (and removed when the slot is removed): > > Object subclass: #TT > slots: { #tttt => AccessorSlot } > classVariables: { } > category: âPackage' > > > NOTE: this is an example of what can be done with Slots. It is *not* an example of what *should* be done with Slots. > (this we only will know after using them for a while). > > Marcus > > > >

Feb. 6, 2015

Re: [Pharo-dev] ||

by stepharo

> I would love to see an editor, which works on the AST directly - aka > it maps the source code to AST nodes, and just updates the smallest > possible subtree at each keystroke. Implementing such editor has it's > challenges ofc, like typing a single character can invalidate the > whole code, but the editor should keep the AST somehow in that case too. Me too and I want pretty print as you type :) A student will probably want to start that adventure so we will have fun. > >> >> Another way to see it: How would the original Smalltalk be designed >> if they would have had 4GB RAM in 1978? >> >> What fascinates me still is that Smalltalk used the existing >> resources (even building their own machines) to an >> extreme, while today we are obsessed to find reasons why we can not >> do anything that makes the system >> slower or use more memory than yesterday. And that even with >> resources growing every yearâ¦ >> >> This is why we e.g. now have a meta object describing every instance >> variable in Pharo. I am sure there are people >> who will see these ~7000 objects as pure wasteâ¦ while I would say >> that we have already *now* the resources to be >> even more radical. > > I think this is a different thing. Improvements are always welcome, as > long as they don't step on your toes. > > About Slots: I don't see their advantages yet (other than bitfields, > but those are so rare in Smalltalk that I implement them causes no > trouble. And they are just an optimization over using multiple fields.). > > Levente > >> >> Marcus >> >> >>

Feb. 6, 2015