I just copy the code from the example on nim's offical documentation:
import std/locks
var
thr: array[0..4, Thread[tuple[a,b: int]]]
L: Lock
proc threadFunc(interval: tuple[a,b: int]) {.thread.} =
for i in interval.a..interval.b:
acquire(L) # lock stdout
echo i
release(L)
initLock(L)
for i in 0..high(thr):
createThread(thr[i], threadFunc, (i*10, i*10+5))
joinThreads(thr)
deinitLock(L)
$ nimble build --threads:on
Verifying dependencies for thread#0.1.0
Building thread/thread.exe using c backend
$ .\thread
then thread.exe crashed...
thread.exe
0.0.0.0
630c5e83
libwinpthread-1.dll
6.3.9600.20512
62cdfc6e
c0000135
00000000000ed1b0
1fc8
01d8bb71e28918ba
F:\MyProjects\Nim\thread\thread.exe
libwinpthread-1.dll
2044d161-2765-11ed-827a-6c86063c07b4
I have no ideas about it...Can anybody help me? Thanks a lot.
Gave it a try in Windows 8.1, it does fail.
Apparently is a recent regression in nim you can make it work if you compile it with --threads:on --tlsEmulation:on (or make sure mingw binaries is on your PATH).
Related
I'm trying to run go build command for my project but it exits with below error.
alpha#GHOST-RIDER:~/GoWorkspace/src/github.com/hyperledger/firstproject$ go build
# github.com/hyperledger/fabric-sdk-go/internal/github.com/hyperledger/fabric/core/operations
../fabric-sdk-go/internal/github.com/hyperledger/fabric/core/operations/system.go:227:23: not enough arguments in call to s.statsd.SendLoop
have (<-chan time.Time, string, string)
want (context.Context, <-chan time.Time, string, string)
Any help would be appreciated.
As per code fabric is using the different version of this library: github.com/go-kit/kit/metrics/statsd. If you follow the System struct's statsd attribute, you can reach the reference on imports.
In master branch of this lib, SendLoop function requires 4 attributes, so that's the root cause. So this causes error when you compile on your local environment.
I had the same issue and worked around it by checking out a tag of library as below:
cd $GOPATH/src/github.com/go-kit/kit
git fetch --tags
git checkout v0.8.0
found a solution on the hyperledger-fabric-go-sdk group chat.
Add context.Background() in s.statsd.SendLoop like below
s.statsd.SendLoop(context.Background(), s.sendTicker.C, network, address)
in fabric-sdk-go/internal/github.com/hyperledger/fabric/core/operations/system.go file at line 227.
I had a same issue, my solution worked and don't need edit fabric source code.
specify github.com/go-kit/kit to v0.8.0, modify go.mod:
replace github.com/go-kit/kit => github.com/go-kit/kit v0.8.0 // you specific version
require (
... ...
// Maybe other version, go mod tidy update automatically, don't care it.
github.com/go-kit/kit v0.9.0 // indirect
... ...
)
then it worked.
While a binary works with bazel run, when I run a test using bazel test, such as:
$ bazel test //systems/sensors:rgbd_camera_test
I encounter a slew of errors from VTK / OpenGL:
ERROR: In /vtk/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx, line 820
vtkXOpenGLRenderWindow (0x55880715b760): failed to create offscreen window
ERROR: In /vtk/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 816
vtkXOpenGLRenderWindow (0x55880715b760): GLEW could not be initialized.
ERROR: In /vtk/Rendering/OpenGL2/vtkShaderProgram.cxx, line 453
vtkShaderProgram (0x5588071d5aa0): Shader object was not initialized, cannot attach it.
ERROR: In /vtk/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 1858
vtkXOpenGLRenderWindow (0x55880715b760): Hardware does not support the number of textures defined.
May I ask why this happens?
(Note: This post is a means to migrate from http://drake.mit.edu/faq.html to StackOverflow for user-based questions.)
The best workaround at the moment is to first mark the test as as local in the BUILD.bazel file, either with local = 1, or tags = [.., "local"]. Doing so will make the specific target run without sandboxing, such that it has an environment similar to that of bazel run.
As an example, in systems/sensors/BUILD.bazel:
drake_cc_googletest(
name = "rgbd_camera_test",
# ...
local = 1,
# ...
)
If this does not work, then try running the test in Bazel without sandboxing:
$ bazel test --spawn_strategy=standalone //systems/sensors:rgbd_camera_test
Please note that you can possibly add --spawn_strategy=standalone to your ~/.bazelrc, but be aware that this means your development testing environment may deviate even more from other developer's testing environments.
I am using MT7688 module with openWRT OS, version 15.05. I did install usbip into the device with:
#opkg install http://downloads.lede-project.org/releases/17.01.1/targets/ramips/mt7688/packages/kmod-usbip-client_4.4.61-1_mipsel_24kc.ipk
#opkg install http://downloads.lede-project.org/releases/17.01.1/targets/ramips/mt7688/packages/kmod-usbip-server_4.4.61-1_mipsel_24kc.ipk
#opkg install http://downloads.lede-project.org/releases/17.01.1/targets/ramips/mt7688/packages/kmod-usbip_4.4.61-1_mipsel_24kc.ipk
Failure scenario:
root#mylinkit:/# usbip
-ash: usbip: not found
So, looks like something broken at user space. Do any one know the solution for it?
Below are the logs which shows kernel module is installed:
root#mylinkit:/# lsmod|grep usbip
usbip_core 4768 2 vhci_hcd
usbip_host 11256 0
root#mylinkit:/# find -name *usbip*
./etc/modules.d/usbip-server
./etc/modules.d/usbip
./etc/modules.d/usbip-client
./lib/modules/3.18.23/usbip-core.ko
./lib/modules/3.18.23/usbip-host.ko
./overlay/upper/etc/modules.d/usbip-server
./overlay/upper/etc/modules.d/usbip
./overlay/upper/etc/modules.d/usbip-client
./overlay/upper/lib/modules/3.18.23/usbip-core.ko
./overlay/upper/lib/modules/3.18.23/usbip-host.ko
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.postinst-pkg
./overlay/upper/usr/lib/opkg/info/kmod-usbip.control
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.prerm
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.postinst
./overlay/upper/usr/lib/opkg/info/kmod-usbip.list
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.prerm
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.list
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.postinst
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.control
./overlay/upper/usr/lib/opkg/info/kmod-usbip.postinst
./overlay/upper/usr/lib/opkg/info/kmod-usbip.prerm
./overlay/upper/usr/lib/opkg/info/kmod-usbip-server.control
./overlay/upper/usr/lib/opkg/info/kmod-usbip.postinst-pkg
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.postinst-pkg
./overlay/upper/usr/lib/opkg/info/kmod-usbip-client.list
./sys/bus/usb/drivers/usbip-host
./sys/devices/platform/vhci_hcd/usbip_debug
./sys/module/usbip_core
./sys/module/usbip_core/parameters/usbip_debug_flag
./sys/module/usbip_core/holders/usbip_host
./sys/module/usbcore/holders/usbip_host
./sys/module/usbip_host
./sys/module/usbip_host/drivers/usb:usbip-host
./usr/lib/opkg/info/kmod-usbip-server.postinst-pkg
./usr/lib/opkg/info/kmod-usbip.control
./usr/lib/opkg/info/kmod-usbip-server.prerm
./usr/lib/opkg/info/kmod-usbip-client.postinst
./usr/lib/opkg/info/kmod-usbip.list
./usr/lib/opkg/info/kmod-usbip-client.prerm
./usr/lib/opkg/info/kmod-usbip-server.list
./usr/lib/opkg/info/kmod-usbip-server.postinst
./usr/lib/opkg/info/kmod-usbip-client.control
./usr/lib/opkg/info/kmod-usbip.postinst
./usr/lib/opkg/info/kmod-usbip.prerm
./usr/lib/opkg/info/kmod-usbip-server.control
./usr/lib/opkg/info/kmod-usbip.postinst-pkg
./usr/lib/opkg/info/kmod-usbip-client.postinst-pkg
./usr/lib/opkg/info/kmod-usbip-client.list
I spend much time to figure out the solution. And in the end, doubt was correct. The installer ipk from release branch, as mentioned in query post, does not have user space binaries.
Solution: To get rid of it, I took complete source from official openwrt
- `git clone https://github.com/openwrt/openwrt`
- `make menuconfig`
- *Enabling from menuconfig*
- `networking->usbip` `networking->usbip-client` and `networking->usbip-server`
And after compiling I got two binaries in sbin
/usr/sbin/usbip
/usr/sbin/usbipd
Which was needed and I was looking for. It works perfectly now.
I have always used erlang stdlib library zip:unzip/1 successfully. Last night i hit a bar with this error:
E:\WimaxStatsParser-1.1>erl
Eshell V5.9.2 (abort with ^G)
1> zip:unzip("e:/WimaxStatsParser-1.1/in/SomeZipFile.zip").
{error,bad_central_directory}
2>
Some one help explain the cause for this ? and how i get around it ?
ADDITIONS
I got some other error on another file: {error,bad_eocd}. Please explain this as well.
I am not able to reproduce your problem with the information you give. There are 2 functions that may send this error:
get_cd_loop/5 and get_name_extra_comment/4 in stdlib-1.18.2/src/zip.erl .
it should be easy to debug
copy the file zip.erl, zip.hrl, file.hrl in a working directory,
compile with debug_info option, you will get the error message "Can't load module that resides in sticky dir", leave the VM
copy zip.beam in the stdlib.../ebin
restart the VM in the working directory, you can now add breakpoint in the zip.erl source.
BR
Pascal.
I am trying to evaluate the answer provided here, and am getting the error: "A file with name ASDF-INSTALL does not exist" when using clisp:
dsm#localhost:~$ clisp -q
[1]> (require :asdf-install)
*** - LOAD: A file with name ASDF-INSTALL does not exist
The following restarts are available:
ABORT :R1 ABORT
Break 1 [2]> :r1
[3]> (quit)
dsm#localhost:~$
cmucl throws a similar error:
dsm#localhost:~$ cmucl -q
Warning: #<Command Line Switch "q"> is an illegal switch
CMU Common Lisp CVS release-19a 19a-release-20040728 + minimal debian patches, running on crap-pile
With core: /usr/lib/cmucl/lisp.core
Dumped on: Sat, 2008-09-20 20:11:54+02:00 on localhost
For support see http://www.cons.org/cmucl/support.html Send bug reports to the debian BTS.
or to pvaneynd#debian.org
type (help) for help, (quit) to exit, and (demo) to see the demos
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
* (require :asdf-install)
Error in function REQUIRE: Don't know how to load ASDF-INSTALL
[Condition of type SIMPLE-ERROR]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(REQUIRE :ASDF-INSTALL NIL)
Source:
; File: target:code/module.lisp
(ERROR "Don't know how to load ~A" MODULE-NAME)
0] (quit)
dsm#localhost:~$
But sbcl works perfectly:
dsm#localhost:~$ sbcl -q
This is SBCL 1.0.11.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (require :asdf-install)
; loading system definition from
; /usr/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd into #<PACKAGE "ASDF0">
; registering #<SYSTEM SB-BSD-SOCKETS {AB01A89}> as SB-BSD-SOCKETS
; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {AC67181}> as SB-BSD-SOCKETS-TESTS
("SB-BSD-SOCKETS" "ASDF-INSTALL")
* (quit)
Any ideas on how to fix this? I found this post on the internet, but using that didn't work either.
The instructions you got mentioned SBCL explicitely, so it's expected that they'll work better using SBCL, I suppose. Some other Lisps don't come with ASDF or don't hook it up to CL:REQUIRE. In the former case, you'll have load ASDF yourself beforehand. In the latter case, you'll need to call (asdf:oos 'asdf:load-op ) instead of (require ).
wget http://cclan.cvs.sourceforge.net/checkout/cclan/asdf/asdf.lisp
It worth checking out clbuild. http://common-lisp.net/project/clbuild/
To get a lisp webserver up and running. You only need:
darcs get http://common-lisp.net/project/clbuild/clbuild
cd clbuild
chmod +x ./clbuild
./clbuild check
./clbuild build slime hunchentoot
./clbuild preloaded
Now a lisp repl will start. There you write:
* (hunchentoot:start-server :port 8080)
Testing that the server answer:
wget -O - http://localhost:8080/
<html><head><title>Hunchentoot</title></head>
<body><h2>Hunchentoot Default Page</h2>
<p>This is the Hunchentoot default page....
try this before anything else:
(require :asdf)
you can steal some ideas from the environment we use. it's available at: darcsweb
see environment.lisp that loads and sets up asdf for us. (sbcl has asdf already loaded)
use clc:clc-require in clisp. Refer to 'man common-lisp-controller'. I had the same error in clisp and resolved it by using clc:clc-require. sbcl works fine with just require though.