- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Startup Preferences

by Benjamin

New version: Now there is a hierarchy for the setting file - first it lloks in the image diretory for st files - if none is found, it looks into ~/.config/pharo/${VERSION} - if none is found it looks into ~/.config/pharo/general We could also add a look into ~/.pharo/ Gofer new squeaksource: 'StartupPreferences'; package: 'StartupPreferences'; load. Ben On Dec 1, 2011, at 6:50 PM, StÃ©phane Ducasse wrote: > me too. > > Stef > > On Dec 1, 2011, at 6:38 PM, Camillo Bruni wrote: > >> Yeah I would really love to see this. >> >> maybe with a fixed lookup chain >> >> 1. Settings from the Image directory/startup.st >> 2. Settings from ~/.pharo/$VERSION/startup.st >> 3. Settings from ~/.pharo/startup.st >> >> cami >> > >

Dec. 13, 2011

[Pharo-project] Progress bar

by StÃ©phane Ducasse

Hi I was looking how we could improve the situation of the progress bar. We could "simply" remove some annoying updates (I did some first analysis because I got tired of this). I will try to continue so that we have less updates all the times. Now what I see is that there is also an architectural problem. I will try to explain it: each method in different classes (change set, MCloader, FileStream), can be used in different scenarios and depending on the path you want or not to raise feedback. A bad solution would be to duplicate the method and pass a boolean to indicate whether the feedback should be raised or not. Now I have the impression that the architecture should be: - the different part raised events (but this is not clear how) - the top level (the part launching) can absorb and aggregate event to give feedback. I do not know if it makes sense. Do you know how this is done in other systems. Stef

Dec. 13, 2011

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

by Bernat Romagosa

Hi all! Stef, thanks a lot! Actually we've always tried to rather adapt the Scratch code to conform to Pharo, better than the other way around. In some cases this wasn't possible, but we've tried to keep Scat from touching core Pharo code as much as possible. Francois, check out this shot for a preview of what our idea is (not functional at all, just a sketch!) http://i.imgur.com/ApJGd.png Serge, the thing is that the code in Scratch is terribly bad... maintaining it is close to impossible. The project was coded by several different students with different coding styles and barely any Smalltalk experience. They took advantage of bugs in the old Squeak version used to build Scratch, and mixed view and controllers so hard one can barely distinguish them at all. We've made our best to get what we could to work in Pharo, but we never tried to make the code better. What we mean when we say we will not maintain it anymore is that we are not going to perform major fixes to the code any further. We will not waste more time trying to make importing/exporting Scratch files better, or rack our brains to get the sound recorder to work. But if somebody is using the Scat code for some project and needs a small fix which we can help with, we will of course offer our help! After all this time we think the only good approach to enhance the code in Scratch would be to erase it all, rethink it all over and do it right from the beginning, which is the approach the BYOB guys are taking in Berkeley with their Snap project, and the results are so far pretty impressive: http://chirp.scratchr.org/dl/experimental/JsMorphic/nasciturus.html So, what are we to do with all the time and effort we put into Scat? Well, we do have a lot of useful stuff ported to Pharo! We can capture webcam images, we have a graphic block execution engine, a paint editor, a sound engine, etc. So not all efforts have been in vain! Cheers! 2011/12/13 Serge Stinckwich <serge.stinckwich(a)gmail.com> > 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/ > > -- Bernat Romagosa.

Dec. 13, 2011

[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