So I think you guys are gonna like this one. I've checked in the new string functionality. Thanks, @Cluso99 for suggesting ASCII0_STREngine.spin as the foundation for a string library!
char.type - string char functions ( isUpper, isLower, etc.)
string - core string operations (like copy, append, etc.)
string.type - string type tests (like isUpper, isLower, etc.)
string.float - convert between floating point numbers and strings
string.integer - convert between integer numbers and strings
So I think you guys are gonna like this one. I've checked in the new string functionality. Thanks, @Cluso99 for suggesting ASCII0_STREngine.spin as the foundation for a string library!
char.type - string char functions ( isUpper, isLower, etc.)
string - core string operations (like copy, append, etc.)
string.type - string type tests (like isUpper, isLower, etc.)
string.float - convert between floating point numbers and strings
string.integer - convert between integer numbers and strings
One suggestion: the "IsSpace" method makes me wonder if it checks for a single space, multiple spaces or any amount of whitespace (tabs, newlines, etc). If it only checks for a single character, it might be helpful to add another method for checking if a string is empty or contains only whitespace.
One suggestion: the "IsSpace" method makes me wonder if it checks for a single space, multiple spaces or any amount of whitespace (tabs, newlines, etc). If it only checks for a single character, it might be helpful to add another method for checking if a string is empty or contains only whitespace.
So there are two separate type objects; one for chars and one for strings.
Calling char.type.IsSpace would tell you if a single character is whitespace.
Calling string.type.IsSpace would tell you if an entire string consists only of whitespace.
Any plans to make the root directory a category only? there is going to be a lot here eventually, might be less cluttered.
The problem here is that Spin has never allowed subdirectories. I have a proposal that I've been working on to incorporate this feature in a way that's backwards-compatible with existing Spin products, but since I am working around it anyway, it is low on my priority list.
One suggestion: the "IsSpace" method makes me wonder if it checks for a single space, multiple spaces or any amount of whitespace (tabs, newlines, etc). If it only checks for a single character, it might be helpful to add another method for checking if a string is empty or contains only whitespace.
So there are two separate type objects; one for chars and one for strings.
Calling char.type.IsSpace would tell you if a single character is whitespace.
Calling string.type.IsSpace would tell you if an entire string consists only of whitespace.
Makes sense. I'd just rename them to IsWhitespace then, since "Space" is a bit ambiguous.
The problem here is that Spin has never allowed subdirectories. I have a proposal that I've been working on to incorporate this feature in a way that's backwards-compatible with existing Spin products, but since I am working around it anyway, it is low on my priority list.
Don't mind me, I control my world from a smart phone. I do have a question, I loose all formatting when I copy and paste code, and that is a pain, not sure there is any way around that, except to use a PC.
I've been lurking this thread, but haven't had much time recently to step outside my cave. There was mention of the Gold Standard on page #1. It seems to be hard to find online, not on the Parallax site anyway. No-one had provided a link, but I just ran across a copy on a disk here, find attached.
I found many of the suggestions quite reasonable for the sake of consistency and have been trying to follow them. So what if it flopped as an initiative. I'm not sure why, but I always feel there is yet another half-way step before any object qualifies as gold. That is to say, always tinkering.
Brett, good luck with this initiative, the whole library, not merely individual objects.
One suggestion the "IsSp" method makes me wonder if it checks forefersingle space, multiple spaces or any amount of whitespace (tabs, newlines, etc). If it only checks for a single character, it might be helpful to add another method for checking if a string is empty or contains only whitespace.
So there are two separate type objects; one for chars and one for strings.
Calling char.type.IsSpace would tell you if a single character is whitespace.
Calling string.type.IsSpace would tell you if an entire string consists only of whitespace.
Makes sense. I'd just rename them to IsWhitespace then, since "Space" is a bit ambiguous.
Ahh, I'll leave it as is. A lot of languages have standard libraries with a similarly named function. It's not really ambiguous when you consider how trivial a function that detects an actual "space" character is.
return (x == " ")
I suspect that if someone actually needed IsSpace(), they would be doing text processing and already know what they're looking for.
The problem here is that Spin has never allowed subdirectories. I have a proposal that I've been working on to incorporate this feature in a way that's backwards-compatible with existing Spin products, but since I am working around it anyway, it is low on my priority list.
Don't mind me, I control my world from a smart phone. I do have a question, I loose all formatting when I copy and paste code, and that is a pain, not sure there is any way around that, except to use a PC.
Thanks,
_mike
Hi there. I'm not sure if this is in response to what I said or not, because it sounds like a general forum question. Anyway that's what the code tags are for (added a space so it'd show up).
I've been lurking this thread, but haven't had much time recently to step outside my cave. There was mention of the Gold Standard on page #1. It seems to be hard to find online, not on the Parallax site anyway. No-one had provided a link, but I just ran across a copy on a disk here, find attached.
I found many of the suggestions quite reasonable for the sake of consistency and have been trying to follow them. So what if it flopped as an initiative. I'm not sure why, but I always feel there is yet another half-way step before any object qualifies as gold. That is to say, always tinkering.
Brett, good luck with this initiative, the whole library, not merely individual objects.
Haha, yes, of course, there is always room for improvement and more things to add. But as @potatohead mentioned earlier in this topic, the main goal here is the basics. Having a solid foundation of core objects that is widely applicable to other projects makes all Propeller programmers more productive. In doing this, we can enable developers to knock out a new application quickly instead of floundering in low-level details.
Because who among us hasn't felt that frustration when you just can't find the library you need when you need it? And who among us hasn't been pleasantly surprised to find that a function you need is actually built-in to the language? That's a good feeling, and one I'd like to recreate with Spin.
Sorry Brett, my problem is just an Android problem, the github site is fantastic, and everday your work is making it better, don't know what I will use next for a descriptive. Below is what I am dealing with, there must be an app for that.
DON'T USE.SPIN
{
Filename: Author: Copyright (c) 2015 See end of file for terms of use.
}CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000VAROBJPUBPRIDAT{
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.
}
Sorry Brett, my problem is just an Android problem, the github site is fantastic, and everday your work is making it better, don't know what I will use next for a descriptive. Below is what I am dealing with, there must be an app for that.
DON'T USE.SPIN
{
Filename: Author: Copyright (c) 2015 See end of file for terms of use.
}CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000VAROBJPUBPRIDAT{
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.
}
Thanks! =P
Ahhh! I see what's going on. This is one of a few issues that comes from making Spin cross-platform. Every operating system handles line endings differently, and every text editor handles them differently too. Some text editors automatically convert line endings but others don't.
Most of Spin's lifetime has seen most Spin files being saved in UTF-16 little-endian with Windows line endings, because PropTool was written at a time when that was more common. PropellerIDE, on the other hand currently converts all files to UTF-8 with UNIX line endings for consistency, which is fine for the most part, but this will for example, make Windows Notepad not like it, while Wordpad will read it without a problem.
Unfortunately, this problem is much bigger than PropellerIDE and there isn't much I can do. There are trade-offs in every solution. My recommendation is to try opening it on a computer, or wait until PropellerIDE has Android support (planned, but you could be waiting awhile). =P
I got a good idea of what you were talking about, the technical is over my head, I usually avoided spin files in OBEX for that reason, I know I'm in a very small minority that doesn't have home internet, and if I wanted dish satellite again, I could solve it.
For now I'll struggle along downloading compressed archive's, or spin's I really want that have to gone over, or take one of my laptops to McD's, guess what's for breakfast.
So @Cluso99, I've been thinking about this "rendezvous point" thing some more, and I think if the location wasn't hard-coded and was something rendered at compile-time, I wouldn't have a problem including it. Can you tell me more about how it would work?
Brett,
Just a little busy currently, so this is short.
You predefine a few longs in hub. Usually fixed, but doesn't have to be.
In the main program you include two stub objects, stdout and stdin. Your program always outputs to the stdout, and always inputs from the stdin.
Before using these though, you start (load) up cog(s) with the actual driver object, passing it the rendezvous location(s) in PAR. In the pcsio object, this is done simply by calling the pcsio.start(inRendezvous, outRendezvous, serPins, baud) pcsio is a modified serial object similar to FullDuplexSerial.
If you are using separate drivers such as keyboard and tv, your main program just calls kbd.start(inRendezvous, pins+etc) and also tv.start(outRedezvous, pins+etc). This starts 2 cogs, one for kbd and one for tv.
Stdin & Stdout only support the very basic char routine and test to see if there is a char available. Any higher level calls should preferably be done via a string/hex/decimal object to convert to the char out.
The Stdin & Stdout routines each use one long rendezvous location in hub. $0 signifies empty ($100 is used for char $0), and asingle char is passed in the rendezvous long. ie we really only use 9 bits, but it allows for future expansion if required.
Here is the stdout routine
VAR
long pRENDEZVOUS
PUB start(rendezvous)
pRENDEZVOUS := rendezvous 'get rendezvous location
PUB out(c)
'' Print a character
c |= $100 '0.FF -> 100..1FF 'add bit9=1 (allows $00 to be passed)
repeat while long[pRENDEZVOUS] 'wait for mailbox to be empty (=$0)
long[pRENDEZVOUS] := c 'place in mailbox for driver to act on
And here is the stdin routine
VAR
long pRENDEZVOUS 'stores a pointer to the hub mailbox
PUB start(rendezvous)
pRENDEZVOUS := rendezvous 'get rendezvous location
PUB in : c
'' Wait for an input character
repeat until c := long[pRendezvous] 'wait until the mailbox has a character
long[pRendezvous]~ 'clear the mailbox
c &= $FF '$100 -> $00 'extract lower 8 bits (byte)
PUB peek
'' Returns a 0 if the buffer is empty,
'' else next character (+$100) but doesn't remove from the buffer.
'' The user routine must extract the 8 bits as the whole long is passed.
return long[pRendezvous] 'return ALL bits (long) in the mailbox
This is the start of the pcsio driver
CON
RX1FIFO_SIZE = 160 '640 bytes
TX1FIFO_SIZE = 160 '640 bytes
VAR
long cog 'cog flag/id
long params[4] 'for passing parameters
PUB start(inRENDEZVOUS, outRENDEZVOUS, serPins, baud)
'' Start Serial driver - starts a cog if necessary
'' returns cog+1 if it had to start a cog, false if cog was already running.
'' serPins = rxPin << 8 | txPin
'' baud = baud
''
long[outRENDEZVOUS] := 4 'Ping Ser Driver
waitcnt(clkfreq>>2+cnt)
if long[outRENDEZVOUS] == 0
return False 'is alive
'else start driver
long[inRENDEZVOUS] := 0 'clear the rendezvous locations
long[outRENDEZVOUS] := ">"
params[0] := inRENDEZVOUS 'pass the parameters
params[1] := outRENDEZVOUS
params[2] := serPins
params[3] := clkfreq / baud
cog := cognew(@entry, @params) + 1 'Start the cog
repeat while long[outRENDEZVOUS] 'wait until cleared (ok to go)
return cog 'cog+1 (=0=false if failed)
DAT
ORG 0
'
' Initialisation.
'
entry mov t1,par 'get the address of the parameter list
rdlong rx1ptr,t1 'inRENDEZVOUS
add t1,#4
rdlong tx1ptr,t1 'outRENDEZVOUS
add t1,#4
rdlong t2,t1 'serPins
test t2,#$80 wz 'if $FF, disable tx
@Cluso99, wow, that's actually not too bad. I think I'll do some experimenting today to see how this could fit into what's there.
It's becoming more important to have this as I've been implementing some more complex terminal interfaces that would be impractical to make them work for different outputs and still be drop-in solutions. This could solve a lot of problems.
@Cluso99, wow, that's actually not too bad. I think I'll do some experimenting today to see how this could fit into what's there.
It's becoming more important to have this as I've been implementing some more complex terminal interfaces that would be impractical to make them work for different outputs and still be drop-in solutions. This could solve a lot of problems.
string tokenize for me is to find a token and replace that with zero, so when you forward this string-pointer it will be this shorter zero-terminated string.
It's destructive, but as all strings are in sram on a Prop it will always work and you could always put the token back if needed.
strtok() (that is what it's called in C string library) is great for parsing.
So it should be: PUB Tokenize(str,str) http://www.tutorialspoint.com/c_standard_library/c_function_strtok.htm
string tokenize for me is to find a token and replace that with zero, so when you forward this string-pointer it will be this shorter zero-terminated string.
It's destructive, but as all strings are in sram on a Prop it will always work and you could always put the token back if needed.
strtok() (that is what it's called in C string library) is great for parsing.
So it should be: PUB Tokenize(str,str) http://www.tutorialspoint.com/c_standard_library/c_function_strtok.htm
Ahh, good point. I had kept it spaces only because I wasn't sure how to go about implementing one that supports full tokens, but now that you mention it, it deserves a second look. I'll see what I can do about that when I get back to it later.
string tokenize for me is to find a token and replace that with zero, so when you forward this string-pointer it will be this shorter zero-terminated string.
It's destructive, but as all strings are in sram on a Prop it will always work and you could always put the token back if needed.
strtok() (that is what it's called in C string library) is great for parsing.
So it should be: PUB Tokenize(str,str) http://www.tutorialspoint.com/c_standard_library/c_function_strtok.htm
Ahh, good point. I had kept it spaces only because I wasn't sure how to go about implementing one that supports full tokens, but now that you mention it, it deserves a second look. I'll see what I can do about that when I get back to it later.
It also should be noted that the replace functions do not currently shrink/expand the strings they operate on, so that's another issue that needs to be resolved that may impact this one.
Hi guys, I've been quiet for a couple of days because I've been working on an object I've wanted for a long time. =P
I've created a new object called commandparser for building command line interfaces with Spin. It depends only on the string library so it can be used to create serial, TV, and LCD interfaces. It also supports multiple commands so you can easily make a terminal that feels like a regular shell. Check it out here:
This is made better because the terminal now implements a ReadLine function that allows backspace.
You will also notice the formatting of this html file. This is a demo of the documentation view that will eventually find its way into PropellerIDE, so start using markdown for your doc comments now!
I created an object called debug.shell which I'd like to become a drop-in debug terminal. Right now, I've merged in Chip's Monitor.spin to print hex data dumps and also added a clock info printout, but any suggestions or code to contribute to this object would be awesome!
The combination of these new objects and the improved terminal in PropellerIDE make for the most shell-like experience I've ever had on a Propeller, and it makes the next IDE feature I should add fairly obvious: a command history!
To see the new command line parser and the debug shell in action, download the latest version of PropellerIDE (just released moments ago) and try out the debug.shell.spin object.
I just stumbled on this after searching for the source of the library that used to be (I think?) part of the propelleride git repository. It looks like a fantastic idea, and I really like what I've seen so far, personally.
One thing I haven't seen anyone address yet, maybe because it doesn't seem to be a problem at least with the objects in the library so far, is capitalization of filenames: this is an issue that can be a real pain on OS's/filesystems that are case-sensitive, because not everyone has the same idea of how filenames should be capitalized. If I remember rightly, I think I brought this up as an issue on propelleride's old issue tracker a long time ago, not really thinking it through - something to the effect of asking if propelleride could be case-preserving, but also case-insensitive. I believe the answer was that if other languages or editors (e.g., C) don't do this, why should propelleride? And indeed, after thinking about it, I agree 100%. The issue still has a potential to exist, though, so it's left more as habit of the programmers. I can't tell you how many times I've downloaded a propeller archive that had source with a line like
ser: "FullDuplexSerial"
but the file stored in the archive is capitalized like fullduplexserial.spin, or similar - it's just frustrating to have to fix in order to build it. What are your thoughts on mandating that source in this repository be made a consistent case, say, all-lowercase, for example?
Regardless, whatever you decide, thanks so much for all your work on this and propelleride!
Cheers,
Jesse
EDIT: Sorry, I hadn't seen CONTRIBUTING.md when I posted this *hides in shame in the corner*
I just stumbled on this after searching for the source of the library that used to be (I think?) part of the propelleride git repository. It looks like a fantastic idea, and I really like what I've seen so far, personally.
One thing I haven't seen anyone address yet, maybe because it doesn't seem to be a problem at least with the objects in the library so far, is capitalization of filenames: this is an issue that can be a real pain on OS's/filesystems that are case-sensitive, because not everyone has the same idea of how filenames should be capitalized. If I remember rightly, I think I brought this up as an issue on propelleride's old issue tracker a long time ago, not really thinking it through - something to the effect of asking if propelleride could be case-preserving, but also case-insensitive. I believe the answer was that if other languages or editors (e.g., C) don't do this, why should propelleride? And indeed, after thinking about it, I agree 100%. The issue still has a potential to exist, though, so it's left more as habit of the programmers. I can't tell you how many times I've downloaded a propeller archive that had source with a line like
ser: "FullDuplexSerial"
but the file stored in the archive is capitalized like fullduplexserial.spin, or similar - it's just frustrating to have to fix in order to build it. What are your thoughts on mandating that source in this repository be made a consistent case, say, all-lowercase, for example?
Regardless, whatever you decide, thanks so much for all your work on this and propelleride!
Cheers,
Jesse
EDIT: Sorry, I hadn't seen CONTRIBUTING.md when I posted this *hides in shame in the corner*
Haha, thanks for the feedback. I'm just happy to hear that someone else is frustrated by the same problem.
The primary difference between PST and com.serial.terminal is that com.serial.terminal factors out the core serial and string formatting functionality into reusable objects, which can reduce the code size of projects that leverage these library objects.
I tried running the test.sh that comes with the library, and got a number of errors. It looks like the tests may have bit-rotted?
openspin -L . ./library/sensor.inductive.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Mar 2 2014 11:49:29
Compiling...
./library/sensor.inductive.spin
|-signal.synth.spin
|-signal.adc.spin
|-display.tv.graphics.spin
|-misc.numbers.spin
misc.numbers.spin : error : Can not find/open file.
openspin -L . ./library/demos/misc/COIL_demo.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Mar 2 2014 11:49:29
Compiling...
./library/demos/misc/COIL_demo.spin
|-display.tv.spin
display.tv.spin : error : Can not find/open file.
openspin -L . ./library/demos/math/rctime/RCTIME_background_DEMO.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Mar 2 2014 11:49:29
Compiling...
./library/demos/math/rctime/RCTIME_background_DEMO.spin
|-display.tv.spin
display.tv.spin : error : Can not find/open file.
openspin -L . ./library/demos/math/rctime/RCTIME_foreground_DEMO.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Mar 2 2014 11:49:29
Compiling...
./library/demos/math/rctime/RCTIME_foreground_DEMO.spin
|-display.tv.spin
display.tv.spin : error : Can not find/open file.
openspin -L . ./library/demos/system/ClockDemo.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Mar 2 2014 11:49:29
Compiling...
./library/demos/system/ClockDemo.spin
|-system.clock.spin
system.clock.spin : error : Can not find/open file.
openspin -L . ./library/demos/sensor/Inductor Demo.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Mar 2 2014 11:49:29
Compiling...
./library/demos/sensor/Inductor Demo.spin
|-display.tv.spin
display.tv.spin : error : Can not find/open file.
openspin -L . ./library/misc.coilread.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Mar 2 2014 11:49:29
Compiling...
./library/misc.coilread.spin
|-system.clock.spin
system.clock.spin : error : Can not find/open file.
Ahh, well, I guess you could say that. This is all a work-in-progress, so I may have changed the names of some objects without updating their demos. I'm releasing a new product in a few months and this effort is a part of that, so everything in due time. =P
Comments
So I think you guys are gonna like this one. I've checked in the new string functionality. Thanks, @Cluso99 for suggesting ASCII0_STREngine.spin as the foundation for a string library!
The string.spin API has been cleaned up a lot.
https://github.com/parallaxinc/spin-standard-library/blob/master/library/string.spin
char.type and string.type offer information about characters and strings respectively.
https://github.com/parallaxinc/spin-standard-library/blob/master/library/char.type.spin
https://github.com/parallaxinc/spin-standard-library/blob/master/library/string.type.spin
Then I added a bunch of new demos!
I also added the Basic template, which is based on Simple_Spin_template.spin (thanks, @MikeDYur!).
Let me know what you guys think, and come on, people! Keep those suggestions coming!
One suggestion: the "IsSpace" method makes me wonder if it checks for a single space, multiple spaces or any amount of whitespace (tabs, newlines, etc). If it only checks for a single character, it might be helpful to add another method for checking if a string is empty or contains only whitespace.
Thanks, guys!
So there are two separate type objects; one for chars and one for strings.
The problem here is that Spin has never allowed subdirectories. I have a proposal that I've been working on to incorporate this feature in a way that's backwards-compatible with existing Spin products, but since I am working around it anyway, it is low on my priority list.
Makes sense. I'd just rename them to IsWhitespace then, since "Space" is a bit ambiguous.
Don't mind me, I control my world from a smart phone. I do have a question, I loose all formatting when I copy and paste code, and that is a pain, not sure there is any way around that, except to use a PC.
Thanks,
_mike
I found many of the suggestions quite reasonable for the sake of consistency and have been trying to follow them. So what if it flopped as an initiative. I'm not sure why, but I always feel there is yet another half-way step before any object qualifies as gold. That is to say, always tinkering.
Brett, good luck with this initiative, the whole library, not merely individual objects.
Ahh, I'll leave it as is. A lot of languages have standard libraries with a similarly named function. It's not really ambiguous when you consider how trivial a function that detects an actual "space" character is.
I suspect that if someone actually needed IsSpace(), they would be doing text processing and already know what they're looking for.
Hi there. I'm not sure if this is in response to what I said or not, because it sounds like a general forum question. Anyway that's what the code tags are for (added a space so it'd show up).
Haha, yes, of course, there is always room for improvement and more things to add. But as @potatohead mentioned earlier in this topic, the main goal here is the basics. Having a solid foundation of core objects that is widely applicable to other projects makes all Propeller programmers more productive. In doing this, we can enable developers to knock out a new application quickly instead of floundering in low-level details.
Because who among us hasn't felt that frustration when you just can't find the library you need when you need it? And who among us hasn't been pleasantly surprised to find that a function you need is actually built-in to the language? That's a good feeling, and one I'd like to recreate with Spin.
DON'T USE.SPIN
{
Filename: Author: Copyright (c) 2015 See end of file for terms of use.
}CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000VAROBJPUBPRIDAT{
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.
}
Thanks! =P
Ahhh! I see what's going on. This is one of a few issues that comes from making Spin cross-platform. Every operating system handles line endings differently, and every text editor handles them differently too. Some text editors automatically convert line endings but others don't.
Most of Spin's lifetime has seen most Spin files being saved in UTF-16 little-endian with Windows line endings, because PropTool was written at a time when that was more common. PropellerIDE, on the other hand currently converts all files to UTF-8 with UNIX line endings for consistency, which is fine for the most part, but this will for example, make Windows Notepad not like it, while Wordpad will read it without a problem.
Unfortunately, this problem is much bigger than PropellerIDE and there isn't much I can do. There are trade-offs in every solution. My recommendation is to try opening it on a computer, or wait until PropellerIDE has Android support (planned, but you could be waiting awhile). =P
I got a good idea of what you were talking about, the technical is over my head, I usually avoided spin files in OBEX for that reason, I know I'm in a very small minority that doesn't have home internet, and if I wanted dish satellite again, I could solve it.
For now I'll struggle along downloading compressed archive's, or spin's I really want that have to gone over, or take one of my laptops to McD's, guess what's for breakfast.
_mike
Just a little busy currently, so this is short.
You predefine a few longs in hub. Usually fixed, but doesn't have to be.
In the main program you include two stub objects, stdout and stdin. Your program always outputs to the stdout, and always inputs from the stdin.
Before using these though, you start (load) up cog(s) with the actual driver object, passing it the rendezvous location(s) in PAR. In the pcsio object, this is done simply by calling the pcsio.start(inRendezvous, outRendezvous, serPins, baud) pcsio is a modified serial object similar to FullDuplexSerial.
If you are using separate drivers such as keyboard and tv, your main program just calls kbd.start(inRendezvous, pins+etc) and also tv.start(outRedezvous, pins+etc). This starts 2 cogs, one for kbd and one for tv.
Stdin & Stdout only support the very basic char routine and test to see if there is a char available. Any higher level calls should preferably be done via a string/hex/decimal object to convert to the char out.
The Stdin & Stdout routines each use one long rendezvous location in hub. $0 signifies empty ($100 is used for char $0), and asingle char is passed in the rendezvous long. ie we really only use 9 bits, but it allows for future expansion if required.
Here is the stdout routine And here is the stdin routine This is the start of the pcsio driver
It's becoming more important to have this as I've been implementing some more complex terminal interfaces that would be impractical to make them work for different outputs and still be drop-in solutions. This could solve a lot of problems.
It's destructive, but as all strings are in sram on a Prop it will always work and you could always put the token back if needed.
strtok() (that is what it's called in C string library) is great for parsing.
So it should be: PUB Tokenize(str,str)
http://www.tutorialspoint.com/c_standard_library/c_function_strtok.htm
Ahh, good point. I had kept it spaces only because I wasn't sure how to go about implementing one that supports full tokens, but now that you mention it, it deserves a second look. I'll see what I can do about that when I get back to it later.
It also should be noted that the replace functions do not currently shrink/expand the strings they operate on, so that's another issue that needs to be resolved that may impact this one.
Hi guys, I've been quiet for a couple of days because I've been working on an object I've wanted for a long time. =P
I've created a new object called commandparser for building command line interfaces with Spin. It depends only on the string library so it can be used to create serial, TV, and LCD interfaces. It also supports multiple commands so you can easily make a terminal that feels like a regular shell. Check it out here:
https://github.com/parallaxinc/spin-standard-library/blob/master/library/commandparser.spin
And read the documentation for it here:
http://lamestation.net/downloads/misc/docview_demo.html
This is made better because the terminal now implements a ReadLine function that allows backspace.
You will also notice the formatting of this html file. This is a demo of the documentation view that will eventually find its way into PropellerIDE, so start using markdown for your doc comments now!
I created an object called debug.shell which I'd like to become a drop-in debug terminal. Right now, I've merged in Chip's Monitor.spin to print hex data dumps and also added a clock info printout, but any suggestions or code to contribute to this object would be awesome!
Check it out here:
https://github.com/parallaxinc/spin-standard-library/blob/master/library/debug.shell.spin
Here it is in action:
The combination of these new objects and the improved terminal in PropellerIDE make for the most shell-like experience I've ever had on a Propeller, and it makes the next IDE feature I should add fairly obvious: a command history!
To see the new command line parser and the debug shell in action, download the latest version of PropellerIDE (just released moments ago) and try out the debug.shell.spin object.
http://developer.parallax.com/propelleride/
I haven't heard any new suggestions for objects recently, so keep them coming, add your own, and let me know what you think!
I just stumbled on this after searching for the source of the library that used to be (I think?) part of the propelleride git repository. It looks like a fantastic idea, and I really like what I've seen so far, personally.
One thing I haven't seen anyone address yet, maybe because it doesn't seem to be a problem at least with the objects in the library so far, is capitalization of filenames: this is an issue that can be a real pain on OS's/filesystems that are case-sensitive, because not everyone has the same idea of how filenames should be capitalized. If I remember rightly, I think I brought this up as an issue on propelleride's old issue tracker a long time ago, not really thinking it through - something to the effect of asking if propelleride could be case-preserving, but also case-insensitive. I believe the answer was that if other languages or editors (e.g., C) don't do this, why should propelleride? And indeed, after thinking about it, I agree 100%. The issue still has a potential to exist, though, so it's left more as habit of the programmers. I can't tell you how many times I've downloaded a propeller archive that had source with a line like but the file stored in the archive is capitalized like fullduplexserial.spin, or similar - it's just frustrating to have to fix in order to build it. What are your thoughts on mandating that source in this repository be made a consistent case, say, all-lowercase, for example?
Regardless, whatever you decide, thanks so much for all your work on this and propelleride!
Cheers,
Jesse
EDIT: Sorry, I hadn't seen CONTRIBUTING.md when I posted this *hides in shame in the corner*
Haha, thanks for the feedback. I'm just happy to hear that someone else is frustrated by the same problem.
I just saved it to my desktop. I'm going to add PST because I frequently use it to develop code.
PST functionality is available in the com.serial.terminal object (though it may be renamed to terminal once a rendezvous driver is available).
https://github.com/parallaxinc/spin-standard-library/blob/master/library/com.serial.terminal.spin
The primary difference between PST and com.serial.terminal is that com.serial.terminal factors out the core serial and string formatting functionality into reusable objects, which can reduce the code size of projects that leverage these library objects.
I just found this thread, and I can't wait until I can download and play with the library.
Jim
Ahh, well, I guess you could say that. This is all a work-in-progress, so I may have changed the names of some objects without updating their demos. I'm releasing a new product in a few months and this effort is a part of that, so everything in due time. =P