Shop OBEX P1 Docs P2 Docs Learn Events
Gold Standard Objects Up for Commission — Parallax Forums

Gold Standard Objects Up for Commission

Daniel HarrisDaniel Harris Posts: 207
edited 2012-06-21 15:07 in Propeller 1
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!
«1

Comments

  • frank freedmanfrank freedman Posts: 1,974
    edited 2012-01-24 20:13
    Should make this one sticky!!

    FF
  • Cluso99Cluso99 Posts: 18,066
    edited 2012-01-24 20:35
    Neat. The Gold Standard Specification is excellent. Not too many demands, but nice requirements for standard naming.

    Oh, and I forgot... even offering store credits too!
  • Daniel HarrisDaniel Harris Posts: 207
    edited 2012-01-25 09:18
    Thanks, Cluso! I respect your (and others) opinion here, and its good to hear that this is a nice medium of standards.
  • prof_brainoprof_braino Posts: 4,313
    edited 2012-01-25 09:25
    objects that are up for commission on the Gold Standard Commission page...to comply to the standards defined

    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.
  • ratronicratronic Posts: 1,451
    edited 2012-01-25 09:56
    The objects you want to convert to "Gold" I already consider "Golden".
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-25 10:02
    The Gold Standard specs look pretty good and easy to follow. I might have preferred no capitialization requirements applied to method names, though, but encourage Spin global variables to have an initial cap, and locals to be lower case. All caps for defined constants and all lower-case for keywords, including PASM operators, are good things and should be adhered to. At least for non-local method calls, the dot notation is an adequate cue that a symbol refers to a parameter-less method and not to a variable.

    One requirement I'd add is this:
    In Spin, one space between binary operators and operands (a + b), no spaces following prefix unary operators (||a), preceding postfilx unary operators (a++), or between a method name and the parenthesis beginning its argument list, and a space after every comma (Hex(value, n)). (Spaces optional in PASM.)

    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
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2012-01-25 10:29
    I agree with most of what Phil says there. Especially the requirement he'd add line and the global vars start with a capital, and locals start with a lowercase.

    The only thing I don't agree on with Phil is that I like the method naming camel case requirement.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-25 10:51
    Roy Eltham wrote:
    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:
    a := parameterless_method() + b
    

    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:
    dromedaryCamel
    BactrainCamel
    nocamel
    pseudo_camel

    -Phil
  • RaymanRayman Posts: 13,805
    edited 2012-01-25 11:19
    Personally, I think specifiying the capitalization is a little over the top...

    To me, what should be "gold" are things that work and are that well documented.
  • Heater.Heater. Posts: 21,230
    edited 2012-01-25 11:27
    What would be "gold" is if all objects that are predominatly PASM would have their PASM written in such a way it could be easily compiled and extracted as a binary blob for use with C and other languages.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-25 11:32
    Rayman wrote:
    Personally, I think specifiying the capitalization is a little over the top...
    I agree, except in the case of constants and keywords. The rest is simply a matter of individual style, subject to a little prodding to conform perhaps, but no big deal if you don't.

    -Phil
  • Jessica UelmenJessica Uelmen Posts: 490
    edited 2012-01-25 11:40
    Hey everyone,

    Thanks for you responses and feedback! I just wanted to address prof_braino's question real quick...
    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?

    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
  • Cluso99Cluso99 Posts: 18,066
    edited 2012-01-25 12:07
    Capitalisation is a personal matter of choice. I am happy to adhere to whatever is/has been decided.

    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.
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2012-01-25 12:17
    I agree with Ray, functionality and documentation trump impeccable form, albeit, adherence to a few common sense standards does make life easier when looking at new material.

    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.
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2012-01-25 12:44
    In terms of "gold functionality" in a single-port serial driver, I would nominate Phil's PBnJ.spin. It comes closest to perfect jitter-free timing. I probably learned the cmpsub trick for arbitrary buffer size from Phil.

    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.
  • Ron CzapalaRon Czapala Posts: 2,418
    edited 2012-01-25 12:57
    What about objects that use other objects that don't meet the Gold Standard?
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2012-01-25 14:14
    Phil, RE: Spin case insensitivity
    I'd like to change it. :) It wouldn't be that hard now. (and we could have an option to make it so you could compile older stuff that might fail).

    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.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-25 14:40
    Roy Eltham wrote:
    I think it would be a good thing to improve on things in Spin like this, ...
    'Better be careful about opening that door even a crack. There are some of us who would like to kick it in the rest of the way. :)

    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
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2012-01-25 14:51
    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
  • ratronicratronic Posts: 1,451
    edited 2012-01-25 14:52
    Ok I admit it, I am a lazy coder. I don't capitalize anything.
  • RossHRossH Posts: 5,336
    edited 2012-01-25 15:51
    Heater. wrote: »
    What would be "gold" is if all objects that are predominatly PASM would have their PASM written in such a way it could be easily compiled and extracted as a binary blob for use with C and other languages.

    You mean something like this?

    Ross.
  • Cluso99Cluso99 Posts: 18,066
    edited 2012-01-25 18:18
    Tracy: I second the change to FullDuplexSerial. I did a version that just put the buffer sizes into the CON section (FullDuplexSerial_rr004 in the obex) but your version is even better.

    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 Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-25 18:28
    Another change I'd like to see to objects like FullDuplexSerial: get rid of the conversion routines like dec, hex, and others of that ilk. There's too much duplication with every I/O object author thinking he has to include conversion routines. What's up with that? That's what SimpleNumbers and similar objects are for. Single-character I/O (with a common set of standardized names, yes!), str, and status-checking methods are enough.

    -Phil
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-01-25 18:30
    Cluso: I second your other point about standardizing the method names as it makes it easier to substitute an output device for instance if the output methods in this case are named the same and work the same. Also, rather than having multiple methods to handle special functions such as clearing the screen etc I much prefer identifying control or escape sequences in the output method.

    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!
  • simonlsimonl Posts: 866
    edited 2012-01-28 08:53
    I'm all for standardising on in(byte) and out(byte) across objects :)

    Peter: UNICOM - yes please ;)
  • MGreimMGreim Posts: 113
    edited 2012-01-29 11:00
    Hi,

    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
  • MGreimMGreim Posts: 113
    edited 2012-01-29 11:03
    and give us a long BREAK (10..100 clocks) and a parity bit also for 8 bit chars ...

    Markus
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-29 11:09
    MGreim wrote:
    BST is not case sensitive for the OBJ / file names, C++ SPIN is.
    Some OSes, like Linux, have case-sensitive filenames. Windows does not. You make an interesting observation. You might mention it in this thread, where it can be discussed more thoroughly:

    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
  • jazzedjazzed Posts: 11,803
    edited 2012-01-29 11:23
    Cluso99 wrote: »
    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.

    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.
  • RossHRossH Posts: 5,336
    edited 2012-01-29 16:39
    Some OSes, like Linux, have case-sensitive filenames. Windows does not. You make an interesting observation. You might mention it in this thread, where it can be discussed more thoroughly:
    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

    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.
Sign In or Register to comment.