- Pharo-dev - lists.pharo.org

[Pharo-project] NetNameResolver localHostName - Mac OS always returns an ip address string
by Chris Cunnington April 26, 2011

April 26, 2011

http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146581.ht… NetNameResolver chooses an interface in an almost random manner. It can't be configured as the logic is baked into the VM. The thread above has some details concerning the topic and mentions a workaround. (You might think that being on a Mac, you could make a configuration change in the plist that comes with the VM and then restart. But I don't think there are any arguments in the plist for network interfaces.) Chris

1 0

[Pharo-project] Reify the VM in the image [WAS] Why we have Behavior >> flushCache?
by Mariano Martinez Peck April 26, 2011

April 26, 2011

Let's change the name of the thread :) On Tue, Apr 26, 2011 at 6:59 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Mariano, > > the point is that it is classes that manage adding methods to classes > and hence it is their private behavior to flush the VM's method cache. > Ok...I agree, but still it is misleading when we are talking about "method cache". Because methods are in classes...so I promise everybody that didn't know and you ask what Behavior >> flushCache does, and everybody will say that it flushed the cache of the methods of that class, not the whole cache. I can understand CompiledMethod >> flushCache and even Symbol >> flushCache ... but this one looks really strange. > You'll see "self flushCache" in Smalltalk-80 v2 images. > that makes more sense indeed > Now of course the VM provides selective cache flushing but back in the day > adding or removing a method implied flushing the whole cache. Personally I > don't see that this justifies adding Smalltalk vm yet. I would wait until > you have a few more use cases. > Sorry but in this case, I disagree. I think the opposite: it is the perfect moment to reify the VM in the image and start using it. Why? exactly because right now we have few uses and it is really easy to migrate. In fact, for Behavior >> flushCache there are only 3 senders. And I don't pretend to remove them right now, but with the normal deprecation policy. This is, in Pharo 1.3 we let the messages like Behavior >> flushCache, SmalltalkImage >> vmVersion, etc. But we let them as deprecated explaining that now they should use XXX. And of course, inside the image we do fix the senders. In fact, in Pharo 1.3, the method SmalltalkImage >> vm "Answer the object to query about virtual machine." ^self already exists :) I see the following possible behavior for VM right now (I mean, the following methods are already in SmalltalkImage): - #flushCache - #buildDate - #interpreterSourceVersion - #platformSourceVersion - #versionLabel - #extraVMMemory - #extraVMMemory: - #gcBiasToGrow: - #gcBiasToGrowLimit: - #getVMParameters - #primitiveGCBiasToGrow: - #vmParameterAt: -#vmParameterAt:put: - #reportCPUandRAM - #vmStatisticsReportString - #vmStatisticsShortString So....I think they are enough. And the sooner we do this, the easier it would be to reify the VM in the image. Cheers Mariano > > On Tue, Apr 26, 2011 at 3:34 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi. As far as I can see, >> >> Behavior >> flushCache >> "Tell the interpreter to remove the contents of its method lookup >> cache, if it has >> one. Essential. See Object documentation whatIsAPrimitive." >> >> <primitive: 89> >> self primitiveFailed >> >> >> And primitive 89 does nothing in particular with the receiver (the class >> in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, >> there is NOTHING related to the receiver class. Of course, that's at least >> what it looks for me (please tell me if I am wrong). >> So...if this is the case, wouldn't make sense to move it elsewhere? like >> Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to >> reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm >> flushCache, Smalltalk vm parameterAt: , etc.... >> >> If you don't like doing "Smalltalk vm" then we can create a VM class with >> all class methods, or a singleton and use #current or a singleton and put it >> in Smalltalk globals...etc >> >> We will need to fix a couple of senders, thus. >> >> What do you think? For me is really confusing, and you don't understand >> it until you see the primitive implementation. >> >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com

2 1

[Pharo-project] glamour chapter
by Tudor Girba April 26, 2011

April 26, 2011

Hi, For those interested, I updated the Glamour chapter on the Moose Book: http://www.themoosebook.org/book/internals/glamour The examples are meant to work in the latest Moose development image, but the engine is not tied to this image. Please let me know if there are still issues you would like to see discussed. Cheers, Doru -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

2 2

[Pharo-project] [COTDC] 53 - AnimatedGIFReadWriter
by laurent laffont April 26, 2011

April 26, 2011

Today: AnimatedGIFReadWriter Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

1 1

[Pharo-project] Suggestions: move examples from UIThemes class to ExampleBuilderMorph class
by DougEdmunds April 26, 2011

April 26, 2011

A couple of suggestions Part 1. Move the methods in the UIThemes class, protocol 'examples' to ExampleBuilderMorph class, protocol 'examples'. Rationale: Every one of these examples first creates an instance of ExampleBuilderMorph as the base class that the example is built on. These examples do not demonstrate anything about how to use UITheme. I made a file that duplicates the methods from UITheme class -examples- to ExampleBuilderMorph class -examples-, suitable for filein. Methods such as ExampleBuilderMorph class >>exampleBasicControls work fine, indicating they have no dependence on UITheme. The file's 347 lines, so I'm not posting it here, unless requested. Part 2. Then move ExampleBuilderMorph and ExampleRadioButtonModel from Polymorph-Widgets into a new package called Polymorph-Widgets-Examples. Rationale: This would be reduce the size of Polymorph-Widgets, and make it more obvious that there are some examples of the widgets to look at. UITheme class is not the place where one expects to find examples of buttons, checkboxes, etc. Also this would be consistent with other Morphic packages. (Morphic-MorphTreeWidget and Morphic-MorphTreeWidget-Examples) --- -- View this message in context: http://forum.world.st/Suggestions-move-examples-from-UIThemes-class-to-Exam… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 2

[Pharo-project] What is a well documented class?
by Alexandre Bergel April 26, 2011

April 26, 2011

Hi! I am dreaming about a tool to help me document source code. The question I have is what is a well documented class? What do you think about the following: A well documented class is a class: - that contains a class comment - its class comments contains either an example, or an associated unit test - without 'as yet unclassified' method category - each public method belongs to a method category named public* - each private method belongs to a method category named private* - each method contains a comment, located before the declaration of temporary variables - other methods are considered as "package visible", meaning that they belong to a category that does not begins with 'private' or 'public' - without commented code contained in its methods. Is there anything else? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

8 26

[Pharo-project] Hudson version 2.0 is available
by DougEdmunds April 26, 2011

April 26, 2011

Pharo is being developed on a Hudson 1.358 server (2010/05/14). Hudson has recently released version 2.0 (2011/04/21). http://hudson-ci.org/ -- View this message in context: http://forum.world.st/Hudson-version-2-0-is-available-tp3475761p3475761.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 1

April 26, 2011

Hi guys I'm chasing a strange bug since a couple of hours and what I would love to have is the possibility to change an instance variable into an object that says stop each time you are changed from this flow. Stef

8 21

[Pharo-project] Henrik should we include Settings-Sound ?
by Mariano Martinez Peck April 26, 2011

April 26, 2011

I saw that package in PharoSound and I wonder if it should be added to the Metacello conf cheers -- Mariano http://marianopeck.wordpress.com

3 11

[Pharo-project] Error with latest ProfStef in Pharo 1.3
by Mariano Martinez Peck April 26, 2011

April 26, 2011

"Error 'Please use buildTutorialTopicFor: instead'" when I try to open it from the menu. ProfStefHelpTutorialBuilder >> buildHelpTopicFrom: aHelpTopicDescription "Start building from the given help topic description" ^(self new) rootToBuildFrom: aHelpTopicDescription; build; topicToBuild the rpoblem is that #new I am using last versions of Pharo1.3 -- Mariano http://marianopeck.wordpress.com

3 10