1. eusqlite and SDL on Windows 8.1
- Posted by ChrisB (moderator) Dec 16, 2015
- 1442 views
Hi
After months of struggling and trying to get these two 32 bit dlls to run with eu, I finally found the solution (though this was given to me a few months ago, I just got around to doing it)
For some reason the 32 bit eu 4.1 wasn't playing with the sqlite and sdl dlls.
The solution, revert back to eu 4.05 32 bit.
What changed between these two versions broke 32 bit dll access. As it's 4.1 that has memstructs, this could be problemmatical for those that are using this.
Cheers
Chris
2. Re: eusqlite and SDL on Windows 8.1
- Posted by jimcbrown (admin) Dec 16, 2015
- 1414 views
Hi
After months of struggling and trying to get these two 32 bit dlls to run with eu, I finally found the solution (though this was given to me a few months ago, I just got around to doing it)
For some reason the 32 bit eu 4.1 wasn't playing with the sqlite and sdl dlls.
The solution, revert back to eu 4.05 32 bit.
What changed between these two versions broke 32 bit dll access.
That's really disturbing.
As it's 4.1 that has memstructs, this could be problemmatical for those that are using this.
Cheers
Chris
Does it happen only on the memstructs version, or does it also crash with a plain (no-memstructs) 32bit 4.1?
3. Re: eusqlite and SDL on Windows 8.1
- Posted by ChrisB (moderator) Dec 16, 2015
- 1402 views
Hi
How do you tell the difference?
And one thing I didn't mention was that this was on 64 bit system, with dlls local to the program, and in syswow64.
Chris
4. Re: eusqlite and SDL on Windows 8.1
- Posted by jimcbrown (admin) Dec 16, 2015
- 1427 views
How do you tell the difference?
I don't know of an easy way to tell, aside from running a file that uses memstructs and see it work (or fail).
5. Re: eusqlite and SDL on Windows 8.1
- Posted by ne1uno Dec 16, 2015
- 1413 views
Hi
How do you tell the difference?
you would have Eu41include\std\memstruct directory. which seems to only have a windows.e at the moment. also. memstruct is a branch yet to be merged though there are quite a few versions out there now which you might be using.
this should fail on non memstruct
include std/memstruct/windows.e
6. Re: eusqlite and SDL on Windows 8.1
- Posted by ChrisB (moderator) Dec 16, 2015
- 1397 views
Hi
Ok, this kind of needs to be standardised.
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.
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.
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.
It would also seem that the standard includes progress at a slower rate than the interpreter - these should be versioned too, maybe to match a range in the interpreter, and if an update to the includes is required for some new feature, then the interpreter should halt until the includes have been updated.
Cheers
Chris
Forked into: version 4.1.0 and memstructs
7. Re: eusqlite and SDL on Windows 8.1
- Posted by ne1uno Dec 16, 2015
- 1392 views
Hi
Ok, this kind of needs to be standardised.
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.
the include should still give an error if run by a non memstruct interpreter or translator because of the syntax.
you can look at the output of bin/bugreport which shows similar version info you can get with eui -v
it would be useful to hardcode the version of compiler the libs & executables were built with. the right click properties in windows could have additional info too.
BTW, that system memory in windows is probably wrong. it will say system memory no matter which options it's built with,
you can sometimes backtrack the hg version string to get the source used. but that isn't foolproof. the build tools often enough fails to embed that information. bugreport should probably include an SCM URL to output the date/time & revision number if it can be determined.
8. Re: eusqlite and SDL on Windows 8.1
- Posted by jimcbrown (admin) Dec 16, 2015
- 1401 views
Hi
Ok, this kind of needs to be standardised.
Well, the memstructs branch is currently a non-standardized dev only branch...
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.
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/
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.
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.
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.
9. Re: eusqlite and SDL on Windows 8.1
- Posted by ChrisB (moderator) Dec 16, 2015
- 1442 views
Hi
Ok, this kind of needs to be standardised.
Well, the memstructs branch is currently a non-standardized dev only branch...
I know. Don't get me wrong, I'm not complaining.
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.
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/
Ok, didn't know that. Perhaps include that in the general info blurb when the interpreter is run without a program.
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.
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.
It would help if some feature was added, and some numpty (like me) just chucked in the interpreters into the bin folder.
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.
or add --no_version_checking (-nvc) to the command line for experimenters.
Cheers
Chris
10. Re: eusqlite and SDL on Windows 8.1
- Posted by jimcbrown (admin) Dec 16, 2015
- 1456 views
It would help if some feature was added, and some numpty (like me) just chucked in the interpreters into the bin folder.
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.
or add --no_version_checking (-nvc) to the command line for experimenters.
I think I see what you mean now. Adding some sort of version check in the includes folder (so an intepreter would know when the include files are too new to be used with it) is a fairly good idea. I think the fundamental issue is different, though - in some cases it's simply not possible to drop in a new interpreter without updating the stdlib as well.
Maybe if xecronix's EuDrop idea gets off the ground, we'll have an easy way to create a dependency and automatically and painlessly update one along with the other, but short of a package repository management system I don't see an easy way out here.
