- Pharo-dev - lists.pharo.org

mc.stfx.eu/ZincHTTPComponents missing files

by Stephan Eggermont

What's the primary repository for Zinc? The configuration seems to refer to a file that is not in the repo Fetched -> Zinc-HTTP-SvenVanCaekenberghe.397 --- http://mc.stfx.eu/ZincHTTPComponents --- http://mc.stfx.eu/ZincHTTPComponents ...RETRY->Zinc-Zodiac-SvenVanCaekenberghe.33 ...RETRY->Zinc-Zodiac-SvenVanCaekenberghe.33 ...FAILED->Zinc-Zodiac-SvenVanCaekenberghe.33 Could not resolve: Zinc-Zodiac [Zinc-Zodiac-SvenVanCaekenberghe.33] in /builds/workspace/Forum/PHARO/30/VERSION/development/VM/vm/package-cache http://mc.stfx.eu/ZincHTTPComponents Stephan

June 25, 2014

Re: [Pharo-dev] [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

by Tudor Girba

This really is beautiful! Doru On Wed, Jun 25, 2014 at 3:29 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I have written a new, extensive, long form, introductory article about > Pharo. > > Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator > > A tutorial on Pharo, test and specification based immersive programming > > > https://medium.com/@svenvc/rediscovering-the-ux-of-the-legendary-hp-35-scie… > > > It is a bit different because > > - it is based on a non-trivial example > - it uses a backdrop story unrelated to Pharo > - it uses several multimedia elements > - it is published on medium.com which is a general publishing platform > > The appendix describes several ways you can get the code. I think building > both a Spec and Seaside UI from the same specification as well as reusing > functional tests in different contexts is cool. Anyway, I hope you enjoy it. > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > -- www.tudorgirba.com "Every thing has its own flow"

June 25, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by stepharo

On 25/6/14 19:57, Johan Brichau wrote: > Hi, > > It seems that when even a single Nautilus system browser is open and you do a load (using Metacello), there is a huge amount of objects that get created and persisted in the image. > This even leads to the point that the image crashes when I try to load our code using a ConfigurationOf. After some time, the Pharo process is stuck at 100%, image size is over 500MB and the entire image becomes unresponsive, finally crashing after an hour or so. > > I have not yet found which objects or why, but I just wrestled with this all day to find out what was going on. I first thought that Metacello was in an infinite loop but after noticing that the image was so large (500MB) and that it got reduced to 20% of its size after closing the browser window, I can say that Nautilus is gathering garbage. It is definitely not Metacello because I can trigger the same problem doing a load via Monticello only. > > When I load the ConfigurationOf without a single browser open, it loads 5x faster and the image size stays reasonable ouch! we will have to look at that. This is the problem that we do not have a difference between loading code and incrementally compiling code. May be this is the same that happened to me recently when I tried to do ((ConfigurationOfGlamour project version: #development) ignoreImage: true; record), but sadly this is not the same :( It reminds me a talk of Georg on VW showing that loading code in VW wa spending 95% of the time in refreshing panes. Can you open a bug entry with a high priority? > > Is this a known issue? Any thoughts on what may be causing this? > > regards! > Johan >

June 25, 2014

Do we remove infiniteForm support?

by stepharo

because when I see code like that, it makes me sick! I wonder also when we migrate to Athens if we will not rewrite all that anyway. fillRectangle: aRectangle basicFillStyle: aFillStyle "Fill the given rectangle with the given, non-composite, fill style." | pattern | (aFillStyle isKindOf: InfiniteForm) ifTrue: [ ^self infiniteFillRectangle: aRectangle fillStyle: aFillStyle ]. (aFillStyle isSolidFill) ifTrue:[^self fillRectangle: aRectangle color: aFillStyle asColor]. "We have a very special case for filling with infinite forms" (aFillStyle isBitmapFill and:[aFillStyle origin = (0@0)]) ifTrue:[ pattern := aFillStyle form. (aFillStyle direction = (pattern width @ 0) and:[aFillStyle normal = (0@pattern height)]) ifTrue:[ "Can use an InfiniteForm" ^self fillRectangle: aRectangle color: (InfiniteForm with: pattern)]. ]. "Use a BalloonCanvas instead" self balloonFillRectangle: aRectangle fillStyle: aFillStyle.

June 25, 2014

Re: [Pharo-dev] [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

by Sven Van Caekenberghe

On 25 Jun 2014, at 20:47, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > Great article Sven! Thank you, Geert. > It would be great to also add a brief explanation in the appendix how > newbies can get the great looking "optional" dark theme after downloading > Pharo 3. #JustAnIdea I understand, but the article is already quite long ;-) And I don't want to be too technical. Now, in Pharo 4, the dark theme comes included, you just have to enable it. This is the original blog post announcing the dark theme: http://smallworks.eu/web/blog/2014-05-01-dark-theme-for-pharo HTH, Sven > -- > View this message in context: http://forum.world.st/Tutorial-Rediscovering-the-UX-of-the-legendary-HP-35-… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by stepharo

> Yesâ¦ the problem is that the âSlot meta objectâ and the âSlot that stores somethingâ use the same nameâ¦ > this was not a problem for instance variables as the where not reified. > > maybe on the class side it could be > > Point slotDefinitionNamed: At least this is clear and I like that. > > but nice it is notâ¦ or we maybe we use #resolveSlot: as the layoutâ¦. > > Marcus >

June 25, 2014

Re: [Pharo-dev] [Pharo4] Slots: API for Classes

by stepharo

> Now we should be careful that the reflective APIs for slots at object-level and at class-level don't clash. > What I means is that if "Point slotNamed: #x" return a slot what is the selector that satisfies "Point ?: #superclass" --> Object. > > It's difficult to have an elegant and consistent naming scheme because we lack precise terminology. > For example when we talk about an instance variable, do we refer to the declaration of an iv in a class or to the value bound to an iv in a given instance of that class? > Right now it is not clear: compare current class-level reflective API (#hasInstVarNamed: #instVarNames & co) to the object-level one (#instVarNamed: #instVarNamed:put: & co). Yes being precise about the api would greatly help. > I'm afraid that if we don't pay attention, we will have the same confusion when talking about slots. > > A slot is the *specification* of a variable that is accessible to the instances of a class. > So I think that the term slot should be reserved for methods of the class-level reflective API, as Marcus proposes with these new methods. > > So now what should be the new reflective API at the object-level? > Note that a slot doesn't necessarily define an instance variable, a slot could represent a shared variable like a class variable for example. > So I'm not sure that #instVarNamed: and #instVarNamed:put are still good names (even if they are backward compatible)... > Maybe #variableNamed: and #variableNamed:put:? > Or #valueOfSlotNamed: and #setValueOfSlotNamed:to:? > I think I dislike both, so I hope you have better ideas :) valueOfSlotNamed: is not that bad. Having a clean and consistent API would be great. > > Sorry to be the annoying nitpicker :), I know I tend to be fussy with terminology. > But terminology determines APIs: ill-defined terminology is a step towards bad APIs. +1 > >> ==> 5 >> >> Marcus > >

June 25, 2014

Re: [Pharo-dev] [Tutorial] Rediscovering the UX of the legendary HP-35 Scientific Pocket Calculator

by Geert Claes

Great article Sven! It would be great to also add a brief explanation in the appendix how newbies can get the great looking "optional" dark theme after downloading Pharo 3. #JustAnIdea -- View this message in context: http://forum.world.st/Tutorial-Rediscovering-the-UX-of-the-legendary-HP-35-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 25, 2014

Re: [Pharo-dev] Spec Button Shortcut Indication

by Sean P. DeNigris

Benjamin Van Ryseghem (Pharo) wrote > Itâs intentional that the C is underlined. Cool!! One of the few good ideas from Windoze... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-Button-Shortcut-Indication-tp4764414p4764778.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 25, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by phil＠highoctane.be

Maybe due to some Annoucement being picked up by Nautilus? Phil On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau <johan(a)inceptive.be> wrote: > Hi, > > It seems that when even a single Nautilus system browser is open and you > do a load (using Metacello), there is a huge amount of objects that get > created and persisted in the image. > This even leads to the point that the image crashes when I try to load our > code using a ConfigurationOf. After some time, the Pharo process is stuck > at 100%, image size is over 500MB and the entire image becomes > unresponsive, finally crashing after an hour or so. > > I have not yet found which objects or why, but I just wrestled with this > all day to find out what was going on. I first thought that Metacello was > in an infinite loop but after noticing that the image was so large (500MB) > and that it got reduced to 20% of its size after closing the browser > window, I can say that Nautilus is gathering garbage. It is definitely not > Metacello because I can trigger the same problem doing a load via > Monticello only. > > When I load the ConfigurationOf without a single browser open, it loads 5x > faster and the image size stays reasonable. > > Is this a known issue? Any thoughts on what may be causing this? > > regards! > Johan >

June 25, 2014