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

Re: [Pharo-dev] source code mgmt issues in Pharo4

by stepharo

Hi johan I usually attract bugs but not these ones. - I got debugger freezing - broken refactoring but not that ones. I would love to have a way to reproduce it. Stef Le 8/4/15 19:41, Johan Brichau a Ã©crit : > Hi all, > > Over the last week, I started working with Pharo4, mostly to make Seaside work cleanly. > > On several occasions, I had severe issues with the package management: > - methods that were changed in a class were not recorded as âchangedâ in monticello and were absent from the published package > - versions of methods disappeared (i.e. no longer accessible in the version history of a method) > - looking at the âchangedâ in Monticello showed all code of the package as changed (though only a single method has changed). > > This makes working with Pharo4 extremely problematic. I cannot trust the source code packaging/publishing and merging anymore. > > I cannot discern a scenario that leads to these issues but I do have an image right now where I only changed a single method and the entire package shows up as âchangedâ. > > Anyone experience similar issues? > > Johan >

April 9, 2015

Re: [Pharo-dev] broken setting in FFI

by stepharo

>> 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. you mean saving settings with Cocoon? Not sure because somebody should do it and my plate will quite full > > Thierry > >

April 9, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by stepharo

What is that? Le 9/4/15 20:05, Esteban Lorenzano a Ã©crit : > does anyone knows? > > Esteban > >

April 9, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Nicolai Hess

2015-04-09 20:05 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > does anyone knows? > > Esteban > > http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… 14689 <https://pharo.fogbugz.com/default.asp?14689> Debugger enters infinite loop when closed after editing test with "doesNotUnderstand: #stepToCallee" errors 14060 <https://pharo.fogbugz.com/default.asp?14060> MNU: receiver of "stepToCallee" is nil

April 9, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Sean P. DeNigris

Nicolai Hess wrote > http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… Ah, I miss that too! From that thread, it seems it was removed temporarily until we have real breakpoints. Is there an issue for its return? ----- Cheers, Sean -- View this message in context: http://forum.world.st/why-we-removed-debugTest-from-nautilus-tp4818657p4818… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 9, 2015

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