- Pharo-dev - lists.pharo.org

[Pharo-project] outdated wiki entries

by Camillo Bruni

If I look at the wiki on https://code.google.com/p/pharo/w/list I see a lot of entries that are no longer valid and outdated... I will delete all the entries without changes in the last year and which have no value to developers. If anyone wants these entries back they are safely archived in the google's svn. best cami

Oct. 7, 2012

Re: [Pharo-project] Roassal Survey

by Alexandre Bergel

> Alexandre, I think this example shows what I was badly hinting at with my "ROElement>>mostSpecificParentCommonWith:" thread. This used to decide which level within a hierarchy of sub-element edges are stored. Referring to the first attachement of Cipirian's post "Figure 2(a)", I think in this case the "inner" edges should be stored as part of the "Composite" element, but I think currently they would be stored in the parent of "Composite". if you check the sender of #mostSpecificParentCommonWith: then you will see that only the Mondrian builder makes use of it. Currently, and outside the Mondrian DSL, you can insert the edge where you actually want, independently of its extremities. > Also I had been thinking for a while that it would be nice to be able to have AttachPoints rendered - both as permanently-visible and also visible-on-hover-only, so that when I re-implement the edge rubber-banding to interactive draw lines between elements (which I demoed to you a while ago on Mondrian) the user could drop the edge-end onto a specific AttachPoint. This should be easy to do. However before to work on this, I have a question about what Roassal currently offers. In Roassal, lines knows about the attach points, i.e., the class ROLine has a variable called 'attachPoint', intended to hold an instance of ROAttachPoint. It is therefore not the node the is aware of it. It is more flexible in my opinion than what traditional drawing tools offers. I am wondering whether this is what we really want. Shouldn't the element/node be aware of its attachpoint, instead of its edges? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 7, 2012

Re: [Pharo-project] Fuel for Squeak stupid questions

by Max Leske

The two objects I looked at where a string and an OrderedCollection. I wouldn't conclude that the problem is class specific... On 07.10.2012, at 16:12, "Edgar J. De Cleene" <edgardec2005(a)gmail.com> wrote: > > > > On 10/7/12 10:51 AM, "Max Leske" <maxleske(a)gmail.com> wrote: > > > Following you example, in Squeak FLBasicSerializationTest>>#testDate > > materialized largeIdentityHash = 2571 > > anObject. largeIdentityHash = 1094 > > > So why Date serializaded object gives this and the rest of objects no ? > > Edgar >

Oct. 7, 2012

Re: [Pharo-project] Fuel for Squeak stupid questions

by Edgar J. De Cleene

On 10/7/12 10:51 AM, "Max Leske" <maxleske(a)gmail.com> wrote: Following you example, in Squeak FLBasicSerializationTest>>#testDate > materialized largeIdentityHash = 2571 > > anObject. largeIdentityHash = 1094 > > > So why Date serializaded object gives this and the rest of objects no ? > > Edgar >

Oct. 7, 2012

Re: [Pharo-project] Fuel for Squeak stupid questions

by Max Leske

One cool thing: Cog is roughly 10 times (!!) faster than the SqueakVM I used :D On the down side, I still have the problem described before. Here's some more detail: Screenshot 1 shows the debugger, opened on the method that signalled the error. It also shows the inspector I used to get the #largeIdentityHash of the object (the value is 2062). Screenshot 2 shows a second debugger, that I opened on the expression "objectsIndexes at: anObject". The value of the expression "key largeIdentityHash" is 182 (when it should be 2062). Cheers, Max On 07.10.2012, at 15:34, "Edgar J. De Cleene" <edgardec2005(a)gmail.com> wrote: > > > > On 10/7/12 10:16 AM, "Max Leske" <maxleske(a)gmail.com> wrote: > >> Here's a possibly related question: >> after having analysed a large object graph, I get exceptions in >> FLEncoder>>encodeReferenceTo:. When I look at the values #largeIdentityHash >> generates for that object, then the one looked up in the dictionary (that is >> used by the debugger) is different than the one I get when asking the object >> manually. Incidentally, the manually retrieved value would lead to a match in >> the lookup. Could there be something weird going on with the hashes? >> >> BTW, the VM is a SqueakVM 4.2.5beta1U. I'll also try with a CogVM later and >> let you know if it worked. >> >> Cheers, >> Max > > > Thanks, is a good pointer. > In my case I try with last CogVM > http://www.mirandabanda.org/files/Cog/VM/VM.r2585/ > > Edgar > > >

Oct. 7, 2012

Re: [Pharo-project] Fuel for Squeak stupid questions

by Edgar J. De Cleene

On 10/7/12 10:23 AM, "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: > Hi Edgar. Which version are you using exactly of the package Fuel? > Thanks, >From http://ss3.gemstone.com/ss/Fuel repository/ Open and load ConfigurationOfFuel-MarianoMartinezPeck.153 Then ConfigurationOfFuel load And this is the list of loaded from Monticello Browser * ConfigurationOfFuel (MarianoMartinezPeck.153) Â³marked dirty as I write ConfigurationOfFuel load in the comment Â³ Fuel (MartinDias.685) FuelCompatibilityBeforePharo12 (MartinDias.8) FuelCompatibilityBeforePharo13 (MarianoMartinezPeck.3) FuelCompatibilityBeforePharo14 (MartinDias.3) FuelCompatibilityBeforePharo20 (MartinDias.4) FuelCompatibilityForSqueak (MMP.4) * FuelTests (MartinDias.267) Â³marked dirty as I put a self halt for seeing whatÂ¹s going onÂ² FuelTestsCompatibilityForSqueak (MMP.1) The same on Pharo-1.4-14557 gives all green test Cheers Edgar

Oct. 7, 2012

Re: [Pharo-project] Fuel for Squeak stupid questions

by Edgar J. De Cleene

On 10/7/12 10:16 AM, "Max Leske" <maxleske(a)gmail.com> wrote: > Here's a possibly related question: > after having analysed a large object graph, I get exceptions in > FLEncoder>>encodeReferenceTo:. When I look at the values #largeIdentityHash > generates for that object, then the one looked up in the dictionary (that is > used by the debugger) is different than the one I get when asking the object > manually. Incidentally, the manually retrieved value would lead to a match in > the lookup. Could there be something weird going on with the hashes? > > BTW, the VM is a SqueakVM 4.2.5beta1U. I'll also try with a CogVM later and > let you know if it worked. > > Cheers, > Max Thanks, is a good pointer. In my case I try with last CogVM http://www.mirandabanda.org/files/Cog/VM/VM.r2585/ Edgar

Oct. 7, 2012

Re: [Pharo-project] Fuel for Squeak stupid questions

by Mariano Martinez Peck

Hi Edgar. Which version are you using exactly of the package Fuel? Thanks, On Sun, Oct 7, 2012 at 2:38 PM, Edgar J. De Cleene <edgardec2005(a)gmail.com>wrote: > Hi Mariano: > > > Just have Fuel loaded into Squeak. > Trying to understand , first I run Sunit > The test says 240 run, 231 passes, 2 expected failures, 6 failures, 0 > errors, 1 unexpected passes > > > failures > > FLBasicSerializationTest>>#testDate > FLBasicSerializationTest>>#testGradientFillStyle > FLInMemoryBasicSerializationTest>>#testDate > FLInMemoryBasicSerializationTest>>#testGradientFillStyle > FLMigrationTest>>#testFormatFixedToVariable > FLMigrationTest>>#testFormatVariableToFixed > FLWeakObjectsTest>>#testAssociationWithWeakFinalizationList > > In testDate, clicking in debugger for materialized and for anObject both > shows as Date objects with 14 May 2002 as value. > Could tell why anObject = materialized evaluates to false ? > > Edgar > > -- Mariano http://marianopeck.wordpress.com

Oct. 7, 2012

Re: [Pharo-project] Fuel for Squeak stupid questions

by Max Leske

Here's a possibly related question: after having analysed a large object graph, I get exceptions in FLEncoder>>encodeReferenceTo:. When I look at the values #largeIdentityHash generates for that object, then the one looked up in the dictionary (that is used by the debugger) is different than the one I get when asking the object manually. Incidentally, the manually retrieved value would lead to a match in the lookup. Could there be something weird going on with the hashes? BTW, the VM is a SqueakVM 4.2.5beta1U. I'll also try with a CogVM later and let you know if it worked. Cheers, Max On 07.10.2012, at 14:38, Edgar J. De Cleene <edgardec2005(a)gmail.com> wrote: > Hi Mariano: > > > Just have Fuel loaded into Squeak. > Trying to understand , first I run Sunit > The test says 240 run, 231 passes, 2 expected failures, 6 failures, 0 errors, 1 unexpected passes > > > failures > > FLBasicSerializationTest>>#testDate > FLBasicSerializationTest>>#testGradientFillStyle > FLInMemoryBasicSerializationTest>>#testDate > FLInMemoryBasicSerializationTest>>#testGradientFillStyle > FLMigrationTest>>#testFormatFixedToVariable > FLMigrationTest>>#testFormatVariableToFixed > FLWeakObjectsTest>>#testAssociationWithWeakFinalizationList > > In testDate, clicking in debugger for materialized and for anObject both shows as Date objects with 14 May 2002 as value. > Could tell why anObject = materialized evaluates to false ? > > Edgar >

Oct. 7, 2012

[Pharo-project] Fuel for Squeak stupid questions

by Edgar J. De Cleene

Hi Mariano: Just have Fuel loaded into Squeak. Trying to understand , first I run Sunit The test says 240 run, 231 passes, 2 expected failures, 6 failures, 0 errors, 1 unexpected passes failures FLBasicSerializationTest>>#testDate FLBasicSerializationTest>>#testGradientFillStyle FLInMemoryBasicSerializationTest>>#testDate FLInMemoryBasicSerializationTest>>#testGradientFillStyle FLMigrationTest>>#testFormatFixedToVariable FLMigrationTest>>#testFormatVariableToFixed FLWeakObjectsTest>>#testAssociationWithWeakFinalizationList In testDate, clicking in debugger for materialized and for anObject both shows as Date objects with 14 May 2002 as value. Could tell why anObject = materialized evaluates to false ? Edgar

Oct. 7, 2012