I rewrite a program and just removed a lot of code, by just making it a comment. After doing that and adding some tests, it is impossible to run the program anymore.
when running go build it has no errors at all.
But when running go test i only become some weird output:
$ go test
2020/05/05 19:14:24 open : no such file or directory
exit status 1
FAIL fwew_lib 0.002s
This error occurs, before a single test is even run, so within the test framework itself.
Why is there is no file specified that is not found? Any idea, what caused this error and how to fix it?
This error also occurred on multiple machines with windows and linux. And with go 1.14.2 and go 1.13.7.
To get this error yourself:
Repo: https://github.com/knoxfighter/fwew/tree/library
Branch: library
Just download the branch and run go test
Your fork is missing this line from the parent
texts["dictionary"] = filepath.Join(texts["dataDir"], "dictionary.txt")
link
But your fork still has this line which depends on the one mentioned above
Version.DictBuild = SHA1Hash(texts["dictionary"])
link
And so the SHA1Hash "fatals" out since you're essentially passing it an empty string.
link
Related
ERROR at //third_party/openssh-portable/fuchsia/developer-keys/BUILD.gn:10:24: Could not read file.
manifest = read_file("//.fx-ssh-path", "list lines")
^---------------
I resolved this to "/home/shivkumar/fuchsia_os/fuchsia/.fx-ssh-path".
See //products/core.gni:102:3: which caused the file to be included.
"//third_party/openssh-portable/fuchsia/developer-keys:ssh_config",
^-----------------------------------------------------------------
ERROR: error running gn gen: exit status 1
This error means that the //.fx-ssh-path file does not exist, or is otherwise unreadable. This file is typically generated on source checkout when the integration manifest runs //tools/ssh-keys/gen-ssh-keys.sh as a jiri hook.
To correct the problem, use gen-ssh-keys.sh again to re-generate the file(s) before setting your build configuration:
$ tools/ssh-keys/gen-ssh-keys.sh
$ fx set core.qemu-x64
Note: Hooks are also run anytime you run jiri update so you could also resync the source tree to correct the issue.
I’m trying to work Aleph with Swi-prolog. Are there any one could please tell me how to run this program if I have a file named train.pl (including the background and positive and negative examples.) What can I do to induce my program and get the output? By the way, I have already downloaded Aleph.pl for my program. When I ran it, it showed like this:
ERROR: c:/users/mac/downloads/aleph.pl:97:
Wrong context: arithmetic_function/1 can only be used in a directive
I also had similar problems. However, after some googling, I found a github repository which contains the aleph script that actually works (prolog/aleph.pl). However, the manual could be more detailed (at least for a newbie like me). A minimal working example that I have managed to run is the trains example (prolog/examples/train.pl) and I did the following:
Put the aleph.pl script into some directory path/to/dir
Put the train.pl script into the same directory.
Executing the following commands, one by one:
working_directory(_, 'path/to/dir').
consult('aleph.pl').
consult('trains.pl').
induce.
I ignored some errors and warnings that have appeared when executing the command consult('trains.pl').:
ERROR: path/to/dir/train.pl:16:
ERROR: source_sink `library(aleph)' does not exist
Warning: path/to/dir/train.pl:16:
Warning: Goal (directive) failed: user:use_module(library(aleph))
How to specify the path of generated debug binary file when debug go-lang in vs-code?
I have tried modify launch.json file but not work.
I can debug go programs well now in vs-code, the only problem is each time i finish debug, a debug binary file was generated under my project directory, like the picture below.
I want to know can i specify the directory of generated debug binary file?
I am on mac screen shot of my problem:
This is followed by vscode-go issue 1345: "Delete binary files created by delve after closing the debug session"
delve is the debugger for Golang, or at least it's the one that the Go extension uses.
When you debug something with delve, it creates a large binary file in the current directory. If you debug a main function (dlv debug), you get 'debug'. If you debug a test function (dlv test), you get 'debug.test'.
In normal delve usage, when you're done, you quit delve. Delve then deletes this file. Apparently VSCode gracelessly terminates (SIGKILL?) delve, which means the file sticks around.
So this is studied, but not yet resolved.
Update July 2018: Ramya Rao adds in this issue:
I finally have an update!
Turns out there is a command called Detach that can be called on the delve server which will result in the required clean up of the debug binary that gets generated.
To get this fix before the next update to the Go extension (which will be either Friday or early next week), please follow the below:
Download https://github.com/Microsoft/vscode-go/blob/master/Go-latest.vsix
Run code --install-extension Go-latest.vsix
If the above fails with Error: end of central directory record signature not found, then clone this repo (vsgo) and use the Go-latest.vsix file from the cloned repo
Reload VS Code
The fix worked for me as long as the program being debugged wasn't spawning processes of its own like a web server for which I have logged an upstream issue with delve.
I'd appreciate it if folks here can give the fix a try and share any feedback.
The change you need to do to provide an output path for the generated debug binary is in the launch.json file.
Use the property output in your debug configuration.
Please don't modify the package.json file.
This debug file was generated by delve when debugging and should be deleted after debugging, this seems to be bug of go extension of vs-code, see the link here
I would like to run a Makefile in IntelliJ whenever a source file changes. Therefore I installed the File Watcher plugin and added a new File Watcher for Go files. In the Watcher Settings I added make as the Program and test for the Arguments.
When I now change a .go file, I get the following error message:
make test
make: *** No rule to make target `test'. Stop.
Process finished with exit code 2
so I assume that the file watcher works in general but is somehow runs the make command in the wrong directory.
When I run make test in a terminal from the root of my project, everything works as expected and I get:
Formatting all packages...
Code analysis with go vet...
Execute test with ginkgo...
[1490735873] Cmd Suite - 1/1 specs • SUCCESS! 120.183µs PASS
[1490735873] Test Helpers Suite - 4/4 specs •••• SUCCESS! 125.046µs PASS
[1490735873] Models Suite - 5/5 specs ••••• SUCCESS! 453.456µs PASS
[1490735873] Services Suite - 16/16 specs •••••••••••••••• SUCCESS! 3.035275ms PASS
Ginkgo ran 4 suites in 855.886243ms
Test Suite Passed
What am I doing wrong - or am I missing the point of using file watchers in IntelliJ?
Solution was that I had to specify the Working Directory in Other Options. When I set this to $ContentRoot$, everything works as expected.
I'm trying to resurrect an old (1999 or earlier) project written in Scheme (PLT-Scheme, using the mzscheme interpreter (?) commandline tool). To make the matters worse, I don't know Scheme, or Lisp (in fact, I want to learn, but that's another story).
I have the source code of the project at:
github.com/akavel/sherman
Now, when running the code, it bails out with an error message like below:
Sherman runtime version 0.5
Hosted on MzScheme version 52, Copyright (c) 1995-98 PLT (Matthew Flatt)
reference to undefined identifier: list->block
(I've tried PLT-Scheme versions 52, 53, 103, 103p1. Earlier versions don't allow mzscheme -L option, which is referenced in the sherman.bat script used in the project. Later versions also have some more serious problems with the code or options.)
The difficulty is, that from what I see, list->block actually is defined - see: collects/sherman/BLOCK.SS line 48. So, what is wrong?
To run the code, I perform the following steps:
Download PLT-Scheme v. 103p1 (from the old versions download page - first closing the "PLT Scheme is now Racket" banner) - for Windows, use: mz-103p1-bin-i386-win32.zip.
Unzip (e.g. to directory c:\PLT).
Copy c:\sherman\collects\sherman directory with contents to: c:\PLT\collects\sherman (where c:\sherman contains the contents of the github repository).
Run cmd.exe, then cd c:\sherman.
set PATH=c:\PLT;%PATH%
sherman.bat run trivial.s
this command is in fact, from what I understand, equivalent to:
(require-library "runtime.ss" "sherman")
(parameterize ((current-namespace sherman-namespace)) (load "trivial.s"))
(current-namespace sherman-namespace)
After that, I get the error as described above (MzScheme version would be reported as 103p1 or whatever).
Could you help me solve the problem?
EDIT 2: SOLVED!
To whom it may concern, I've added a fully fledged "How to use this project" instruction on the project page, detailing the solution to the problem thanks to soegaard's help.
In short:
copy trivial.s trivial.rs
rem (the above is workaround for problems with 'r2s.exe < trivial.r > trivial.rs')
sherman.bat compile trivial.rs
sherman.bat run trivial.zo
rem (or: sherman.bat run trivial.ss)
Not an answer, but a few notes too big for a comment.
1. Sanity Check
The error message says list->block is undefined.
Make sure that the code in block.ss is run, by
inserting (display "block.ss is loaded!") in block.ss
just to make sure, the code is run.
2. Random Thoughts
The file blocks.ss begins with:
(require-library "functios.ss")
(require-library "synrule.ss")
(require-library "stream.ss" "sherman")
The file "sherman/stream.ss" is in the repository,
but where is "synrule.ss" and "functios.ss" ?
Ah... This code is old! Here is a description of
how require-library worked. It lists functios.ss
and synrule.ss as part of MzLib.
http://www.informatik.uni-kiel.de/~scheme/doc/mzscheme/node158.htm
Let's check out how require-library worked:
When require-library is used to load a file, the library name and the
resulting value(s) are recored in a table associated with the current
namespace. If require-library is evaluated for a library that is
already registered in the current namespace's load table, then the
library is not loaded again; the result(s) recorded in the load table
is returned, instead.
So when the code in block.ss is run, the names are stored in a namespace. If the current namespace is the wrong one, when the code in block.ss is evaluated, it would explain you error message of list->block being undefined.