Over the years I have seen plenty of robots carrying around honking great laptops as their "brains". There are many on YouTube.
Presumably they have Arduinos or other processors/electronics to handle all the sensor inputs, motor controls etc. Presumably those Arduinos or whatever are also programmable from the stonking great laptop being carried around.
So here's the reasoning. The honking great laptop can be replaced with an tiny, low power consumption ARM board running Linux. It provides the horse power for the "brains" part. The low level stuff is done by Arduino or our favourite the Propeller. It make sence then that the "brains" can also be used to reprogram the Propeller.
Put a Raspi board and a Prop board together and you have the whole control system in a cigarette packet sized space to fit in your robot or whatever. Complete with networking, USB etc. WIFI is only a tiny dongle away. As a bonus the whole machine is now completely self hosting. No PC required anymore. If, that is, all the Propeller tools can be got working on the ARM. Which so far they can.
For 30 dollars or so, why not do it?
As for practical, well that Pi has more processing power and disk space than the PC I was using a few years back. Well OK last centuary. There is nothing practical about being tied to a desktop machine on a particular desk.
The robot applicaiton makes a lot of sense. I was mostly wondering why anyone would want to use a RaspberryPi as a replacement for a desktop computer unless the *really* couldn't afford any more than $35 which is, of course, possible. Anyway, for my purposes, I have far too many desktop and laptop computers already. I don't have a need for a cheap and small desktop replacement.
This is exactly how many compilers work already, acting only as a front-end then passing their output to gcc for the actual compiling. Fortran, pascal, and ada are three that work this way off the top of my head.
You make it sound as if in the GCC world Fortran, Pascal, Ada etc are translated to C and then compiled by the GCC C compiler.
This is not what happens. I have no idea of the details, others here could explain better, but all languages handle by GCC are first compiled into an intermediate language, including C. Which is not supposed to be human readable or used for programming. From that intermediate representaion they are then transformed and optimized into assembly language. Which is different for different target architectures of course. That is in turn assembled and linked into the final executable.
It is true though, that the first implementation of C++ was exactly a preprocessor that output C code for copilation. That is no longer so.
And yes there is a Pascal to C translator. No idea if it is of any use or not.
Required indentation is the worst thing ever to happen to programming. The syntax checker should know what segments belong where, requiring spaces to line up harkins back to cobol, and I can't see any reason for it at all. I started learning python, then gave up when I discovered indentation was required there too. Sure, it looks nice (to those who can see it) but for those of us who can't, it takes more time to count each lines leading spaces than it does to write more code. Thus, as of yet, I've not done much coding on the propeller, I use stamps and pbasic, which has no such restrictions.
Indentation is a coding style, not a structured part of a language (imo). I realize this is already a lost cause, and I'm of course constrained to use whatever comes out of the creation shops (at least until I d/l the source and change it), but other than pretty code, honestly, what's the reason for mandatory indentation?
... but other than pretty code, honestly, what's the reason for mandatory indentation?
Umm ... to delineate blocks?
BTW, I also program in Perl, which requires those C-like braces for block delineation. I also indent my Perl code. Frankly, I have no easier time visualizing Perl blocks when the nesting depth reaches a certain level than I do with Spin. The only advantage I can see with braces is that sometimes you can combine an entire block on one line with its antecedent, which can improve readability a little. But that's the exception.
Perhaps something could be done in the IDE using color cues to help with block visualization. Another way might be to click anywhere in a block and have that block and everything it encloses subtly highlighted.
In Spin, visual block ambiguity is often caused by partial indentation, IOW indentation by a fractional "tab" stop. This is something a "smart" editor could prevent.
I've not looked at the source in years, but the initial versions of fpc did translate the pascal code to c, then called gcc to do the compiling. I've seen other one-shot languages use this approach as well.
Phil, you didn't answer my question. Blocking chunks of code is a visual thing, the compiler doesn't (or shouldn't at least) care how much indentation thee is. I maintain, the only reason for indentation is for readability. Nothing rong with that, but making it mandatory makes no sense, so I repeat the question, what's the purpose? Other than for readability.
The spin compiler does care about the indentation. It determines the start and end of blocks of code. Not sure how you don't understand this? It's pretty fundamental to Spin coding.
if there wasn't indenting, then you would need to add something else to mark the start and end of blocks of code. Like the { }'s in C/C++ (et al), or the begin/end in pascal/delphi.
I think softcon understands that indentation is used to delineate blocks, but the question is why use indentation instead of explicit block delimiters? I think the answer is that Chip prefers indentation over explicit block delimiters.
Chip's original answers came down to not liking to type things twice, and not liking to type things that didn't add a lot of value, and for general readability, clean code purposes, among other things we can probably find in the early Propeller archives.
Braces can cut down on vertical screen space, or can be difficult to see as blocks when they don't. Since the spaces need to be there anyway, they can serve the purpose of delineating blocks.
I totally get the opinion that it's not a good feature. There are strong cases for that. Defensible. We all have our preferences too. No worries.
The characterization that "it's the worst thing to happen to programming" isn't something I find defensible, FWIW. Programming is filled with lots of ugly things, and they are in various places, creating various annoyances. This just needs to be managed personally. One other thing I know Chip has expressed is just learning the good tools, and then applying the tool generally is leaner than bending a tool to work like other tools, of course depending on what is being dealt with, and that is all about getting cool stuff done. The cool stuff is what we want, the tools are what we need to get there. Use the tool that works best and get the cool stuff done.
In that spirit, SPIN was meant to be an effective tool for programming Propellers. With some advanced case exceptions we've come to know well, that goal was met seriously well! I strongly identify with this, and that has been my general approach to a lot of things over the years. It works. I don't worry so much about it all personally. If a tool is too hard, or different, then maybe it makes sense to do the work to get a more standard or familiar one up and running. Past that, it's meta that isn't productive really.
IMHO, some editor work can help with this. The idea of highlighting a block and having the editor highlight it is a good one, BTW. I know there are priorities right now, and scope creep needs to be managed, but adding that one to some list somewhere for someday would be a net gain, if and when it ever got done. For better or worse the Propeller Tool is a significant part of what makes the SPIN + PASM + Propeller package work so well. It was all designed to work and get to the cool stuff quick, and now that the scope of things is expanded, there has been a lot of work to duplicate that package. Worth while work, but work that needs to be kept separate from maintaining the quality of the package.
The way I see it is the Propeller is a highly differentiated design. The Propeller is going to continue to be highly differentiated too. Where that kind of thing is true, there is absolutely no reason to also provide highly differentiated tools, right along with "standard" or "professional" tools. This is done all the time. Which path people choose depends on what their process / experience / preferences are.
Coupla schools of thought:
1. Those that have invested in standard tools will want to apply them to the Propeller as they would other devices. Great! That's what we've got C for. We need to make C / C++ the very best it can be for Propellers, so that school of thought is well served. Doing that is good for everybody, whether or not they adopt C for use with the Propeller. And that's getting done too. Lots of great progress and options. C is gonna rock. Damn cool!
2. There are people who will just adopt the "native" tools. They do this for a lot of reasons. SPIN + PASM needs to be highly differentiated, exploiting the Propeller in the highly productive, lean, easy to read, fast way it does now. (and I know "fast" is relative, but given how it's built, SPIN is fast --and fast enough for how it was designed to operate with the Propeller way of doing things, but that's another discussion, right?) Doing this is also good for everybody regardless of whether or not they adopt SPIN for use with the Propeller. Hopefully, this will get done, and SPIN will continue to rock, and it will be damn cool!
3. There will be people who don't care. Ideally, maximizing 1 and 2 will keep these to a minimum, seeing the Propeller more widely adopted, which is good for everyone, and frankly, will result in even more tools. The more the merrier!
Frankly, what isn't good for everybody is to mush the tools together so that the differentiation is lost. With that goes the value, yet the overhead of understanding the other differences that will remain are simply a cost. Net loss to go down that path. Might as well just center on one tool / environment and be done with it. I believe this would be a gain over just making a mess, but not as much of one as simply making both environments / tools sing on the chip would be.
Thank you, an excellent and well thought out answer. That takes care of my issues. I appreciate the full answer, and as mentioned before, I'm not happy, but it makes sense, and I can cope. It's just not a comfortable thing for me, space counting is not a trivial task using modern screen readers (dos screen readers worked just fine) because they tend to be line oriented instead of character oriented these days. Thus, when going to the next line in code, the screen readers have a tendency to go back to the start of the line, thus I have no idea if code lines are lined up or not, it takes time (adding to several minutes on sufficiently large chunks of code) to verify all spacing is as required. Perhaps I'll build myself a preprocessor that spaces according based on tags I insert into my data files, so I no longer need to count spaces. I'm ok with that. Things always are easier for me to deal with if I can understand the reasoning behind it all. Spacing certainly isn't something I'd have made a requirement, but having it explained as above works, and now it's a whole lot easier for me to find work arounds instead of writing it all off as a bad deal and using other things to do the job.
I'm not sure I'd have bothered to learn spin/pasm otherwise. I know, it's kind of silly of me, but I gave up on python for the same reason, it takes long enough to write the code, I don't need to spend hours debugging code just because I left out a space somewhere.
That kind of thing tends to make me extremely frustrated.
Of course, Apple has a tendency to put loads of abbriviations into their voices, which cause me no end of frustration when programming, because they tend to expand things that shouldn't be, such as vol always being pronounced as volume, whether it's spelled out or not. Nice when it means that, but quite another issue when it's not. Lots and lots of examples of this kind of thing almost made me go back to windows when I first switched to the mac. I still loose lots of development time to stupid mispronounciations like that, but at least now, I know roughly what to look for, so it's not as common as it used to be.
It's still frustrating, and a time waster though, thus my irritation with things that seem to make no sense to me, of which enforced formatting was one.
However, I think I can work around this one now, since I now understand how/why/what it is all for.
My first couple spin programs didn't work properly, because I tend to left justify things (can't see it, so who cares about spaces right?) and I never did find out why they didn't work. It was only after a few episodes of first spin podcast, where they just happened to mention in passing that indentation was used to identify blocks of code that I finally figured out what the problem was.
I hadn't seen mention of such anywhere in the documents/chunks of code I'd read up to that point.
So, there's just a bit of background, as to why I was so insistent on finding an answer for this one.
Thanks one and all, I'll shut up on this topic now.
And, actually go and learn spin properly.
BTW, I also program in Perl, which requires those C-like braces for block delineation. I also indent my Perl code. Frankly, I have no easier time visualizing Perl blocks when the nesting depth reaches a certain level than I do with Spin. The only advantage I can see with braces is that sometimes you can combine an entire block on one line with its antecedent, which can improve readability a little. But that's the exception.
Perhaps something could be done in the IDE using color cues to help with block visualization. Another way might be to click anywhere in a block and have that block and everything it encloses subtly highlighted.
In Spin, visual block ambiguity is often caused by partial indentation, IOW indentation by a fractional "tab" stop. This is something a "smart" editor could prevent.
-Phil
My problem with "blocking by indentation" isn't the indentation it's that the indentation defines the blocking. A stray space during an edit and you've introduced a nightmare to find change in the functionality of the code. Personally I not only indent my code but also use "vertical white space" (blank lines) to make the block stand out. I would also hate to have blank lines before and after a block delineate blocks even though I do it anyhow.
You raise an interesting point that not many of us would have thought of. The fact that white space indenting is discriminative, its excluding those who cannot see. Or at least making their access to code a lot harder. As such white space indenting is not just a technical mistake it's anti-social.
I consider it a technical mistake for the reason that pasting code into the forum, for example, will mess up the spacing and hence change the program logic. So then we need code tags around the code in our postings. There are many other ways those spaces can get messed up.
The mere fact that so many clamour for some kind of markers in the editor to show block layout should be a strong hint that it'a a bad idea. And those requests come from people who can see perfectly well.
softcon: It never ceases to amaze me how you manage. I have never thought about indentation from a blind persons perspective. It must be incredibly difficult without the spacing problem.
Your preprocessor is a great idea using tags. You can always use bst or homespun to compile for you from a command line.
Andy wrote a PreSpin compiler that preprocesses a spin program and then calls the PropTool to compile.
While this was for include files, obviously Andy has made this work, so perhaps he may be willing to share his code for you to modify.
Here is Andy's details - PreSpin 0.3 by Andy Schenk www.insonix.ch/propeller
Phil Pilgrim (PhiPi) also uses a spin preprocessor (as mentioned above), so he could also be another to help you.
Either of these solutions would provide you with the basic code, so it would only be a simple matter of expanding the tags to spaces.
I didn't realize you couldn't see softcon. Frankly, programming that way is amazing! Hats off to you! I have setup screen readers for various things and people, and frankly, find them extremely difficult.
Sure glad you read that the way it was intended. I was about to make an edit or two this morning, just because I didn't want it to go badly. Cheers!
A blind programmer having problems with the indentation in Spin? We need to put our heads together and solve this!
Could one add braces { } like in C? Hmm, no, braces mean something else in Spin.
What about some other command, eg "begin" and "end". What if you put a single quote then begin. That could be backwards compatible because an old compiler would treat it as a comment but a new compiler could treat it as a block beginning. Would {begin} be backwards compatible?
It doesn't have to be 'begin. It could be or anything really.
Or - what about the little arrows that are in the proptool. Could those be turned into actual ascii characters? Is there something in the ascii 0-127 range, or would it be something in the extended 128-255 range?
Counting spaces would be a real pain. There has to be a better solution than that.
I'm thinking the same thing Dr_A. We should engineer this.
Ok, this just popped into my head, and maybe it should have stayed there, but...
What about a block command of some sort. Pick a keyword that makes sense and that is short...
some root statement
:bd1 REPEAT 5
:bd1 do stuff
:bd2 do more stuff
:bd2 and still more stuff
:bd1 continue after repeat
Simply encode it all as a label or something, or use a keyword whatever. That way, the reader can say what the indent is directly, and there are no excess spaces, keeping the code lean. Software could translate things one way or the other. For something indented, it gets reduced to this form, and for something in this form, expand with a set spacing, say X spaces. Edit: Just noted the pre-processor comment... oh well, I'll just leave this and the discussion can continue.
Perl and C use braces, but, as Phil said, we still indent the code for readability. But there's a major difference to when the indentation is alone (and necessary, as with Spin), with no braces.. the editor can't find it for you. With braces you simply place the ending brace where you want to end your block, never mind how the code above came out (maybe you cut&pasted it from somewhere else), then hit a key (if even that) and the editor will line up the indentation for you. Without the braces (or whatever anchor points provided by the language) the editor cannot help you in sorting out your blocks - you're on your own.
I use bst as well, and unix shell scripts are something I'm quite familiar with, so no problem using a script to call my preprocessor first, then feed that output into the bstc tool. I use scripts for all kinds of thins, including compiling, because frankly, typing all the required command-line parameters is too much work, especially on osx when including frameworks to handle speech output, or various graphics packages for adding formatting to finished programs. This is one reason I like Java, I just use the grid layout, and let the computer handle the layout for me. So, I'll either write my own preprocessor, or use one of the above mentioned ones, and that will solve the problem. Very nicely too. I should have thought of that before, but sometimes, it takes prodding to come up with things. I like the idea of using comment blocks 'begin 'end type things, I'll implement that, that way if I do accidentally post my code instead of the processed stuff, it won't break existing solutions, though I suppose not working right could be considered broken. Thanks again all for the assistance. This forume is great, even when I'm being stubborn, folks still come through with solutions, that takes tolerance and patients. Thanks all.
Roy recently put a pre-processor into the open source spin compiler. Perhaps he can add a #s4 or something to give 4+1 spaces before a statement. I.e. "#s4 repeat"
@softcon, I've always been amazed at how prolific you are. Since .sigs show up when I'm not logged in, I've noticed your disability and wondered when other people without your condition would see it. I've never wanted to make you feel different out of respect for you and the disabled friends in my life. You must have great concentration ability, perseverance, and attention to detail that few of us share. Thank you for wanting to help make Spin better for all instead of giving up.
There might be another solution to this screen reader issue. How about a screen reader that was Spin aware?
Now I have no idea what a modern screen reader does when it comes to Spin or Python. Does it announce the new lines? Does it go through all the spaces and tabs "tab, tab, tab..." or does it just ignore them like "repeat a = 1 to 10 b = c + d x = y * z...". Which I can see would drive you nuts.
A white space indent aware screen reader would know that there is a new indentation block level and announce it accordingly . perhaps like so: "repeat a = 1 to 10 do b = c + d x = y * z...end"
Now there are free and open source readers, for example Festival which can be found here: http://www.cstr.ed.ac.uk/projects/festival/ and is probably packaged for most Linux distributions.
Something like that could be built into SimpleIDE, for example, and made white space aware.
I have often thought, and suggested at times, that there should be a switch in the IDE that could change the code from spaced indentation to/from marked code (using "{" and "}" or another character pair/words such as "begin" and "end"). Initially this would be in the form of a preprocessor/converter, but if proven useful could untimately built in to the IDE.
I would prefer to use something as used in other languages. The markers should be placed on their own lines (i.e. inserted as lines) and indented as per the current indentation block to make easier reading (and make the translation code easier to implement).
If "begin" and "end" were used then I don't think there would be any need for anything else to be changed, so perhaps this is the simpler way to go.
If "{" and "}" were used then the existing "{" and "}" would need to be changed. Either we also change "{{" and "}}" using the // and /* */ as in c or say "{{#" and "#}}" because we want to be able to convert back and forth.
Now, I think it would be good practice to identify this at the beginning of the code. So the first line should contain a parameter/option command. Perhaps "#indent on" and "#indent off" with the default if missing to "#indent on" to maintain backward compatibility.
softcon: Would this work for you? From what you said, the spacing is a pain. So, we could add into the conversion routines an additional switch that removes the indentation when the block parameters are used. When converting back, we would also have to define the indentation tabbing (i.e. 2 or 3 or whatever). Perhaps this could just be an extra parameter(s) in the #indent command. Something like "#indent on/off -2/2" where "-2" means remove indentation when "on" and means indentation 2 spaces per block when "on".
Does this make sense ???
Postedit:
As an afterthought, perhaps we could also add converting to/from the parallax 16bit character code to UTF-8 (or whatever it is called) by using a delimiter character to maintain the extended characters in the font when going to UTF-8. This way, other editors would work, but users could switch to view any diagrams if present.
So if we write a pre-processor, what are the rules?
Is it something like - remove leading spaces, get first word, look for match in keyword list (eg if, else, repeat), measure number of leading spaces on this line, measure number of leading spaces on next line, insert "begin" or whatever block start word we choose, keep searching lines until leading spaces goes back to the first number of leading spaces, then insert "end".
Hmm - that is a bit complex even to describe. And the Proptool is doing it all behind the scenes, and on the fly with every character typed.
The problem you'll run into when trying to add a screen reader into a program is the fact that everyone uses different settings in their speech settings. I run mine as fast as it'll go, others run it at default rates, which are muc slower. Some folks change pitch for caps, change punctuation when programming, then change it back when reading plain text, and so on. It would be literally impossible to build in anything that would work for most screen reader users. I'm actually not sure how many screen reader users there are that are programmers. A few hundred to be sure, possibly a few thousand, and may be even higher. Problem is, no matter how you look at it, it's not worth making that much work for someone to make what would amount to a partial solution. It's much easier on OSX, because apple already includes a screen reader called voiceover. Adding things that make voiceover work well with osx programs is relatively simple, so most osx progs are usable if not entirely accessible, but other operating systems don't have that advantage, and especially on windows, each screen reader works differently, so no joy there. So, something like what was suggested, #s2 or #s4 or something, with a define to turn it on or off, defaultig to off would be perfect, that would allow those of us who need it to have it, but would have minimal impact on most users.
I agree - I'm not sure a screen reader is the answer.
I'm thinking of a simple command line program. You feed it a spin program and it spits out a changed spin program with block beginnings and endings marked. Maybe it tidies up indents too so that they are always two spaces. Maybe it is {begin} and {end} and the proptool treats those as comments so ignores them.
So you can read that program more easily. It should compile just fine too.
And maybe there is a companion program that strips out those block markers. That would be a very simple program - a find and replace. But maybe this second program is not needed - it is more for people who might look at it and go 'that is not standard spin'.
So feed in any program in the obex into this command line program and it outputs "block marked spin". It can't be that hard to write - the language rules are pretty simple. I reckon it could be less than a hundred lines of vb or C#.
The problem you'll run into when trying to add a screen reader into a program is the fact that everyone uses different settings in their speech settings. I run mine as fast as it'll go, others run it at default rates, which are muc slower. Some folks change pitch for caps, change punctuation when programming, then change it back when reading plain text, and so on. It would be literally impossible to build in anything that would work for most screen reader users. I'm actually not sure how many screen reader users there are that are programmers. A few hundred to be sure, possibly a few thousand, and may be even higher. Problem is, no matter how you look at it, it's not worth making that much work for someone to make what would amount to a partial solution. It's much easier on OSX, because apple already includes a screen reader called voiceover. Adding things that make voiceover work well with osx programs is relatively simple, so most osx progs are usable if not entirely accessible, but other operating systems don't have that advantage, and especially on windows, each screen reader works differently, so no joy there. So, something like what was suggested, #s2 or #s4 or something, with a define to turn it on or off, defaultig to off would be perfect, that would allow those of us who need it to have it, but would have minimal impact on most users. That would certainly be the least amount of work for all involved I think, and keeping it simple is always best.
As an afterthought, there are things that can be done with programs even in windows to make them more speech friendly, and anything I can offer in that arena to make any new environments work better with existing speech programs I'm certainly willing to do, as I'm sure there will be more of us eventually. (at least there will be if I have anything to say about it) I want folks to know they can build their own adaptive technology solutions, and not rely on those overpriced solutions that are currently available.
If I have my way, blind/disabled folks will be building their own solutions where possible and practical, and showing the companies that charge 1200 bucks for a talking note taker, that we can build our own without their assistance thank you very much, and can do so for a tenth the price.
I doubt it'll happen, but what the heck, it's worth a try.
And, come to think of it, I do have source rights to a windows screen reader, but unfortunately, I can't do anything with it at the moment, because I'm missing some libraries it uses, the most important of which is the dectalk development libs. Until recently, I was unable to track down who owned the rights and could sell a license. I bought the source rights from the brother of the guy who used to develop it when he died a few years ago. Without those libs though, which the code relies on heavily, the code has just sat here on my hd, collecting dust. I've made a few attempts to revive it, but the way it's written, it's really difficult to remove dependency on dectalk libs, and still have it work properly.
And, it doesn't help that C and C++ isn't one of my strongest language skills, and you can see why it's just hung there doing nothing.
Now, I can at least check to see what a new license would cost me, though I doubt I could afford it.
it used to be quite a hefty chunk of change, and I don't have the sale of a house to finance my purchase this time.
Comments
You make it sound as if in the GCC world Fortran, Pascal, Ada etc are translated to C and then compiled by the GCC C compiler.
This is not what happens. I have no idea of the details, others here could explain better, but all languages handle by GCC are first compiled into an intermediate language, including C. Which is not supposed to be human readable or used for programming. From that intermediate representaion they are then transformed and optimized into assembly language. Which is different for different target architectures of course. That is in turn assembled and linked into the final executable.
It is true though, that the first implementation of C++ was exactly a preprocessor that output C code for copilation. That is no longer so.
And yes there is a Pascal to C translator. No idea if it is of any use or not.
Indentation is a coding style, not a structured part of a language (imo). I realize this is already a lost cause, and I'm of course constrained to use whatever comes out of the creation shops (at least until I d/l the source and change it), but other than pretty code, honestly, what's the reason for mandatory indentation?
BTW, I also program in Perl, which requires those C-like braces for block delineation. I also indent my Perl code. Frankly, I have no easier time visualizing Perl blocks when the nesting depth reaches a certain level than I do with Spin. The only advantage I can see with braces is that sometimes you can combine an entire block on one line with its antecedent, which can improve readability a little. But that's the exception.
Perhaps something could be done in the IDE using color cues to help with block visualization. Another way might be to click anywhere in a block and have that block and everything it encloses subtly highlighted.
In Spin, visual block ambiguity is often caused by partial indentation, IOW indentation by a fractional "tab" stop. This is something a "smart" editor could prevent.
-Phil
if there wasn't indenting, then you would need to add something else to mark the start and end of blocks of code. Like the { }'s in C/C++ (et al), or the begin/end in pascal/delphi.
Roy
Braces can cut down on vertical screen space, or can be difficult to see as blocks when they don't. Since the spaces need to be there anyway, they can serve the purpose of delineating blocks.
I totally get the opinion that it's not a good feature. There are strong cases for that. Defensible. We all have our preferences too. No worries.
The characterization that "it's the worst thing to happen to programming" isn't something I find defensible, FWIW. Programming is filled with lots of ugly things, and they are in various places, creating various annoyances. This just needs to be managed personally. One other thing I know Chip has expressed is just learning the good tools, and then applying the tool generally is leaner than bending a tool to work like other tools, of course depending on what is being dealt with, and that is all about getting cool stuff done. The cool stuff is what we want, the tools are what we need to get there. Use the tool that works best and get the cool stuff done.
In that spirit, SPIN was meant to be an effective tool for programming Propellers. With some advanced case exceptions we've come to know well, that goal was met seriously well! I strongly identify with this, and that has been my general approach to a lot of things over the years. It works. I don't worry so much about it all personally. If a tool is too hard, or different, then maybe it makes sense to do the work to get a more standard or familiar one up and running. Past that, it's meta that isn't productive really.
IMHO, some editor work can help with this. The idea of highlighting a block and having the editor highlight it is a good one, BTW. I know there are priorities right now, and scope creep needs to be managed, but adding that one to some list somewhere for someday would be a net gain, if and when it ever got done. For better or worse the Propeller Tool is a significant part of what makes the SPIN + PASM + Propeller package work so well. It was all designed to work and get to the cool stuff quick, and now that the scope of things is expanded, there has been a lot of work to duplicate that package. Worth while work, but work that needs to be kept separate from maintaining the quality of the package.
The way I see it is the Propeller is a highly differentiated design. The Propeller is going to continue to be highly differentiated too. Where that kind of thing is true, there is absolutely no reason to also provide highly differentiated tools, right along with "standard" or "professional" tools. This is done all the time. Which path people choose depends on what their process / experience / preferences are.
Coupla schools of thought:
1. Those that have invested in standard tools will want to apply them to the Propeller as they would other devices. Great! That's what we've got C for. We need to make C / C++ the very best it can be for Propellers, so that school of thought is well served. Doing that is good for everybody, whether or not they adopt C for use with the Propeller. And that's getting done too. Lots of great progress and options. C is gonna rock. Damn cool!
2. There are people who will just adopt the "native" tools. They do this for a lot of reasons. SPIN + PASM needs to be highly differentiated, exploiting the Propeller in the highly productive, lean, easy to read, fast way it does now. (and I know "fast" is relative, but given how it's built, SPIN is fast --and fast enough for how it was designed to operate with the Propeller way of doing things, but that's another discussion, right?) Doing this is also good for everybody regardless of whether or not they adopt SPIN for use with the Propeller. Hopefully, this will get done, and SPIN will continue to rock, and it will be damn cool!
3. There will be people who don't care. Ideally, maximizing 1 and 2 will keep these to a minimum, seeing the Propeller more widely adopted, which is good for everyone, and frankly, will result in even more tools. The more the merrier!
Frankly, what isn't good for everybody is to mush the tools together so that the differentiation is lost. With that goes the value, yet the overhead of understanding the other differences that will remain are simply a cost. Net loss to go down that path. Might as well just center on one tool / environment and be done with it. I believe this would be a gain over just making a mess, but not as much of one as simply making both environments / tools sing on the chip would be.
I'm not sure I'd have bothered to learn spin/pasm otherwise. I know, it's kind of silly of me, but I gave up on python for the same reason, it takes long enough to write the code, I don't need to spend hours debugging code just because I left out a space somewhere.
That kind of thing tends to make me extremely frustrated.
Of course, Apple has a tendency to put loads of abbriviations into their voices, which cause me no end of frustration when programming, because they tend to expand things that shouldn't be, such as vol always being pronounced as volume, whether it's spelled out or not. Nice when it means that, but quite another issue when it's not. Lots and lots of examples of this kind of thing almost made me go back to windows when I first switched to the mac. I still loose lots of development time to stupid mispronounciations like that, but at least now, I know roughly what to look for, so it's not as common as it used to be.
It's still frustrating, and a time waster though, thus my irritation with things that seem to make no sense to me, of which enforced formatting was one.
However, I think I can work around this one now, since I now understand how/why/what it is all for.
My first couple spin programs didn't work properly, because I tend to left justify things (can't see it, so who cares about spaces right?) and I never did find out why they didn't work. It was only after a few episodes of first spin podcast, where they just happened to mention in passing that indentation was used to identify blocks of code that I finally figured out what the problem was.
I hadn't seen mention of such anywhere in the documents/chunks of code I'd read up to that point.
So, there's just a bit of background, as to why I was so insistent on finding an answer for this one.
Thanks one and all, I'll shut up on this topic now.
And, actually go and learn spin properly.
My problem with "blocking by indentation" isn't the indentation it's that the indentation defines the blocking. A stray space during an edit and you've introduced a nightmare to find change in the functionality of the code. Personally I not only indent my code but also use "vertical white space" (blank lines) to make the block stand out. I would also hate to have blank lines before and after a block delineate blocks even though I do it anyhow.
You raise an interesting point that not many of us would have thought of. The fact that white space indenting is discriminative, its excluding those who cannot see. Or at least making their access to code a lot harder. As such white space indenting is not just a technical mistake it's anti-social.
I consider it a technical mistake for the reason that pasting code into the forum, for example, will mess up the spacing and hence change the program logic. So then we need code tags around the code in our postings. There are many other ways those spaces can get messed up.
The mere fact that so many clamour for some kind of markers in the editor to show block layout should be a strong hint that it'a a bad idea. And those requests come from people who can see perfectly well.
Your preprocessor is a great idea using tags. You can always use bst or homespun to compile for you from a command line.
Andy wrote a PreSpin compiler that preprocesses a spin program and then calls the PropTool to compile.
While this was for include files, obviously Andy has made this work, so perhaps he may be willing to share his code for you to modify.
Here is Andy's details - PreSpin 0.3 by Andy Schenk www.insonix.ch/propeller
Phil Pilgrim (PhiPi) also uses a spin preprocessor (as mentioned above), so he could also be another to help you.
Either of these solutions would provide you with the basic code, so it would only be a simple matter of expanding the tags to spaces.
Sure glad you read that the way it was intended. I was about to make an edit or two this morning, just because I didn't want it to go badly. Cheers!
@Heater, well now Smile. Nicely stated.
Could one add braces { } like in C? Hmm, no, braces mean something else in Spin.
What about some other command, eg "begin" and "end". What if you put a single quote then begin. That could be backwards compatible because an old compiler would treat it as a comment but a new compiler could treat it as a block beginning. Would {begin} be backwards compatible?
It doesn't have to be 'begin. It could be or anything really.
Or - what about the little arrows that are in the proptool. Could those be turned into actual ascii characters? Is there something in the ascii 0-127 range, or would it be something in the extended 128-255 range?
Counting spaces would be a real pain. There has to be a better solution than that.
Ok, this just popped into my head, and maybe it should have stayed there, but...
What about a block command of some sort. Pick a keyword that makes sense and that is short...
some root statement
:bd1 REPEAT 5
:bd1 do stuff
:bd2 do more stuff
:bd2 and still more stuff
:bd1 continue after repeat
Simply encode it all as a label or something, or use a keyword whatever. That way, the reader can say what the indent is directly, and there are no excess spaces, keeping the code lean. Software could translate things one way or the other. For something indented, it gets reduced to this form, and for something in this form, expand with a set spacing, say X spaces. Edit: Just noted the pre-processor comment... oh well, I'll just leave this and the discussion can continue.
-Tor
@softcon, I've always been amazed at how prolific you are. Since .sigs show up when I'm not logged in, I've noticed your disability and wondered when other people without your condition would see it. I've never wanted to make you feel different out of respect for you and the disabled friends in my life. You must have great concentration ability, perseverance, and attention to detail that few of us share. Thank you for wanting to help make Spin better for all instead of giving up.
--Steve
Now I have no idea what a modern screen reader does when it comes to Spin or Python. Does it announce the new lines? Does it go through all the spaces and tabs "tab, tab, tab..." or does it just ignore them like "repeat a = 1 to 10 b = c + d x = y * z...". Which I can see would drive you nuts.
A white space indent aware screen reader would know that there is a new indentation block level and announce it accordingly . perhaps like so: "repeat a = 1 to 10 do b = c + d x = y * z...end"
Now there are free and open source readers, for example Festival which can be found here: http://www.cstr.ed.ac.uk/projects/festival/ and is probably packaged for most Linux distributions.
Something like that could be built into SimpleIDE, for example, and made white space aware.
And no, I don't think I'm up to such a task.
I would prefer to use something as used in other languages. The markers should be placed on their own lines (i.e. inserted as lines) and indented as per the current indentation block to make easier reading (and make the translation code easier to implement).
If "begin" and "end" were used then I don't think there would be any need for anything else to be changed, so perhaps this is the simpler way to go.
If "{" and "}" were used then the existing "{" and "}" would need to be changed. Either we also change "{{" and "}}" using the // and /* */ as in c or say "{{#" and "#}}" because we want to be able to convert back and forth.
Now, I think it would be good practice to identify this at the beginning of the code. So the first line should contain a parameter/option command. Perhaps "#indent on" and "#indent off" with the default if missing to "#indent on" to maintain backward compatibility.
softcon: Would this work for you? From what you said, the spacing is a pain. So, we could add into the conversion routines an additional switch that removes the indentation when the block parameters are used. When converting back, we would also have to define the indentation tabbing (i.e. 2 or 3 or whatever). Perhaps this could just be an extra parameter(s) in the #indent command. Something like "#indent on/off -2/2" where "-2" means remove indentation when "on" and means indentation 2 spaces per block when "on".
Does this make sense ???
Postedit:
As an afterthought, perhaps we could also add converting to/from the parallax 16bit character code to UTF-8 (or whatever it is called) by using a delimiter character to maintain the extended characters in the font when going to UTF-8. This way, other editors would work, but users could switch to view any diagrams if present.
Is it something like - remove leading spaces, get first word, look for match in keyword list (eg if, else, repeat), measure number of leading spaces on this line, measure number of leading spaces on next line, insert "begin" or whatever block start word we choose, keep searching lines until leading spaces goes back to the first number of leading spaces, then insert "end".
Hmm - that is a bit complex even to describe. And the Proptool is doing it all behind the scenes, and on the fly with every character typed.
Is the algorithm the proptool uses available?
I'm thinking of a simple command line program. You feed it a spin program and it spits out a changed spin program with block beginnings and endings marked. Maybe it tidies up indents too so that they are always two spaces. Maybe it is {begin} and {end} and the proptool treats those as comments so ignores them.
So you can read that program more easily. It should compile just fine too.
And maybe there is a companion program that strips out those block markers. That would be a very simple program - a find and replace. But maybe this second program is not needed - it is more for people who might look at it and go 'that is not standard spin'.
So feed in any program in the obex into this command line program and it outputs "block marked spin". It can't be that hard to write - the language rules are pretty simple. I reckon it could be less than a hundred lines of vb or C#.
As an afterthought, there are things that can be done with programs even in windows to make them more speech friendly, and anything I can offer in that arena to make any new environments work better with existing speech programs I'm certainly willing to do, as I'm sure there will be more of us eventually. (at least there will be if I have anything to say about it) I want folks to know they can build their own adaptive technology solutions, and not rely on those overpriced solutions that are currently available.
If I have my way, blind/disabled folks will be building their own solutions where possible and practical, and showing the companies that charge 1200 bucks for a talking note taker, that we can build our own without their assistance thank you very much, and can do so for a tenth the price.
I doubt it'll happen, but what the heck, it's worth a try.
And, come to think of it, I do have source rights to a windows screen reader, but unfortunately, I can't do anything with it at the moment, because I'm missing some libraries it uses, the most important of which is the dectalk development libs. Until recently, I was unable to track down who owned the rights and could sell a license. I bought the source rights from the brother of the guy who used to develop it when he died a few years ago. Without those libs though, which the code relies on heavily, the code has just sat here on my hd, collecting dust. I've made a few attempts to revive it, but the way it's written, it's really difficult to remove dependency on dectalk libs, and still have it work properly.
And, it doesn't help that C and C++ isn't one of my strongest language skills, and you can see why it's just hung there doing nothing.
Now, I can at least check to see what a new license would cost me, though I doubt I could afford it.
it used to be quite a hefty chunk of change, and I don't have the sale of a house to finance my purchase this time.