[Pharo-project] PharoKernel 13269
Hi I uploaded new set of Pharo images. The generation is now much simpler because Pharo already has all patches necessary for the generation of the kernel image. The Morphic initialization is now better and generated PharoCore image seems to be normally usable. Please try it on the Mac virtual machines. https://gforge.inria.fr/frs/download.php/28664/PharoKernel-13269.zip Cheers, -- Pavel
Thanks a lot pavel We should continue to work on Hazelnuts too. Stef On Jun 21, 2011, at 4:23 PM, Pavel Krivanek wrote:
Hi
I uploaded new set of Pharo images. The generation is now much simpler because Pharo already has all patches necessary for the generation of the kernel image.
The Morphic initialization is now better and generated PharoCore image seems to be normally usable. Please try it on the Mac virtual machines.
https://gforge.inria.fr/frs/download.php/28664/PharoKernel-13269.zip
Cheers, -- Pavel
On 21/06/11 10:23 AM, Pavel Krivanek wrote:
The Morphic initialization is now better and generated PharoCore image seems to be normally usable. Please try it on the Mac virtual machines.
https://gforge.inria.fr/frs/download.php/28664/PharoKernel-13269.zip
Running on: System Version: Mac OS X 10.5.8 (9L30) Kernel Version: Darwin 9.8.0 with Mac VM: http://www.mirandabanda.org/files/Cog/VM/VM.r2434/ the results are as follows. PharoKernel-1.3-13269.image and PharoKernel-Gofer-1.3-13269.image - Drag & drop the image onto Cog app - VM icon appears on dock, Croquet menu appears at top - since it's a headless image, everything seems okay (should have tested with a startup script, and started the vm in a shell terminal) - choose "Quit Croquet" from Apple menu bar, a blank Pharo window pops up. Ctrl-. yields nothing (not surprising in Kernel image, I suppose) - Use Activity Manager utility - "Quit" does not stop the process - "Force Quit" does stop the process PharoKernel-Core-1.3-13269.image - starts up just like the above two images, no Pharo window - choose "Quit Croquet", then blank Pharo window opens, some partial redraws appear - missing sources file report - after adding the sources file, get blank Pharo window - Crtl-. causes a redraw and debugger window to appear - closed the debugger - opened a TestRunner, run all tests - Running 7912 tests, stalled (after 5 or 10 minutes) with: 2635 run, 2593 passes, 31 expected failures, 5 failures, 6 errors, 0 unexpected passes - have to "Force Quit" that image - try again, without running the tests, able to open system browser, transcript, file browser - things seem generally usable (except for the image startup problems)
Thank you very much for the report! -- Pavel On Tue, Jun 21, 2011 at 8:43 PM, Yanni Chiu <yanni@rogers.com> wrote:
On 21/06/11 10:23 AM, Pavel Krivanek wrote:
The Morphic initialization is now better and generated PharoCore image seems to be normally usable. Please try it on the Mac virtual machines.
https://gforge.inria.fr/frs/download.php/28664/PharoKernel-13269.zip
Running on: Â System Version: Â Â Â Mac OS X 10.5.8 (9L30) Â Kernel Version: Â Â Â Darwin 9.8.0
with Mac VM: Â http://www.mirandabanda.org/files/Cog/VM/VM.r2434/
the results are as follows.
PharoKernel-1.3-13269.image and PharoKernel-Gofer-1.3-13269.image  - Drag & drop the image onto Cog app  - VM icon appears on dock, Croquet menu appears at top  - since it's a headless image, everything seems okay (should have tested with a startup script, and started the vm in a shell terminal)  - choose "Quit Croquet" from Apple menu bar, a blank Pharo window pops up. Ctrl-. yields nothing (not surprising in Kernel image, I suppose)  - Use Activity Manager utility - "Quit" does not stop the process  - "Force Quit" does stop the process
PharoKernel-Core-1.3-13269.image  - starts up just like the above two images, no Pharo window  - choose "Quit Croquet", then blank Pharo window opens, some partial redraws appear  - missing sources file report  - after adding the sources file, get blank Pharo window  - Crtl-. causes a redraw and debugger window to appear  - closed the debugger  - opened a TestRunner, run all tests  - Running 7912 tests, stalled (after 5 or 10 minutes) with:   2635 run, 2593 passes, 31 expected failures, 5 failures, 6 errors, 0 unexpected passes  - have to "Force Quit" that image  - try again, without running the tests, able to open system browser, transcript, file browser - things seem generally usable (except for the image startup problems)
what we should pay attention (to be verified) is that igor told me that he does not understand why the latest code of the vm published by eliot does not include some fixes he did for 1.2. May be the code was never integrated. In addition the latest vm produced by eliot does not include a long list of fixes made by igor and mariano. Igor asked in the vm mailing-list what will happen to his changes and there were no reaction so far. So we should pay attention that using the latest vm from eliot may also break our system. We should also think about the fact that may be we will have to burn igor's time to merge vm fixes when other people don't do it. I asked igor to continue to work on the windows build because we want to run regression tests at the VM level. We should be able to trace vm changes and control the impact they have on us and not run after different versions and releases. To have a process in a sense. Stef yeah.. harmonization, it would be good, Eliot if you take a look of changes made in VMMaker-oscog-MarianoMartinezPeck.66 and integrate them, so we will use common version. They have a common ancestor - VMMaker-oscog.54 Without this all of the following work will be lost: Name: VMMaker-oscog-IgorStasenko.54 Author: IgorStasenko Time: 23 March 2011, 5:30:42 pm UUID: c98a0b6c-7f68-4af7-9012-85d3dfdf29ae Ancestors: VMMaker-oscog-IgorStasenko.53 - added disabling module loading support Name: VMMaker-oscog.dtl.56 Author: dtl Time: 4 April 2011, 10:06:00.292 pm UUID: c1d30608-00e8-53b7-209a-34f7a46c1508 Ancestors: VMMaker-IgorStasenko.55 Add tests from VMMaker trunk to document various issues and verify presence of primitives. Name: VMMaker-oscog.dtl.57 Author: dtl Time: 11 April 2011, 10:13:51.668 pm UUID: c1d30608-04dd-53b7-209a-34f7a46c1508 Ancestors: VMMaker-oscog.dtl.56 Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier. Name: VMMaker-oscog-dtl.58 Author: dtl Time: 17 April 2011, 10:22:12.174 pm UUID: c1d30608-04b3-a5b7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.57, VMMaker-oscog.dtl.57 Merge VMMaker-oscog.dtl.57 Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier. Name: VMMaker-oscog-dtl.59 Author: dtl Time: 17 April 2011, 10:32:55.018 pm UUID: c1d30608-042d-4bb7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.58 Merge VMMaker-oscog.dtl.58, and add #primitiveImageFormatVersion Add primitiveMillisecondClockMask, an optional named primitive used in conjunction with primitiveMillisecondClock for duration calculations. The image assumes a value for this constant that is assumed to correspond to the actual value used in the VM. This primitive permits the VM to report the actual value being used. Add primitiveImageFormatVersion, an optional named primitive answering the image format number of the current image. This is the value stored in the first word of an image file header when the image is saved, and possibly modified on image load if the VM adds or removes capabilities for the running image. This primitive was added to VMMaker trunk in VMMaker-dtl.169. Rationale: supports float word order handing for image segments, reference http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html Name: VMMaker-oscog-dtl.64 Author: dtl Time: 21 April 2011, 8:24:32.46 pm UUID: c1d30608-30ec-50b7-208a-31f7a46c1508 Ancestors: VMMaker-oscog-dtl.59 Re-save from VMMaker-oscog-EstebanLorenzano.62 because VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60 were saved without correct ancestry. This version incorporates the changes from VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61, and VMMaker-oscog-dtl.60. Name: VMMaker-oscog-EstebanLorenzano.62 -added ClipboardExtendedPlugin as a regular plugin (taken from the InterpreterVM branch) I don't know if it works right now, but at least it compiles :) Name: VMMaker-oscog-dtl.61 A second batch of updates from VMM trunk, primarily cosmetic but also a class comment update and a couple of methods that had not previously been pragmatized in oscog. Name: VMMaker-oscog-dtl.60 These changes are methods from the main VMM branch for which <#var:#type:> declarations have been formatted with proper spacing. By updating these in the oscog branch, all of these methods are identical in both branches. All changes are cosmetic (no functional changes to the methods). Name: VMMaker-oscog-MarianoMartinezPeck.65 Author: MarianoMartinezPeck Time: 23 April 2011, 1:50:19 pm UUID: 944f5c54-f2f5-4cc7-b693-b4db9320cff8 Ancestors: VMMaker-oscog-dtl.64 blah Name: VMMaker-oscog-MarianoMartinezPeck.66 Author: MarianoMartinezPeck Time: 23 April 2011, 2:17:26 pm UUID: 97bab5b0-51d6-4deb-8b58-5bcedd4747dc Ancestors: VMMaker-oscog-MarianoMartinezPeck.65 Adapt VMMakerTool so that it doesnt try to register in the menu if TheWorldMenu is not present, like the case of Pharo. This change was already integrated in the main trunk of VMMaker but since Eliot forked VMMaker-oscog before that, it was not there. It doesn't affect Squeak -- Best regards, Igor Stasenko AKA sig.
On 21/06/11 3:29 PM, Stéphane Ducasse wrote:
what we should pay attention (to be verified) is that igor told me that he does not understand why the latest code of the vm published by eliot does not include some fixes he did for 1.2. May be the code was never integrated.
Until now (because it's what I got used to doing), I've always gotten Cog VMs from Eliot's site - I forgot about the Hudson builds. I just tried the last successful build of the Cog Mac Cocoa VM - Build #28 (May 18, 2011 4:29:18 AM). I got a vm crash on all the PharoKernel images. VM crashed for other non-Kernel images too, so I think it's a VM problem. I have a slightly older version of MacOSX. ===== Process: CogVM [71927] Path: /Users/yanni/apps/squeakvm/CogVM.app/Contents/MacOS/CogVM Identifier: org.squeakfoundation.Squeak Version: ??? (???) Code Type: X86 (Native) Parent Process: launchd [292] Interval Since Last Report: 656 sec Crashes Since Last Report: 1 Per-App Interval Since Last Report: 0 sec Per-App Crashes Since Last Report: 1 Date/Time: 2011-06-22 00:47:09.876 -0400 OS Version: Mac OS X 10.5.8 (9L30) Report Version: 6 Anonymous UUID: XXXXXXXX Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0 Dyld Error Message: unknown required load command 0x80000022
Hi All, On Tue, Jun 21, 2011 at 12:29 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
what we should pay attention (to be verified) is that igor told me that he does not understand why the latest code of the vm published by eliot does not include some fixes he did for 1.2. May be the code was never integrated. In addition the latest vm produced by eliot does not include a long list of fixes made by igor and mariano. Igor asked in the vm mailing-list what will happen to his changes and there were no reaction so far.
I feel some ownership of the Cog branch. It would be nice to have a chance to review code before it gets in instead of having to merge. You might think of sending me changesets for the more complex sets of changes (e.g. finalization) so that the merge is easier. Finally, you might understand that I'm busy at work and for personal reasons have essentially no time at the weekends to work on Cog. Criticising me in public like this does not make me any more eager to find the time.
So we should pay attention that using the latest vm from eliot may also break our system. We should also think about the fact that may be we will have to burn igor's time to merge vm fixes when other people don't do it. I asked igor to continue to work on the windows build because we want to run regression tests at the VM level. We should be able to trace vm changes and control the impact they have on us and not run after different versions and releases. To have a process in a sense.
Stef
yeah.. harmonization, it would be good, Eliot if you take a look of changes made in VMMaker-oscog-MarianoMartinezPeck.66 and integrate them, so we will use common version.
They have a common ancestor - VMMaker-oscog.54
Without this all of the following work will be lost:
Name: VMMaker-oscog-IgorStasenko.54 Author: IgorStasenko Time: 23 March 2011, 5:30:42 pm UUID: c98a0b6c-7f68-4af7-9012-85d3dfdf29ae Ancestors: VMMaker-oscog-IgorStasenko.53
- added disabling module loading support
Name: VMMaker-oscog.dtl.56 Author: dtl Time: 4 April 2011, 10:06:00.292 pm UUID: c1d30608-00e8-53b7-209a-34f7a46c1508 Ancestors: VMMaker-IgorStasenko.55
Add tests from VMMaker trunk to document various issues and verify presence of primitives.
Name: VMMaker-oscog.dtl.57 Author: dtl Time: 11 April 2011, 10:13:51.668 pm UUID: c1d30608-04dd-53b7-209a-34f7a46c1508 Ancestors: VMMaker-oscog.dtl.56
Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier.
That's already integrated.
Name: VMMaker-oscog-dtl.58 Author: dtl Time: 17 April 2011, 10:22:12.174 pm UUID: c1d30608-04b3-a5b7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.57, VMMaker-oscog.dtl.57
Merge VMMaker-oscog.dtl.57
Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier.
ditto.
Name: VMMaker-oscog-dtl.59 Author: dtl Time: 17 April 2011, 10:32:55.018 pm UUID: c1d30608-042d-4bb7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.58
Merge VMMaker-oscog.dtl.58, and add #primitiveImageFormatVersion
Since there's a VM parameter I question the need for yet-another-primitive.
Add primitiveMillisecondClockMask, an optional named primitive used in conjunction with primitiveMillisecondClock for duration calculations. The image assumes a value for this constant that is assumed to correspond to the actual value used in the VM. This primitive permits the VM to report the actual value being used.
Already integrated.
Add primitiveImageFormatVersion, an optional named primitive answering the image format number of the current image. This is the value stored in the first word of an image file header when the image is saved, and possibly modified on image load if the VM adds or removes capabilities for the running image. This primitive was added to VMMaker trunk in VMMaker-dtl.169. Rationale: supports float word order handing for image segments, reference http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html
Not integrating this. The VM parameter (41) has been in Cog since the beginning. Instead why not merge the VM parameter back into Interpreter?
Name: VMMaker-oscog-dtl.64 Author: dtl Time: 21 April 2011, 8:24:32.46 pm UUID: c1d30608-30ec-50b7-208a-31f7a46c1508 Ancestors: VMMaker-oscog-dtl.59
Re-save from VMMaker-oscog-EstebanLorenzano.62 because VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60 were saved without correct ancestry. This version incorporates the changes from VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61, and VMMaker-oscog-dtl.60.
Name: VMMaker-oscog-EstebanLorenzano.62 -added ClipboardExtendedPlugin as a regular plugin (taken from the InterpreterVM branch) I don't know if it works right now, but at least it compiles :)
Name: VMMaker-oscog-dtl.61 A second batch of updates from VMM trunk, primarily cosmetic but also a class comment update and a couple of methods that had not previously been pragmatized in oscog.
Name: VMMaker-oscog-dtl.60 These changes are methods from the main VMM branch for which <#var:#type:> declarations have been formatted with proper spacing. By updating these in the oscog branch, all of these methods are identical in both branches. All changes are cosmetic (no functional changes to the methods).
Name: VMMaker-oscog-MarianoMartinezPeck.65 Author: MarianoMartinezPeck Time: 23 April 2011, 1:50:19 pm UUID: 944f5c54-f2f5-4cc7-b693-b4db9320cff8 Ancestors: VMMaker-oscog-dtl.64
blah
Name: VMMaker-oscog-MarianoMartinezPeck.66 Author: MarianoMartinezPeck Time: 23 April 2011, 2:17:26 pm UUID: 97bab5b0-51d6-4deb-8b58-5bcedd4747dc Ancestors: VMMaker-oscog-MarianoMartinezPeck.65
Adapt VMMakerTool so that it doesnt try to register in the menu if TheWorldMenu is not present, like the case of Pharo. This change was already integrated in the main trunk of VMMaker but since Eliot forked VMMaker-oscog before that, it was not there.
It doesn't affect Squeak
-- Best regards, Igor Stasenko AKA sig.
-- best, Eliot
I feel some ownership of the Cog branch. It would be nice to have a chance to review code before it gets in instead of having to merge. You might think of sending me changesets for the more complex sets of changes (e.g. finalization) so that the merge is easier. Finally, you might understand that I'm busy at work and for personal reasons have essentially no time at the weekends to work on Cog. Criticising me in public like this does not make me any more eager to find the time.
eliot I understand that. I'm not criticizing but people should be aware that there are differences between VMs and that we can have bugs related to that. I think that igor should know how to play in the vm community. Just tell him that his contributions are not welcomed and we will think about it and do something. After we met this winter I thought it was clear you wanted to collaborate and build a community. I can tell you that I do not like when igor enters my office and tell me that he feels like shit because some of his changes from about a year ago are still not integrated. Stef
So we should pay attention that using the latest vm from eliot may also break our system. We should also think about the fact that may be we will have to burn igor's time to merge vm fixes when other people don't do it. I asked igor to continue to work on the windows build because we want to run regression tests at the VM level. We should be able to trace vm changes and control the impact they have on us and not run after different versions and releases. To have a process in a sense.
Stef
yeah.. harmonization, it would be good, Eliot if you take a look of changes made in VMMaker-oscog-MarianoMartinezPeck.66 and integrate them, so we will use common version.
They have a common ancestor - VMMaker-oscog.54
Without this all of the following work will be lost:
Name: VMMaker-oscog-IgorStasenko.54 Author: IgorStasenko Time: 23 March 2011, 5:30:42 pm UUID: c98a0b6c-7f68-4af7-9012-85d3dfdf29ae Ancestors: VMMaker-oscog-IgorStasenko.53
- added disabling module loading support
Name: VMMaker-oscog.dtl.56 Author: dtl Time: 4 April 2011, 10:06:00.292 pm UUID: c1d30608-00e8-53b7-209a-34f7a46c1508 Ancestors: VMMaker-IgorStasenko.55
Add tests from VMMaker trunk to document various issues and verify presence of primitives.
Name: VMMaker-oscog.dtl.57 Author: dtl Time: 11 April 2011, 10:13:51.668 pm UUID: c1d30608-04dd-53b7-209a-34f7a46c1508 Ancestors: VMMaker-oscog.dtl.56
Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier.
That's already integrated.
Name: VMMaker-oscog-dtl.58 Author: dtl Time: 17 April 2011, 10:22:12.174 pm UUID: c1d30608-04b3-a5b7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.57, VMMaker-oscog.dtl.57
Merge VMMaker-oscog.dtl.57
Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier.
ditto.
Name: VMMaker-oscog-dtl.59 Author: dtl Time: 17 April 2011, 10:32:55.018 pm UUID: c1d30608-042d-4bb7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.58
Merge VMMaker-oscog.dtl.58, and add #primitiveImageFormatVersion
Since there's a VM parameter I question the need for yet-another-primitive.
Add primitiveMillisecondClockMask, an optional named primitive used in conjunction with primitiveMillisecondClock for duration calculations. The image assumes a value for this constant that is assumed to correspond to the actual value used in the VM. This primitive permits the VM to report the actual value being used.
Already integrated.
Add primitiveImageFormatVersion, an optional named primitive answering the image format number of the current image. This is the value stored in the first word of an image file header when the image is saved, and possibly modified on image load if the VM adds or removes capabilities for the running image. This primitive was added to VMMaker trunk in VMMaker-dtl.169. Rationale: supports float word order handing for image segments, reference http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html
Not integrating this. The VM parameter (41) has been in Cog since the beginning. Instead why not merge the VM parameter back into Interpreter?
Name: VMMaker-oscog-dtl.64 Author: dtl Time: 21 April 2011, 8:24:32.46 pm UUID: c1d30608-30ec-50b7-208a-31f7a46c1508 Ancestors: VMMaker-oscog-dtl.59
Re-save from VMMaker-oscog-EstebanLorenzano.62 because VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60 were saved without correct ancestry. This version incorporates the changes from VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61, and VMMaker-oscog-dtl.60.
Name: VMMaker-oscog-EstebanLorenzano.62 -added ClipboardExtendedPlugin as a regular plugin (taken from the InterpreterVM branch) I don't know if it works right now, but at least it compiles :)
Name: VMMaker-oscog-dtl.61 A second batch of updates from VMM trunk, primarily cosmetic but also a class comment update and a couple of methods that had not previously been pragmatized in oscog.
Name: VMMaker-oscog-dtl.60 These changes are methods from the main VMM branch for which <#var:#type:> declarations have been formatted with proper spacing. By updating these in the oscog branch, all of these methods are identical in both branches. All changes are cosmetic (no functional changes to the methods).
Name: VMMaker-oscog-MarianoMartinezPeck.65 Author: MarianoMartinezPeck Time: 23 April 2011, 1:50:19 pm UUID: 944f5c54-f2f5-4cc7-b693-b4db9320cff8 Ancestors: VMMaker-oscog-dtl.64
blah
Name: VMMaker-oscog-MarianoMartinezPeck.66 Author: MarianoMartinezPeck Time: 23 April 2011, 2:17:26 pm UUID: 97bab5b0-51d6-4deb-8b58-5bcedd4747dc Ancestors: VMMaker-oscog-MarianoMartinezPeck.65
Adapt VMMakerTool so that it doesnt try to register in the menu if TheWorldMenu is not present, like the case of Pharo. This change was already integrated in the main trunk of VMMaker but since Eliot forked VMMaker-oscog before that, it was not there.
It doesn't affect Squeak
-- Best regards, Igor Stasenko AKA sig.
-- best, Eliot
On Jun 22, 2011, at 7:07 PM, Eliot Miranda wrote:
Hi All,
On Tue, Jun 21, 2011 at 12:29 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: what we should pay attention (to be verified) is that igor told me that he does not understand why the latest code of the vm published by eliot does not include some fixes he did for 1.2. May be the code was never integrated. In addition the latest vm produced by eliot does not include a long list of fixes made by igor and mariano. Igor asked in the vm mailing-list what will happen to his changes and there were no reaction so far.
I feel some ownership of the Cog branch. It would be nice to have a chance to review code before it gets in instead of having to merge. You might think of sending me changesets for the more complex sets of changes (e.g. finalization) so that the merge is easier. Finally, you might understand that I'm busy at work and for personal reasons have essentially no time at the weekends to work on Cog. Criticising me in public like this does not make me any more eager to find the time.
eliot I understand that. I'm not criticizing but people should be aware that there are differences between VMs and that we can have bugs related to that. I think that igor should know how to play in the vm community. Just tell him that his contributions are not welcomed and we will think about it and do something. After we met this winter I thought it was clear you wanted to collaborate and build a community. I can tell you that I do not like when igor enters my office and tell me that he feels like shit because some of his changes from about a year ago are still not integrated. Stef
So we should pay attention that using the latest vm from eliot may also break our system. We should also think about the fact that may be we will have to burn igor's time to merge vm fixes when other people don't do it. I asked igor to continue to work on the windows build because we want to run regression tests at the VM level. We should be able to trace vm changes and control the impact they have on us and not run after different versions and releases. To have a process in a sense.
Stef
yeah.. harmonization, it would be good, Eliot if you take a look of changes made in VMMaker-oscog-MarianoMartinezPeck.66 and integrate them, so we will use common version.
They have a common ancestor - VMMaker-oscog.54
Without this all of the following work will be lost:
Name: VMMaker-oscog-IgorStasenko.54 Author: IgorStasenko Time: 23 March 2011, 5:30:42 pm UUID: c98a0b6c-7f68-4af7-9012-85d3dfdf29ae Ancestors: VMMaker-oscog-IgorStasenko.53
- added disabling module loading support
Name: VMMaker-oscog.dtl.56 Author: dtl Time: 4 April 2011, 10:06:00.292 pm UUID: c1d30608-00e8-53b7-209a-34f7a46c1508 Ancestors: VMMaker-IgorStasenko.55
Add tests from VMMaker trunk to document various issues and verify presence of primitives.
Name: VMMaker-oscog.dtl.57 Author: dtl Time: 11 April 2011, 10:13:51.668 pm UUID: c1d30608-04dd-53b7-209a-34f7a46c1508 Ancestors: VMMaker-oscog.dtl.56
Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier.
That's already integrated.
Name: VMMaker-oscog-dtl.58 Author: dtl Time: 17 April 2011, 10:22:12.174 pm UUID: c1d30608-04b3-a5b7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.57, VMMaker-oscog.dtl.57
Merge VMMaker-oscog.dtl.57
Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier.
ditto.
Name: VMMaker-oscog-dtl.59 Author: dtl Time: 17 April 2011, 10:32:55.018 pm UUID: c1d30608-042d-4bb7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.58
Merge VMMaker-oscog.dtl.58, and add #primitiveImageFormatVersion
Since there's a VM parameter I question the need for yet-another-primitive.
Add primitiveMillisecondClockMask, an optional named primitive used in conjunction with primitiveMillisecondClock for duration calculations. The image assumes a value for this constant that is assumed to correspond to the actual value used in the VM. This primitive permits the VM to report the actual value being used.
Already integrated.
Add primitiveImageFormatVersion, an optional named primitive answering the image format number of the current image. This is the value stored in the first word of an image file header when the image is saved, and possibly modified on image load if the VM adds or removes capabilities for the running image. This primitive was added to VMMaker trunk in VMMaker-dtl.169. Rationale: supports float word order handing for image segments, reference http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html
Not integrating this. The VM parameter (41) has been in Cog since the beginning. Instead why not merge the VM parameter back into Interpreter?
Name: VMMaker-oscog-dtl.64 Author: dtl Time: 21 April 2011, 8:24:32.46 pm UUID: c1d30608-30ec-50b7-208a-31f7a46c1508 Ancestors: VMMaker-oscog-dtl.59
Re-save from VMMaker-oscog-EstebanLorenzano.62 because VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60 were saved without correct ancestry. This version incorporates the changes from VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61, and VMMaker-oscog-dtl.60.
Name: VMMaker-oscog-EstebanLorenzano.62 -added ClipboardExtendedPlugin as a regular plugin (taken from the InterpreterVM branch) I don't know if it works right now, but at least it compiles :)
Name: VMMaker-oscog-dtl.61 A second batch of updates from VMM trunk, primarily cosmetic but also a class comment update and a couple of methods that had not previously been pragmatized in oscog.
Name: VMMaker-oscog-dtl.60 These changes are methods from the main VMM branch for which <#var:#type:> declarations have been formatted with proper spacing. By updating these in the oscog branch, all of these methods are identical in both branches. All changes are cosmetic (no functional changes to the methods).
Name: VMMaker-oscog-MarianoMartinezPeck.65 Author: MarianoMartinezPeck Time: 23 April 2011, 1:50:19 pm UUID: 944f5c54-f2f5-4cc7-b693-b4db9320cff8 Ancestors: VMMaker-oscog-dtl.64
blah
Name: VMMaker-oscog-MarianoMartinezPeck.66 Author: MarianoMartinezPeck Time: 23 April 2011, 2:17:26 pm UUID: 97bab5b0-51d6-4deb-8b58-5bcedd4747dc Ancestors: VMMaker-oscog-MarianoMartinezPeck.65
Adapt VMMakerTool so that it doesnt try to register in the menu if TheWorldMenu is not present, like the case of Pharo. This change was already integrated in the main trunk of VMMaker but since Eliot forked VMMaker-oscog before that, it was not there.
It doesn't affect Squeak
-- Best regards, Igor Stasenko AKA sig.
-- best, Eliot
Please guys fluidify, it's too damned important. Hilaire Le 23/06/2011 07:50, Stéphane Ducasse a écrit :
On Jun 22, 2011, at 7:07 PM, Eliot Miranda wrote:
Hi All,
On Tue, Jun 21, 2011 at 12:29 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: what we should pay attention (to be verified) is that igor told me that he does not understand why the latest code of the vm published by eliot does not include some fixes he did for 1.2. May be the code was never integrated. In addition the latest vm produced by eliot does not include a long list of fixes made by igor and mariano. Igor asked in the vm mailing-list what will happen to his changes and there were no reaction so far.
I feel some ownership of the Cog branch. It would be nice to have a chance to review code before it gets in instead of having to merge. You might think of sending me changesets for the more complex sets of changes (e.g. finalization) so that the merge is easier. Finally, you might understand that I'm busy at work and for personal reasons have essentially no time at the weekends to work on Cog. Criticising me in public like this does not make me any more eager to find the time.
eliot I understand that. I'm not criticizing but people should be aware that there are differences between VMs and that we can have bugs related to that. I think that igor should know how to play in the vm community. Just tell him that his contributions are not welcomed and we will think about it and do something. After we met this winter I thought it was clear you wanted to collaborate and build a community. I can tell you that I do not like when igor enters my office and tell me that he feels like shit because some of his changes from about a year ago are still not integrated.
Stef
So we should pay attention that using the latest vm from eliot may also break our system. We should also think about the fact that may be we will have to burn igor's time to merge vm fixes when other people don't do it. I asked igor to continue to work on the windows build because we want to run regression tests at the VM level. We should be able to trace vm changes and control the impact they have on us and not run after different versions and releases. To have a process in a sense.
Stef
yeah.. harmonization, it would be good, Eliot if you take a look of changes made in VMMaker-oscog-MarianoMartinezPeck.66 and integrate them, so we will use common version.
They have a common ancestor - VMMaker-oscog.54
Without this all of the following work will be lost:
Name: VMMaker-oscog-IgorStasenko.54 Author: IgorStasenko Time: 23 March 2011, 5:30:42 pm UUID: c98a0b6c-7f68-4af7-9012-85d3dfdf29ae Ancestors: VMMaker-oscog-IgorStasenko.53
- added disabling module loading support
Name: VMMaker-oscog.dtl.56 Author: dtl Time: 4 April 2011, 10:06:00.292 pm UUID: c1d30608-00e8-53b7-209a-34f7a46c1508 Ancestors: VMMaker-IgorStasenko.55
Add tests from VMMaker trunk to document various issues and verify presence of primitives.
Name: VMMaker-oscog.dtl.57 Author: dtl Time: 11 April 2011, 10:13:51.668 pm UUID: c1d30608-04dd-53b7-209a-34f7a46c1508 Ancestors: VMMaker-oscog.dtl.56
Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier.
That's already integrated.
Name: VMMaker-oscog-dtl.58 Author: dtl Time: 17 April 2011, 10:22:12.174 pm UUID: c1d30608-04b3-a5b7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.57, VMMaker-oscog.dtl.57
Merge VMMaker-oscog.dtl.57
Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier.
ditto.
Name: VMMaker-oscog-dtl.59 Author: dtl Time: 17 April 2011, 10:32:55.018 pm UUID: c1d30608-042d-4bb7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.58
Merge VMMaker-oscog.dtl.58, and add #primitiveImageFormatVersion
Since there's a VM parameter I question the need for yet-another-primitive.
Add primitiveMillisecondClockMask, an optional named primitive used in conjunction with primitiveMillisecondClock for duration calculations. The image assumes a value for this constant that is assumed to correspond to the actual value used in the VM. This primitive permits the VM to report the actual value being used.
Already integrated.
Add primitiveImageFormatVersion, an optional named primitive answering the image format number of the current image. This is the value stored in the first word of an image file header when the image is saved, and possibly modified on image load if the VM adds or removes capabilities for the running image. This primitive was added to VMMaker trunk in VMMaker-dtl.169. Rationale: supports float word order handing for image segments, reference http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html
Not integrating this. The VM parameter (41) has been in Cog since the beginning. Instead why not merge the VM parameter back into Interpreter?
Name: VMMaker-oscog-dtl.64 Author: dtl Time: 21 April 2011, 8:24:32.46 pm UUID: c1d30608-30ec-50b7-208a-31f7a46c1508 Ancestors: VMMaker-oscog-dtl.59
Re-save from VMMaker-oscog-EstebanLorenzano.62 because VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60 were saved without correct ancestry. This version incorporates the changes from VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61, and VMMaker-oscog-dtl.60.
Name: VMMaker-oscog-EstebanLorenzano.62 -added ClipboardExtendedPlugin as a regular plugin (taken from the InterpreterVM branch) I don't know if it works right now, but at least it compiles :)
Name: VMMaker-oscog-dtl.61 A second batch of updates from VMM trunk, primarily cosmetic but also a class comment update and a couple of methods that had not previously been pragmatized in oscog.
Name: VMMaker-oscog-dtl.60 These changes are methods from the main VMM branch for which <#var:#type:> declarations have been formatted with proper spacing. By updating these in the oscog branch, all of these methods are identical in both branches. All changes are cosmetic (no functional changes to the methods).
Name: VMMaker-oscog-MarianoMartinezPeck.65 Author: MarianoMartinezPeck Time: 23 April 2011, 1:50:19 pm UUID: 944f5c54-f2f5-4cc7-b693-b4db9320cff8 Ancestors: VMMaker-oscog-dtl.64
blah
Name: VMMaker-oscog-MarianoMartinezPeck.66 Author: MarianoMartinezPeck Time: 23 April 2011, 2:17:26 pm UUID: 97bab5b0-51d6-4deb-8b58-5bcedd4747dc Ancestors: VMMaker-oscog-MarianoMartinezPeck.65
Adapt VMMakerTool so that it doesnt try to register in the menu if TheWorldMenu is not present, like the case of Pharo. This change was already integrated in the main trunk of VMMaker but since Eliot forked VMMaker-oscog before that, it was not there.
It doesn't affect Squeak
-- Best regards, Igor Stasenko AKA sig.
-- best, Eliot
-- Education 0.2 -- http://blog.ofset.org/hilaire
participants (6)
-
Eliot Miranda -
Hilaire Fernandes -
Pavel Krivanek -
stephane ducasse -
Stéphane Ducasse -
Yanni Chiu