I am trying to use multicore-0.2.15 toolbox with Octave v3.6.4 on Windows7 64bit
( http://octave.sourceforge.net/multicore/ )
but even the demo script doesn't seem to work, it's not possible to create a pipe and I received an error message. So if I try to evaluate the following command in Octave
[read_fd, write_fd, err, msg] = pipe ()
I receive the following output:
read_fd = -1
write_fd = -1
err = -1
msg = pipe: not supported on this system
The fork function doesn't work either.
Does anyone have an idea what the problem might be?
Zoltan
The error message pipe: not supported on this system says it all. There is no support for pipe() in your system (Windows 7). You can:
Not use the multicore which you will notice is unmaintained (see the unmaintained section at the bottom of the package list). You could instead use the parallel package.
Try another build of Octave. Maybe the MinGW builds will work with pipes.
Try another version of Octave. Version 3.8.1 has already been released and if it is a problem on the side of Octave instead of Windows, maybe it has been fixed.
Change operating system (pipe() works fine in Debian)
Related
I am trying to write a simple function to test why numba.cuda isn't working. The function should set a variable to a fixed value. When I call the function, it seems to compile, but nothing happens. I added, that it should raise an exception, just to see, that it gets called, but again nothing happens. I don't get any kind of exception to give me a hint, why it is not working.
Function:
from numba import cuda
#cuda.jit # also tried it with brackets: #cuda.jit()
def cuda_func(out):
out = 1
raise NameError('MyException')
I call the funtction like this:
>>> import Cuda_Class
>>> a = 0
>>> Cuda_Class.cuda_func[1, 1](a)
>>> a
0
numba.cuda.is_available returns True.
I am working inside a miniconda environment and had some trouble with installing cuda. I accidentally installed multiple versions, so I had to purge everything, and installed cuda 10.2 in my base environment. In the conda environment I installed the cudatoolkit (10.2.89).
I set CUDA_HOME to /usr/local/cuda-10.2. So nvcc --version gives me the right version. So the compiler is accessible.
NUMBA_CUDA_DRIVER should lead to cudalib.so, which I had trouble finding. I did not manually install the nvidia driver, it was installed in combination with cuda. I found cudalib.so under /usr/local/cuda-10.2/targets/x86_64-linux/lib/stubs/libcuda.so. There was no other file named libcuda.so, only libcuda.so.7. However, even before I set NUMBA_CUDA_DRIVER and it was empty, the behavior was exactly the same. No reaction, no exceptions. It looks as if the function would be called correctly, but nothing happens.
The only idea I have left is, that maybe it is a problem, that libcuda.so is in a "stubs" folder?
The first comment solved my problem:
I tried to change the value of an immutable Integer.
Although raise is supported by numba.cuda, apparently exceptions are not supported.
Neither of those mistakes lead to an error message.
Changing "out" to an array and manipulating the first value works.
UPDATE:
The JS version of closure-compiler is no longer supported or maintained.
https://github.com/google/closure-compiler-npm/blob/master/packages/google-closure-compiler-js/readme.md
Im trying to find if there is a way to remove the "debugger" keyword during compilation process, im using the javascript version google-closure-compiler with gulp.
Looking through the documentation it is clear we can set the flag to stop/show error messages during compilation by doing the following.
https://github.com/google/closure-compiler/wiki/Flags-and-Options
--jscomp_off
translating this to gulp, it is:
const googleClosureOptions = {
...
jscomp_error:"checkDebuggerStatement"
}
however this works on stopping the compilation by throwing error or to show a warning.
zyxcdafg.js:1444: ERROR - [JSC_DEBUGGER_STATEMENT_PRESENT] Using the debugger statement can halt your application if the user has a JavaScript debugger running.
debugger;
^^^^^^^^^
but what I am trying to achieve is to remove the debugger keyword. Is this possible to achieve using googleclosure. I can not find any flags or options relating to this.
UPDATE:
The JS version of closure-compiler is no longer supported or maintained.
https://github.com/google/closure-compiler-npm/blob/master/packages/google-closure-compiler-js/readme.md
No I don't think so. I'd suggest you use something else to do it. Like sed:
find dist -name "*.js" -exec sed -i 's/\sdebugger;//' {} +
Something like that will find files in your dist folder that end with .js and then exec-ute sed to replace all instances of debugger; with nothing.
You could add that to a script that calls your Closure Compiler build.
The compiler doesn't have a command-line api for defining custom code removal passes, but the compiler's architecture does allow for registering custom passes and a pass to remove a debugger statement should be trivial:
if (n.isDebugger()) {
compiler.reportChangeToEnclosingScope(n);
n.detach();
}
The general structure would follow:
https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/CheckDebuggerStatement.java
Our Tcl-based web application (OpenACS, NaviServer) provides the functionality for uploading and extracting ZIP Archives. After upgrading to the latest version of Tcl (8.5.18), the server now crashes when processing the contents of the extracted archive and spits out this error.
nsd: /usr/local/src/tcl/tcl8.5.18/unix/../generic/tclIO.c:5395: DoReadChars: Assertion `!((statePtr)->flags & ((1<<9))) || ((statePtr)->flags & ((1<<10))) || Tcl_InputBuffered((Tcl_Channel)chanPtr) == 0' failed.
This assertion has been introduced between Tcl 8.5.17 and 8.5.18. Is the assertion wrong or too rigorous, or does this hint at some form of error at the application level?
It turns out that I was running into a known bug that was fixed in April 2015 (http://core.tcl.tk/tcl/info/879a0747bee593e2). When Tcl 8.5.19 is released, using that will make my troubles go away. Before that, one can work from Tcl development sources, or try the patch in isolation (http://core.tcl.tk/tcl/info/4b964e7afb811898).
I'm currently develop an Objective-C library that links to the MariaDB C connector. I believe there is a problem with the library, though.
Every time I execute my code I get very strange errors on the console. The -(id)init method of my library calls mysql_init(NULL) to initialise the library but as soon as I return from -(id)init I get the following errors in the console:
Object 0x10643df70 of class XXX autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
Thing is, there is no multithreaded code being executed and if I run the same - (id)init without the call to mysql_init(NULL) the errors disappear. I believe the libmariadb library is causing these errors to appear. I don't get why though.
Do I need to build it with any special command line switches? Am I calling the right methods? I obviously used the MySQL online documentation as a guide.
Make sure you add this anytime you have a new thread:
#autoreleasepool {
//enter code here
}
Have you tried latest revision from launchpad?
Also try to build libmariadb with -DUNDEF_THREADS_HACK and
CMAKE_USE_PTHREADS:BOOL=OFF)
I was busy with other stuff for a while. I've since updated MariaDB to the latest version and, as far as I can tell, it works fine.
I built a console app to find all the *.ts files in my project and then compile them using tsc.exe.
Everything was working fine, but as I converted my JavaScript files to TypeScript, I eventually ran into the following error:
ytsc.js(21053, 17) Microsoft JScipt runtime error: 'window' is undefined
Each time this happened when I was trying to extend window:
window['prop'] = "something";
I tested the code until I found the answer, which had little to do with my code...
The fault was my build tool.
I had declared the -e (execute) command line option when calling tsc.exe:
I did this because I thought I might add some automated testing code in the modules.
The cause for the error:
Most of my code is in functions.
However, there were a few places that I wanted to extend 'window' (for example if a built in function is missing from an old browser, I was shimming those calls). The code to shim the window object was running as the file loaded:
if (window.fun == null) {
window.fun = function(){...};
}
Anyway, because of the -e option, the tsc.exe was attempting to run the code (outside of a browser environment). This caused the above error.