I have a working C-extension for Racket. In the Racket CLI and the interactions window of DrRacket it works like a charm. However, I can't get it to work in the definitions window of DrRacket, which would be really useful as that is the interface for my students to develop their programs.
The problem seems to be that definitions in the extension are not 'seen' (or registered or something). The module is loaded (or at least found) but DrRacket complains that it doesn't have execute permission for it, which I don't understand.
In the C code I declared the extension to be a module and I tried both inclusion methods:
(load-extension "racket_extension.so")
and
(require "racket_extension.rkt") ; which requires you put it in a folder relative to the current working folder as follows:
"compiled/native/x86_64-linux/3m/racket_extension_rkt.so"
Neither method works. The first case gives no error, but the definitions of the external are not registered ("undefined").
In the second case DrRacket gives an error:
forbidden (execute) access to ....compiled/native/x86_64-linux/3m/racket_extension_rkt.so
but why?
Does anyone have ideas how I can get this to work? What am I missing?
Thanks!
Marc
How are you compiling and linking your extension? Are you using the raco ctool or gcc? Are you executing DrRacket within the same directory as your compiled directory? The way I usually test my extensions is to execute: drracket my_ext_test.rkt in the same directory as my compiled directory. That has been an issue for me in the past. Also, if it says the action is forbidden, did you try changing the permissions of your .so? Maybe it's something as simple as that. I'd start with the simple example Writing Racket Extensions and make sure that you can get the hello world program to work in the definitions window. I personally have never had the problem you have mentioned, but I am also running on Linux.
Related
I'm currently Studying Computer enginering and taking embeded systems class, My isuse is that we use a custom library then compile it in a old version of Codewarrior.
how I would go about creating an include path for my lsp with nvim
I was woundering how I would go about creating an include path for my lsp with nvim, when I am not compiling the code localy but later compiling it with an old IDE
any wisdom would be apreciated.
note: in class we are required to use an exterior editor and the older version of code warrior is verry bad it is used for compiling for our micro controler but is unusable for writting code.
things I have done
I have atempted using compile_commands.json by coppying my vscode config for path location
I have tryed using a .clangd file with -I ...
I have tried other method but had no sucess so far
over all I was hopping to find a solution and have poured over the getting started page and stack overflow for several hours trying diffrent method to no avail.
The easiest approach is probably to use a .clangd file. Based on the path in your comment, the .clangd file should look like this:
CompileFlags:
Add: -I/home/bjc1269/Documents/github/libraries/lib/hc12c/include
A few things that I'm seeing in the .clangd file in your comment that don't work are:
Variable substitutions like ${workspaceFolder}. This is a VSCode feature that works in some VSCode settings like "clangd.arguments", but is not supported in a .clangd file, which is editor-agnostic (for example, it works with editors that don't have a concept of a "workspace").
Referring to your home directory as ~. Expanding ~ to /home/<username> is a feature of your shell. Command-line arguments specified in .clangd are passed directly to the compiler without being processed by the shell, so ~ will not work.
Globs like **. To be honest, I'm not even sure what the intended semantics for this could be in the context of specifying include directories.
Square brackets inside the argument to -I. Square brackets may appear in a .clangd file as YAML syntax for specifying multiple values in a list, for example you might have:
CompileFlags:
Add: [-I/path/to/directory1, -I/path/to/directory2]
But if you write -I=[/path/to/directory], the brackets just get passed on verbatim to the compiler, which does not understand this syntax.
First of all: Welcome to stackoverflow! :D
I'd recommend to use bear for this. You just simply invoke it with your build-command and the clangd LSP will read the includes automatically.
Ok, n00b question. I have a cpp file. I can build and run it in the terminal. I can build and run it using clang++ in VSCode.
Then I add gtest to it. I can compile in the terminal with g++ -std=c++0x $FILENAME -lgtest -lgtest_main -pthread and then run, and the tests work.
I install the C++ TestMate extension in VSCode. Everything I see on the internet implies it should just work. But my test explorer is empty and I don't see any test indicators in the code window.
I've obviously missed something extremely basic. Please help!
Executables should be placed inside the out or build folder of your workspace. Or one can modify the testMate.cpp.test.executables config.
I'd say, never assume something will "just work".
You'll still have to read the manual and figure out what are the names of config properties. I won't provide exact examples, because even though I've only used this extension for a short time, its name, and therefore full properties path, has already changed, so any example might get obsolete quite fast.
The general idea is: this extension monitors some files/folders, when they change, it assumes those are executables created using either gtest or catch2. The extension tries to run them with standard (for those frameworks) flags to obtain a list of test suites and test cases. If it succeeds, it will parse the output and create a nice list in the side panel. Markers in the code are also dependent on the exactly same parsed output, so if you have one, you have the other as well.
From the above, you need 3 things to make this work:
Provide correct path (or a glob pattern) for finding all test executables (while ignoring all non-test executables) in the extension config. There are different ways to do this, depending on the complexity of your setup, they are all in the documentation though.
Do not modify the output of the test executable. For example, if you happen to print something to stdout/stderr before gtest implementation parses and processes its standard flags, extension will fail to parse the output of ./your_test_binary --gtest-list_tests.
If your test executable needs additional setup to run correctly (env vars, cwd), make sure, that you use the "advanced" configuration for the extension and you configure those properties accordingly.
To troubleshoot #2 and #3 you can turn on debug logging for the extension (again, in the VSCode's config json), this will cause an additional "Output" tab/category to be created, where you can see, which files were considered, which were run, what was the output, and what caused this exact file to be ignored.
This messed with me for a while, I did as Mate059 answered above and it didn't work.
Later on I found out that the reason it didn't work was because I was using a Linux terminal inside windows (enabled from the features section) and I previously had installed the G++ compiler using the linux terminal so the compiler was turning my code into a .out file, for some reason TestMate could not read .out files.
Once I compiled the C++ source file using the powershell terminal it created a .exe file which I then changed the path in the setting.json as Mate059 said and it showed up.
TL;DR
Mate059 gave a great answer, go into settings.json inside your .vscode folder and modify "testMate.cpp.test.executables": "filename.exe".
For me it also worked using the wildcard * instead of filename.exe but I do not suggest to do that as in that might mess up something with the .exe from the main cpp file and what not.
I was trying to set up Haxe, but this error faces me whenever I try to import a Library, whether it be js.Lib, cpp.Lib, etc. It always comes up with this error:
Error: You cannot access the cpp package while targeting cross (for cpp.Lib)
I've been searching for hours now, with nobody seeming to get the same problem and no fixes. Please help!
"cross" means that the compiler is being invoked without any target (-cpp, -js...) specified.
I'm not sure which one you selected, but if I remember correctly, the project setup with some of HaxeDevelop's templates is a bit unusual. Normally you would use a HXML file where you can specify the arguments directly. A build.hxml that looks like this should work here:
-cp src
-main Main
-cpp bin
Then just run haxe build.hxml.
So in my process of switching to emacs I find it very difficult to forgo Visual Studio 2010 for C++. Trying to setup cedet for emacs didn't make it any easier. So I used the gentle introduction by Alex Ott and my init file looks similar to the one provided :
(load-file "~/.emacs.d/plugins/cedet/common/cedet.el")
(global-ede-mode 1)
(semantic-load-enable-excessive-code-helpers)
(require 'semanticdb)
(global-semanticdb-minor-mode 1)
(setq semantic-ectag-program "C:/devel/ctags/ctags58/ctags.exe")
(semantic-load-enable-secondary-exuberent-ctags-support)
(require 'semantic-ia)
(require 'semantic-gcc)
(setq-mode-local c-mode semanticdb-find-default-throttle
'(local unloaded system recursive))
(ede-enable-generic-projects)
(global-srecode-minor-mode 1)
All good and dandy but when I try to open a cpp file which has a header (array_loader.h) in the same directory and try to do code completion for the register_reader() method:
array_loader al; al.register_reader();
I get "cannot find types for 'array_loader al' ". Paradoxically, auto-complete-mode works seamlessly. Do they interfere?
I just checked out 1.1 beta using bazaar and then byte compiled it. I didn't setup a project because all my projects are cmake based and they don't have a single path for include files. each sub-library of my project has the headers in the same directory. Is there a way to parse a CMakeLists.txt and feed that information to ede or semantic? Even if there wasn't this basic example should work. Am I doing something wrong?
Well in case anyone has this problem again, I managed to solve it by setting up my cedet init files as indicated by Alex Ott:
https://github.com/alexott/emacs-configs/blob/master/rc/emacs-rc-cedet.el
Also I defined my cmake project and used the recursive find to go through my cmake project folders to find the headers.
It is still strange how cpp files external to the project could not find the signature of the classes/methods although they were defined in headers found in the same folder. the semanticcdb throttle was set as follows
(setq-mode-local cpp-mode semanticdb-find-default-throttle
'(project local unloaded system recursive))
Context
I am working on a klee (http://klee.llvm.org) fork and want to clean up our repository to separate our stuff from the "canonical" klee code. Anyway, I'm having trouble understanding/extending the build system.
Problem
The directory structure in /lib/ looks like this
Basic/
Core/
Support/
Expr/
Solver/
Module/
Mine/
Mine was just added by me, so far we threw everything in Core and I am moving it to Mine. How do I tell the build system to do this properly?
My attempt
Being unable to figure this out on my own, I edited /lib/Makefile:
LEVEL=..
PARALLEL_DIRS=Basic Support Expr Solver Module Core Mine
include $(LEVEL)/Makefile.common
and copied the /lib/Core/Makefile to /lib/Mine/Makefile while changing LIBRARYNAME=kleeCore to LIBRARYNAME=kleeMine.
Caveat
I have a feeling that this is not the proper way to do it, and I should rather modify some configure script or something. Also it does not link (it compiles, though).
A colleague just told me how to get it to link, which is by modifying /tools/klee/Makefile
USEDLIBS = kleeCore.a kleeModule.a kleaverSolver.a kleaverExpr.a kleeSupport.a kleeBasic.a kleeMine.a