I know I already asked this, but I didn't get a working solution. I want to change the default size of the host windows that runs on Pharo. Does someone know how to do that?
I attach the 2 screenshots: what I have, and what I want. Thanks mariano _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
I asked the same question a few weeks back and the only working
solution I found was to patch the window size in the image file. The actual implementation is from Max Leske: http://github.com/renggli/builder/blob/master/scripts/resize-window.sh Lukas 2010/5/16 Mariano Martinez Peck <[hidden email]>: > I know I already asked this, but I didn't get a working solution. I want to > change the default size of the host windows that runs on Pharo. Does someone > know how to do that? > > I attach the 2 screenshots: what I have, and what I want. > > Thanks > > mariano > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <[hidden email]> wrote: I asked the same question a few weeks back and the only working OMG. WHAT A HACK!!!! but works hahahah. I cannot believe such thing could work...but in fact, it does! It is sad this cannot be done with Smalltalk, just evaluating something in the image. Thanks! Mariano Lukas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
>> http://github.com/renggli/builder/blob/master/scripts/resize-window.sh
> > OMG. WHAT A HACK!!!! but works hahahah. I cannot believe such thing could > work...but in fact, it does! > > It is sad this cannot be done with Smalltalk, just evaluating something in > the image. You can resize the window size with the Fenestri plugin, but that does not work if the image is built headless. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
2010/5/16 Mariano Martinez Peck <[hidden email]>
? Why do you assume it can't be done in Smalltalk? shrinkDisplayInImageFile: imageFileName | fs | fs := StandardFileStream fileNamed: imageFileName.
fs binary. [fs position: 24. SmalltalkImage current isLittleEndian ifTrue: [fs nextLittleEndianNumber: 4 put: (1024 bitShift: 16) + 768. "Display size"
fs nextLittleEndianNumber: 4 put: 0. "full-screen flag (off)"] ifFalse: [self error: 'not yet implemented']]
ensure: [fs close]! !
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On May 16, 2010, at 5:52 PM, Eliot Miranda wrote: > > > 2010/5/16 Mariano Martinez Peck <[hidden email]> > > > On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <[hidden email]> wrote: > I asked the same question a few weeks back and the only working > solution I found was to patch the window size in the image file. The > actual implementation is from Max Leske: > > http://github.com/renggli/builder/blob/master/scripts/resize-window.sh > > > OMG. WHAT A HACK!!!! but works hahahah. I cannot believe such thing could work...but in fact, it does! > > It is sad this cannot be done with Smalltalk, just evaluating something in the image. > > ? Why do you assume it can't be done in Smalltalk? > > shrinkDisplayInImageFile: imageFileName > > | fs | > fs := StandardFileStream fileNamed: imageFileName. > fs binary. > [fs position: 24. > SmalltalkImage current isLittleEndian > ifTrue: > [fs nextLittleEndianNumber: 4 put: (1024 bitShift: 16) + 768. "Display size" > fs nextLittleEndianNumber: 4 put: 0. "full-screen flag (off)"] > ifFalse: > [self error: 'not yet implemented']] > ensure: [fs close]! ! What is fun with smalltalk is that now I understand that this information is encoded in the image format :) Now eliot do you think that the vm could expose an API of primitives so that we could script the size of the host window without having to restart the image. because I imagine that we have to. Stef > > > Thanks! > > Mariano > > > > Lukas > > 2010/5/16 Mariano Martinez Peck <[hidden email]>: > > I know I already asked this, but I didn't get a working solution. I want to > > change the default size of the host windows that runs on Pharo. Does someone > > know how to do that? > > > > I attach the 2 screenshots: what I have, and what I want. > > > > Thanks > > > > mariano > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Eliot Miranda-2
2010/5/16 Eliot Miranda <[hidden email]>
Just because we didn't get an answer before ;)
Cool. It works, but ONLY appling it to another image....which in such case I rather shell :( I tried: | fs | fs := StandardFileStream fileNamed: (SmalltalkImage current imageName). fs binary. [fs position: 24. SmalltalkImage current isLittleEndian ifTrue: [fs nextLittleEndianNumber: 4 put: (1024 bitShift: 16) + 768. "Display size" fs nextLittleEndianNumber: 4 put: 0. "full-screen flag (off)"] ifFalse: [self error: 'not yet implemented']] ensure: [fs close] Notice the (SmalltalkImage current imageName). but didn't work. Is this expected? Is there a way to change the current image? Thanks! Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stéphane Ducasse
On Sun, May 16, 2010 at 9:19 AM, Stéphane Ducasse <[hidden email]> wrote:
I don't understand. The VM has the relevant functionality. It is easy to construct a special save-as that resizes the screen (or puts it into full screen mode), saves, and then restores the display to what it was. The above is useful when one wants to change an image file after the fact. And again it is easy to construct a special save-as that saves and then rewrites the image header, which would allow one e.g. to save a large display image file on a small display machine. The KISS principle agues against modifying the VM to take a series of variables that overrode the actual display size on save. If the iage header is well-defined (it hasn't changed in a loooong time) ten the above is fine, no?
BTW, since Cog is using a number of other bits in the full-screen flag word for other values (platform-dependent float order, whether process preemption yields, etc) the above should read something like
seDisplayExtent: extent fullScreen: fullScreenFlag iInImageFile: imageFileName | fs flags | fs := StandardFileStream fileNamed: imageFileName.
fs binary. [fs position: 28. flags := fs nextLittleEndianNumber: 4.
flags := fullScreenFlag ifTrue: [flags bitOr: 1] ifFalse: [flags bitClear: 1]. fs position: 24.
SmalltalkImage current isLittleEndian ifTrue: [fs nextLittleEndianNumber: 4 put: (extent x bitShift: 16) + extent y. "Display size"
fs nextLittleEndianNumber: 4 put: flags.] ifFalse: [self error: 'not yet implemented']]
ensure: [fs close] Find attached on SmalltalkImage class.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project SmalltalkImage class-seDisplayExtentfullScreeniInImageFile.st (1018 bytes) Download Attachment |
oops iInImageFile: => inImageFile:
On Sun, May 16, 2010 at 9:39 AM, Eliot Miranda <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project SmalltalkImage class-seDisplayExtentfullScreeninImageFile.st (1018 bytes) Download Attachment |
Argh! Message to self: never program in bed on a Sunday morning on a 1900x1200 display with inadequate spectacles.
seDisplayExtent: => setDisplayExtent: On Sun, May 16, 2010 at 9:42 AM, Eliot Miranda <[hidden email]> wrote: oops iInImageFile: => inImageFile: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project SmalltalkImage class-setDisplayExtentfullScreeninImageFile.st (996 bytes) Download Attachment |
In reply to this post by Eliot Miranda-2
It still strikes me, why not just simply keep it in special objects in
a first place? stuff := self splObj: #VariousStuff. fullScreen := stuff at: 1. width:=stuff at: 2 .. etc.. 2010/5/16 Eliot Miranda <[hidden email]>: > > > On Sun, May 16, 2010 at 9:19 AM, Stéphane Ducasse > <[hidden email]> wrote: >> >> On May 16, 2010, at 5:52 PM, Eliot Miranda wrote: >> >> > >> > >> > 2010/5/16 Mariano Martinez Peck <[hidden email]> >> > >> > >> > On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <[hidden email]> >> > wrote: >> > I asked the same question a few weeks back and the only working >> > solution I found was to patch the window size in the image file. The >> > actual implementation is from Max Leske: >> > >> > >> > http://github.com/renggli/builder/blob/master/scripts/resize-window.sh >> > >> > >> > OMG. WHAT A HACK!!!! but works hahahah. I cannot believe such thing >> > could work...but in fact, it does! >> > >> > It is sad this cannot be done with Smalltalk, just evaluating something >> > in the image. >> > >> > ? Why do you assume it can't be done in Smalltalk? >> > >> > shrinkDisplayInImageFile: imageFileName >> > >> > | fs | >> > fs := StandardFileStream fileNamed: imageFileName. >> > fs binary. >> > [fs position: 24. >> > SmalltalkImage current isLittleEndian >> > ifTrue: >> > [fs nextLittleEndianNumber: 4 put: (1024 >> > bitShift: 16) + 768. "Display size" >> > fs nextLittleEndianNumber: 4 put: 0. >> > "full-screen flag (off)"] >> > ifFalse: >> > [self error: 'not yet implemented']] >> > ensure: [fs close]! ! >> >> What is fun with smalltalk is that now I understand that this information >> is encoded in the image format :) >> Now eliot do you think that the vm could expose an API of primitives so >> that we could script the size of the host window >> without having to restart the image. because I imagine that we have to. > > I don't understand. The VM has the relevant functionality. It is easy to > construct a special save-as that resizes the screen (or puts it into full > screen mode), saves, and then restores the display to what it was. The > above is useful when one wants to change an image file after the fact. And > again it is easy to construct a special save-as that saves and then rewrites > the image header, which would allow one e.g. to save a large display image > file on a small display machine. The KISS principle agues against modifying > the VM to take a series of variables that overrode the actual display size > on save. If the iage header is well-defined (it hasn't changed in a loooong > time) ten the above is fine, no? > BTW, since Cog is using a number of other bits in the full-screen flag word > for other values (platform-dependent float order, whether process preemption > yields, etc) the above should read something like > seDisplayExtent: extent fullScreen: fullScreenFlag iInImageFile: > imageFileName > | fs flags | > fs := StandardFileStream fileNamed: imageFileName. > fs binary. > [fs position: 28. > flags := fs nextLittleEndianNumber: 4. > flags := fullScreenFlag ifTrue: [flags bitOr: 1] ifFalse: [flags bitClear: > 1]. > fs position: 24. > SmalltalkImage current isLittleEndian > ifTrue: > [fs nextLittleEndianNumber: 4 put: (extent x bitShift: 16) + extent y. > "Display size" > fs nextLittleEndianNumber: 4 put: flags.] > ifFalse: > [self error: 'not yet implemented']] > ensure: [fs close] > Find attached on SmalltalkImage class. >> >> Stef >> > >> > >> > Thanks! >> > >> > Mariano >> > >> > >> > >> > Lukas >> > >> > 2010/5/16 Mariano Martinez Peck <[hidden email]>: >> > > I know I already asked this, but I didn't get a working solution. I >> > > want to >> > > change the default size of the host windows that runs on Pharo. Does >> > > someone >> > > know how to do that? >> > > >> > > I attach the 2 screenshots: what I have, and what I want. >> > > >> > > Thanks >> > > >> > > mariano >> > > >> > > _______________________________________________ >> > > Pharo-project mailing list >> > > [hidden email] >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >> > >> > >> > >> > -- >> > Lukas Renggli >> > www.lukas-renggli.ch >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Eliot Miranda-2
> Argh! Message to self: never program in bed on a Sunday morning on a 1900x1200 display with inadequate spectacles. > > seDisplayExtent: => setDisplayExtent: > > On Sun, May 16, 2010 at 9:42 AM, Eliot Miranda <[hidden email]> wrote: > oops iInImageFile: => inImageFile: :) for me this is more never too late after fixing the house, kids, students, excel,,,.... Friday is usually a bad day for heavy coding at night Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Eliot Miranda-2
elliot
that the format is in the image is good know. Do you know where we can find the information I imagine in VMmaker But sometimes we want to be able to script the image itself without restarting it. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi Steph,
On Sun, May 16, 2010 at 11:24 AM, Stéphane Ducasse <[hidden email]> wrote:
elliot The method is Interpreter>>writeImageFileIO:. Here's the relevant extract from the slightly extended method in Cog:
headerSize := 64. "header size in bytes; do not change!" f := self cCode: 'sqImageFileOpen(imageName, "wb")'.
f = nil ifTrue: "could not open the image file for writing" [^self primitiveFail].
headerStart := self cCode: 'sqImageFileStartLocation(f,imageName,headerSize+imageBytes)'. self cCode: '/* Note: on Unix systems one could put an exec command here, padded to 512 bytes */'.
"position file to start of header" self sqImageFile: f Seek: headerStart.
self putLong: self imageFormatVersion toFile: f. self putLong: headerSize toFile: f.
self putLong: imageBytes toFile: f. self putLong: self startOfMemory toFile: f.
self putLong: specialObjectsOop toFile: f. self putLong: self newObjectHash toFile: f.
self putLong: self ioScreenSize toFile: f. self putLong: self getImageHeaderFlags toFile: f.
self putLong: extraVMMemory toFile: f. self putShort: desiredNumStackPages toFile: f.
self putShort: self unknownShortOrCodeSizeInKs toFile: f. self putLong: desiredEdenBytes toFile: f.
self putShort: (maxExtSemTabSizeSet ifTrue: [self ioGetMaxExtSemTableSize] ifFalse: [0]) toFile: f. self putShort: 0 toFile: f.
1 to: 4 do: [:i | self putLong: 0 toFile: f]. "fill remaining header words with zeros" So the simple header (the header without an initial 512 bytes used on some Mac systems) looks like:
bytes 0 to 3: image version number in either little or big endian order (used to determine header and image byte order) 6504 for 32-bit images
68002 for 64-bit images 6505 for 32-bit Cog images (slightly different compact class layout)
bytes 4 to 7: header size (e.g. 64 bytes) bytes 8 to 11: image size in bytes bytes 12 to 15: address of start of first object in image (nil) when image was saved (*) bytes 16 to 19: address of specialObjectsOop (not start of specialObjectsOop) when image was saved (*)
bytes 20 to 23: next object hash (unused in Cog) bytes 24 to 27: screen width << 16 + screen height big endian: bytes 24 & 25 are width, little endian: bytes 24 & 25 are height
bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 bit 0: 1 => open full screen, 0 => open using width & height
bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) bit 4: 1 => preempting a process does not put it to the back of its run queue bytes 32 to 35: extra vm memory (typically 0) bytes 36 to 37: number of stack pages to allocate
bytes 38 to 39: amount of memory for JITed code in 1024k units (63 MB max) bytes 40 to 43: size of the eden zone
really a value that determines how much memory to allocate before doing an incremental collection bytes 44 to 45: max size of the external semaphore table (64k max)
bytes 46 to 47: 0, reserved for future use bytes 48 to 63: 0, reserved for future use
So e.g. if anyone writes an image modification utility please try and preserve the entirety of the header, modifying only what you need to modify, so as not to break future VMs.
HTH Eliot Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
thanks
On May 17, 2010, at 8:03 PM, Eliot Miranda wrote: > Hi Steph, > > On Sun, May 16, 2010 at 11:24 AM, Stéphane Ducasse <[hidden email]> wrote: > elliot > > that the format is in the image is good know. Do you know where we can find the information I imagine in VMmaker > But sometimes we want to be able to script the image itself without restarting it. > > The method is Interpreter>>writeImageFileIO:. Here's the relevant extract from the slightly extended method in Cog: > > headerSize := 64. "header size in bytes; do not change!" > > f := self cCode: 'sqImageFileOpen(imageName, "wb")'. > f = nil ifTrue: "could not open the image file for writing" > [^self primitiveFail]. > > headerStart := self cCode: 'sqImageFileStartLocation(f,imageName,headerSize+imageBytes)'. > self cCode: '/* Note: on Unix systems one could put an exec command here, padded to 512 bytes */'. > "position file to start of header" > self sqImageFile: f Seek: headerStart. > > self putLong: self imageFormatVersion toFile: f. > self putLong: headerSize toFile: f. > self putLong: imageBytes toFile: f. > self putLong: self startOfMemory toFile: f. > self putLong: specialObjectsOop toFile: f. > self putLong: self newObjectHash toFile: f. > self putLong: self ioScreenSize toFile: f. > self putLong: self getImageHeaderFlags toFile: f. > self putLong: extraVMMemory toFile: f. > self putShort: desiredNumStackPages toFile: f. > self putShort: self unknownShortOrCodeSizeInKs toFile: f. > self putLong: desiredEdenBytes toFile: f. > self putShort: (maxExtSemTabSizeSet ifTrue: [self ioGetMaxExtSemTableSize] ifFalse: [0]) toFile: f. > self putShort: 0 toFile: f. > 1 to: 4 do: [:i | self putLong: 0 toFile: f]. "fill remaining header words with zeros" > > So the simple header (the header without an initial 512 bytes used on some Mac systems) looks like: > > bytes 0 to 3: image version number in either little or big endian order (used to determine header and image byte order) > 6504 for 32-bit images > 68002 for 64-bit images > 6505 for 32-bit Cog images (slightly different compact class layout) > bytes 4 to 7: header size (e.g. 64 bytes) > bytes 8 to 11: image size in bytes > bytes 12 to 15: address of start of first object in image (nil) when image was saved (*) > bytes 16 to 19: address of specialObjectsOop (not start of specialObjectsOop) when image was saved (*) > bytes 20 to 23: next object hash (unused in Cog) > bytes 24 to 27: screen width << 16 + screen height > big endian: bytes 24 & 25 are width, little endian: bytes 24 & 25 are height > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 > bit 0: 1 => open full screen, 0 => open using width & height > bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format > bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls > > bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) > bit 4: 1 => preempting a process does not put it to the back of its run queue > bytes 32 to 35: extra vm memory (typically 0) > bytes 36 to 37: number of stack pages to allocate > bytes 38 to 39: amount of memory for JITed code in 1024k units (63 MB max) > bytes 40 to 43: size of the eden zone > really a value that determines how much memory to allocate before doing an incremental collection > bytes 44 to 45: max size of the external semaphore table (64k max) > bytes 46 to 47: 0, reserved for future use > bytes 48 to 63: 0, reserved for future use > > > So e.g. if anyone writes an image modification utility please try and preserve the entirety of the header, modifying only what you need to modify, so as not to break future VMs. > > > HTH > Eliot > > > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Eliot Miranda-2
On Ma > > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 > bit 0: 1 => open full screen, 0 => open using width & height > bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format > bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls > > bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) > bit 4: 1 => preempting a process does not put it to the back of its run queue I was not clear how to read bit 3: 1 this information is not in the compiledMethods? Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse <[hidden email]> wrote:
For the Cog JIT I want to measure which methods get interpreted to determine the threshold at which to decide to JIT methods. It makes little sense to JIT methods that are large and only executed once, typically class initialization methods. A simple criterion is to set a limit on the number of literals in a method. But I still need to know whether my threshold is affecting frequently used methods. So I added the option of setting the flag bit in any method which the JIT refuses to compile because it has too many literals. Since I need to see which methods are interpreted on start-up putting a flag in the image header was convenient. The effect is that the JIT will set the flag bit on any method it refuses to JIT. I can then browse these in the image and decide whether any are important and adjust the threshold accordingly. Arguably this should be a command line argument, not an image header flag.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/5/17 Eliot Miranda <[hidden email]>:
> > > On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse > <[hidden email]> wrote: >> >> On Ma >> > >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also >> > uses bits 1 through 4 >> > bit 0: 1 => open full screen, 0 => open using width & >> > height >> > bit 1: 1 => image floats are in little-endian format, 0=> >> > image floats are in big-endian format >> > bit 2: 1 => Process's 4th inst var (after myList) is >> > threadId to be used by the VM for overlapped calls >> > >> > bit 3: 1 => set the flag bit on methods that the VM will >> > only interpret (because they're considered too big to JIT) >> > bit 4: 1 => preempting a process does not put it to the >> > back of its run queue >> >> >> I was not clear how to read >> bit 3: 1 >> this information is not in the compiledMethods? > > For the Cog JIT I want to measure which methods get interpreted to determine > the threshold at which to decide to JIT methods. It makes little sense to > JIT methods that are large and only executed once, typically class > initialization methods. A simple criterion is to set a limit on the number > of literals in a method. But I still need to know whether my threshold is > affecting frequently used methods. So I added the option of setting the > flag bit in any method which the JIT refuses to compile because it has too > many literals. Since I need to see which methods are interpreted on > start-up putting a flag in the image header was convenient. The effect is > that the JIT will set the flag bit on any method it refuses to JIT. I can > then browse these in the image and decide whether any are important and > adjust the threshold accordingly. Arguably this should be a command line > argument, not an image header flag. Eliot, i beg you, instead of using an obscure flags in image header, just add (or reserve unused) splObject indice and read/write whatever you want from there. I guess that Cog having substantial changes all around places, so adding a convenient API for VM flags and removing a bit fiddling from image header, would make things transparent and easy to use from language side. >> >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Eliot Miranda-2
this is cool
We could then build tools for you :) Boxes are packages, little squares are classes Blue: classes with no instances Green: classes with instances, but no used Red: classes with instances and at least one used just brainstorming with mariano On May 17, 2010, at 10:40 PM, Eliot Miranda wrote: > > > On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse <[hidden email]> wrote: > > On Ma > > > > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 > > bit 0: 1 => open full screen, 0 => open using width & height > > bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format > > bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls > > > > bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) > > bit 4: 1 => preempting a process does not put it to the back of its run queue > > > I was not clear how to read > bit 3: 1 > this information is not in the compiledMethods? > > For the Cog JIT I want to measure which methods get interpreted to determine the threshold at which to decide to JIT methods. It makes little sense to JIT methods that are large and only executed once, typically class initialization methods. A simple criterion is to set a limit on the number of literals in a method. But I still need to know whether my threshold is affecting frequently used methods. So I added the option of setting the flag bit in any method which the JIT refuses to compile because it has too many literals. Since I need to see which methods are interpreted on start-up putting a flag in the image header was convenient. The effect is that the JIT will set the flag bit on any method it refuses to JIT. I can then browse these in the image and decide whether any are important and adjust the threshold accordingly. Arguably this should be a command line argument, not an image header flag. > > > Stef > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Example2.png (100K) Download Attachment |
2010/5/18 Stéphane Ducasse <[hidden email]>:
> this is cool > We could then build tools for you :) > Boxes are packages, little squares are classes > > > Blue: classes with no instances > Green: classes with instances, but no used > Red: classes with instances and at least one used > > just brainstorming with mariano > Could it draw with pink, the ones who has no instances, but having a methods invocations (an abstract superclasses can have no instances, but can be under heavy use). > > > > > > On May 17, 2010, at 10:40 PM, Eliot Miranda wrote: > >> >> >> On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse <[hidden email]> wrote: >> >> On Ma >> > >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4 >> > bit 0: 1 => open full screen, 0 => open using width & height >> > bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format >> > bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls >> > >> > bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT) >> > bit 4: 1 => preempting a process does not put it to the back of its run queue >> >> >> I was not clear how to read >> bit 3: 1 >> this information is not in the compiledMethods? >> >> For the Cog JIT I want to measure which methods get interpreted to determine the threshold at which to decide to JIT methods. It makes little sense to JIT methods that are large and only executed once, typically class initialization methods. A simple criterion is to set a limit on the number of literals in a method. But I still need to know whether my threshold is affecting frequently used methods. So I added the option of setting the flag bit in any method which the JIT refuses to compile because it has too many literals. Since I need to see which methods are interpreted on start-up putting a flag in the image header was convenient. The effect is that the JIT will set the flag bit on any method it refuses to JIT. I can then browse these in the image and decide whether any are important and adjust the threshold accordingly. Arguably this should be a command line argument, not an image header flag. >> >> >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |