Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- 1 participants
- 144633 messages
[Pharo 7.0-dev] Build #150: 20462-An-error-in-the-Tests-never-break-the-build
by ci-pharo-ci-jenkins2＠inria.fr
There is a new Pharo build available!
The status of the build #150 was: FAILURE.
The Pull Request #308 was integrated: "20462-An-error-in-the-Tests-never-break-the-build"
Pull request url: https://github.com/pharo-project/pharo/pull/308
Issue Url: https://pharo.fogbugz.com/f/cases/20462
Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…
Sept. 22, 2017
Re: [Pharo-dev] Pharo7 and full block closures
by Clément Bera
I totally agree with you on this.
For a while I had a CI job that was trying to execute Sista on the latest
version of Pharo and VM, and sent me a mail when something had gone wrong.
I disabled it when there was problems on the CI, I will make it work again.
This way I am notified and I can update the Sista code as Pharo 7 is
developed. That helps a lot.
On the Pharo CI the time to run tests matters hence I will try to find
another solution to test full block and the other bytecode set. I did not
do that because I hope I can change Pharo to use full block by default
soon, but since they're broken...
Regards
On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther <holger(a)freyther.de>
wrote:
>
> > On 22. Sep 2017, at 13:33, Clément Bera <bera.clement(a)gmail.com> wrote:
>
>
> Hi Clement,
>
>
> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and 6.1
> but it won't work every day during the alpha of Pharo 7 and no sane
> framework developer can guarantee that. Sista does not work currently in
> Pharo 7 due to some changes breaking the full block closures, I am going to
> fix it but even then in the incoming months there is a high chance that
> another change in Pharo 7 breaks it again, so I would never recommend to
> use it with the alpha.
>
>
> thank you for your response. I didn't expect it to work (after all you
> label it "Alpha" and I ran into issues already) but my intention for the
> mail was a bit different. Let me try to briefly explain my motivation. In
> my experience:
>
> (1) Software not executed stops to work (or never "worked")
> (2) The earlier breakage is detected the less expensive it is to fix.
>
> My assumption is that Opal is part of Pharo and that we look at a
> regression of the Opal compiler and/or how it interacts with the rest of
> the image. As it might be easier to understand/fix it now than later I
> brought it up. From my point of view I wonder if we want to add ~50s to the
> CI process to execute:
>
> CompilationContext bytecodeBackend: OpalEncoderForSistaV1.
> CompilationContext usesFullBlockClosure: true.
> OpalCompiler recompileAll.
>
>
> Is there any value in doing so?
>
>
> cheers
>
> holger
>
>
> PS
>
> (2) The intuitive explanation is that the cost of analysis is a lot lower
> the earlier the problem is detected. There are fewer potential changes that
> lead to the breakage and the people involved will remember what/why they
> did reducing the cost of fixing. Ideally things are found to be broken and
> fixed before integration.
>
> Maybe an analogy is old-school aviation navigation.. the earlier a mistake
> is found in navigation the closer to the original course...
>
Sept. 22, 2017
Re: [Pharo-dev] Pharo7 and full block closures
by Holger Freyther
> On 22. Sep 2017, at 13:33, Clément Bera <bera.clement(a)gmail.com> wrote:
Hi Clement,
> Sista will work for the release of Pharo 7 as it did for Pharo 6 and 6.1 but it won't work every day during the alpha of Pharo 7 and no sane framework developer can guarantee that. Sista does not work currently in Pharo 7 due to some changes breaking the full block closures, I am going to fix it but even then in the incoming months there is a high chance that another change in Pharo 7 breaks it again, so I would never recommend to use it with the alpha.
thank you for your response. I didn't expect it to work (after all you label it "Alpha" and I ran into issues already) but my intention for the mail was a bit different. Let me try to briefly explain my motivation. In my experience:
(1) Software not executed stops to work (or never "worked")
(2) The earlier breakage is detected the less expensive it is to fix.
My assumption is that Opal is part of Pharo and that we look at a regression of the Opal compiler and/or how it interacts with the rest of the image. As it might be easier to understand/fix it now than later I brought it up. From my point of view I wonder if we want to add ~50s to the CI process to execute:
CompilationContext bytecodeBackend: OpalEncoderForSistaV1.
CompilationContext usesFullBlockClosure: true.
OpalCompiler recompileAll.
Is there any value in doing so?
cheers
holger
PS
(2) The intuitive explanation is that the cost of analysis is a lot lower the earlier the problem is detected. There are fewer potential changes that lead to the breakage and the people involved will remember what/why they did reducing the cost of fixing. Ideally things are found to be broken and fixed before integration.
Maybe an analogy is old-school aviation navigation.. the earlier a mistake is found in navigation the closer to the original course...
Sept. 22, 2017
Re: [Pharo-dev] Iceberg Default Subdirectory Setting?
by Esteban Lorenzano
> On 22 Sep 2017, at 10:01, stephan <stephan(a)stack.nl> wrote:
>
> On 22-09-17 09:25, Esteban Lorenzano wrote:
>> In response to my:
>>> You cannot use pattern 2 with shared repos.
>>
>> yes you can.
>> shared repo is a suggestion, you can always chose to add a project from another place.
>
> Yes, so that makes pattern 2 practically impossible?
why? is perfectly possible.
> Where am I going wrong?
> I create an image with a certain repo, checkout a branch.
> 6 months later I reopen the image and need to bring it up to date.
yes, then you fetch and update⦠again, whatâs the problem? there is something Iâm missing about your reasoning :(
> For that I need to look at a few other images, having different versions/branches. I then need to create as many clones of the repo as I have images I need to compare, open them, switch their repos to the right clone and switch to the right branch and version.
why?
you can compare branches inside same image⦠and even switch to them and reload. This will not work for pharo itself (because of initialisation order), but it will work on other projects.
one thing I want to add is a âreload on baseline orderâ option on baseline plugin⦠so you can update your system following a baseline.
Esteban
>
> Stephan
>
>
Sept. 22, 2017
Re: [Pharo-dev] Iceberg Default Subdirectory Setting?
by stephan
On 22-09-17 09:25, Esteban Lorenzano wrote:
>In response to my:
>> You cannot use pattern 2 with shared repos.
>
> yes you can.
> shared repo is a suggestion, you can always chose to add a project from another place.
Yes, so that makes pattern 2 practically impossible?
Where am I going wrong?
I create an image with a certain repo, checkout a branch.
6 months later I reopen the image and need to bring it up to date.
For that I need to look at a few other images, having different
versions/branches. I then need to create as many clones of the repo as I
have images I need to compare, open them, switch their repos to the
right clone and switch to the right branch and version.
Stephan
Sept. 22, 2017
Re: [Pharo-dev] Iceberg Default Subdirectory Setting?
by Esteban Lorenzano
> On 22 Sep 2017, at 09:20, Esteban Lorenzano <estebanlm(a)gmail.com> wrote:
>
>
>> On 21 Sep 2017, at 20:08, stephan <stephan(a)stack.nl> wrote:
>>
>> On 21-09-17 18:54, Esteban Lorenzano wrote:
>>> I do not understand what is the problem.
>>> You have different approaches:
>>> 1) you work always on same branch (even if you âjumpâ from branchs): like today I work on âissue-1â and tomorrow on âissue-2â. You just switch branchs on your iceberg tool and thatâs all.
>>> 2) you work on different branchs at same time and you do not want to switch branches all the time. Then you just have two clones and points to this different clones.
>>> in general, Iâm working on different branches all the time (pharo branches, so big projects) and I prefer to use pattern (1), but you can also use pattern (2)⦠as I said⦠I do not understand what is the problem :)
>>
>> You cannot use pattern 2 with shared repos.
>
> yes you can.
> shared repo is a suggestion, you can always chose to add a project from another place.
btwâ¦
- metacello #lock function should work to âlockâ projects to other directions than url in baseline. I just donât know exactly how it works since I never did it myself.
- iceberg itself should not re-clone a project you already have in your registry. That means if you have project A who depends on project B, and you are working on a branch of B, if you load B first, iceberg will take that version instead the one declared in baseline (I made this at ESUG, because seaside development requires it).
Esteban
>
> Esteban
>
>>
>> Stephan
>>
>>
>
Sept. 22, 2017
Re: [Pharo-dev] Iceberg Default Subdirectory Setting?
by Esteban Lorenzano
> On 21 Sep 2017, at 20:08, stephan <stephan(a)stack.nl> wrote:
>
> On 21-09-17 18:54, Esteban Lorenzano wrote:
>> I do not understand what is the problem.
>> You have different approaches:
>> 1) you work always on same branch (even if you âjumpâ from branchs): like today I work on âissue-1â and tomorrow on âissue-2â. You just switch branchs on your iceberg tool and thatâs all.
>> 2) you work on different branchs at same time and you do not want to switch branches all the time. Then you just have two clones and points to this different clones.
>> in general, Iâm working on different branches all the time (pharo branches, so big projects) and I prefer to use pattern (1), but you can also use pattern (2)⦠as I said⦠I do not understand what is the problem :)
>
> You cannot use pattern 2 with shared repos.
yes you can.
shared repo is a suggestion, you can always chose to add a project from another place.
Esteban
>
> Stephan
>
>
Sept. 22, 2017
Re: [Pharo-dev] Pharo7 and full block closures
by Clément Bera
Hi Holger,
Nobody can guarantee any framework to be stable on Pharo alpha (Currently
Pharo 7) since deep changes can happen every day during alpha. So the
answer is yes, having any framework *not* working on the alpha version is
to be expected.
The instructions to use the Sista runtime are detailed here
<https://clementbera.wordpress.com/2017/07/19/sista-open-alpha-release/> in
the How to get/build a Sista image and VM section and are very clear in
step 1 about using Pharo 6 (the stable Pharo version). They also work with
Pharo 6.1.
Sista will work for the release of Pharo 7 as it did for Pharo 6 and 6.1
but it won't work every day during the alpha of Pharo 7 and no sane
framework developer can guarantee that. Sista does not work currently in
Pharo 7 due to some changes breaking the full block closures, I am going to
fix it but even then in the incoming months there is a high chance that
another change in Pharo 7 breaks it again, so I would never recommend to
use it with the alpha.
On Fri, Sep 22, 2017 at 5:08 AM, Holger Freyther <holger(a)freyther.de> wrote:
> Hi,
>
> I kind of missed the open alpha of "Scorch" and to make up for it I tried
> to follow the instructions on Pharo7 but I do crash the VM. Is that to be
> expected?
>
> "Add special selector for trap instruction"
> Smalltalk specialObjectsArray at: 60 put: #trapTripped.
> "Disable hot spot detection (to load the Scorch code)"
> Smalltalk specialObjectsArray at: 59 put: nil.
> "Recompile the fetch mourner primitive which has strange side-effect with
> alternate bytecode set and closures"
> WeakArray class compile: 'primitiveFetchMourner ^ nil' classified: #patch.
> "Enable FullBlockClosure and alternate bytecode set"
> CompilationContext bytecodeBackend: OpalEncoderForSistaV1.
> CompilationContext usesFullBlockClosure: true.
> OpalCompiler recompileAll.
>
>
> If I only execute the last three lines it is crashing as well but at a
> different point in the VM?
>
>
> (lldb) bt
> * thread #1: tid = 0x5636d2, 0xa165e496 libsystem_kernel.dylib`__pthread_kill
> + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
> * frame #0: 0xa165e496 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0xa1744c63 libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0xa15bea34 libsystem_c.dylib`abort + 141
> frame #3: 0x00087128 Pharo`error + 55
> frame #4: 0x000132e6 Pharo`lookupMethodInClass + 601
> frame #5: 0x000085c1 Pharo`interpret + 25756
> frame #6: 0x00011b9a Pharo`enterSmalltalkExecutiveImplementation + 135
> frame #7: 0x000023ab Pharo`interpret + 646
> frame #8: 0x000889d9 Pharo`-[sqSqueakMainApplication runSqueak] + 476
> frame #9: 0x95ac4a1b Foundation`__NSFirePerformWithOrder + 419
> frame #10: 0x942811fe CoreFoundation`__CFRUNLOOP_IS_
> CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
> frame #11: 0x94281157 CoreFoundation`__CFRunLoopDoObservers + 391
> frame #12: 0x942614a2 CoreFoundation`__CFRunLoopRun + 1058
> frame #13: 0x94260e1a CoreFoundation`CFRunLoopRunSpecific + 506
> frame #14: 0x94260c0b CoreFoundation`CFRunLoopRunInMode + 123
> frame #15: 0x93954396 HIToolbox`RunCurrentEventLoopInMode + 268
> frame #16: 0x93954057 HIToolbox`ReceiveNextEventCommon + 195
> frame #17: 0x93953f7b HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter
> + 83
> frame #18: 0x91f86015 AppKit`_DPSNextEvent + 1227
> frame #19: 0x926ebbbb AppKit`-[NSApplication(NSEvent)
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1742
> frame #20: 0x926eb4e5 AppKit`-[NSApplication(NSEvent)
> nextEventMatchingMask:untilDate:inMode:dequeue:] + 132
> frame #21: 0x91f7acb6 AppKit`-[NSApplication run] + 943
> frame #22: 0x91f47d1e AppKit`NSApplicationMain + 1368
> frame #23: 0xa152f395 libdyld.dylib`start + 1
> (lldb) p (int) activeProcess()
> (int) $0 = 115378352
> (lldb) p/x (int) activeProcess()
> (int) $1 = 0x06e088b0
> (lldb) p (void) printAllStacks()
> Process 0x6e088b0 priority 40
> 0xbfffc124 I FileReference(AbstractFileReference)>writeStreamDo:
> 0x9a303d8: a(n) FileReference
> 0xbfffc144 M [] in OmBlockFileStore(OmFileStore)>flushEntryBuffer
> 0x9a2c3c0: a(n) OmBlockFileStore
> 0xbfffc164 M [] in Semaphore>critical: 0x6e08898: a(n) Semaphore
> 0xbfffc184 M BlockClosure>ensure: 0x6f2d1f8: a(n) BlockClosure
> 0xbfffc1a4 M Semaphore>critical: 0x6e08898: a(n) Semaphore
> 0xbfffc1c8 I OmBlockFileStore(OmFileStore)>critical: 0x9a2c3c0: a(n)
> OmBlockFileStore
> 0xbfffc1e4 M OmBlockFileStore(OmFileStore)>flushEntryBuffer 0x9a2c3c0:
> a(n) OmBlockFileStore
> 0xbfffc204 I OmDeferrer>sendMessage 0x9a303f8: a(n) OmDeferrer
> 0xbfffc21c M [] in OmDeferrer>flush 0x9a303f8: a(n) OmDeferrer
> 0xbfffc23c M BlockClosure>ensure: 0x6f2d0e0: a(n) BlockClosure
> 0xbfffc260 I OmDeferrer>flush 0x9a303f8: a(n) OmDeferrer
> 0xbfffc280 I [] in OmDeferrer>runMessageProcess 0x9a303f8: a(n) OmDeferrer
> 0xbfffc2a0 I [] in BlockClosure>newProcess 0x6e12fb8: a(n) BlockClosure
>
> processes at priority 40
> Process 0x7f4ae88 priority 40
> 0xbfff7208 M IdentityDictionary(Dictionary)>at:ifAbsent: 0x6e11fa8: a(n)
> IdentityDictionary
> 0xbfff7228 M IdentityDictionary(Dictionary)>at:ifAbsentPut: 0x6e11fa8:
> a(n) IdentityDictionary
> 0xbfff7248 M IRBytecodeGenerator>label: 0x6e12050: a(n) IRBytecodeGenerator
> 0xbfff7264 M IRTranslatorV2>label: 0x6e12118: a(n) IRTranslatorV2
> 0xbfff7280 M IRTranslatorV2>visitSequence: 0x6e12118: a(n) IRTranslatorV2
> 0xbfff729c M IRSequence>accept: 0x6e12138: a(n) IRSequence
> 0xbfff8fa4 M IRTranslatorV2(IRVisitor)>visitNode: 0x6e12118: a(n)
> IRTranslatorV2
> 0xbfff8fc0 M [] in IRTranslatorV2(IRVisitor)>visitNodes: 0x6e12118: a(n)
> IRTranslatorV2
> 0xbfff8fe4 M SortedCollection(OrderedCollection)>do: 0x6e12248: a(n)
> SortedCollection
> 0xbfff9000 M IRTranslatorV2(IRVisitor)>visitNodes: 0x6e12118: a(n)
> IRTranslatorV2
> 0xbfff901c M IRTranslatorV2>visitSequences: 0x6e12118: a(n) IRTranslatorV2
> 0xbfff9038 M IRTranslatorV2>visitMethod: 0x6e12118: a(n) IRTranslatorV2
> 0xbfff9054 M IRMethod>accept: 0x6e12320: a(n) IRMethod
> 0xbfff9070 M IRTranslatorV2(IRVisitor)>visitNode: 0x6e12118: a(n)
> IRTranslatorV2
> 0xbfff9094 M IRMethod>generateBlock:withScope: 0x6e12320: a(n) IRMethod
> 0xbfff90b4 M IRMethod>compiledBlock: 0x6e12320: a(n) IRMethod
> 0xbfff90d4 M OCASTTranslator>translateFullBlock: 0x6e123a8: a(n)
> OCASTTranslator
> 0xbfff90f8 M OCASTTranslatorForValue(OCASTTranslator)>visitFullBlockNode:
> 0x6e12450: a(n) OCASTTranslatorForValue
> 0xbfff9120 M OCASTTranslatorForValue(OCASTTranslator)>visitBlockNode:
> 0x6e12450: a(n) OCASTTranslatorForValue
> 0xbfff913c M RBBlockNode>acceptVisitor: 0x6e12420: a(n) RBBlockNode
> 0xbfff9158 M OCASTTranslatorForValue(RBProgramNodeVisitor)>visitNode:
> 0x6e12450: a(n) OCASTTranslatorForValue
> 0xbfff9174 M OCASTTranslatorForValue(OCASTTranslator)>visitNode:
> 0x6e12450: a(n) OCASTTranslatorForValue
> 0xbfff9190 M [] in OCASTTranslatorForValue(OCASTTranslator)>emitMessageNode:
> 0x6e12450: a(n) OCASTTranslatorForValue
> 0xbfff91b4 M OrderedCollection>do: 0x6e12480: a(n) OrderedCollection
> 0xbfff91d0 M OCASTTranslatorForValue(OCASTTranslator)>emitMessageNode:
> 0x6e12450: a(n) OCASTTranslatorForValue
> 0xbfff91ec M OCASTTranslatorForValue(OCASTTranslator)>visitMessageNode:
> 0x6e12450: a(n) OCASTTranslatorForValue
> 0xbfff9208 M RBMessageNode>acceptVisitor: 0x6e124f8: a(n) RBMessageNode
> 0xbfff9224 M OCASTTranslatorForValue(RBProgramNodeVisitor)>visitNode:
> 0x6e12450: a(n) OCASTTranslatorForValue
> 0xbfff9240 M OCASTTranslatorForValue(OCASTTranslator)>visitNode:
> 0x6e12450: a(n) OCASTTranslatorForValue
> 0xbfff925c M [] in OCASTTranslatorForEffect(OCASTTranslator)>emitMessageNode:
> 0x6e12520: a(n) OCASTTranslatorForEffect
> 0xbfff9280 M OrderedCollection>do: 0x6e12550: a(n) OrderedCollection
> 0xbfff929c M OCASTTranslatorForEffect(OCASTTranslator)>emitMessageNode:
> 0x6e12520: a(n) OCASTTranslatorForEffect
> 0xbfffa00c M OCASTTranslatorForEffect>emitMessageNode: 0x6e12520: a(n)
> OCASTTranslatorForEffect
> 0xbfffa028 M OCASTTranslatorForEffect(OCASTTranslator)>visitMessageNode:
> 0x6e12520: a(n) OCASTTranslatorForEffect
> 0xbfffa044 M RBMessageNode>acceptVisitor: 0x6e125c8: a(n) RBMessageNode
> 0xbfffa060 M OCASTTranslatorForEffect(RBProgramNodeVisitor)>visitNode:
> 0x6e12520: a(n) OCASTTranslatorForEffect
> 0xbfffa07c M OCASTTranslatorForEffect(OCASTTranslator)>visitNode:
> 0x6e12520: a(n) OCASTTranslatorForEffect
> 0xbfffa098 M [] in OCASTTranslatorForEffect>visitSequenceNode: 0x6e12520:
> a(n) OCASTTranslatorForEffect
> 0xbfffa0bc M OrderedCollection>do: 0x6e12668: a(n) OrderedCollection
> 0xbfffa0d8 M OCASTTranslatorForEffect>visitSequenceNode: 0x6e12520: a(n)
> OCASTTranslatorForEffect
> 0xbfffa0f4 M RBSequenceNode>acceptVisitor: 0x6e126e0: a(n) RBSequenceNode
> 0xbfffa110 M OCASTTranslatorForEffect(RBProgramNodeVisitor)>visitNode:
> 0x6e12520: a(n) OCASTTranslatorForEffect
> 0xbfffa12c M OCASTTranslatorForEffect(OCASTTranslator)>visitNode:
> 0x6e12520: a(n) OCASTTranslatorForEffect
> 0xbfffa148 M OCASTTranslator>visitMethodNode: 0x6e12708: a(n)
> OCASTTranslator
> 0xbfffa164 M RBMethodNode>acceptVisitor: 0x6e12780: a(n) RBMethodNode
> 0xbfffa180 M OCASTTranslator(RBProgramNodeVisitor)>visitNode: 0x6e12708:
> a(n) OCASTTranslator
> 0xbfffa19c M OCASTTranslator>visitNode: 0x6e12708: a(n) OCASTTranslator
> 0xbfffa1bc M RBMethodNode>generateIR 0x6e12780: a(n) RBMethodNode
> 0xbfffa1d4 M RBMethodNode>generate: 0x6e12780: a(n) RBMethodNode
> 0xbfffa1f4 M [] in OpalCompiler>compile 0x6e127e8: a(n) OpalCompiler
> 0xbfffa20c M BlockClosure>on:do: 0x6e12868: a(n) BlockClosure
> 0xbfffa230 M OpalCompiler>compile 0x6e127e8: a(n) OpalCompiler
> 0xbfffa250 M AbstractNautilusUI class(Behavior)>recompile:from:
> 0x7fb08f8: a(n) AbstractNautilusUI class
> 0xbfffa274 M [] in AbstractNautilusUI class(Behavior)>compileAllFrom:
> 0x7fb08f8: a(n) AbstractNautilusUI class
> 0xbfffa29c M Set>do: 0x6e12970: a(n) Set
> 0xbfffaf34 M AbstractNautilusUI class(Behavior)>compileAllFrom:
> 0x7fb08f8: a(n) AbstractNautilusUI class
> 0xbfffaf50 M AbstractNautilusUI class(Class)>compileAllFrom: 0x7fb08f8:
> a(n) AbstractNautilusUI class
> 0xbfffaf6c M AbstractNautilusUI class(Behavior)>compileAll 0x7fb08f8: a(n)
> AbstractNautilusUI class
> 0xbfffaf8c I AbstractNautilusUI class(Class)>compileAll 0x7fb08f8: a(n)
> AbstractNautilusUI class
> 0xbfffafac I AbstractNautilusUI class(Behavior)>recompile 0x7fb08f8: a(n)
> AbstractNautilusUI class
> 0xbfffafc4 M [] in SmalltalkImage>recompile 0x74ca9b8: a(n) SmalltalkImage
> 0xbfffaff8 M [] in OrderedCollection(Collection)>do:displayingProgress:every:
> 0x6e12aa0: a(n) OrderedCollection
> 0xbfffb01c M OrderedCollection>do: 0x6e12aa0: a(n) OrderedCollection
> 0xbfffb054 I [] in OrderedCollection(Collection)>do:displayingProgress:every:
> 0x6e12aa0: a(n) OrderedCollection
> 0xbfffb078 I BlockClosure>cull: 0x6e12b40: a(n) BlockClosure
> 0xbfffb094 M [] in Job>run 0x6e12a58: a(n) Job
> 0xbfffb0b8 M [] in CurrentJob(DynamicVariable)>value:during: 0x72f6dc0:
> a(n) CurrentJob
> 0xbfffb0d8 M BlockClosure>ensure: 0x6e12b80: a(n) BlockClosure
> 0xbfffb104 I CurrentJob(DynamicVariable)>value:during: 0x72f6dc0: a(n)
> CurrentJob
> 0xbfffb12c I CurrentJob class(DynamicVariable class)>value:during:
> 0x7233b28: a(n) CurrentJob class
> 0xbfffb14c M [] in Job>run 0x6e12a58: a(n) Job
> 0xbfffb16c M BlockClosure>ensure: 0x6e12c80: a(n) BlockClosure
> 0xbfffb190 I Job>run 0x6e12a58: a(n) Job
> 0xbfffb1b0 I MorphicUIManager(UIManager)>displayProgress:from:to:during:
> 0x9a2c2d8: a(n) MorphicUIManager
> 0xbfffb1e0 I ByteString(String)>displayProgressFrom:to:during: 0x748c040:
> a(n) ByteString
> 0xbfffb214 I OrderedCollection(Collection)>do:displayingProgress:every:
> 0x6e12aa0: a(n) OrderedCollection
> 0xbfffb240 I OrderedCollection(Collection)>do:displayingProgress:
> 0x6e12aa0: a(n) OrderedCollection
> 0xbfffb268 I SmalltalkImage>recompile 0x74ca9b8: a(n) SmalltalkImage
> 0xbfffb288 I OpalCompiler class>recompileAll 0x7310170: a(n) OpalCompiler
> class
>
>
>
>
Sept. 22, 2017
Pharo7 and full block closures
by Holger Freyther
Hi,
I kind of missed the open alpha of "Scorch" and to make up for it I tried to follow the instructions on Pharo7 but I do crash the VM. Is that to be expected?
"Add special selector for trap instruction"
Smalltalk specialObjectsArray at: 60 put: #trapTripped.
"Disable hot spot detection (to load the Scorch code)"
Smalltalk specialObjectsArray at: 59 put: nil.
"Recompile the fetch mourner primitive which has strange side-effect with alternate bytecode set and closures"
WeakArray class compile: 'primitiveFetchMourner ^ nil' classified: #patch.
"Enable FullBlockClosure and alternate bytecode set"
CompilationContext bytecodeBackend: OpalEncoderForSistaV1.
CompilationContext usesFullBlockClosure: true.
OpalCompiler recompileAll.
If I only execute the last three lines it is crashing as well but at a different point in the VM?
(lldb) bt
* thread #1: tid = 0x5636d2, 0xa165e496 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0xa165e496 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0xa1744c63 libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0xa15bea34 libsystem_c.dylib`abort + 141
frame #3: 0x00087128 Pharo`error + 55
frame #4: 0x000132e6 Pharo`lookupMethodInClass + 601
frame #5: 0x000085c1 Pharo`interpret + 25756
frame #6: 0x00011b9a Pharo`enterSmalltalkExecutiveImplementation + 135
frame #7: 0x000023ab Pharo`interpret + 646
frame #8: 0x000889d9 Pharo`-[sqSqueakMainApplication runSqueak] + 476
frame #9: 0x95ac4a1b Foundation`__NSFirePerformWithOrder + 419
frame #10: 0x942811fe CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
frame #11: 0x94281157 CoreFoundation`__CFRunLoopDoObservers + 391
frame #12: 0x942614a2 CoreFoundation`__CFRunLoopRun + 1058
frame #13: 0x94260e1a CoreFoundation`CFRunLoopRunSpecific + 506
frame #14: 0x94260c0b CoreFoundation`CFRunLoopRunInMode + 123
frame #15: 0x93954396 HIToolbox`RunCurrentEventLoopInMode + 268
frame #16: 0x93954057 HIToolbox`ReceiveNextEventCommon + 195
frame #17: 0x93953f7b HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 83
frame #18: 0x91f86015 AppKit`_DPSNextEvent + 1227
frame #19: 0x926ebbbb AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1742
frame #20: 0x926eb4e5 AppKit`-[NSApplication(NSEvent) nextEventMatchingMask:untilDate:inMode:dequeue:] + 132
frame #21: 0x91f7acb6 AppKit`-[NSApplication run] + 943
frame #22: 0x91f47d1e AppKit`NSApplicationMain + 1368
frame #23: 0xa152f395 libdyld.dylib`start + 1
(lldb) p (int) activeProcess()
(int) $0 = 115378352
(lldb) p/x (int) activeProcess()
(int) $1 = 0x06e088b0
(lldb) p (void) printAllStacks()
Process 0x6e088b0 priority 40
0xbfffc124 I FileReference(AbstractFileReference)>writeStreamDo: 0x9a303d8: a(n) FileReference
0xbfffc144 M [] in OmBlockFileStore(OmFileStore)>flushEntryBuffer 0x9a2c3c0: a(n) OmBlockFileStore
0xbfffc164 M [] in Semaphore>critical: 0x6e08898: a(n) Semaphore
0xbfffc184 M BlockClosure>ensure: 0x6f2d1f8: a(n) BlockClosure
0xbfffc1a4 M Semaphore>critical: 0x6e08898: a(n) Semaphore
0xbfffc1c8 I OmBlockFileStore(OmFileStore)>critical: 0x9a2c3c0: a(n) OmBlockFileStore
0xbfffc1e4 M OmBlockFileStore(OmFileStore)>flushEntryBuffer 0x9a2c3c0: a(n) OmBlockFileStore
0xbfffc204 I OmDeferrer>sendMessage 0x9a303f8: a(n) OmDeferrer
0xbfffc21c M [] in OmDeferrer>flush 0x9a303f8: a(n) OmDeferrer
0xbfffc23c M BlockClosure>ensure: 0x6f2d0e0: a(n) BlockClosure
0xbfffc260 I OmDeferrer>flush 0x9a303f8: a(n) OmDeferrer
0xbfffc280 I [] in OmDeferrer>runMessageProcess 0x9a303f8: a(n) OmDeferrer
0xbfffc2a0 I [] in BlockClosure>newProcess 0x6e12fb8: a(n) BlockClosure
processes at priority 40
Process 0x7f4ae88 priority 40
0xbfff7208 M IdentityDictionary(Dictionary)>at:ifAbsent: 0x6e11fa8: a(n) IdentityDictionary
0xbfff7228 M IdentityDictionary(Dictionary)>at:ifAbsentPut: 0x6e11fa8: a(n) IdentityDictionary
0xbfff7248 M IRBytecodeGenerator>label: 0x6e12050: a(n) IRBytecodeGenerator
0xbfff7264 M IRTranslatorV2>label: 0x6e12118: a(n) IRTranslatorV2
0xbfff7280 M IRTranslatorV2>visitSequence: 0x6e12118: a(n) IRTranslatorV2
0xbfff729c M IRSequence>accept: 0x6e12138: a(n) IRSequence
0xbfff8fa4 M IRTranslatorV2(IRVisitor)>visitNode: 0x6e12118: a(n) IRTranslatorV2
0xbfff8fc0 M [] in IRTranslatorV2(IRVisitor)>visitNodes: 0x6e12118: a(n) IRTranslatorV2
0xbfff8fe4 M SortedCollection(OrderedCollection)>do: 0x6e12248: a(n) SortedCollection
0xbfff9000 M IRTranslatorV2(IRVisitor)>visitNodes: 0x6e12118: a(n) IRTranslatorV2
0xbfff901c M IRTranslatorV2>visitSequences: 0x6e12118: a(n) IRTranslatorV2
0xbfff9038 M IRTranslatorV2>visitMethod: 0x6e12118: a(n) IRTranslatorV2
0xbfff9054 M IRMethod>accept: 0x6e12320: a(n) IRMethod
0xbfff9070 M IRTranslatorV2(IRVisitor)>visitNode: 0x6e12118: a(n) IRTranslatorV2
0xbfff9094 M IRMethod>generateBlock:withScope: 0x6e12320: a(n) IRMethod
0xbfff90b4 M IRMethod>compiledBlock: 0x6e12320: a(n) IRMethod
0xbfff90d4 M OCASTTranslator>translateFullBlock: 0x6e123a8: a(n) OCASTTranslator
0xbfff90f8 M OCASTTranslatorForValue(OCASTTranslator)>visitFullBlockNode: 0x6e12450: a(n) OCASTTranslatorForValue
0xbfff9120 M OCASTTranslatorForValue(OCASTTranslator)>visitBlockNode: 0x6e12450: a(n) OCASTTranslatorForValue
0xbfff913c M RBBlockNode>acceptVisitor: 0x6e12420: a(n) RBBlockNode
0xbfff9158 M OCASTTranslatorForValue(RBProgramNodeVisitor)>visitNode: 0x6e12450: a(n) OCASTTranslatorForValue
0xbfff9174 M OCASTTranslatorForValue(OCASTTranslator)>visitNode: 0x6e12450: a(n) OCASTTranslatorForValue
0xbfff9190 M [] in OCASTTranslatorForValue(OCASTTranslator)>emitMessageNode: 0x6e12450: a(n) OCASTTranslatorForValue
0xbfff91b4 M OrderedCollection>do: 0x6e12480: a(n) OrderedCollection
0xbfff91d0 M OCASTTranslatorForValue(OCASTTranslator)>emitMessageNode: 0x6e12450: a(n) OCASTTranslatorForValue
0xbfff91ec M OCASTTranslatorForValue(OCASTTranslator)>visitMessageNode: 0x6e12450: a(n) OCASTTranslatorForValue
0xbfff9208 M RBMessageNode>acceptVisitor: 0x6e124f8: a(n) RBMessageNode
0xbfff9224 M OCASTTranslatorForValue(RBProgramNodeVisitor)>visitNode: 0x6e12450: a(n) OCASTTranslatorForValue
0xbfff9240 M OCASTTranslatorForValue(OCASTTranslator)>visitNode: 0x6e12450: a(n) OCASTTranslatorForValue
0xbfff925c M [] in OCASTTranslatorForEffect(OCASTTranslator)>emitMessageNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfff9280 M OrderedCollection>do: 0x6e12550: a(n) OrderedCollection
0xbfff929c M OCASTTranslatorForEffect(OCASTTranslator)>emitMessageNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfffa00c M OCASTTranslatorForEffect>emitMessageNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfffa028 M OCASTTranslatorForEffect(OCASTTranslator)>visitMessageNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfffa044 M RBMessageNode>acceptVisitor: 0x6e125c8: a(n) RBMessageNode
0xbfffa060 M OCASTTranslatorForEffect(RBProgramNodeVisitor)>visitNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfffa07c M OCASTTranslatorForEffect(OCASTTranslator)>visitNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfffa098 M [] in OCASTTranslatorForEffect>visitSequenceNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfffa0bc M OrderedCollection>do: 0x6e12668: a(n) OrderedCollection
0xbfffa0d8 M OCASTTranslatorForEffect>visitSequenceNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfffa0f4 M RBSequenceNode>acceptVisitor: 0x6e126e0: a(n) RBSequenceNode
0xbfffa110 M OCASTTranslatorForEffect(RBProgramNodeVisitor)>visitNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfffa12c M OCASTTranslatorForEffect(OCASTTranslator)>visitNode: 0x6e12520: a(n) OCASTTranslatorForEffect
0xbfffa148 M OCASTTranslator>visitMethodNode: 0x6e12708: a(n) OCASTTranslator
0xbfffa164 M RBMethodNode>acceptVisitor: 0x6e12780: a(n) RBMethodNode
0xbfffa180 M OCASTTranslator(RBProgramNodeVisitor)>visitNode: 0x6e12708: a(n) OCASTTranslator
0xbfffa19c M OCASTTranslator>visitNode: 0x6e12708: a(n) OCASTTranslator
0xbfffa1bc M RBMethodNode>generateIR 0x6e12780: a(n) RBMethodNode
0xbfffa1d4 M RBMethodNode>generate: 0x6e12780: a(n) RBMethodNode
0xbfffa1f4 M [] in OpalCompiler>compile 0x6e127e8: a(n) OpalCompiler
0xbfffa20c M BlockClosure>on:do: 0x6e12868: a(n) BlockClosure
0xbfffa230 M OpalCompiler>compile 0x6e127e8: a(n) OpalCompiler
0xbfffa250 M AbstractNautilusUI class(Behavior)>recompile:from: 0x7fb08f8: a(n) AbstractNautilusUI class
0xbfffa274 M [] in AbstractNautilusUI class(Behavior)>compileAllFrom: 0x7fb08f8: a(n) AbstractNautilusUI class
0xbfffa29c M Set>do: 0x6e12970: a(n) Set
0xbfffaf34 M AbstractNautilusUI class(Behavior)>compileAllFrom: 0x7fb08f8: a(n) AbstractNautilusUI class
0xbfffaf50 M AbstractNautilusUI class(Class)>compileAllFrom: 0x7fb08f8: a(n) AbstractNautilusUI class
0xbfffaf6c M AbstractNautilusUI class(Behavior)>compileAll 0x7fb08f8: a(n) AbstractNautilusUI class
0xbfffaf8c I AbstractNautilusUI class(Class)>compileAll 0x7fb08f8: a(n) AbstractNautilusUI class
0xbfffafac I AbstractNautilusUI class(Behavior)>recompile 0x7fb08f8: a(n) AbstractNautilusUI class
0xbfffafc4 M [] in SmalltalkImage>recompile 0x74ca9b8: a(n) SmalltalkImage
0xbfffaff8 M [] in OrderedCollection(Collection)>do:displayingProgress:every: 0x6e12aa0: a(n) OrderedCollection
0xbfffb01c M OrderedCollection>do: 0x6e12aa0: a(n) OrderedCollection
0xbfffb054 I [] in OrderedCollection(Collection)>do:displayingProgress:every: 0x6e12aa0: a(n) OrderedCollection
0xbfffb078 I BlockClosure>cull: 0x6e12b40: a(n) BlockClosure
0xbfffb094 M [] in Job>run 0x6e12a58: a(n) Job
0xbfffb0b8 M [] in CurrentJob(DynamicVariable)>value:during: 0x72f6dc0: a(n) CurrentJob
0xbfffb0d8 M BlockClosure>ensure: 0x6e12b80: a(n) BlockClosure
0xbfffb104 I CurrentJob(DynamicVariable)>value:during: 0x72f6dc0: a(n) CurrentJob
0xbfffb12c I CurrentJob class(DynamicVariable class)>value:during: 0x7233b28: a(n) CurrentJob class
0xbfffb14c M [] in Job>run 0x6e12a58: a(n) Job
0xbfffb16c M BlockClosure>ensure: 0x6e12c80: a(n) BlockClosure
0xbfffb190 I Job>run 0x6e12a58: a(n) Job
0xbfffb1b0 I MorphicUIManager(UIManager)>displayProgress:from:to:during: 0x9a2c2d8: a(n) MorphicUIManager
0xbfffb1e0 I ByteString(String)>displayProgressFrom:to:during: 0x748c040: a(n) ByteString
0xbfffb214 I OrderedCollection(Collection)>do:displayingProgress:every: 0x6e12aa0: a(n) OrderedCollection
0xbfffb240 I OrderedCollection(Collection)>do:displayingProgress: 0x6e12aa0: a(n) OrderedCollection
0xbfffb268 I SmalltalkImage>recompile 0x74ca9b8: a(n) SmalltalkImage
0xbfffb288 I OpalCompiler class>recompileAll 0x7310170: a(n) OpalCompiler class
Sept. 22, 2017
Re: [Pharo-dev] [ci-announces] [CI] July 28, 2017 Incident Report
by David T. Lewis
Kudos for providing a good incident report and explanation of the cause of the problem.
I know little about this actual incident, but that it not important. It is really good
to see constructive responses to problems like this with a focus on inprovement and
problem prevention in the future.
Dave
On Thu, Sep 21, 2017 at 03:35:19PM +0200, Christophe Demarey wrote:
> July 28, 2017 Incident Report
>
> This summer, we experienced a hard incident on the Continuous Integration service infrastructure.Today we???re providing an incident report that details the nature of the incident and our response.
> We understand this service issue has impacted all Inria developers using the CI service and their valued time, and we apologize to everyone who was affected.
>
> Issue summary
> Due to a manipulation error, a lot of Virtual Machines (VM) hosted on CloudStack were destroyed and not recoverable!
> Jenkins servers are not concerned by this issue, so all Jenkins jobs and history are safe.
>
> Root cause
> After the successful migration of Jenkins servers and security fixes (July 18-19, 2017), a few projects were not able to reach their slaves hosted on the CI build farm. This problem was due to a synchronization problem between the CI database and CloudStack (powering the CI build farm) having its own way to manage projects and users (through domains).
> An attempt to reproduce and debug this problem on the qualification infrastructure failed. So, we added some logging on the production infrastructure. To avoid troubles to the production infrastructure, we limited the synchronization to one project. It was the mistake!
> The synchronization of one project led to the deletion of all other CloudStack domains (i.e. projects). Indeed, the synchronization code expected to get the full environment (all CI projects) and if it finds a domain not bound to a CI project, it deletes it...
> The synchronization process was aborted before its termination but it was too late. Some user Virtual Machines were still alive during some hours but were finally purged by CloudStack.
> It means we lost most VM and templates hosted on the CI build farm.
>
> Resolution and recovery
> It was impossible to recover destroyed virtual machines. CloudStack is configured to keep VM data 24 hours before actually destroying it but it does not work when the domain hosting the VM is destroyed.
> Primary storage hosting running VM is a high-performance and very expensive storage. That???s why the CI team chose (at the CI service setup) to do not backup VM but rather to rely on both the expunge delay and the snapshot / template mechanism to save VM state. This mechanism was useless in relation to this incident.
> Templates and snapshots are hosted on the secondary storage that is a redundant storage in two different buildings to ensure data reliability and recovery. The incident led CloudStack to perform a ?? clean ?? deletion of all the domain data including templates. That???s why they also became unavailable.
>
> We were able to rebuild all domains from the CI database but CI service users had to create new VM to replace the destroyed ones.
>
> Corrective and preventative measures
> All members of the CI team (DSI, SED) worked and are still working all together to find the best solution to mitigate the incident and prevent same situations in the future.
> The synchronization code responsible of the deletion of CloudStack domain has been deactivated. CloudStack domain deletion is a critical action and will no longer be automated. Deletions will be reviewed and approved by the CI team before being completed.
> This incident showed us that backup mechanism in place are not strong enough and we are now evaluating the cost to backup, with history:
> all VM, snapshots and templates or
> all snapshots and templates.
> We are also working on providing a way to download templates created on CloudStack so that you can easily get a copy of them. We encourage you to create templates for virtual machines that are time consuming to set up from scratch.
>
>
> Sincerely,
> The CI Team
Sept. 22, 2017