1.5 Lib: Goals

[Cristian Maglie]

Hi,

as requested, here a list of the goals that the 1.5 library specification aims to solve.

1) hardware dependencies: there should be some metadata that tells the user if the library can compile successfully on his board or not.

This goal is due to the increasing number of people asking "why this library doesn't compile on my XXXXX-NON-AVR Board?"

The specification started with the "architecture" field only, without going in deeper detail. This is not a complete solution: we've seen, also from your comments, that it can't completely solve the problem but, at least, its preparatory to let people understand that a library made for "AVR" (Uno) will not run on "SAM" (Due), or "KINETIS" (Teensy). It's a raw categorization, but its simple to understand and its what we tried to achieve.

BTW I'm really happy to see other proposal discussed:

from Bill: "arch/cpu/board" selection

from Paul: "arch/features/requires" or simply "features/requires"

Every proposal has its pro and cons, and choosing one is very difficult, I'm looking with interest every proposal, I have a no final answer ATM, and I would like to see other opinions as well.

2) library dependencies: add some metadata to allow automatic dependencies resolution and avoid the user need to #include every dependency manually on the sketch.

* This is not yet implemented on the IDE.

And probably the metadata needs some refinements.

3) core dependencies: something similar to library dependencies, but this time on the cores.

* Also this one is not yet implemented on the IDE.

Same here: the metadata needs some refinements.

Bill already proposed: instead of "core" use "mantainer/core"

4) put some metadata about the library: name, author, description, etc. to be used by a future library manager GUI.

5) solve some of the weirdness of the 1.0 library format

some of the following was requested many times from 3rd party libraries developers:

- recursive subfolder compile: with 1.0 you can't use subfolders to organize your source code, with 1.5 yes

- "utility" folder treated in special way: I guess this anomaly was introduced to partly solve the missing recursive subfolder compile, the 1.5 remove this anomaly

- Source code mixed with everything else: with the 1.0 the source code is mixed with everything, with the 1.5 the source code is moved in its own "src" folder. This makes possible to add recursive compile and remove the "utility" folder but it makes the 1.5 format incompatible with 1.0.

- Add the "arch" folder facility.

Again this doesn't add any "new" feature from the 1.0, it aims only to increase code readability and to reduce maintenance efforts (to library developers, not tool mantainer). Since its an 1.0 incompatible format, it seemed nice to have it.

- Put everything in their place: if you read carefully the specification you can notice that everything has its place (documentation, example, extras, source code) the specification is made to be extendable, so in the future we can release a 1.6 library spec. with, say, schematics, photos, and whatever else we want, without being incompatible with previous versions.

If we want to keep 1.0 compatibilty we will lose *all* this benefits. Again, I didn't have a final answer here, I understand Bill concerns about compatibilty, and avenue33 and jantje about "arch" library, and would like to see as much opinions as possible. I've no problem to move back to an 1.0 compatible library

C

[Paul Stoffregen]

While you were writing about the goals, I was writing about compatibility!  ;-)

If we want to keep 1.0 compatibilty we will lose *all* this benefits.

Who actually benefits from these benefits?

Is helping library authors worthwhile if it comes with a cost of compatibility troubles for end users?


1.0 compatibility does not need to sacrifice *all* of the benefits, only some.  Metadata needed for a future library manager can be provided in library.properties, which is ignored by 1.0.  Compatibility checking can still be implemented based on metadata.  I still have concerns about impact on end user participation, as well as the technical details to make such checks effective, but it certainly should be possible to do in a compatible way.

Much of the need for separate architecture code can lessened by additions to the Arduino API.  I can help with this.  I have personally ported dozens of libraries to Teensy.  If fact, many libraries that currently work on Leonardo are the result of my patches for Teensy 2.0, as in many (Firmata, IRremote, OneWire, etc) I've added compatibility layers that made Uno-only libraries compatible with a wide range of boards.  In the process I've built test hardware for a good portion of the widely used 3rd party Arduino libraries.

I've seen several common issue where an API can allow libraries to become architecture independent.  The recent digitalPinToInterrupt macro (and/or attachInterruptToPin) is just one example which allows 4 widely used libraries to become architecture independent, or at least replace a big chunk of special #ifdef code with an API.

I can identify more of these, just like I did weeks ago with digitalPinToInterrupt.  But honestly Cristian, proposing even very simple and obvious APIs like digitalPinToInterrupt is a LOT of work on this mail list.  For example, there seemed to be consensus on digitalPinToInterrupt, but perhaps not digitalPinToInterrupt, after *much* discussion.  Has digitalPinToInterrupt been merged, it is sitting unused in a pull request?

There are many more of these API opportunities to improve compatibility.  When they're preprocessor macros, it's easy for library authors to test if they're defined.  Long term, I believe everybody will benefit if we collectively invest our engineering effort to reduce the need for architecture-specific code, at least where we can.

Library authors already strive for compatibility.  We can also do much better at providing library authors automatically defined preprocessor symbols, for things like the vendor, board and variant, for the cases where that information really is needed.  It would be nice to provide library authors with a beautiful format, but is optimizing for the experienced users who publish libraries really worthwhile if it comes at a cost to novice users who have no means to resolve errors when they use those libraries?!

[avenue33]

Now we have a 4th thread on 1.5. Just insane.

[Matthijs Kooijman]

Hey Paul & others,

I'll try to keep this post to the subject and talk about the goals we
want to achieve, and to refrain from proposing actual implementations,
since it seems the discussion on implementation needs better defined
goals first.

With regard to the 5 goals Christian posted, those all look sane to me.
I don't have any other goals to add. However, I think we might need to
add two semi-goals (or "conditions", not sure what the proper English
term would be):
- Compatibility with older libraries and IDEs
- Compatibility with 3rd party building tools

Paul already commented on the first, to which I'll respond below, on the
forum the second was mostly discussed.

> >If we want to keep 1.0 compatibilty we will lose *all* this benefits.
>
> Who actually benefits from these benefits?

Christian wrote: "some of the following was requested many times from
3rd party libraries developers", so I guess library writers.

By extension, end users would also benefit (note that I'm not saying
that the benefits outweigh the costs wrt compatibility and whatnot, I'm
just saying that happy library developers at least are positive for end
users as well to some degree).

> Is helping library authors worthwhile if it comes with a cost of
> compatibility troubles for end users?

I'd have to say yes, but we have to be very careful about _how big_ a
cost this is. I think we can all agree that making the transition as
painless as possible is also a goal.

Regarding compatibility, I think we should remember that there are two
faces to this:
1. Allowing "1.0 libraries" to work on the 1.5 IDE
2. Allowing "1.5 libraries" to work on the 1.0 IDE

Allowing "1.0 libraries" to work on the 1.5 IDE is the easier one of the
two and, IMHO, the more important one. This compatibility allows users
that upgrade to 1.5 to still use all libraries out there.

Allowing "1.5 libraries" to work on the 1.0 IDE is harder to implement
wrt goal 5 Christian listed ("solve some of the weirdness of the 1.0
library format"), since that goal _is_ to move files around. Also, I
consider this the less important of the two, since it is generally easy
for end users to simply use the latest stable IDE version (and 1.5 is
intended to become the stable version soon, AFAIU).

I realize that things are not so easy for users of third-party hardware,
who often use a forked IDE version, so this second kind of compatibility
is certainly not something to ignore.

On the bright side, I don't think that goals 1-4 as stated by Christian
cause problems wrt compatibility (other than that users of 1.0 should
pay a bit more attention and figure out dependencies and requirements
themselves, just like currently).

> Much of the need for separate architecture code can lessened by
> additions to the Arduino API.

I wholeheartedly agree to this! If enough engineering effort is applied,
a proper API would solve a lot of the architecture-specific stuff.

However, realistically I fear that we'll continue to have some
architecture specific code. Sometimes perhaps to increase performance,
even when a proper API exists (which can then be used as a fallback).

I suspect you bring this up as an argument to drop the arch/ subfolders?
I'd say that given this argument, the arch/ subfolders shouldn't be an
essential goal, but I don't think it invalidates them as goal
completely: They'll still prove useful for some libraries (though I
can't properly estimate how many that'll be).

Gr.

Matthijs

[Matthew Ford]

<warning rant follows>
Sod the compatibility!!
Lets get a good design that will continue to work in the future. 
IMHO the library authors are the future of Arduino.
The more difficult it is for them to keep up to date with the fast changing board hardware and addons the less relevant Arduino will become.

Once there is a design that appears to provide long term support and growth for the project, then we can consider the compatibility problem.

One compatibility assistance may be to proved a translation program, either aimed at the library developers or at the users, depending on what needs to be done.
The translation program should provide the heavy lifting, if not it does not provide whole solution.

matthew

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Matthijs Kooijman]

Hi Christian & others,

last night, I realized another potential goal: separation of public and
private APIs.

A library will declare a number of functions and classes. Some of these
are intended to be used from within a sketch and constitute the public
API. Others, are only used within the library itself (and shouldn't be
used from the sketch) and thus form a private (or internal) API.

The most obvious way to handle this separation is to just note in the
documentation for each class or function wether it is a public or
private API. Putting all the public API in one .h file and all private
API in another is also sensible. Neither of these require any tool
support.

However, we might also want to _ensure_ that the private API cannot be
used from a Sketch. The most obvious way to do this is by putting the
private API .h files in a directory that is not on the include path.

The current 1.0 libraries already partly implement this with their
"utility" folders. AFAIU, these folders are somewhat intended to contain
some private code that is used from the main library code, but never
from the sketch directly (I think you can still circumvent this by
putthing "#include <utility/foo.h>" in your sketch, though).


So, I'm just saying this is a _potential_ usecase, that needs something
in the library layout if we want to support it properly.

The question is, does this look like something we should provide support
for? My personal feeling says it's not very important. The alternative
of making the separation in documentation or even convention (a library
named "Foo" contains a single "Foo.h" file with all the public API, all
other files should not normally be included, for example) seems
sufficient.

Any other views?

Gr.

Matthijs

[Pekka Nikander]

Jumping in from the outside, as a relative newcomer to the Arduino-ecosystem, please forgive me if I'm suggesting something obvious. Anyway, I think it might be useful to make a difference between

a) existing libraries, and
b) new libraries

Of course, you can also make the division in some other way, like "old libraries not updated any more" and "actively maintained or new libraries"; the exact division is not that important.

My point is that for some libraries backwards compatibility will be important, as they are unlikely to get updated to the new format, or if they are, the update may be done by some third party, perhaps not understanding properly what is going on in the library nor with different boards. Keeping these as useful as possible for a long time to come obviously requires backwards compatibility and probably jumping some hoops.

Now, considering the other libraries, i.e. new ones or actively maintained ones, I surmise a high-quality template might be more important for them than the actual new library format.

If I were to write an Arduino library, I would most probably only have couple of different MCU-boards (at most), with which I could test my stuff. For all the other MCU-boards, good examples (in a form of a template) would make my life much easier. Without them I most probably would not even try to include support for any other platforms/architectures than those in my disposal.

Hence, once the goals have somehow been settled, at least a little, it might be more useful to first write a library template rather than first arguing about the details of what the library format. Such a template should include examples for the most often used functionalities in libraries, such as fast GPIO access, using timers, interrupt handlers, continuous or timer-triggered ADC reading, etc.

From the software patterns movement point of view, extracting and writing down such examples would be pattern mining. That is, looking at existing library code, identifying what is common between them, and then extracting the common aspects into models of how to build similar functionality in the future.

In the longer term, this would probably also form a gradual bases for more advanced APIs than the current Wiring-based ones, but first having library writers to use them (as examples or whatever) and only later releasing them to the wider public might allow them to organically evolve and stabilise.

I would be interested in trying to write a few such examples for AVR and STM32, just to get a feeling of the feasibility of such an idea. Maybe someone (like Paul) could point out to a few patterns within the existing libraries, even preferably to patterns where two distinct libraries solve an essentially similar problem.

So, in summary, I'm afraid that without a high-quality and well maintained library example that future library writers can use as their starting point, the prevailing problems with library compatibility will continue for a long time. On the other hand, if such an example is good enough, it might even be easier for old libraries to migrate to the new format through the example than trying to be directly modified.

--Pekka

[Paul Stoffregen]

On 10/31/2013 03:23 AM, Matthijs Kooijman wrote:
> However, we might also want to _ensure_ that the private API cannot be
> used from a Sketch. The most obvious way to do this is by putting the
> private API .h files in a directory that is not on the include path.

Private APIs are already well supported and widely used by most
libraries with C++ "public", "protected" and "private".

For example, look at Wire.h. Functons onRequestService(),
onReceiveService() and others under "private:" are Wire's private API.
Functions under "public:", begin(), beginTransmission(), write(), etc
are the public API. If you try to use the private API from a sketch,
you'll get a compiler error.

> So, I'm just saying this is a _potential_ usecase, that needs something
> in the library layout if we want to support it properly.

Please, I beg of you to make compatibility a primary goal. I'm sure you
have good intentions. Please, when you think "support it properly", I
hope you'll consider making trouble-free end user experience. Arduino's
primary value proposition is ease of use. Any incompatibilities will
deteriorate Arduino's value. Please, please, tread carefully.

[Cristian Maglie]

In data mercoledì 30 ottobre 2013 12:03:46, Paul Stoffregen ha scritto:
> Much of the need for separate architecture code can lessened by
> additions to the Arduino API. I can help with this. I have personally
> ported dozens of libraries to Teensy. If fact, many libraries that
> currently work on Leonardo are the result of my patches for Teensy 2.0,
> as in many (Firmata, IRremote, OneWire, etc) I've added compatibility
> layers that made Uno-only libraries compatible with a wide range of
> boards. In the process I've built test hardware for a good portion of
> the widely used 3rd party Arduino libraries.

I totally agree that extending the "variant" API would simplify portability.
I'm in favor of adding as any new "variant" as you can point out, never said
the contrary :-)

This is surey an argument that makes me think about the "arch" folder, but let
me check with the VirtualWire example you posted, and I'll give you some more
insight on my thought.

> I can identify more of these, just like I did weeks ago with
> digitalPinToInterrupt. But honestly Cristian, proposing even very
> simple and obvious APIs like digitalPinToInterrupt is a LOT of work on
> this mail list. For example, there seemed to be consensus on
> digitalPinToInterrupt, but perhaps not digitalPinToInterrupt, after
> *much* discussion. Has digitalPinToInterrupt been merged, it is sitting
> unused in a pull request?

digitalPinToInterrupt has been merged, instead the helper funcion that replace
the attachInterrupt with attachInterruptToPin was not.
I probably will close the pull request this way (or maybe keep it on hold for
the future 2.0 API).

C

[Cristian Maglie]

In data giovedì 31 ottobre 2013 12:38:07, Cristian Maglie ha scritto:
> digitalPinToInterrupt has been merged, instead the helper funcion that
> replace the attachInterrupt with attachInterruptToPin was not.
> I probably will close the pull request this way (or maybe keep it on hold
> for the future 2.0 API).

ARGH, just looked at the pull request and it was not merged, sorry about that.
I'm going to fix that ASAP.

C

[Matthijs Kooijman]

Hi Paul,

On Thu, Oct 31, 2013 at 04:31:37AM -0700, Paul Stoffregen wrote:
> On 10/31/2013 03:23 AM, Matthijs Kooijman wrote:
> >However, we might also want to _ensure_ that the private API cannot be
> >used from a Sketch. The most obvious way to do this is by putting the
> >private API .h files in a directory that is not on the include path.
>
> Private APIs are already well supported and widely used by most
> libraries with C++ "public", "protected" and "private".

That is true only for C++ code. Looking at the Wire library, most of the
private API is C functions inside twi.h / twi.c. So _if_ we want to
provide full support for private APIs, something from the IDE and/or
library layout is needed as well, I think.

> >So, I'm just saying this is a _potential_ usecase, that needs something
> >in the library layout if we want to support it properly.
>
> Please, I beg of you to make compatibility a primary goal. I'm sure
> you have good intentions.

I realize that compatibility is important and we should keep it in mind
when deciding on an implementation for a specific goal. I didn't discuss
compatibility in my mail about public/private API because I just wanted
to discuss if public/private API support should be a goal or not. If it
turns out that all possible implementations have too high of a
compatibility cost, we can conclude that the goal cannot be satisfied
later.

Gr.

Matthijs

[Matthijs Kooijman]

Hey folks,

> I don't have any other goals to add. However, I think we might need to
> add two semi-goals (or "conditions", not sure what the proper English
> term would be):
> - Compatibility with older libraries and IDEs
> - Compatibility with 3rd party building tools

Just a bit of clarification what I meant here. I said "semi-goals" and
"conditions", but that doesn't mean I think they are any less important.

In fact, I mean that these "conditions" need to be kept in mind with
_every_ decision we make wrt the new library layout. Whenever we propose
an implementation of one of the goals, we should (probably explicitly)
consider what the consequences wrt to compatibility are.

Looking at these conditions like this makes them conceptually different
from the other goals, which is why I named them differently :-)

Gr.

Matthijs

[Bill Perry]

So while I think this discussion of "Goals" is great and what
I was trying to get everyone to focus on, I think by just using
the term "Goals" it is fully missing my point.
The reasoning is,
because if all you have is "goals" then nothing is actually required.

What is needed is a set of REQUIREMENTS, FUTURE-REQUIREMENTS,
GOALS, and NON-GOALS.
Requirements are things that absolutely must be done/supported.
Goals are things that are desirable and are striven for but are not required.

So for example requirements might be:
- The implementation shall allow the use of a 1.0 library "as is".
- The implementation shall have the ability to specify its needed processor architecture.

An example of a future requirement might be:
- The implementation shall have the ability to specify other library dependencies.

An example of a goal might be:
- The implementation shall allow the ability to specify supported boards.


An example of a non-Goal might be:
- It is not a goal to allow implementing libraries being able to be used on implementation IDEs.


Once you start to break things down in terms of requirements, future requirements,
goals, and non-goals and perhaps even ranked goals,
then the discussion becomes much easier.
People can focus on what is important and argue that their needed/desired feature/capability
is a requirement vs future requirement, vs a goal.
Things can be moved between categories and prioritized until consensus is reached.

And also by having a set of requirements, future requirements, and ranked goals, it can become much
easier to evaluate proposed solutions.
You can simply go down the check list and see how each proposal stacks up against
the requirements & goals and ensure that it handles all the requirements, can be extended
to support the future requirements, and how many of the goals it addresses.

And then when it is time for implementation, the list of requirements
makes a great set of test vectors to ensure the implementation is compliant.

This is the type of conversation that I think needs to happen before we start moving
down actual implementation discussion.

And again, I will say from my perspective, I don't think that everyone is on the same
page about the requirements, and future requirements of this much
less the goals.
Everyone seems to be so quick about jumping to actual implementations before
there is even any agreement on what is required.

--- bill

[Bill Perry]

> An example of a non-Goal might be:
> - It is not a goal to allow implementing libraries being able to be used on implementation IDEs.
>
>

oops.
I meant to say:

> It is not a goal to allow implementing libraries being able to be used on implementation IDEs.

In other words, the implementation does not require that libraries that use the new implementation
still can operate on 1.x IDEs.

--- bill

[Cristian Maglie]

Bill, I changed the specification as you suggested, but I'm not sure if I've done it correctly. Feel free to change or add. When I say "GUI" I mean a future Library Manager GUI that will help the user to manage libraries: download, search & install from a repository, etc.

[done] means that the requirement is currently implemented.

general requirements

REQUIREMENT: There must be a file that contains all the metadata. The metadata field is the same on the current 1.5 specification [done]

The metadata information will be used in a GUI. For example, a user may search through "descriptions" to easily find a library suitable for his project.

REQUIREMENT: Backward compatibility, IDE >=1.5.0 must support 1.0 libraries [done]

REQUIREMENT: Forward compatibility: 1.0.x IDEs must work with 1.5 libraries

hardware dependencies

REQUIREMENT: There must be metadata to determine if the library can compile successfully on a selected board. The IDE will show only the libraries that compiles on the user's target board. [done, architecture only]

REQUIREMENT: The metadata must be designed to not be "exclusive": users must not be blocked, by a too strict dependency check, to do a legitimate operation. (for example specifing that a library works only with board "A" but the user has a board "B" that is compatible).

library dependencies:

FUTURE-REQUIREMENT: There must be metadata to allow automatic dependencies resolution, i.e. to determine a list of libraries needed by the current library to work properly. This metadata may be used by the GUI to download and install missing dependencies.

FUTURE-REQUIREMENT: The IDE will use the metadata to automatically #include every dependency in the sketch (and avoid this task to the user).

core dependencies:

FUTURE-REQUIREMENT: There must be metadata to allow automatic core-dependencies resolution, i.e. to determine if a library may work with the core used on the user's target board. Will be used in the IDE to show only the libraries that works on the user's target board.

FUTURE-REQUIREMENT: The metadata must be designed to not be "exclusive": users must not be blocked, by a too strict dependency check, to do a legitimate operation. (for example specifing that a library works only with core "A" but the user has a board using a core "B" that is compatible with "A").

solve the weirdness of the 1.0 library format

Since we have the chance to change the library structure, I think it is the right time to also make a proper format that support some of the most requested features:

GOAL: Design the specification in a way that is easily extendable in the future [done]

GOAL: Allow recursive subfolders compile [done]

GOAL: Remove "utility" folder anomaly [done]

GOAL: Source code not mixed with everything else [done]

and also to add facilities that help library authors to write better libraries:

GOAL: Add "arch" folder facility [done]

C

[Peter Feerick]

Cristian,

For the library and architecture dependencies, where you state:

> The metadata must be designed to not be "exclusive":

Wouldn't this be implemented simply as a warning when you try to use/compile a library that the metadata doesn't state is supported by the core/architecture? Just checking my understanding of this.

Cheers,,
Pete

[Peter Feerick]

* Sorry for the multiple posts - just keeping to the threads *

Firstly, my sincere thanks to Cristian for all the hard work he is putting into this, and for providing a clear set of specifications for discussion. 

If the API improves and continues masking architecture differences, surely libraries will need less and less mcu / architecture specific code  (except in the case of highly optimized thus advanced libraries / code), and thus arch folder are not really needed? Whilst they seem nice and make things tidy, I don't feel that it helps in making changes across architectures, and make more files to work with. #ifdefs for different mcus / archs I can deal with, if the code is formatted properly... but having to dig through a rats nest of files in arch folders... :yuck:

I like have is the metadata that allows for a GUI manager to help sort / find / download / update libraries. And removal of some of the 1.0 weirdness like 'utility' is good too :). 

I also like the automatic inclusion / dependency checking - much better to be able to tell a user that xyz library is needed instead of a cryptic compiler message. And the sub-directory recursion makes organising code much easier :)

-Pete

Peter Feerick
BIT, BLDes CQU

0413 431 284

174 Cummins Rd
Bundaberg Q 4670

peter....@gmail.com
peter....@cqumail.com

[Cristian Maglie]

Yup this solution implement the requirement but, since you still need to build
the sketch to verify if its compatible, it doesn't add any value to have it.

The requirement may be rephrased to loosen the check in a way similar to what
suggested by Matthijs (side note: thanks for all your contributions!),
something like:

"Filter the library only when it is 100% sure that the library won't
compile/work on the target".

But also this one hides some hicckups, for example consider a library written
using AVR-specific registers: you may be convinced that the library would work
with only on AVR, but that's not true, it may works also on Teensy 3 because
Paul has made some "emulation" layers that make it work also on Kinetis (with
some limitations of course).

The "non-exclusivity" requirement is the most challenging in this specification
and I have the feeling that finding a good solution is not as easy as it seemed
at a first sight.

C

[Matthijs Kooijman]

Hey Christian,

> REQUIREMENT: Forward compatibility: 1.0.x IDEs must work with 1.5 libraries

I'd argue that this is too strict a requirement, since AFAICS it
directly conflicts with most of the goals below.

With the risk of nudging towards the implmentation I previously
suggested, perhaps relax this to:

REQUIREMENT: Allow 1.5 libraries to work with 1.0.x IDEs, if the library
author wants.

> REQUIREMENT: There must be a file that contains all the metadata. The metadata
> field is the same on the current 1.5 specification [done]

Would do you mean with the second sentence here? That anything we decide
on must be compatible with the metadata already implemented in the 1.5
betas? Or something else?

> REQUIREMENT: There must be metadata to determine if the library can compile
> successfully on a selected board. The IDE will show only the libraries that
> compiles on the user's target board. [done, architecture only]
>
> REQUIREMENT: The metadata must be designed to not be "exclusive": users must
> not be blocked, by a too strict dependency check, to do a legitimate
> operation. (for example specifing that a library works only with board "A" but
> the user has a board "B" that is compatible).

Perhaps reword these a bit more generically?

REQUIREMENT: There must be metadata that allows the IDE to provide
guidance to the user as to wether a given library will work on a given
board and when multiple implementations of the same library are
available, help the user choose one.

REQUIREMENT: This metadata should be designed to encourage library
authors to take a optimistic approach: Better to specify that a library
might work / works on board when it doesn't, then to specify it does not
work while it does.

> FUTURE-REQUIREMENT: The IDE will use the metadata to automatically #include
> every dependency in the sketch (and avoid this task to the user).

Just a technicality: it shouldn't be needed to #include those libraries
in the main sketch, but it should link against the library in the link
step.

> core dependencies:
>
> FUTURE-REQUIREMENT: There must be metadata to allow automatic core-
> dependencies resolution, i.e. to determine if a library may work with the core
> used on the user's target board. Will be used in the IDE to show only the
> libraries that works on the user's target board.
>
> FUTURE-REQUIREMENT: The metadata must be designed to not be "exclusive": users
> must not be blocked, by a too strict dependency check, to do a legitimate
> operation. (for example specifing that a library works only with core "A" but
> the user has a board using a core "B" that is compatible with "A").

Aren't these really just a part of the hardware dependencies? Since a
given board uses a given core, the question remains "will this library
work on this board?". On the other hand, a library might of course not
care about what hardware is used exactly, as long as a specific (version
of) a core is used. Any actual proposal for new library layout could
still choose to implement the hardware and core requirements using a
single mechanism, so keeping the goals separate.

Also, I like that fact that you say "using a core B that is compatible
with A", since that suggests an obvious implementation change for the
platform.txt (or perhaps somewhere else): It should be able to declare
that a given core is compatible with another core. In practice, this
will allow third-parties to use a core name of their own and declare it
is compatible with the arduino 1.5.4 core, instead of having everybody
just reuse the "arduino" core name so libraries will at least work with
their core (which would reduce the value of core dependencies to 0...).

> GOAL: Allow recursive subfolders compile [done]
> GOAL: Remove "utility" folder anomaly [done]
> GOAL: Source code not mixed with everything else [done]

As suggested above, these goals might need to be opt-in for a library
author to prevent conflicts with the 1.0.x IDE compatability. For that
reason, perhaps rephrase the last goal as:

GOAL: Allow separating source code from everything else [done]

Gr.

Matthijs

[Paul Stoffregen]

On 11/04/2013 12:57 AM, Matthijs Kooijman wrote:
> Hey Christian,
>
>> REQUIREMENT: Forward compatibility: 1.0.x IDEs must work with 1.5 libraries
> I'd argue that this is too strict a requirement, since AFAICS it
> directly conflicts with most of the goals below.

I hope this requirement is NOT relaxed.

Ease of use for end users is Arduino's most valuable feature, the very
reason Arduino is successful.

Increasing IDE's library capability will indirectly benefit end users,
but it's a terrible trade-off if it comes at the cost of end user
compatibility problems. Anything that does not "just work" diminishes
Arduino's main value.

> With the risk of nudging towards the implmentation I previously
> suggested, perhaps relax this to:
>
> REQUIREMENT: Allow 1.5 libraries to work with 1.0.x IDEs, if the library
> author wants.

NO!!!! We've been down this path before: pushing responsibility to
library authors. It does not end well.


If this requirement is relaxed, I believe the very minimum should be:

REQUIREMENT: Forward compatibility: IDE 1.0.6+ must work with 1.5 libraries


This isn't as good as supporting 1.0.5 and earlier, but it would
mitigate most of the pain if 1.0.6 is released long before many 3rd
parties start using the new format.

[Matthijs Kooijman]

Hey Paul,

On Mon, Nov 04, 2013 at 03:15:56AM -0800, Paul Stoffregen wrote:
> On 11/04/2013 12:57 AM, Matthijs Kooijman wrote:
> >Hey Christian,
> >
> >>REQUIREMENT: Forward compatibility: 1.0.x IDEs must work with 1.5 libraries
> >I'd argue that this is too strict a requirement, since AFAICS it
> >directly conflicts with most of the goals below.
>
> I hope this requirement is NOT relaxed.

Not relaxing them means the layout-related goals (recursive subdirectory
compilation, source outside of the library root, no special handling of
the utility folder) cannot be satisfied. Does this mean you do not think
those are useful goals, or do you think compatibility is important
enough to stick to the old layout forever?

The reason that I propose relaxing this requirement is not that I think
compatibility is not important, but I'd like to improve the layout to
something I consider a better layout and this strict requirement
prevents that.

> >With the risk of nudging towards the implmentation I previously
> >suggested, perhaps relax this to:
> >
> >REQUIREMENT: Allow 1.5 libraries to work with 1.0.x IDEs, if the library
> >author wants.
>
> NO!!!! We've been down this path before: pushing responsibility to
> library authors. It does not end well.

Can you elaborate? I'd say that if we allow library authors to make this
choice, then initially a lot of libraries can still use the old layout
for compatibility (since library authors benefit from maximum exposure
as well) . Later, when more and more users and 3rd parties switch to
1.5, I'd expect more authors to switch to the new layout, since there
isn't much of a userbase for the old layout anymore. The Arduino team
can probably direct this a bit by providing proper recommendations in
the library documentation (initiallly recommend the old layout and later
switch to recommending the new layout).

Doing it like this makes sure that:
- Libraries can start using the 1.5 specification right away, with the
old layout.
- When they later switch to the new layout, all (stable) 1.5 IDE
versions know about the new layout already.

> If this requirement is relaxed, I believe the very minimum should be:
>
> REQUIREMENT: Forward compatibility: IDE 1.0.6+ must work with 1.5 libraries
>
>
> This isn't as good as supporting 1.0.5 and earlier, but it would
> mitigate most of the pain if 1.0.6 is released long before many 3rd
> parties start using the new format.

This sounds like a fine alternative to me. Adding some extra code to
1.0.6 to make it compatible with the new format should be fairly easy
(especially since it doesn't have to actually read the metadata, for
example, just understand the new layout).

Perhaps we could even combine the two: Have 1.0.6 support the 1.5 layout,
and allow library authors to use 1.5 style libaries with the 1.0 layout.
This would maximize compatibility now and allows migrating to the
improved layout later.

To get back from implementation to requirements again, this would mean
there will be two separate requirements:

REQUIREMENT: All 1.5 libraries must work with IDE 1.0.6 and above.

REQUIREMENT: 1.5 libraries must work with IDE 1.0.5 and below, if the
library author opts to use the older layout.

Does this sound acceptable?

Gr.

Matthijs

[Jan Baeyens]

On 04-Nov-13 13:27, Matthijs Kooijman wrote:
> REQUIREMENT: All 1.5 libraries must work with IDE 1.0.6 and above.
>
> REQUIREMENT: 1.5 libraries must work with IDE 1.0.5 and below, if the
> library author opts to use the older layout.

Regardless whether this is a good requirement or not I feel "must work"
is not explicit enough. Maybe
must work = must produce runnable code
is better.

> REQUIREMENT: There must be a file that contains all the metadata. The
> metadata field is the same on the current 1.5 specification [done]
>

> The metadata information will be used in a GUI. For example, a user
> may search through "descriptions" to easily find a library suitable
> for his project.
>

a file is an implementation. Why not a web service? This would allow for
quicker changes and alerts for newer versions.
The word "a" is likely be interpreted as one by one person and a set by
others.
I think we should talk about a library specification and a library
implementation. Then I would propose::

REQUIREMENT: Each library specification must specify his metadata in a
standardized way. The metadata contains amongst others ID, library
description, library author, library version, intended
hardware/features/boards.

The metadata information will be used in a GUI. For example, a user may
search through "descriptions" to easily find a library suitable for his
project.

REQUIREMENT: Each library implementation must specify his metadata in a
standardized way.. The metadata contains amongst others the ID, library
author, library version, library specification ID, library specification
version, library source(for instance github link). If there is a
conflict the implementation metadata takes priority to the specification
metadata.


jantje

[Matthijs Kooijman]

Hi folks,

thinking back about the discussion on the forum and some of the
subsequent discussion here about the arch/ subfolders, I think there is
something important that has not yet been included in the list of
requirements.

During that discussion, it was stated that we should make it easy and
maintainable for a library to support multiple architectures. Ideally, a
single implementation of a given library will be available that supports
multiple architectures/pieces of hardware and different developers will
collaborate on this single implementation.

However, most people also agreed that this is (often) not how it works
in practice. Library author A writes a Foo library to talk to some
hardware on his Arduino Uno and puts it on the playground. Library
author B has a Due, takes the library code, modifies it to work with his
Due and puts it up on github.

Now, user Z has a sketch which he wants to run on both a Due and a Uno,
which uses the library Foo. What should he do? He can't install both
libraries at the same time, since they are both called "Foo".

To solve this now, user Z can install one library as FooUno and one as
FooDue, modify the library's .h and .cpp filenames and add #ifdefs to
his sketch:

#ifdef ARDUINO_BOARD_UNO
#include "FooUno.h"
#else
#include "FooDue.h"
#endif

However, this isn't very pretty. Is there something we can do in the
library specification to help out the user in cases like this?

Or do we think that it's unlikely for a single user to need two
different implementations of the same library like this and assume that
a user can simply always install one version?

Or perhaps we don't want to support this scenario to encourage people to
do things the right way? This seems unlikely to actually work...


If we want to support this, I could imagine a solution that works like
this. I previously already suggested something along these lines, so I'm
mostly repeating myself here:
- Add a requirement to the library specification regarding allowing
multiple implementations of a single library to be installed.
- Whenever multiple library versions are available, ask the user which
one to use (and remember the decision for the current board and/or
board and sketch).

While writing this I realize that this same approach could be used to
have multiple versions of a library installed. For example, it could be
that a library 1.0 supports only the Uno, and 1.1 supports the Due and
Uno but triggers a bug in your Uno setup, so you might need to use
different versions based on the board.

How does this look?

Gr.

Matthijs

[Cristian Maglie]

Hi Matthijs,

In data lunedì 4 novembre 2013 15:31:20, Matthijs Kooijman ha scritto:
> If we want to support this, I could imagine a solution that works like
> this. I previously already suggested something along these lines, so I'm
> mostly repeating myself here:
> - Add a requirement to the library specification regarding allowing
> multiple implementations of a single library to be installed.
> - Whenever multiple library versions are available, ask the user which
> one to use (and remember the decision for the current board and/or
> board and sketch).

IMHO this seems to add a bunch of complications that I'd likely avoid right
now, and seems more related to the GUI. I don't exclude that in the future may
be a mechanism in the IDE that will allow you to install multiple versions of
the same library and pin-point one of them to a sketch, but for now I'd
prefere to stick to the simple "single version" scheme, and focus the efforts
to find a library specification that satisfies everyone.

C

[Matthijs Kooijman]

Hey Christian,

The reason I bring it up now, is because of the way libraries get their
names. In the current 1.0 libraries, AFAIK a library is named after the
directory it is in. Furthermore, the libraries to use are autodetected
from the .h files included by a sketch, so there must exist a .h file
with the same name as the library itself.

An obvious, easy and elegant way to implement my first point above is to
explicitely name a library in the library.properties file and drop the
requirements on the directory it is in. However, if we want to do that,
we should think about this _now_ and probably even include an explicit
mention of this fact (so users as well as third party tool developers
realize this).

Gr.

Matthijs

[Gmail]

On 04-Nov-13 16:08, Matthijs Kooijman wrote:

An obvious, easy and elegant way to implement my first point above is to
explicitely name a library in the library.properties file and drop the
requirements on the directory it is in. However, if we want to do that,
we should think about this _now_ and probably even include an explicit
mention of this fact (so users as well as third party tool developers
realize this).

I have brought up this point but I can't recall having had a answer on this
http://forum.arduino.cc/index.php?topic=165827.msg1440013#msg1440013
As we are at it.
One of the things I liked about the Arduino libraries (pre 1.5) is that 1 library=1 include in the ino file.
The 1.5.4 includes all the headers in the src folder.  for 1 library (I don't remember its name) there is even no file with the library name. I think this will confuse the newbe (and puzzle  even the more experienced like me).
My preference goes to 1 include in the ino file with the library name (The name of the folder and maybe preceding folders) for 1 library. 
As you state a name in the properties file would do just as wel.


I have brought up this point as well.
http://forum.arduino.cc/index.php?topic=165827.msg1440094#msg1440094
There is a library for avr for tone and you have a new implementation which is better but takes more space and is still in beta.
Some people will want the old one. other will want the new one. Why not have both and let the user select the most appropriate for him/her?
In this particular case the folder name can not be the architecture as the architecture is the same for the 2.
so you will have tone/arch/stable and tone/arch/beta
the folder /arch/stable contains a property file stating the architectures it runs on and so does arch/beta.
So it can be that /arch/stable supports avr, sam, all and chipKIT but arch/beta only avr.

Seems I picked a wrong example library and the discussion is about the implementation but for me (and Matthijs ) the requirement still stands.
So I'm 100% supporting this. It is not because we will not fix it in the near future it can not be a "driver" for the solution or long term goal. This to avoid incompatibilities in the future.
In other words it should not be a "must have" requirement but a "nice to have" requirement.


I also share Paul  (who has my greatest respect) his thoughts

I've already written too many lengthy messages in this conversation.  It's hard to imagine more will help.

I think more than enough information is available for a new writeup that can be put forward for validation.
Someone will need to write up a requirements document and architectural decisions (why is the requirement not granted) or we will keep on going in circles.

Jantje

[Cristian Maglie]

In data lunedì 4 novembre 2013 16:08:50, Matthijs Kooijman ha scritto:
> An obvious, easy and elegant way to implement my first point above is to
> explicitely name a library in the library.properties file and drop the
> requirements on the directory it is in. However, if we want to do that,
> we should think about this _now_ and probably even include an explicit
> mention of this fact (so users as well as third party tool developers
> realize this).

Currently there are no constraints on the folder name. The library selection
is done on the .h files found on the library's source code.

For example you can put MyLib.h inside a folder named MyLibDue, and the IDE
will always find it if you #include <MyLib.h>. So the scenario you're
describing (putting two different implementation of the same library in two
different folders) is already possible.

Even if it seems weird, I'm very reluctant to change this behavior since it
was there from the beginning and Arduino users are extremely used to that.

(Jantje, as far as I remember it was always like that, nothing changed from
0022 to 1.0.0 to 1.5.4)

C

[Matthijs Kooijman]

Hi Christian,

> Currently there are no constraints on the folder name. The library selection
> is done on the .h files found on the library's source code.

Ah, right. Apologies, I must have made a wrong assumption here or
there.

So, for the new library spec, we can just preserve this behaviour and
later see if we can make the IDE smarter about multiple versions? That
seems a good way forward to me.

Gr.

Matthijs

[Gmail]

On 04-Nov-13 18:07, Cristian Maglie wrote:
> (Jantje, as far as I remember it was always like that, nothing changed from
> 0022 to 1.0.0 to 1.5.4)

Cristian
You are right that from a coding point of view nothing changed in this
area between these Arduino IDE versions.
There is however a usage change because until 1.5.2 each library
contained a file with the folder name.
In 1.5.4 this is no longer true. The libraries I found are
Robot_control
RobotIRremote
Robot_Motor
USBHost
So; yes nothing changes at the code level but something changed at the
usage level. With risks if you ask me.
To prove my point consider following newbie experiance (tried and tested
yust now with 1.5.4).
Newbie buys arduino and irremote kit.
He looks for Arduino IR remote (in google using "arduino irremote
library") and finds Ken Shirriff his ir library on github.
He downloads the library and finds that all works great.
Because of his great experience he buys an arduino robot. Knowing ir now
he includes the RobotIRremote and BANG (error log see below).
I assume anyone having irremote lib instaled and included RobotIRremote
will have this problem.

It is going to take lots of brain power in the forum to troubleshoot
this problem.
My thinking -> bad idea.
I always assumed arduino IDE found his libraries based on a foldername
equal to the lib name. Now I know it is not the case I'm surprised that
this is not a hot topic on the community. I expect that the "foldername"
"include name" link is the reason why there has been little problems. So
I expect dropping this link will cause issues and commotion.

side thought: It is funny to see how the world turns around
When investigating this problem I saw that 10 pull requests are open for
the irremote lib on github. This is a typical demonstration of someone
making a lib and then moving on.
I even see Paul put in a pull request for Teensy compatibility.
The Arduino team shaked the library so much I would not expect replacing
irRemote with RobotIRremote to work.
So this case proves you can not expect a library maker to maintain his
library let alone maintain it for other hardware.
It also proves Paul does great work on cross architecture porting.
Proving the concerns of the library makers with the spec.

Jantje


/home/jan/programs/arduino-1.5.4/hardware/tools/avr/bin/avr-gcc -Os
-Wl,--gc-sections -mmcu=atmega32u4 -o
/tmp/build379231124625482070.tmp/sketch_nov04a.cpp.elf
/tmp/build379231124625482070.tmp/sketch_nov04a.cpp.o
/tmp/build379231124625482070.tmp/RobotIRremote/IRremote.cpp.o
/tmp/build379231124625482070.tmp/RobotIRremote/IRremoteTools.cpp.o
/tmp/build379231124625482070.tmp/IRremote/IRremote.cpp.o
/tmp/build379231124625482070.tmp/core.a
-L/tmp/build379231124625482070.tmp -lm
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `MATCH(int, int)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `MATCH_MARK(int, int)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `MATCH_SPACE(int, int)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::IRrecv(int)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `irparams'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::IRrecv(int)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::resume()'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::decodeNEC(decode_results*)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::getRClevel(decode_results*, int*, int*, int)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::compare(unsigned int, unsigned int)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::decodeHash(decode_results*)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::decode(decode_results*)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `__vector_41'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::blink13(int)'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here
IRremote/IRremote.cpp.o: In function `IRsend::sendNEC(unsigned long, int)':
/home/jan/Arduino/libraries/IRremote/IRremote.cpp:70: multiple
definition of `IRrecv::enableIRIn()'
RobotIRremote/IRremote.cpp.o:/home/jan/programs/arduino-1.5.4/libraries/RobotIRremote/IRremote.cpp:82:
first defined here

[Paul Stoffregen]

On 11/04/2013 11:52 AM, Jantje wrote:
> When investigating this problem I saw that 10 pull requests are open
> for the irremote lib on github. This is a typical demonstration of
> someone making a lib and then moving on.

That's partly my fault. Ken gave me access and asked for help to
maintain the library. IRremote maintenance is on my to-do list. Some of
those pull requests conflict with each other. I just haven't had time
to dedicate to IRremote over the last several months. Like so many
things, I hope to get to it sometime next year!

IRremote's timer abstraction layer, by the way, was my work a few years
ago. Ken's original library had AVR timer2 registers hard-coded. I
wrote and contributed the abstraction layer. Later when Arduino
Leonardo was released, IRremote "just worked", and also now on the
Arduino Robot, only because of the code I added. ;-)

IRremote is one the libraries where I have not been able to imagine an
API that Arduino could provide. In the very long term, I want to
revisit IRremote and try to leverage the far more sophisticated hardware
available on newer ARM chips, which may be difficult to abstract. So
many things to do, never enough time.........

[Cristian Maglie]

In data lunedì 4 novembre 2013 20:52:30, Gmail ha scritto:
> There is however a usage change because until 1.5.2 each library
> contained a file with the folder name. In 1.5.4 this is no longer true.

But how do you infer that? It's false, there are a lot of libraries that had
more than 1 file before 1.5.2. USBHost (just to pick the one you mentioned) is
a fork of USB_Host_Shield:

https://github.com/felis/USB_Host_Shield_2.0

as you can see it contains more than one file, and also the examples relies on
the fact that you can include, say, "cdcacm.h":

https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/acm/acm_terminal/acm_terminal.ino

This library is out well before IDE 1.5.4.
(but there are a LOT of other similar libraries)

> To prove my point consider following newbie experiance (tried and tested
> yust now with 1.5.4).
> Newbie buys arduino and irremote kit.
> He looks for Arduino IR remote (in google using "arduino irremote
> library") and finds Ken Shirriff his ir library on github.
> He downloads the library and finds that all works great.

You installed an IRRemote that is incompatible with the Robot. User installed
libraries have priority on the default provided with the IDE, and its good to
be like that. Moreover, this behaviour is independent from the number of files
(that seems your main concern here).

(my apologies to the list for annoying you with these details, this is my last
email for today)

C

[Gmail]

Paul
I'm not thinking/speaking in terms of fault.
It is just a simple fact of life that people do things and then move on.
As such it is not realistic to request someone who put the effort in
writing a library and shared it with the rest of the world to maintain
the library for the rest of his days (and stay alive 8-) )
I personally see making code open source as a way of "Don't ask me to
maintain it; do it yourself". I'm sure many people who have shared code
think the same way.

But I'm happy to learn you can give someone else access on github and
then have that person being blamed for not maintaining the code :-P

Jantje

PS Paul I know you know all this but from the conversations on this
subject I'm not sure everybody does.

[Jan Baeyens]

As I don't seem to be able to explain a simple problem
and as I think including a library with name Y is impossible when a
private library with name z exists is not a detail.
I will unsubscribe from this list.
I wish you all and Arduino the best but I'm not hopeful
Jantje

On 04-Nov-13 22:11, Cristian Maglie wrote:

[avenue33]

I've given up.