Show Posts
Pages: 1 ... 58 59 [60]
886  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Library handling on: February 14, 2010, 07:59:21 am
Quote
A good idea per se, but it will break the (for me) precious c/c++ compatability.
I what way?
You are not able to replace '#inlude Foo' with '#include <Foo.h>' by hand to restore c/c++ compatability?
Ever tried to run a Sketch Pde file directly through the compiler? It's not valid C++ code anyway.

You are not the intended audicence for this sort of improvement, and I know you will not have any problems translating the Arduino Sketch-code back to plain C/C++.

Like the homepage says:
Quote
Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It's intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments.
The C/C++ heritage is not even mentioned on this page.

Eberhard
887  Forum 2005-2010 (read only) / Uno Punto Zero / Library handling on: February 14, 2010, 07:30:11 am
Proposals for advanced Library Handling:

Use statement '#library Foo' instead of '#include <Foo.h>' to import libraries
Why:
Much easier to comprehend than the include statement.
Users know exactly where they pull in Arduino library code and where avr-libc code is referenced.
The IDE-Preprocessor knows exactly which libaries to include. It can give an early warning
"Library 'FooHoo' not found"
before the compiler chokes  on the unsatisfied #include statement and spits out some incomprehensible tech-message

Support a library.properties file
Why:
Two questions come up regulary
  • A) Library X does not work with board Y
  • B) Why can't I import an existing library into my own library

Solution:
A Library Foo can have (optionally) a config-file named Foo.properties. This file is parsed be the IDE every time the Verify/Upload process is started and a Sketch inludes the library.
The File supports (for a start) two entries
Code:
#properties for library Foo
depends=Wire
boards=arduino.Mega arduino.Nano xmega.XPlain

The depends entry lists all Libraries that the current Library is build upon and which have to be compiled and linked into to project to make the sketch work.
I our example Library Foo uses the Wire-lib.
There is no need for hacks anymore, like mentioning the Wire-Lib in the Sketch-code even though it is never exlicitly called.

The boards entry lists all the boards that are supported for by the code.
boards.txt should  provide a unique key for each board like the examples used above. The arduino. is a kind of namespace-id which will make is possible to write a Library for third party boards.
myXMega.XPlain in the example would be a board from the external myXMega project. The parser supports wildcards arduino.*.

For backward compatibility the existance of such a file is not enforced. If no Foo.properties files exists, the library will be comiled for all boards (no matter if it supports the hardware or not).
888  Forum 2005-2010 (read only) / Uno Punto Zero / Third Party Hardware support on: February 22, 2010, 05:42:50 am
Hi,
this already works basically but the concept could be taken a bit further
Suggestions
  • The Boards-menu should be made into a new toplevel menu. There  is no relation to the other items in Tools like autoformat.
  • The third party boards should apppear in a dedicated sub-menu of the boards menu which is named after the core they belong to.
  • Import libraries should group the available libraries in submenus by the core they belong to.
  • Programmers should be grouped in submenus by the core in which they are defined.
  • Support a dedicated sketchbook-folder for libraries written for a specific core.

Eberhard
889  Forum 2005-2010 (read only) / Uno Punto Zero / Re: After 1.0 on: February 12, 2010, 03:34:20 am
Here is the annoucement:
http://arduino.cc/blog/?p=392
Eberhard
890  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Why discussing anything IDE related anyway? on: February 13, 2010, 04:35:47 pm
Quote
That still leaves lots of room for changes and improvements.
Maybe, but I also lost faith that this call for improvements in 1.0 will lead to anything concerning the IDE.
For me (and from what I read in other posts quite a few other people as well ) this is the most annoying part of the whole Arduino-Thingy.
The hardware, core/libraries, basic idea ,documentation , I have a lot of respect for this ...
... but when it comes to the IDE  :'(
Its not fun to work with, its buggy, its the part of the project in bad need of improvements.
And since I expected the answer...
Quote
In the particular details of text editing and window management (as shared by Processing), you're right that I'd rather defer to Processing.  
...I didn't feel like it was worth posting anything into this part of the forum.

No matter how many shiny new chrome-fittings Arduino 1.0 will have under the hood, People will still point with fingers at us and say
Hey look, the Arduinos are still driving around with their rusty old Processing-GuiMobile  ;D

Eberhard

A question that needs to be investigated : Is this a German thing?

Pages: 1 ... 58 59 [60]