- Pharo-dev - lists.pharo.org

CFP IWST 2015 - Deadline extension - 17th April

by jannik laval

Please note that the deadline has been extended to the 17th April 2015 . [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 17th, 2015* Notification deadline: May 20th, 2015 Workshop : July 15th, 2015 All accepted papers will be published in ACM DL ------------------- 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 eligible, 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/

April 9, 2015

Re: [Pharo-dev] About the singleton pattern

by Dmitri Zagidulin

What are pragmas for, ideally? I've only seen them mentioned in the context of flagging menu items. (And I know some of the frameworks like Seaside use them to mark http GET / POST etc handlers). On Thu, Apr 9, 2015 at 2:34 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 09 Apr 2015, at 20:32, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > > +1 to standardizing #uniqueInstance. > > but as I saidâ¦ not always. > > > Also, would it be appropriate to mark intended singleton creation methods > with a pragma? (So that they could be flagged as special in the UI, etc). > > no, we should not abuse the use of pragmas. > tools can recognise appropriate selectors (like it happens with > initialisation, etc.) without need to pollute the code. > > Esteban > > > On Wed, Apr 8, 2015 at 6:21 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> On 08 Apr 2015, at 12:01, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> On Wed, Apr 8, 2015 at 11:52 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> >>> > On 08 Apr 2015, at 11:37, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> > >>> > Sometimes I use #new >>> thatâs horrible! >>> completely misleading >>> >> >> I'm curious, if it is singleton, should you worry from outside about the >> fact that it is a singleton? Shouldn't that be hidden from the user? >> >> nope. >> new means new. >> you are confusing your user if you send a new message and you receive an >> already existing (aka not new) object. >> the literature existing always recommend to use an specific method >> (usually #instance or #uniqueInstance, in smalltalk.. who decided to use >> #uniqueInstance as a convention). >> >> Esteban >> >> >> Peter >> >> >> > >

April 9, 2015

Re: [Pharo-dev] Spotter

by Dmitri Zagidulin

This reminds me - who wants to write a section (or a chapter) on Spotter, for the updated Pharo By Example book? :) (The issue for discussing or committing against is here: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/31 ). It seems like an amazing tool and an important part of Pharo 4 workflow, so we should definitely encourage new developers to use it. On Sat, Apr 4, 2015 at 9:03 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Ben, >> >> >> This is quite a hidden and implicit key stroke. Regardless that I know >> I've used it before follow a tutorial, I forgot it. Since Spotter has a >> <Settings Icon> (which I like and think it could be pushed as a standard >> throughout the system in Pharo 5), it might be useful for Pharo 4 if the >> Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that >> just contains descriptive text. Or if there is no facility for that, >> perhaps a few of the keyboard shortcuts listed as individual items with >> descriptions, even if you can't change them. I think this will be useful >> for people presented with Spotter for the first time, particularly since >> first use already prompts users to go to settings to send usage data. > > > > Yes, you right, shortcuts were quite hidden. However, after we received a > lot of similar feedback we improved the situation with shortcuts. Now all > actions in Spotter have explicit action buttons: > [image: Inline image 1] > > As soon as you press "shift" (you can't not to press shift during usage of > spotter) all action buttons are highlighted explicitly: > [image: Inline image 2] > > If you hover action button for a few second a hint appears that tells > which shortcut is assigned to an action. If you hover the button while > pressing shift a hint appears immediately: > > [image: Inline image 3] > > Also, in Pharo help there is a good tutorial listing all Spotter shortcuts > and assigned actions: > [image: Inline image 4] > > How else can we improve discoverability of Spotter features? > > Cheers, > Alex > > > Cheers, > Alex > > On Sun, Apr 5, 2015 at 2:35 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> Thanks Aliaksei. >> >> This is quite a hidden and implicit key stroke. Regardless that I know >> I've used it before follow a tutorial, I forgot it. Since Spotter has a >> <Settings Icon> (which I like and think it could be pushed as a standard >> throughout the system in Pharo 5), it might be useful for Pharo 4 if the >> Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that >> just contains descriptive text. Or if there is no facility for that, >> perhaps a few of the keyboard shortcuts listed as individual items with >> descriptions, even if you can't change them. I think this will be useful >> for people presented with Spotter for the first time, particularly since >> first use already prompts users to go to settings to send usage data. >> >> cheers -ben >> >> On Sun, Apr 5, 2015 at 8:25 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> wrote: >> >>> Hi Ben, >>> >>> It's CMD+Shift+Right >>> On Apr 5, 2015 2:23 AM, "Ben Coman" <btc(a)openinworld.com> wrote: >>> >>>> Just a note, I went back to an old image and really miss the Spotter >>>> workflow. >>>> >>>> One thing, can you remind me how when it shows 5/30 implementors I get >>>> a list of all 30? I'm sure I've done this before but can't remember. >>>> Perhaps this means its not obvious and maybe should appear in a "How To >>>> Use" section in the Release Notes. >>>> >>>> cheers -ben >>>> >>> >> >

April 9, 2015

Re: [Pharo-dev] About the singleton pattern

by Esteban Lorenzano

> On 09 Apr 2015, at 20:32, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > > +1 to standardizing #uniqueInstance. but as I saidâ¦ not always. > > Also, would it be appropriate to mark intended singleton creation methods with a pragma? (So that they could be flagged as special in the UI, etc). no, we should not abuse the use of pragmas. tools can recognise appropriate selectors (like it happens with initialisation, etc.) without need to pollute the code. Esteban > > On Wed, Apr 8, 2015 at 6:21 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> On 08 Apr 2015, at 12:01, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> >> On Wed, Apr 8, 2015 at 11:52 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> > On 08 Apr 2015, at 11:37, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> > >> > Sometimes I use #new >> thatâs horrible! >> completely misleading >> >> I'm curious, if it is singleton, should you worry from outside about the fact that it is a singleton? Shouldn't that be hidden from the user? > > nope. > new means new. > you are confusing your user if you send a new message and you receive an already existing (aka not new) object. > the literature existing always recommend to use an specific method (usually #instance or #uniqueInstance, in smalltalk.. who decided to use #uniqueInstance as a convention). > > Esteban > >> >> Peter > >

April 9, 2015

Re: [Pharo-dev] About the singleton pattern

by Dmitri Zagidulin

+1 to standardizing #uniqueInstance. Also, would it be appropriate to mark intended singleton creation methods with a pragma? (So that they could be flagged as special in the UI, etc). On Wed, Apr 8, 2015 at 6:21 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 08 Apr 2015, at 12:01, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Wed, Apr 8, 2015 at 11:52 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> > On 08 Apr 2015, at 11:37, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> > Sometimes I use #new >> thatâs horrible! >> completely misleading >> > > I'm curious, if it is singleton, should you worry from outside about the > fact that it is a singleton? Shouldn't that be hidden from the user? > > nope. > new means new. > you are confusing your user if you send a new message and you receive an > already existing (aka not new) object. > the literature existing always recommend to use an specific method > (usually #instance or #uniqueInstance, in smalltalk.. who decided to use > #uniqueInstance as a convention). > > Esteban > > > Peter > > >

April 9, 2015

why we removed debugTest from nautilus?

by Esteban Lorenzano

does anyone knows? Esteban

April 9, 2015

Re: [Pharo-dev] broken setting in FFI

by Thierry Goubier

Le 09/04/2015 16:10, stepharo a Ã©crit : > > > Le 7/4/15 15:19, Thierry Goubier a Ã©crit : >> Le 07/04/2015 15:14, Tudor Girba a Ã©crit : >>> This setting should be removed. Does anyone have anything against that? >> >> Or, could settings be rewritten so that we don't regularly triggers >> DNUs and MNUs when we reload them? >> >> You know, just regular, declarative, boring settings instead of >> something which execute code on non-existent Classes half of the time... > > We started to extract tge configuration code out of pillar but we do not > know if it will work for settings. > So far no time to check. > > It is called cocoon on pharoextras Small remark on the documentation on Smalltalkhub: it is STON-based, not JSON-based. Will you make this an item (replace settings by Cocoon) on the roadmap for Pharo5? I know I would. Thierry

April 9, 2015

Re: [Pharo-dev] broken setting in FFI

by Thierry Goubier

Le 09/04/2015 16:10, stepharo a Ã©crit : > > > Le 7/4/15 15:19, Thierry Goubier a Ã©crit : >> Le 07/04/2015 15:14, Tudor Girba a Ã©crit : >>> This setting should be removed. Does anyone have anything against that? >> >> Or, could settings be rewritten so that we don't regularly triggers >> DNUs and MNUs when we reload them? >> >> You know, just regular, declarative, boring settings instead of >> something which execute code on non-existent Classes half of the time... > > We started to extract tge configuration code out of pillar but we do not > know if it will work for settings. > So far no time to check. > > It is called cocoon on pharoextras Seems fine. Just browsing through it. Maybe a tad complex, to have to subclass both a CCConfiguration and a CCSTONConfigurationInterpreter for the thing to work. Flexible and powerfull. Composable. Is missing some of the code needed for settings: a default place to store them, the GUI part (settings browser), and the logic run-once. As the previous one, gives the feeling that settings are not application driven, but system driven (and applications are passive receivers). It's a design choice, and I'm not entirely happy with that choice, because it has a tendency to force decoupling layers in apps so that they can control if and when they take in account external settings or in-image settings changes. Thierry

April 9, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Guillermo Polito

Hi! It took me a while to read this thread before answering. :) With Camille we spent some hours this afternoon to take a look at this bug. We added new test cases and managed to do a hack that solves all the issues we could spot. You can find a slice for it in the inbox Now, we would like to have much more testing on it. SLICE-Issue-14606-Cant-see-some-variables-values-while-debugging-closure-GuillermoPolito.2 Our conclusion looking at the issue is that some parts of Opal (particularly the parts that manage the temp mapping and the temp vector) should be rewritten. By the moment our fix looks more like a hack. Guille El lun., 6 de abr. de 2015 a la(s) 3:43 p. m., Ben Coman < btc(a)openinworld.com> escribiÃ³: > So the current status of this is "apparent" VM bug. Is it apparent enough > that for now should I stop banging my head against it from the image side? > > > Actually I am working 10 hour shifts the next three weeks during the power > station's annual maintenance outage, so my time is probably limited anyway. > cheers -ben > > On Mon, Apr 6, 2015 at 4:10 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> >> 2015-04-05 17:38 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >>> >>> >>> On Sun, Apr 5, 2015 at 8:59 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>>> >>>> Thanks both of you for the energy you put into Pharo. >>>> The tam really appreciates. >>>> This is because there are guys like you that Pharo is worth being done. >>>> Thanks for the tests. >>>> Esteban has apparently found the bug on the VM. >>>> >>>> Stef >>>> >>>> >>> Energy breeds energy. For me it was an opportunity to learn more deep >>> stuff(tm) by digging with a goal. It remains a bit beyond me, but I'm >>> happy if I've been able to beat the high grass enough to flush the tiger >>> into the open where the marksman can take a shot at it. >>> >>> Nice to flush out a VM bug (can't be too many of those left ;). Let us >>> know when we can do testing on it. I guess I'll read more about it on >>> [vm-dev]. >>> >>> cheers -ben >>> >> >> >> If it's a VM bug, the VM folks would be really really interested by a bug >> report, especially if ever it may affect Eliot's branch. >> Even if it's a Pharo only bug, it is still very interesting to know, >> because there's allways something to learn from a bug. >> So I'm all ears... >> >> cheers >> >> Nicolas >> > >

April 9, 2015

Fwd: [ci-announces] Memory upgrade on Jenkins servers

by Christophe Demarey

Scheduled shutdown of jenkins servers: DÃ©but du message rÃ©expÃ©diÃ© : > De : Emmanuel Jeanvoine <emmanuel.jeanvoine(a)inria.fr> > Date : 9 avril 2015 17:10:23 HAEC > Ã : ci-announces(a)inria.fr > Objet : [ci-announces] Memory upgrade on Jenkins servers > RÃ©pondre Ã : Emmanuel Jeanvoine <emmanuel.jeanvoine(a)inria.fr> > > Dear users, > > In order to prevent issues related to memory saturation on Jenkins servers, > an upgrade will be performed on next Monday (April 13th, 2015) between > 09:45 and 11:15. Meanwhile, the Jenkins instances will be stopped. In order > to prevent any issue, you should stop your Jenkins instances before the > maintenance. > > Thank you for your understanding, > Emmanuel > > -- > Emmanuel Jeanvoine > Inria Research Engineer > +33 3 54 95 86 21 > http://www.loria.fr/~ejeanvoi/

April 9, 2015