mpark said...
Sapieha, try putting quotation marks (") around your filenames-with-spaces:
homespun018.exe /w /d "FullDuplexSerial Chip Gracey 4 in 1.spin" > "FullDuplexSerial Chip Gracey 4 in 1.list"
I don't think this problem is limited to Homespun. Allowing spaces in filenames is a terrible idea, imho.
I'm with Michael here. Spaces in filenames/dirnames cause all sorts of ambiguous issues when parsing paths.
On Non-Windows OS you can use a quote character '\' before the space, but the easy way to do it is put the file/path name in quotes like was suggested above.
bstc has exactly the same problem with spaces in names. It's not an easy problem to solve (particularly across platforms that use different path delimiters '\' '/')
Don't forget, Spin syntax does allow you to delimit blocks with braces. Might not do what you want though.
I was thinking if you took away the indent sensitivity and added begin / end blocks you would pretty much have a variant of pascal syntax.
I know hippy did some early work on a pascal compiler/runtime for the prop. I wonder how hard it would be do build a limited pascal parser (that is easy) that generated spin bytecode.
Strings are where this would likely fall down, but the rest of the pascal operators a pretty "spinish".
My thoughts were rather than keep "extending" or mangling spin to make it fit what people want (which just drifts further and further away from the Parallax reference) was to develop a new sytnax based from SPIN using a different block identifier. You would only need one. No need to differentiate between PUB and PRI. Personally I was drifting toward a BAS block that used some form of familiar BASIC syntax. The spin interpreter has all the primitives required to do goto/gosub, it would just be a matter of syntax.
I've not touched basic since my apple ][noparse][[/noparse] back in the mid 80's though, so it's something I'd need to look at closely. I did think of buying a basic stamp II to try and get familiar with, but then it's on the end of a long list [noparse]:)[/noparse]
I always indent my code in VB so that wasn't a problem for me. I thought the indent idea was great for beginners. However, I have been trapped by cutting and pasting or just commenting a line.
However, if you were going to remove the indentation requirement (and alternative option, not replacement), I would also suggest a slight syntax change to be more like VB or C. Take for example the "if then" construct and "endif". It makes sense to me to make it more like other languages rather than the subtle differences which are present now. I like Brad's suggestion of an alternative to PUB/PRI like BAS. I am not so sure on the "BAS" though I can't think of anything better.
Don't change the maths symbols such as <<, etc. This is part of spin. Then I think it would be easy to write a module to convert back and forth from one form to the other.
I agree that the indented block structuring is downright evil.
I am still laughing at that quote but it echos my thoughts exactly, indentation for code readability is fine and should be the paradigm, indentation for code function is another mater entirely.
As you guys are probably aware I am writing a development platform (glorified way of saying editor) for propeller development.
To leverage the best functionality for the development platform would require some changes to the spin syntax.
I would therefore propose a "enhanced" syntax for spin and as long as the compiler is backward compatible with the current spin syntax there should be no issue.
Lets call it SpinX though I am partial to the name Spasm (includes pasm) goes something like this:
Pub|Pri Sub(values etc) ' Subroutine where no value returned
'Local variables declared as:
Var X
Var Y := 0 'can be initialized with a value
End Sub
Pub|Pri Func(values etc) ' Function where value returned
'Local variables declared as:
Var X
Var Y := 0 'can be initialized with a value
RETURN whatever
End Sub
'Other blocks
If End If
Select End Select
Repeat End Repeat ' block repeat
Dat End Dat
Con End Con
Var End Var
Obj End Obj
A command line switch for the compiler would be sufficient to enable compiling for the new syntax.
I would like to add something akin to the object browser in VS to the development platform as well as intellesense and object context prompts. Anyone who has used VS will understand the convenience of these features.
I agree that the indented block structuring is downright evil.
I am still laughing at that quote but it echos my thoughts exactly, indentation for code readability is fine and should be the paradigm, indentation for code function is another mater entirely.
As you guys are probably aware I am writing a development platform (glorified way of saying editor) for propeller development.
To leverage the best functionality for the development platform would require some changes to the spin syntax.
I would therefore propose a "enhanced" syntax for spin and as long as the compiler is backward compatible with the current spin syntax there should be no issue.
My problem with this is if people start widely adopting the "enhanced" (read that as butchered) syntax, then the code becomes incompatible with the existing Spin Tools and Object exchange. You lose the ability to be able to just include existing spin objects (as they use the official format) and you have problems interchanging code with people who use other variants.
<snipped>
--
Brad (Member of the Popular Peoples Front of Judea! Splitters!!)
Praxis said...
@BradC: Be that as it may then please suggest how to do code folding without something to indicate the end of a block?
Also note that I was thinking about an import function for existing spin code.
Want to make a nice omelette you gotta break some eggs!
Ahh, you need to do a cursory parse of the code to get the block start and end points. Same for your syntax highlighting. You really need to be able to do a basic parse of the syntax to identify the relevant components. It's not hard, it just means more work on your part, however it completely removes the need to butcher the syntax to work around a limitation in the ide.
I guess it's either "Pain for one and gain for many" or "Gain for one and Pain for many".
You can do it. Parallax did with their syntax highlighter and Ctrl-I block intent indicator.
Of course doing highlights and block folding with C is easy, there are already many, many highlighters available...
If Chip didn't want to do the design his own way, we wouldn't have ended up with a great Propeller Chip.
Years ago a friend of mine re-wrote an assembler for the mini we programmed. It added all kinds of additional features that he wanted and had been asking the manufacturer for for years. The manufacturer's version was free and his cost a few thousand $ per licence. Within a couple of years, the manufacturer was using his assembler (world-wide) for all their own development software.
So, make the improvements to spin. Please keep backward compatability. We will then have the best of both worlds.
For Select / End Select may I suggest you allow Case / End Case as well. I always hated Select as I thought Case was more readable.
So just go for it and thanks for giving us an alternative.
BradC said...
I know hippy did some early work on a pascal compiler/runtime for the prop. I wonder how hard it would be do build a limited pascal parser (that is easy) that generated spin bytecode.
Should be possible but I've moved away from a pure Pascal compiler. Mostly the differences in languages are purely decorative, different words, slightly different order of things, but they are all easily translatable to Spin. My vision now is a unified compiler which would take Spin, C, Pascal, and Basic source inter-mixed. The trigger is what the opening word was for the method; "PUB"/"PRI", "PROCEDURE"/"FUNCTION", "SUB"/"DEF", or a type definition for C then parse that entire method using the applicable syntax.
To make it easy to implement the programmer is forced to use the types Spin uses so parameters and locals have to be type "int" etc or they get an error. It is possible to allow word and byte by masking and extending where variables are used but not absolutely necessary.
It wouldn't be true C, Pascal or Basic, but Spin in that language's clothing. That seems to be what people are really after or would accept.
As to compatibility ...
I think that's something we just have to accept as impossible to achieve. As soon as something is added and used by a programmer which PropTool doesn't support compatibility is broken. The extent of compatibility should be to using existing code without needing change to work. If someone wants to use code which requires a third party compiler with the PropTool then that's unfortunate, it may not be possible.
Not a perfect situation but the best there is. If PropTool did all that was necessary there would be little incentive to create alternatives. Except to duplicate it as open source on a point of principle, there would be no reason to go beyond replicating functionality.
If PropTool were open source in some manner then I expect effort would have gone into improving PropTool to do what was required. As it isn't, the only alternative is parallel development and divergence from PropTool functionality.
I'd go as far as saying third party tools shouldn't hold themselves back to remain PropTool compatible but that PropTool ( by which I mainly mean the compiler ) needs to pull itself forward to achieve what third party tools can offer and be compatible with them. I appreciate that Parallax don't have the resources individuals can throw at tool development, so they have to make the decision; provide those resources to stop Spin development tool fragmentation, open the tool up so third parties can develop PropTool itself rather than competing tools, or accept the fragmentation.
There are ways to open up PropTool without going fully Open Source or losing copyright or control and I'd like to see that happen. Done right they will get free resources from developers who end up contributing ( to the benefit of everyone ) rather than seeing the fragmentation as now which does give rise to legitimate concerns over compatibility. Not just with PropTool but between third party tools.
The genie is out the bottle and without a single direction of focus ( which PropTool itself could provide as the de-facto tool ) people will go in whatever direction they want to and fragmentation will get worse. If that's the situation we just have to accept it.
Version 0.19 in first post.
My attempt to add multidimensional arrays to Spin. Only works with VARs. Syntax is C-style:
con
_clkmode = xtal1+pll16x
_xinfreq = 6_000_000
obj
text : "tv_text"
var
long array[noparse][[/noparse]10][noparse][[/noparse]10] ' 10 x 10 matrix
pub main | i, j, k
text.start(24)
k := 0
repeat i from 0 to 9 ' initialize array
repeat j from 0 to 9
array[noparse][[/noparse]i][noparse][[/noparse]j] := k++
repeat i from 0 to 9 ' print array
repeat j from 0 to 9
text.dec( array[noparse][[/noparse]i][noparse][[/noparse]j] )
text.out( " " )
text.out( 13 ) ' CR
No limit on number of dimensions. No bounds-checking.
I added this for myself (I'm thinking of writing a program where this might come in handy), but I wonder, does anyone else find this useful? ·
There's a potential for confusion between the way arrays are used here ( myArray[noparse]/noparse[noparse]/noparse ) and the way the current indexing works and with long[noparse]/noparse[noparse]/noparse etc, and particularly if passing a pointer to a multi-dimensioned array into a method.
If your compiler accepts non-SPIN input, at least give an option to generate exact-SPIN *output*.
This way, if people want to program in SpinX or Pascal or BASIC or whatnot, they would still
be able to generate PropTool-compatible Spin programs.
Excellent work mpark. I haven't tried your compiler yet, but I just know it's going to be something I make a lot of use of in the future, so well done.
BTW: Any idea if this is going to fit with Praxis' IDE?
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
I've been trying homespun under mono and the MacOS and have run into problems with the command line scanning. The MacOS provides for conversion of file names into POSIX format with quotes around them and these use "/" for subdirectory delimiters. Homespun chokes on them thinking they're some kind of unknown option. Specifically, the command line is:
Mike Green said...
I've been trying homespun under mono and the MacOS and have run into problems with the command line scanning. The MacOS provides for conversion of file names into POSIX format with quotes around them and these use "/" for subdirectory delimiters. Homespun chokes on them thinking they're some kind of unknown option. Specifically, the command line is:
Couple of things.
At the moment, Homespun expects the -L to be followed *immediately* by the directory (no intervening spaces). Also, each directory needs its own -L.
What this means for quoted directories, I don't know. Do you have to include the -L inside the quotes? Beats me. I will change the -L so that it no longer expects to be conjoined with the directory, but for now you'll have to experiment.
The other thing is that Homespun expects - and / to preface options. Of course if your source file starts with / then it gets confused, but who the heck uses / in paths? (Note to self: non-Windows people, you dum-dum.)
I guess the easiest thing to do is to take out the slash options, except I like using slash <pout>. I guess I could treat any unrecognized option as a filename. Nah, I'll take out slash.
Hi mpark.
I am XP user but if You use \ and / as path options .
Use - as Directive options.
That give both worlds XP, OSX and Linux posiblites tu take correct path
Ps. It is not problem for XP environment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
1. Is the .out appended to the filename on the compile code required, if not can it be dropped?
2. Will you be providing a compile to binary output?
3. Can you have a switch to suppress the parsing & compiling messages i.e.
-ix or /ix where x = 1 show parse, 2 show compile and 3 show all.
All errors and warnings (with /w) display as normal.
4. Can you have an (optional) destination (and or filename) for the compiled output?
Hi Praxis!
I think single quotes are possible, but why? Where are you going with this?
I can certainly drop the .out; it was just there so I could tell Homespun output from Proptool output.
I could make .binary files (now that I know what they are, from another thread).
I can add a -ix switch, but I think I'll eliminate the "compiling blah" messages altogether; they don't really add any information. Why do you suggest "i" for this switch?
The single quote for the listing file comments is so that when I pull the listing file into the IDE I can colorize it.
As for "i" short for information.
Keep the compiling messages as I can optional pull them into the IDE, its an nice check that all the modules compiled and provides feedback that compiling is functioning OK, its the parsing messages that are not really required but can be retained with a switch option for debug etc.
Just a thought for standardization:
A warning message is in the format - Warning: MATHFLOAT32A.spin (91, 29): ORG without address (defaults to 0)
Whereas an error message (parser) is - CompilerTest.spin (15, 8): Unexpected LONG1
Can we get the error message in this format - Error: CompilerTest.spin (15, 8): Unexpected LONG1
In the IDE these messages will be displayed back to the user and a double click on the displayed message will open (if already not) the code document and show the error.
I have one quwstion if You can have alternate listing In Pasm section.
Example....
0ba4: 00 00 00 00
0ba4: EE1|FF1|1110|1111|02 It is more reliable in debuging to fould code and what is doing on Registers in COG < .............. (000011 000i 1111 ddddddddd sssssssss)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
If you decide to allow an alternate pasm listing as Sapieha has suggested, put in on the line as well, but in correct order
Example:
0BA4: 00 00 00 00 >1FF 1F 1FF 1FF .........
0BA4: 00 00 00 00 >1FF 1F 1FF #1FF ......... (# for immediate would be even better)
For me is is not marter with order is native else goes backwards.
My idea was to fllow after bytes in COG list.
It gives easy comparation with Instructions in Propeller Manual.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Experimental new feature: object sharing. Suppose you have an object, top, that has a child object, middle, that in turn has a child, bottom. Suppose in addition that each object will be using float32, floatString,·and tv_text. Now check this out:
' top.spin
con
_clkmode = xtal1+pll16x
_xinfreq = 6_000_000
obj
middle : "middle"
text : "tv_text" pointer
f : "float32" pointer
fp : "floatString" pointer
pub Main
middle.Start
text := middle.PointerToTvText
f := middle.PointerToFloat32
fp := middle.PointerToFloatString
text.str( string( "top says sqrt(33) = " ) )
text.str( fp.FloatToString( f.FSqr( 33.0 ) ) )
text.out( 13 )
Note that only middle has an actual tv_text object. It passes a "pointer to tv_text"·up to top and down to bottom. In other words, top, middle, and bottom are all using one "instance" of tv_text (and the same for float32 and floatString).
I haven't tested this extensively, but the above program does work.
Note that this runs into trouble if, for example, middle contains an array of bottom objects. middle can share its tv_text etc with only one bottom at a time. That is, if middle calls bottom[noparse][[/noparse]0].Start(text, f, fp), only bottom[noparse][[/noparse]0] can use the tv_text object. bottom[noparse][[/noparse]1] and bottom[noparse][[/noparse]2] are out of luck. Ten points if you can figure out why. A thousand points if you can figure out a way around it.
Comments
I'm with Michael here. Spaces in filenames/dirnames cause all sorts of ambiguous issues when parsing paths.
On Non-Windows OS you can use a quote character '\' before the space, but the easy way to do it is put the file/path name in quotes like was suggested above.
bstc has exactly the same problem with spaces in names. It's not an easy problem to solve (particularly across platforms that use different path delimiters '\' '/')
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I was thinking if you took away the indent sensitivity and added begin / end blocks you would pretty much have a variant of pascal syntax.
I know hippy did some early work on a pascal compiler/runtime for the prop. I wonder how hard it would be do build a limited pascal parser (that is easy) that generated spin bytecode.
Strings are where this would likely fall down, but the rest of the pascal operators a pretty "spinish".
My thoughts were rather than keep "extending" or mangling spin to make it fit what people want (which just drifts further and further away from the Parallax reference) was to develop a new sytnax based from SPIN using a different block identifier. You would only need one. No need to differentiate between PUB and PRI. Personally I was drifting toward a BAS block that used some form of familiar BASIC syntax. The spin interpreter has all the primitives required to do goto/gosub, it would just be a matter of syntax.
I've not touched basic since my apple ][noparse][[/noparse] back in the mid 80's though, so it's something I'd need to look at closely. I did think of buying a basic stamp II to try and get familiar with, but then it's on the end of a long list [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I always indent my code in VB so that wasn't a problem for me. I thought the indent idea was great for beginners. However, I have been trapped by cutting and pasting or just commenting a line.
However, if you were going to remove the indentation requirement (and alternative option, not replacement), I would also suggest a slight syntax change to be more like VB or C. Take for example the "if then" construct and "endif". It makes sense to me to make it more like other languages rather than the subtle differences which are present now. I like Brad's suggestion of an alternative to PUB/PRI like BAS. I am not so sure on the "BAS" though I can't think of anything better.
Don't change the maths symbols such as <<, etc. This is part of spin. Then I think it would be easy to write a module to convert back and forth from one form to the other.
I am still laughing at that quote but it echos my thoughts exactly, indentation for code readability is fine and should be the paradigm, indentation for code function is another mater entirely.
As you guys are probably aware I am writing a development platform (glorified way of saying editor) for propeller development.
To leverage the best functionality for the development platform would require some changes to the spin syntax.
I would therefore propose a "enhanced" syntax for spin and as long as the compiler is backward compatible with the current spin syntax there should be no issue.
Lets call it SpinX though I am partial to the name Spasm (includes pasm) goes something like this:
A command line switch for the compiler would be sufficient to enable compiling for the new syntax.
I would like to add something akin to the object browser in VS to the development platform as well as intellesense and object context prompts. Anyone who has used VS will understand the convenience of these features.
Any thoughts on = versus := ??
Cheers
Post Edited (Praxis) : 10/4/2008 10:21:35 AM GMT
My problem with this is if people start widely adopting the "enhanced" (read that as butchered) syntax, then the code becomes incompatible with the existing Spin Tools and Object exchange. You lose the ability to be able to just include existing spin objects (as they use the official format) and you have problems interchanging code with people who use other variants.
<snipped>
--
Brad (Member of the Popular Peoples Front of Judea! Splitters!!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (BradC) : 10/4/2008 10:58:49 AM GMT
Also note that I was thinking about an import function for existing spin code.
Want to make a nice omelette you gotta break some eggs!
Post Edited (Praxis) : 10/4/2008 11:07:52 AM GMT
Ahh, you need to do a cursory parse of the code to get the block start and end points. Same for your syntax highlighting. You really need to be able to do a basic parse of the syntax to identify the relevant components. It's not hard, it just means more work on your part, however it completely removes the need to butcher the syntax to work around a limitation in the ide.
I guess it's either "Pain for one and gain for many" or "Gain for one and Pain for many".
You can do it. Parallax did with their syntax highlighter and Ctrl-I block intent indicator.
Of course doing highlights and block folding with C is easy, there are already many, many highlighters available...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Years ago a friend of mine re-wrote an assembler for the mini we programmed. It added all kinds of additional features that he wanted and had been asking the manufacturer for for years. The manufacturer's version was free and his cost a few thousand $ per licence. Within a couple of years, the manufacturer was using his assembler (world-wide) for all their own development software.
So, make the improvements to spin. Please keep backward compatability. We will then have the best of both worlds.
For Select / End Select may I suggest you allow Case / End Case as well. I always hated Select as I thought Case was more readable.
So just go for it and thanks for giving us an alternative.
Should be possible but I've moved away from a pure Pascal compiler. Mostly the differences in languages are purely decorative, different words, slightly different order of things, but they are all easily translatable to Spin. My vision now is a unified compiler which would take Spin, C, Pascal, and Basic source inter-mixed. The trigger is what the opening word was for the method; "PUB"/"PRI", "PROCEDURE"/"FUNCTION", "SUB"/"DEF", or a type definition for C then parse that entire method using the applicable syntax.
To make it easy to implement the programmer is forced to use the types Spin uses so parameters and locals have to be type "int" etc or they get an error. It is possible to allow word and byte by masking and extending where variables are used but not absolutely necessary.
It wouldn't be true C, Pascal or Basic, but Spin in that language's clothing. That seems to be what people are really after or would accept.
As to compatibility ...
I think that's something we just have to accept as impossible to achieve. As soon as something is added and used by a programmer which PropTool doesn't support compatibility is broken. The extent of compatibility should be to using existing code without needing change to work. If someone wants to use code which requires a third party compiler with the PropTool then that's unfortunate, it may not be possible.
Not a perfect situation but the best there is. If PropTool did all that was necessary there would be little incentive to create alternatives. Except to duplicate it as open source on a point of principle, there would be no reason to go beyond replicating functionality.
If PropTool were open source in some manner then I expect effort would have gone into improving PropTool to do what was required. As it isn't, the only alternative is parallel development and divergence from PropTool functionality.
I'd go as far as saying third party tools shouldn't hold themselves back to remain PropTool compatible but that PropTool ( by which I mainly mean the compiler ) needs to pull itself forward to achieve what third party tools can offer and be compatible with them. I appreciate that Parallax don't have the resources individuals can throw at tool development, so they have to make the decision; provide those resources to stop Spin development tool fragmentation, open the tool up so third parties can develop PropTool itself rather than competing tools, or accept the fragmentation.
There are ways to open up PropTool without going fully Open Source or losing copyright or control and I'd like to see that happen. Done right they will get free resources from developers who end up contributing ( to the benefit of everyone ) rather than seeing the fragmentation as now which does give rise to legitimate concerns over compatibility. Not just with PropTool but between third party tools.
The genie is out the bottle and without a single direction of focus ( which PropTool itself could provide as the de-facto tool ) people will go in whatever direction they want to and fragmentation will get worse. If that's the situation we just have to accept it.
This do not alter the spin syntax and mantain compatibility with PropTool
regards
Dario
Post Edited (dMajo) : 10/4/2008 1:31:10 PM GMT
My attempt to add multidimensional arrays to Spin. Only works with VARs. Syntax is C-style:
con _clkmode = xtal1+pll16x _xinfreq = 6_000_000 obj text : "tv_text" var long array[noparse][[/noparse]10][noparse][[/noparse]10] ' 10 x 10 matrix pub main | i, j, k text.start(24) k := 0 repeat i from 0 to 9 ' initialize array repeat j from 0 to 9 array[noparse][[/noparse]i][noparse][[/noparse]j] := k++ repeat i from 0 to 9 ' print array repeat j from 0 to 9 text.dec( array[noparse][[/noparse]i][noparse][[/noparse]j] ) text.out( " " ) text.out( 13 ) ' CRNo limit on number of dimensions. No bounds-checking.
I added this for myself (I'm thinking of writing a program where this might come in handy), but I wonder, does anyone else find this useful?
·
It may be better to use comma separated indexing.
This way, if people want to program in SpinX or Pascal or BASIC or whatnot, they would still
be able to generate PropTool-compatible Spin programs.
Anyhoo, I've updated the first post with version 0.20: array syntax is now a[noparse][[/noparse]i,j,k].
Heya! That's a really neat implementation. I like the way you did that.
Now I gotta think about "Keeping up with the Joneses" .. so much to do, so little time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
BTW: Any idea if this is going to fit with Praxis' IDE?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
mono /Applications/MonoApps/homespun.exe -L '/Applications/MonoApps/PropLib/' '/Users/mgreen/Desktop/PodiumPiece/PodiumTest.spin'
The error message I get is:
Unknown option: /Applications/MonoApps/PropLib/
Unknown option: /Users/mgreen/Desktop/PodiumPiece/PodiumTest.spin
No input file specified
I could convert the "/" to "\", but the use of "/" is a standard (POSIX) and it would be nice to be able to accomodate it.
I'm not sure about the implementation on OSX, but on Linux I could not get it to compile anything that was not in the immediate directory.
brad@bklaptop2:~$ mono homespun018.exe /tracks/Objects/FemtoBasic_2008-02-28/FemtoBasic/FemtoBasic.spin
Homespun Spin Compiler 0.18
Unknown option: /tracks/Objects/FemtoBasic_2008-02-28/FemtoBasic/FemtoBasic.spin
No input file specified
brad@bklaptop2:/tracks/Objects/FemtoBasic_2008-02-28/FemtoBasic$ mono ~/homespun018.exe FemtoBasic.spin Homespun Spin Compiler 0.18
parsing FemtoBasic.spin
parsing fsrwFemto.spin
parsing sdspiFemto.spin
parsing vga_Drive.spin
parsing comboKeyboard.spin
The other issue I have is with the libraries and a case sensitive filesystem, but I don't think that is an issue on OSX.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
At the moment, Homespun expects the -L to be followed *immediately* by the directory (no intervening spaces). Also, each directory needs its own -L.
What this means for quoted directories, I don't know. Do you have to include the -L inside the quotes? Beats me. I will change the -L so that it no longer expects to be conjoined with the directory, but for now you'll have to experiment.
The other thing is that Homespun expects - and / to preface options. Of course if your source file starts with / then it gets confused, but who the heck uses / in paths? (Note to self: non-Windows people, you dum-dum.)
I guess the easiest thing to do is to take out the slash options, except I like using slash <pout>. I guess I could treat any unrecognized option as a filename. Nah, I'll take out slash.
Oh, and Simon, you'd have to ask Praxis.
I am XP user but if You use \ and / as path options .
Use - as Directive options.
That give both worlds XP, OSX and Linux posiblites tu take correct path
Ps. It is not problem for XP environment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
1. Is the .out appended to the filename on the compile code required, if not can it be dropped?
2. Will you be providing a compile to binary output?
3. Can you have a switch to suppress the parsing & compiling messages i.e.
-ix or /ix where x = 1 show parse, 2 show compile and 3 show all.
All errors and warnings (with /w) display as normal.
4. Can you have an (optional) destination (and or filename) for the compiled output?
Post Edited (Praxis) : 10/10/2008 10:16:25 AM GMT
I think single quotes are possible, but why? Where are you going with this?
I can certainly drop the .out; it was just there so I could tell Homespun output from Proptool output.
I could make .binary files (now that I know what they are, from another thread).
I can add a -ix switch, but I think I'll eliminate the "compiling blah" messages altogether; they don't really add any information. Why do you suggest "i" for this switch?
As for "i" short for information.
Keep the compiling messages as I can optional pull them into the IDE, its an nice check that all the modules compiled and provides feedback that compiling is functioning OK, its the parsing messages that are not really required but can be retained with a switch option for debug etc.
Just a thought for standardization:
A warning message is in the format - Warning: MATHFLOAT32A.spin (91, 29): ORG without address (defaults to 0)
Whereas an error message (parser) is - CompilerTest.spin (15, 8): Unexpected LONG1
Can we get the error message in this format - Error: CompilerTest.spin (15, 8): Unexpected LONG1
In the IDE these messages will be displayed back to the user and a double click on the displayed message will open (if already not) the code document and show the error.
Cheers
Post Edited (Praxis) : 10/10/2008 11:52:22 AM GMT
Thanks
I have one quwstion if You can have alternate listing In Pasm section.
Example....
0ba4: 00 00 00 00
0ba4: EE1|FF1|1110|1111|02 It is more reliable in debuging to fould code and what is doing on Registers in COG < .............. (000011 000i 1111 ddddddddd sssssssss)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Example:
0BA4: 00 00 00 00 >1FF 1F 1FF 1FF .........
0BA4: 00 00 00 00 >1FF 1F 1FF #1FF ......... (# for immediate would be even better)
format 1FF = opcode, 1F = Immediate+cond, 1FF = Dest, 1FF = Source
It's a partway towards disassembly.
For me is is not marter with order is native else goes backwards.
My idea was to fllow after bytes in COG list.
It gives easy comparation with Instructions in Propeller Manual.
Example....
0ba4: 11 22 33 44
.......................flags as bits
0ba4: 1AA|1BB|1110|1111|1C
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 10/11/2008 5:55:55 AM GMT
Experimental new feature: object sharing. Suppose you have an object, top, that has a child object, middle, that in turn has a child, bottom. Suppose in addition that each object will be using float32, floatString,·and tv_text. Now check this out:
Note that only middle has an actual tv_text object. It passes a "pointer to tv_text"·up to top and down to bottom. In other words, top, middle, and bottom are all using one "instance" of tv_text (and the same for float32 and floatString).
I haven't tested this extensively, but the above program does work.
Note that this runs into trouble if, for example, middle contains an array of bottom objects. middle can share its tv_text etc with only one bottom at a time. That is, if middle calls bottom[noparse][[/noparse]0].Start(text, f, fp), only bottom[noparse][[/noparse]0] can use the tv_text object. bottom[noparse][[/noparse]1] and bottom[noparse][[/noparse]2] are out of luck. Ten points if you can figure out why. A thousand points if you can figure out a way around it.