[Pharo-project] Memory usage
Dear pharoers, We are loading really big models in the Moose software analysis platform. This generate a lot of small objects and with the biggest model, we approach the limit of 2Gb of the VM. Is it possible for anyone who knows the VM to add extra memory space ? Going to 4Gb or maybe 8Gb would be a great thing. Thank you for your help. Cheers, --- Jannik Laval
[Pharo-project] how to find the memory size of an object graph
Hi, I have some problems with memory consumption in a Moose model. However, I do not quite know where the memory is spent. To solve this, I would need to know the amount of space occupied by the objects (and all the referenced objects subgraphs). I found ObjectsizeInMemory, but this only shows the size of the current object. What I would need is a graph traversal that does not break on cyclic graphs, and that accumulates the size of the objects. I thought of using Fuel for this. I tried to follow the instructions from here: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/Debugging and work with the debug facilities: (ConfigurationOfFuel project version: '1.8') load: #(FuelDebug). For small examples, it seems to work fine: FLAnalyzer newDefault setDebug; analysisFor: #((1) (2) (3) (4)) However, for larger examples, the process takes forever. Is there another way of approaching this problem? Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-project] how to find the memory size of an object graph
On Mon, Jul 23, 2012 at 9:45 AM, Tudor Girba tu...@tudorgirba.com wrote: Hi, I have some problems with memory consumption in a Moose model. However, I do not quite know where the memory is spent. Even if it is not 100% about YOUR object graph, maybe space tally helps you? Once you have the graph, evaluate: SpaceTally new printSpaceAnalysis and then see the file 'STspace.text'. That may give you an idea of what is going on. To solve this, I would need to know the amount of space occupied by the objects (and all the referenced objects subgraphs). I found ObjectsizeInMemory, but this only shows the size of the current object. What I would need is a graph traversal that does not break on cyclic graphs, and that accumulates the size of the objects. Exactly. Notice also that #sizeInMemory is buggy since it does not take into account padding: 'a' sizeInMemory - 5 but it actually should be 8. There is a method in the VM which answers the exact size...I wonder why we cannot expose that as a primitive I thought of using Fuel for this. I tried to follow the instructions from here: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/Debugging and work with the debug facilities: (ConfigurationOfFuel project version: '1.8') load: #(FuelDebug). For small examples, it seems to work fine: FLAnalyzer newDefault setDebug; analysisFor: #((1) (2) (3) (4)) However, for larger examples, the process takes forever. Yes, it is not useful, because Fuel format has nothing to do. Is there another way of approaching this problem? Here I attach a quick/simple graph traversal. Just subclass and implement #doInterception: Cheers, -- Mariano http://marianopeck.wordpress.com GraphTraverser.st Description: Binary data
[Pharo-project] Change in MCCacheRepository that affects Metacello loading
Hi Dale. http://code.google.com/p/pharo/issues/detail?id=6405 renames MCCacheRepository #default to #uniqueInstance. Therefore, to be able to bootstrap Metacello we need to change: ConfigurationOfMetacello class bootstrapPackage: aString from: aPath | repository version | repository := (*MCCacheRepository uniqueInstance* includesVersionNamed: aString) ifTrue: [*MCCacheRepository uniqueInstance*] ifFalse: [MCHttpRepository location: aPath user: '' password: '']. repository versionReaderForFileNamed: aString , '.mcz' do: [:reader | version := reader version. version load. version workingCopy repositoryGroup addRepository: repository] I could commit, but I don't want to break Metacello loading in other images and I don't know how do you handle these cases. Thanks, -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] fuelized test failures
On Fri, Jul 20, 2012 at 6:09 PM, Camillo Bruni camillobr...@gmail.comwrote: From now on all the test-failures are serialized on the build server. This allows us to quickly find the cause of a failing test: - download the .fuel file for the failing test Where can I find these .fuel of the tests? - materialize the .fuel in the image and debug the code | aContext | aContext := FLMaterializer materializeFromFileNamed: 'PharoDebug.fuel'. Debugger openContext: aContext label: 'This is the new debugger!' contents: nil The serialized stack trace is very limited (generally only 2 contexts) but they are enough to get a decent view on what the variables are -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] fuelized test failures
in the Workspace of the job -- Pavel On Mon, Jul 23, 2012 at 10:22 AM, Mariano Martinez Peck marianop...@gmail.com wrote: On Fri, Jul 20, 2012 at 6:09 PM, Camillo Bruni camillobr...@gmail.com wrote: From now on all the test-failures are serialized on the build server. This allows us to quickly find the cause of a failing test: - download the .fuel file for the failing test Where can I find these .fuel of the tests? - materialize the .fuel in the image and debug the code | aContext | aContext := FLMaterializer materializeFromFileNamed: 'PharoDebug.fuel'. Debugger openContext: aContext label: 'This is the new debugger!' contents: nil The serialized stack trace is very limited (generally only 2 contexts) but they are enough to get a decent view on what the variables are -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] [Moose-dev] Performance of text presentation in Glamour
Hmm, I would like to know the answer as well.
As far as I can tell, the problem is given by transforming the String
into Text, and this is done by PluggableTextMorph.
Does anyone have a clue on how to proceed when we want to display a
large amount of text in a Morph?
Cheers,
Doru
On Mon, Jul 23, 2012 at 5:36 AM, Usman Bhatti usman.bha...@gmail.com wrote:
Hello all,
I am working with text presentation in Glamour: the browser is used to show
the contents of code files. I noted that the time to display the contents of
a file (almost) exponentially grows with the size of the file. So,
performing tests on files of three different sizes, I obtain the following
response times (using Pharo profiler):
1000 lines 2s
2500 lines 11s
3500 lines 23s.
So thats quite lot for me where I occasionally have files with 2K lines and
I may need to browse their contents rapidly.
Running my test script with the profiler in Pharo, I get this tree. I see
that the message fromString: method is sent to Text class several times and
that takes about 96% of the time (in all test cases). Any hints on how to
reduce the number of times the method is invoked by glamour?
tx in advance,
Usman
Trace with 3.5K lines:
- 23669 tallies, 23671 msec.
**Tree**
Process: (40s) 516161536: nil
100.0% {23669ms} GLMTabulator(GLMBrowser)openOn:with:
100.0% {23667ms} GLMTabulator(GLMBrowser)openWith:
100.0% {23667ms} GLMMorphicRendereropen:
91.2% {21577ms} GLMMorphicWindowRenderer
class(GLMMorphicWidgetRenderer class)render:from:
|91.2% {21577ms} GLMMorphicWindowRendererrender:
| 72.3% {17122ms}
GLMSystemWindow(SystemWindow)addMorph:fullFrame:
||72.3% {17122ms} PanelMorphadoptPaneColor:
|| 72.3% {17120ms} PanelMorph(Morph)adoptPaneColor:
||72.3% {17120ms} PanelMorphadoptPaneColor:
|| 72.3% {17120ms} PanelMorph(Morph)color:
||72.3% {17120ms} PanelMorph(Morph)changed
|| 72.3% {17120ms} PanelMorph(Morph)privateFullBounds
||72.3% {17120ms} PanelMorph(Morph)submorphBounds
|| 72.3% {17120ms}
LazyTabGroupMorph(Morph)fullBounds
||72.3% {17120ms}
LazyTabGroupMorph(Morph)doLayoutIn:
|| 65.1% {15418ms} TableLayoutlayout:in:
|||65.1% {15418ms}
TableLayoutlayoutTopToBottom:in:
||| 65.1% {15418ms}
PanelMorph(Morph)layoutInBounds:
|||65.1% {15418ms}
PanelMorph(Morph)bounds:
||| 65.1% {15418ms}
PanelMorph(Morph)position:
|||65.1% {15418ms}
PanelMorph(Morph)fullBounds
||| 65.1% {15418ms}
PanelMorph(Morph)doLayoutIn:
|||65.1% {15418ms}
TableLayoutlayout:in:
||| 65.1% {15418ms}
TableLayoutlayoutTopToBottom:in:
|||65.1% {15418ms}
GLMPluggableTextMorph(Morph)layoutInBounds:
||| 65.1% {15418ms}
GLMPluggableTextMorph(Morph)bounds:
|||65.1% {15418ms}
GLMPluggableTextMorph(PluggableTextMorph)extent:
||| 65.1% {15414ms}
GLMTextMorphForEditView(TextMorph)extent:
|||65.1% {15414ms}
GLMTextMorphForEditView(TextMorph)installEditorToReplace:
||| 65.1% {15414ms}
GLMSmalltalkEditor class(TextEditor class)forMorph:
|||65.1%
{15414ms} GLMSmalltalkEditor(TextEditor)initWithMorph:
||| 65.1%
{15414ms} GLMSmalltalkEditor(TextEditor)resetState
|||65.1%
{15414ms} GLMSmalltalkEditor(TextEditor)paragraph
||| 65.1%
{15414ms} GLMTextMorphForEditView(TextMorphForEditView)paragraph
|||65.1%
{15414ms} GLMTextMorphForEditView(TextMorph)paragraph
|||
65.1% {15414ms} Paragraphcompose:style:from:in:
|||
65.1% {15414ms} ParagraphcomposeAll
|||
65.1% {15414ms}
ParagraphmultiComposeLinesFrom:to:delta:into:priorLines:atY:
|||
65.1% {15414ms}
TextComposermultiComposeLinesFrom:to:delta:into:priorLi...extStyle:text:container:wantsColumnBreaks:
||
Re: [Pharo-project] how to find the memory size of an object graph
On Jul 23, 2012, at 9:55 AM, Mariano Martinez Peck wrote: On Mon, Jul 23, 2012 at 9:45 AM, Tudor Girba tu...@tudorgirba.com wrote: Hi, I have some problems with memory consumption in a Moose model. However, I do not quite know where the memory is spent. Even if it is not 100% about YOUR object graph, maybe space tally helps you? Once you have the graph, evaluate: SpaceTally new printSpaceAnalysis and then see the file 'STspace.text'. That may give you an idea of what is going on. To solve this, I would need to know the amount of space occupied by the objects (and all the referenced objects subgraphs). I found ObjectsizeInMemory, but this only shows the size of the current object. What I would need is a graph traversal that does not break on cyclic graphs, and that accumulates the size of the objects. Exactly. Notice also that #sizeInMemory is buggy since it does not take into account padding: 'a' sizeInMemory - 5 but it actually should be 8. There is a method in the VM which answers the exact size...I wonder why we cannot expose that as a primitive…. Mariano can you open a specific thread on this point because we need better tools. I thought of using Fuel for this. I tried to follow the instructions from here: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/Debugging and work with the debug facilities: (ConfigurationOfFuel project version: '1.8') load: #(FuelDebug). For small examples, it seems to work fine: FLAnalyzer newDefault setDebug; analysisFor: #((1) (2) (3) (4)) However, for larger examples, the process takes forever. Yes, it is not useful, because Fuel format has nothing to do. Is there another way of approaching this problem? Here I attach a quick/simple graph traversal. Just subclass and implement #doInterception: Cheers, -- Mariano http://marianopeck.wordpress.com GraphTraverser.st
Re: [Pharo-project] Change in MCCacheRepository that affects Metacello loading
may be we should rollback this changes because it is not mandatory. Stef On Jul 23, 2012, at 10:14 AM, Mariano Martinez Peck wrote: Hi Dale. http://code.google.com/p/pharo/issues/detail?id=6405 renames MCCacheRepository #default to #uniqueInstance. Therefore, to be able to bootstrap Metacello we need to change: ConfigurationOfMetacello class bootstrapPackage: aString from: aPath | repository version | repository := (MCCacheRepository uniqueInstance includesVersionNamed: aString) ifTrue: [MCCacheRepository uniqueInstance] ifFalse: [MCHttpRepository location: aPath user: '' password: '']. repository versionReaderForFileNamed: aString , '.mcz' do: [:reader | version := reader version. version load. version workingCopy repositoryGroup addRepository: repository] I could commit, but I don't want to break Metacello loading in other images and I don't know how do you handle these cases. Thanks, -- Mariano http://marianopeck.wordpress.com
[Pharo-project] Problem/ommission in Pharo 2.0?
I don't know if that really is a problem. Hoewever in MCCacheRepository there is the default class side message missing. This is needed to load I guess any Metacello package. Regards Friedrich
Re: [Pharo-project] Problem/ommission in Pharo 2.0?
The #default method was renamed to #uniqueInstance. The issue already has been forwarded to Dale to see how we can make metacello load again. Cheers, Guille On Mon, Jul 23, 2012 at 11:44 AM, Friedrich Dominicus fr...@q-software-solutions.de wrote: I don't know if that really is a problem. Hoewever in MCCacheRepository there is the default class side message missing. This is needed to load I guess any Metacello package. Regards Friedrich
Re: [Pharo-project] fuelized test failures
On Sun, Jul 22, 2012 at 11:11 AM, Marcus Denker marcus.den...@inria.frwrote: On Jul 22, 2012, at 10:00 AM, Stéphane Ducasse wrote: I love that scenario :) This is great that powerful tools let us imagine and build solutions that would not be possible before. Power to imagination… And it is an example for a building block that helps to build things. Things that are *impossible* without it. Another way to view Fuel is that of a scientific experiment: We empirically study the existing (ImageSegment). Without pre-concived notions to replace it! (We actually thought ImageSegments would turn out to be the greatest thing ever and just needed some documentation/more understandable implementation). Indeed. I remember my first months in Douai for my PhD making drawings to understand the IS primitives :) And then Martin arrived hahaha. - You study the existing - You claim that you can do better - You do better. And then the next step is *extremeley* importnat: - You prove that it is better for real by *replacing* ALL the existing subsystems that do the same. That last part is very essential: in the end, you often see that it is actually not that easy. That's a real good point. In Spanish I would say Los pingos se ven en la cancha So *replacing* is important. The other thing important is to realize that it enables things that are impossible without. +1 Fuel is getting more and more users. Even in BioInformatics: http://biosmalltalk.blogspot.fr/2012/07/custom-serialization-of-big-dna-or.html http://rmod.lille.inria.fr/web/pier/software/Fuel/Software-using-Fuel Cheers, -- Mariano http://marianopeck.wordpress.com
[Pharo-project] Who wants to do a Spec/Zinc/Fuel experiment? [WAS] Re: fuelized test failures
On Fri, Jul 20, 2012 at 6:09 PM, Camillo Bruni camillobr...@gmail.comwrote: From now on all the test-failures are serialized on the build server. This allows us to quickly find the cause of a failing test: - download the .fuel file for the failing test - materialize the .fuel in the image and debug the code | aContext | aContext := FLMaterializer materializeFromFileNamed: 'PharoDebug.fuel'. Debugger openContext: aContext label: 'This is the new debugger!' contents: nil The serialized stack trace is very limited (generally only 2 contexts) but they are enough to get a decent view on what the variables are I was thinkingit should be really easy to build a very simple UI that: - lets you select/write a Jenkins job and a test - downloads the .fuel - materialize it and open the debugger Anyone interested? Ben do you need another tool for your paper/chapter? ;) Cheers, -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] dirty package
On Jul 23, 2012, at 12:17 PM, Pavel Krivanek wrote: Hi, in the image 20231 on Jenkins there is a dirty package KernelTests. this is fixed in 20232... we really need to get jenkins again to automatically update. -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] athens for strikefonts
Hi, Tudor all. Yes. i will work on that in closest days.. but first i need to finish with the VM update/upgrade cycle, so we could have a better prepared VMs for Athens, SSL on Windows. On 22 July 2012 22:04, Alexandre Bergel alexandre.ber...@me.com wrote: Ah okay. I understand now Alexandre On Jul 22, 2012, at 11:50 AM, Tudor Girba wrote: For the time being, StrikeFonts are the default fonts in Pharo. Given that it is the default it is used in practice all the time, and thus if we want Athens to be adopted easily we need support for the default case. The other solution is to change the default fonts, but this implies that we need to rethink how we distribute it, too, and I guess this will take a while. Cheers, Doru On 22 Jul 2012, at 16:40, Alexandre Bergel wrote: Hi Doru, I am missing why StrikeFonts is so important for Moose. Is it the font used in all other the system? Cheers, Alexandre On Jul 22, 2012, at 5:00 AM, Tudor Girba wrote: Hi Igor, First of all, how was your holidays? :) A while ago, you said that supporting StrikeFonts would not be that difficult. For me it would be important to have this support in order to have a smooth transition to Athens even without Cairo. So, what would it take for this support to happen? Cheers, Doru On 11 Jul 2012, at 09:04, Tudor Girba wrote: Aha. Ok. I will wait. Doru On Wed, Jul 11, 2012 at 8:43 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Good idea if possible. Igor like me is on vacation until 19 of july. On Jul 10, 2012, at 7:07 AM, Tudor Girba wrote: Hi Igor, I just wanted to ask: is the little fix of having Athens work with StrikeFont still on the roadmap :)? As I mentioned before, this would make the adoption easier, because we can switch the Athens even with the regular CogVMs. Cheers, Doru -- www.tudorgirba.com It's not what we do that matters most, it's how we do it. -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com In a world where everything is moving ever faster, one might have better chances to win by moving slower. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Every now and then stop and ask yourself if the war you're fighting is the right one. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Best regards, Igor Stasenko.
Re: [Pharo-project] athens for strikefonts
Sure. I was just pinging to make sure the point does not get lost :) Cheers, Doru On Mon, Jul 23, 2012 at 1:26 PM, Igor Stasenko siguc...@gmail.com wrote: Hi, Tudor all. Yes. i will work on that in closest days.. but first i need to finish with the VM update/upgrade cycle, so we could have a better prepared VMs for Athens, SSL on Windows. On 22 July 2012 22:04, Alexandre Bergel alexandre.ber...@me.com wrote: Ah okay. I understand now Alexandre On Jul 22, 2012, at 11:50 AM, Tudor Girba wrote: For the time being, StrikeFonts are the default fonts in Pharo. Given that it is the default it is used in practice all the time, and thus if we want Athens to be adopted easily we need support for the default case. The other solution is to change the default fonts, but this implies that we need to rethink how we distribute it, too, and I guess this will take a while. Cheers, Doru On 22 Jul 2012, at 16:40, Alexandre Bergel wrote: Hi Doru, I am missing why StrikeFonts is so important for Moose. Is it the font used in all other the system? Cheers, Alexandre On Jul 22, 2012, at 5:00 AM, Tudor Girba wrote: Hi Igor, First of all, how was your holidays? :) A while ago, you said that supporting StrikeFonts would not be that difficult. For me it would be important to have this support in order to have a smooth transition to Athens even without Cairo. So, what would it take for this support to happen? Cheers, Doru On 11 Jul 2012, at 09:04, Tudor Girba wrote: Aha. Ok. I will wait. Doru On Wed, Jul 11, 2012 at 8:43 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Good idea if possible. Igor like me is on vacation until 19 of july. On Jul 10, 2012, at 7:07 AM, Tudor Girba wrote: Hi Igor, I just wanted to ask: is the little fix of having Athens work with StrikeFont still on the roadmap :)? As I mentioned before, this would make the adoption easier, because we can switch the Athens even with the regular CogVMs. Cheers, Doru -- www.tudorgirba.com It's not what we do that matters most, it's how we do it. -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com In a world where everything is moving ever faster, one might have better chances to win by moving slower. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Every now and then stop and ask yourself if the war you're fighting is the right one. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Best regards, Igor Stasenko. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-project] Cairo, VM?
On 9 July 2012 14:31, Hilaire Fernandes hilaire.fernan...@edu.ge.ch wrote: I need to adjust the path to the Cairo lib. Some cleaning seems to be needed as nbLibraryNameOrHandle is redefined several time. Or do I misunderstand something with the Trait ? This trait used by multiple classes. Should be everything ok.. but i will check Hilaire On 07/07/2012 21:53, Igor Stasenko wrote: On 7 July 2012 21:44, Hilaire Fernandes hilaire.fernan...@edu.ge.ch wrote: And for the Linux VM? All are good? linux NBCog should work just fine. Thanks Hilaire On 07/07/2012 06:26, Igor Stasenko wrote: RIght now for macs only.. https://ci.lille.inria.fr/pharo/view/NativeBoost/job/NB-Cog-Mac-Cocoa/29/ (well, actually linux one is *ready* too , you just need to install cairo library by yourself, and even, AFAIK, it is there by default in many linux distros on linux we don't need to care about bundling. -- Dr. Geo -- http://www.drgeo.eu -- Dr. Geo -- http://www.drgeo.eu -- Best regards, Igor Stasenko.
[Pharo-project] How to filter out method extensions in Ring?
Hello all, You may help me on this one. I want to filter out method selectors which are extensions of a particular class. For example, in Pharo 1.4 the ArrayedCollection class has these selectors: ArrayedCollection selectors asSortedCollection I would want all of them except #writeOnGZIPByteStream: which is in Compression package. I did a try to Ring ArrayedCollection selectors asSortedCollection collect: [ : each | RGMethodDefinition class: ArrayedCollection selector: each ] with MethodReference I did : ... ( each category beginsWith: '*' ) not ... but it seems not supported in Ring? Any hints? Cheers, Hernán
Re: [Pharo-project] Memory usage
On Mon, Jul 23, 2012 at 09:26:18AM +0200, jannik.laval wrote: Dear pharoers, We are loading really big models in the Moose software analysis platform. This generate a lot of small objects and with the biggest model, we approach the limit of 2Gb of the VM. Is it possible for anyone who knows the VM to add extra memory space ? Going to 4Gb or maybe 8Gb would be a great thing. It is possible to have an image of at least 7GB (I have done this on my PC with 8GB real memory). Currently this requires tracing the image to a 64-bit object format with SystemTracer, and running the image on an interpreter VM compiled for the 64-bit format. I expect that this will work for Moose in a Pharo image, although performance of the garbage collector is likely to become an issue as the memory grows with lots of smaller objects, and the 64-bit interpreter VM will be significantly slower than a 32-bit Cog VM. If you want to try this with one of your images, I'll try to give you some help. I believe that Eliot has longer term plans for 64-bit object formats, VMs, and improved garbage collectors. Dave
Re: [Pharo-project] Memory usage
The prospect sounds exciting. Jannik, if you do manage to get this to work with Moose, it would be great to document it :) Cheers, Doru On Mon, Jul 23, 2012 at 2:15 PM, David T. Lewis le...@mail.msen.com wrote: On Mon, Jul 23, 2012 at 09:26:18AM +0200, jannik.laval wrote: Dear pharoers, We are loading really big models in the Moose software analysis platform. This generate a lot of small objects and with the biggest model, we approach the limit of 2Gb of the VM. Is it possible for anyone who knows the VM to add extra memory space ? Going to 4Gb or maybe 8Gb would be a great thing. It is possible to have an image of at least 7GB (I have done this on my PC with 8GB real memory). Currently this requires tracing the image to a 64-bit object format with SystemTracer, and running the image on an interpreter VM compiled for the 64-bit format. I expect that this will work for Moose in a Pharo image, although performance of the garbage collector is likely to become an issue as the memory grows with lots of smaller objects, and the 64-bit interpreter VM will be significantly slower than a 32-bit Cog VM. If you want to try this with one of your images, I'll try to give you some help. I believe that Eliot has longer term plans for 64-bit object formats, VMs, and improved garbage collectors. Dave -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-project] Cairo, VM?
Le 23/07/2012 13:38, Igor Stasenko a écrit : This trait used by multiple classes. Should be everything ok.. but i will check I really have to hand edit in several place, and I am pretty sure it is not the intended goal of trait ;-) Not sure what went wrong. Hilaire
Re: [Pharo-project] Change in MCCacheRepository that affects Metacello loading
Yeah, if you could hold off on that change for a bit (this is for Pharo-2.0 right?)...I might have a different solution for Pharo-2.0... Dale - Original Message - | From: Stéphane Ducasse stephane.duca...@inria.fr | To: Pharo-project@lists.gforge.inria.fr | Cc: metace...@googlegroups.com | Sent: Monday, July 23, 2012 1:41:58 AM | Subject: Re: [Pharo-project] Change in MCCacheRepository that affects Metacello loading | | may be we should rollback this changes because it is not mandatory. | | Stef | | On Jul 23, 2012, at 10:14 AM, Mariano Martinez Peck wrote: | | Hi Dale. http://code.google.com/p/pharo/issues/detail?id=6405 | renames MCCacheRepository #default to #uniqueInstance. Therefore, | to be able to bootstrap Metacello we need to change: | | ConfigurationOfMetacello class bootstrapPackage: aString from: | aPath | | repository version | | repository := (MCCacheRepository uniqueInstance | includesVersionNamed: aString) | ifTrue: [MCCacheRepository uniqueInstance] | ifFalse: [MCHttpRepository | location: aPath | user: '' | password: '']. | repository | versionReaderForFileNamed: aString , '.mcz' | do: [:reader | | version := reader version. | version load. | version workingCopy repositoryGroup addRepository: repository] | | I could commit, but I don't want to break Metacello loading in | other images and I don't know how do you handle these cases. | | Thanks, | | | -- | Mariano | http://marianopeck.wordpress.com | | | |
Re: [Pharo-project] Strange behavior of Metacello in Pharo 2.0
Alexandre, Is utterly fail a technical term:)? Do you get a walkback? Do you get an error message? Mariano just posted a message on the Metacello list about changing the protocol on MCCacheDictionary that causes a MNU for #uniqueIntance during the bootstrapping process ... I think that for at least the short term, #uniqueInstace will be restored ... Dale - Original Message - | From: Alexandre Bergel alexandre.ber...@me.com | To: An open mailing list to discuss any topics related to an open-source Smalltalk | Pharo-project@lists.gforge.inria.fr | Sent: Sunday, July 22, 2012 6:35:16 PM | Subject: [Pharo-project] Strange behavior of Metacello in Pharo 2.0 | | Hi! | | I've just downloaded a configuration using monticello browser. In a | workspace I am doing: | -=-=-=-=-=-=-=-=-= | ConfigurationOfVersionner project | -=-=-=-=-=-=-=-=-= | | and apparently Pharo tries to get something from | http://www.squeaksource/MetacelloRepository , which utterly fail. | | | I am using the last Pharo from the forge. | Is there something obvious I am missing? Am I the only one to | experience this? | | Cheers, | Alexandre | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | |
Re: [Pharo-project] [squeak-dev] CompiledMethod#hash broken on CogVM r2559, Win7, Squeak 4.3
On Mon, Jul 23, 2012 at 8:08 PM, Eliot Miranda eliot.mira...@gmail.comwrote:
Hi Marcel,
that's because the old hash method is broken. The Cog VM finally adds
a correct bounds check that prevents byte access to the non-byte parts
(literals) of a CompiledMethod. Accessing the literals of a method via
byte access gives access to the addresses of objects. This is broken since
the GC is a moving garbage collector and so addresses can change. Hence a
hash derived from such bytes is not stable. See Kernel-eem.692 which
provides the attached hash method.
Hi Eliot. I remember seeing this discussion in the Pharo mailing list also.
So...I guess we should commit that also in Pharo, right?
On Sun, Jul 22, 2012 at 7:10 AM, Marcel Taeumel
marcel.taeu...@student.hpi.uni-potsdam.de wrote:
Hi!
It is not possible to compute the hash value of a CompiledMethod instance
with the CogVM r2559 on a Windows 7 machine using a Squeak 4.3 image.
Should it be possible despite of all enhancements in the Cog VM?
Best,
Marcel
22 July 2012 4:06:54.988 pm
VM: Win32 - Smalltalk
Image: Squeak4.3 [latest update: #11860]
SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir C:\Tools\vivide_dev
Trusted Dir C:\Tools\vivide_dev\Marcel
Untrusted Dir C:\Users\Marcel\Documents\My Squeak
CompiledMethod(Object)error:
Receiver: (Morph#drawOn: a CompiledMethod(337))
Arguments and temporary variables:
aString:'subscript is out of bounds: 1'
Receiver's instance variables:
(Morph#drawOn: a CompiledMethod(337))
CompiledMethod(Object)errorSubscriptBounds:
Receiver: (Morph#drawOn: a CompiledMethod(337))
Arguments and temporary variables:
index: 1
Receiver's instance variables:
(Morph#drawOn: a CompiledMethod(337))
CompiledMethod(Object)basicAt:
Receiver: (Morph#drawOn: a CompiledMethod(337))
Arguments and temporary variables:
index: 1
Receiver's instance variables:
(Morph#drawOn: a CompiledMethod(337))
CompiledMethod class(ByteArray class)hashBytes:startingWith:
Receiver: CompiledMethod
Arguments and temporary variables:
aByteArray: (Morph#drawOn: a CompiledMethod(337))
speciesHash:244619647
byteArraySize: 43
hash: 244619647
low:nil
pos:1
Receiver's instance variables:
superclass: ByteArray
methodDict: a MethodDictionary(size 190)
format: 3586
instanceVariables: nil
organization: ('accessing' clearFlag defaultSelector
dragLabel endPC flag
flush...etc...
subclasses: nil
name: #CompiledMethod
classPool: a Dictionary(#LargeFrame-56
#SmallFrame-16 )
sharedPools:nil
environment:Smalltalk globals a SystemDictionary
with lots of globals
category: #'Kernel-Methods'
CompiledMethod(ByteArray)hash
Receiver: (Morph#drawOn: a CompiledMethod(337))
Arguments and temporary variables:
Receiver's instance variables:
(Morph#drawOn: a CompiledMethod(337))
UndefinedObjectDoIt
Receiver: nil
Arguments and temporary variables:
Receiver's instance variables:
nil
Compilerevaluate:in:to:notifying:ifFail:logged:
Receiver: a Compiler
Arguments and temporary variables:
textOrStream: a ReadWriteStream '(Morph#drawOn:) hash'
aContext: nil
receiver: nil
aRequestor: a SmalltalkEditor
failBlock: [closure] in [] in
SmalltalkEditor(TextEditor)evaluateSelectionAnd...etc...
logFlag:true
methodNode: DoIt
^ (Morph #drawOn:) hash
method: (UndefinedObject#DoIt a
CompiledMethod(1506))
value: nil
toLog: nil
itsSelection: nil
itsSelectionString: nil
Receiver's instance variables:
sourceStream: a ReadWriteStream '(Morph#drawOn:) hash'
requestor: a SmalltalkEditor
class: UndefinedObject
category: nil
context:nil
parser: a Parser
[] in SmalltalkEditor(TextEditor)evaluateSelectionAndDo:
Receiver: a SmalltalkEditor
Arguments and temporary variables:
error during printing
Receiver's instance variables:
morph: a TextMorphForEditView(2114)
selectionShowing: false
model: a Workspace
paragraph: a
Re: [Pharo-project] [squeak-dev] CompiledMethod#hash broken on CogVM r2559, Win7, Squeak 4.3
On Mon, Jul 23, 2012 at 11:34 AM, Mariano Martinez Peck
marianop...@gmail.com wrote:
On Mon, Jul 23, 2012 at 8:08 PM, Eliot Miranda eliot.mira...@gmail.comwrote:
Hi Marcel,
that's because the old hash method is broken. The Cog VM finally
adds a correct bounds check that prevents byte access to the non-byte parts
(literals) of a CompiledMethod. Accessing the literals of a method via
byte access gives access to the addresses of objects. This is broken since
the GC is a moving garbage collector and so addresses can change. Hence a
hash derived from such bytes is not stable. See Kernel-eem.692 which
provides the attached hash method.
Hi Eliot. I remember seeing this discussion in the Pharo mailing list
also. So...I guess we should commit that also in Pharo, right?
Yes. Also the bug fixes in Kernel-eem.700 Kernel-eem.703.
On Sun, Jul 22, 2012 at 7:10 AM, Marcel Taeumel
marcel.taeu...@student.hpi.uni-potsdam.de wrote:
Hi!
It is not possible to compute the hash value of a CompiledMethod instance
with the CogVM r2559 on a Windows 7 machine using a Squeak 4.3 image.
Should it be possible despite of all enhancements in the Cog VM?
Best,
Marcel
22 July 2012 4:06:54.988 pm
VM: Win32 - Smalltalk
Image: Squeak4.3 [latest update: #11860]
SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir C:\Tools\vivide_dev
Trusted Dir C:\Tools\vivide_dev\Marcel
Untrusted Dir C:\Users\Marcel\Documents\My Squeak
CompiledMethod(Object)error:
Receiver: (Morph#drawOn: a CompiledMethod(337))
Arguments and temporary variables:
aString:'subscript is out of bounds: 1'
Receiver's instance variables:
(Morph#drawOn: a CompiledMethod(337))
CompiledMethod(Object)errorSubscriptBounds:
Receiver: (Morph#drawOn: a CompiledMethod(337))
Arguments and temporary variables:
index: 1
Receiver's instance variables:
(Morph#drawOn: a CompiledMethod(337))
CompiledMethod(Object)basicAt:
Receiver: (Morph#drawOn: a CompiledMethod(337))
Arguments and temporary variables:
index: 1
Receiver's instance variables:
(Morph#drawOn: a CompiledMethod(337))
CompiledMethod class(ByteArray class)hashBytes:startingWith:
Receiver: CompiledMethod
Arguments and temporary variables:
aByteArray: (Morph#drawOn: a CompiledMethod(337))
speciesHash:244619647
byteArraySize: 43
hash: 244619647
low:nil
pos:1
Receiver's instance variables:
superclass: ByteArray
methodDict: a MethodDictionary(size 190)
format: 3586
instanceVariables: nil
organization: ('accessing' clearFlag defaultSelector
dragLabel endPC flag
flush...etc...
subclasses: nil
name: #CompiledMethod
classPool: a Dictionary(#LargeFrame-56
#SmallFrame-16 )
sharedPools:nil
environment:Smalltalk globals a SystemDictionary
with lots of globals
category: #'Kernel-Methods'
CompiledMethod(ByteArray)hash
Receiver: (Morph#drawOn: a CompiledMethod(337))
Arguments and temporary variables:
Receiver's instance variables:
(Morph#drawOn: a CompiledMethod(337))
UndefinedObjectDoIt
Receiver: nil
Arguments and temporary variables:
Receiver's instance variables:
nil
Compilerevaluate:in:to:notifying:ifFail:logged:
Receiver: a Compiler
Arguments and temporary variables:
textOrStream: a ReadWriteStream '(Morph#drawOn:)
hash'
aContext: nil
receiver: nil
aRequestor: a SmalltalkEditor
failBlock: [closure] in [] in
SmalltalkEditor(TextEditor)evaluateSelectionAnd...etc...
logFlag:true
methodNode: DoIt
^ (Morph #drawOn:) hash
method: (UndefinedObject#DoIt a
CompiledMethod(1506))
value: nil
toLog: nil
itsSelection: nil
itsSelectionString: nil
Receiver's instance variables:
sourceStream: a ReadWriteStream '(Morph#drawOn:)
hash'
requestor: a SmalltalkEditor
class: UndefinedObject
category: nil
context:nil
parser: a Parser
[] in SmalltalkEditor(TextEditor)evaluateSelectionAndDo:
Receiver: a SmalltalkEditor
Arguments and temporary variables:
error during printing
Receiver's instance variables:
morph: a
Re: [Pharo-project] Change in MCCacheRepository that affects Metacello loading
mariano can you create an issue and a fix so that we do not forget. stef On Jul 23, 2012, at 6:24 PM, Dale Henrichs wrote: Yeah, if you could hold off on that change for a bit (this is for Pharo-2.0 right?)...I might have a different solution for Pharo-2.0... Dale - Original Message - | From: Stéphane Ducasse stephane.duca...@inria.fr | To: Pharo-project@lists.gforge.inria.fr | Cc: metace...@googlegroups.com | Sent: Monday, July 23, 2012 1:41:58 AM | Subject: Re: [Pharo-project] Change in MCCacheRepository that affects Metacello loading | | may be we should rollback this changes because it is not mandatory. | | Stef | | On Jul 23, 2012, at 10:14 AM, Mariano Martinez Peck wrote: | | Hi Dale. http://code.google.com/p/pharo/issues/detail?id=6405 | renames MCCacheRepository #default to #uniqueInstance. Therefore, | to be able to bootstrap Metacello we need to change: | | ConfigurationOfMetacello class bootstrapPackage: aString from: | aPath || repository version | |repository := (MCCacheRepository uniqueInstance |includesVersionNamed: aString) |ifTrue: [MCCacheRepository uniqueInstance] |ifFalse: [MCHttpRepository |location: aPath |user: '' |password: '']. |repository |versionReaderForFileNamed: aString , '.mcz' |do: [:reader | |version := reader version. |version load. |version workingCopy repositoryGroup addRepository: repository] | | I could commit, but I don't want to break Metacello loading in | other images and I don't know how do you handle these cases. | | Thanks, | | | -- | Mariano | http://marianopeck.wordpress.com | | | |
