[Vm-dev] snafu for e013b6766a05037812d48960702c0910
btc at openinworld.com
Fri Nov 24 05:27:41 UTC 2017
On 24 November 2017 at 12:18, Holger Freyther <holger at freyther.de> wrote:
> > On 16. Nov 2017, at 07:18, Eliot Miranda <eliot.miranda at gmail.com>
> > Hi All,
> I was looking at a OpenSSL issue and master with spur seems to be broken,
> is it because of the same issue? What would it take to have everyone use
> Pull Requests and benefit from pre-merge testing? These days computing time
> is so cheap... (think of a reference to the mythical man month)
I haven't used them, but there seem a few options for issuing PRs from the
command-line, which may make this more palatable.
Thus the CI should run without needing to visit github's web-UI.
https://hub.github.com/ (search for "pull")
> > mea culpa. Yesterday I managed to generate completely broken
> sources and broke CI servers etc. I've realized what went wrong. For the
> past week I've been doing VM development in a 64-bit Squeak image (*) and
> yesterday for the first time I generated sources from the 64-bit image.
> There was old very broken code in VMMaker:
> > VMMaker>>initialize
> > logger := Transcript.
> > inline := true.
> > forBrowser := false.
> > internalPlugins := SortedCollection new.
> > externalPlugins := SortedCollection new.
> > platformName := self class machinesDirName.
> > >> is64BitVM := Smalltalk wordSize == 8.
> > interpreterClassName := Interpreter name.
> > optionsDictionary := Dictionary new.
> > >> optionsDictionary at: #BytesPerWord put: Smalltalk wordSize.
> > VMStructType voidStructTypeCache
> > which caused mayhem. In particular, invalid types were inferred for
> plugin files. These files ahem to be generated choosing types such that
> the generated files work on both 64 and 32-bit. That means /not/
> initializing the VMMaker instance as above.
> > I'm not sure when things will be back to normal but it should be soon,
> given that I finally understand what went wrong. Apologies for all the
> > (*) I was looking at Juan Vuletich's 64-bit scavenger crash due to
> remember set overflow that Clément fixed recently. I was adding logging to
> the scavenger so we can better analyse failures like this and better tune
> the GC. Simulation of a 64-bit image is somewhat quicker in 64-bits (less
> work synthesizing 64-bit values from the heap) and so I thought I'd try
> developing in 64-bits.
> > _,,,^..^,,,_
> > best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev