1. 4.0 vs. 4.1

Forked from Re: minimanual.pdf -- comments requested

jimcbrown said...
SDPringle said...
jimcbrown said...

Sounds like a reason to drop 4.0.6 and focus all our efforts on 4.1.0, instead of having to find and fix the same bugs in two codebases.

Jim, you really have to lock your computer when you walk away from the keyboard. Look at the kind of ignorant things get posted in your name.

I really am leaning towards the view that we should focus all efforts into 4.1.0 and not into 4.0.6.

It sounded like you meant something else. I honestly could not believe it. Sorry about that.

Rather than introduce new changes, I am of the opinion that users prefer to have something that has fewer bugs first. Once squashed, add features.

Any bug fix for 4.1 if it also in 4.0, is to get committed to the 4.0 branch. Later, this 4.0 change is to get merged into 4.1. Then the changes ported if necessary to 64-bit platforms. I am under the impression that all of the 4.0 bugs tickets also affect the current 4.1 tip.

Shawn

new topic     » topic index » view message » categorize

2. Re: 4.0 vs. 4.1

SDPringle said...

It sounded like you meant something else. I honestly could not believe it. Sorry about that.

Not a problem.

SDPringle said...

Rather than introduce new changes, I am of the opinion that users prefer to have something that has fewer bugs first. Once squashed, add features.

This was one of the reasons that memstructs was left out of 4.1.0 originally. However, the release of 4.1.0 has taken so long, and apparently for no good reason, that to leave this well developed and well debugged feature out seems like a loss for no gain. (Merging it in wouldn't be very hard and wouldn't take very long, and it seems like more users use the memstructs version instead of the default branch of 4.1, which means it might be better debugged as well.)

Only 4 devs have ever done a release - Jeremy, Matt, Shawn, and Ira (who did 4.1.0 beta). In the past, Jeremy and Matt were the leads and did most of the heavy lifting, but nowadays neither of them appear to have time to do the extremly tedious and unglamourous work involved.

SDPringle said...

I am under the impression that all of the 4.0 bugs tickets also affect the current 4.1 tip.

To the best of my knowledge, this is correct.

SDPringle said...

Then the changes ported if necessary to 64-bit platforms.

This is not automatic, however. It's quite possible the author of the 4.0 patch doesn't know how to apply it to 64bit code, and the merger doesn't understand the patch well enough to do the job.

Still, with two main lines and the extra platforms on the 4.1 line, that's probably the best we can do.

new topic     » goto parent     » topic index » view message » categorize

3. Re: 4.0 vs. 4.1

jimcbrown said...
SDPringle said...

Rather than introduce new changes, I am of the opinion that users prefer to have something that has fewer bugs first. Once squashed, add features.

This was one of the reasons that memstructs was left out of 4.1.0 originally. However, the release of 4.1.0 has taken so long, and apparently for no good reason, that to leave this well developed and well debugged feature out seems like a loss for no gain. (Merging it in wouldn't be very hard and wouldn't take very long, and it seems like more users use the memstructs version instead of the default branch of 4.1, which means it might be better debugged as well.)

I agree it should be merged, it's been mentioned before, many many people are already using memstruct branch. the memstruct feature does not have any impact on the rest of the interpreter or compiler and thus can be ignored by anyone else. there are minimal docs but a growing number of examples on the forum and archive already utilizing memstructs.

there are many innocent or maybe not so innocent ways to trigger a silent exit by misuse of the syntax or as yet undiscovered bugs. there are a few key features not implemented which are required now and again to wrap some libraries. I don't know if there are any planned changes to existing syntax or implementation to make room for the missing features.

so, missing syntax, more tests, coverage and who knows what else?

Matt has already said it's not ready to merge yet so there's the current best answer.

  • I should add, no impact on the use of the interpreter or translator, there may well be plenty of implications for anyone working on the interpreter or translator that would require a working knowledge of memstructs to avoid breakage.
new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu