- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [OT] Re: Why Smalltalk ? Which Smalltalk ?

by Levente Uzonyi

On Tue, 21 Dec 2010, Sven Van Caekenberghe wrote: > > On 21 Dec 2010, at 19:16, Levente Uzonyi wrote: > >> a) removing unessential code from Squeak (Squeak, having started as a children.s education project, has accumulated a fair amount of cruft over the years), >> b) clearer licensing (MIT license), >> c) more frequent updates (think Ubuntu versus Debian), and >> d) being a reference implementation for the Seaside platform (perfect, exactly what I need it for)." >> >> b) and c) are clearly false. a) ignores the fact that you can unload quite a lot of "cruft" from Squeak making it comparable to Pharo-Core. > > I might be wrong, and I known that Squeak has been changing lately, but Pharo seems to have been the driver here, putting these issues on the map. The modularization of Squeak is an old idea (a). One such effort is Pavel's KernelImage project which dates back to 2006: http://lambda-the-ultimate.org/node/1873 The idea of relicensing Squeak (b) dates back to 2003 or earlier. Apple relicensed the original Squeak code in 2006 under the Apache license. AFAIK the MITification process started in 2006 or 2007: http://c2.com/cgi-bin/wiki?SqueakRelicensePush. According to wikipedia the driving force was adding EToys to OLPC. I think that in case of the update frequency (c) Squeak was the driving force. Why? Let's see the timeline: 21 March 2008: Squeak 3.10 released 21 May 2008: Pharo forked Squeak 3.9 (the date may not be exact) 30 May 2008: First Pharo snapshot uploaded to gforge 02 July 2009: Squeak's new developement process announced (aka 3.11 developement cancelled) 31 July 2009: Pharo 1.0 Beta announced 16 March 2010: Squeak 4.0 comes out (same as Squeak 3.10, but with MIT license) 29 March 2010: Squeak 4.1 feature freeze announced 16 April 2010: Pharo 1.0 released 26 April 2010: Squeak 4.1 released (the first artifact of the new process) 16 May 2010: Pharo 1.1 Beta announced 26 July 2010: Pharo 1.1 released 08 December 2010: Pharo 1.2 Beta announced 13 December 2010: Squeak 4.2 feature freeze announced Pharo's developement cycle restarts after a beta. Squeak's developement cycle restarts after the release. So: Artifact DW RW WSPR ------------------------------------ Pharo 1.0 62 99 N/A Pharo 1.1 41 47 14 Pharo 1.2 29 >31 >21 Squeak 4.1 38 42 5 but irrelevant Squeak 4.2 33 >34 >34 DW = Developement weeks (number of weeks between cycle restart and feature freeze/beta) RW = Release weeks (number of weeks between cycle restart and release) WSPR = Weeks since previous release (number of weeks between releases) What I wanted to show is that the release of Pharo 1.0 was not urgent at all (DW and RW are both _more than a year_) until Squeak 4.1 came out. After the release of Squeak 4.1, Pharo 1.0 and 1.1 was released ASAP. So yes, I think you're wrong, just like Dmitri. Levente > > Sven > > >

Dec. 22, 2010

Re: [Pharo-project] Graph library in Smalltalk - Need for advices

by Chris Muller

On Wed, Dec 22, 2010 at 11:09 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> Raster image = bitmap. Â As you know, bitmaps have the ability, no >> matter whether you render 1 node or 1-billion nodes and edges on it, >> it does not take up much more space. > > It depends on the size of the bitmap :-) Not really; if you start with an empty (say, all white), uncompressed bitmap, painting various graphics on it does not change its uncompressed size. > I am not sure to understand. Suppose you have a domain (e.g., cars, persons and ownership). You can render this domain the way you want. Dragging nodes does not changes your models. It changes the graph built by Mondrian (i.e., instances of MONode and MOEdes). Right. I am not talking about the cars and persons, I am talking about "Mondrians domain model", "(i.e., instances of MONode and MOEdes)". If I have 1 million cars and persons and I want Mondrian to render a visualization involving all of them, then it has to create and *keep* 1 million MONodes. I want to do it without keeping them since that cannot scale. Assume, perhaps, that I have my 1 million Cars in a Magma database, and I don't want to persist 1M MONodes just to render a quick picture. > What is exactly the problem you're trying to solve? The (imaginary) problem I'm interested to solve is I have a huge model persisted in Magma, I want to make a visualization based on one million+ objects without creating and keeping 1M MONodes in memory.... Instead, I would like to create each MONode, render it on the raster image, but don't keep it so it can be GC'd. But its representation is already preserved on the bitmap.

Dec. 22, 2010

Re: [Pharo-project] accessors vs direct access in Cog

by Eliot Miranda

On Wed, Dec 22, 2010 at 12:12 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi guys > > Ideally I would love to be able to use accessors as the abstraction layer > that they can bring us: > I mean the fact that we could avoid to have offset based bytecode means > that we could reuse a lot more > the methods (in special case - mixins and others). > > Now I have a question does the JIT or the shortcut (not sure if this is in > stackVM) blurry the cost of accessors > vs. direct accesses? > Not yet. But IMO it would be straight-forward to add. The PIC design supports inserting extra code at a send site, which is the logical place to put the access code. > > Does anybody run a benchmarck about > self x vs x in Cog recently > on a real app? > > Stef > best Eliot

Dec. 22, 2010

Re: [Pharo-project] SandstoneDb + SortedCollections

by Eliot Miranda

On Tue, Dec 21, 2010 at 10:31 PM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > On 12/21/2010 08:51 PM, David Zmick wrote: > >> What can I do to fix this? >> > > Another option might be to use a sort block that isn't a block, but an > ordinary object that responds as a sort block would, allowing the collection > to be serialized successfully. Another option would be to fix the limitation. There's nothing conceptually preventing serializing a block. It's just an object after all. You have some choices - how do you serialize the home context (you need to serialize every context along the static chain out to the home context)? It should be serialized with a nil sender. - bringing the block back in do you try and hook up the method to the corresponding method in image or leave it anonymous; leave it anonymous. 2Â¢ Eliot > > -- > Ramon Leon > http://onsmalltalk.com > >

Dec. 22, 2010

Re: [Pharo-project] Error on page http://lists.gforge.inria.fr/mailman/listinfo

by Marcus Denker

This is now fixed http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project On Dec 21, 2010, at 9:45 AM, Marcus Denker wrote: > > I opened a ticke with the support. > > On Dec 21, 2010, at 7:04 AM, James Foster wrote: > >> http://lists.gforge.inria.fr/mailman/listinfo gives an error. >> > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 22, 2010

Re: [Pharo-project] Graph library in Smalltalk - Need for advices

by Alexandre Bergel

> Raster image = bitmap. As you know, bitmaps have the ability, no > matter whether you render 1 node or 1-billion nodes and edges on it, > it does not take up much more space. It depends on the size of the bitmap :-) > But because Mondrian builds an object-model in RAM (from which it > renders), there is a definite scalability limit in terms of the > number of nodes. Rendering also takes more time due to > object-allocation, etc. In Mondrian, each object is rendered via a shape. There is a number of shapes, one of them is MOImageShape, which displays a bitmap. > The only reasons I can think to need to create a full domain model of > the graph is: > > 1) to calculate positioning > 2) for user-input; being able to drag the nodes around (thus > updating the Mondrian domain model, for subsequent display updates). I am not sure to understand. Suppose you have a domain (e.g., cars, persons and ownership). You can render this domain the way you want. Dragging nodes does not changes your models. It changes the graph built by Mondrian (i.e., instances of MONode and MOEdes). > (1) _might_ be able to be accomodated by, when generating the picture, > only keeping track of various node counts at each level and/or overall > bounds of the picture. Mondrian has a cache mechanism that does exactly that. A node may contains elements. A bitmap is created for you to speed the things up. > (2) is what I'm arguing might not be a good trade-off in all cases. > Sure, the output is now a static picture instead of something with > draggable boxes, but at the cost of speed and scale. > > Does that make sense? I find Mondrian interesting, thanks for your feedback. You can drag and drop inner nodes, the caches is reset without any particular action. What is exactly the problem you're trying to solve? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 22, 2010

[Pharo-project] Issue 3478 in pharo: [Failing Test] Graphics.Tests.Files.BMPReadWriterTest.testBmp24Bit

by pharo＠googlecode.com

Status: Accepted Owner: marcus.denker Labels: Milestone-1.2 New issue 3478 by marcus.denker: [Failing Test] Graphics.Tests.Files.BMPReadWriterTest.testBmp24Bit http://code.google.com/p/pharo/issues/detail?id=3478 Graphics.Tests.Files.BMPReadWriterTest.testBmp24Bit

Dec. 22, 2010

Re: [Pharo-project] Graph library in Smalltalk - Need for advices

by Chris Muller

>> Hi Alexandre, I only have very limited experience with Mondrian, so >> please excuse me if this is a stupid question. Â Is it possible to >> employ an Iterator to simply draw on a raster image rather than >> creating a model in RAM? Â Perhaps it could be an option? Â Would it be >> hard to make Mondrian work this way? > > I am not sure what you mean by raster image. Raster image = bitmap. As you know, bitmaps have the ability, no matter whether you render 1 node or 1-billion nodes and edges on it, it does not take up much more space. But because Mondrian builds an object-model in RAM (from which it renders), there is a definite scalability limit in terms of the number of nodes. Rendering also takes more time due to object-allocation, etc. The only reasons I can think to need to create a full domain model of the graph is: 1) to calculate positioning 2) for user-input; being able to drag the nodes around (thus updating the Mondrian domain model, for subsequent display updates). (1) _might_ be able to be accomodated by, when generating the picture, only keeping track of various node counts at each level and/or overall bounds of the picture. (2) is what I'm arguing might not be a good trade-off in all cases. Sure, the output is now a static picture instead of something with draggable boxes, but at the cost of speed and scale. Does that make sense? I find Mondrian interesting, thanks for your feedback. - Chris

Dec. 22, 2010

[Pharo-project] [update 1.2] #12286

by StÃ©phane Ducasse

12286 ----- - Issue 3474: BmpReadWriterPlugin primitives should be used. Thanks Andreas Raab and Igor Stasenko for the funny discussion on this useful plugin :). - Issue 3452: GlorpDBX no longer loads due to garbled timestamp. Thanks Yanni Chiu. - Issue 3263: Add followingBytecode method to InstructionStream Stef

Dec. 22, 2010

Re: [Pharo-project] Issue 3263 in pharo: Add followingBytecode method to InstructionStream

by pharo＠googlecode.com

Updates: Summary: Add followingBytecode method to InstructionStream Status: closed Comment #3 on issue 3263 by stephane.ducasse: Add followingBytecode method to InstructionStream http://code.google.com/p/pharo/issues/detail?id=3263 in 12286

Dec. 22, 2010