June 2014 - Pharo-dev - lists.pharo.org

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

Nautilus memory leak/hog crashing Pharo

by Johan Brichau

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

Re: [Pharo-dev] ZnURL HTTP Download-to-file shortcut

by Sven Van Caekenberghe

Henrik, Good idea, added a slightly modified version (named the class to the operation) and added a test. In #bleedingEdge. Thank you ! Sven PS: I was almost forgotten that I added this ZnUrlOperation stuff, I am glad you found it. === Name: Zinc-HTTP-SvenVanCaekenberghe.403 Author: SvenVanCaekenberghe Time: 25 June 2014, 7:26:21.541717 pm UUID: 3032d604-6363-400b-b2ce-c9401ac7cf17 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.402 Add ZnHttpSaveContentsToFile to implement ZnUrl>>saveContentsToFile: (thx Henrik Sperre Johansen) with a new unit test Make sure to put the code where necessary in the proper package extensions Fix ZnClient>>#testLogging on Pharo 2 === Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.25 Author: SvenVanCaekenberghe Time: 25 June 2014, 7:27:13.501891 pm UUID: 867946e0-c085-4a7a-a35d-0005a99c7e44 Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.24 Add ZnHttpSaveContentsToFile to implement ZnUrl>>saveContentsToFile: (thx Henrik Sperre Johansen) with a new unit test Make sure to put the code where necessary in the proper package extensions Fix ZnClient>>#testLogging on Pharo 2 == Name: Zinc-Tests-SvenVanCaekenberghe.213 Author: SvenVanCaekenberghe Time: 25 June 2014, 7:27:39.279953 pm UUID: 1b7415a0-72b5-4b9e-93fa-53749e05b3e5 Ancestors: Zinc-Tests-SvenVanCaekenberghe.212 Add ZnHttpSaveContentsToFile to implement ZnUrl>>saveContentsToFile: (thx Henrik Sperre Johansen) with a new unit test Make sure to put the code where necessary in the proper package extensions Fix ZnClient>>#testLogging on Pharo 2 === On 18 Jun 2014, at 15:07, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Hi! > Iâm a lazy bastard, but one which needs to download large files from time to time, hence I wrote the attached shortcut-operation for ZnUrls which gives me that without the extra fuss of manually creating a client etc. > Maybe just me who didnât spot existing functionality, or maybe itâd be a nice convenience operation to have in general distribution if you feel like picking better names/integrating it. > > Cheers, > Henry > > <DownloadToFile.cs>

June 25, 2014

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

by Chris Cunningham

Hi. On Wed, Jun 25, 2014 at 8:06 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com > >: > > 2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > Slot > \SimpleSlot (current iv slot) > > > Yes, the naming of that oneâ¦ I think we just need to take the freedom of > iterating. > For now I called it âInstanceVariableSlotâ, but that might be confusing > and it is a long word. > > > but is less confusing than âSimpleSlotâ, which basically says nothing, IMO > > > What about SimpleInstanceVariableSlot? (just kidding) > > I don't like over descriptive class names. Because they restrict you > from using it for other, unexpected, purposes or contexts. > > > The question to me is why this is "over descriptive". We have a tradition > here to be descriptive and intention revealing. It happens everywhere > except when it comes to instance variables it is instVarAt: instVarNamed: > etc. I never liked them. > Another question might be the usage context. Why is it called > InstanceVariableSlot anyway? Is there a difference if the slot is attached > to the instance side or class side? Isn't it really just a VariableSlot? > The context for the instance is where it is used. Asking an object for > instance variables and class instance variables could just return a > collection of VariableSlots, no? > Instances have instanceVariables, and classes have instanceVariables. There are also ClassVariables, which are a completely different thing (and commonly referred to directly from instance, class, and subclasses directly). It would be good not to make this any more complex (confusing?) than those concepts already are. -cbc > > Norbert > >

June 25, 2014