[Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10
nicolas I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change) I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing 2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did. Stef On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz Nicolas 2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok now I understand why I only got 14 and not 16 tests green. On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote:
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
But the tests just blocked after 2256 run, 2162 passes, etc... and no response to ALT+. :( I will have a quick look... 2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Ok now I understand why I only got 14 and not 16 tests green.
On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote:
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Do you know how to dump Smalltalk process stacks from within the VM debugger (I mean gdb) ? 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
But the tests just blocked after 2256 run, 2162 passes, etc... and no response to ALT+. :(
I will have a quick look...
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Ok now I understand why I only got 14 and not 16 tests green.
On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote:
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Do you know how to dump Smalltalk process stacks from within the VM debugger (I mean gdb) ?
never mind, found it: (gdb) info functions .*[Ss]tack.* All functions matching regular expression ".*[Ss]tack.*": File gnu-interp.c: sqInt balancedStackafterPrimitivewithArgs(sqInt, sqInt, sqInt); sqInt fetchStackPointerOf(sqInt); sqInt okayActiveProcessStack(void); sqInt popStack(void); sqInt primitiveInstVarsPutFromStack(void); sqInt primitiveStoreStackp(void); sqInt printAllStacks(void); etc... (gdb) call printAllStacks() Process 2022647440 SharedQueue>findFirst: 2022647348 Semaphore>critical: 2022647256 BlockClosure>ensure: 2022647100 Semaphore>critical: 2022646948 SharedQueue>findFirst: 2022646856 InputEventSensor>peekKeyboardEvent 2022646764 InputEventSensor>keyboardPressed 2022646672 InputEventSensor>flushKeyboard 2022646580 Debugger>openNotifierContents:label: 2022646248 >openInterrupt:onProcess: 2022645324 DebuggerUnwindBug>testUnwindDebugger 2022645232 TestCase>performTest 2022645140 TestCase>runCase 2022645048 BlockClosure>ensure: 2022644916 TestCase>runCase 2022644824 TestResult>runCase: 2022644704 BlockClosure>on:do: 2022644560 TestResult>runCase: 2022644468 BlockClosure>on:do: 2022644340 TestResult>runCase: 2022644248 TestCase>run: 2022644156 TestRunner>runTest: 2022644064 TestRunner>runSuite: 2022643972 SequenceableCollection>do:displayingProgress: 2015446772 SequenceableCollection>withIndexDo: 2015446652 SequenceableCollection>do:displayingProgress: 2015446560 ProgressInitiationException>defaultAction 2015446384 BlockClosure>ensure: 2015446100 ProgressInitiationException>defaultAction 2015446008 UndefinedObject>handleSignal: 2015445916 ContextPart>handleSignal: 2015445824 Exception>signal 2015445684 ProgressInitiationException>display:at:from:to:during: 2015445592 >display:at:from:to:during: 2015445464 String>displayProgressAt:from:to:during: 2015445276 SequenceableCollection>do:displayingProgress: 2015445184 TestRunner>basicRunSuite:do: 2015445092 BlockClosure>ensure: 2015441744 TestRunner>basicRunSuite:do: 2015441652 TestRunner>runSuite: 2015348260 TestRunner>runAll 2015348168 PluggableButtonMorph>performAction 2015348052 PluggableButtonMorphPlus>performAction 2015347960 PluggableButtonMorph>mouseUp: 2015347868 SequenceableCollection>do: 2015344832 PluggableButtonMorph>mouseUp: 2015344696 PluggableButtonMorphPlus>mouseUp: 2015344604 Morph>handleMouseUp: 2015344512 MouseButtonEvent>sentTo: 2015344420 Morph>handleEvent: 2015344328 Morph>handleFocusEvent: 2015344148 HandMorph>sendFocusEvent:to:clear: 2015344056 PasteUpMorph>becomeActiveDuring: 2015343964 BlockClosure>on:do: 2015343872 PasteUpMorph>becomeActiveDuring: 2015343752 HandMorph>sendFocusEvent:to:clear: 2015343660 HandMorph>sendEvent:focus:clear: 2015343568 HandMorph>sendMouseEvent: 2015343420 HandMorph>handleEvent: 2015343268 HandMorph>processEvents 2015343156 WorldState>doOneCycleNowFor: 2015343064 SequenceableCollection>do: 2015342972 WorldState>handsDo: 2015342880 WorldState>doOneCycleNowFor: 2015342752 WorldState>doOneCycleFor: 2015342660 PasteUpMorph>doOneCycle 2008850980 >spawnNewProcess 2008850852 BlockClosure>newProcess Process 2010748656 >finalizationProcess 2010748564 >restartFinalizationProcess 2010748748 BlockClosure>newProcess Process 2022648416 Semaphore>critical: 2022648324 BlockClosure>ensure: 2022648168 Semaphore>critical: 2022648052 SharedQueue>nextPut: 2022647960 InputEventSensor>queueEvent: 2022647832 InputEventSensor>handleEvent: 2022647740 InputEventFetcher>signalEvent: 2022647624 OrderedCollection>do: 2022647532 InputEventFetcher>signalEvent: 2010762944 InputEventFetcher>eventLoop 2010762852 InputEventPollingFetcher>installEventLoop 2010763076 BlockClosure>newProcess Process 2022648508 >handleTimerEvent 2011103312 >? 2011103156 BlockClosure>on:do: 2011103064 >? 2011102972 >? 2011103464 BlockClosure>newProcess Process 2015023020 SystemDictionary>lowSpaceWatcher 2015022928 SystemDictionary>installLowSpaceWatcher 2015023152 BlockClosure>newProcess Process 2022646156 DebuggerUnwindBug>testUnwindDebugger 2022645848 Semaphore>critical: 2022645756 BlockClosure>ensure: 2022645664 Semaphore>critical: 2022645572 DebuggerUnwindBug>testUnwindDebugger 2022645940 BlockClosure>newProcess
I know that john has a vm with traces but I do not know how to do what you need. Do you think that it can help if I integrate the next batch? Nicolas I can also remove from the stream the item so that you can take time to look at it. you just need to load the version 836 of the scriptLoader (from the pharo repository). and manually launch the loading of the last update. ScriptLoader new update10287 Stef On Apr 20, 2009, at 10:15 PM, Nicolas Cellier wrote:
Do you know how to dump Smalltalk process stacks from within the VM debugger (I mean gdb) ?
2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
But the tests just blocked after 2256 run, 2162 passes, etc... and no response to ALT+. :(
I will have a quick look...
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Ok now I understand why I only got 14 and not 16 tests green.
On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote:
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
just to say that the tests freeze around 10284cl. I was going to mention it but it already came up! Do we run all the tests before pushing out updates? 10281cl ran through ok. thanks, Mike
Wait, I think the problem is not at all caused by Concurrency fixes... I strongly suspect introduction of SharedQueue>>#findFirst: The test hang randomly in: InputEventSensor>>peekKeyboardEvent "Allows for use of old Sensor protocol to get at the keyboard, as when running kbdTest or the InterpreterSimulator in Morphic" ^eventQueue findFirst: [:buf | self isKbdEvent: buf] Old code was: peekKeyboardEvent "Return the next keyboard char event from the receiver or nil if none available" ^eventQueue nextOrNilSuchThat: [:buf | buf first = EventTypeKeyboard and: [(buf fourth) = EventKeyChar]] But I noticed SharedQueue>>findFirst: and SharedQueue>>nextOrNilSuchThat: are not EXACTLY the same... findFirst: FAILS TO INCREMENT readPos... Nicolas 2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I know that john has a vm with traces but I do not know how to do what you need. Do you think that it can help if I integrate the next batch? Nicolas I can also remove from the stream the item so that you can take time to look at it. you just need to load the version 836 of the scriptLoader (from the pharo repository). and manually launch the loading of the last update.
ScriptLoader new update10287
Stef
On Apr 20, 2009, at 10:15 PM, Nicolas Cellier wrote:
Do you know how to dump Smalltalk process stacks from within the VM debugger (I mean gdb) ?
2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
But the tests just blocked after 2256 run, 2162 passes, etc... and no response to ALT+. :(
I will have a quick look...
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Ok now I understand why I only got 14 and not 16 tests green.
On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote:
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
So nicolas should I harvest the find related bug fixes? On Apr 20, 2009, at 10:34 PM, Nicolas Cellier wrote:
Wait, I think the problem is not at all caused by Concurrency fixes...
I strongly suspect introduction of SharedQueue>>#findFirst:
The test hang randomly in:
InputEventSensor>>peekKeyboardEvent "Allows for use of old Sensor protocol to get at the keyboard, as when running kbdTest or the InterpreterSimulator in Morphic"
^eventQueue findFirst: [:buf | self isKbdEvent: buf]
Old code was:
peekKeyboardEvent "Return the next keyboard char event from the receiver or nil if none available" ^eventQueue nextOrNilSuchThat: [:buf | buf first = EventTypeKeyboard and: [(buf fourth) = EventKeyChar]]
But I noticed SharedQueue>>findFirst: and SharedQueue>>nextOrNilSuchThat: are not EXACTLY the same... findFirst: FAILS TO INCREMENT readPos...
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I know that john has a vm with traces but I do not know how to do what you need. Do you think that it can help if I integrate the next batch? Nicolas I can also remove from the stream the item so that you can take time to look at it. you just need to load the version 836 of the scriptLoader (from the pharo repository). and manually launch the loading of the last update.
ScriptLoader new update10287
Stef
On Apr 20, 2009, at 10:15 PM, Nicolas Cellier wrote:
Do you know how to dump Smalltalk process stacks from within the VM debugger (I mean gdb) ?
2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
But the tests just blocked after 2256 run, 2162 passes, etc... and no response to ALT+. :(
I will have a quick look...
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Ok now I understand why I only got 14 and not 16 tests green.
On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote:
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, SharedQueue>>#findFirst: MUST be corrected ASAP 2009/4/21 Stéphane Ducasse <stephane.ducasse@inria.fr>:
So nicolas should I harvest the find related bug fixes?
On Apr 20, 2009, at 10:34 PM, Nicolas Cellier wrote:
Wait, I think the problem is not at all caused by Concurrency fixes...
I strongly suspect introduction of SharedQueue>>#findFirst:
The test hang randomly in:
InputEventSensor>>peekKeyboardEvent    "Allows for use of old Sensor protocol to get at the keyboard,    as when running kbdTest or the InterpreterSimulator in Morphic"
   ^eventQueue findFirst: [:buf | self isKbdEvent: buf]
Old code was:
peekKeyboardEvent    "Return the next keyboard char event from the receiver or nil if none available"    ^eventQueue nextOrNilSuchThat:                    [:buf |                    buf first = EventTypeKeyboard and: [(buf fourth) = EventKeyChar]]
But I noticed SharedQueue>>findFirst: and SharedQueue>>nextOrNilSuchThat: are not EXACTLY the same... findFirst: FAILS TO INCREMENT readPos...
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I know that john has a vm with traces but I do not know how to do what you need. Do you think that it can help if I integrate the next batch? Nicolas I can also remove from the stream the item so that you can take time to look at it. you just need to load the version 836 of the scriptLoader (from the pharo repository). and manually launch the loading of the last update.
ScriptLoader new update10287
Stef
On Apr 20, 2009, at 10:15 PM, Nicolas Cellier wrote:
Do you know how to dump Smalltalk process stacks from within the VM debugger (I mean gdb) ?
2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
But the tests just blocked after 2256 run, 2162 passes, etc... and no response to ALT+. :(
I will have a quick look...
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Ok now I understand why I only got 14 and not 16 tests green.
On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote:
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Â Delay startTimerEventLoop. Â (self buildConfigurationMapFor: Â #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
 Delay startTimerEventLoop.  (ScriptLoader new buildConfigurationMapFor:      #('Kernel-nice.renggli.301.mcz'      'KernelTests-nice.96.mcz'      'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I'm pushing the delayPArttwo now and after I will do that SharedQueue>>#findFirst: On Apr 21, 2009, at 11:32 AM, Nicolas Cellier wrote:
Yes, SharedQueue>>#findFirst: MUST be corrected ASAP
2009/4/21 Stéphane Ducasse <stephane.ducasse@inria.fr>:
So nicolas should I harvest the find related bug fixes?
On Apr 20, 2009, at 10:34 PM, Nicolas Cellier wrote:
Wait, I think the problem is not at all caused by Concurrency fixes...
I strongly suspect introduction of SharedQueue>>#findFirst:
The test hang randomly in:
InputEventSensor>>peekKeyboardEvent "Allows for use of old Sensor protocol to get at the keyboard, as when running kbdTest or the InterpreterSimulator in Morphic"
^eventQueue findFirst: [:buf | self isKbdEvent: buf]
Old code was:
peekKeyboardEvent "Return the next keyboard char event from the receiver or nil if none available" ^eventQueue nextOrNilSuchThat: [:buf | buf first = EventTypeKeyboard and: [(buf fourth) = EventKeyChar]]
But I noticed SharedQueue>>findFirst: and SharedQueue>>nextOrNilSuchThat: are not EXACTLY the same... findFirst: FAILS TO INCREMENT readPos...
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I know that john has a vm with traces but I do not know how to do what you need. Do you think that it can help if I integrate the next batch? Nicolas I can also remove from the stream the item so that you can take time to look at it. you just need to load the version 836 of the scriptLoader (from the pharo repository). and manually launch the loading of the last update.
ScriptLoader new update10287
Stef
On Apr 20, 2009, at 10:15 PM, Nicolas Cellier wrote:
Do you know how to dump Smalltalk process stacks from within the VM debugger (I mean gdb) ?
2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
But the tests just blocked after 2256 run, 2162 passes, etc... and no response to ALT+. :(
I will have a quick look...
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Ok now I understand why I only got 14 and not 16 tests green.
On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote:
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Does any one need such a VM? I would have to build a new one since the old one is not closure based. On 20-Apr-09, at 1:24 PM, Stéphane Ducasse wrote:
I know that john has a vm with traces but I do not know how to do what you need.
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Not me, I'm on linux and a simple printAllStacks() fulfiled my needs. Thanks 2009/4/21 John M McIntosh <johnmci@smalltalkconsulting.com>:
Does any one need such a VM? I would have to build a new one since the old one is not closure based.
On 20-Apr-09, at 1:24 PM, Stéphane Ducasse wrote:
I know that john has a vm with traces but I do not know how to do what you need.
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Arg so you confirmed my fear. Stef On Apr 20, 2009, at 10:10 PM, Nicolas Cellier wrote:
But the tests just blocked after 2256 run, 2162 passes, etc... and no response to ALT+. :(
I will have a quick look...
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Ok now I understand why I only got 14 and not 16 tests green.
On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote:
Yes, it seems OK The tests are running on my linux versions now... not yet frozen The two additionnal DelayTest from Andreas which were in KernelTests-nice.95.mcz are not yet loaded but will be with KernelTests-nice.96.mcz
Nicolas
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
it is not a problem. I just want to make sure. Some changes are easy to undo some not. So I will integrate the second batch. Did you have a look at the integration I just did.
Stef
On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote:
Yes, Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay because Andreas changes solved the problem. KernelTests-nice.96.mcz change the Delay upper bound test System-Support-nice.11.mcz fix a problem of sending deprecated Process>>#offList (it should have gone with earlier change)
I wanted to decompose integration of Andreas changes carefully to be sure it can be redone... But now, I realize that I published too many messages, that's confusing
2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
I integrated in 10287
script363 Delay startTimerEventLoop. (self buildConfigurationMapFor: #('Kernel-nice.renggli.300.mcz')) load
So I imagine that the following one is another fix that I should integrate. Is is correct
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Nicolas for the integration of the second patch. Is the Delay startTimerEventLoop mandatory? Stef
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
No 2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Nicolas for the integration of the second patch. Is the Delay startTimerEventLoop mandatory?
Stef
Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel concurrency fixes? 3.10 http://code.google.com/p/pharo/issues/detail?id=688
I published the changes in PharoInbox I checked that entire changes related to mantis 7321 list can be loaded with following instructions:
Delay startTimerEventLoop. (ScriptLoader new buildConfigurationMapFor: #('Kernel-nice.renggli.301.mcz' 'KernelTests-nice.96.mcz' 'System-Support-nice.11.mcz')) load.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
John M McIntosh -
Michael Roberts -
Nicolas Cellier -
Stéphane Ducasse