- Pharo-dev - lists.pharo.org

[Pharo-project] Redline: No more Java ...
by James Ladd May 18, 2012

May 18, 2012

Adopting a class in Redline Smalltalk is now easier and doesn't require compilation of Java - See the Getting Started http://www.redline.st/discover/getting-started.html Please help Redline by Adopting a Class.

2 1

[Pharo-project] Moving data into new package/image version
by Sean P. DeNigris May 17, 2012

May 17, 2012

I'm porting some apps that were using simple image-based persistence (ReferenceStream) from 1.3 to 1.4. The first thing that I ran into was FS class name changes (e.g. FSReference -> FileReference). Since the class wasn't present, I got an errorKeyNotFound [1]. Naively tried: Smalltalk globals at: #FSReference put: FileReference; at: #FSFilesystem put: FileSystem; at: #FSAbsolutePath put: AbsolutePath; at: #FSUnixStore put: UnixStore. But got "primitive #primGetPosition: in MultiByteFileStream failed" from ReferenceStream>>next I have a few ideas, but has anyone gone successfully through this type of process before? What's my best bet? I've been following Fuel and STON (which is quite nice for parsing json from REST APIs b.t.w.), but I'm not clear if either would be helpful here. What do you suggest? Thanks, Sean [1] Stack trace (heavily snipped) SystemDictionary(Dictionary)>>errorKeyNotFound: Receiver: a SystemDictionary(lots of globals) Arguments and temporary variables: aKey: #FSReference Receiver's instance variables: tally: 2920 array: an Array(#MemoryHandle->MemoryHandle nil nil #BlockClosuresTestCase->Blo...etc... cachedClassNames: nil cachedNonClassNames: nil ... ReferenceStream(DataStream)>>readInstance Receiver: a ReferenceStream Arguments and temporary variables: instSize: 2 aSymbol: #FSReference refPosn: 50 anObject: nil newClass: nil Receiver's instance variables: byteStream: MultiByteFileStream: '/Volumes/Sean''s Universe/sean/.jenkins/jobs/...etc... topCall: nil basePos: 0 references: an IdentityDictionary() objects: an IdentityDictionary(0->#(nil) 5->a Resources 10->#Resources 21->an O...etc... currentReference: 55 fwdRefEnds: an IdentityDictionary() blockers: an IdentityDictionary() skipping: an IdentitySet() -- View this message in context: http://forum.world.st/Moving-data-into-new-package-image-version-tp4628820.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

5 10

[Pharo-project] Release of Roassal
by Alexandre Bergel May 17, 2012

May 17, 2012

Dear Pharoer, We are very happy to announce the release of Roassal, an agile visualization engine. Roassal graphically renders objects using short and expressive Smalltalk expressions. A large set of interactions are offered for a better user experience. Painting, brushing, interconnecting, zooming, drag and dropping will just make you more intimate with any arbitrary object model. Screenshot available on http://objectprofile.com/pier/Products/Roassal/Screenshots Roassal is distributed under the MIT license and run on VisualWorks (7.4, 7.7.1, 7.9), Pharo (1.3, 1.4, 2.0) and ObjectStudio. Roassal is freely distributed, you are therefore free to use it, even in a commercial setting. We will however be glad to hear about your experience. Just send us an email if you are adopting Roassal. Kai and Hapao, the two other products of Object Profile, are using Roassal for their rendering. We will be extremely attentive to your experience. It is important for us that you are happy and feel comfortable with Roassal. The Object Profile crew (Twitter: @ObjectProfile , web: http://objectprofile.com) -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 4

[Pharo-project] Are we losing method versions?
by Sean P. DeNigris May 17, 2012

May 17, 2012

For DateAndTime class>>#readFrom: ... In Pharo 1.0, only one version: 'PeterHugossonMiller 9/3/2009 01:10' In Pharo 1.2.2, two versions, minus the one from 1.0: "#('SeanDeNigris 8/5/2010 15:51' 'StephaneDucasse 4/24/2010 12:46')" In Pharo 2.0, only the last version from 1.2.2 remains: 'SeanDeNigris 8/5/2010 15:51' -- View this message in context: http://forum.world.st/Are-we-losing-method-versions-tp4630520.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

6 8

[Pharo-project] User questions
by Sean P. DeNigris May 17, 2012

May 17, 2012

I think the options we identified are: * StackOverflow * dedicated site - we seem not to fit stackexchange's guidelines - our own hosted site, possibly like http://ask.rascal-mpl.org/questions/ * Users mailing list The disadvantage of the users list vs. the other options is that the domain model is much weaker for questions/answers e.g. was it answered? does the community think it's a good answer? On the question of internal/external. I guess the big tradeoff is the visibility of something like SO (where the outside world will see the energy of Pharo's Smalltalk revival) vs. keeping control of the content. Of the two options available this second, which do we prefer to get started - SO, or the users list? Sean -- View this message in context: http://forum.world.st/User-questions-tp4630513.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 3

[Pharo-project] WTF -> instVar called 'behaviors' in first slot
by Mariano Martinez Peck May 17, 2012

May 17, 2012

Hi guys. Today we had something really strange with Pharo 2.0. We are serializing FLPackage: Object subclass: #FLPackage instanceVariableNames: 'extensionMethods behaviors mustInitialize preLoadActions postLoadActions additionalObjects' classVariableNames: 'MustInitializeByDefault' poolDictionaries: '' category: 'FuelPackageLoader' That definition, where 'extensionMethods' is before 'behaviors' it works perfect. However, when just switching the oder to: Object subclass: #FLPackage instanceVariableNames: 'behaviors extensionMethods mustInitialize preLoadActions postLoadActions additionalObjects' classVariableNames: 'MustInitializeByDefault' poolDictionaries: '' category: 'FuelPackageLoader' The serialization of PharoCore fails because a problem with a metaclass of HTTPSocket. Any idea what can happen? thanks -- Mariano http://marianopeck.wordpress.com

4 7

Re: [Pharo-project] Are we losing method versions?
by Marcus Denker May 17, 2012

May 17, 2012

On May 16, 2012, at 8:16 PM, Sean P. DeNigris wrote: > For DateAndTime class>>#readFrom: ... > > In Pharo 1.0, only one version: 'PeterHugossonMiller 9/3/2009 01:10' > In Pharo 1.2.2, two versions, minus the one from 1.0: "#('SeanDeNigris > 8/5/2010 15:51' 'StephaneDucasse 4/24/2010 12:46')" > In Pharo 2.0, only the last version from 1.2.2 remains: 'SeanDeNigris > 8/5/2010 15:51' > Yes, we did a condense sources in 1.4. The .sources file reached 40MB. (condensed 12). Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] Pharo is exploding
by Marcus Denker May 17, 2012

May 17, 2012

On May 16, 2012, at 9:23 AM, Pavel Krivanek wrote: > On Tue, May 15, 2012 at 11:29 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >>>> It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do >>>> seriuous development you won't beusing Pharo 2.0, will you? ;) >>> >>> I talked about that few days ago with GermÃ¡n. The problem is not in >>> using of unstable version. The problem is that it is very easy to stop >>> to be in touch with Pharo now and within one year when the current >>> unstable version will become stable the developers will face to very >>> different system. That is one of the reason why GermÃ¡n choose Cuis for >>> his current projects. Developers want simple predictable system. >> >> Absolutely wonderful. So what people wants just the same. Ok but this is not Pharo. >> And and and again again again and again who is concerned by RPackage vs PackageInfo, >> systemNotifier vs. announcement, better monticello, better canvas, better Zincâ¦. >> I find that a totally false argument. > > I will quote GermÃ¡n (I hope he will not mind): "lot and lot of > things... Lot of new things each day. Part of that is that I started the project "tweet something about Pharo every day". some 15 months? ago... my idea was that we need to make public what happens because most people's perception was : Smalltak is dead. If people want I can stop. > Not time to stabilize nothing. Pharo 1.4 is frozen. We just fix bugs. The same with 1.3. Or even 1.2... > Is needed such acceleration? ... My point is, I'm trying to move a > business with Smalltalk and the acceleration of Pharo is well know by > me (from other companies) and sooner or later, impact in my job and > I'm a very LITTLE software house can't migrate my products all the > time." > You should *not* migrate. That's the idea. Just as one uses a (in the future unchanging Cuis, I am sorry to hear that), you can use an unchaning Pharo 1.4, or 1.3. Only when your project needs it, (because you actively with manpower develop it for a longer time), you can move to a new version. > We simply have to accept that some developers can have this feelings > and try to find a way how to limit it. I think that some official > Pharo blog (maybe written by Esteban) would be very helpful. Some kind > of not very extensive technical information source that will help > people to stay in touch with Pharo progress. That will explain what is > being changed in Pharo and why. I think that developers than will see > the changes like positive not as alien ones. > What I think is problematic: Peopler are against Change. But when somone nevertheless does it, build a great system, the same people that did not allow us to move will gladly abandon the old system for the new system. Cuis is a good example. According to the Philosophy of German, it should not exist. Maybe we should partition the *mailinglist* by stable and unstable? This way people using the stable don't see the noise and can focus... Marcus -- Marcus Denker -- http://marcusdenker.de

8 7

[Pharo-project] n-dimensional arrays
by Francisco Garau May 17, 2012

May 17, 2012

Hi -- just wonder if someone has implemented a n-dimensional array as in NumPy. What is cool about those arrays is that they are stored efficiently in an homogeneous collection (eg FloatArray) over which you can have several "views" or "slices" without having to take a copy. - Francisco

2 1

[Pharo-project] Collection>>difference: behaviour in 1.4 (was [Moose-dev] Re: Jenkins build is still unstable: moose-latest-dev #972 )
by Ben Coman May 16, 2012

May 16, 2012

'From Pharo1.4 of 18 April 2012 [Latest update: #14438] on 16 May 2012 at 11:15:20 pm'! !MOAbstractRegularTreeLayout methodsFor: 'hook' stamp: 'BenComan 5/16/2012 23:14'! doExecute: node | rootNodes btcdebug| alreadyLayoutedNodes := OrderedCollection new. rootNodes := self rootNodesFor: node nodes. nodesByLayer := OrderedCollection new. self flag: #btcdebug. "Regarding moose-dev(a)iam.unibe.ch emails 'Jenkins build is still unstable: moose-latest-dev #972' To isolate the issue, open a Transcript then generate the following in Mondrian Easel twenty times view shape label. view nodes: #(1 2 3 4 ). view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}. view treeLayout. " btcdebug := rootNodes first. Transcript cr; crShow: '------------------------------'. Transcript crShow: 'B1>', (self childrenFor: btcdebug) asString. Transcript crShow: 'B2>', (self computeChildrenFor: btcdebug) asString. self layout: rootNodes atPoint: self leftGap @ self topGap atLayer: 1. self isLayered ifTrue: [ self rearrangeByLayers: node ]! ! !MOAbstractVerticalTreeLayout methodsFor: 'hook-private' stamp: 'BenComan 5/16/2012 23:02'! layout: aNodeCollection atPoint: aPoint atLayer: aNumber | treeSize childrenPosition x y middleOfTree | aNodeCollection isEmpty ifTrue: [ ^ 0 ]. x := aPoint x. y := aPoint y. alreadyLayoutedNodes addAll: aNodeCollection. self atLayer: aNumber add: aNodeCollection. aNodeCollection do: [ :each | self flag: #btcdebug. Transcript crShow: 'A2>', each asString. childrenPosition := y + each height + self verticalGap. treeSize := each width max: (self layout: (self computeChildrenFor: each) atPoint: x @ childrenPosition atLayer: aNumber + 1). middleOfTree := x + (treeSize / 2.0) - (each width / 2.0). each translateTo: middleOfTree @ y. x := x + treeSize + self horizontalGap ]. ^ x - aPoint x - self horizontalGap! !

4 3