About “Stage All”, should it add all files (including new ones) or just the modified ones that are already in version control?
I think that there can always be files which you do not want to add to the version control. So I would do the latter.
1 Like
Got another issue I forgot to report!
It seems like fields marked are final work as intended for primitive types, but will make any object reference be a reference to const (that is, forbidding object changes through fields and methods) instead of a const reference (forbidding changing which object is pointed to). In java, there is no language-level facilities for constant objects.
2 Likes
D’oh, you’re right, it needs to output Type * const instead.
Error: : Could not find zombies
The line number and the source file name would be very useful 
2 Likes
Ain’t that a winning condition? 
3 Likes
It would, but right now the compiler doesn’t know which line caused the error either. 
I tend to do that anyway, but I don’t use staging to do so,
I’m just careful about how I construct my commits.
Fun fact for people who don’t know the difference:
const in C++ is actually supposed to apply to the thing to the left of the const, e.g. Type const means Type is const, Type * const means that the pointer is const but Type isn’t const, and Type const * const means Type is const and the pointer to that is also const.
The ability to write const Type is actually an exception to the rule,
but through some fluke of history that’s what became the more commonly used version.
(There’s a few flukes like that, like ++i being cheaper than i++, but the latter being used more often.)
For what it’s worth, Arduino uses the #line directive in the C++ files it generates from .inos.
A horrible abuse of a silly directive, but it works.
1 Like
Generally Femto works very well 
It is surprisingly mature for such a new tool.
The biggest problems that is slowing down the development are the error messages:
- Sometimes the message do not show a file name or a line. This is quite laborious as you have to memorize what you have changed since the last ok build, and try to re-implement them one by one
- Often error messages are very cryptic (I still do not know what is the problem with my enum
Switched to consts instead. ). This is quite much contradicting the rest of the UI which is generally beginner friendly. - I would expect a red color to indicate an error, but it is not.
- A small improvement would be to show the variable names in brackets or in different color to avoid confusion with variable names
- If the error comes after generating the C++ code fron Java, resolving it needs C++ skills, not only Java skills. I expect this is not easy to fix, but showing the line number in original Java code would also help here.
I can make issues to GitHub of these after the review.
3 Likes
If the generated C++ code is saved somewhere accessible then I can probably point out where the translation is going wrong if someone has a specific problem.
I suddenly remembered what Java’s concept of an ‘enum’ is…
In all honesty if enum isn’t working at the moment then you might as well make a class with a load of public static final members because in Java it amounts to roughly the same thing.
There’s only a small number of specific differences between a Java enum and a Java class with public static final members :
And if you’re particularly observant, you’ll realise that this means Java enums are basically all singletons with multiple instances (polytons? n-tons?), and a Java enum with just one value is literally a singleton.
I’m confused by this point.
Did you mean put the type names in colour to avoid confusion with variable names,
or do you mean highlighting variable names in error messages?
1 Like
If you happen to have a variable named “zombies”:
Instead of this:
Error: : Could not find zombies
Show this:
Error: : Could not find "zombies"
3 Likes
I meant the Java compiler doesn’t know, not the C++ one. The error he’s seeing happens after all the code has been correctly parsed and it’s resolving references. The function that looks for a symbol takes a name and a scope, it doesn’t know where that name came from.
It’s a matter of propagating token data everywhere.
Yeah, I know they’re important, but I haven’t had a chance to give the error messages the attention they need yet. The focus so far was to get correct code to do the right thing.
It would be good to have issues for these things on github, but they’d need to be as specific as possible. A simple snippet demonstrating the issue would be the awesome. Especially for the instances where it is generating incorrect C++ code.
Red color is supposed to indicate an error. Is there any case where it doesn’t?
I’ll add quotes to the “Could not find” error.
As for enums, as @Pharap has pointed out, they are very different compared to C++ enums. They were only partially implemented because what we probably should be using is actually a const.
2 Likes
I will do it next time I get one.
This also.
There could be a list of unsupported language features in the Wiki.
2 Likes
You could shoehorn it into the comments somehow.
E.g.
//~ @line43 - var 'myNumber'
int myNumber = 0;
Nobody is going to look at the generated code anyway.
(At least, not unless they know what they’re doing or they value their sanity.)
You’d have to pick something that wouldn’t clash with Doxygen though (hence the //~).
I doubt many people will end up using Doxygen, but in the distant future Doxygen could possibly be used as a means of supporting Javadoc.
Or possibly constexpr.
I doubt the generated code would try to use it in a way that would require it to be constexpr, but it’s plausible.
@FManga can’t manage all this on his own, we need more people doing stuff like wiki editing.
Though admittedly I’m not sure how anyone else would know what is and isn’t supported…
1 Like
I said const since that’s what @Hanski mentioned in his post, but since we’re talking about Java code, that should actually be final. The suggestion is that we should use final int instead of enum in Java.
Indeed, any help in maintaining the wiki would be most welcome.
2 Likes
How much of an effort would it be to start documenting the Java library with Doxygen and generate a documentation page that way?
For one thing I’m concerned about the Wiki missing type information - Doxygen would prevent that.
For another it would provide a complete list of classes and functions regardless of whether or not they have actual detailed information yet.
The wiki could still be kept for examples, though I think Doxygen might have a way to incorporate that sort of thing somehow.
1 Like
The library is still small, so it wouldn’t be too much work for whoever attempted it.
I worry more about fragmenting information and having the library documentation in one place, the rest of the wiki information in another.
If Doxygen could be used to fill in the wiki it’d be ideal.
I don’t actually know how to do it, but I know it’s possible to use Doxygen to create a sort of hybrid of code documentation and guide/FAQ/Tutorial.
For proof, take a look a Eigen’s documentation:
http://eigen.tuxfamily.org/dox/
The question is just a matter of how they achieve that.
You can embed code examples in the Doxygen output.
Though I don’t think separating information about the IDE and the Java library would necessarily be a bad thing.
They are mostly separate concerns. (From an external point of view at least.)
If the wiki was changed to be a separate website hosted on GitHub then I think it would be possible to supplement the Doxygen output with additional info to turn it into a Wiki.
Though it would be a Wiki that relied on commits and PRs rather than the traditional approach of allowing anyone to edit and having it instantly update.
What I don’t know is how to do that, but I can do some more digging.
I figured out how to get .md files included in the document tree about an hour or two ago but I’ve had no luck with figuring out a good way of grouping them.
Once I’ve figured that out it would probably be possible to simply embed the existing wiki text into the Doxygen output in a decent way.
That said, while it makes sense to include code examples and maybe some demos with the Java library documentation,
I still think it might be better to document the IDE separately.
I’ve also discovered Doxygen can generate ‘man pages’ in case any Linux-lovers out there wanted a copy.
Unforseen bonus maybe? :P
Edit
After yet more searching I finally tracked down a blogpost with a demo of what I needed to know and figured out how to make a hierarchical page list work.
http://alesnosek.com/blog/2015/06/21/the-structure-of-doxygen-documentation/
Basically in each markdown file you have to have:
# Title {#page_id}
@subpage subpage_page_id
Which isn’t ideal, but you can make it match the directory system so it’s less confusing.
Could probably also add in a step to automate the generation of the necessary directives if need be,
but getting that working cross-platform wouldn’t be as easy.