JS may suck but then so does C/C++. I'm stunned to learn here that after nearly forty years it's still impossible to get comparing ASCII strings in C right!
Programming is objective, right? Why so many shortcuts to program? So nobody knows what it is doing. Said a World uncomplicated, just complications.
Spin to PASM to C to C + + to Java. This crazy world, without any objectivity.
For those learning to program is a nightmare.
If you happen to have a program that runs on some machine you can ask some objective questions about it:
1) How big is it ?
2) How long does it take to produce results?
3) How much memory does it use?
4) How does execution time and memory usage scale with size of the input data?
5) How far does it scale, what are it's limits ?
6) Does it produce correct results for correct input?
7) Does it detect incorrect input?
8) To what precision / accuracy are those results produced?
That's about it for objectivity. Even so of those items are dubious, for example what does "correct result" mean? You can only know that if you have a very rigorous, mathematical, definition of what the function the program is actually supposed to be.
Everything else about programming is subjective.
A) Why was it written in the language it was? Was it written in a nice style?
C) Is it understandable easily?
D) Why was it written in the first place?
E) Why does it do what it does (rather than something else I'd like it to do)?
F) Why does the programmer seem to care about features a,b,c,...and not so much about features x, y, z...?
G) Why is it's user interface like it is ?
H) Is it portable to other similar machines?
All the first group of concerns we might call "computer science", the hard, real, measurable stuff.
The second group of concerns is very woolly, subjective. Some of it is the stuff of "software engineering". But a lot is "art".
Politics also comes into this. The classic case of this is that the GCC compiler tools are written in a certain way so as to make their use from "non-free software" difficult.
Economics has a say in all this. Paying people to write code is an expensive business.
For the programmer, it can be an art. A very emotional thing. They can be very passionate about a thing and the way it is done.
Question A) is a killer because it's recursive. Now you can ask all the same questions about the programming language used to create the program we are looking at. Why is the language the way it is?
You might think that perhaps the hardware of the computer itself is "objective". I suggest this is not true either. You can apply all those same questions to CPU and computer architecture.
Until you get down to logic gates, zeros and ones....perhaps.
I've decide to make the version be 1.00.70 (where 70 is the build number and is one greater than the last build I did on google code).
When I make changes to the source that are between releases, I'll add a 4th number (e.g. 1.00.70.1) that will help with identifying builds that people make from grabbing the source and building instead of using releases. Releases will just have the 3 numbers.
Bill,
I couldn't find anything documenting when gcc changed things such that strcasecmp because stricmp. It seemed like it was with the change to 4.8, but now it appears that it must be in one of the minor versions between 4.8.1 and 4.8.4 (I think). I can tweak that version check and get it updated.
However, you'll need to switch over to the github version (see message #331 in this thread) since I won't be updating the google code one anymore. I say this because you mentioned needing subversion, so I assume you grabbed the google code version which uses svn.
Bill, are you using the github version or the google code version? github is the latest version, google code is no longer being updated.
Looks like you are still using svn to get code from google. That's not going to work, and not going to be updated. You need to use git to get the code from the repository on github.
If you get that version you should see this at the top of PropellerCompiler.h:
//// OpenSpin code uses _stricmp() which is the VC++ name for the function.
// this needs to be remapped to stricmp or strcasecmp depending on the compiler and OS being compiled on
// GCC prior to version 4.8 have strcasecmp on both linux and windows
// GCC 4.8 and newer on linux appears to still have strcasecmp, but GCC 4.8 and newer on windows does not (it has stricmp instead)
//
#if defined(__linux__)
// we are on linux, then always use strcasecmp
#define _stricmp strcasecmp
#else
#if __GNUC__
// if GCC version is 4.8 or greater use stricmp, else use strcasecmp
#if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ >= 8 ))
#define _stricmp stricmp
#else
#define _stricmp strcasecmp
#endif
#endif
#endif
I think I have found some bugs/issues in the latest code:
At command line openspin only accept the first define statement (-D) and ignores each other. The patch for fixing this:
I found a compatibility issue in the FIT directive between OpenSpin and the Propeller Tool (and BST, for that matter).
In my code I am using a combination of the ORG and FIT directives to work as a kind of compile-time check of configuration constants, a trick that I saw someone else post some years ago (sorry, I don't remember who). It works like this:
' Any logical or comparison operation resulting in false in the FIT directive
' will result in a compile-time error.
org 1
' The CACHE_SIZE_BYTES must be a power of two.
' Error means CACHE_SIZE_BYTES is not a power of 2
fit (CACHE_SIZE_BYTES == |< ((>| CACHE_SIZE_BYTES)-1))
This works fine using the Propeller Tool and BST, but does not work for OpenSpin, even if the value is really a power of two. (There is a fairly simple work-around: use the absolute value unary operator, ||, before the expression, to convert the -1 to a 1.)
The following is a more complete program documenting and demonstrating the issue:
{{
fit_tests.spin -- Test the FIT directive operation between BST, OpenSpin and
the Propeller Tool.
(c) Copyright 2014 Thomas Dinger (Ding-Batty)
TERMS OF USE: "MIT License" -- Full license is at the end of the file.
Current Version: Sep 14, 2014
Change History is also at the end of the file.
=====================================================================
Constants: Clock:
}}
CON
_CLKMODE = XTAL1 + PLL16x
_XINFREQ = 5_000_000
'=====================================================================
PUB Main
{{
Main test routine -- does nothing
}}
repeat ' Wait here forever.
'=====================================================================
DAT
{{
Test the FIT command with various value arguments, and document the
behavior of each of the three compilers.
These are divided into two groups:
- Those that work the same for all three compilers
- Those that show behavioral variation.
The test is against an "org 1" directive, so any positive number => 1 should
be allowed by the compiler. The value 0 should generate an error.
We test with a number of "interesting" values.
Of the ones that are inconsistent, the one that is somewhat difficult is the
"-1" case, because it comes in handy when using ORG+FIT as a compile-time
configuration check, for example, to make sure a compile-time configuration
setting is in an acceptable range. For example, I use code to make sure that
a constant has a power-of-two value:
org 1
' The CACHE_SIZE_BYTES must be a power of two.
' Error means CACHE_SIZE_BYTES is not a power of 2
fit (CACHE_SIZE_BYTES == |< ((>| CACHE_SIZE_BYTES)-1))
This _can_ be worked around using the absolute value operator (||):
fit ||(CACHE_SIZE_BYTES == |< ((>| CACHE_SIZE_BYTES)-1))
I was just surprised that this was needed.
I suspect that both BST and the Propeller Tool treat the ORG-FIT comparison
as an unsigned comparison, while (I know that) OpenSpin performs a signed
comparison. Furthermore, the difference for $20000000 is because OpenSpin
converts the COG addresses to "byte" offsets by left-shifting them by
2 bits, so all values in the $20000000..$3FFFFFFF range will become negative
from that shift, thereby failing the signed comparison.
}}
org 1
' Uncomment one of the FIT directives, below, to test it.
' The following all produce the same results in all three compilers.
'fit 0
' BST: error
' PropTool: error
' OpenSpin: error
'fit 1
' BST: OK
' PropTool: OK
' OpenSpin: OK
'fit $1FFFFFFF
' BST: OK
' PropTool: OK
' OpenSpin: OK
'fit $80000000
' BST: error
' PropTool: error
' OpenSpin: error
'fit $80000001
' BST: OK
' PropTool: OK
' OpenSpin: OK
' The following produce different results on the two compilers.
fit -1
'fit $FFFFFFFF ' same as fit -1
' BST: OK
' PropTool: OK
' OpenSpin: error
'fit $7FFFFFFF
' BST: OK
' PropTool: OK
' OpenSpin: error
'fit $20000000
' BST: OK
' PropTool: OK
' OpenSpin: error
{{
==========================================================================
Change History
--------------
Sep 14, 2014: Initial release.
(c) Copyright 2014 Thomas Dinger (Ding-Batty)
TERMS OF USE: "MIT License"
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
}}
This covers Ding-Batty's issue, and one of joergd (the -D one).
For the other two things mentioned by joergd: The case limit one is not changing for now, and the other one I asked him for more info on the github issue, but he has not replied.
I manually updated my PropellerIDE install to 1.00.71 and now it doesn't seem to like a program I wrote 10 minutes ago using #include. If I switch back to 1.00.70 (I renamed instead of deleting), everything is hunky-dorey.
This is the now-offending line, and the file is in my Library folder.
The dialog says "Unable to open file", and yet, if I switch back to the older version of OpenSpin it works just fine. Thanks for investigating -- I think this feature will be immensely helpful.
The dialog says "Unable to open file", and yet, if I switch back to the older version of OpenSpin it works just fine. Thanks for investigating -- I think this feature will be immensely helpful.
Is it possible that the default path for include files changed between versions? Is your include file in the same directory as the Spin file that includes it?
All I did was copy my timing CON block into it's own file. My test (just a simple blinky light program) had that same section commented out and an #include directive for this file added in.
JonnyMac,
Are you sure you are compiling the exact same file when it fails in .71 and works in .70? I'm not able to get it to fail with Unable to open file or anything even remotely like that with version .71 of OpenSpin compileing a spin file that includes your file.
One thing I did notice is that your timing_5x16.spin file has no newline at the end, so when it gets included if there is an important thing on the line immediately after it, then that will cause a compile failure since that next line after the include is actually on the end of the last line in your include. I'm not sure if this is actually a bug or not. Should #include add an newline after what it includes or not? I kind of think not.
GCC adds a newline when including files with an incomplete last line. This seems like a reasonable thing to do since the #include statement is on a separate line. Otherwise programmers will run into the problem that Jon encountered.
In many editors it's hard to notice if there's a missing newline on the last line. So all C compilers that I work with (in addition to GCC) work the way Dave describes. And many other tools.
I will make the change to have the preprocessor add on the newline for an include file that is missing it on the last line.
This doesn't explain JonnyMac's problem though. This preprocessor stuff is identical between 1.00.70 and 1.00.71. He said it worked with 70, but not 71.
Jon, I still need more information/files from you. Please see my message above.
I just started trying to use openspin, and have a problem compiling, any objects in the top level spin file seem to be not found. I'm sure it's something stupid I'm doing but I can't spot it. This is an assembly debugger demo I found.
gnorton-desktop:~/Dropbox/Propeller_Programs/PASD_07> pwd
/home/gnorton/Dropbox/Propeller_Programs/PASD_07
gnorton-desktop:~/Dropbox/Propeller_Programs/PASD_07> ls -l *.spin
-rw-rw-rw- 1 gnorton gnorton 2903 Sep 3 2007 PASD_AsmDebugDemo.spin
-rw-rw-rw- 1 gnorton gnorton 13600 Aug 18 2007 PasDebug.spin
gnorton-desktop:~/Dropbox/Propeller_Programs/PASD_07> /opt/propelleride/bin/openspin -I /home/gnorton/Dropbox/Propeller_Programs/PASD_07 -e -o /home/gnorton/Dropbox/Propeller_Programs/PASD_07/PASD_AsmDebugDemo.eeprom /home/gnorton/Dropbox/Propeller_Programs/PASD_07/PASD_AsmDebugDemo.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.70 Compiled on Aug 6 2014 15:47:27
Compiling...
/home/gnorton/Dropbox/Propeller_Programs/PASD_07/PASD_AsmDebugDemo.spin
|-PASDebug.spin
PASDebug.spin : error : Can not find/open file.
Greg Norton,
The issue I believe you are having is the case of the filename not matching the case in the source code. The file is called PasDebug.spin, but the source code calls out PASDebug.spin.
This is an issue on linux or any OS that has case sensitive file systems. You'll need to either rename the file to be PASDebug.spin or change the source code to PasDebug.spin.
It's a problem that doesn't have a trivial solution in code. It's easier to just make sure the case matches for your files and where they are called out in the source code.
Sorry, Roy, I thought I had responded. After looking at it again, it seems that the new version of OpenSpin doesn't like the included file to be in the Library folder.
Both versions work when include file is in the same folder as the compiled code
The previous version of OpenSpin allows the included file to be in the Library (I renamed the file in the same folder to validate)
The new version of OpenSpin balks when the included file is in the Library -- seems only to be looking in the application folder.
In the Properties selection I highlighted the version of OpenSpin that works (renamed it before installing the newest version).
The include file is what I typically use as my timing header. I hoping to be able to include this in projects and time-oriented objects of that project as it defines ticks/millisecond and I use that a lot.
JonnyMac,
Thanks for the extra details. It's really odd that it works in the previous version, but not now. I haven't changed any of the code for file handling/searching at all between the versions. Hopefully I can replicate the problem with the new info and then debug it. Thanks.
I have found a bug with open spin relating to the -u switch (great feature by the way), it seem the run time memory space is calculated before the un-used methods are removed, so programs that would NOT exceed 32K with un-used methods removed returns the error "Object exceeds run time memory limit", my work around has been to use the -M switch with a size greater than 32K
Comments
JS may suck but then so does C/C++. I'm stunned to learn here that after nearly forty years it's still impossible to get comparing ASCII strings in C right!
Spin to PASM to C to C + + to Java. This crazy world, without any objectivity.
For those learning to program is a nightmare.
Everyone can participate in building tools if they like, but the deep end of the pool should be avoided for anyone not having adequate experience.
If you happen to have a program that runs on some machine you can ask some objective questions about it:
1) How big is it ?
2) How long does it take to produce results?
3) How much memory does it use?
4) How does execution time and memory usage scale with size of the input data?
5) How far does it scale, what are it's limits ?
6) Does it produce correct results for correct input?
7) Does it detect incorrect input?
8) To what precision / accuracy are those results produced?
That's about it for objectivity. Even so of those items are dubious, for example what does "correct result" mean? You can only know that if you have a very rigorous, mathematical, definition of what the function the program is actually supposed to be.
Everything else about programming is subjective.
A) Why was it written in the language it was?
C) Is it understandable easily?
D) Why was it written in the first place?
E) Why does it do what it does (rather than something else I'd like it to do)?
F) Why does the programmer seem to care about features a,b,c,...and not so much about features x, y, z...?
G) Why is it's user interface like it is ?
H) Is it portable to other similar machines?
All the first group of concerns we might call "computer science", the hard, real, measurable stuff.
The second group of concerns is very woolly, subjective. Some of it is the stuff of "software engineering". But a lot is "art".
Politics also comes into this. The classic case of this is that the GCC compiler tools are written in a certain way so as to make their use from "non-free software" difficult.
Economics has a say in all this. Paying people to write code is an expensive business.
For the programmer, it can be an art. A very emotional thing. They can be very passionate about a thing and the way it is done.
Question A) is a killer because it's recursive. Now you can ask all the same questions about the programming language used to create the program we are looking at. Why is the language the way it is?
You might think that perhaps the hardware of the computer itself is "objective". I suggest this is not true either. You can apply all those same questions to CPU and computer architecture.
Until you get down to logic gates, zeros and ones....perhaps.
I used the github release feature to tag the source and also include a zip of the windows binary. See here: https://github.com/reltham/OpenSpin/releases
I've decide to make the version be 1.00.70 (where 70 is the build number and is one greater than the last build I did on google code).
When I make changes to the source that are between releases, I'll add a 4th number (e.g. 1.00.70.1) that will help with identifying builds that people make from grabbing the source and building instead of using releases. Releases will just have the 3 numbers.
make -C PropellerCompiler all make[1]: Entering directory `/home/bhenning/openspin-src/PropellerCompiler' g++ -Wall -g -static -o BlockNestStackRoutines.o -c BlockNestStackRoutines.cpp g++ -Wall -g -static -o CompileDatBlocks.o -c CompileDatBlocks.cpp g++ -Wall -g -static -o CompileExpression.o -c CompileExpression.cpp g++ -Wall -g -static -o CompileInstruction.o -c CompileInstruction.cpp g++ -Wall -g -static -o CompileUtilities.o -c CompileUtilities.cpp g++ -Wall -g -static -o DistillObjects.o -c DistillObjects.cpp g++ -Wall -g -static -o Elementizer.o -c Elementizer.cpp g++ -Wall -g -static -o ErrorStrings.o -c ErrorStrings.cpp g++ -Wall -g -static -o ExpressionResolver.o -c ExpressionResolver.cpp g++ -Wall -g -static -o InstructionBlockCompiler.o -c InstructionBlockCompiler.cpp g++ -Wall -g -static -o StringConstantRoutines.o -c StringConstantRoutines.cpp g++ -Wall -g -static -o SymbolEngine.o -c SymbolEngine.cpp SymbolEngine.cpp: In member function SymbolTableEntry* SymbolEngine::FindSymbol(const char*): SymbolEngine.cpp:351:55: error: stricmp was not declared in this scope if (_stricmp(pSymbol->m_data.name, pSymbolName) == 0) ^ SymbolEngine.cpp:364:55: error: stricmp was not declared in this scope if (_stricmp(pSymbol->m_data.name, pSymbolName) == 0) ^ SymbolEngine.cpp:377:55: error: stricmp was not declared in this scope if (_stricmp(pSymbol->m_data.name, pSymbolName) == 0) ^ make[1]: *** [SymbolEngine.o] Error 1 make[1]: Leaving directory `/home/bhenning/openspin-src/PropellerCompiler' make: *** [PropellerCompiler/libopenspin.a] Error 2 real 0m0.930s user 0m0.716s sys 0m0.145ssudo apt-get install subversion
sudo apt-get install g++
https://github.com/reltham/OpenSpin.wiki.git
svn checkout http://open-source-spin-compiler.googlecode.com/svn/ openspin-src
cd openspin-src
make all
sudo cp openspin /opt/parallax/bin
sudo chown bhenning.bhenning /opt/parallax/bin/openspin
Edit PropellerCompiler.h at the topso that _stricmp is defined properly for gcc supplied with Ubuntu 13.10
Then enjoy!
(thanks everyone)
Looks like you are still using svn to get code from google. That's not going to work, and not going to be updated. You need to use git to get the code from the repository on github.
If you get that version you should see this at the top of PropellerCompiler.h:
This should do the "right thing" on linux builds.
At command line openspin only accept the first define statement (-D) and ignores each other. The patch for fixing this:
--- OpenSpin.orig/SpinSource/openspin.cpp 2014-04-21 17:27:54.000000000 +0200 +++ OpenSpin/SpinSource/openspin.cpp 2014-04-21 17:31:22.000000000 +0200 @@ -716,7 +716,6 @@ CleanupMemory(); return 1; } - break; } } }For some of my projects, I need a higher value for the case_limit (256). Is there any reason why this is set to 64?
In build 70 I get an error if I use a reference to an object that is defined later in an "OBJ" block. Example: OpenSpin complains about unknown gc#HBEAT, if I put the OBJ block before the CON block, it works.
The reason is the new code in the preprocessor, if I comment out this the example above is working again:
--- OpenSpin.orig/SpinSource/preprocess.c 2014-04-21 17:27:54.000000000 +0200 +++ OpenSpin/SpinSource/preprocess.c 2014-04-21 17:34:43.000000000 +0200 @@ -864,8 +864,8 @@ pp_finish(struct preprocess *pp) { flexbuf_addchar(&pp->whole, 0); - pp_clear_define_state(pp); - flexbuf_delete(&pp->line); +// pp_clear_define_state(pp); +// flexbuf_delete(&pp->line); return flexbuf_get(&pp->whole); }Joerg
I found a compatibility issue in the FIT directive between OpenSpin and the Propeller Tool (and BST, for that matter).
In my code I am using a combination of the ORG and FIT directives to work as a kind of compile-time check of configuration constants, a trick that I saw someone else post some years ago (sorry, I don't remember who). It works like this:
' Any logical or comparison operation resulting in false in the FIT directive ' will result in a compile-time error. org 1 ' The CACHE_SIZE_BYTES must be a power of two. ' Error means CACHE_SIZE_BYTES is not a power of 2 fit (CACHE_SIZE_BYTES == |< ((>| CACHE_SIZE_BYTES)-1))This works fine using the Propeller Tool and BST, but does not work for OpenSpin, even if the value is really a power of two. (There is a fairly simple work-around: use the absolute value unary operator, ||, before the expression, to convert the -1 to a 1.)The following is a more complete program documenting and demonstrating the issue:
{{ fit_tests.spin -- Test the FIT directive operation between BST, OpenSpin and the Propeller Tool. (c) Copyright 2014 Thomas Dinger (Ding-Batty) TERMS OF USE: "MIT License" -- Full license is at the end of the file. Current Version: Sep 14, 2014 Change History is also at the end of the file. ===================================================================== Constants: Clock: }} CON _CLKMODE = XTAL1 + PLL16x _XINFREQ = 5_000_000 '===================================================================== PUB Main {{ Main test routine -- does nothing }} repeat ' Wait here forever. '===================================================================== DAT {{ Test the FIT command with various value arguments, and document the behavior of each of the three compilers. These are divided into two groups: - Those that work the same for all three compilers - Those that show behavioral variation. The test is against an "org 1" directive, so any positive number => 1 should be allowed by the compiler. The value 0 should generate an error. We test with a number of "interesting" values. Of the ones that are inconsistent, the one that is somewhat difficult is the "-1" case, because it comes in handy when using ORG+FIT as a compile-time configuration check, for example, to make sure a compile-time configuration setting is in an acceptable range. For example, I use code to make sure that a constant has a power-of-two value: org 1 ' The CACHE_SIZE_BYTES must be a power of two. ' Error means CACHE_SIZE_BYTES is not a power of 2 fit (CACHE_SIZE_BYTES == |< ((>| CACHE_SIZE_BYTES)-1)) This _can_ be worked around using the absolute value operator (||): fit ||(CACHE_SIZE_BYTES == |< ((>| CACHE_SIZE_BYTES)-1)) I was just surprised that this was needed. I suspect that both BST and the Propeller Tool treat the ORG-FIT comparison as an unsigned comparison, while (I know that) OpenSpin performs a signed comparison. Furthermore, the difference for $20000000 is because OpenSpin converts the COG addresses to "byte" offsets by left-shifting them by 2 bits, so all values in the $20000000..$3FFFFFFF range will become negative from that shift, thereby failing the signed comparison. }} org 1 ' Uncomment one of the FIT directives, below, to test it. ' The following all produce the same results in all three compilers. 'fit 0 ' BST: error ' PropTool: error ' OpenSpin: error 'fit 1 ' BST: OK ' PropTool: OK ' OpenSpin: OK 'fit $1FFFFFFF ' BST: OK ' PropTool: OK ' OpenSpin: OK 'fit $80000000 ' BST: error ' PropTool: error ' OpenSpin: error 'fit $80000001 ' BST: OK ' PropTool: OK ' OpenSpin: OK ' The following produce different results on the two compilers. fit -1 'fit $FFFFFFFF ' same as fit -1 ' BST: OK ' PropTool: OK ' OpenSpin: error 'fit $7FFFFFFF ' BST: OK ' PropTool: OK ' OpenSpin: error 'fit $20000000 ' BST: OK ' PropTool: OK ' OpenSpin: error {{ ========================================================================== Change History -------------- Sep 14, 2014: Initial release. (c) Copyright 2014 Thomas Dinger (Ding-Batty) TERMS OF USE: "MIT License" Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. }}Here is the above code, as a file: fit_tests.spin
I've added an issue to Roy's GitHub repository.
This covers Ding-Batty's issue, and one of joergd (the -D one).
For the other two things mentioned by joergd: The case limit one is not changing for now, and the other one I asked him for more info on the github issue, but he has not replied.
This is the now-offending line, and the file is in my Library folder.
#include "timing_5x16.spin"
What is the error it gives you, if any?
If no error, then can you send me the source files so I can debug it?
Are you sure you are compiling the exact same file when it fails in .71 and works in .70? I'm not able to get it to fail with Unable to open file or anything even remotely like that with version .71 of OpenSpin compileing a spin file that includes your file.
One thing I did notice is that your timing_5x16.spin file has no newline at the end, so when it gets included if there is an important thing on the line immediately after it, then that will cause a compile failure since that next line after the include is actually on the end of the last line in your include. I'm not sure if this is actually a bug or not. Should #include add an newline after what it includes or not? I kind of think not.
-Tor
This doesn't explain JonnyMac's problem though. This preprocessor stuff is identical between 1.00.70 and 1.00.71. He said it worked with 70, but not 71.
Jon, I still need more information/files from you. Please see my message above.
You there? Still need more info from you on this...
I just started trying to use openspin, and have a problem compiling, any objects in the top level spin file seem to be not found. I'm sure it's something stupid I'm doing but I can't spot it. This is an assembly debugger demo I found.
Any advice on where I'm going wrong?
Thanks.
Greg
The issue I believe you are having is the case of the filename not matching the case in the source code. The file is called PasDebug.spin, but the source code calls out PASDebug.spin.
This is an issue on linux or any OS that has case sensitive file systems. You'll need to either rename the file to be PASDebug.spin or change the source code to PasDebug.spin.
It's a problem that doesn't have a trivial solution in code. It's easier to just make sure the case matches for your files and where they are called out in the source code.
Roy
Greg
Both versions work when include file is in the same folder as the compiled code
The previous version of OpenSpin allows the included file to be in the Library (I renamed the file in the same folder to validate)
The new version of OpenSpin balks when the included file is in the Library -- seems only to be looking in the application folder.
In the Properties selection I highlighted the version of OpenSpin that works (renamed it before installing the newest version).
The include file is what I typically use as my timing header. I hoping to be able to include this in projects and time-oriented objects of that project as it defines ticks/millisecond and I use that a lot.
Thanks for the extra details. It's really odd that it works in the previous version, but not now. I haven't changed any of the code for file handling/searching at all between the versions. Hopefully I can replicate the problem with the new info and then debug it. Thanks.
Roy