Hi Nico,
somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds?
cheers, Esteban
On 17 Mar 2016, at 22:49, commits@source.squeak.org wrote:
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732
Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf: version.
=============== Diff against VMMaker.oscog-nice.1732 ===============
Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object access') ----- stSizeOf: oop "Return the number of indexable fields in the receiver"
<doNotGenerate> ^oop basicSize!
2016-03-18 16:00 GMT+01:00 Esteban Lorenzano estebanlm@gmail.com:
Hi Nico,
somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds?
cheers, Esteban
Hi Esteban, Please provide more feedback - can/can't compile ? - VM crash ? instantly or on specific operations ? - all OS or OS specific ? - which flavour - stack/cogit x spur/v3 x 32/64 bits ? I presume cogit-spur-32bits for Pharo head? Maybe a few explanations accompanying a Jenkins link would do it
I've experimented macosx stack spur 64 bits with simulator, and I use most of these changes in my own VM branch, except the fetch64/store64 message sends I'll check ASAP (this will be tonight)
Nicolas
On 17 Mar 2016, at 22:49, commits@source.squeak.org wrote:
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732
Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf: version.
=============== Diff against VMMaker.oscog-nice.1732 ===============
Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object
access') -----
stSizeOf: oop "Return the number of indexable fields in the receiver"
<doNotGenerate> ^oop basicSize!
On 18 Mar 2016, at 16:11, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2016-03-18 16:00 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Hi Nico,
somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds?
cheers, Esteban
Hi Esteban, Please provide more feedback
- can/can't compile ?
- VM crash ? instantly or on specific operations ?
can compile, but image is unusable (no refresh of UI… error with Bitmaps I think).
- all OS or OS specific ?
all environments (mac, linux and win) have this problem.
- which flavour - stack/cogit x spur/v3 x 32/64 bits ? I presume cogit-spur-32bits for Pharo head?
yes
Maybe a few explanations accompanying a Jenkins link would do it
I don’t know what more to say :) but if you download:
wget -O- get.pharo.org/50+vmLatest | bash
and execute it… you will see the problem.
and that does not happens if you execute
wget -O- get.pharo.org/50+vm | bash
(the only difference between those VMs are your commits).
cheers, Esteban
I've experimented macosx stack spur 64 bits with simulator, and I use most of these changes in my own VM branch, except the fetch64/store64 message sends I'll check ASAP (this will be tonight)
Nicolas
On 17 Mar 2016, at 22:49, commits@source.squeak.org mailto:commits@source.squeak.org wrote:
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732
Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf: version.
=============== Diff against VMMaker.oscog-nice.1732 ===============
Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object access') ----- stSizeOf: oop "Return the number of indexable fields in the receiver"
<doNotGenerate> ^oop basicSize!
Hi Esteban,
On Mar 18, 2016, at 8:23 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 18 Mar 2016, at 16:11, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2016-03-18 16:00 GMT+01:00 Esteban Lorenzano estebanlm@gmail.com:
Hi Nico,
somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds?
cheers, Esteban
Hi Esteban, Please provide more feedback
- can/can't compile ?
- VM crash ? instantly or on specific operations ?
can compile, but image is unusable (no refresh of UI… error with Bitmaps I think).
- all OS or OS specific ?
all environments (mac, linux and win) have this problem.
- which flavour - stack/cogit x spur/v3 x 32/64 bits ? I presume cogit-spur-32bits for Pharo head?
yes
Maybe a few explanations accompanying a Jenkins link would do it
I don’t know what more to say :) but if you download:
wget -O- get.pharo.org/50+vmLatest | bash
and execute it… you will see the problem.
and that does not happens if you execute
wget -O- get.pharo.org/50+vm | bash
(the only difference between those VMs are your commits).
Some things to try (Clément is across the hall; he can help)
1. build an assert-enabled VM and run this. You may get very useful error information. You can use the -trace flag to get it to output the sends the VM makes and see where the first error is
2. Open the image in the simulator, but that may be difficult with pharo cuz it uses so many external libraries. Nite that you can still, with a little effort, do this but you have to write the plugin simulation code that maps from calls in the simulator to calls against the host VM's facilities. For example, in the simulator the FilePluginSimulator defers to the host Smalltalk system to access files so the simulated VM can still access files just like the real VM, which defers to the stdio library or win32 APIs to access files.
The simulator is not just worth maintaining it is /essential/ to being able to debug the VM effectively. It should be a goal to have the Pharo image runnable in the simulator.
cheers, Esteban
I've experimented macosx stack spur 64 bits with simulator, and I use most of these changes in my own VM branch, except the fetch64/store64 message sends I'll check ASAP (this will be tonight)
Nicolas
On 17 Mar 2016, at 22:49, commits@source.squeak.org wrote:
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732
Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf: version.
=============== Diff against VMMaker.oscog-nice.1732 ===============
Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object access') ----- stSizeOf: oop "Return the number of indexable fields in the receiver"
<doNotGenerate> ^oop basicSize!
On 18 Mar 2016, at 16:56, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Mar 18, 2016, at 8:23 AM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
On 18 Mar 2016, at 16:11, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com> wrote:
2016-03-18 16:00 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Hi Nico,
somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds?
cheers, Esteban
Hi Esteban, Please provide more feedback
- can/can't compile ?
- VM crash ? instantly or on specific operations ?
can compile, but image is unusable (no refresh of UI… error with Bitmaps I think).
- all OS or OS specific ?
all environments (mac, linux and win) have this problem.
- which flavour - stack/cogit x spur/v3 x 32/64 bits ? I presume cogit-spur-32bits for Pharo head?
yes
Maybe a few explanations accompanying a Jenkins link would do it
I don’t know what more to say :) but if you download:
wget -O- get.pharo.org/50+vmLatest http://get.pharo.org/50+vmLatest | bash
and execute it… you will see the problem.
and that does not happens if you execute
wget -O- get.pharo.org/50+vm http://get.pharo.org/50+vm | bash
(the only difference between those VMs are your commits).
Some things to try (Clément is across the hall; he can help)
no, today I’m not there :)
- build an assert-enabled VM and run this. You may get very useful error information. You can use the -trace flag to get it to output the sends the VM makes and see where the first error is
that’s the first thing I did… it does not says anything :( The only information I have is a stack trace:
Bitmap(Object)>>error: Bitmap(Object)>>errorImproperStore Bitmap(Object)>>at:put: Bitmap class(ArrayedCollection class)>>with: Color>>bitPatternForDepth: Form>>bitPatternFor: BitBlt>>fillColor: BitBlt>>setDestForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: BitBlt class>>destForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: Form(DisplayMedium)>>fillShape:fillColor:at: Form(DisplayMedium)>>fillShape:fillColor: CursorWithMask>>asCursorForm HandMorph>>showTemporaryCursor:hotSpotOffset: HandMorph>>showTemporaryCursor: RubEditingArea(RubAbstractTextArea)>>showOverEditableTextCursor RubEditingArea(RubAbstractTextArea)>>mouseEnter: RubEditingArea(Morph)>>handleMouseEnter: MouseMoveEvent(MouseEvent)>>sentTo: MouseMoveEvent>>sentTo: RubEditingArea(Morph)>>handleEvent: MouseOverHandler>>transform:from:andSendTo: [ self transform: evt from: anEvent andSendTo: aLeftMorph ] in MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: in Block: [ self transform: evt from: anEvent andSendTo: aLe...etc... True>>ifTrue:ifFalse: MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: [ :anEnteredMorph | self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: anEvent ifNotFocusedDo: [ ] ] in MouseOverHandler>>handleAsMouseEnter: in Block: [ :anEnteredMorph | ... Array(SequenceableCollection)>>reverseDo: MouseOverHandler>>handleAsMouseEnter: MouseOverHandler>>processMouseOver: HandMorph>>handleEvent: HandMorph>>processEvents
cheers, Esteban
- Open the image in the simulator, but that may be difficult with pharo cuz it uses so many external libraries. Nite that you can still, with a little effort, do this but you have to write the plugin simulation code that maps from calls in the simulator to calls against the host VM's facilities. For example, in the simulator the FilePluginSimulator defers to the host Smalltalk system to access files so the simulated VM can still access files just like the real VM, which defers to the stdio library or win32 APIs to access files.
The simulator is not just worth maintaining it is /essential/ to being able to debug the VM effectively. It should be a goal to have the Pharo image runnable in the simulator.
cheers, Esteban
I've experimented macosx stack spur 64 bits with simulator, and I use most of these changes in my own VM branch, except the fetch64/store64 message sends I'll check ASAP (this will be tonight)
Nicolas
On 17 Mar 2016, at 22:49, commits@source.squeak.org mailto:commits@source.squeak.org wrote:
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732
Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf: version.
=============== Diff against VMMaker.oscog-nice.1732 ===============
Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object access') ----- stSizeOf: oop "Return the number of indexable fields in the receiver"
<doNotGenerate> ^oop basicSize!
Hi Esteban,
On Fri, Mar 18, 2016 at 9:27 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 18 Mar 2016, at 16:56, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Mar 18, 2016, at 8:23 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 18 Mar 2016, at 16:11, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2016-03-18 16:00 GMT+01:00 Esteban Lorenzano estebanlm@gmail.com:
Hi Nico,
somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds?
cheers, Esteban
Hi Esteban, Please provide more feedback
can/can't compile ?
VM crash ? instantly or on specific operations ?
can compile, but image is unusable (no refresh of UI… error with Bitmaps I think).
- all OS or OS specific ?
all environments (mac, linux and win) have this problem.
which flavour - stack/cogit x spur/v3 x 32/64 bits ?
I presume cogit-spur-32bits for Pharo head?
yes
Maybe a few explanations accompanying a Jenkins link would do it
I don’t know what more to say :) but if you download:
wget -O- get.pharo.org/50+vmLatest | bash
and execute it… you will see the problem.
and that does not happens if you execute
wget -O- get.pharo.org/50+vm | bash
(the only difference between those VMs are your commits).
Some things to try (Clément is across the hall; he can help)
no, today I’m not there :)
- build an assert-enabled VM and run this. You may get very useful error
information. You can use the -trace flag to get it to output the sends the VM makes and see where the first error is
that’s the first thing I did… it does not says anything :( The only information I have is a stack trace:
So start the assert VM under gdb or lldb. Put a breakpoint in the function "warning" and run it with "run -breaksel errorImproperStore" and the VM will breakpoint in warning when errorImproperStore is sent.
Now get a C backtrace and see if the VM is in the interpreter or if in machine code. If in interpreter walk up the C stack until you're in the function interpret then use "call shortPrintFrameAndCallers(localFP)" to get the backtrace of frames. If this fails, rerun using a debug VM (localFP may be optimised and so it may work only in the unoptimised debug VM).
If not in the interpreter (there will be some weird call stack pointing back into form frame that won't have a name, but just an address), use "call printStackCallStack()" to get the backtrace.
Now, once you have located the frame for Bitmap(Object)>>at:put:, use "call printFrame(TheFramePointerValue)" to print the frame in detail, including arguments, temporaries and stack contents, etc. That should show you what the argument is and whether there's a bug in Bitmap>>at:put; or some other bug. You can print the sender frame by using the "saved fp" value. You should be able to narrow down that cause a lot using these functions. It's not a patch on the Smalltalk debugger; it's slow and error prone, but you can debug images that won't start. It's much easier in the simulator, but possible in gdb/lldb.
Good luck!
Bitmap(Object)>>error: Bitmap(Object)>>errorImproperStore Bitmap(Object)>>at:put: Bitmap class(ArrayedCollection class)>>with: Color>>bitPatternForDepth: Form>>bitPatternFor: BitBlt>>fillColor:
BitBlt>>setDestForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: BitBlt class>>destForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: Form(DisplayMedium)>>fillShape:fillColor:at: Form(DisplayMedium)>>fillShape:fillColor: CursorWithMask>>asCursorForm HandMorph>>showTemporaryCursor:hotSpotOffset: HandMorph>>showTemporaryCursor: RubEditingArea(RubAbstractTextArea)>>showOverEditableTextCursor RubEditingArea(RubAbstractTextArea)>>mouseEnter: RubEditingArea(Morph)>>handleMouseEnter: MouseMoveEvent(MouseEvent)>>sentTo: MouseMoveEvent>>sentTo: RubEditingArea(Morph)>>handleEvent: MouseOverHandler>>transform:from:andSendTo: [ self transform: evt from: anEvent andSendTo: aLeftMorph ] in MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: in Block: [ self transform: evt from: anEvent andSendTo: aLe...etc... True>>ifTrue:ifFalse: MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: [ :anEnteredMorph | self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: anEvent ifNotFocusedDo: [ ] ] in MouseOverHandler>>handleAsMouseEnter: in Block: [ :anEnteredMorph | ... Array(SequenceableCollection)>>reverseDo: MouseOverHandler>>handleAsMouseEnter: MouseOverHandler>>processMouseOver: HandMorph>>handleEvent: HandMorph>>processEvents
cheers, Esteban
- Open the image in the simulator, but that may be difficult with pharo
cuz it uses so many external libraries. Nite that you can still, with a little effort, do this but you have to write the plugin simulation code that maps from calls in the simulator to calls against the host VM's facilities. For example, in the simulator the FilePluginSimulator defers to the host Smalltalk system to access files so the simulated VM can still access files just like the real VM, which defers to the stdio library or win32 APIs to access files.
The simulator is not just worth maintaining it is /essential/ to being able to debug the VM effectively. It should be a goal to have the Pharo image runnable in the simulator.
cheers, Esteban
I've experimented macosx stack spur 64 bits with simulator, and I use most of these changes in my own VM branch, except the fetch64/store64 message sends I'll check ASAP (this will be tonight)
Nicolas
On 17 Mar 2016, at 22:49, commits@source.squeak.org wrote:
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732
Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf: version.
=============== Diff against VMMaker.oscog-nice.1732 ===============
Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object
access') -----
stSizeOf: oop "Return the number of indexable fields in the receiver"
<doNotGenerate> ^oop basicSize!
Esteban I confirm that this happens on 32bits squeak.stack.spur too. I already got this error before in my branch, I think I forgot to apply one change. I'm looking now
2016-03-18 20:46 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Esteban,
On Fri, Mar 18, 2016 at 9:27 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 18 Mar 2016, at 16:56, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Mar 18, 2016, at 8:23 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 18 Mar 2016, at 16:11, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2016-03-18 16:00 GMT+01:00 Esteban Lorenzano estebanlm@gmail.com:
Hi Nico,
somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds?
cheers, Esteban
Hi Esteban, Please provide more feedback
can/can't compile ?
VM crash ? instantly or on specific operations ?
can compile, but image is unusable (no refresh of UI… error with Bitmaps I think).
- all OS or OS specific ?
all environments (mac, linux and win) have this problem.
which flavour - stack/cogit x spur/v3 x 32/64 bits ?
I presume cogit-spur-32bits for Pharo head?
yes
Maybe a few explanations accompanying a Jenkins link would do it
I don’t know what more to say :) but if you download:
wget -O- get.pharo.org/50+vmLatest | bash
and execute it… you will see the problem.
and that does not happens if you execute
wget -O- get.pharo.org/50+vm | bash
(the only difference between those VMs are your commits).
Some things to try (Clément is across the hall; he can help)
no, today I’m not there :)
- build an assert-enabled VM and run this. You may get very useful
error information. You can use the -trace flag to get it to output the sends the VM makes and see where the first error is
that’s the first thing I did… it does not says anything :( The only information I have is a stack trace:
So start the assert VM under gdb or lldb. Put a breakpoint in the function "warning" and run it with "run -breaksel errorImproperStore" and the VM will breakpoint in warning when errorImproperStore is sent.
Now get a C backtrace and see if the VM is in the interpreter or if in machine code. If in interpreter walk up the C stack until you're in the function interpret then use "call shortPrintFrameAndCallers(localFP)" to get the backtrace of frames. If this fails, rerun using a debug VM (localFP may be optimised and so it may work only in the unoptimised debug VM).
If not in the interpreter (there will be some weird call stack pointing back into form frame that won't have a name, but just an address), use "call printStackCallStack()" to get the backtrace.
Now, once you have located the frame for Bitmap(Object)>>at:put:, use "call printFrame(TheFramePointerValue)" to print the frame in detail, including arguments, temporaries and stack contents, etc. That should show you what the argument is and whether there's a bug in Bitmap>>at:put; or some other bug. You can print the sender frame by using the "saved fp" value. You should be able to narrow down that cause a lot using these functions. It's not a patch on the Smalltalk debugger; it's slow and error prone, but you can debug images that won't start. It's much easier in the simulator, but possible in gdb/lldb.
Good luck!
Bitmap(Object)>>error: Bitmap(Object)>>errorImproperStore Bitmap(Object)>>at:put: Bitmap class(ArrayedCollection class)>>with: Color>>bitPatternForDepth: Form>>bitPatternFor: BitBlt>>fillColor:
BitBlt>>setDestForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: BitBlt class>>destForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: Form(DisplayMedium)>>fillShape:fillColor:at: Form(DisplayMedium)>>fillShape:fillColor: CursorWithMask>>asCursorForm HandMorph>>showTemporaryCursor:hotSpotOffset: HandMorph>>showTemporaryCursor: RubEditingArea(RubAbstractTextArea)>>showOverEditableTextCursor RubEditingArea(RubAbstractTextArea)>>mouseEnter: RubEditingArea(Morph)>>handleMouseEnter: MouseMoveEvent(MouseEvent)>>sentTo: MouseMoveEvent>>sentTo: RubEditingArea(Morph)>>handleEvent: MouseOverHandler>>transform:from:andSendTo: [ self transform: evt from: anEvent andSendTo: aLeftMorph ] in MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: in Block: [ self transform: evt from: anEvent andSendTo: aLe...etc... True>>ifTrue:ifFalse: MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: [ :anEnteredMorph | self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: anEvent ifNotFocusedDo: [ ] ] in MouseOverHandler>>handleAsMouseEnter: in Block: [ :anEnteredMorph | ... Array(SequenceableCollection)>>reverseDo: MouseOverHandler>>handleAsMouseEnter: MouseOverHandler>>processMouseOver: HandMorph>>handleEvent: HandMorph>>processEvents
cheers, Esteban
- Open the image in the simulator, but that may be difficult with pharo
cuz it uses so many external libraries. Nite that you can still, with a little effort, do this but you have to write the plugin simulation code that maps from calls in the simulator to calls against the host VM's facilities. For example, in the simulator the FilePluginSimulator defers to the host Smalltalk system to access files so the simulated VM can still access files just like the real VM, which defers to the stdio library or win32 APIs to access files.
The simulator is not just worth maintaining it is /essential/ to being able to debug the VM effectively. It should be a goal to have the Pharo image runnable in the simulator.
cheers, Esteban
I've experimented macosx stack spur 64 bits with simulator, and I use most of these changes in my own VM branch, except the fetch64/store64 message sends I'll check ASAP (this will be tonight)
Nicolas
On 17 Mar 2016, at 22:49, commits@source.squeak.org wrote:
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732
Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf:
version.
=============== Diff against VMMaker.oscog-nice.1732 ===============
Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object
access') -----
stSizeOf: oop "Return the number of indexable fields in the receiver"
<doNotGenerate> ^oop basicSize!-- _,,,^..^,,,_ best, Eliot
Ah got it in http://smalltalkhub.com/mc/nice/NiceVMExperiments/main -------------------------------------- Name: VMMaker.oscog-nice.1515 Author: nice Time: 9 November 2015, 12:16:42.195 am UUID: 120aa03b-9686-4219-bd35-0e90011f64be Ancestors: VMMaker.oscog-nice.1514
Fix spurious signed/unsigned BUG I reintroduced by restoring Eliot's positive32BitIntegerFor: version
The main symptom is Bitmap improper store... ...due to (65536 bitOr: (65536 bitShift: 16)) answering -1... -------------------------------------- But the diff did not help, I must track further
2016-03-18 21:07 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Esteban I confirm that this happens on 32bits squeak.stack.spur too. I already got this error before in my branch, I think I forgot to apply one change. I'm looking now
2016-03-18 20:46 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Esteban,
On Fri, Mar 18, 2016 at 9:27 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 18 Mar 2016, at 16:56, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Mar 18, 2016, at 8:23 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 18 Mar 2016, at 16:11, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2016-03-18 16:00 GMT+01:00 Esteban Lorenzano estebanlm@gmail.com:
Hi Nico,
somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds?
cheers, Esteban
Hi Esteban, Please provide more feedback
can/can't compile ?
VM crash ? instantly or on specific operations ?
can compile, but image is unusable (no refresh of UI… error with Bitmaps I think).
- all OS or OS specific ?
all environments (mac, linux and win) have this problem.
which flavour - stack/cogit x spur/v3 x 32/64 bits ?
I presume cogit-spur-32bits for Pharo head?
yes
Maybe a few explanations accompanying a Jenkins link would do it
I don’t know what more to say :) but if you download:
wget -O- get.pharo.org/50+vmLatest | bash
and execute it… you will see the problem.
and that does not happens if you execute
wget -O- get.pharo.org/50+vm | bash
(the only difference between those VMs are your commits).
Some things to try (Clément is across the hall; he can help)
no, today I’m not there :)
- build an assert-enabled VM and run this. You may get very useful
error information. You can use the -trace flag to get it to output the sends the VM makes and see where the first error is
that’s the first thing I did… it does not says anything :( The only information I have is a stack trace:
So start the assert VM under gdb or lldb. Put a breakpoint in the function "warning" and run it with "run -breaksel errorImproperStore" and the VM will breakpoint in warning when errorImproperStore is sent.
Now get a C backtrace and see if the VM is in the interpreter or if in machine code. If in interpreter walk up the C stack until you're in the function interpret then use "call shortPrintFrameAndCallers(localFP)" to get the backtrace of frames. If this fails, rerun using a debug VM (localFP may be optimised and so it may work only in the unoptimised debug VM).
If not in the interpreter (there will be some weird call stack pointing back into form frame that won't have a name, but just an address), use "call printStackCallStack()" to get the backtrace.
Now, once you have located the frame for Bitmap(Object)>>at:put:, use "call printFrame(TheFramePointerValue)" to print the frame in detail, including arguments, temporaries and stack contents, etc. That should show you what the argument is and whether there's a bug in Bitmap>>at:put; or some other bug. You can print the sender frame by using the "saved fp" value. You should be able to narrow down that cause a lot using these functions. It's not a patch on the Smalltalk debugger; it's slow and error prone, but you can debug images that won't start. It's much easier in the simulator, but possible in gdb/lldb.
Good luck!
Bitmap(Object)>>error: Bitmap(Object)>>errorImproperStore Bitmap(Object)>>at:put: Bitmap class(ArrayedCollection class)>>with: Color>>bitPatternForDepth: Form>>bitPatternFor: BitBlt>>fillColor:
BitBlt>>setDestForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: BitBlt class>>destForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect: Form(DisplayMedium)>>fillShape:fillColor:at: Form(DisplayMedium)>>fillShape:fillColor: CursorWithMask>>asCursorForm HandMorph>>showTemporaryCursor:hotSpotOffset: HandMorph>>showTemporaryCursor: RubEditingArea(RubAbstractTextArea)>>showOverEditableTextCursor RubEditingArea(RubAbstractTextArea)>>mouseEnter: RubEditingArea(Morph)>>handleMouseEnter: MouseMoveEvent(MouseEvent)>>sentTo: MouseMoveEvent>>sentTo: RubEditingArea(Morph)>>handleEvent: MouseOverHandler>>transform:from:andSendTo: [ self transform: evt from: anEvent andSendTo: aLeftMorph ] in MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: in Block: [ self transform: evt from: anEvent andSendTo: aLe...etc... True>>ifTrue:ifFalse: MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: [ :anEnteredMorph | self inform: asMouseEnterEvent to: anEnteredMorph originatedFrom: anEvent ifNotFocusedDo: [ ] ] in MouseOverHandler>>handleAsMouseEnter: in Block: [ :anEnteredMorph | ... Array(SequenceableCollection)>>reverseDo: MouseOverHandler>>handleAsMouseEnter: MouseOverHandler>>processMouseOver: HandMorph>>handleEvent: HandMorph>>processEvents
cheers, Esteban
- Open the image in the simulator, but that may be difficult with pharo
cuz it uses so many external libraries. Nite that you can still, with a little effort, do this but you have to write the plugin simulation code that maps from calls in the simulator to calls against the host VM's facilities. For example, in the simulator the FilePluginSimulator defers to the host Smalltalk system to access files so the simulated VM can still access files just like the real VM, which defers to the stdio library or win32 APIs to access files.
The simulator is not just worth maintaining it is /essential/ to being able to debug the VM effectively. It should be a goal to have the Pharo image runnable in the simulator.
cheers, Esteban
I've experimented macosx stack spur 64 bits with simulator, and I use most of these changes in my own VM branch, except the fetch64/store64 message sends I'll check ASAP (this will be tonight)
Nicolas
On 17 Mar 2016, at 22:49, commits@source.squeak.org wrote:
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732
Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf:
version.
=============== Diff against VMMaker.oscog-nice.1732 ===============
Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object
access') -----
stSizeOf: oop "Return the number of indexable fields in the receiver"
<doNotGenerate> ^oop basicSize!-- _,,,^..^,,,_ best, Eliot
I wonder why you do not check our builds before pushing a change. Staging changes can make sure that we control the propagation of errors. And as you know, error = time = money. This is always difficult for someone to try to understand error that he had no clue from where they come.
Stef
Stephane, that's my fault and I apologize.This time, i've not put enough effort before the commit. Instead i've put excessive confidence in the simulator and my previous work in own branch. I can only commit nightly, so effectively, it can cost a day before I correct my mistakes.
HOWEVER, may I remind you the combinatorial: (spur,v3) x (interpreter,cogit) x (32,64bits) x (mac,win,linux,...) x (squeak,pharo,newspeak) not speaking of ARM, android free bsd etc... How do you conceivably expect that a single contributor like me would perform tests for each and every configuration? You naturally put YOUR build above every other, but to me this has no more value than anyone else bias.
Performing that bunch of tests is not human, only a bot can do it. Isn't it what the Jenkins architecture is all about? Incorrect commit are correctly detected and should remain unused. The commiter should be notified, and that was the case. So what do you want more? Everyone else duplicating this effort?
Ggit would help managing development with branches, but we are not there currently, so please revise your standards.
You know that I'm not found of the break it first, fix it later strategy. Though it sometimes happen that I get caught. Here it sounds like you are not granting to me this right to break things when in the same time this right is totally abused in every day Pharo development... So despite the fact that you are completely right this time, I'd say that I would have been more inclined to take the lesson I deserved from say Eliot ;)
I'm taking too much time writing this when there's probably more trouble with the spur VM currently and that ain't good. Stephane, I like your energy, and I wish I could use and promote Pharo, but please, keep it positive :) Tonight, you gave me bad vibrations :(
Nicolas
2016-03-18 22:13 GMT+01:00 stephane ducasse stephane.ducasse@gmail.com:
I wonder why you do not check our builds before pushing a change. Staging changes can make sure that we control the propagation of errors. And as you know, error = time = money. This is always difficult for someone to try to understand error that he had no clue from where they come.
Stef
On 19 Mar 2016, at 01:23, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Stephane, that's my fault and I apologize.This time, i've not put enough effort before the commit. Instead i've put excessive confidence in the simulator and my previous work in own branch. I can only commit nightly, so effectively, it can cost a day before I correct my mistakes.
HOWEVER, may I remind you the combinatorial: (spur,v3) x (interpreter,cogit) x (32,64bits) x (mac,win,linux,...) x (squeak,pharo,newspeak) not speaking of ARM, android free bsd etc... How do you conceivably expect that a single contributor like me would perform tests for each and every configuration? You naturally put YOUR build above every other, but to me this has no more value than anyone else bias.
I paid igor during six months to have this infrastructure and people can take it and run away with it and use it for there own needs. And instead of taking advantages we got “oh this is for pharo”. With clement we are checking the kind of slaves we can put in place to tests his crazy tests. Because against combinatorial there is machines and automated process.
Performing that bunch of tests is not human, only a bot can do it. Isn't it what the Jenkins architecture is all about? Incorrect commit are correctly detected and should remain unused. The commiter should be notified, and that was the case. So what do you want more? Everyone else duplicating this effort?
Ggit would help managing development with branches, but we are not there currently, so please revise your standards.
Esteban is managing all with git just because this is easier and empowering us. Moving a project to git is not that a big deal. I hate git API personnally but I imagine that git should not be a problem for people mastering VM. So I do not see the point. The problem here is not technological. But again we are free not to use the tools that can empower us. But then in that case why using VMmaker and not plain C. You see this is the same argument.
You know that I'm not found of the break it first, fix it later strategy. Though it sometimes happen that I get caught. Here it sounds like you are not granting to me this right to break things when in the same time this right is totally abused in every day Pharo development... So despite the fact that you are completely right this time, I'd say that I would have been more inclined to take the lesson I deserved from say Eliot ;)
This is not a question of lesson taken this is a economical point. Within a year esteban will leave in another place and have its own company and run for money and the question is should he spent time trying to understand and fix things that a simple farm of machine could have caught?
I'm taking too much time writing this when there's probably more trouble with the spur VM currently and that ain't good. Stephane, I like your energy, and I wish I could use and promote Pharo, but please, keep it positive :) Tonight, you gave me bad vibrations :(
You see you do not understand my message. So let us not change anything and continue to work like that since this is perfect.
Nicolas
2016-03-18 22:13 GMT+01:00 stephane ducasse <stephane.ducasse@gmail.com mailto:stephane.ducasse@gmail.com>:
I wonder why you do not check our builds before pushing a change. Staging changes can make sure that we control the propagation of errors. And as you know, error = time = money. This is always difficult for someone to try to understand error that he had no clue from where they come.
Stef
On Mar 18, 2016, at 11:21 PM, stephane ducasse stephane.ducasse@gmail.com wrote:
On 19 Mar 2016, at 01:23, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Stephane, that's my fault and I apologize.This time, i've not put enough effort before the commit. Instead i've put excessive confidence in the simulator and my previous work in own branch. I can only commit nightly, so effectively, it can cost a day before I correct my mistakes.
HOWEVER, may I remind you the combinatorial: (spur,v3) x (interpreter,cogit) x (32,64bits) x (mac,win,linux,...) x (squeak,pharo,newspeak) not speaking of ARM, android free bsd etc... How do you conceivably expect that a single contributor like me would perform tests for each and every configuration? You naturally put YOUR build above every other, but to me this has no more value than anyone else bias.
I paid igor during six months to have this infrastructure and people can take it and run away with it and use it for there own needs. And instead of taking advantages we got “oh this is for pharo”. With clement we are checking the kind of slaves we can put in place to tests his crazy tests. Because against combinatorial there is machines and automated process.
but you never thought to have Igor consult me and come up with a build structure is be happy with. And I'm not happy with the VM infrastructure in the Pharo build and I hope that we can agree on a single build infrastructure, which clearly separates C VM generation from C VM compilation.
Performing that bunch of tests is not human, only a bot can do it. Isn't it what the Jenkins architecture is all about? Incorrect commit are correctly detected and should remain unused. The commiter should be notified, and that was the case. So what do you want more? Everyone else duplicating this effort?
Ggit would help managing development with branches, but we are not there currently, so please revise your standards.
Esteban is managing all with git just because this is easier and empowering us. Moving a project to git is not that a big deal. I hate git API personnally but I imagine that git should not be a problem for people mastering VM. So I do not see the point. The problem here is not technological. But again we are free not to use the tools that can empower us. But then in that case why using VMmaker and not plain C. You see this is the same argument.
You know that I'm not found of the break it first, fix it later strategy. Though it sometimes happen that I get caught. Here it sounds like you are not granting to me this right to break things when in the same time this right is totally abused in every day Pharo development... So despite the fact that you are completely right this time, I'd say that I would have been more inclined to take the lesson I deserved from say Eliot ;)
This is not a question of lesson taken this is a economical point. Within a year esteban will leave in another place and have its own company and run for money and the question is should he spent time trying to understand and fix things that a simple farm of machine could have caught?
I'm taking too much time writing this when there's probably more trouble with the spur VM currently and that ain't good. Stephane, I like your energy, and I wish I could use and promote Pharo, but please, keep it positive :) Tonight, you gave me bad vibrations :(
You see you do not understand my message. So let us not change anything and continue to work like that since this is perfect.
Nicolas
2016-03-18 22:13 GMT+01:00 stephane ducasse stephane.ducasse@gmail.com:
I wonder why you do not check our builds before pushing a change. Staging changes can make sure that we control the propagation of errors. And as you know, error = time = money. This is always difficult for someone to try to understand error that he had no clue from where they come.
Stef
I paid igor during six months to have this infrastructure and people can take it and run away with it and use it for there own needs. And instead of taking advantages we got “oh this is for pharo”. With clement we are checking the kind of slaves we can put in place to tests his crazy tests. Because against combinatorial there is machines and automated process.
but you never thought to have Igor consult me and come up with a build structure is be happy with. And I'm not happy with the VM infrastructure in the Pharo build and I hope that we can agree on a single build infrastructure, which clearly separates C VM generation from C VM compilation.
well I’m not sure that we should reopen such period because I do not think that we are the bad guys in the story.
Two points
You know that I'm not found of the break it first, fix it later strategy.
I have no problem with that. I have problem that automated tests do not catch it to free programmers and brain.
Though it sometimes happen that I get caught. Here it sounds like you are not granting to me this right to break things when in the same time this right is totally abused in every day Pharo development…
You see in Pharo our process is stagged. If the tests to not run, the tests is not in. For example this year we did not integrate Epicea and marcus tried 15 times (for real 15 times) this is just that you did not see it. Now we break things because we do not have enough tests and UI/widgets is not covered.
So despite the fact that you are completely right this time, I'd say that I would have been more inclined to take the lesson I deserved from say Eliot ;)
I'm taking too much time writing this when there's probably more trouble with the spur VM currently and that ain't good. Stephane, I like your energy, and I wish I could use and promote Pharo, but please, keep it positive :) Tonight, you gave me bad vibrations :(
Nicolas
2016-03-18 22:13 GMT+01:00 stephane ducasse <stephane.ducasse@gmail.com mailto:stephane.ducasse@gmail.com>:
I wonder why you do not check our builds before pushing a change. Staging changes can make sure that we control the propagation of errors. And as you know, error = time = money. This is always difficult for someone to try to understand error that he had no clue from where they come.
Stef
Hi Stephane, let's be clear: which tests are you speaking of?
There is practically no SUnit for the VM dev.
The first level is using the simulator. But - running the simulator is pretty long, it's efficient if you want to focus on a specific bug, less for wide-range testing I used the simulator though by running most squeak tests and that took > 24h My goal was to see if I would not break the simulator because Eliot heavily rely on it. I did mainly simulate one flavour : squeak stack spur 64bits. Maybe the 32 bits too, but I'm not sure now - the simulator does not catch all, and have subtle differences about signed/unsigned handling
The next level is to generate the code and compile it. I generated these ones: 32bits squeak.cog.v3 squeak.cog.spur squeak.stack.v3 squeak.stack.spur 64bits squeak.cog.spur squeak.stack.spur Then I compiled... It took me a bunch of efforts because the motion of UUIDplugin from internal to external made the compilation failed, I don't know exactly why, so Ias workaround had to first undo it, find . -name '*.o' -delete, then compile again.
At this time, I think it was late and I only checked the 64 bits squeak stack spur which fits my main working image. I ran a few tests that passed so I commited these changes that are two years old and that I was preparing for several days. My mistake was to not run a 32 bits image, that's pretty true I messed up. I apologize again.
But you can't say that I don't test, it's insulting. I do pretty much for one not being paid to. For these reasons, I invite you to be a bit more forgiving.
What I tell you is that a bot DOES the rest of the tests for us. What I tell you is that there is no other way to fire the bot than committing currently. It's not perfect, but that's already something. So what's the point of blaming me for an architecture that I'm not in charge of, that I did not decide, that I don't control? Do you still think I could do more?
It's sad that the work of Igor was not leveraged, but it's a social problem not a technical one. Igor work was constructed as a fork. Surprisingly that failed. Or wasn't it doomed to fail because you didn't have the manpower/money/experienced team, whatever the tremendous quality of Igor? Who did take care of the main VM contributor and his own constraints at this time?
Please stop saying other do not understand, it's absolutely un-constructive.
If you want to see some progress, there's another attitude than being aggressive. You could try to collaborate for example. Do you really want a better infrastucture, git, etc? If yes, then find a win-win attitude with Eliot, and we'll see some progress. Others like me will follow. Can you understand that?
2016-03-19 7:48 GMT+01:00 stephane ducasse stephane.ducasse@gmail.com:
Two points
You know that I'm not found of the break it first, fix it later strategy.
I have no problem with that. I have problem that automated tests do not catch it to free programmers and brain.
Though it sometimes happen that I get caught. Here it sounds like you are not granting to me this right to break things when in the same time this right is totally abused in every day Pharo development…
You see in Pharo our process is stagged. If the tests to not run, the tests is not in. For example this year we did not integrate Epicea and marcus tried 15 times (for real 15 times) this is just that you did not see it. Now we break things because we do not have enough tests and UI/widgets is not covered.
So despite the fact that you are completely right this time, I'd say that I would have been more inclined to take the lesson I deserved from say Eliot ;)
I'm taking too much time writing this when there's probably more trouble with the spur VM currently and that ain't good. Stephane, I like your energy, and I wish I could use and promote Pharo, but please, keep it positive :) Tonight, you gave me bad vibrations :(
Nicolas
2016-03-18 22:13 GMT+01:00 stephane ducasse stephane.ducasse@gmail.com:
I wonder why you do not check our builds before pushing a change. Staging changes can make sure that we control the propagation of errors. And as you know, error = time = money. This is always difficult for someone to try to understand error that he had no clue from where they come.
Stef
On 19 Mar 2016, at 01:23, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Dear Nicolas,
Stephane, that's my fault and I apologize.This time, i've not put enough effort before the commit. Instead i've put excessive confidence in the simulator and my previous work in own branch. I can only commit nightly, so effectively, it can cost a day before I correct my mistakes.
HOWEVER, may I remind you the combinatorial: (spur,v3) x (interpreter,cogit) x (32,64bits) x (mac,win,linux,...) x (squeak,pharo,newspeak) not speaking of ARM, android free bsd etc... How do you conceivably expect that a single contributor like me would perform tests for each and every configuration?
the burden should never be on a single contributor but luckily computing time has become so cheap that many projects let computers take care of it (nobody needs to wait for a batch job, nobody needs hours to wait for a compiler, etc). Specially with github and travis-ci (or semaphoreci, wercker, ... or tons of other services) it becomes very easy to execute a matrix of configurations before merging something to master. This includes running tests on Linux and OSX and maybe on the Android emaulator if you want to.
Before working on Telecommunication I was a WebKit reviewer and we had a strict policy on regressions. No user should experience an issue that has been already resolved once. This leads to a policy where bug fixes come with tests[1]. I would be very happy if the VM development community could pick-up similar policies. I am happy to help with travis-ci integration.
have a nice weekend holger
Hi Stef,
On Mar 18, 2016, at 2:13 PM, stephane ducasse stephane.ducasse@gmail.com wrote:
I wonder why you do not check our builds before pushing a change. Staging changes can make sure that we control the propagation of errors. And as you know, error = time = money. This is always difficult for someone to try to understand error that he had no clue from where they come.
We need to stage on the other side. Indeed VMMaker.oscog commits /should/ be expected to break slave builds. Then only VMs that pass slave builds should be put somewhere where non-VM developers can fetch them and rely on them.
In my own site I provide a /latest and a /stable link instead of the raw builds. Hopefully the Pharo VM access can be made similar?
Stef
On 19 Mar 2016, at 19:13, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Stef,
On Mar 18, 2016, at 2:13 PM, stephane ducasse stephane.ducasse@gmail.com wrote:
I wonder why you do not check our builds before pushing a change. Staging changes can make sure that we control the propagation of errors. And as you know, error = time = money. This is always difficult for someone to try to understand error that he had no clue from where they come.
We need to stage on the other side. Indeed VMMaker.oscog commits /should/ be expected to break slave builds. Then only VMs that pass slave builds should be put somewhere where non-VM developers can fetch them and rely on them.
This is not the point again. I’m sorry to be dense: We did publish the changes of this VM. We do not publish changes blindly. Why do you think that we are that stupid?
Esteban just mentioned that the changes did not work. And to me this opens a big warning! A tool infrastrcuture should spot that problem not a human. Now apparently you do not believe in such infrastructure. Ok point taken but do not expect that will come to help. I thought that after the years you understand our motivations but apparently not and I cannot do much about it I’m just sad but I’m currently learning many lessons.
Stef
In my own site I provide a /latest and a /stable link instead of the raw builds. Hopefully the Pharo VM access can be made similar?
Stef
btw… that means it works ok in your VMs? I would be very surprised, since error seems to happen in places I never seen before (which usually means we didn’t change anything there).
Esteban
On 18 Mar 2016, at 16:56, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Mar 18, 2016, at 8:23 AM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
On 18 Mar 2016, at 16:11, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com> wrote:
2016-03-18 16:00 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Hi Nico,
somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become unusable :( are you aware of this? maybe I’m forgetting something in my builds?
cheers, Esteban
Hi Esteban, Please provide more feedback
- can/can't compile ?
- VM crash ? instantly or on specific operations ?
can compile, but image is unusable (no refresh of UI… error with Bitmaps I think).
- all OS or OS specific ?
all environments (mac, linux and win) have this problem.
- which flavour - stack/cogit x spur/v3 x 32/64 bits ? I presume cogit-spur-32bits for Pharo head?
yes
Maybe a few explanations accompanying a Jenkins link would do it
I don’t know what more to say :) but if you download:
wget -O- get.pharo.org/50+vmLatest http://get.pharo.org/50+vmLatest | bash
and execute it… you will see the problem.
and that does not happens if you execute
wget -O- get.pharo.org/50+vm http://get.pharo.org/50+vm | bash
(the only difference between those VMs are your commits).
Some things to try (Clément is across the hall; he can help)
build an assert-enabled VM and run this. You may get very useful error information. You can use the -trace flag to get it to output the sends the VM makes and see where the first error is
Open the image in the simulator, but that may be difficult with pharo cuz it uses so many external libraries. Nite that you can still, with a little effort, do this but you have to write the plugin simulation code that maps from calls in the simulator to calls against the host VM's facilities. For example, in the simulator the FilePluginSimulator defers to the host Smalltalk system to access files so the simulated VM can still access files just like the real VM, which defers to the stdio library or win32 APIs to access files.
The simulator is not just worth maintaining it is /essential/ to being able to debug the VM effectively. It should be a goal to have the Pharo image runnable in the simulator.
cheers, Esteban
I've experimented macosx stack spur 64 bits with simulator, and I use most of these changes in my own VM branch, except the fetch64/store64 message sends I'll check ASAP (this will be tonight)
Nicolas
On 17 Mar 2016, at 22:49, commits@source.squeak.org mailto:commits@source.squeak.org wrote:
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.1733 Author: nice Time: 17 March 2016, 11:45:52.436 pm UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102 Ancestors: VMMaker.oscog-nice.1732
Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf: version.
=============== Diff against VMMaker.oscog-nice.1732 ===============
Item was changed: ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object access') ----- stSizeOf: oop "Return the number of indexable fields in the receiver"
<doNotGenerate> ^oop basicSize!
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Esteban Lorenzano -
Holger Freyther -
Nicolas Cellier -
stephane ducasse