Sloeber eclipse plugin V4 & ArduinoJson 5.8.2/5.8.1

[hreintke]

Hi,

I do not know whether it is an issue with ArduinoJson or Sloeber eclipse plugin but using the combination I get errors for both Arduino Nano & ESP8266 projects. C:/Utilities/sloeber/arduinoPlugin/libraries/ArduinoJson/5.8.2/fuzzing/fuzzer.cpp:3:39: error: expected class-name before '{' token class memstream : public std::istream { Using 5.8.0 -> no problem

[jantje]

Thanks for the input. The reason this happens is because the arduinoJoson library contains other files and folders then the pure code. Some of these files/folders are considered code by sloeber and not by the Arduino IDE.

So to fix the problem (in eclipse) go to you project open the libraries folder open the Arduino Json folder. you will see that fuzzing is a folder. This folder should not be part of the code. The fact the folder also contains a makefile is a very good hint it should not be part of arduino code. To exclude this folder from the build right click the folder->resource configurations->exclude from build. In the pop up select select all and OK. Now fuzzing should be grayed out.

Note that the main problem here is that Arduino IDE works with a inclusion filter and CDT (as such Sloeber) works with a exclusion filter

[bblanchon]

Hi,

The ARMmbeb IDE solves this problem with a .mbedignore file.

Would it be possible to implement a similar feature?

[jantje]

an ignore file is a exclude filter just like eclipse uses. The problem here is that the current ignore filter is not ignoring fuzzing Another problem is that eclipse/CDT does not support "not like" which would make it possible to make it a include filter. You can see the filter used in the project properties->C/C++ general->path and symbols->source location->in the source folders on build path open your project and select the filter. Note that this filter is created at project creation so the filter is dependent on the Sloeber version you used to created your project. In the project I investigated the problem I have: As you can see I added the folders scripts and fuzzing from ArduinoJson.

So to really fix this problem a "not like" selection filter should be added to CDT. Or arduinoJson could comply to the arduino library specification https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification as a 1.5x library (in other words the source is in the src folder ) and not a pre 1.5x library ( the source code is in the root folder)

[Gerry33]

Hi all, may I join the discussion as I'm obviously the originator at https://github.com/esp8266/Arduino/issues/2900

I do not know if its the final solution, but with the above changes suggested by @jantje above, I was able to compile and link succesfully the JSONLib examples and also my targeted project 'homie' https://github.com/marvinroger/homie-esp8266

I will now try to get it running.

For now thank you all very much for your kind assistance to @jantje, @hreintke and @bblanchon. br Gerry

[bblanchon]

@jantje For your information, I stopped using the 1.5.x library layout because it was causing problems with the many alternative IDE: ARMmbed, Energia, PlatformIO, Stino and Visual Micro to name a few.

I switched to header-only as it was the only way to make it work with all of them and the number of support requests on that topic drop dramatically since them. So, no, I'm not switching back to the 1.5.x layout.

@jantje I don't understand why you're building the .cpp files in the subfolders. Arduino pre 1.5.x didn't do that; it just built the .cpp in the root folder.

[jantje]

@jantje I don't understand why you're building the .cpp files in the subfolders. Arduino pre 1.5.x didn't do that; I just built the .cpp in the root folder.

Sloeber is based on top of CDT. CDT is a C/C++ development tool with C/C++ mindset. Arduino IDE (and most of their specifications) were more a java mindset.

Anyway in C/C++ world a folder is compiled inclusive all subfolders. So this is what CDT does. Because some people added folders for other things a "exclude from source" was added. But better of course is to add a src folder -only containing code- next to anything else (like in the Arduino 1.5.x layout) ;-) .

Arduino pre 1.5 states the following 2 folders (if they exist) must be compiled . and ./utilities. This is why I add . (this automatically includes ./utilities). Other folders need to be excluded. Typical folders are examples, extras, test, documents with or without a starting capital. So these have been put in the exclude filter by Sloeber. As you can see in the filter above I added all folders starting with c d and D. This because users reported problems on those. To add all letters except for u of utility I would need to have 26+25 filters and then url would still be compiled.

So it is not my choice it is the standard C/C++ way of doing things. As Sloeber runs on a standard C/C++ IDE this is its behaviour.

If you prefer sticking to pre 1.5 format I think the safest you can do is put all non code stuff in a folder called extras. This is a "old" format so probably supported by all tools.

[hreintke]

I have a workaround. Closing this issue

[jantje]

@hreintke Is your work around different from the one I explained? If so can you elaborate?

So to fix the problem (in eclipse) go to you project open the libraries folder open the Arduino Json folder. you will see that fuzzing is a folder. This folder should not be part of the code. The fact the folder also contains a makefile is a very good hint it should not be part of arduino code. To exclude this folder from the build right click the folder->resource configurations->exclude from build. In the pop up select select all and OK. Now fuzzing should be grayed out.

[hreintke]

@jantje : The workaround you mentioned works but has the disadvantage that it needs to be done for every project which needs the library.

For now I just remove the fuzzing directory from the library (sloeber/arduinoplugin/libraries/....)

[jantje]

That is a very good alternative :-)

[jantje]

I'm reopening as I'm planning to add libraries/?/f/?* to the filter

[rlogiacco]

@jantje you knowthis already, I advise against adding those exclusions. Since no better solution is available for now (like inclusion patterns) I believe the workaround applied on a per project/library is still the best option.

[jantje]

@rlogiacco He welcome back. I'm sorry but I forgot that you advised against those exclusions. Can you remind me of your arguments?

[rlogiacco]

Thanks @jantje! If you remember I was surprised about the lack of inclusion support and I tried to fix that myself, but I could only confirm your conclusion: there is no better way, at the moment, than list exclusions.

My point about this is having a long list of default exclusions is going to slow down all Eclipse installations (ok, that is probably going to be unnoticed), but only a few libraries will benefit from that, not to mention the clutter we'll create: all those users opening that configuration panel will wonder what is the reason for that long list of exclusions and they can only remain puzzled.

I understand you wish to simplify everybody's life when adopting Sloeber, on the other end I believe it's normal Sloeber users are looking to step up from Arduino IDE, which means it's normal to take more responsibility and greater awareness of what's under the hood.

Arduino IDE does a great job at making life simple for starting, I believe Sloeber should aim at making life simple for experienced users. As an experienced user I should understand the pattern inclusion/exclusion and be able to handle them.

Sorry for my long winded response 😁

[hreintke]

@jantje @rlogiacco : New to Sloeber plugin so not talking with experience.

In my opinion @rlogiacco is right that a long list of default exclusions is not the best solution. Besides his arguments, you never know which library will suffer from these.

For a solution I liked the idea of @bblanchon, a library can state the exclusions in a ".sloeber" file. In this way you create a standard way handing these situations and leave the "exclude list" to the library maintainers.

[jantje]

Thanks for the input. I'll think about this. I don't think a .sloeber file is a slution because all not utility subfolders should be ignored so no file is needed for that. Sure no ide specific file

[DavidR1953]

@Gerry33 Did you ever get Homie working? I can build OK, but it fails on run with an Exception (28) Can you share your experience?

[Gerry33]

@DavidR1953 Hi David, I do not yet use HOMIE as I wait for the final 2.0 release ( and I do no have the time right now....)

I have built my own MQTT- environment for my ESP8266 devices with simple GUIs where I can configure everything. I will publish it on GITHUB soon.

However, HOMIE has the superior basic structure for MQTT. I will change when V2 is available. Sorry I cannot help on that. Perhaps address the Excp. to the HOMIE guys.

Best regards Gerry

[DavidR1953]

@Gerry33 > Perhaps address the Excp. to the HOMIE guys.

I have successfully built and run Homie v2 (master) using PlatformIO so I know the code is OK. It seems to be an issue with Sloeber. I'm trying to compare the build scripts of each, but it's a struggle. Hopefully jante can pitch in. Thanks for your input.

[jantje]

I'm used to comparing compile outputs by now (at least arduino ide versus sloeber) If you send me these I can compare

[DavidR1953]

Thanks for the offer. I'm going away for a week and leave really early so don't have time to prepare it now, but I'll do it when I get back.

Warm regards,

David Read

On 28 Mar 2017 21:54, "jantje" notifications@github.com wrote:

I'm used to comparing compile outputs by now (at least arduino ide versus sloeber) If you send me these I can compare

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Sloeber/arduino-eclipse-plugin/issues/642#issuecomment-289901328, or mute the thread https://github.com/notifications/unsubscribe-auth/AVsycLdDg0qQyTK8JPW4nle5qDQw-2Bwks5rqXNogaJpZM4LtbPd .

[Gerry33]

@DavidR1953 Hi Dave, regarding your exceptions reboot, I made an obervation with one of the underlying libs of HOMIE named "async-mqtt-client".

When changing my code from the MQTT lib ("https://github.com/knolleary/pubsubclient)" to (https://github.com/marvinroger/async-mqtt-client) I observe frequent exceptions with reboots in my code that come out of nowhere and in a place in the code also in the nowhere.

The rest of the code is the same, just the On/OffConnect to MQTT and mqtt Send are adapted from "pubsubclient" to "async-mqtt-client".

So I can exclude a coding problem in my code. I changed back to "pubsubclient" and everythings runs smoothly. I'll kick "async-mqtt-client" for now.

BTW, do you have DHT sensors running within your project ? I use an asynchronous lib for reading DHT sensors (PietteTech_DHT) and somewhere in that area the exception reboot happens. As said, the same code works perfect with MQTT's "pubsubclient".

Regards Gerry

[DavidR1953]

@Gerry33 I'm out of the country with limited internet and replying to the email so hope it works. I'll certainly try playing with the mqtt client when I get back, on Thursday.

Regards, David.

On 2 Apr 2017 12:56 p.m., "Gerry33" notifications@github.com wrote:

@DavidR1953 https://github.com/DavidR1953 Hi Dave, regarding your exceptions reboot, I made an obervation with one of the underlying libs of HOMIE named "async-mqtt-client".

When changing my code from the MQTT lib ("https://github.com/ knolleary/pubsubclient)" to (https://github.com/marvinroger/async-mqtt-client) I observe frequent exceptions with reboots in my code that come out of nowhere and in a place in the code also in the nowhere.

The rest of the code is the same, just the On/OffConnect to MQTT and mqtt Send are adapted from "pubsubclient" to "async-mqtt-client".

So I can exclude a coding problem in my code. I changed back to "pubsubclient" and everythings runs smoothly. I'll kick "async-mqtt-client" for now.

BTW, do you have DHT sensors running within your project ? I use an asynchronous lib for reading DHT sensors (PietteTech_DHT) and somewhere in that area the exception reboot happens. As said, the same code works perfect with MQTT's "pubsubclient".

Regards Gerry

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Sloeber/arduino-eclipse-plugin/issues/642#issuecomment-290978917, or mute the thread https://github.com/notifications/unsubscribe-auth/AVsycHfdSHf_VSkFzBdXFJJH_Wa85ITHks5rr37bgaJpZM4LtbPd .

[Gerry33]

@DavidR1953 Don't hurry ! First have a safe way home, then the rest will align ...

Here is some additional information which might be of general interest:

As said above, I have a DHT library "PietteTech_DHT" based on interrupts included in my app. When I remove this lib from the code, everything works perfect.

So in my case "PietteTech_DHT" and "async-mqtt-client" (and its underlying ESPAsyncTCP-master lib) do clash. Removing either of these libs, everything is fine.

HTH Gerry

[jantje]

I'm going to parse the folder and add folders to the exclude path as needed when the library is attached to the project