forum-msg-id-129197-edit

Original date:2015-12-16 12:50:09 Edited by: jimcbrown Subject: Re: eusqlite and SDL on Windows 8.1

ChrisB said...

Hi

Ok, this kind of needs to be standardised.

Well, the memstructs branch is currently a non-standardized dev only branch...

ChrisB said...

I have the memstruct include, but rightly or wrongly I overwite installs. So I have overwritten the eu 4.1 that wasn't working, with eu 4.05 that is, and as a result the includes still show the memstruct include.

That's why I didn't go this route - that test is helpful but not definitive.

Now the 4.1 was an overwrite too - and I don't know whether the last overwrite was with 4.1 + memstructs, or 4.1 - memstructs.

Running eui in the backed up folder tells me it's 4.1 development using system memory, and the most recently installed tells me that it's 4.05 using managed memory.

ChrisB said...

I propose, as a matter of urgency that a versioning system be included in the euphoria interpreters / compilers etc, that tells us which version is being used, which branch / sub branch etc.

You can already find this out. In the version output, a hash is given that represents the hg revision. You can visit http://scm.openeuphoria.org/hg/euphoria/rev/ rev> (e.g. http://scm.openeuphoria.org/hg/euphoria/rev/85f1de9939fc ) to see what branch the commit was from, when the commit was made, etc.

In euphoria/source/version.h we already have a system to differentiate different types of releases, and this is where memstructs should have been marked. But the dev in charge simply didn't do that for the memstructs branch.

ChrisB said...

It would also seem that the standard includes progress at a slower rate than the interpreter - these should be versioned too,

We already have this information in hg. I'm not sure how much having a separate versioning system for the stdlib would help us, though some other language do take this approach.

ChrisB said...

and if an update to the includes is required for some new feature, then the interpreter should halt until the includes have been updated.

This is already the case in the mainline branches (standard 4.0 and 4.1). Halting bug fixes/etc in the mainline branches while someone is doing experimental work in an experiment branch would be seriously impractical - remember that not every such branch and feature ends up getting adopted.

Not Categorized, Please Help

Search



Quick Links

User menu

Not signed in.

Misc Menu