Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Plugins development / Re: RFC: ccmanager ignores requests for completion.
« Last post by Pecan on Today at 06:32:16 am »
... because this change introduces a incompatible binary change (signature of function changes). So i wonder if this could lead to quite high PLUGIN_SDK_VERSION_RELEASE  numbers in the future...

For my education, where does this patch change the call or function signature?
2
Great news...
  • DAP debugging working on Linux
  • DAP debugging working on MacOS - see attachment
Now the not so great news. There are some issues on the Mac:
  • The code to run the following does not work, so I need to manually run it and comment out the code:
                  /usr/local/Cellar/llvm/14.0.6/bin/lldb-vscode -port 12345
  • I have had C::B crash when doing some debugging
The source code for the DLL and plugin is available from the following repo, but be aware that it is only for the hard core developers and WILL change and is NOT production quality or even beta quality:
    https://github.com/acotty/CB_Debugger_DAP_Plugin         
In the next few hours I will do a major update on the following repo to include all of the changes so you can use it to build C::B with the plugin:   https://github.com/acotty/CodeBlocks_Unofficial_Testing
BTW There is an issue with the main workspace I am using where I have specified the plugin depends on the DAP DLL, but the DAP DLL does not get built before the plugin so the plugin link fails.
Note: Working is used very very very loosely above.


3
Hi, Pecan, thanks for the patch. It also looks good to me. :)
4
Plugins development / Re: Code completion using LSP and clangd
« Last post by Pecan on Yesterday at 06:57:16 pm »
I'm using the latest nightly in a Windows 7 pro 64 bit OS and for the first time I tested your implementation of the code completion using Clangd. Overall I like it and it's working but I have the following comments.

@Max
Firstly, thanks for testing.

Regarding 1)
You do not have to wait for the background parsing to finish.
Active editors always get parsed first, then inactive editors, then background (non-editor) files. Newly opened editors go to the head of the queue and get parsed ahead of background files. Code completion requests also go to the head of queue.

There's no need to wait after the active editor is parsed (3 to 7 secs).
 
When I open CodeBlocks workspace (31_64), the active editor is indexed by clangd in a max of 7 seconds. All open editors have been indexed in less than 30 seconds. But I never have to wait more then 3-7 seconds to use code completion or other clangd features from within the active editor.

All those files being parsed in the background are used to fill the symbols tree. They're parsed in order of last-changed-time, then last-opened-time then all others so that the symbols tree gets filled with the most likely used files and symbols.

Regarding 2)
Currently, changes on a single line need to be saved manually. Changes on multiple lines usually are recognized and clangd reparses the file. This is how the older codecompletion worked but I'll see if I can do a little better in a furture fix.

Regarding 3)
CodeBlocks clangd_client has no control over what clangd reports as a warning. However you can hide the warning as follows:
With the warning in the LSP messages log, right click on the "LSP messages" tab and click on "Show/set ignore messages". In the resulting dialog, check the box for the messages you want to ignore.

Regarding Indentation:
I have no idea what indentation rules clang/clangd is applying to source files.
5
Help / Re: Can't find attiny441 in linux Code::Blocks avr toolchain
« Last post by moricef on Yesterday at 06:16:10 pm »
The same on Windows10.
Installed avr-gcc-12.1.0-x64-windows from https://blog.zakkemble.net/avr-gcc-builds/
Compiler settings on C:\Program Files (x86)\avr-gcc-12.1.0-x64-windows
additional paths C:\Program Files (x86)\avr-gcc-12.1.0-x64-windows\utils\bin
wizard script modified  and added attiny441
BUT NOTHING in the processors list
Wtf ???
6
Help / Re: Can't find attiny441 in linux Code::Blocks avr toolchain
« Last post by moricef on Yesterday at 05:22:06 pm »
@Miguel Gimenez

In the compiler settings I add /usr/lib/avr/lib/ in toolchain executables additionnal paths

So why is there attiny441 and attiny841 in

ls /usr/lib/avr/lib/avr25/
(...) crtattiny441.o crtattiny461a.o crtattiny841.o (...)

and why compiling avr-gcc -g -mmcu=attiny441 -Wall -Os -c main.c does not return an error?

Where are Brian Sidebotham and H. Metin OZER  ?
7
Help / Re: Can't find attiny441 in linux Code::Blocks avr toolchain
« Last post by Miguel Gimenez on Yesterday at 04:40:11 pm »
C::B does not supply a toolchain, just allows using whatever you have.
8
Help / Re: Can't find attiny441 in linux Code::Blocks avr toolchain
« Last post by moricef on Yesterday at 04:19:43 pm »
Why does Code::Blocks ignore my settings for the toolchain and why is the toolchain offered by Code::Blocks outdated compared to the one installed on Debian 11?
 
Why is the wizard script in readonly mode?
Why do I have to copy the file /usr/share/codeblocks/templates/wizard/avr/wizard.script to ~/.local/share/codeblocks/templates/wizard/avr/ so that right clicking on avr wizard does open  a read-write file?
Why does the CPU list not contain the ATtiny441 though I changed /usr/share/codeblocks/templates/wizard/avr/wizard.script AND ~/.local/share/codeblocks/templates/wizard/avr/wizard.script
9
Using Code::Blocks / Re: wxWidgets 3.1.7 is available
« Last post by AndrewCot on Yesterday at 03:00:40 pm »
Mac still has no debugging that is easy to do (or in my case get working), so first step to fix or investigate any Mac bugs is to get it so you get debug the code without resorting back to the god old printf days. So before I look at any Mac bugs I need to get debugging working first. IMHO and also Eran's Codelite changes for MAC is to add DAP debugger support. Eran has been working on the DAP library and integrating the changes into Codelite over the last few weeks. Some of the DAP library issues I have stumbled across have been fixed in DAP updates and some have been me or my config type issues.

Unfortunately based on past experience most of my large patches are not going to be accepted as they have or will be hijacked IMHO by someone who does not want to think or take the time to try to figure out why the patch is needed in the first place by the average user (not C::B devs) and as such I do not want to waste time on tickets and patches that go no where anymore. AS soon as I get the  "Please explain the reason for this patch..." I now give up as it's a waste of time responding as it goes no where.

Once I get DAP debugging working then I will supply info on the GIT repo and leave it for someone else to run with.
10
Using Code::Blocks / Re: wxWidgets 3.1.7 is available
« Last post by Miguel Gimenez on Yesterday at 12:00:46 pm »
There are some tickets related to Mac, can you reproduce any of them?
Pages: [1] 2 3 4 5 6 ... 10