December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Scat - Public Release and announcement

by Serge Stinckwich

2011/12/13 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>: > Hi list, > > Joan GÃ¼ell and I have been working onÂ Scat -the Scratch port to Pharo-Â quite > a lot recently.Â We wanted to push it to a point where we could release the > first reasonably working version, which we've just managed today. Great work Joan & Bernat ! > Please take a look at the release announcementÂ (which should be read in a > bit of a humorous tone), in which we explain what's up with the project and > what future is left for it. > > For the tl;dr version, please read: > > Many things are working, many aren't, but the state of the project allows us > to move into more interesting stuff based on the graphic programming > metaphor. > Scat is a time-consuming, brain-smashing, life sucking-project. > We no longer will be maintaining this massive unmaintainable code. > Suddenly: free time for other projects! Why do you say that you will not maintain the project anymore ? Do you mean this is better to rebuild something better ? Any news from Scratch about a relicensing of the core ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Dec. 13, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by Mariano Martinez Peck

On Sun, Dec 11, 2011 at 7:50 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > When I last looked at SmartReferenceStream, it did two things that were > bad: > > (1) it essentially assumed all "users" are in fact programmers, have > access to the debugger, and (more presumptuous) know what to to with same. > There are times when yelling "it's broken" is about all the system should > dare do. SRS made no such distinction. Again, the age of the code is > showing. We have exception handling now, and should design with it in mind. > > (2) reshape code was placed in SRS itself, not in the class that is > changing shape. The thing that is being deserialized (which is when > problems become apparent) should be in charge of the change. It simplifies > both packaging (fewer loose methods to consider, and reduced opportunity > for name collisions) and it also helps with using proxies for special > circumstances. > > Thanks for the notes Bill. We will take them into account. > > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano > Martinez Peck [marianopeck(a)gmail.com] > *Sent:* Sunday, December 11, 2011 10:54 AM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Cleaning up SmartRefStream use > > > > On Sun, Dec 11, 2011 at 4:35 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> On Dec 11, 2011, at 4:26 PM, Mariano Martinez Peck wrote: >> >> > >> > >> > On Sun, Dec 11, 2011 at 11:32 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> > Indeed this is fun I was doing the same :) >> > Now I do not understand why some parts of the system uses dataStream, >> others ReferenceStream and finally others SmartRefStream >> > why not all of them use SmartRefStream. >> > >> > It is not that I like these guys, but their class comments are pretty >> clear: >> > - DataStream does NOT handle cycles, but hence it may be faster in >> certain scenarios. I guess that for example, Monticello is sure that in its >> definitions, there cannot be cycles. In addition, it doesn't take into >> account variables names/order and hence class reshape isn't supported. >> > - ReferenceStream supports cycles but still doesn't support class >> reshape. >> > - SmartRefStream supports cycles and class reshape. >> > >> sounds good > > > Yes it does. In fact, I would love also to have those things > optional/configurable in Fuel: optional cycle detection and optional class > reshape support :) > > >> then we should be able to replace all the reference stream and smart by >> fuel. >> > > Yes, but Fuel is not completly ready to fully replace them. There are some > hooks they provide that Fuel does not yet. But we will get there at some > point. > > >> >> stef >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Dec. 13, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Mariano Martinez Peck

On Tue, Dec 13, 2011 at 12:32 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Dec 12, 2011 at 1:56 PM, Carlo <snoobabk(a)yahoo.ie> wrote: > >> Hi >> >> Wouldn't the fact that you use hash cause potential loops now? e.g. >> collection refers to another object that refers to first collection. --> >> aCollection>>hash references an item which causes this current collection's >> hash to be called again? >> >> > Hi Carlo. I am still newbie with Collections but I think I am having > exactly that problem. During my tests, it loops in Collection >> #hash > when sending #hash to its elements. > Sorry, but I couldn't undertand what is the cause of the problem? why it > doesn't work while it does using #identityHash? could you elaborate? > > Well, now I understood, and I understand also why it doesn't happen with #identityHash. But what happens then with regular Dictionaries using #hash? why it doesn't happen there? > thanks > > >> identityHash is deterministic in this case. >> >> Does this help? >> Cheers >> Carlo >> >> On 12 Dec 2011, at 10:58 AM, Mariano Martinez Peck wrote: >> >> Hi guys. I hope this is not a very stupid question. Background: in Fuel >> we have a IdentityDictionary where we put each of the objects we find while >> traversing the graph. We need to use IdentitySet because we cannot have >> repetitions (and to avoid loops) so we NEED to use #==. In such dictionary >> we put ALL objects of the graph, so it can be very big. Since IdentitySet >> uses #identityHash, it means it will be using those ONLY 12 bits in the >> object header. It means that we have 2^12 = 4096 different values. >> >> Question: having explained the previous, I wanted to be able to use >> #hash rather than #identityHash since several classes implement #hash and >> hence I thought that using #hash I could have less colisions and hence a >> better performance. I tried to make a subclass of IdentitySet that uses >> #hash rather than #identityHash but my image freezes. I also tried >> something like: >> >> set := PluggableSet new. >> set hashBlock: [ :elem | elem hash ]. >> set equalBlock: [ :a :b | a == b ]. >> >> But it doesn't work either. I works with simple tests in a workspace but >> when I run the full tests of Fuel, it enters in a loop in the method #hash >> of Collection.. >> >> Anyway, my question is, should that work? if not, what is the exact >> reason? >> >> Thanks in advance, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Dec. 12, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Mariano Martinez Peck

Thanks Levente. I will try both. Actually, I would also need a fast (or at least I would like to use #hash) IdentityDictionary apart from a IdentitySet ;) On Mon, Dec 12, 2011 at 1:52 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Mon, 12 Dec 2011, Levente Uzonyi wrote: > > On Mon, 12 Dec 2011, Mariano Martinez Peck wrote: >> >> Hi guys. I hope this is not a very stupid question. Background: in Fuel >>> we >>> have a IdentityDictionary where we put each of the objects we find while >>> traversing the graph. We need to use IdentitySet because we cannot have >>> repetitions (and to avoid loops) so we NEED to use #==. In such >>> dictionary >>> we put ALL objects of the graph, so it can be very big. Since IdentitySet >>> uses #identityHash, it means it will be using those ONLY 12 bits in the >>> object header. It means that we have 2^12 = 4096 different values. >>> >>> Question: having explained the previous, I wanted to be able to use >>> #hash >>> rather than #identityHash since several classes implement #hash and >>> hence I >>> thought that using #hash I could have less colisions and hence a better >>> performance. I tried to make a subclass of IdentitySet that uses #hash >>> rather than #identityHash but my image freezes. I also tried something >>> like: >>> >>> set := PluggableSet new. >>> set hashBlock: [ :elem | elem hash ]. >>> set equalBlock: [ :a :b | a == b ]. >>> >>> But it doesn't work either. I works with simple tests in a workspace but >>> when I run the full tests of Fuel, it enters in a loop in the method >>> #hash >>> of Collection.. >>> >>> Anyway, my question is, should that work? if not, what is the exact >>> reason? >>> >> >> If the serialized objects remain unchanged, then it can work. You can >> also give another IdentitySet implementation a try, e.g.: >> http://leves.web.elte.hu/**squeak/LargeIdentitySet.st<http://leves.web.elte.hu/squeak/LargeIdentitySet.st>. >> > > You can also take a look at SystemTracer, because (IIRC) it uses an > IdentitySet which will contain all objects at a point, and it's reasonably > fast. IIRC the idea is to use the identityHash of the object mixed with the > hash of its class to increase the number of bits in the key. > > > Levente > > > >> >> Levente >> >> >>> Thanks in advance, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >>> >> >> > -- Mariano http://marianopeck.wordpress.com

Dec. 12, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Mariano Martinez Peck

On Mon, Dec 12, 2011 at 1:56 PM, Carlo <snoobabk(a)yahoo.ie> wrote: > Hi > > Wouldn't the fact that you use hash cause potential loops now? e.g. > collection refers to another object that refers to first collection. --> > aCollection>>hash references an item which causes this current collection's > hash to be called again? > > Hi Carlo. I am still newbie with Collections but I think I am having exactly that problem. During my tests, it loops in Collection >> #hash when sending #hash to its elements. Sorry, but I couldn't undertand what is the cause of the problem? why it doesn't work while it does using #identityHash? could you elaborate? thanks > identityHash is deterministic in this case. > > Does this help? > Cheers > Carlo > > On 12 Dec 2011, at 10:58 AM, Mariano Martinez Peck wrote: > > Hi guys. I hope this is not a very stupid question. Background: in Fuel we > have a IdentityDictionary where we put each of the objects we find while > traversing the graph. We need to use IdentitySet because we cannot have > repetitions (and to avoid loops) so we NEED to use #==. In such dictionary > we put ALL objects of the graph, so it can be very big. Since IdentitySet > uses #identityHash, it means it will be using those ONLY 12 bits in the > object header. It means that we have 2^12 = 4096 different values. > > Question: having explained the previous, I wanted to be able to use #hash > rather than #identityHash since several classes implement #hash and hence I > thought that using #hash I could have less colisions and hence a better > performance. I tried to make a subclass of IdentitySet that uses #hash > rather than #identityHash but my image freezes. I also tried something like: > > set := PluggableSet new. > set hashBlock: [ :elem | elem hash ]. > set equalBlock: [ :a :b | a == b ]. > > But it doesn't work either. I works with simple tests in a workspace but > when I run the full tests of Fuel, it enters in a loop in the method #hash > of Collection.. > > Anyway, my question is, should that work? if not, what is the exact reason? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Dec. 12, 2011

Re: [Pharo-project] Pharo research page

by Mariano Martinez Peck

Hi Alexandre. I attach one of object swapping and ImageSegment, it is a journal. There is the journal of Fuel also but we are waiting the notification :( Cheers @article{Mart11c, Abstract = {In object-oriented systems, runtime memory is composed of an object graph in which objects refer to other objects. This graph of objects evolves while the system is running. Graph exporting and swapping are two important object graph operations. Exporting refers to copying the graph to some other memory so that it can be loaded by another system. Swapping refers to moving the graph to a secondary memory (for example, a hard disk) to temporary release part of the primary memory (for example, RAM). Exporting and swapping are achieved in different ways and the speed in presence of large object graphs is critical. Nevertheless, most of the existing solutions do not address well this issue. Another challenge is to deal with common situations where objects outside the exported/swapped graph point to objects inside the graph. To correctly load back an exported subgraph, it is necessary to compute and export extra information that is not explicit in the object subgraph. This extra information is needed because certain objects may require to be reinitialized or recreated, to run specific code before or after the loading, to be updated to a new class definition, etc. In this paper, we present all general problems to our knowledge about object exporting and swapping. As a case of study, we present an analysis of ImageSegment, a fast solution to export and swap object graphs, developed by Dan Ingalls. ImageSegment addresses the speed problems in an efficient way, as shown by the results of several benchmarks we have conducted using Pharo Smalltalk. However, ImageSegment is not a panacea since it still has other problems that hampers its general use.}, Aeres = {ACL}, Aeresstatus = {aeres12}, Annote = {internationaljournal}, Author = {Martinez Peck, Mariano and Noury Bouraqadi and St\'ephane Ducasse and Luc Fabresse}, Doi = {10.1016/j.cl.2011.10.001}, Labo = {dans}, Journal = {Journal of Computer Languages, Systems and Structures}, Keywords = {pharo-pub lse-pub raweb2011}, Impactfactor = {5 Year ISI impact factor 0.567 (2010)}, Month = nov, Number = {1}, Pages = {1--15}, Peerreview = {yes}, Publisher = {Elsevier}, Title = {Object Swapping Challenges: an Evaluation of ImageSegment}, Url = { http://rmod.lille.inria.fr/archives/papers/Mart11c-COMLAN-ObjectSwapping.pdf }, Volume = {38}, X-Country = {FR}, X-Editorial-Board = {yes}, X-International-Audience = {yes}, X-Language = {EN}, X-Pays = {FR}, X-Proceedings = {yes}, Year = {2012}, Hal-Id = {hal-00646897}, Inria = {RMOD}, Selectif = {non}} On Mon, Dec 12, 2011 at 2:13 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Dear All, > > As you may know, the page http://www.pharo-project.org/about/researchlists the publications related to Pharo. > > If you have a publication related to Pharo and want to see it listed > there, send me the bibitem. > Example of bibentries are > http://scg.unibe.ch/scgbib?_k=4LCS3SCq&query=pharo+2011&display=bibtex > Having a url field in your bibitem will enable people download your paper. > > 5 publications are listed for 2011. I am sure we have published more than > that :-) > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 12, 2011

[Pharo-project] Big Image Tests

by Sven Van Caekenberghe

Today I tried to find out if it would be possible to allocate a large amount of memory in a VM. I used the official 32-bit VM (http://gforge.inria.fr/frs/download.php/29042/CogVM-Unix-13307.zip) and a Pharo 1.3 (http://gforge.inria.fr/frs/download.php/29273/Pharo-1.3-13315.zip) derived image on Ubuntu 11.04 (x86_64) Amazon AWS EC2 m1.large instance (about 8Gb RAM) and the following bash and Smalltalk scripts: run.sh #!/bin/bash script_home=$(dirname $0) script_home=$(cd $script_home && pwd) image=$script_home/pharo-t3.image script=$script_home/run.st args=$* vm=$script_home/bin/CogVM options="-mmap 1536m -vm-display-null -vm-sound-null" #echo $vm $options $image $script $args $vm $options $image $script $args run.st | args size monolithic object | FileStream stdout wantsLineEndConversion: true. Smalltalk garbageCollect. FileStream stdout nextPutAll: 'Running run.st with args: '; nextPutAll: Smalltalk commandLine arguments printString; cr; nextPutAll: Smalltalk vmStatisticsReportString. args := Smalltalk commandLine arguments. size := args first asInteger. monolithic := (args size > 1 and: [ args second = 'monolithic' ]). monolithic ifTrue: [ object := ByteArray ofSize: size * 1024 * 1024 ] ifFalse: [ object := Array ofSize: size * 1024. 1 to: size * 1024 do: [ :each | object at: each put: (ByteArray ofSize: 1024) ] ]. Smalltalk garbageCollect. FileStream stdout nextPutAll: 'Allocation of a size '; print: object size; space; print: object class; nextPutAll: ' OK'; cr; nextPutAll: Smalltalk vmStatisticsReportString. Smalltalk quitPrimitive. These were the results trying to allocate 1GB: $ ./run.sh 1024 Running run.st with args: #('1024') uptime 0h0m0s memory 49,103,224 bytes old 36,625,732 bytes (74.60000000000001%) young 9,812 bytes (0.0%) used 36,635,544 bytes (74.60000000000001%) free 12,467,680 bytes (25.400000000000002%) GCs 8 (90ms between GCs) full 2 totalling 212ms (29.400000000000002% uptime), avg 106.0ms incr 6 totalling 10ms (1.4000000000000001% uptime), avg 1.7000000000000002ms tenures 0 Allocation of a size 1048576 Array OK uptime 0h0m26s memory -1,007,414,928 bytes old -1,020,337,428 bytes (101.30000000000001%) young 5,888 bytes (0.0%) used -1,020,331,540 bytes (101.30000000000001%) free 12,916,612 bytes (-1.3%) GCs 590 (44ms between GCs) full 62 totalling 14,735ms (56.6% uptime), avg 237.70000000000002ms incr 528 totalling 10,225ms (39.300000000000004% uptime), avg 19.400000000000002ms tenures 519 (avg 1 GCs/tenure) Since last view 582 (44ms between GCs) uptime 25.3s full 60 totalling 14,523ms (57.400000000000006% uptime), avg 242.10000000000002ms incr 522 totalling 10,215ms (40.300000000000004% uptime), avg 19.6ms tenures 519 (avg 1 GCs/tenure) $ ./run.sh 1024 monolithic Running run.st with args: #('1024' 'monolithic') uptime 0h0m0s memory 49,103,216 bytes old 36,627,976 bytes (74.60000000000001%) young 9,844 bytes (0.0%) used 36,637,820 bytes (74.60000000000001%) free 12,465,396 bytes (25.400000000000002%) GCs 8 (46ms between GCs) full 2 totalling 208ms (56.1% uptime), avg 104.0ms incr 6 totalling 10ms (2.7% uptime), avg 1.7000000000000002ms tenures 0 Allocation of a size -1073741824 ByteArray OK uptime 0h0m2s memory -1,020,427,928 bytes old -1,037,112,380 bytes (101.60000000000001%) young 5,952 bytes (0.0%) used -1,037,106,428 bytes (101.60000000000001%) free 16,678,500 bytes (-1.6%) GCs 13 (177ms between GCs) full 4 totalling 725ms (31.5% uptime), avg 181.3ms incr 9 totalling 14ms (0.6000000000000001% uptime), avg 1.6ms tenures 0 Since last view 5 (386ms between GCs) uptime 1.9000000000000001s full 2 totalling 517ms (26.8% uptime), avg 258.5ms incr 3 totalling 4ms (0.2% uptime), avg 1.3ms tenures 0 Basically it seems to work. What I find particulary strange is that #vmStatisticsReportString starts reporting negative sizes, also the size of the 1GB ByteArray is reported as negative. Why ? Tomorrow I might try to find out how much further I can take this ? How close to 4GB ? Anybody else tried this ? Sven

Dec. 12, 2011

Re: [Pharo-project] Company/freelance working with Pharo/Seaside

by Sean P. DeNigris

Stephan Eggermont wrote > >> Although it is important that the community keeps on growing, we reached >> critical mass a long time ago, IMHO. > For innovators yes. For early adopters, no. They value different things. > There was a great TED Talk that speaks to this topic: Simon Sinek: How great leaders inspire action http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html And a Smalltalk discussion of it at http://forum.world.st/Spreading-Smalltalk-td3435227.html The bottom line is: tell people what you believe, not what you do; and the tipping point (critical mass) is 15%-18%. "You can trip over 10% of the customers... that just 'get it'", but "the early majority will not try something until someone else has tried it first" -- View this message in context: http://forum.world.st/Re-Company-freelance-working-with-Pharo-Seaside-tp418… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 12, 2011

Re: [Pharo-project] Missing network primitive

by Noury Bouraqadi

Ok. I added it to the Cog bug tracker. http://code.google.com/p/cog/issues/detail?id=68 Noury On 10 dÃ©c. 2011, at 16:29, Levente Uzonyi wrote: > On Sat, 10 Dec 2011, Noury Bouraqadi wrote: > >> Hi, >> >> While working on OCEAN (yes, yes, we're still working on it :-) we have an annoying issue. >> We have some netname resolver tests that do work with the Squeak Mac VM 5.8, but they are not working in the Mac Cog VMs. >> >> This is because the following primitives are missing at the VM side. Still, they are useful cause they allow getting addresses of all network interfaces of your machine. >> >> primitiveResolverGetAddressInfo >> primitiveResolverGetAddressInfoSize >> primitiveResolverGetAddressInfoResult >> primitiveResolverGetNameInfo >> primitiveResolverGetNameInfoHostSize >> primitiveResolverGetNameInfoHostResult >> primitiveResolverGetAddressInfoNext >> >> >> There are methods defined in the old NetNameResolver (class side) that call these primitives, but they are NOT referenced. >> primGetAddressInfoHost:service:flags:family:type:protocol: >> primGetAddressInfoSize >> primGetAddressInfoResult: >> primGetNameInfo:flags: >> primGetNameInfoHostSize >> primGetNameInfoHostResult: >> primGetAddressInfoNext >> >> We checked the SqueakVM SVN, and they are there in the SocketPlugin.c >> Why didn't they get introduced in Mac CogVM? >> Are there missing for other platforms too? > > Yes they are, CogVM was forked before these were added to SqueakVM. > > > Levente > >> >> Luc and Noury >> -- >> http://twitter.com/#!/NouryBouraqadi >> >> >> > Noury -- http://twitter.com/#!/NouryBouraqadi

Dec. 12, 2011

Re: [Pharo-project] Sprint friday 16 @ lille

by Noury Bouraqadi

Hi, On 9 dÃ©c. 2011, at 09:06, StÃ©phane Ducasse wrote: > Hi guys > > I'm not sure that my message passed in the mailing-list. > We will organize a sprint new friday and everybody is welcome. Cool. I'll be there! > Just let us know so that we prepare the rooms. > It would be nice if we have a few items we collaborate to addess. One possible item I'm planning to contribute to is to help Marcus/help our selves by reviewing some pending fixes in the bug tracker. Noury -- http://twitter.com/#!/NouryBouraqadi

Dec. 12, 2011