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

[Pharo-project] About Deprecated13

by StÃ©phane Ducasse

Hi guys Lukas mentions that MenuIcons is gone without notice in 1.4. This is not really true :) It was in the deprecated13 package. Now this package which contains a lot of old old old code does not really load well in 1.4. I fileouted MenuIcons but this is not really a solution. Now since some parts of the system are really ugly, we cannot really spend time making that deprecated13 is fully working loading, but at least we could make sure that we can load it without problem. But for that it requires effort and probably the results may be a list of empty classes. So does it help you if we have that? So far having MenuIcons is working but this is ad-hoc now an automated solution does not work. Stef

Dec. 13, 2011

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

by Mariano Martinez Peck

On Tue, Dec 13, 2011 at 8:43 AM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > Hi Mariano, when I read this thread I was a bit confused that you wanted > an IdentitySet that used #hash. From that statement it sounded like you > just wanted a Set. This would allow any object to define its own hash and > importantly what equality means with #=. So if you want to delegate that to > the object use a Set. > > No, I cannot use a Set because I cannot have repetitions. This that I am asking is what we do in Fuel serializer while traversing the object graph. Each analyzed object is put in an IdentityDictionary (but the question is the same for IdentitySet) as key. To avoid cycles, I need to put each object only once. Since graphs can be very big, such dict could have lots of objects. > However as the thread has gone on perhaps you want the identity > relationship but you just wanted a bigger identity hash space? > Yes, exactly. I were thinking if there could be a way (maybe...that's why I am asking) of improve its performance considering that I could have much more objects than 2^13. In other words, I wanted to see if I could avoid colisions. > > IdentitySets are fast because they bypass any delegation. Once you have > seen the object in your traversal (common usage pattern) that's it. You > grab it's identity which is a pretty low level thing to do. > Ok...it is a tradeoff. If I use #identityHash it is fast because there is no delegation and it is almost an immediate primitive. But I gues it will be slow if there are lots of colisions. Not using #identityHash but something else maybe could decrease maybe the amount of colisions, but maybe with the delegation it will gets slower. I will try with Levente idea of what it is done in SystemTracer: use as a hash the identityHash of the object mixed with the identityHash of its class. Maybe that decreases the colisions and at the same time I don't pay delegation (#class is special bytecode, so nothing, and ok..there are 2 sends to #identityhash but I don't thinnk it is that much). Anyway, thanks for the interesting post, I always learn :) > > As for what happens with collections who knows. Depends. Relying on > identity set semantics for a collection is easy. Set semantics is not so. > Remember that both hash and equals are important to know if the set already > contains the element. Depending on the collection implementation both of > these could be composite in terms of the parts. Who knows where you end or > how long it takes. I.e. if it is a function of the size of the collection > and further collections are composite.... > > yes... > Cheers > Mike > > > > On Tuesday, December 13, 2011, Carlo <snoobabk(a)yahoo.ie> wrote: > > Hi Mariano > > I'm no expert either ;) > > Without having access to the exact code it would look like either you > have a collection that references itself (which would break all collection > implementations) or maybe the tests have just slowed down to the point > where you think it's 'crashed'. > > Do you have anymore info or perhaps which methods you changed on > IdentitySet? > > Cheers > > Carlo > > On 13 Dec 2011, at 1:57 AM, Mariano Martinez Peck wrote: > > > > > > 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 > > > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 13, 2011

Re: [Pharo-project] Pharo research page

by StÃ©phane Ducasse

I already gave all our pharo related refs to alex. Stef On Dec 13, 2011, at 12:17 AM, Mariano Martinez Peck wrote: > 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/research lists 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. 13, 2011

Re: [Pharo-project] Citezen

by Oscar Nierstrasz

Seems to parse ok. http://scg.unibe.ch/scgbib?query=Kort08a --- Prof. Dr. O. Nierstrasz -- oscar(a)iam.unibe.ch Software Composition Group -- http://scg.unibe.ch/oscar University of Bern -- Tel/Fax +41 31 631.4618/3355 On 12 Dec 2011, at 20:54, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > I haven't checked closely, but it may comes from the bibitem Kort08a: > > @incollection{Kort08a, > author = {Kortenkamp, David and Simmons, Reid}, > title = {Robotic systems architectures and programming}, > chapter = {8}, > booktitle = {Springer Handbook of Robotics}, > pages = {187--206}, > address = {Berlin, Heidelberg}, > publisher = {Springer}, > doi = {10.1007/978-3-540-30301-5}, > year = {2008}, > keywords = {robotics springer damiencbib}, > isbn = {978-3-540-23957-4} > } > } > > Obviously, there is a mismatch of the curly brackets. But both bibtex and "make test" are happy. Strange. Maybe a white character is somewhere between. > > Cheers, > Alexandre > > On 12 Dec 2011, at 12:50, Oscar Nierstrasz wrote: > >> >> We are using Citezen-Pier to parse the scgbib on our web site. I'm on the Netherlands right now so I cannot check ... >> >> cheers >> on >> >> --- >> Prof. Dr. O. Nierstrasz -- oscar(a)iam.unibe.ch >> Software Composition Group -- http://scg.unibe.ch/oscar >> University of Bern -- Tel/Fax +41 31 631.4618/3355 >> >> >> On 12 Dec 2011, at 12:26, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >>> Hi! >>> >>> Apparently, Citezen does not parse scg.bib (http://scg.unibe.ch/scgbib) The following expression raises an error: CZBibParser parse: (FileStream fileNamed: '/Users/alexandrebergel/Workspace/scgbib/scg.bib') contents >>> >>> Is there something obvious I missed? >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Dec. 13, 2011

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

by Michael Roberts

Hi Mariano, when I read this thread I was a bit confused that you wanted an IdentitySet that used #hash. From that statement it sounded like you just wanted a Set. This would allow any object to define its own hash and importantly what equality means with #=. So if you want to delegate that to the object use a Set. However as the thread has gone on perhaps you want the identity relationship but you just wanted a bigger identity hash space? IdentitySets are fast because they bypass any delegation. Once you have seen the object in your traversal (common usage pattern) that's it. You grab it's identity which is a pretty low level thing to do. As for what happens with collections who knows. Depends. Relying on identity set semantics for a collection is easy. Set semantics is not so. Remember that both hash and equals are important to know if the set already contains the element. Depending on the collection implementation both of these could be composite in terms of the parts. Who knows where you end or how long it takes. I.e. if it is a function of the size of the collection and further collections are composite.... Cheers Mike On Tuesday, December 13, 2011, Carlo <snoobabk(a)yahoo.ie> wrote: > Hi Mariano > I'm no expert either ;) > Without having access to the exact code it would look like either you have a collection that references itself (which would break all collection implementations) or maybe the tests have just slowed down to the point where you think it's 'crashed'. > Do you have anymore info or perhaps which methods you changed on IdentitySet? > Cheers > Carlo > On 13 Dec 2011, at 1:57 AM, Mariano Martinez Peck wrote: > > > 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. 13, 2011

Re: [Pharo-project] native boost is the best thing since COGVM

by Fernando Olivero

Done, indeed it's a better design now! I've removed the NBCairo class, reified almost all Cairo objects as a subclass of NBCairoObject. I've also added CairoText, for easier drawing of text using Cairo Toy Text API. (and CairoLineCap, CairoLineJoin ) All the examples work again, also the new ones. As soon as squeaksource is up again i'll commit. Fernando pd: I will apply the same refactoring to NBPango also. I still have to answer your questions regarding the use of Pango. On Mon, Dec 12, 2011 at 6:44 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 12, 2011, at 5:35 PM, Igor Stasenko wrote: > >> On 12 December 2011 17:16, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>> ok, i see your point. I will refactor back to Javier's approach. >>> My rationale was to reify the Cairo library as it is, luckily all the >>> other examples work. >> >> Well, it makes sense to do things like that, when you want a fast and >> dirty working stuff. >> But a good wrapping makes a lot of difference: there is no need to >> indicate that you using a library >> through 'self cairo' everywhere. It is just an indirection without any benefit. >> >> Wrapper classes and their instances should provide a required >> functionality through well defined protocols, and then from user's >> standpoint it is really >> makes no difference who implements them. >> That's why we need Athens. > > Indeed we do want to have cairo dependencies inside our system > just encapsulated in their respective canvases. > > >>> If i add the shared pool NBCairoTypes to the NBCairo then NativeBoost >>> automatically associates the type? Because i've been putting directly >>> "int". Would be nice to have a couple of examples of NB (whenever the >>> time is enough for you guys, i know you are busy) >>> >> >> Yes, but these examples were written specifically to show how to wrap >> a library in object-oriented way Â :) >> Look at pharo by example book [1], there you can find an explanation >> how to use shared pools. >> Of course it is far from complete, but my opinion that your >> refactoring gives a bad example to future developers. >> They should think in terms of objects and place callouts in >> corresponding classes with nicely formed protocol(s). >> >> I am looking forward for you to come, so i can explain things more >> directly and easier :) >> >> [1] https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Ali… >> >>> thanks for the feedback, >>> Fernando >>> >>> >>> >>> On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> CairoSamplePrograms>>rectangleAndText >>>> does not works, because it uses a following method: >>>> >>>> NBCairo>>selectFont: aFamily slant: slant weight: aWeight on: aNBCairoContext >>>> Â Â Â Â <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >>>> Â Â Â Â ^self call: #(void cairo_select_font_face (NBCairoContext aNBCairoContext, >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â String aFamily, >>>> >>>> cairo_font_slant_t slant, >>>> >>>> cairo_font_weight_t aWeight) ) >>>> >>>> >>>> and during code generation it barks that it unable to resolve >>>> 'cairo_font_slant_t' Â type. >>>> Because NBCairo class does not includes a corresponding shared pool >>>> (NBCairoTypes). >>>> >>>> Also, Fernando, i don't like that you put everything into a single >>>> class (NBCairo). >>>> This is wrong, not object-oriented. The original organization made by >>>> Javier was much more closer to my tastes. >>>> >>>> This approach to wrapping a library is too mechanical. It is much >>>> better to place calls at proper place(s) in proper classes, >>>> rather than putting everything into a single one. Which means that in >>>> this way you are at least 1 message send farther from >>>> real function call. >>>> But in your case its not even that.. >>>> >>>> NBCairoPattern>>status >>>> Â Â Â Â ^ self cairo patternStatusOf: self >>>> >>>> cairo >>>> Â Â Â Â ^ NBCairo default >>>> >>>> so , it is 2 extra message sends, instead of direct call to foreign function! >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Dec. 13, 2011

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

by Carlo

Hi Mariano I'm no expert either ;) Without having access to the exact code it would look like either you have a collection that references itself (which would break all collection implementations) or maybe the tests have just slowed down to the point where you think it's 'crashed'. Do you have anymore info or perhaps which methods you changed on IdentitySet? Cheers Carlo On 13 Dec 2011, at 1:57 AM, Mariano Martinez Peck wrote: 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. 13, 2011

Re: [Pharo-project] [ANN] Eclipse Icons for Pharo

by Fernando Olivero

Nice! As soon as squeaksource is up, i will import them using the icon importer, so we can give them a try. Fernando On Mon, Dec 12, 2011 at 6:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > http://www.famfamfam.com/ > ? > > > >> Hi Fernando, >> >> oops... I forgot your icon importer, sorry :P >> >> I would like âfor a futureâ to integrate it to pharo and replace current ThemeIcons with an icon strategy based on your package... maybe that is the best "future scenario" for icons. >> >> best, >> Esteban >> >> El 11/12/2011, a las 8:49a.m., Fernando Olivero escribiÃ³: >> >>> Hi Esteban, nice work! >>> For importing the icons you can use the toolset i've developed: it >>> automates completely the process of importing a complete set of icons >>> of a given family. >>> >>> ExternalIconFamily @ squeaksource. >>> I've used it for importing the Oxygen icon set, and others (you can >>> google the list for previous related emails). >>> >>> Fernando >>> >>> On Sun, Dec 11, 2011 at 10:38 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Esteban >>>> I know that feeling :) >>>> >>>> :) >>>> Now I'm not sure that I would like to carry the Eclipse License around in Pharo :) >>>> What are the other icons sets we could use with a nice license and we do it :). >>>> famfam? >>>> >>>> We should clean also the old icons because some are really old. >>>> Thanks for pushing that. I would love to have new icons for Pharo. >>>> Stef >>>> >>>> >>>> >>>> On Dec 11, 2011, at 3:15 AM, Esteban Lorenzano wrote: >>>> >>>>> Hi, >>>>> >>>>> Today I was bored and not wanting to think too much... but I wanted to do something for Pharo... and I never liked the current Pharo icons, so I took one icon library I really like and changed all needed icons (well... all that I saw). >>>>> Here a couple of screen shots: >>>>> >>>>> <Captura de pantalla 2011-12-10 a la(s) 23.05.55.png> >>>>> <Captura de pantalla 2011-12-10 a la(s) 23.06.20.png> >>>>> >>>>> Of course, I don't think they are perfect (also maybe I didn't pick the best icons), but I think they look a lot better than the older. >>>>> >>>>> If you want to see how they look, this are the packages: >>>>> >>>>> for Pharo 1.3: >>>>> >>>>> <Eclipse-Icons-EstebanLorenzano.2.mcz> >>>>> >>>>> for Pharo 1.4: >>>>> >>>>> <Eclipse-Icons-EstebanLorenzano.4.mcz> >>>>> >>>>> >>>>> Then you execute: >>>>> >>>>> ThemeIcons initializeIcons. >>>>> World resetWorldMenu. >>>>> >>>>> ... and enjoy your new icons :) >>>>> >>>>> btw... this icons are in an open-source license, the EPL: http://www.eclipse.org/legal/epl-v10.html >>>>> so, maybe âif all agreeâ, we can add this icons to regular distribution :) >>>>> >>>>> best, >>>>> Esteban >>>>> >>>> >>>> >>> >> >> >

Dec. 13, 2011

[Pharo-project] [COTDC] 96 - GZipWriteStream

by DeNigris Sean

94 classes done 16 Packages done 800 classes remaining Continuing in Compression... Today: GZipWriteStream 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 p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Dec. 13, 2011

Re: [Pharo-project] Big Image Tests

by David T. Lewis

On Tue, Dec 13, 2011 at 12:07:59AM +0100, Sven Van Caekenberghe wrote: > Today I tried to find out if it would be possible to allocate a large amount of memory in a VM. > <snip> > > 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 ? Hi Sven, At one time it was possible to get an image up to about 7.5 GB using a 64 bit image and VM, see attached picture. Links and information at <http://squeakvm.org/squeak64> Unfortunately VMMaker has regressed a bit in this regard and I can no longer repeat the experiment. When you see a big integer reported as negative, it is usually because of integer overflow, or from stuffing a large int value into a 32 bit int. Usually this is an issue with variable declarations, e.g. declaring a variable as signed when it is supposed to contain a positive value that may exceed the range of a signed int. Dave

Dec. 13, 2011