[Pharo-project] how to change the default size of the Pharo host windows?
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
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 <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli@gmail.com> 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. Thanks! Mariano
Lukas
2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>
On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli@gmail.com> 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]! !
Thanks!
Mariano
Lukas
2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <marianopeck@gmail.com>
On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli@gmail.com> 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 <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, May 16, 2010 at 9:19 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
On May 16, 2010, at 5:52 PM, Eliot Miranda wrote:
2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>
On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli@gmail.com>
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 <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
oops iInImageFile: => inImageFile: On Sun, May 16, 2010 at 9:39 AM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Sun, May 16, 2010 at 9:19 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On May 16, 2010, at 5:52 PM, Eliot Miranda wrote:
2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>
On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli@gmail.com>
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 <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <eliot.miranda@gmail.com>wrote:
oops iInImageFile: => inImageFile:
On Sun, May 16, 2010 at 9:39 AM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Sun, May 16, 2010 at 9:19 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On May 16, 2010, at 5:52 PM, Eliot Miranda wrote:
2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>
On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli@gmail.com>
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 <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <eliot.miranda@gmail.com> 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
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 <eliot.miranda@gmail.com>:
On Sun, May 16, 2010 at 9:19 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On May 16, 2010, at 5:52 PM, Eliot Miranda wrote:
2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>
On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli@gmail.com> 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 <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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
Hi Steph, On Sun, May 16, 2010 at 11:24 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/5/17 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/5/17 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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.
SOme times it isn't appropriate to put flags in the special objects array. Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray. For all the flags which can be set in the header I provide access through vmParameterAt:[put:].
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.
Ah, ok. That exists in vmParameterAt:[put:]. i.e. here's what's different in vmParameterAt:put: at Teleplace: VM parameters are numbered as follows: ... 4 allocationCount (read-only; nil in Cog VMs) 5 allocations between GCs (read-write; nil in Cog VMs) ... 41 imageFormatVersion for the VM 42 number of stack pages in use (Cog Stack VM only, otherwise nil) 43 desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil) 44 size of eden, in bytes (Cog VMs only, otherwise nil) 45 desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil) 46 size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil) 47 desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only) 48 various properties of the Cog VM as an integer encoding an array of bit flags. Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative) Bit 1: if set, methods that are interpreted will have the flag bit set in their header Bit 2: if set, implies preempting a process does not put it to the back of its run queue 49-55 reserved for VM parameters that persist in the image (such as eden above) 56 number of process switches since startup (read-only) 57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only) 59 number of check event calls since startup (read-only) 60 number of stack page overflows since startup (read-only; Cog VMs only) 61 number of stack page divorces since startup (read-only; Cog VMs only) 62 compiled code compactions since startup (read-only; Cog only; otherwise nil) 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
cool we could turn them into nice query methods with semantics revealing names :) On May 18, 2010, at 7:21 PM, Eliot Miranda wrote:
On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <siguctua@gmail.com> wrote: 2010/5/17 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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.
SOme times it isn't appropriate to put flags in the special objects array. Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray. For all the flags which can be set in the header I provide access through vmParameterAt:[put:].
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.
Ah, ok. That exists in vmParameterAt:[put:]. i.e. here's what's different in vmParameterAt:put: at Teleplace: VM parameters are numbered as follows: ... 4 allocationCount (read-only; nil in Cog VMs) 5 allocations between GCs (read-write; nil in Cog VMs) ... 41 imageFormatVersion for the VM 42 number of stack pages in use (Cog Stack VM only, otherwise nil) 43 desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil) 44 size of eden, in bytes (Cog VMs only, otherwise nil) 45 desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil) 46 size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil) 47 desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only) 48 various properties of the Cog VM as an integer encoding an array of bit flags. Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative) Bit 1: if set, methods that are interpreted will have the flag bit set in their header Bit 2: if set, implies preempting a process does not put it to the back of its run queue 49-55 reserved for VM parameters that persist in the image (such as eden above) 56 number of process switches since startup (read-only) 57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only) 59 number of check event calls since startup (read-only) 60 number of stack page overflows since startup (read-only; Cog VMs only) 61 number of stack page divorces since startup (read-only; Cog VMs only) 62 compiled code compactions since startup (read-only; Cog only; otherwise nil) 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
cool we could turn them into nice query methods with semantics revealing names :)
I would just use a SHaredPool with class variables appropriately named, e.g. SharedPool subclass: #VMParameterNames instanceVariableNames: '' classVariableNames: '... ImageFormatVersion ...' VMParameterNames class methods for initialization initialize ... ImageFormatVersion := 41 ... then a client would use things like Smalltalk image vmParameterAt: ImageFormatVersion These are for very special uses and I don't really like the idea of making access to them too easy.
On May 18, 2010, at 7:21 PM, Eliot Miranda wrote:
On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
2010/5/17 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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.
SOme times it isn't appropriate to put flags in the special objects array. Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray. For all the flags which can be set in the header I provide access through vmParameterAt:[put:].
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.
Ah, ok. That exists in vmParameterAt:[put:]. i.e. here's what's different in vmParameterAt:put: at Teleplace: VM parameters are numbered as follows: ... 4 allocationCount (read-only; nil in Cog VMs) 5 allocations between GCs (read-write; nil in Cog VMs) ... 41 imageFormatVersion for the VM 42 number of stack pages in use (Cog Stack VM only, otherwise nil) 43 desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil) 44 size of eden, in bytes (Cog VMs only, otherwise nil) 45 desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil) 46 size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil) 47 desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only) 48 various properties of the Cog VM as an integer encoding an array of bit flags. Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative) Bit 1: if set, methods that are interpreted will have the flag bit set in their header Bit 2: if set, implies preempting a process does not put it to the back of its run queue 49-55 reserved for VM parameters that persist in the image (such as eden above) 56 number of process switches since startup (read-only) 57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only) 59 number of check event calls since startup (read-only) 60 number of stack page overflows since startup (read-only; Cog VMs only) 61 number of stack page divorces since startup (read-only; Cog VMs only) 62 compiled code compactions since startup (read-only; Cog only; otherwise nil) 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 18 May 2010 22:17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
cool we could turn them into nice query methods with semantics revealing names :)
I would just use a SHaredPool with class variables appropriately named, e.g. SharedPool subclass: #VMParameterNames instanceVariableNames: '' classVariableNames: '... ImageFormatVersion ...' VMParameterNames class methods for initialization initialize ... ImageFormatVersion := 41 ... then a client would use things like Smalltalk image vmParameterAt:Â ImageFormatVersion These are for very special uses and I don't really like the idea of making access to them too easy.
With such excuse, were ending up with a hacky shell scripts - an ultimately afwul way to access these attributes. It should be easier :) Its been always easy to make a mess: Array setFormat: 88888. Array new. bye-bye vm & image. Just give developers freedom, and then it is their own responsibility to not make mess out of it, not yours. -- Best regards, Igor Stasenko AKA sig.
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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/5/18 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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
Interesting. 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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Tue, May 18, 2010 at 9:52 AM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/5/18 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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
Interesting. 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).
Sorry I forgot to change the colors. Look above to see the references. Cheers Mariano
On May 17, 2010, at 10:40 PM, Eliot Miranda wrote:
On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse <
stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/5/16 Eliot Miranda <eliot.miranda@gmail.com>
2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>
On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli@gmail.com> 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?
Just because we didn't get an answer before ;)
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]! !
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
Thanks!
Mariano
Lukas
2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Eliot Miranda -
Igor Stasenko -
Lukas Renggli -
Mariano Martinez Peck -
Stéphane Ducasse