I built nupic as per the instructions in the wiki. However, when I run testeverything, the RegionTest fails with a message that pynode cannot be found since neither nta_rootdir nor pythonpath are set.
echo $pythonpath and echo $nta_rootdir gives the correct results though
The exact message is
MSG: Unable to find the pynode dynamic library because neither NTA_ROOTDIR not PYTHONPATH is set.
How do I fix this?
I'd like to track this issue on the NuPIC issue tracker.
Related
When running srb init in a Rails app I get the following:
Generating /tmp/d20220723-3779490-paqj5l/reflection.rbi with 6784 modules and 142 aliases
Printing your code's symbol table into /tmp/d20220723-3779490-paqj5l/from-source.json
/home/allan/.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/sorbet-0.5.10206/lib/hidden-definition-finder.rb:123:in `write_constants': Your source can't be read by Sorbet. (RuntimeError)
You can try `find . -type f | xargs -L 1 -t bundle exec srb tc --no-config --isolate-error-code 1000` and hopefully the last file it is processing before it dies is the culprit.
If not, maybe the errors in this file will help: /tmp/d20220723-3779490-paqj5l/from-source.json.err
When I check that error file I find this:
Exception::raise(): Unimplemented Parser Node: EmptyElse
Is there a workaround to get past this error?
Anytime you see Exception::raise in a Sorbet error message, it means there was a bug in Sorbet. You can report Sorbet bugs at https://github.com/sorbet/sorbet/issues
I have created a fix for this bug here: https://github.com/sorbet/sorbet/pull/6161
It will require upgrading Sorbet before you can take advantage of the fix. If you can't wait for that, you will have to hunt down the file in your codebase that uses Ruby's new case ... in syntax for pattern matching with an empty else keyword, and either delete the else keyword or change it to mention else nil instead.
Sorry for the inconvenience.
In the future, please use https://github.com/sorbet/sorbet/issues to report all issues—I only happened to see this by accident today, but I normally do not monitor StackOverflow for bug reports.
I have a find package module that utilizes check_cxx_source_runs() to test if package was loaded properly. However, it fails and I am not sure what causes it to.
Is there any way I can print the actual error (as one would see on terminal) from check_cxx_source_runs() rather than just the variable that tells success/failure?
I found the error output in "CMakeError.log" under the build directory.
I'm facing some interesting issues. Changing the order of kernel parameters passed to the -append, it changes the outcome.
Running my QEMU VM with the following works:
-append "root=/dev/disk/by-id/virtio-rootfs rootflags=rw flatcar.first_boot=1 tsc=reliable no_timer_check= rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp= reboot=k console=hvc0 console=hvc1 cryptomgr.notests= net.ifnames=0 pci=lastbus=0"
However, if put the root= to the end then it does not work and the root volume is not found so not mounted.
So I'm now wondering. the order does it really matter? And if so there is any logic behind it? Any rules to follow?
I got it solved by checking which flags were passed into the system and checking cat /proc/cmdline I've found out that that the flags were quoted with double quote so the kernel was failing the parsing
When I try to compile nettle-2.7.1, I get the following:
root#tcx2270-19:~/nettle-2.7.1# make
make: Warning: Can't find aes-decrypt-internal.o.d': No such file or directory
make: Fatal error in reader: Makefile, line 594: Read of include fileaes-decrypt-internal.o.d' failed
Has anyone seen this issue? Thanks.
I also had the exact same problem. It has nothing to do with gmp. The ./configure script generates a broken Makefile. After doing some analyzation of the generated Makefile I figured out a solution.
On the very bottom of the generated Makefile search for the line that looks like the following:
DEP_FILES = $(SOURCES:.c=.$(OBJEXT).d) $(SOURCES:.c=.p$(OBJEXT).d) asm.d
You can fix the build by changing it to the following line:
DEP_FILES = $(SOURCES:.c=.c.$(OBJEXT).d) $(SOURCES:.c=.c.p$(OBJEXT).d) asm.d
Additionally, we have to fix the Makefiles in all sub-directories.
For ./tools/Makefile, on the very bottom, find the line that looks like:
include $(SOURCES:.c=.$(OBJEXT).d)
and change it to
include $(SOURCES:.c=.c.$(OBJEXT).d)
Furthermore, you need to add the following two build-targets:
../libnettle.a:
$(MAKE) -C .. libnettle.a
../libhogweed.a:
$(MAKE) -C .. libhogweed.a
For ./testsuite/Makefile, on the very bottom, find the line that looks like this:
DEP_FILES = $(SOURCES:.c=.$(OBJEXT).d) $(CXX_SOURCES:.cxx=.$(OBJEXT).d)
and change it to:
DEP_FILES = $(SOURCES:.c=.c.$(OBJEXT).d) $(CXX_SOURCES:.cxx=.cxx.$(OBJEXT).d)
Finally, in ./examples/Makefile, again on the very bottom, search for the line that looks like:
include $(SOURCES:.c=.$(OBJEXT).d)
and change it to
include $(SOURCES:.c=.c.$(OBJEXT).d)
Phew, at least for me, that makes the build work. Of course, this is an ugly solution but it gets the job done. A better solution would be to fix the configure-script but I did not have the time to do it yet. It is also worth noting that nettle 3.0 does not have this issue. Too bad gnutls does not work with that newer version.
UPDATE: I created a patch which does all the above fixes in the Makefile.in files. As a result, you don't have to fix them yourselfs. Optimally, just unpack the source, apply the patch and proceed the way you normally would by continuing with the ./configure.
Get it from here: http://pastebin.com/36M5LHK3
I'm using xcodebuild inside a bash script on a continuous integration server.
I would like to know when a build as failed in the script, so I can exit prematurely from it and mark the build as failed.
xcodebuild displays a BUILD FAILED message to the console, but I don't succeed in getting a return value.
How can I achieve this?
Thanks in advance
I solved my problem using this command: xcodebuild -... || exit 1
You can use the "$?" variable to get the return code of the previous command.
xcodebuild -...
if [[ $? == 0 ]]; then
echo "Success"
else
echo "Failed"
fi
xcodebuild always returns 0, regardless of the actual test result. You should check for either ** BUILD FAILED ** or ** BUILD SUCCEEDED ** in the output to know whether tests pass or not.
Xcodebuild can return any of the error codes listed below and not restricted to EX_OK (or int 0).
However, I learnt from solution provided by Dmitry and modified as following. It works for me and I hope it could be helpful.
xcodebuild -project ......
if test $? -eq 0
then
echo "Success"
else
echo "Failed"
fi
Error codes
The following are the error codes that can be returned by sysexits archive:
EX_OK (0): Successful exit.
EX_USAGE (64): The command was used incorrectly, e.g., with the wrong number of arguments, a bad flag, a bad syntax in a parameter, or whatever.
EX_DATAERR (65): The input data was incorrect in some way. This should only be used for user's data and not system files.
EX_NOINPUT (66): An input file (not a system file) did not exist or was not readable. This could also include errors like ``No message'' to a mailer (if it cared to catch it).
EX_NOUSER (67): The user specified did not exist. This might be used for mail addresses or remote logins.
EX_NOHOST (68): The host specified did not exist. This is used in mail addresses or network requests.
EX_UNAVAILABLE (69): A service is unavailable. This can occur if a support program or file does not exist. This can also be used as a catchall message when something you wanted to do doesn't work, but you don't know why.
EX_SOFTWARE (70): An internal software error has been detected. This should be limited to non-operating nonoperating operating system related errors as possible.
EX_OSERR (71): An operating system error has been detected. This is intended to be used for such things as cannot fork'',cannot create pipe'', or the like. It includes things like getuid returning a user that does not exist in the passwd file.
EX_OSFILE (72): Some system file (e.g., /etc/passwd, /var/run/utmp, etc.) does not exist, cannot be opened, or has some sort of error (e.g., syntax error).
EX_CANTCREAT (73): A (user specified) output file cannot be created.
EX_IOERR (74): An error occurred while doing I/O on some file.
EX_TEMPFAIL (75): Temporary failure, indicating something that is not really an error. In send-mail, sendmail, mail, this means that a mailer (e.g.) could not create a connection, and the request should be reattempted later.
EX_PROTOCOL (76): The remote system returned something that was ``not possible'' during a protocol exchange.
EX_NOPERM (77): You did not have sufficient permission to perform the operation. This is not intended for file system problems, which should use EX_NOINPUT or EX_CANTCREAT, but rather for higher level permissions.
EX_CONFIG (78): Something was found in an unconfigured or misconfigured state.
For more info click here.
Maybe it's not because of the xcodebuild not returning non-zero when build failed. Your shell script continuing to run regardless of the returning-error line might be the result of that you didn't run the script with a "-e" option.
Try put #!/bin/bash -e ahead of the script file.
Generally, you can always check the exist value for the last run process in Unix bash by:
$ echo $?
where $? is a built-in placeholder of the exist value of last executed command. For more details about other bash's built-in variables see here.
So, first run your command you want to investigate its return code, then run echo as above.
Whether the compiled product （.a or .ipa file）exists