Ok so dumb question moving forward.
If we are porting a library that uses stoffregons WString classes which is already in wiring do we make it work by hacking the print library to support it or do we wedge it and wait?
I am trying to port the WireFree library for the gainspan wifi modules.
https://github.com/diysandbox/Wirefree
gbulmer
Moderator
feurig - I must admit, I tend to be conservative, and avoid complexity.
I am not super keen on that String implementation for this application. It isn't C++ string or basic_string, and seems much more sophisticated and complex than necessary. I am not keen on deriving from 'printable' class in a simple environment which lacks a robust file abstraction, and its use in many places in that code seems to be purely to get something printable. I'd try to avoid that.
WARNING - IIRC, malloc/realloc might not be set up properly on Maple, but I'd need to go check.
Scanning the Wirefree code, it will be work to remove String. So, if String does work, it may be best left in place in order to make progress.
Looking at WireFree's source (*.cpp), there are 35 uses of 'String'.
1 is a comment
4 are printable messages containing the word String.
13 are definitions of functions which take a String as an argument.
Of the remainder a lot of the uses of String are just to make something printable (8+).
In some places it concatenate several strings so that println can be called once, which would be unnecessary if String returned a const pointer to its buffer (like C++ string c_str).
So all the machinery of that String implementation is being used to create a String, concatenate a value, print it, then destroy the String, and garbage collect the free'd space when it goes out of scope, just to avoid saying, e.g.
Serial1.println(cmd_tbl[cmd].cmd_str); Serial1.println(this->security_key);
A lot of the other uses of String are equivalent to strncmp(). Others are concatenating a character onto the buffer.
So an adequate replacement for String might be very light-weight.
I'm not a big fan of converting things like 16bit IP port numbers into strings, IP addresses into strings, etc. I tend to try to encapsulate the semantics into a class (e.g. a URL might be a string or an IP address) rather than squish stuff into a type (like a String) which can later be used to reconstitute the semantics. But that is probably not worth any effort.
Possible approach:
Test String, and if it works, try to get Wirefree working with String.
Then add a (const char *) cast to String, so that String isn't needed just to print an array of char, and then ditch that print code.
Maybe build a wrapper which would unify Serial1 & Serial, so that the most of Wirefree doesn't care which MCU it is being compiled for.
If I could find the time and energy, I might replace that big, smart String, and build a small, light-weight string that is free-standing, and independent of the ability to print, but that seems like a lot of work for little benefit.
Just a comment: the only links found by Search on the Wiring site for WString are to bugs in a destructor which took about three weeks to fix. I downloaded the code, and can't find any unit tests for String, which saddens me.
Summary:
Test that String works. If it does, then get Wirefree working using it.
If you folks have the energy, consider unifying the output class (Serial & Serial1) so that Wirefree doesn't conditionally compile for two different boards. That appears to be a real improvement. Once that is done, replace the uses of String where its only behaviour is to print text.
Thanks for looking at this. You pretty much came to the same conclusions I did in relation to the String usage in WireFree.
If I were to replace the string I would ditch the c++ style printing altogether. It is just dumb. I would rather create a printing function that snprintf's into a static buffer and sends it.
gs.printf("%s %s",cmd_tbl[cmd].cmd_str),this->security_key);
String from arduino 1.0 does work without too much trouble. String from wiring had a few more dependencies so I didn't push too far in that direction. I will try the casting and then we should be good.
The serial handling in gs.cpp is clearly an "I need it now" hack and should be replaced with a macro or a pointer.
But the greater and greater disparity between the arduino 18 libraries and the current Wiring platform begged the question a bit.
It had occurred to me where the hardware isn't the issue (like with the new print/stream/string changes in wiring) that It would be an interesting effort to merge most of the wiring libraries with libmaple so that there are less porting issues in general.
gbulmer
Moderator
feurig - I'd assumed you'd done planning and analysis, but I thought it might be helpful to give some detail of my thinking.
I hope that that Wiring's String class is dropped.
I do not like types inheriting from printable.
It's fine for types to have a mechanism to convert themselves to strings (of some form). I prefer types having a standard way to yield a C-string value (or a very simple string), like Java toString(), and handing that to whatever output functions exist.
LeafLabs have announced that they are working towards Wiring compatibility.
I now feel I need to look harder at the Wiring library. That String class causes me to feel less confident that Wiring is a good target. If String is the only weakness, then I'll be delighted.
Rod
Member
I can donate a 200 line printf that does "udxXcs%' plus field widths in sprintf and printf mode and runs on the Maple Mini STM32 as a starting point if anyone would like.
Its basically stripped down to do everything in 32 bit ints for simplicity. Started from tiny printf by Kustaa Nyholm http://www.sparetimelabs.com/tinyprintf/index.html
Rod,
I need to get a little time to look at the code it will be nice if I ever get back to resource starved micros. For of my work avr-libc and newlib's implimentations work well enough. The C++ "clunky at best" io is pretty much what kept me from learning it 18 years ago. It still sucks (more so in this environment). I wish the wiring/arduino folk had abandoned it but they didn't. So we are stuck working on compatibility.
gbulmer,
Most of us would probably take a different approach than the Arduino Community but it has an established code base supporting an amazing amount of peripherals. Because of this code base an amazing amount of prototyping can be done very quickly as long as the libraries are compatible. (Here watch while I pull a wireless data-logger out of my hat). When the maple deviates or gets significantly out of sync with the Wiring/Arduino libraries we loose a lot. IMHO The wiring team is definitely the more disciplined of the two (zb look at the bootloaders) and subsequently they tend to lead the way. I hope that the merger of the two code bases moves more quickly so that I don't wind up porting and then reporting later :)
gbulmer
Moderator
feurig - I've been using Arduino for several years. I think I am still a 'god member' over there, and haven't posted since 2010. So I do think I understand the value of Arduino technology, community, and what it has achieved.
Compatibility is valuable.
IMHO, people who care about the technology underpinning a community should not silently accept something purely for the sake of compatibility. That mindset would have been a hurdle to electric street lights, national power grids, the transistor, PAL television, 3-pin power plugs, horses for ploughing, UNIX, C, Haskell, Erlang, Python, the steam engine, Java, Ruby, Golang, AVR, ARM, the Internet, the Dollar, the Gregorian calendar, the Euro, digital TV, steel, digital radio, etc (an extremely long list, not all of equal importance :-)
I think something which seems complicated needs to be challenged. How will people within a community recognise that there is such a thing as 'taste', or that people should care about 'taste', or that there are technical tradeoffs to be balanced? (I am involved in education, and I hear stories from employers who are very concerned at the ability and judgement of school children, undergraduates and post graduates. IMHO, trying to examine components is helpful to improve our critical faculties)
IMHO discussion should not brushed aside for the sake of compatibility. I worry; how could a single individual feel empowered to contribute if their contribution might break compatibility?
I think my view that Wiring's quality needs deeper analysis on the basis that it includes a complicated, monolithic String class is a reasonable and defensible observation. I agree, there is very little value in diverging for the sake of it.
I think I can deal with my concerns using an ad hoc approach. If it were a very important issue, to many people, I think we could gather some stats on actual uses of String, to get a handle on whether diverging on that class would be a big issue. I genuinely don't know if it would be an issue. Most people discourage the use of managed memory, so it may be irrelevant. I suspect that there are a bunch of okay alternatives.
I am not sure that comparing the discipline of the Wiring team with the Arduino community is a 'like for like' comparison. What is 'discipline'? Delivering on time to promise? Not delivering anything until code is high-quality? Delivering small incremental improvements regularly and frequently with no quality regressions? Not taking anything out once it has been delivered? Not including stuff which is complicated? Only including new stuff which has an understood need?
I feel that an assessment of discipline also needs to consider the pressures involved. In my experience, it is easier to deliver software where demands are modest, versus in a high-pressure situation. If the quantity of forum activity is one measure of the pressure on a team, then the Arduino's forum has more people on line much of the day, and more topics and posts in a day than the Wiring forum has registered members, or posts in its published history.
I am not suggesting that the Wiring team are not effective, only that the Arduino team has a lot of pressure to deal with.
AFAIK, the Arduino team has not responded to the Wiring team on the questions of merging code bases http://forum.wiring.co/index.php/topic,37.msg267.html
You should hang in the #wiring channel for a bit.
And as to the quality it is not a like like thing, again look at the bootloaders (Half of the bootloaders on my clients mega2560s have a fairly nasty known bug that is well over a year old, they die if you enable the wdt (until you reflash the entire chip)) Compare the code (which looks and acts like a hack) to that in wiring current.
gbulmer
Moderator
feurig
You should hang in the #wiring channel for a bit.
Why?
I have no issues with active collaborators using channels.
Typically, when I am not an active collaborator to a project, but instead I am a user, then I prefer a project which has tactics and strategies which scale well, and are convenient for my time frame. Documentation, forums and wiki's can scale. Channels don't seem to. Documentation, forums and wiki's are asynchronous, which suites me very well.
You must log in to post.
