Activity for Andrew Cottrell
-
Andrew Cottrell modified ticket #1326
SVN r13027 Linux workspace does not build
-
The specific issues reported are fixed.
-
Thanks. I will check when Pecan updates some of the files used to build the clangd_client plugin as I am still working my way through the different OS/WxWidget build checks.
-
Will check when Pecan updates some of the files used to build the clangd_client plugin as I am still working my way through the different OS/WxWidget build checks.
-
SVN r13027 Linux workspace does not build
-
Bye
-
Last try Same script as per 22-Feb-2022 post above. The SVN command used to create the patch is: svn diff -x "--context 0 --ignore-eol-style" > ../SF_1172_RCS_Removal.patch Updated patch against r12990 is attached.
-
SVN changes between r12985 and r12990 degraded toolbar icons quality and issues logged
-
With the logging I spotted the Fortran extern has an issue in the trunk Makefile.am where the following line is missing a "/" images/fortranproject/24x24*.png \ Should be images/fortranproject/24x24/*.png \
-
The [r12968] does not fall back. The attached xtra_res.cpp does fall back. The SetToolbarImageSize(...) function change is reverted as it is needed in the GetCenteredBitmap (..) when the SVG does not exist so that it works like it does now.
-
r12961 does not fallback to use PNG if SVG files not found in GetCenteredBitmap
-
Can you please supply a crash rpt?
-
If you have a target that needs to be built before another target then you have a dependency. If the targets can be built in any order then there is no dependency. You can always have a look at the C::B source and supply a patch to resolve what you want. If you want C::B virtual targets to build in a specific order then this is an enhancement and not a bug as C::B does not support this at this point in time and as far as I am aware no one is working on this or have any plans to do this (I could be...
-
What version of C::B are you using? If you are not using the latest nightly give it a try as the keybinder plugin has been updated since 20.03. If you look in the ~/.config/codeblocks/<personality>.cbKeybinder20.conf file and see what the accelerator for "Ctrl-Shift" is set to if any and let us know if you find it. The default personality is default.</personality> If you cannot find the accelerator for "Ctrl-Shift" can you please attach the cbKeybinder20.conf file you are using. I cannot reproduce...
-
As per the wiki you need to use a workspace and have multiple projects where you setup dependencies based on the project. The project/projects can have virtual targets. Attached is the sample reworked to have one workspace and two projects with the dependency configured as per the wiki. If you want to have dependencies within the one project based on other project target(s) within the one project file then this is an enhancement and not a bug as C::B does not support this at this point in time and...
-
Zip the files and attach the zip file. Did you test with the nightly release? If you did what version did you use? The foo.cbp project is not complete in that it does not have nay files (no main.cpp, test.cpp etc) . The sample can be a hello world using a library or anything so long as it shows your issue. It also has no dependencies in it, so unless you are using a workspace with multiple project files you have not setup any dependencies. This is one of the reasons I would like a sample project...
-
Zip the files and attach the zip file.
-
Please read the following and let us know if this fixes your issue or not: https://wiki.codeblocks.org/index.php/Common_problems_and_solutions#Multi-targets_library_and_executable_ignore_interdependence If the dependency changes from the wiki do not work with C::B 20.03 then please try the latest nightly and let us know if the nightly fixes the issue or not with the dependency changes from the wiki. If you end up with the problem still not working can you please supply a small project that shows...
-
Spam ticket?
-
SVN r12909 introduced Linux crash due to missing file due to typo
-
Installer NSIS script needs updating to add the SVG files.
-
Still got "L" plates and want to double check that it's okay as the ticket process is not documented and as such I can make mistakes very easy.
-
Miguel, if you have time could you have a read of this ticket and [77] and if you think they should be closed can you please close them. Thanks Andrew
-
Miguel if you are okay with the posts above can you please close this ticket?
-
No updated patch will be supplied as the request has been open for 3 months. Also Miguel's changes for HIDPI may have resolved this. As such this ticket may be suitable to be closed and if testing later shows the issue is not fixed then the ticket can be reopened or another ticket could be created.
-
Fixed with ticket [1315] change in [r12902]. As such this ticket can be closed.
-
Looks like this is never going to be tested. As such this ticket may be suitable to be closed and if testing later shows the issue is not fixed then the ticket can be reopened or another ticket could be created.
-
Daniel, Can you try the latest C::B source as Miguel has made a number of changes in the last month that may have resolved the issue you were having. Can you please let us know if it latest C::B source build does or does not resolve the issue. Thanks.
-
Getting "them" to compile is not a 2 minute job. I have got them to compile and run. The code is available from my unofficial github repo (see https://github.com/acotty/CodeBlocks_Unofficial_Testing/tree/master/src/plugins/contrib-wip/PythonPlugins ). I have not tested that the 4 plugins work correctly as I only use Python when it is part of something I need to get working. As such I do not know if they are useful. There is a PreservePermissions directory, which I did not build as it did not seem...
-
Thanks for applying.
-
The following page also gets MAC devs to make the same change in step 9: https://www.geeksforgeeks.org/how-to-install-code-blocks-for-c-on-macos/
-
MAC fix ability to run console app.
-
Manager::LoadResource failure does not show file on LocateDataFile(..) failure
-
MAC wxTheClipboard->Flush(); failing in app.cpp with wx3.2.1
-
Mac install does not include any dictionary, so spell checker displays message
-
Docs do not build on Linux due to Save_watch.png camel case issue
-
Update some URL files in the installer where there are updated web pages
-
Update some URL file some the installer where there are updated web pages
-
No workspace/makefile includes src\plugins\contrib\PythonPlugins files
-
No workspace/makefile includes src\plugins\contrib\PythonPlugins files
-
No workspace includes src\plugins\contrib\PythonPlugins files
-
Crash report attached that may be related to this report. The report has line and code info in it, so it may be useful to see if anything is obvious. The issue occurred after editing a file in NotePad++ on the second monitor and then clicked on the C::B editor that had the same file. The crash does NOT occur every time this is done. The last crash was in late August, so it is rare.
-
Linux - call stack dialog data not cleared on project close
-
Linux - breakpoint dialog data not cleared on project close
-
Linux - watch dialog data not cleared on project close
-
Patch to fix crash. This has only had an hour of testing.
-
My guess on what is going on is that the three of us have the hunspell.h file in different directories and as such when we compile the source we get different results. Where on your systems do you have the hunspell.h file? Search and include the results for both the C::B source tree and the compiler source tree. I have it in the following C::B source tree directory only: \src\plugins\contrib\SpellChecker\hunspell\src\hunspell\hunspell.h I have it in the following MSYS2 directory only (results for...
-
It will get worse when 3.2 make it to Linux as another set of project files will be created if the current process is still used. Then another two sets will be needed when Mac workspace/project files eventually land at some stage in the future id the current process is still used. So eventually going down the current path would mean that to make a change a dev would need to update all of the following sets at some stage in the future if my crystal ball is working correctly: * Windows wx3.1 32 bit...
-
Strange as I did not have to change the search paths in any project file or makefile to get the build to work after making the #include change. I used the 3.2 64 bit windows workspace.
-
The patch was not a standalone patch as it was "patch showing the changes to fix just the depreciated functions." Attached is a patch to fix the build.
-
See [1188] for a patch to solve the issue.
-
SVN patch.
-
NSIS Installer update due to ticket 1036 changes
-
This is not a C::B bug. Please use the C::B forum for help: https://forums.codeblocks.org/index.php/board,1.0.html?PHPSESSID=214286d27339a01336fa0369979f4dbd
-
The app crashed due to user doing crazy things. If you can show that there is a security issue then it can be looked at, but if you want to get it fixed then patches are welcome that stop the crash for crazy/stupid/dumb end users. Just because you overflowed something does NOT mean there is a security issue.
-
Close this ticket as it's a support type post and the forum is for this type of post.
-
In the general settings dialog under the editor settings the Code Completion optiosn shown even after plugin removed
-
On run/debug the "Select target dialog" is always shown even when nothign has changed
-
You can use VirtualBox or Vmware Player or Qemu to install a Linux distro and run it as a virtual machine. I do this and have multiple OS's to test on for various projects.
-
Have you checked if this patch causes build issues on Linux or Mac?
-
When writing install or build guides if end users can choose an option that is dumb and will not work then expect issues because they will and there is nothing you can do, apart from making sure the doc specifies a working set of tools/packages and processes. As such if you say install A and there are 4 versions if only two of them work the specify A version 1 or 2 (do NOT use 3 or 4).
-
If you look at the plugin directory almost every one of the directories and sub directories is a plugin on Windows, but not on Linux. Use the forum for cross compiling issues as it has nothing to do with this patch.
-
Redundant file - src\mac_pack
-
The build and install worked fine. The resulting C::B looks to only have the Linux plugins and therefore does not have the extra Windows plugins. Have you looked at this to see if you can build the additional Windows plugins with Cygwin?
-
The ../codeblocks-code/configure does not exist, it should be ../configure
-
The configure line has your home directory specified and newbies will just copy and paste the line without checking it as there is no info that it needs changing. I would suggest adding info that the user needs to change the --prefix or if ~ works then you would not need to change it (I do not know if ~ works on not). ../codeblocks-code/configure --prefix=/home/Carlo/inst_cb --with-wx-config=/usr/bin/wx-config-3.0 --enable-silent-rules As there is no Code::Blocks Cygwin package you may also want...
-
The configure line has your home directory specified and newbies will just copy and paste the line without checking it as there is no info that it needs changing. I would suggest adding info that the user needs to change the --prefix or if ~ works then you would not need to change it (I do not know if ~ works on not). ../codeblocks-code/configure --prefix=/home/Carlo/inst_cb --with-wx-config=/usr/bin/wx-config-3.0 --enable-silent-rules As there is no Code::Blocks Cygwin package you may also want...
-
The package list shows libwx_gtku3.0 , but on the mirror I have used for the last 15 years I have the options of gtk2 or gtk3: libwx_gtk2u3.0 libwx_gtk3u3.0* I am assuming I should be using the gtk3. Can you edit the post above to update it or let me know if the mirror I am using is missing the files. I will post more updates as I progress.
-
Do you have any docs on what Cygwin packages have to be installed and the steps you need to follow in order to build C::B using Cygwin so that you end up with a runable C::B exe in a directory or installed in the Cygwin directory tree? You can look at the C::B wiki site for old docs or have a look at the following doc that I have created that you could use as a template: https://github.com/acotty/CodeBlocks_Unofficial_Testing/blob/master/Readme_Build_Windows_MSYS2_by_Makefile.txt
-
Do you have any docs on what Cygwin packages have to be installed and the steps you need to follow in order to build C::B using Cygwin so that you end up with a runable C::B exe in a directory or installed in the Cygwin directory tree?
-
This is a weird one in that my local build was crashing with the same problem a few days ago and now it is working.... I did not change any of the code that is to do with the scripting or the globals.cpp so I do not know what I did to "fix: the issue.
-
Thanks very much for taking the time to find the problem and fix it. I read the comment on the line before the LoadPage() and thought all it did was load the "data", but did not show it. I made two mistakes, one was miss interpreting the comment and the other of not looking up the wxWidget docs.
-
Thanks very much for taking the time to find the problem and fix it. I read the comment on the line before the LoadPage() and thought it did loaded the "data", but did not show it. I made two mistakes, one was miss interpreting the comment and the other of not looking up the wxWidget docs.
-
This ticket looks to be the same as [833] and if it is then this one can be closed.
-
Darmar, Is it okay to close this ticket and if/when the NVIDIA HPC SDK comes out/back with Windows support then either this ticket can be re-opened or a new one created?
-
Another ticket IMHO that can be closed.
-
Another ticket that IMHO can be closed.
-
Another MAC ticket to close IMHO.
-
Another MAC ticket IMHO to close.
-
Another MAC ticket IMHO to close.
-
Cannot reproduce with the latest C::B build with CC removed and Clangd_cleint used instead.
-
Cannot reproduce with the latest with CC removed and Clangd_cleint used instead.
-
Linux run time warning - "Debug: wxColour::Set - couldn't set to colour string '.....'
-
Yet another ticket that can IMHO be closed based on previous posts above. If someone comes back to say the issue still exists then this ticket can be re-opened or a new ticket can be created. Try #2!
-
Fix warning in scintilla Document.cxx
-
As usual dumb response that shows you do not look. There is only one post from me above the previous post and it's the initial description,.
-
As usual you did not read the post.
-
Update SpellChecker due to use of depricated functions used & remove hunspell source
-
Removing the ZLIB and BZIP2 library build and source files simplifies the build/source tree and also reduces the compiler warning.
-
Linux - reduce compiler warning by 151 with very simple change
-
I agree is is possibly related. BTW earlier this week I spotted an issue(C::B does not start) with the "--debug-log" parameter only when debugging C::B from C::B, but it works running C::B from a command line. I The issue in the code could be in the same area , but I have not looked into it in more detail. When I get time I will and raise another ticket with info in it. I thought I may mention it here just in case someone spots a fix for it while looking at this ticket.
-
I agree is is possibly related.
-
Based on my month or so usage of the LLVM compiler infrastructure mixing of LLVM and other compiler tools does NOT always work. As such this patch tries to use the LLVM resource compiler when using CLANG on windows in a similar way to the following change: https://svn.code.sf.net/p/codeblocks/code/trunk@8712 https://github.com/acotty/codeblocks_sfmirror/commit/50e86470c11c0b0468b2ff2008eedd3ced7ba615 Once ticket [1285] (Windows C::B build errors with MSYS2 Clangw64) I will then be able to test this...
-
C::B build fails when building with Windows MSYS2 Clang64 compiler
-
Debugger manager error message incorrect if no project loaded
-
Miguel, I am going through the Mac tickets as I now have the ability to debug (okay simple debugging at the moment) on a virtual MacOS using the the DAP debugger I/F and when digging into this ticket founds that part of the patch was applied and part was not. At the moment I cannot answer the questions as I am a Mac noob. I have put it in my local CodeBlocks_MacOS directory, but as for the C::B truck I have no idea. I would defer to Xaviou for where it should be in the source tree, but you may need...
-
Migual, I am going through the Mac tickets as I now have the ability to debug (okay simple debugging at the moment) on a virtual MacOS using the the DAP debugger I/F and when digging into this ticket founds that part of the patch was applied and part was not. At the moment I cannot answer the questions as I am a Mac noob. I have put it in my local CodeBlocks_MacOS directory, but as for the C::B truck I have no idea. I would defer to Xaviou for where it should be in the source tree, but you may need...
-
The patch was applied as r12315 , but the sign.sh is not included so it is not in the source tree!!!!
-
Can I get the following from any of the people who are having the issue reported: 1) Start Code::Blocks and before you do anything can you go to the Code::Blocks log and right click and "Copy the contents to Clipboard" . Save the clipboard data to a file called "Codeblocks.log". 2) Load your simple hello world project and re-build it. 3) Go to the "Build Log" log and right click and "Copy the contents to Clipboard" . Save the clipboard data to a file called "BuildLog.log". 4) In your ~/Library/Application...
-
Updating to 20.03 from 18.2 is not simple. You are better to install 20.03 from scratch as it will be allot quicker. Attached is my VB LM 20.03 script to create the initial image
1 >