Hi All,
on returning to VM work I'm seeing lots of VM crashes with recent changes. It looks like the 4-bit Windows work has really affected things. What to do? Personally I'd like to see the type inferrence and platform changes reverted and the work put on a fork. But that's just my opinion. Thoughts? _,,,^..^,,,_ best, Eliot |
it is easy to fork a branch in GIT you should do that. Only stable code (you can decide what that means) should reach the main branch or merged into the Cog Branch. Git makes it easy to experiment by forking. Don't merge stuff until you can show the branch/commit point is stable. On Fri, Aug 5, 2016 at 5:40 PM, Eliot Miranda <[hidden email]> wrote:
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk =========================================================================== |
Hi, I agree that only reasonably stable code should go into the Cog branch. But how do we ensure that? I'm against going with someone's "gut feeling" for this, instead I think we really do need some tests. Right now the only "test" we run is that the VM compiles in different configurations on different platforms. We really need proper stress tests, in-Image as well as out-of-Image. There are many tests in Squeak, for example, that have nothing to do with the system and only test VM specifics (that are subject to change anyway, like testing that Floats are boxed). Personally I would think we should move these into the VM project and run them on Travis. Additionally we need an easy way to add a test when a new crash is discovered to guard ourselves against regressions. I believe that with more people making contributions (which was one of the reasons for the github move) it just becomes infeasible to always test branches manually. Am 06.08.2016 3:27 vorm. schrieb "John McIntosh" <[hidden email]>:
|
On 06.08.2016, at 08:46, Tim Felgentreff <[hidden email]> wrote: > Hi, > > I agree that only reasonably stable code should go into the Cog branch. But how do we ensure that? I'm against going with someone's "gut feeling" for this, instead I think we really do need some tests. Right now the only "test" we run is that the VM compiles in different configurations on different platforms. We really need proper stress tests, in-Image as well as out-of-Image. There are many tests in Squeak, for example, that have nothing to do with the system and only test VM specifics (that are subject to change anyway, like testing that Floats are boxed). Personally I would think we should move these into the VM project and run them on Travis. Additionally we need an easy way to add a test when a new crash is discovered to guard ourselves against regressions. > > I believe that with more people making contributions (which was one of the reasons for the github move) it just becomes infeasible to always test branches manually. Nothing to add, just what he says. Best regards -Tobias |
Hi Eliot, the VMMaker changes relative to LLP64 are so far really tiny: just the change of CCodeGenerator for >> and the memcpy.The infrastructure progress (automated tests), and the way to declare a VM stable (whatever it is) are there to enable this process. If we use such process for each feature, we could integrate several features at once, with so called "octopus" merge. This would be the process nearest to current one: the integrator (you) assemble several features for the next "release" (understand HEAD commit). This may raise several questions about rebasing or merging changes, but it's worth thinking about it. 2016-08-06 11:00 GMT+02:00 Tobias Pape <[hidden email]>:
|
On Mon, Aug 8, 2016 at 2:51 AM, Nicolas Cellier <[hidden email]> wrote:
I'm having difficulty focussing on fixing this problem right now because the bug means I don't have a stable VM. I'm trying to a) release machine code shallowCopy and b) fix a Slang bug (a TSendNode whose receiver is a Set instead of a member of the TParseNode hierarchy). So right now I want to locate a VM that was built before any of the changes that was stable. I suppose I could revert my git repository and go from that. But I'd prefer to download one. Things seemed stable in June. i wonder what revision to revert to. I'll take a look. Bisecting is hard without a reliable test to crash the program :-( BTW, somehow I forgot to mark SpurMemoryManager>>markAndTrace: as <inline: #never> and consequently it is being inlined into markAndTraceStackPage; not a good idea ;-) I'll be able to respond more cogently when I feel I have a stable VM :-/
_,,,^..^,,,_ best, Eliot |
In reply to this post by timfelgentreff
Hi Tim,
On Fri, Aug 5, 2016 at 11:46 PM, Tim Felgentreff <[hidden email]> wrote:
Agreed. We need a suite of tests that is strong enough that we would mark as stable any VM that passed them all. A simple test is running the test suite, but IME that doesn't stress the VM enough; it does find VM flaws in primitives, etc. But may not stress the system enough to find GC bugs. One test then is to build a VMMaker image from the updated trunk image (a la image/buildspurtrunkvmmakerimage.sh) and have this image produce all sources (a la [VMMaker generateAllConfigurationsUnderVersionControl] valueSupplyingAnswer: false). All this should happen in three ways: - in a single step, updating the image, loading all of VMMaker and then generating all the sources, - in a single step, but with a save after each step - as three steps, updating the image, saving and quitting, launching, loading all of VMMaker, saving and quitting, launching, generating all sources This is a good stress case for my usage (and would certainly identify the current instability). Chris M, could you contribute a Magma multi-image test in any form? Anyone else have any big stress cases?
_,,,^..^,,,_ best, Eliot |
On Fri, Aug 12, 2016 at 1:28 AM, Eliot Miranda <[hidden email]> wrote: > > Hi Tim, > > On Fri, Aug 5, 2016 at 11:46 PM, Tim Felgentreff <[hidden email]> wrote: >> >> >> >> Hi, >> >> I agree that only reasonably stable code should go into the Cog branch. But how do we ensure that? I'm against going with someone's "gut feeling" for this, instead I think we really do need some tests. Right now the only "test" we run is that the VM compiles in different configurations on different platforms. We really need proper stress tests, in-Image as well as out-of-Image. There are many tests in Squeak, for example, that have nothing to do with the system and only test VM specifics (that are subject to change anyway, like testing that Floats are boxed). Personally I would think we should move these into the VM project and run them on Travis. Additionally we need an easy way to add a test when a new crash is discovered to guard ourselves against regressions. >> >> I believe that with more people making contributions (which was one of the reasons for the github move) it just becomes infeasible to always test branches manually. > > Agreed. We need a suite of tests that is strong enough that we would mark as stable any VM that passed them all. > > A simple test is running the test suite, but IME that doesn't stress the VM enough; it does find VM flaws in primitives, etc. But may not stress the system enough to find GC bugs. > > One test then is to build a VMMaker image from the updated trunk image (a la image/buildspurtrunkvmmakerimage.sh) and have this image produce all sources (a la [VMMaker generateAllConfigurationsUnderVersionControl] valueSupplyingAnswer: false). All this should happen in three ways: > - in a single step, updating the image, loading all of VMMaker and then generating all the sources, Would this then be done by Travis? If the sources were generated there, then maybe its a reasonable workflow to generate sources prior to building the VM(??), and have only Travis commit the generated sources prior to building the VM, and then tests that new VM generating sources again. cheers -ben > - in a single step, but with a save after each step > - as three steps, updating the image, saving and quitting, launching, loading all of VMMaker, saving and quitting, launching, generating all sources > > This is a good stress case for my usage (and would certainly identify the current instability). > > Chris M, could you contribute a Magma multi-image test in any form? > > Anyone else have any big stress cases? > >> >> Am 06.08.2016 3:27 vorm. schrieb "John McIntosh" <[hidden email]>: >>> >>> >>> it is easy to fork a branch in GIT you should do that. >>> >>> Only stable code (you can decide what that means) should reach the main branch or merged into the Cog Branch. >>> >>> Git makes it easy to experiment by forking. Don't merge stuff until you can show the branch/commit point is stable. >>> >>> >>> >>> On Fri, Aug 5, 2016 at 5:40 PM, Eliot Miranda <[hidden email]> wrote: >>>> >>>> >>>> Hi All, >>>> >>>> on returning to VM work I'm seeing lots of VM crashes with recent changes. It looks like the 4-bit Windows work has really affected things. What to do? >>>> >>>> Personally I'd like to see the type inferrence and platform changes reverted and the work put on a fork. But that's just my opinion. Thoughts? >>>> >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>> >>> >>> >>> -- >>> =========================================================================== >>> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk >>> =========================================================================== >>> >> > > > > -- > _,,,^..^,,,_ > best, Eliot > |
Free forum by Nabble | Edit this page |