Built-in Library Manger for 3rd party libraries

[Ivan Kravets]

Hey,

We have just started discussion with Paul Stoffregen  as for library.json specification and built-in Library Manager for Arduino IDE and I want to hear all opinions about it here. 

Paul Stoffregen:

I still have mixed feelings about this metadata format, but at least it's a start. 

My hope is to someday make a library management tool within the Arduino IDE. Actually, I'm really hoping someone else will do this and I can simply use it. Many people have tried to do such tools in the past, but all have abandoned their effort or never really got started (even Arduino has wanted to do this for years, but never made significant progress).
For every library I publish, there's a stable download URL, and the work-in-progress GitHub address. It would be nice if both were in the metadata. How some future library manager will actually use those links, I do not know. I'm not very good at predicting the future!
Another feature missing is a clear way to specify one or more pages that are the documentation for the library. The description also appears to be limited to only a short description (often an image communicates a visual idea of a library's purpose much easier than reading text). There's also no way to specify well defined categories. In some sort of library manager tool, where many hundreds of libraries are shown to users, all of that type of descriptive metadata will be needed.
But at least this format is a good start with basic info. I'd rather start something imperfect and improve as needed, instead of waiting and never making any forward progress due to indecision.

My answer:

My hope is to someday make a library management tool within the Arduino IDE. Actually, I'm really hoping someone else will do this and I can simply use it. 

This is quite easy to do it with PlatformIO Library Registry. The API is open for all. If I had have practice with Java + GUI Framework I could helped Arduino community with nice GUI tool. As for API:

Search for libs: http://api.platformio.ikravets.com/lib/search?query=%QUERY_HERE%

The `%QUERY_HERE%` (must be properly URL-encoded) can contain not only "words", but also special filters, like:

`keyword:`, `author:`, `framework:` or `platform:`. For example, 

• The 1-wire -based libs: http://api.platformio.ikravets.com/lib/search?query=framework:arduino%201-wire
  
• The libs by Adafruit Industries: http://api.platformio.ikravets.com/lib/search?query=framework:arduino author:"Adafruit Industries"
• The libs by "web" keyword: http://api.platformio.ikravets.com/lib/search?query=framework:arduino keyword:web
• Boolean logic, Arduino-based X10 or XBee libs: http://api.platformio.ikravets.com/lib/search?query=framework:arduino +(x10 xbee)
• The detailed information about more complicated Boolean queries is located in the documentation.

Accordingly PlatformIO Library Registry the unique entity is based on ID (Unsigned Integer), because we can have multiple libs with the same name, but for different platforms.

 As a result, each "library item" in JSON response contain "id" field. This ID will be used for install/uninstall/update operations. 

Get library information: http://api.platformio.ikravets.com/lib/info/%LIB_ID%

For example, OneWire library: http://api.platformio.ikravets.com/lib/info/1

Get cleaned library source code by different versions (based on `downloadUrl` or `repository` commits): http://api.platformio.ikravets.com/lib/download/%LIB_ID%?version=%VERSION_NUMBER%

The `version` argument is optional. For example:

• The latest OneWire source code from repository: http://api.platformio.ikravets.com/lib/download/1
  
• The stable 2.2 version: http://api.platformio.ikravets.com/lib/download/1?version=2.2

Get library latest version (good for update operation): http://api.platformio.ikravets.com/lib/version/%LIB_ID1,LIB_ID2, ..., LIB_IDn%

For example, http://api.platformio.ikravets.com/lib/version/70,1

Another feature missing is a clear way to specify one or more pages that are the documentation for the library.

What do you think about `docsUrl` field? It can be `String`, for one URL, or `Array` with the multiple URLs

The description also appears to be limited to only a short description (often an image communicates a visual idea of a library's purpose much easier than reading text). 

Are you sure that manifest file should contain more detailed information about library? I think this information should be located in special file/files, documentation or etc., like README file. Then we can define the URL to this README file in `docsUrl` field.

There's also no way to specify well defined categories.

This is good idea. I like Python's package classifiers https://pypi.python.org/pypi?%3Aaction=list_classifiers  

I'm not sure that we should spend time for it now. To my mind, the `keywords` field is enough at this point. People are not interested in it :( Or, maybe, they don't know about it :)

P.S: I wrote an article about Integration PlatformIO CLI Library Manager to Arduino IDE. I think that it can easy integrated to Arduino IDE natively inside separated Popup Window (Library Manager). See how this looks with mine Arduino IDE with one command which installed all dependencies:

Before & after:

[bob cousins]

What version of Arduino IDE is this for? I don't see any support for Arduino Due.

I am not keen on adding a dependency on Python, it would be better if it was in Java like the IDE.

[Ivan Kravets]

> On Oct 25, 2014, at 20:02, bob cousins <bobcou...@googlemail.com> wrote:
>
> What version of Arduino IDE is this for? I don't see any support for Arduino Due.

The described way with PlatformIO CLI + Arduino IDE is compatible wii all versions which support scanning for additional libraries in the special folders

> I am not keen on adding a dependency on Python, it would be better if it was in Java like the IDE.

Sure, I don't shout and invite to use PlatformIO CLI, I wrote here about PlatformIO Library Registry. It is free and open for all. I'm working on library populating now. I would be thankful if someone help with adding new "library.json" manifest files to popular libs.

How I see this in Arduino?

1. From the menu user opens "Library Manager" in separated window (like Console).
2. Need to show already installed libs in the list with option to delete them. PlatformIO holds 5 latest versions of each library in own storage. Each library is cleaned from different unused things (images, huge docs and etc) adn contains TWO files:
".library.json" - this is SERVICE manifest file, which contains additional information about library, including "ID". The JAVA application can use this file to identify that library is installed correctly and has correct structure.
"library.json" - this is original manifest library file which is created by owner of lib. PlatformIO Library Crawler uses it for generating Registry DB.

3. Search form - the API is described above.
4. Double click on library should show additional information about lib.
5. "Update" button - look for new versions.

All these operations should be performed within Arduino IDE without any dependencies.

With best regards, Ivan Kravets
- "Creativity comes from talent and never from knowledge" (c)
________________________
http://www.ikravets.com

[Vaclav]

I would hope this community would find either their own name / description of add - in / on classes / objects and quit calling them "libraries". They are NOT libraries. 

As messy as it is to add these "libraries" it is still basically a sequence one has to follow to be successful. It seems to be cool to automate some processes ( setup / loop ) instead of teaching / documenting how to implement existing ones.

Instead of "developing " a "library" tool, why not have some smart developer tell us how to implement multiple search path to be able to navigate to other directories beside Arduino's  ..\libraries. 

I ain't compiler expert, just a user , but there is something in command line as -Ic... so why can't we use that EXISTING technology / method somehow??

I did try #pragma... (lib,...) to add another library path, but I guess it did not work because I was not including REAL library path. 

--
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.

[Paul Stoffregen]

Sometime I wonder why software developers so deeply aligned against Arduino's approach to improving usability for novices bother to "contribute" to this mail list / google group.

On 10/25/2014 07:44 PM, 'Vaclav' via Developers wrote:

[bob cousins]

On Saturday, October 25, 2014 7:12:31 PM UTC+1, Ivan Kravets wrote:

> On Oct 25, 2014, at 20:02, bob cousins <bobcou...@googlemail.com> wrote:
>
> What version of Arduino IDE is this for? I don't see any support for Arduino Due.
The described way with PlatformIO CLI  + Arduino IDE is compatible wii all versions which support scanning for additional libraries in the special folders

Surely to be compatible it needs the Due as a possible target? How do I get third-party boards added into the system?

In order to use the system, does the user need access to your website? What happens if the site is down or disappears?

Is the PlatformIO system something that can be integrated into Arduino IDE now, or is it being proposed as a template for something that could
be implemented?

I think I am missing some levels of understanding here. How your system works will be obvious to you, as someone who has never seen it I am trying to grasp what it is about.

[Ivan Kravets]

> On Oct 26, 2014, at 13:22, bob cousins <bobcou...@googlemail.com> wrote:
>
>
> On Saturday, October 25, 2014 7:12:31 PM UTC+1, Ivan Kravets wrote:
>
> > On Oct 25, 2014, at 20:02, bob cousins <bobcou...@googlemail.com> wrote:
> >
> > What version of Arduino IDE is this for? I don't see any support for Arduino Due.
> The described way with PlatformIO CLI + Arduino IDE is compatible wii all versions which support scanning for additional libraries in the special folders
>
> Surely to be compatible it needs the Due as a possible target?

Does this question is related to PlatformIO CLI source code builder? PlatformIO doesn't have support for Atmel SAM MCUs. But I can add this support. If you are interesting in it, please contact directly me (because here we are discussing lib manager :) ).

> How do I get third-party boards added into the system?

The full list with supported boards are published here (use TABS) http://platformio.ikravets.com/#!/boards or more detailed info in documentation http://docs.platformio.ikravets.com/en/latest/platforms/index.html

> In order to use the system, does the user need access to your website?

No, he doesn't. You can access to all information which is published in this site from documentation http://docs.platformio.ikravets.com and search for libs via CLI interface without browser and etc. See examples http://docs.platformio.ikravets.com/en/latest/userguide/lib/cmd_search.html#examples

This is actual for JAVA version of Library Manager. User will not know anything about PlatformIO site or etc. All information (libs search, info, updating, managing) - will be accessible from native JAVA-based IDE interface.

> What happens if the site is down or disappears?

I don't plan to shutdown this site even if "0" users will use it, because me and my friends use it :)

> Is the PlatformIO system something that can be integrated into Arduino IDE now,

The API for Library Registry - this part can be integrated to Arduino IDE directly. The only one thing that need to do is GUI for it :)
I've found a guy which is interested in it recently. I hope he can implement "simple" GUI for this API. We will share our progress here.

> or is it being proposed as a template for something that could be implemented?

Sure, it is proposed as "raw solution". What is interesting, it works good. You redefine in PlatformIO "lib_dir" ti Arduino's library directory and then manager your libs from CLI (search/ install/ update adn etc). Don't forget to restart Arduino IDE after "install/uninstall" operations. The full steps are described in article http://www.ikravets.com/computer-life/platformio/2014/10/07/integration-of-platformio-library-manager-to-arduino-and-energia-ides

> I think I am missing some levels of understanding here. How your system works will be obvious to you, as someone who has never seen it I am trying to grasp what it is about.

It's normal, don't hesitate to ask. Thanks a lot for interesting!

[Ivan Kravets]

> On Oct 26, 2014, at 04:44, 'Vaclav' via Developers <devel...@arduino.cc> wrote:
>
> I would hope this community would find either their own name / description of add - in / on classes / objects and quit calling them "libraries". They are NOT libraries.
> As messy as it is to add these "libraries" it is still basically a sequence one has to follow to be successful. It seems to be cool to automate some processes ( setup / loop ) instead of teaching / documenting how to implement existing ones.

I think, you should ask about it whole Arduino's community why they are calling "bunch of C files" like "library". The roots of this problem have begun since "Import Library..." menu item :)
What is your proposition how we should call them?

> Instead of "developing " a "library" tool, why not have some smart developer tell us how to implement multiple search path to be able to navigate to other directories beside Arduino's ..\libraries.
> I ain't compiler expert, just a user , but there is something in command line as -Ic... so why can't we use that EXISTING technology / method somehow??
>
> I did try #pragma... (lib,...) to add another library path, but I guess it did not work because I was not including REAL library path.

You can publish this question to separated thread. Maybe, someone will add this functionality to Settings window, where people will have access to customise LIB_SEARCH_PATHs.

[Ivan Kravets]

If like to build source code from the CLI, I recommend you to look into "build_flags" option from "project's configuration file" http://docs.platformio.ikravets.com/en/latest/projectconf.html#build-flags
You can define different flags/options for each environment within single source code.

See example with "Wiring-Blink" https://github.com/ivankravets/platformio/blob/develop/examples/wiring-blink/platformio.ini

> On Oct 26, 2014, at 04:44, 'Vaclav' via Developers <devel...@arduino.cc> wrote:
>

> Instead of "developing " a "library" tool, why not have some smart developer tell us how to implement multiple search path to be able to navigate to other directories beside Arduino's ..\libraries.
> I ain't compiler expert, just a user , but there is something in command line as -Ic... so why can't we use that EXISTING technology / method somehow??
>
> I did try #pragma... (lib,...) to add another library path, but I guess it did not work because I was not including REAL library path.

[Peter Feerick]

Ivan, I think that Bob's question on "Surely to be compatible it needs the Due as a possible target?" was more directed at the list of supported boards... ie. the list at http://platformio.ikravets.com/#!/boards, because the Arduino Due is not included in that list.

I like the look of the PlatformIO website, and hope that the existence of a central repository for Arduino libraries stimulates interest in the concept of a library manager again.

Regards,

Peter

[Ivan Kravets]

Peter, I'm going to add support for Atmel SAM platform including Due board this week. I will report here.
Thanks.

> On Oct 27, 2014, at 11:31, Peter Feerick <peter....@gmail.com> wrote:
>
> Ivan, I think that Bob's question on "Surely to be compatible it needs the Due as a possible target?" was more directed at the list of supported boards... ie. the list at http://platformio.ikravets.com/#!/boards, because the Arduino Due is not included in that list.
>
> I like the look of the PlatformIO website, and hope that the existence of a central repository for Arduino libraries stimulates interest in the concept of a library manager again.

[Vaclav]

Thanks Ivan,

I think it will do the job I want.

Vaclav 

[bob cousins]

It does look slick, Ivan has obviously spent some time on it. However, I don't feel that Ivan gave me straight answers to some simple questions, which does not give me confidence and I am not much wiser on exactly how it could work.

I would favour a library manager which uses a /decentralised/ database, i.e. an open one that can be easily forked. Ivan says he will maintain the website forever, and I am sure he believes that, but with greatest respect to Ivan, people's life circumstances can and do change and there is no guarantee the website will be around forever. Therefore I would not spend time developing for a website which for all I know could disappear tomorrow.

I raised the question of how to add third party boards, which was not really answered, but I think a similar extensible JSON descriptor could be created for those as well, instead of being baked into some python scripts. It appears platformio is based on IDE 1.0.x way of handling targets, but this has changed a lot in 1.5.x.

I think that the only thing that is needed for Arduino is a github repository containing the library json files, then that can be used for the search, install and update operations within Arduino IDE. There doesn't appear to be a need for all the other stuff provided by platformio.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[Ivan Kravets]

> On Oct 27, 2014, at 22:17, bob cousins <bobcou...@googlemail.com> wrote:
>
> It does look slick, Ivan has obviously spent some time on it. However, I don't feel that Ivan gave me straight answers to some simple questions, which does not give me confidence and I am not much wiser on exactly how it could work.

Sorry, I will try to answer more clearly.

> I would favour a library manager which uses a /decentralised/ database, i.e. an open one that can be easily forked. Ivan says he will maintain the website forever, and I am sure he believes that, but with greatest respect to Ivan, people's life circumstances can and do change and there is no guarantee the website will be around forever. Therefore I would not spend time developing for a website which for all I know could disappear tomorrow.

I had similar idea several months ago. I created for it special "mirror-repository". See here https://github.com/ivankravets/platformio-libmirror/tree/master/configs
I thought that this is bad idea and many developers wont like it :( Then I decided to make "pull-requests" for popular libraries within GitHub. To my mind, each developer should be responsible for own library and "library.json" manifest information.

If we decided to use central GitHub repo - I can export all configs to it from DB and then keep it up-to-date.

> I raised the question of how to add third party boards, which was not really answered, but I think a similar extensible JSON descriptor could be created for those as well, instead of being baked into some python scripts.

I don't think that is hard to add new platform/board. The build logic is based on great project http://www.scons.org It's a cross-platform software construction tool.
For example, please take a look into Arduino "build script" - https://github.com/ivankravets/platformio/blob/develop/platformio/builder/scripts/atmelavr.py
As for me, it is easy for reading and editing and it looks more clearly for different developers then Makefile.

Finally, this is a configuration file for "atmelavr" platform https://github.com/ivankravets/platformio/blob/develop/platformio/platforms/atmelavr.py

That's all :) We should create 2 scripts(files) for new platform :)

> It appears platformio is based on IDE 1.0.x way of handling targets, but this has changed a lot in 1.5.x.

PlatformIO doesn't based on any board or IDE. It depends on Framework which will be installed by your command:
> $ platformio install atmelave --framework=****

Currently, I uploaded to dl.repo 1.5.8 branch.

> I think that the only thing that is needed for Arduino is a github repository containing the library json files, then that can be used for the search, install and update operations within Arduino IDE. There doesn't appear to be a need for all the other stuff provided by platformio.

I hope that I've just answered about it above. But is it good that developer of library should depend on GitHub ? Does each developer have GitHub account? Because current logic allows PlatformIO to monitor different "library.json": it can be located on GitHub, on GIT/SVN or even in forum post. Please read this page about "Source Code Location" http://docs.platformio.ikravets.com/en/latest/librarymanager/creating.html

My dream is to collect all libraries in one place from whole Internet, including forums and etc. As for Arduino-based libs, the most popular libs are located on GitHub and it is easy to find their. The opposite situation is with "MSP430" libs, they are scattered within forums, blogs and etc :(

>
> On Monday, October 27, 2014 9:32:39 AM UTC, peter.feerick wrote:
> Ivan, I think that Bob's question on "Surely to be compatible it needs the Due as a possible target?" was more directed at the list of supported boards... ie. the list at http://platformio.ikravets.com/#!/boards, because the Arduino Due is not included in that list.
>
> I like the look of the PlatformIO website, and hope that the existence of a central repository for Arduino libraries stimulates interest in the concept of a library manager again.
>
> Regards,
> Peter
>
>
> On Mon, Oct 27, 2014 at 1:49 AM, Ivan Kravets <m...@ikravets.com> wrote:
> If like to build source code from the CLI, I recommend you to look into "build_flags" option from "project's configuration file" http://docs.platformio.ikravets.com/en/latest/projectconf.html#build-flags
> You can define different flags/options for each environment within single source code.
>
> See example with "Wiring-Blink" https://github.com/ivankravets/platformio/blob/develop/examples/wiring-blink/platformio.ini
>
> > On Oct 26, 2014, at 04:44, 'Vaclav' via Developers <devel...@arduino.cc> wrote:
> >
> > Instead of "developing " a "library" tool, why not have some smart developer tell us how to implement multiple search path to be able to navigate to other directories beside Arduino's ..\libraries.
> > I ain't compiler expert, just a user , but there is something in command line as -Ic... so why can't we use that EXISTING technology / method somehow??
> >
> > I did try #pragma... (lib,...) to add another library path, but I guess it did not work because I was not including REAL library path.
>
> With best regards, Ivan Kravets
> - "Creativity comes from talent and never from knowledge" (c)
> ________________________
> http://www.ikravets.com
>
>
>
>
> --
> 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.
>
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/arduino.cc/d/topic/developers/xCDjekcQW4k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to developers+...@arduino.cc.

[Paul Stoffregen]

On 10/26/2014 08:26 AM, Ivan Kravets wrote:
> The API for Library Registry - this part can be integrated to Arduino
> IDE directly. The only one thing that need to do is GUI for it :)

How will your API support a GUI for browsing and finding libraries? For
example, suppose someone wants to find all the libraries that might help
them measure weather, for some sort of weather monitor station.

So far, you appear to have the ability to list all libraries, and to
search by keywords.

Keyword search is great when 2 happy circumstances happen to coincide:
#1: the library's metadata actually has the desired keyword, and #2: the
end user actually knows the right keyword before they search. With
novice Arduino users, #2 is particularly a problem when most keywords
are unfamiliar technical terms.

Listing all libraries does not scale well. Arduino 1.5.8 ships with 22
libraries, which is probably about as many as a simple flat list can
accommodate. There are at least a few hundred really valuable and
widely used libraries for Arduino. Many hundreds more are
obsolete/incompatible, or duplicate functionality of another superior
library, or are so buggy they should never be used, or just aren't very
useful. A simple flat list just isn't useful.

For example, imagine you have a project where you want to somehow share
data between multiple Arduinos. How would someone find the libraries
which might suit that need using your web page?

http://platformio.ikravets.com/#!/lib/search?query=framework%253Aarduino&page=1

Are they supposed to click for each page of 10 and read every
description? Already you have 7 pages, and the list will grow
unworkably long. Many of the descriptions even begin with the useless
words "Arduino library for". Many of the descriptions are brief and
technical, assuming the reader already has knowledge of what the library
does.

To build a high quality GUI that allows novice Arduino users to discover
the libraries which suit their goals, or to browse large groups of
libraries that are somewhat related to their goals, to help them plan
their project, much better metadata and a better API are needed. Of
course, the GUI programming is also needed, but the GUI alone can't make
up for inadequate metadata.

At the very least, some form of categorization scheme is needed. The
challenge with categorizes is to create enough to make searches and
lists return a smaller, easier-to-read list, but not so many that they
become ambiguous or overlapping. The other huge challenge of categorize
is the list must be rigidly defined, so that new libraries don't make up
some new category, which tends to ruin the entire scheme.

Previously we talked about library categories. This is the currently
proposed list: "Display", "Communication", "Signal Input/Output",
"Sensors", "Device Control", "Timing", "Data Storage", "Data
Processing", "Other", "Uncategorized". This list probably isn't perfect.

On top of categorizes, to manage libraries, some mechanism is needed to
specify when an library is effectively replaced by another improved
library. For example, several old libraries exist for pushbutton
debouncing, which are all superseded by the "Bounce" library. Any sort
of display of library search results should only show Bounce, and
perhaps a small button at the end to "show older or obsolete" libraries.

There are many special cases where these library relationships are not
as clear. For example, there is a library called "TrueRandom" which
claims to generate high quality random numbers. It doesn't, despite the
fact it got quite a lot of publicity years ago and is widely mentioned.
Later, a very good library called "Entropy" was published, with little
publicity. Even though the two code bases and completely unrelated, and
pages about TrueRandom still claim it works well, a GUI and back-end
metadata system/API that is truly useful to end users should be able to
have these little details curated by a group of experts, so people
wishing to get better random numbers will be directed to the superior
Entropy library.

Of course, there are lots of other libraries with duplicate or similar
functionality, where it's not clear which one is better (should be show
first in a list).

Numerous other issues exist, but ultimately as the list of all libraries
grows very large, searching and browsing will will only be valuable if
they're able to "separate the wheat from the chaff".

[bob cousins]

On Monday, October 27, 2014 8:53:44 PM UTC, Ivan Kravets wrote:

> I raised the question of how to add third party boards, which was not really answered, but I think a similar extensible JSON descriptor could be created for those as well, instead of being baked into some python scripts.
I don't think that is hard to add new platform/board. The build logic is based on great project http://www.scons.org It's a cross-platform software construction tool.
For example, please take a look into Arduino "build script" - https://github.com/ivankravets/platformio/blob/develop/platformio/builder/scripts/atmelavr.py
As for me, it is easy for reading and editing and it looks more clearly for different developers then Makefile.

Finally, this is a configuration file for "atmelavr" platform https://github.com/ivankravets/platformio/blob/develop/platformio/platforms/atmelavr.py

That's all :) We should create 2 scripts(files) for new platform  :)

As I said before, this is based on Arduino 1.0.5 way of doing things, which I think is something you are not getting. In 1.5.x there are no built-in tools, they are defined in the platform.txt files for each platform, this makes it easy to add new hardware platforms. The way you have done it makes it hard again.

I have spent some time looking at platformio, and I can see it is well executed. It works well as a standalone system separate to the IDE, but does not lend itself to easy integration with Arduino. Apart from the general concept, I can't see anything useful for Arduino. I had hoped that the library.json files could be useful, but they have some problems. e.g. there is nothing in Arduino matching "atmelavr". There is "avr" and "sam".

The issue of searching for libraries is a can of worms, and I wouldn't want to reinvent google. If the meta-data was distributed, then perhaps users could choose which meta-repos to use, similar to how PPAs are used.

Therefore I would restrict the use cases to installing a library specified from a list, checking for updates, and possibly uninstalling. A useful addition would be associating user installed libraries with particular hardware platforms, currently if you have a mix of AVR and SAM libraries they all appear in the "Import library" menu, which is not the case for libraries discovered in hardware/* folders.

If I have some time I will write some code to implement some basic ideas.

[Ivan Kravets]

> On Oct 27, 2014, at 23:01, Paul Stoffregen <pa...@pjrc.com> wrote:
>
> At the very least, some form of categorization scheme is needed. The challenge with categorizes is to create enough to make searches and lists return a smaller, easier-to-read list, but not so many that they become ambiguous or overlapping. The other huge challenge of categorize is the list must be rigidly defined, so that new libraries don't make up some new category, which tends to ruin the entire scheme.
>
> Previously we talked about library categories. This is the currently proposed list: "Display", "Communication", "Signal Input/Output", "Sensors", "Device Control", "Timing", "Data Storage", "Data Processing", "Other", "Uncategorized". This list probably isn't perfect.

Thanks. This is great idea and addition to "library.json". I have a few questions:
1. Can category has sub-category?
2. What do you think about moving "frameworks" and "platforms" fields to this "library categories...."?

I want to propose to implement new field named "classifiers". I'm inspired by PyPi classifiers https://pypi.python.org/pypi?%3Aaction=list_classifiers
How it can look for library?

"name": "DHT22"
...
"classifiers":
[
"Sensor :: Temperature",
"Sensor :: Humidity",
"Application :: Weather-station",
"Communication :: Single-bus",
"Framework :: Arduino",
"Platform :: Atmel AVR",
"Platform :: Teensy",
...
]

Then user will have great instrument with filters to browse libs.

>
> On top of categorizes, to manage libraries, some mechanism is needed to specify when an library is effectively replaced by another improved library. For example, several old libraries exist for pushbutton debouncing, which are all superseded by the "Bounce" library. Any sort of display of library search results should only show Bounce, and perhaps a small button at the end to "show older or obsolete" libraries.
>
> There are many special cases where these library relationships are not as clear. For example, there is a library called "TrueRandom" which claims to generate high quality random numbers. It doesn't, despite the fact it got quite a lot of publicity years ago and is widely mentioned. Later, a very good library called "Entropy" was published, with little publicity. Even though the two code bases and completely unrelated, and pages about TrueRandom still claim it works well, a GUI and back-end metadata system/API that is truly useful to end users should be able to have these little details curated by a group of experts, so people wishing to get better random numbers will be directed to the superior Entropy library.
>
> Of course, there are lots of other libraries with duplicate or similar functionality, where it's not clear which one is better (should be show first in a list).

Should be located this information in "library.json"?

> Numerous other issues exist, but ultimately as the list of all libraries grows very large, searching and browsing will will only be valuable if they're able to "separate the wheat from the chaff".

I'm totally agree with you. I think the categories/classifiers will resolve it.

[Ivan Kravets]

> On Oct 29, 2014, at 03:35, bob cousins <bobcou...@googlemail.com> wrote:
> As I said before, this is based on Arduino 1.0.5 way of doing things, which I think is something you are not getting. In 1.5.x there are no built-in tools, they are defined in the platform.txt files for each platform, this makes it easy to add new hardware platforms. The way you have done it makes it hard again.

No, no, no... Arduino 1.0.5 had "hardcoded" build options inside Java-based source code. PlatformIO also has "hardcoded" default options per platform, but it allows people redefine ALL options via "build_flags". See documentation: http://docs.platformio.ikravets.com/en/latest/projectconf.html#build-flags

> I have spent some time looking at platformio, and I can see it is well executed. It works well as a standalone system separate to the IDE, but does not lend itself to easy integration with Arduino. Apart from the general concept, I can't see anything useful for Arduino.

I don't propose to integrate "source code builder" part of PlatformIO to Arduino IDE. The Arduino IDE has own tool chains and contains their by default inside application.

> I had hoped that the library.json files could be useful, but they have some problems. e.g. there is nothing in Arduino matching "atmelavr". There is "avr" and "sam".

You are right. This "platforms" field isn't good generalised. I've just proposed in the previous letter to move "platforms" and "frameworks" fields into "classifiers" field, where we will define real and normalised information about library. Then a developer or another "library manager" will decided to use or not a data from "classifiers" field, like: "Platform :: Atmel AVR" .. "Platform :: Atmel SAM" and etc...

> The issue of searching for libraries is a can of worms, and I wouldn't want to reinvent google. If the meta-data was distributed, then perhaps users could choose which meta-repos to use, similar to how PPAs are used.

I answered your in the previous letter about moving lib's confs to separated repository. Is it good idea? Which way will be preferable to developers to maintain theirs lib's "library.json" files:
1. Via pull-requests to meta-repo
2. To keep own "library.json" within library source code and edit it when want.

> Therefore I would restrict the use cases to installing a library specified from a list, checking for updates, and possibly uninstalling.

Do you have any arguments?

> A useful addition would be associating user installed libraries with particular hardware platforms, currently if you have a mix of AVR and SAM libraries they all appear in the "Import library" menu, which is not the case for libraries discovered in hardware/* folders.

The problem is in "library name". The current version of Arduino IDE uses lib's name like as "folder name". If we decide to use "library.json", then we will show useful meta-information about library in "Import library..." menu. The idea with putting platform's type to library folder name is not good because Arduino Trademark Policy doesn't allow us to use "arduino" in titles and etc.
See here http://arduino.cc/en/Trademark/HomePage?from=Main.Trademark

[bob cousins]

On Wednesday, October 29, 2014 9:30:40 PM UTC, Ivan Kravets wrote:

> The issue of searching for libraries is a can of worms, and I wouldn't want to reinvent google. If the meta-data was distributed, then perhaps users could choose which meta-repos to use, similar to how PPAs are used.
I answered your in the previous letter about moving lib's confs to separated repository. Is it good idea? Which way will be preferable to developers to maintain theirs lib's "library.json" files:
1. Via pull-requests to meta-repo
2. To keep own "library.json" within library source code and edit it when want.

I don't plan on using library.json files, or any other part of platformio, so it is not an issue.

We already have a library spec: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification which was thrashed out over a good deal of discussion.

This includes a library metafile format, I really don't know why we would even consider suddenly switching to a different format.

[Vaclav]

I do not want to muddy -up the waters, but from recent bad experience "installing" 1.5.6 and up - how does Windowze registry fits into scheme of things? ( I had few mismatches when deleting an "old" releases.) 

 I "grew up " with ini file and after starting to use Arduino was not sure I like to "go back" all the way to txt file as configuration data file. And I do realize Windows is not the only OS Arduino works with. 

--
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+unsub...@arduino.cc.

[Ivan Kravets]

I can't understand how "Library Manager" can use this format for different platforms and support library dependencies. This specification is good when the library source code:
- is already cleaned (only h/c/cpp files and etc)
- is well structured, where "source code" should be located in "src" dir
- the examples are located in right path

How about the library which doesn't want to keep source code in "src" and examples in "examples"? We have a lot of libraries in Internet which don't feet to this specification. Will you recommend all owners to change folder structures for all libs? How much time(years) we need for it?

As for Arduino, maybe, this is good solution because we didn't have any specifications earlier.

To my mind, we should create specification which will allow developers to describe library with changes to existing source code. "library.json" allows do it via "include", "exclude", "examples", "dependencies", "downloadUrl", "repository" and etc fields. Developer can decide via "include"/"exclude" fields which files should be used by "library manager".

-----
Bob, are interested in "Library manager" with "search/install/uninstall/update" features within separated window inside Arduino IDE? I found guy which can implement it.

> --
> You received this message because you are subscribed to a topic in the Google Groups "Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/arduino.cc/d/topic/developers/xCDjekcQW4k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to developers+...@arduino.cc.

[Federico Fissore]

Hi

We are working on a library manager that we'll bundle into the IDE with
version 1.6.1 or 1.6.2

The problem in using tools we don't own * but that are (sometime
impressive) efforts of single developers is that they cannot guarantee
the level of service an Arduino user expects (don't get me wrong: we are
far from perfect, but we take the blame and then fix what we can fix)

Therefore we can only
1) make something new, or deeply customize something already existing in
order to have a seamless user experience
2) sign contracts with companies that have acceptable service level
agreements

* "owning" has different meanings, depending on the tool. For example,
we don't literally "own" gcc, but we are able to build our own version,
as well as to patch it [1]

[1]
https://github.com/arduino/toolchain-avr/commit/5d8e0f5450f9976f582f8aa98926e8e77a0c161f

Federico

[bob cousins]

On Monday, November 24, 2014 8:33:59 AM UTC, f.fissore wrote:

We are working on a library manager that we'll bundle into the IDE with
version 1.6.1 or 1.6.2

It would have been great if that had been mentioned earlier!

I'm glad I hadn't wasted any time developing patches.

[Peter Feerick]

Hi Bob,

It has been mentioned a few times on the mailing list about developing an official library manager... but there was never a time or version commitment... just *in the pipeline*. It would have been good for this thread if it had been mentioned as 'coming soon' whenever it was a serious commitment. Perhaps next time?

I think the lack of a roadmap that contributors can view is where most problems arise. Why take time and effort to when a change in direction in the development of the IDE makes it pointless? (I'm thinking of the IDE refactor here - and is a web ui around the corner making focusing on the current ui not so much a priority - just fixing any major gremlins rather enhancements?)

Peter

--

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.

[Federico Fissore]

Hi

yes, there's sure a lot of room for improvement.

Sharing a long term roadmap can be an issue.
It would create expectations for features that we plan to implement in
months from now because they are part of a long term strategy.
However you may think such features have a higher priority, because of
your needs.
This could lead to pointless discussions about what should be done
first, instead of focusing on *how* to code a particular feature (much
more interesting).

What do you think of kind of "currently working on" emails sent to the list?

As for improvements to the java IDE, 1.0.x is going out of scope because
we are putting all our efforts into 1.6.
One piece we would have liked to release for 1.6 is a new editor:
trashing away the current JEdit based implementation in favour of a much
cooler http://fifesoft.com/rsyntaxtextarea/.
This should also make life easier to the autocomplete feature mentioned
some threads ago.
Any help here is much appreciated.

Regards

Federico

[Ricardo JL Rufino]

"One piece we would have liked to release for 1.6 is a new editor: trashing away the current JEdit based implementation in favour of a much cooler http://fifesoft.com/rsyntaxtextarea/.

This should also make life easier to the autocomplete feature mentioned some threads ago."

Someone else is working on it?

I am already finalizing the implementation of auto-complete and integrate with a parser that generates the same autocomplete for libraries that were not prepared ...

I'm using rsyntaxtextarea.

My plan had delayed because just implementing other things (integrated documentation in the editor), but soon make available for testing ...

Ricardo JL Rufino

----------------------------------------------------------------------
CriativaSoft - Desenvolvimento de Sistemas com Qualidade
Analista e Engenheiro de Software

Skype: ricardojlrufino

Linkedin: br.linkedin.com/pub/ricardo-rufino/5a/696/81a

[Federico Fissore]

Ricardo JL Rufino ha scrito il 01/12/2014 alle 13:49:

> "One piece we would have liked to release for 1.6 is a new editor:
> trashing away the current JEdit based implementation in favour of a much
> cooler http://fifesoft.com/rsyntaxtextarea/.
> This should also make life easier to the autocomplete feature mentioned
> some threads ago."
>
> Someone else is working on it?
> I am already finalizing the implementation of auto-complete and
> integrate with a parser that generates the same autocomplete for
> libraries that were not prepared ...
> I'm using rsyntaxtextarea.
> My plan had delayed because just implementing other things (integrated
> documentation in the editor), but soon make available for testing ...
>

Not that I'm aware of. If you wish to take care of it, just say it loud :)

federico

[Ricardo JL Rufino]

I'm working on .. ;)

2014-12-01 11:24 GMT-03:00 Federico Fissore <f.fi...@arduino.cc>:

Not that I'm aware of. If you wish to take care of it, just say it loud :)

[Vasilis Georgitzikis]

Guys, I think the conversation has deviated a bit from the Thread's main discussion.

Federico, I love the fact that you mention how we should focus on the *how* of a particular feature. I'm very interested to learn more about how you envision the library manager to work, and I'll go ahead and start the discussion with some of my own questions.

1. First and foremost, will the content be curated by Arduino, Marketplace-style, or by the community at large, package-manager/Linux-style? (or something in-between). There's definitely pros and cons for either, but I'd like to know what you guys have in mind.

2. Just as importantly, will the system be open, or will it be tailored to the Arduino IDE. Of course, I have vested interest for asking this, but it's important for the overall community to know if there will be APIs for other services to access that data, be it other IDEs, package management systems, or any kind of service that want to hook into the platform.

3. Arduino has a great precedence of open-sourcing stuff, but afaik, none of the web services and system used/developed by Arduino have been open sources. Most of that is for good reason, since noone would care too much about the CSS changes you made to a Forum engine anyway, for example. But there's certainly benefit for both the Arduino Team, and the community at large, if this system was open sourced. What are the current plans in terms of this?

Regards,
Vasilis

[PeterFeerick]

Hi Federico,

I can see your point re: discussions on priorities rather than on how to
code a feature or how it should function. That's why if it were to be
done, I was thinking more of a "in the next three - six months... x y z
are the focus... in no particular order..." roadmap - just a heads up so
that we don't start working on something that you guys are already doing
internally or won't be beneficial due to changes somewhere else. I'm
thinking that it would allow proactive development rather than reactive
- focusing on specific goals rather than whatever comes along. As it is
Ricardo is doing some great work on this, I suppose it is a lucky
coincidence he is doing it at the same time you would have liked to had
it done?

Any, some form of "currently working on" updates would be good... just a
peek in the direction that you guys are heading next... And anyone who
argues (rather than constructively discuss) with what you guys say is
next is welcome to jump in the lake :)

Enough from me, I've taken this thread off topic enough. Going back on
topic, I'm very interested in seeing the response to the questions that
Vasilis has raised... I hope you're moving towards some hosted
open-source moderated/maintained 'market-place' that has an open API so
other IDEs that support Arduino can hook into it. If it could hook into
github some way for actual code hosting that would be excellent -
imagine being able to just click 'Add from github' and being able to
copy&paste a URL and it automagically install! (Please note: automagic
requires significant developer time to create, and ceases to function if
you let the magic blue smoke out :-D ).

Peter

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

[Federico Fissore]

Vasilis Georgitzikis ha scrito il 01/12/2014 alle 15:57:

> Guys, I think the conversation has deviated a bit from the Thread's main discussion.
>
> Federico, I love the fact that you mention how we should focus on the *how* of a particular feature. I'm very interested to learn more about how you envision the library manager to work, and I'll go ahead and start the discussion with some of my own questions.
>
> 1. First and foremost, will the content be curated by Arduino, Marketplace-style, or by the community at large, package-manager/Linux-style? (or something in-between). There's definitely pros and cons for either, but I'd like to know what you guys have in mind.

We will maintain a list of "main" libraries (the ones that are already
bundled with the IDE).
Library developers will opt in for being included in the list of
"contributed" libraries. If the tool we are coding likes the structure
of the lib's git repo, we will just fork it. If not, we will create an
empty repo and the lib dev will make pull requests against it.
This is just a way to avoid forcing/asking users to change their repo
structure.
In case a lib does not have a repo, we will make it and just, say,
unpack the zip onto it.

>
> 2. Just as importantly, will the system be open, or will it be tailored to the Arduino IDE. Of course, I have vested interest for asking this, but it's important for the overall community to know if there will be APIs for other services to access that data, be it other IDEs, package management systems, or any kind of service that want to hook into the platform.
>

It will be tailored to the Arduino IDE, but the data will be open: the
list of libraries will be a freely downloadable json file

> 3. Arduino has a great precedence of open-sourcing stuff, but afaik, none of the web services and system used/developed by Arduino have been open sources. Most of that is for good reason, since noone would care too much about the CSS changes you made to a Forum engine anyway, for example. But there's certainly benefit for both the Arduino Team, and the community at large, if this system was open sourced. What are the current plans in terms of this?
>

Most if not all of the web side of Arduino is infrastructure stuff and
we have no plans of opening it. The content is what matters and it's
available under CC-BY-SA license.
We are evaluating to open things like the forum, although its
customizations are mostly cosmetics.

Regards

Federico

[Paul Stoffregen]

On 12/04/2014 01:50 AM, Federico Fissore wrote:
>
> Library developers will opt in for being included in the list of
> "contributed" libraries. If the tool we are coding likes the structure
> of the lib's git repo, we will just fork it. If not, we will create an
> empty repo and the lib dev will make pull requests against it.

Speaking as the author / maintainer of several libraries, I'm not sure
how I feel about this.

Of course it's designed to give Arduino maximum control over what's
presented to Arduino users. If well maintained (a pretty big "if"), I
can see how this could really benefit a lot of Arduino users.

However, I'm not so excited about opting into a system where my own repo
is no longer the primary source where users obtain my code.

[Federico Fissore]

Paul Stoffregen ha scrito il 04/12/2014 alle 15:17:

I see your point.
Purpose of the fork is to have a backup of a library and to give
continuity to users (avoid the loss of a library because its developer
has deleted its repo)

What about keeping the fork but fetching directly from your repo? This
way, in order to make a new release, you will just have to add a tag (no
pull requests)

As for credits, library.properties already has the "url" prop that's
under lib's dev control.

Regards

Federico

[Paul Stoffregen]

On 12/05/2014 07:45 AM, Federico Fissore wrote:
>
> What about keeping the fork but fetching directly from your repo?

Yes, I like that much more. :-)

> This way, in order to make a new release, you will just have to add a
> tag (no pull requests)

Small details matter.

I really hope you'll involve me and other library authors /
maintainers. A really well designed system could really work for
everyone. I know it's a lot more effort to include many stakeholders
with different viewpoints, and I sincerely appreciate it.

[limor]

On 12/5/2014 5:43 PM, Paul Stoffregen wrote:
> On 12/05/2014 07:45 AM, Federico Fissore wrote:
>>
>> What about keeping the fork but fetching directly from your repo?
>
> Yes, I like that much more.

me three! i've got over 100 library repos that are constantly going
updates to support new arduinos (like zero!) and old-new arduinos (like
Due), but we're really good on making sure the current repo works and we
wont be renaming them

fork-to-backup is good, fork-to-distribute will mean its constantly out
of sync

limor

[Matt Jadud]

On Fri, Dec 5, 2014 at 5:43 PM, Paul Stoffregen <pa...@pjrc.com> wrote:
> Small details matter.
>
> I really hope you'll involve me and other library authors / maintainers. A
> really well designed system could really work for everyone. I know it's a
> lot more effort to include many stakeholders with different viewpoints, and
> I sincerely appreciate it.

I would also encourage the Arduino team not to try and invent
something like this without carefully studying the solutions other
language/IDE communities have developed. Handling versioning and
platforms is hard.

* The Racket language group has put long and hard thought into this
problem; I would recommend studying their PLaneT tool
(http://docs.racket-lang.org/planet/index.html) and/or its successor.
It solves problems that less capable versioning/library managers (Ruby
gems) fail on. Many languages have package/library managers, and it
isn't clear that this community needs to reinvent what already exists.
(And, of course, apt, yum, and their ilk provide models, each with
trade-offs.)

* Please involve the developer community in the design and
implementation. Transparency in the design phase of this work is going
to save people like Paul, Limor, and the other contributors to the
Arduino ecosystem huge headaches. And, when you save them huge
headaches, you save me and my students huge headaches, because you
didn't invent something new that works poorly, and thus makes it
harder for me to do interesting things in the classroom.

Put simply, I worry whether an overworked team can do better design in
a vacuum on a hard problem like library management than the resulting
design that would come from a transparent, open process.

Lurking,
Matt

[Vasilis Georgitzikis]

there seems to be two very good keepaways:
1. involve the library authors. they are also the audience of this feature, perhaps even more so than the "consumers"
2. don't reinvent the wheel. dependency/package/library managers have existed for a while, they are constantly improving, and there are many good systems out there. leverage that knowledge.

If you don't mind, i'd like to ask again about the FOSS nature of the system (or lack of). We both agree that Arduino's web stuff has been operational stuff so far, and it didn't make sense to open source them. What's the plan for this?

Vasilis

[Federico Fissore]

Vasilis Georgitzikis ha scrito il 08/12/2014 alle 10:56:

> there seems to be two very good keepaways:
> 1. involve the library authors. they are also the audience of this feature, perhaps even more so than the "consumers"
> 2. don't reinvent the wheel. dependency/package/library managers have existed for a while, they are constantly improving, and there are many good systems out there. leverage that knowledge.
>

First implementation will be very simple: it will just download and
upgrade the libraries, no library interdependencies or sketches that
depend on libraries.

> If you don't mind, i'd like to ask again about the FOSS nature of the system (or lack of). We both agree that Arduino's web stuff has been operational stuff so far, and it didn't make sense to open source them. What's the plan for this?
>

As said in a previous email, there currently are no plans to opensource
the script that will generate the file with the library listing. That
file will be freely downloadable.

Regards

federico

[Andrew Kroll]

One already exists, and it is actually very well laid out.
http://platformio.ikravets.com/#!/

We're listed here:
http://platformio.ikravets.com/#!/lib/show/59/USB-Host-Shield-20

federico

--
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+unsubscribe@arduino.cc.

--

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[Federico Fissore]

Andrew Kroll ha scrito il 10/12/2014 alle 10:45:

> One already exists, and it is actually very well laid out.
> http://platformio.ikravets.com/#!/
> We're listed here:
> http://platformio.ikravets.com/#!/lib/show/59/USB-Host-Shield-20
>

That's actually where this thread started. See my previous email about
why we cannot use tools we don't "own" (and don't forget to read the
meaning of "owning")

https://groups.google.com/a/arduino.cc/d/msg/developers/xCDjekcQW4k/aLM2leqS4dMJ

Regards

Federico

[Ivan Kravets]

Hi all,

Thanks a lot for discussion!

1. I can't understand why "Arduino Community" should own something? The both projects Arduino and PlatformIO are _OPEN_SOURCE_. PlatformIO is licensed under MIT. All source code, including WebSite, API, Docs and PlatformIO tool are hosted on GitHub. See: https://github.com/ivankravets?tab=repositories

2. If Arduino Community doesn't like the domain name like "platformio.ikravets.com" - we can move it to independent domain, like, "platformio.org" /cc and etc. I didn't want to popularise my "own" domain or my surname. I decided to use subdomain, because I didn't know if PlatformIO will useful.

3. I don't plan to "monetise" PlatformIO. I did it totally for _FREE_ and I want to support it totally for _FREE_. If something is missing in our world and I can fix it - I must fix it. It's my credo.

4. The main problem is that PlatformIO represents different vendors, boards and etc. It isn't good for _VENDORS_, like _COMPETITION_ in the one place. But it is useful for the end users. I've received a lot of feedbacks about PlatformIO for the last month, including feedbacks from the several _VENDORS_. All of them received from me the same answer: PlatformIO can't be sold and can't be re-branded to the specific "owner".

5. I love Arduino, I love TI and I love Teensy and I love many more... The main idea was to merge multiple "embedded love" into the one project.

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

It will not be a problem for me if no one use PlatformIO.

What I see in this point: we should discuss general specification for embedded libraries. I know, that Arduino has own specification (I knew about it in this discussion). I proposed the another way:
http://docs.platformio.ikravets.com/en/latest/librarymanager/config.html

All propositions to this specification were applied immediately. I hope, Paul Stoffregen can confirm it. Thanks a lot for his contribution to it.

1. Yes, we have discussion about "frameworks" and "platforms" fields, they are specific "hard-coded" for PlatformIO Crawler. But we can discuss it.
2. The "library.json" doesn't link with PlatformIO, it is independent format. It allows developer to describe own source code via "meta-fields". Developer should not rely on "library.json". "library.json" is very flexible and allows to keep source code in the different locations/folders. No here "SOURCE_CODE_REQUIREMENTS". See examples:

1. The main source code is located in the ROOT of project:
https://github.com/felis/USB_Host_Shield_2.0/blob/master/library.json
https://github.com/PaulStoffregen/OneWire/blob/master/library.json
https://github.com/adafruit/Adafruit_CC3000_Library/blob/master/library.json

2. The source code is located Archive:
https://github.com/ivankravets/platformio-libmirror/blob/master/configs/arduino-xbee.json
https://github.com/ivankravets/platformio-libmirror/blob/master/configs/arduino-nrf24.json

3. The one repo for multiple libs (+ dependencies):
http://bit.ly/136zuLq
https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/library.json
https://github.com/jrowberg/i2cdevlib/blob/master/MSP430/MPU6050/library.json

Have a nice day!

> --

[Andrew Kroll]

Ivan: Well said. +1 to you! I only disagree that it isn't good for vendors...

Have you ever wondered why restaurants are always found in clusters, instead of spread out all over?
Believe it or not, when a restaurant is placed alone, it does not do as well... The same is true for microcontrollers. development boards, software, etc.
Cross pollination is beneficial to the customer AND the provider.
Perhaps someone may want to use your product as either a host or client to a competitor's product because neither product does everything required.

You may gain customers that you never had before because they didn't know about your products.

Finally, if Arduino were to do this, it would actually impress me because it would indicate that Arduino is confident in their own products to the point where they have the balls to do something like this.

--

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.

[Ivan Kravets]

Hey :)

I'm back here with a new PlatformIO 1.0, new development platforms (Atmel SAM, STM32, Teensy and etc). The full pre-release is published in reddit: http://redd.it/2x5h53

It has support for Arduino Due, but I've not tested uploading... I don't have this board :(
I would be grateful, if someone test PlatformIO 1.0 with Arduino Due.

Could you try it with your projects? Thanks a lot!