Gold Standard Objects Up for Commission
Daniel Harris
Posts: 207
Hello All,
I've posted some objects that are up for commission on the Gold Standard Commission page. This is an easy way for you to earn Parallax store credit - 50 bucks per object. If you are interested, all you have to do is update some of Parallax's existing Propeller Library objects to comply to the standards defined here: http://www.parallaxsemiconductor.com/support/goldstandard/specifications.
Visit the following link to see the available commissions:
http://www.parallaxsemiconductor.com/support/goldstandard/commission
Remember, submissions are on a first come first serve basis. There may be a race for the easy objects
.
Thanks!
I've posted some objects that are up for commission on the Gold Standard Commission page. This is an easy way for you to earn Parallax store credit - 50 bucks per object. If you are interested, all you have to do is update some of Parallax's existing Propeller Library objects to comply to the standards defined here: http://www.parallaxsemiconductor.com/support/goldstandard/specifications.
Visit the following link to see the available commissions:
http://www.parallaxsemiconductor.com/support/goldstandard/commission
Remember, submissions are on a first come first serve basis. There may be a race for the easy objects
.Thanks!
Comments
FF
Oh, and I forgot... even offering store credits too!
Sorry, process guy here, I gotta ask....
Is there going to be a (peer) review of the objects submitted? Otherwise, how do we know we agree the object comply? Or that the standard can be applied?
Also, each individual item in the "standard" that is to be applied and checked needs a unique serial number of other identifier so we can easily talk about whether or not an individual item is met correctly. Consider this a contribuation to the review of the "standard" itself.
$50 store credit means we're talking money now, so it rapidly becomes worthwhile to do it right.
One requirement I'd add is this:
I would also encourage redundant parentheses where Spin's precedence rules differ from those of other languages, like C, or where an operator is unique to Spin or rarely used. The most dog-eared page in my Prop manual is the precedence table.
Finally, I would discourage method names in an object from beginning with something common to all methods in the object. I'm referring to the floating-point objects, in particular, where all the public method names begin with "F". This is redundant when invoked externally. "f.add" conveys just as much information as "f.fadd" without the redundancy.
-Phil
The only thing I don't agree on with Phil is that I like the method naming camel case requirement.
It's a matter of taste, I guess. It's unfortunate that Spin doesn't allow something like this to disambiguate local method calls from variables for the casual reader:
In any event, I believe that variable and method capitalization rules in non-case-sensitive languages like Spin should be in the form of encouragement rather than requirement. Such standards are more important in case-sensitive languages, like Perl, where naming standards, if they exist at all, are routinely ignored in the CPAN modules. These cause all manner of inconvenience if you forget which modules use which standards:
BactrainCamel
nocamel
pseudo_camel
-Phil
To me, what should be "gold" are things that work and are that well documented.
-Phil
Thanks for you responses and feedback! I just wanted to address prof_braino's question real quick...
Yes! Every Gold Standard object will be reviewed by one of our FAE's for compliance. Nothing will be posted without their stamp of approval.
Cheers,
Jessica
I prefer and most always use redundant () because that way I don't have to remember various precedences, perhaps with the exception of + and -.
SPIN: Where a large complex expression is used for speed, expressions in the slower way as comments would be nice to be included to show what it is really doing
PASM: Where convoluted code has been used for speed, a non-convoluted pasm code as a comment would be nice (see my speed improvements to potatoheads VGA (or TV?) code).
I agree with heater that being able to use the pasm as a binary blob is to be encouraged. I think the specs help this.
But, as I said, the specs seem to form an excellent base. Not too restrictive, but standard use rules. Certainly as the FAE(s) review code they will no doubt form some more recommended or mandatory additions to the Gold Standard.
May I suggest that the Multiport Serial object would be an excellent serial driver to form the basis of a gold standard - note I have not seen the code to know if it complies. It is the functionality of up to 4 ports that makes this a nice driver. This might reduce the number of serial drivers present. IIRC, each port has to be initialised separately. I am not sure I like this idea - perhaps this could be discussed in another thread.
Can I comment about FullDuplexSerial? It was the first gold standard object and for almost a year now it has been embarrassingly lonely. It is essentially the same object that Chip wrote back in the dawn of cognition. In the meantime, many people reacted to the skimpy 16 byte rx and tx buffers by writing variations that increased those buffers and added a host of other features, many in spin, some in pasm, to expand functionality. Why can't FullDuplexSerial evolve as a gold standard object? Accordingly, I submit my own version 1.3. It makes only one change, to make the buffer sizes independent compile time constants, any number from 1 to 511.
Vetting these objects is going to be a big task for Parallax isn't it? The forums help immensely with that, a noisy environment, but effective. Personally I like to see links to relevant forum threads within the documentation of objects.
Within any one category, such as "serial ports", no one object is going to satisfy all requirements. There is room for one that does multiple ports with one cog, another that will do higher speeds or operate at lower power, options like flow control and parity, and a host of data processing and specialized functions. Within a gold obex, a meta-file becomes necessary to explain which file is most suited to which purpose.
I'd like to change it.
Also, it would be trivial to change it so parameter-less functions could/should have the (). Again with an option to disable for old code.
I think it would be a good thing to improve on things in Spin like this, especially given that Spin will have to be extended to support the Prop2. I think it would probably be a good idea to, as much as possible, "upgrade" spin for the Prop1 to be as close to Spin for the Prop2. Of course, I'm only talking about the compiler side of things, it'll all boil down to the same bytecode that runs with the same in rom interpreter on the Prop1.
I'm torn on the case sensitivity issue. What I would really like to see, I guess, is an IDE that makes global changes to the case as you type, the way QuickBASIC did. It was nominally case-insensitive, but it enforced case coherence via the editor. For beginning programmers, recognizing a distinction between i and I may be too much to ask.
I'd definitely be in favor of making the () optional for parameterless method calls. I wouldn't use a mode where it was mandatory, though, since there are times that the extra parens are just clutter. It's good to be able to mix usages, I think. Again, a good editor can come to the rescue and color-code method calls to distinguish them from variables.
If you're open to other ideas for extending the language in an interpreter-compatible way, I'm more than happy to provide them! The absolute biggest one on my list is a way to specify subdirectories in the OBJ section, the lack of which has irked me no end for five years.
We should probably start another thread for this, though, and let Daniel have his back.
-Phil
One of the reasons I personally signed on to the task of converting the x86 code over to C/C++ was so that it would be possible to open the door to enhancements and changes. Right up there near the top of my list is making OBJ section references work more like #include in C/C++ (and others), so you can specify partial (relative) or full paths, it's pretty trivial to support in the C/C++ version.
Obviously, I will be working with Parallax on their requests first in this regard, but my plan is to do what I can to add the features we all want.
Anyway, we should start a different thread (or move over to my thread about the C/C++ compiler), since this is trailing off topic.
Roy
You mean something like this?
Ross.
This brings me to another point. The differences between the standard interfaces like FDX, VGA, TV, Keyboard. They all use different calls for the same thing making substitution of the objects inpossible. Take .tx .out for starters. Why not standardise on xxx.out(byte) for outputting a char/byte and xxx.in(byte) for input? At least we have xxx.dec() and xxx.hex() the same.
At least in FDX add in a PUB out(byte) that just calls tx(byte) so that we can shift easily.
Roy: I am pleased you are intending to expand spin as you have suggested. Looking forward to the new thread.
-Phil
As for a serial object I do have very many but I confess that I have never really tidied any of them up enough for the OBEX, let alone the "GOLDEN OBEX". I have serial objects where the buffers can be dynamically allocated (at run-time) given a buffer address to use. They also handle XON/XOFF handshaking, RS485 etc. Push me hard somebody I will spend some time on it to clean them up, maybe even finish off my UNICOM as a complete and "golden" object.
ratronic: You did capitalize your statement that said that you do not capitalize anything!
Peter: UNICOM - yes please
things are not so pretty trivial i fear ;-)
Yesterday i tested the new C++ based compiler against BST und Linux.
And what happens in OBJ section?
BST is not case sensitive for the OBJ / file names, C++ SPIN is.
Markus
Markus
I often get lazy and just type "fullduplexserial", for example. But I guess that should probably be deprecated, since it's not portable across platforms.
-Phil
Please standardize this
Also, having TV or VGA xxx.in that does nothing would make it much easier to just interchange TV and FDX regardless of keyboard stuff - seems to me that was part of cluso's point too, but maybe not obvious. One could add a wrapper object, but that eats bytes.
Yes, I run into this all the time (anyone who uses Linux as well as Windows probably has the same problem). My current solution is to always try compiling on Linux, which enforces the use of the proper case (in which case it will work on both).
But sometimes I forget
Ross.