[PD] Pduino: Call for testing

[Hans-Christoph Steiner]

On Mar 4, 2012, at 9:45 AM, Roman Haefeli wrote:

> On Sat, 2012-03-03 at 22:27 -0800, Hans-Christoph Steiner wrote:
> 
>> I would prefer that you use a different name unless you are interested
>> in providing strict compatibility with the current Pduino.
> 
> Yes, actually I'm interested.
> 
>>  Things like using namespace prefixes are one example of
>> compatibility that it sounds like you are not interested in, for
>> example. 
> 
> There is a conflict: Either it works only in Pd-extended setups, or you
> loose the advantage of using namespace prefixes. I solved that conflict
> by not using [makesymbol] at all.
> 
> Some words about that particular case:
> Actually [zexy/makesymbol] wasn't ever used in [arduino], only in
> arduino-help.pd . There it's used to display the Firmware version in a
> GOP cnv object -> [zexy/makesymbol firmata_%s.%s]. This can be safely
> replaced nowadays by [symbol firmata_$1.$2(. However, I didn't even use
> that, because I thought it would be useful to display the whole Firmata
> specification there, not only the protocol version. It now displays
> something like:
> 
> StandardFirmata 2 3
> 
> and it does so with only using vanilla classes. Let me point that
> [arduino] itself is not all affected by this.

Replacing [zexy/makesymbol] sounds like a good solution. I think that the [symbol Firmata_$1.$2( will produce the most readable version of this.  "StandardFirmata 2 3" is not super clear, especially to newbies.


>> Pduino deliberately uses namespace prefixes because that's currently
>> the only way to guarantee the correct object is being loaded. 
> 
> Agreed.
> 
>> Using [declare -lib zexy]  [makesymbol] does not currently guarantee
>> that (tho it should).
> 
> Yeah, I also agree that it should.
> 
> Please, tell me about your further constraints, if there are any, and
> I'll see how I can comply with them.

I can't think of any off the top of my head, but I am sure they exist.  The best approach for something like this, I think, is to try to make sure that the given output is exactly the same.  So if the [zexy/makesymbol] code produces "Firmata_2.3", the updated code should as well, unless the problem is specifically because the message is like "Firmata_2.3".

.hc


>> On Mar 3, 2012, at 6:47 AM, Roman Haefeli wrote:
>> 
>>> Hi Hans
>>> 
>>> On Fri, 2012-03-02 at 08:55 -0800, Hans-Christoph Steiner wrote:
>>>> I'm happy to see you working on this.  Since you are making a new
>>>> version, perhaps it makes sense to change the names.  Like maybe it
>>>> makes sense to change the object from [arduino] to [firmata]?  That's
>>>> something I thought about doing in the past.  This would also make it
>>>> easier for testers going forward because they could keep the old
>>>> Pduino installed and also use your new library.  I suppose then the
>>>> library would be called something besides Pduino too.
>>>> 
>>>> But if you want to keep those names, that's fine by me.
>>> 
>>> Actually, I prefer not to host a separate version/fork. I think the
>>> design of the protocol and its implementation in [arduino] is solid and
>>> I haven't messed at all with it. Our efforts for [arduino] were mainly
>>> focused on smallish issues with usability and portability. Our plans are
>>> to eventually push it into Debian as pd-arduino. For that goal, some
>>> changes like getting rid of name-spaced objects (for instance:
>>> [zexy/makesymbol], doesn't work in Debian with pd-zexy) and some other
>>> stuff were necessary. Plus, it got a bug fixed Ingo discovered a while
>>> ago. Still, the overall changes to [arduino] itself are rather smallish
>>> and I wouldn't expect any severe bugs. Also, I think we tested it quite
>>> well. 
>>> 
>>> The main effort, however, went into documentation and [arduino-gui] and
>>> to figure out the tiny details and differences between the several
>>> Firmata versions around in order to make the help-patch consistent as
>>> documentation and [arduino-gui] consistent in its behaviour.  I consider
>>> the updated help-patch a significant improvement (in that it covers all
>>> features of the firmware, is clear in which pin supports which mode,
>>> explains the differences in different firmware versions) and I wouldn't
>>> see a reason to keep to old one living. 
>>> 
>>> Personally, I'd much prefer not to host a separate fork and I am all for
>>> joining forces, not separating them. With your consent, I'd like to push
>>> the new version to the svn repository. We could wait to do so, until we
>>> got some positive reports from a few people, of course. There is really
>>> no hurry.  Also, I'd take responsibility for any issues and bugs related
>>> to Pduino (if that is what you want; I don't plan any 'hostile
>>> take-over'). 
>>> 
>>> Finally, if we eventually agree on merging our git Pduino with the
>>> official pd-svn/externals/hardware/arduino, I'd like to bump the Pduino
>>> version to the Firmata version. As I understand, [arduino] is a plain
>>> implementation of the Firmata protocol, not less, not more. I think it
>>> would make sense to reflect the version of the protocol it implements in
>>> its own version. We could still add a bug-fix number, so changes to
>>> [arduino] without switching the prococol version could be reflected.
>>> Something like 
>>> 
>>> 2.3.1
>>> | | |
>>> | | Pduino bugfix version
>>> | protocol minor version
>>> protocol major version
>>> 
>>> What do you think?
>>> 
>>> Roman
>>> 
>>> 
>> 
>> 
>> 
>> ----------------------------------------------------------------------------
>> 
>> "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."        -John Gilmore
>> 
>> 
> 
> 



----------------------------------------------------------------------------

                  ¡El pueblo unido jamás será vencido!