1. SVN Revision 1914 and higher
- Posted by jeremy (admin) Apr 10, 2009
- 973 views
- Last edited Apr 11, 2009
Just a warning, 1914 and higher are broke. Work is being done to fix it, but in the mean time, do not do a svn up or you will be sorry. It will compile but result in an unusable interpreter/translator/backend. Stick with your current versions until you hear more here that SVN is functional again.
Jeremy
2. Re: SVN Revision 1914 and higher
- Posted by bernie Apr 11, 2009
- 956 views
Just a warning, 1914 and higher are broke. Work is being done to fix it, but in the mean time, do not do a svn up or you will be sorry. It will compile but result in an unusable interpreter/translator/backend. Stick with your current versions until you hear more here that SVN is functional again.
Jeremy
Jeremy:
I had some code that worked on any binary prior to the change to interpreter's new names.
Any binaries after the name changed; exhibited the failure.
I am using dynamic inline assembler that is built into my code so I had no way to create an example to show the failure.
It is a strtok function that fails to parse anything and returns a result of zero on the first call.
I think that the change back to only managed memory introduced some kind of memory problem because the strtok depends on allocated buffer to be persistent.
I didn't report it because I had no way of proving it. So I decided to wait because I knew the error would eventually show up under other circumstances.
So my suggestion is to go back to the SVN when the names were changed and start looking there.
3. Re: SVN Revision 1914 and higher
- Posted by bernie Apr 11, 2009
- 954 views
Just a warning, 1914 and higher are broke. Work is being done to fix it, but in the mean time, do not do a svn up or you will be sorry. It will compile but result in an unusable interpreter/translator/backend. Stick with your current versions until you hear more here that SVN is functional again.
Jeremy
Jeremy:
I had some code that worked on any binary prior to the change to interpreter's new names.
Any binaries after the name changed; exhibited the failure.
I am using dynamic inline assembler that is built into my code so I had no way to create an example to show the failure.
It is a strtok function that fails to parse anything and returns a result of zero on the first call.
I think that the change back to only managed memory introduced some kind of memory problem because the strtok depends on allocated buffer to be persistent.
I didn't report it because I had no way of proving it. So I decided to wait because I knew the error would eventually show up under other circumstances.
So my suggestion is to go back to the SVN when the names were changed and start looking there.
I just built and tested the binaries up to SVN1705 and they
all ran my above mention code ( strtok ) without any problem.
When I try to build SVN1706 I get the following:
wlink SYS nt op maxe=25 op q op symf op el @E:\dummey\source\intobj\int.lbc na me E:\dummey\source\exwc.exe wrc -q -ad exw.res E:\dummey\source\exwc.exe wlink SYS nt_win op maxe=25 op q op symf op el @E:\dummey\source\intobj\int.lbc name E:\dummey\source\exw.exe wrc -q -ad exw.res E:\dummey\source\exw.exe wmake -h -f makefile.wat E:\dummey\source\exwc.exe EX=e:\dummey\bin\exwc.exe EU_ TARGET=int. OBJDIR=intobj DEBUG= MANAGED_MEM= CONFIG=config.wat DEBUG= MANAGED_M EM= e:\dummey\bin\exwc.exe -i ..\include revget.ex revget.ex:58 in function is_current() slice length is less than 0 (-4) ... called from revget.ex:205 in procedure rev_1_4() ... called from revget.ex:259 in procedure rev_1_3() ... called from revget.ex:276 --> See ex.err Press Enter...
From SVN1706 on I either could not build binaries or
if I could build them then the above ( strtok ) code did not work
using the binaries I built.
4. Re: SVN Revision 1914 and higher
- Posted by SDPringle Apr 11, 2009
- 948 views
You may have svn 1.5 binaries on your system. In that case, indeed revget.ex will fail in some way. Download svnversion and revget will automatically use that.
Shawn
5. Re: SVN Revision 1914 and higher
- Posted by jimcbrown (admin) Apr 11, 2009
- 1008 views
You may have svn 1.5 binaries on your system. In that case, indeed revget.ex will fail in some way. Download svnversion and revget will automatically use that.
Shawn
svn 1706 introduced a bug in revget.ex, that was only fixed in later revisions.
It also true that revget.ex will probably fail on svn 1.5
6. Re: SVN Revision 1914 and higher
- Posted by SDPringle Apr 16, 2009
- 958 views
SVN Revision 1933 works, now. I used a pre-1914 interpreter to build a 1933 tool kit and it passed the unittests. Then I used this 1933 tool kit to build itself and the result passed the unittests.
Shawn Pringle
7. Re: SVN Revision 1914 and higher
- Posted by SDPringle Apr 16, 2009
- 990 views
Correction it passed all but 2:
Test results summary:
FAIL: translated t_pipeio.exe
FAIL: translated t_socket.exe
Files run: 157, failed: 2 (98.7% success
