Forum : Ride IDE
| Post Information | Post |
|---|---|
|
March 10, 2008 - 11:03am
|
I accently moved a folder to top level in project tree. This caused RIDE to crash. All in all I am starting to regret that I bought 2xRLink Pros for use in our software development and figured I would use RIDE's IDE for developing because it uses the GCC compiler which is nice. The RIDE behaves like something developed by amaturs and it seems that the answer to all errors is to crash with the loss of data as an result.. Its been 3months+ since the last release and I would really like to see the following fixed: Sorry for my harsh tone, but I needed to let out some steam because it just crashed as I had libraries and RTOS configured and was ready to start on the fun part of implementing :-P /Henrik |
- When adding new files please remember last used directory. Often you want to add several files from the same source tree, for instance when adding FreeRTOS support there are several directories in the same source tree where you need to add files)
- Alternativly add support for drag and drop of files from a filemananger or another RIDE7 project window
We will check -and fix- these issues in the next days (a new release is planned for very soon).
Thanks for the report.
- RIDE crash when to many local variables are in view during debugging.
For this issue, we don't believe that the number of variables could be an issue. Probably a specific variable would be the cause. If you could help..
Thanks.
More information:
"RIDE do not go to definition unless you have selected the function/variable"
known, should be already fixed
"Break on memory changes are not implemented."
Watchpoint have been implemented for the STM32 (Cortex M3) for the next release.
Thank you very much for the heads up on upcoming releases.. Sounds great - I think Ride is pretty decent, but I do have a hard time accepting program crashes, because they tend to interrupt your work horribly..
The other issues are minor compared to program crashes..
With regards to the crash on local variables..
I have enabled the watch local's window again and will try to get some more information.. Unfortunatly I can not disclose the projects I work on..
Right now it seems to work in the spots where I had problems.. Wierd... I will keep you posted on that one.. Could it be when RIDE can't find a structure or a local variable that it think is defined?
Another thing that is starting to bug me as the project I work on get's bigger.
Is that I have found that Ride gets rather slow when the project contains lots of source files. My current project contains 107 c source files.. and 11 include directories.
Task manager reports:
MemUsage 43MB - User Objects 336 GDI objects 552
I do realize that there is some housekeeping when messing around and saving project, etc.. But I think it would be reallly nice if it was
able to save the project faster (atleast while it still is crashprone, hehe) . As I started out by saying things like this are minor compared to when the IDE crash..
With regards to the speed I tried to get around this by attempt to make a library of some of the files - This caused RIDE to complain that the variable $(tools.librarymanager) or something like that was not defined. I just discovered this.. And have not made further attempt at fixing it.. Need to get some other work done..
Best Regards
Henrik
With regards to creating a library. It worked when I made a standalone library project and not just created it in the existing application project
Henrik,
I had worked last year a few weeks on the CicleOS project (www.stm32circle.com). I can't say 'without crashing' but honestly, I don't remember whether I crashed... Therefore, the crashes you experienced are probably linked to something special in your project. Because of the project size? It's true that CircleOS is much smaller (20-30 files only).
Anyway, we will try to find out the reason by analysing the 'reports' generated that you can send by email.
We are testing the new release and, hopefully, it should be posted early next week. Let us know if you still encounter these problems.
Then, we will work on making the "load/save" faster for the projects.
I will test also the library generation with this next release.
Francis
I work with RIDE around eight hours five days a week, and have done so since November last year...
I have figured out how to avoid most of the crashes. But as I added a slew of new source files last week, RIDE exploded on me again. Now I crash atleast twice a day + the speed have slowed down quite a bit from all those files. Just had my first crash today.
I have not yet figured out any way to avoid those crashes, All I can tell is that it typically crash when compiling.
Have sent my report and will continue to do so ;-)
Another small issue I discovered last week is that when you add two parts in a project (Library and application) and you have selected one of the files in the library (selected in the project browser) RIDE gives you the error "Error Launching the debug session" - Seems RIDE attempts to launch debug on the library file. Even though the application is set as startup project.
When select a file from the application par of my project the debugging is started no problem.
/Henrik
I have a side question..
When including another project what is $(ApplicationDir) for that project set to? I just worked on the Library in a project for it self, but after opening the Application project which also include my Library project (So I can debug the source code in Library). $(ApplicationDir) in my Library project was set to the Application's directory and all my source files in the Library project was also changed to be based of ApplicationDir.
Is there a place where I can see what $(xxx) variables I can use to in projects?
Ah I removed the Libary project and added it again.. Now $(ApplicationDir) for the Library is what I expecetd (the base dir of Library project) ;-)
Best Regards
Henrik
We now reproduce some crashes when the number of files is greater than 100. We are trying to fix this issue before the next release.