1. ver. 4.0 WIN98 Binaries
- Posted by bernie Sep 12, 2008
- 1553 views
Caution this may cause a problem if you are using SVN 1159 include files.
Binaries contained in eu40win9x-1159.zip are in fact SVN 1160
2. Re: ver. 4.0 WIN98 Binaries
- Posted by jeremy (admin) Sep 12, 2008
- 1573 views
Thanks for pointing that out Bernie. I think what's going wrong is revget.e ... It's pulling the revision from the euphoria/source directory. In 1160, euphoria/source was not updated, only euphoria/include ... thus, the .svn folder in euphoria/source still reflects 1159.
Jim, does that sound right? Maybe you have further input on this?
Jeremy
3. Re: ver. 4.0 WIN98 Binaries
- Posted by jimcbrown (admin) Sep 12, 2008
- 1542 views
Thanks for pointing that out Bernie. I think what's going wrong is revget.e ... It's pulling the revision from the euphoria/source directory. In 1160, euphoria/source was not updated, only euphoria/include ... thus, the .svn folder in euphoria/source still reflects 1159.
Jim, does that sound right? Maybe you have further input on this?
Jeremy
This is possible. I'll update the Makefile to use the toplevel .svn in order to avoid this.
4. Re: ver. 4.0 WIN98 Binaries
- Posted by bernie Sep 12, 2008
- 1545 views
Caution this may cause a problem if you are using SVN 1159 include files.
Binaries contained in eu40win9x-1159.zip are in fact SVN 1160
Will someone please compile a new WIN98 Binary for the latest SVN
There is something wrong with SVN 1159 ( 1160 )
It is crashing on my win98 system
I had no problems with the last SVN binaries Jim made but
I deleted them while upgrading and installing SVN 1159 ( 1160 )
5. Re: ver. 4.0 WIN98 Binaries
- Posted by jimcbrown (admin) Sep 12, 2008
- 1584 views
I just tested them, and they ran buzz.ex fine
What is the error you are getting?
Caution this may cause a problem if you are using SVN 1159 include files.
Binaries contained in eu40win9x-1159.zip are in fact SVN 1160
Will someone please compile a new WIN98 Binary for the latest SVN
There is something wrong with SVN 1159 ( 1160 )
It is crashing on my win98 system
I had no problems with the last SVN binaries Jim made but
I deleted them while upgrading and installing SVN 1159 ( 1160 )
6. Re: ver. 4.0 WIN98 Binaries
- Posted by bernie Sep 12, 2008
- 1532 views
I just tested them, and they ran buzz.ex fine
What is the error you are getting?
Caution this may cause a problem if you are using SVN 1159 include files.
Binaries contained in eu40win9x-1159.zip are in fact SVN 1160
Will someone please compile a new WIN98 Binary for the latest SVN
There is something wrong with SVN 1159 ( 1160 )
It is crashing on my win98 system
I had no problems with the last SVN binaries Jim made but
I deleted them while upgrading and installing SVN 1159 ( 1160 )
This program has an invalid page fault in module EXW.EXE at 0167:0040ab3d. If the problem persists, contact the program vendor. EXW caused an invalid page fault in module EXW.EXE at 0167:0040ab3d. Registers: EAX=005c64ec CS=0167 EIP=0040ab3d EFLGS=00010213 EBX=00000008 SS=016f ESP=0063f640 EBP=0063f6a8 ECX=00000000 DS=016f ESI=00000000 FS=510f EDX=800b8c9c ES=016f EDI=00000000 GS=0000 Bytes at CS:EIP: 8b 3c fd 00 00 00 00 8b 7f 0c 81 ff ff ff ff bf Stack dump: 00000020 00473ef6 00000008 00001733 800d2b5f 00000000 00000000 00000000 00000019 0000173b 800d2b5f 00000000 00000000 00000000 00000000 00000000
7. Re: ver. 4.0 WIN98 Binaries
- Posted by jimcbrown (admin) Sep 12, 2008
- 1562 views
- Last edited Sep 13, 2008
Looks like you are running a binary that has managed mem disabled (simple malloc turned on).
I assume this error occurs immedately as soon as you run exw or exwc, before it gets to the prompt where it asks you for a file name to run?
This program has an invalid page fault in module EXW.EXE at 0167:0040ab3d. If the problem persists, contact the program vendor. EXW caused an invalid page fault in module EXW.EXE at 0167:0040ab3d. Registers: EAX=005c64ec CS=0167 EIP=0040ab3d EFLGS=00010213 EBX=00000008 SS=016f ESP=0063f640 EBP=0063f6a8 ECX=00000000 DS=016f ESI=00000000 FS=510f EDX=800b8c9c ES=016f EDI=00000000 GS=0000 Bytes at CS:EIP: 8b 3c fd 00 00 00 00 8b 7f 0c 81 ff ff ff ff bf Stack dump: 00000020 00473ef6 00000008 00001733 800d2b5f 00000000 00000000 00000000 00000019 0000173b 800d2b5f 00000000 00000000 00000000 00000000 00000000
8. Re: ver. 4.0 WIN98 Binaries
- Posted by ne1uno Sep 12, 2008
- 1532 views
- Last edited Sep 13, 2008
please anyone, give some details about what you were trying to do when a crash happens.
could there be a replace(), insert() or remove() in the program? they have been known to crash and have been fixed recently.
give the dev's something to work with, post the smallest bit of program or test that crashes if you can.
or is it as jim asks, always crash on any program at startup?
if you see the svn number banner, it could not have been a non managed mem compile I think. they are quite crash happy on win9x.
Looks like you are running a binary that has managed mem disabled (simple malloc turned on).
I assume this error occurs immedately as soon as you run exw or exwc, before it gets to the prompt where it asks you for a file name to run?
This program has an invalid page fault in module EXW.EXE at 0167:0040ab3d. If the problem persists, contact the program vendor. EXW caused an invalid page fault in module EXW.EXE at 0167:0040ab3d. Registers: EAX=005c64ec CS=0167 EIP=0040ab3d EFLGS=00010213 EBX=00000008 SS=016f ESP=0063f640 EBP=0063f6a8 ECX=00000000 DS=016f ESI=00000000 FS=510f EDX=800b8c9c ES=016f EDI=00000000 GS=0000 Bytes at CS:EIP: 8b 3c fd 00 00 00 00 8b 7f 0c 81 ff ff ff ff bf Stack dump: 00000020 00473ef6 00000008 00001733 800d2b5f 00000000 00000000 00000000 00000019 0000173b 800d2b5f 00000000 00000000 00000000 00000000 00000000
9. Re: ver. 4.0 WIN98 Binaries
- Posted by bernie Sep 13, 2008
- 1551 views
please anyone, give some details about what you were trying to do when a crash happens.
could there be a replace(), insert() or remove() in the program? they have been known to crash and have been fixed recently.
give the dev's something to work with, post the smallest bit of program or test that crashes if you can.
or is it as jim asks, always crash on any program at startup?
if you see the svn number banner, it could not have been a non managed mem compile I think. they are quite crash happy on win9x.
Looks like you are running a binary that has managed mem disabled (simple malloc turned on).
I assume this error occurs immedately as soon as you run exw or exwc, before it gets to
the prompt where it asks you for a file name to run?
This program has an invalid page fault in module EXW.EXE at 0167:0040ab3d. If the problem persists, contact the program vendor. EXW caused an invalid page fault in module EXW.EXE at 0167:0040ab3d. Registers: EAX=005c64ec CS=0167 EIP=0040ab3d EFLGS=00010213 EBX=00000008 SS=016f ESP=0063f640 EBP=0063f6a8 ECX=00000000 DS=016f ESI=00000000 FS=510f EDX=800b8c9c ES=016f EDI=00000000 GS=0000 Bytes at CS:EIP: 8b 3c fd 00 00 00 00 8b 7f 0c 81 ff ff ff ff bf Stack dump: 00000020 00473ef6 00000008 00001733 800d2b5f 00000000 00000000 00000000 00000019 0000173b 800d2b5f 00000000 00000000 00000000 00000000 00000000
The program crashs during the parse of a large program and I don't know
where it is crashing; all I get is the above error.
The problem is that the binary zip file was suppose to be SVN 1159.
The binaries inside the zip file were SVN 1160.
Therefore I have no idea what SVN include files were used to compile
the binaries; I have been always using the SVN include files that match
the binaries SVN and not had any problem.
What you don't seem to realize is that it is IMPORTANT that if you compile
binaries that the SVN of the binaries MUST match the SVN of the include
files because I can not guess what include files were used.
If I use newer or older include files I will get error's because
of feature changes and bug fixes.
The easiest solution is to please make new WIN98 binaries using the
same SVN include files.
10. Re: ver. 4.0 WIN98 Binaries
- Posted by jimcbrown (admin) Sep 13, 2008
- 1541 views
The program crashs during the parse of a large program and I don't know
where it is crashing; all I get is the above error.
Ok, if it works fine for small programs (like buzz.ex) then you may have found a bug. :)
Do you have the svn source directory checked out? If you do, please test your program with int.ex and report back what happens.
The problem is that the binary zip file was suppose to be SVN 1159.
The binaries inside the zip file were SVN 1160.
Hopefully this is fixed now. Not that it should make a difference.
Therefore I have no idea what SVN include files were used to compile
the binaries; I have been always using the SVN include files that match
the binaries SVN and not had any problem.
Why not build the binaries yourself?
What you don't seem to realize is that it is IMPORTANT that if you compile
binaries that the SVN of the binaries MUST match the SVN of the include
files because I can not guess what include files were used.
If I use newer or older include files I will get error's because
of feature changes and bug fixes.
In general this is true, but having mismatched include files should never cause the interpreter itself to crash. Not with a segfault.
One possible solution is simply to zip up the entire svn checkout tree after the binaries are built. Then you have both the includes and the binaries, as well as the source used to build them.
The easiest solution is to please make new WIN98 binaries using the
same SVN include files.
My understanding is that this is always the case. The issue was with revget.ex but the includes and the source code used to build the binaries were in fact at the same revision.
11. Re: ver. 4.0 WIN98 Binaries
- Posted by bernie Sep 13, 2008
- 1525 views
The program crashs during the parse of a large program and I don't know
where it is crashing; all I get is the above error.
Ok, if it works fine for small programs (like buzz.ex) then you may have found a bug. :)
Do you have the svn source directory checked out? If you do, please test your program with int.ex and report back what happens.
The problem is that the binary zip file was suppose to be SVN 1159.
The binaries inside the zip file were SVN 1160.
Hopefully this is fixed now. Not that it should make a difference.
Therefore I have no idea what SVN include files were used to compile
the binaries; I have been always using the SVN include files that match
the binaries SVN and not had any problem.
Why not build the binaries yourself?
What you don't seem to realize is that it is IMPORTANT that if you compile
binaries that the SVN of the binaries MUST match the SVN of the include
files because I can not guess what include files were used.
If I use newer or older include files I will get error's because
of feature changes and bug fixes.
In general this is true, but having mismatched include files should never cause the interpreter itself to crash. Not with a segfault.
One possible solution is simply to zip up the entire svn checkout tree after the binaries are built. Then you have both the includes and the binaries, as well as the source used to build them.
The easiest solution is to please make new WIN98 binaries using the
same SVN include files.
My understanding is that this is always the case. The issue was with revget.ex but the includes and the source code used to build the binaries were in fact at the same revision.
One possible solution is simply to zip up the entire svn checkout tree after the binaries are built. Then you have both the includes and the binaries, as well as the source used to build them.
Please, then someone has to do this so I can get around the problem.
I can not build my self if I have no binaries that work.
12. Re: ver. 4.0 WIN98 Binaries
- Posted by jimcbrown (admin) Sep 13, 2008
- 1536 views
From the very latest svn, here is the entire tree including prebuilt binaries (in eu40\source which need to be copied over to eu40\bin)
http://malcom.unkmar.com/eu40.zip
Binaries, source, includes, docs, demos, etc
The program crashs during the parse of a large program and I don't know
where it is crashing; all I get is the above error.
Ok, if it works fine for small programs (like buzz.ex) then you may have found a bug. :)
Do you have the svn source directory checked out? If you do, please test your program with int.ex and report back what happens.
The problem is that the binary zip file was suppose to be SVN 1159.
The binaries inside the zip file were SVN 1160.
Hopefully this is fixed now. Not that it should make a difference.
Therefore I have no idea what SVN include files were used to compile
the binaries; I have been always using the SVN include files that match
the binaries SVN and not had any problem.
Why not build the binaries yourself?
What you don't seem to realize is that it is IMPORTANT that if you compile
binaries that the SVN of the binaries MUST match the SVN of the include
files because I can not guess what include files were used.
If I use newer or older include files I will get error's because
of feature changes and bug fixes.
In general this is true, but having mismatched include files should never cause the interpreter itself to crash. Not with a segfault.
One possible solution is simply to zip up the entire svn checkout tree after the binaries are built. Then you have both the includes and the binaries, as well as the source used to build them.
The easiest solution is to please make new WIN98 binaries using the
same SVN include files.
My understanding is that this is always the case. The issue was with revget.ex but the includes and the source code used to build the binaries were in fact at the same revision.
One possible solution is simply to zip up the entire svn checkout tree after the binaries are built. Then you have both the includes and the binaries, as well as the source used to build them.
Please, then someone has to do this so I can get around the problem.
I can not build my self if I have no binaries that work.
13. Re: ver. 4.0 WIN98 Binaries
- Posted by bernie Sep 13, 2008
- 1557 views
From the very latest svn, here is the entire tree including prebuilt binaries (in eu40\source which need to be copied over to eu40\bin)
http://malcom.unkmar.com/eu40.zip
Binaries, source, includes, docs, demos, etc
The program crashs during the parse of a large program and I don't know
where it is crashing; all I get is the above error.
Ok, if it works fine for small programs (like buzz.ex) then you may have found a bug. :)
Do you have the svn source directory checked out? If you do, please test your program with int.ex and report back what happens.
The problem is that the binary zip file was suppose to be SVN 1159.
The binaries inside the zip file were SVN 1160.
Hopefully this is fixed now. Not that it should make a difference.
Therefore I have no idea what SVN include files were used to compile
the binaries; I have been always using the SVN include files that match
the binaries SVN and not had any problem.
Why not build the binaries yourself?
What you don't seem to realize is that it is IMPORTANT that if you compile
binaries that the SVN of the binaries MUST match the SVN of the include
files because I can not guess what include files were used.
If I use newer or older include files I will get error's because
of feature changes and bug fixes.
In general this is true, but having mismatched include files should never cause the interpreter itself to crash. Not with a segfault.
One possible solution is simply to zip up the entire svn checkout tree after the binaries are built. Then you have both the includes and the binaries, as well as the source used to build them.
The easiest solution is to please make new WIN98 binaries using the
same SVN include files.
My understanding is that this is always the case. The issue was with revget.ex but the includes and the source code used to build the binaries were in fact at the same revision.
One possible solution is simply to zip up the entire svn checkout tree after the binaries are built. Then you have both the includes and the binaries, as well as the source used to build them.
Please, then someone has to do this so I can get around the problem.
I can not build my self if I have no binaries that work.
Thank You very much, I,am in the process of download them.
Bernie
14. Re: ver. 4.0 WIN98 Binaries
- Posted by euphoric (admin) Sep 13, 2008
- 1586 views
Thank You very much, I,am in the process of download them.
Please, for the love of all that's holy... TRIM YOUR POSTS!!!
Look how many lines you quoted just so you could say "Thank you."
Come on. It's not that difficult. And you conserve resources and I don't have to scroll down the page to see that you don't add anything to the conversation.
15. Re: ver. 4.0 WIN98 Binaries
- Posted by bernie Sep 13, 2008
- 1579 views
Thanks Jim:
I finally found what was crashing the system but was not reporting the error.
If you run this simple program on WIN98
It will crash the system.
Note that PreDefList sequence is not declared and
the parser is not detecting it.
-- junk.ew -- sequence dscrip dscrip = PreDefList[1] if getc(0) then end if -- end of junk.ew --
16. Forward reference bug: was Re: ver. 4.0 WIN98 Binaries
- Posted by jimcbrown (admin) Sep 13, 2008
- 1521 views
Thanks Jim:
I finally found what was crashing the system but was not reporting the error.
If you run this simple program on WIN98
It will crash the system.
Same crash on linux. I was able to find the bug in the parser using int.ex
Note that PreDefList sequence is not declared and
the parser is not detecting it.
Yes, this is a forward reference bug.
The parser emits an opcode to state that this is a forward reference that will need to be backpatched later, but then the RHS_SUBS opcode immediately attempts to reference the variable before the parser has had a chance to attempt to backpatch it. (If it had gotten that chance, then this would have just been a simple and easy "variable not declared" error.)
I've fixed it and I'm about to check this in, but I may have discovered another bug. Need to check with Matt L about this one.
-- junk.ew -- sequence dscrip dscrip = PreDefList[1] if getc(0) then end if -- end of junk.ew --
-- junk.ew -- sequence dscrip dscrip = PreDefList[1] if getc(0) then end if sequence PreDefList -- end of junk.ew --
That now comes up with PreDefList being an unresolved forward reference. Is that right??
If it is made a global sequence, then the parser succeeds and we get the obvious runtime error (of PreDefList not having a value).
17. Re: Forward reference bug: was ver. 4.0 WIN98 Binaries
- Posted by ryanj Sep 13, 2008
- 1529 views
-- junk.ew -- sequence dscrip dscrip = PreDefList[1] if getc(0) then end if sequence PreDefList -- end of junk.ew --
That now comes up with PreDefList being an unresolved forward reference. Is that right??
If it is made a global sequence, then the parser succeeds and we get the obvious runtime error (of PreDefList not having a value).
Why would a variable have anything to do with a forward reference? I thought forward references are for routines, not variables.
18. Re: Forward reference bug: was ver. 4.0 WIN98 Binaries
- Posted by jimcbrown (admin) Sep 13, 2008
- 1550 views
Another bug found:
-- junk.ew -- sequence dscrip dscrip = PreDefList[1] if getc(0) then end if global constant PreDefList = "0" -- end of junk.ew --
This gives a runtime error about PreDefList not being assigned a value.
I've fixed it and I'm about to check this in, but I may have discovered another bug. Need to check with Matt L about this one.
-- junk.ew -- sequence dscrip dscrip = PreDefList[1] if getc(0) then end if sequence PreDefList -- end of junk.ew --
That now comes up with PreDefList being an unresolved forward reference. Is that right??
If it is made a global sequence, then the parser succeeds and we get the obvious runtime error (of PreDefList not having a value).
19. Re: Forward reference bug: was ver. 4.0 WIN98 Binaries
- Posted by jimcbrown (admin) Sep 13, 2008
- 1526 views
Why would a variable have anything to do with a forward reference? I thought forward references are for routines, not variables.
Matt added the ability to forward reference variables and constants and enums and etc. This makes a lot of sense, since when dealing with the issue of recursive include files often more than just routines are shared between the libraries.
20. Re: Forward reference bug: was ver. 4.0 WIN98 Binaries
- Posted by mattlewis (admin) Sep 13, 2008
- 1588 views
Why would a variable have anything to do with a forward reference? I thought forward references are for routines, not variables.
Matt added the ability to forward reference variables and constants and enums and etc. This makes a lot of sense, since when dealing with the issue of recursive include files often more than just routines are shared between the libraries.
Yes, the real reason for this is for when two files are interdependent and include each other. Previously, working code was extremely dependent upon which file was included first. Now, it doesn't matter. If you put an include in your file, you don't have to worry about that sort of thing, and you can just use the file, even if it uses you back. It really only allows you to forward reference variables, constants and enums in other files.
Also, it's actually convenient for finding typos in code. Instead of the parser immediately throwing a compile time error, it waits until the end, and you get the entire list of errors that it found. I've found this much more convenient (and easier on my blood pressure) than run, crash, fix....run crash fix....etc...
Matt
21. Re: Forward reference bug: was ver. 4.0 WIN98 Binaries
- Posted by euphoric (admin) Sep 13, 2008
- 1532 views
- Last edited Sep 14, 2008
Also, it's actually convenient for finding typos in code. Instead of the parser immediately throwing a compile time error, it waits until the end, and you get the entire list of errors that it found.
Yes, that was a real nice surprise the other day when I first encountered it.
