I have a question about Clozure CL.
While I was trying to quickload a package from quicklisp.
It throws out an error. Have googled it, but nothing useful found.
Here is the error message:
(ql:quickload :drakma)
To load "drakma":
Load 1 ASDF system:
drakma
; Loading "drakma"
..
Read error between positions 6342 and 6532 in /Users/Mac/quicklisp/dists/quicklisp/software/cl+ssl-20111105-git/streams.lisp.
> Error: Foreign variable "O_NONBLOCK" not found
> While executing: CCL::%LOAD-VAR, in process Listener(6).
Thank you in advance
I've asked on mailing list:
answer from mailing list:
If you move or rename the "darwin-x86-headers" directory (or otherwise
try to simulate an incomplete installation):
[src/ccl-dev] gb#antinomial> mv darwin-x86-headers64 darwin-x86-headers64X
and then run CCL and try to access something (O_NONBLOCK) defined in the
interface files in that directory:
[src/ccl-dev] gb#antinomial> ccl64
Welcome to Clozure Common Lisp Version 1.8-dev-r15225M-trunk (DarwinX8664)!
? #$O_NONBLOCK
you get a warning or two about the missing interface files
; Warning: Interface file #P"/usr/local/src/ccl-dev/darwin-x86-headers64/libc/constants.cdb" does not exist, and the containing directory does not exist.
; This may mean that that the "ccl:" logical-pathname host has not been properly initialized. ; While executing: CDB-OPEN, in process listener(1).
; Warning: Interface file #P"/usr/local/src/ccl-dev/darwin-x86-headers64/libc/vars.cdb" does not exist, and the containing directory does not exist.
; This may mean that that the "ccl:" logical-pathname host has not been properly initialized.
before getting the same error that you reported.
If you use Quicklisp to load some code that tries to lookup that constant's value
in (missing) database files, you don't see that warning.
On the other hand, you do see dot characters printed when using
Quicklisp. (Sometimes lots of them !)
I don't claim to be part of Quicklisp's target audience, but I had a vote
I think I'd vote for being able to see progress messages and diagnostics
(even if that meant seeing fewer dots and even - especially - if the diagnostics
indicate an installation problem, as they seem to in this case.)
To stop flaming and try to address the original question, if the interface directory
is moved back to where CCL expects it to be, then:
? #$O_NONBLOCK
4
things work as expected. (If they didn't, it wouldn't be possible to compile
CCL itself or to compile lots of other code that uses the FFI's reader macros.)
That means that my best guess is that CCL isn't installed correctly on your
system. I don't know that with absolute certainty and I don't have any way
of knowing how it's installed on your system, but I believe that if it's installed
the way that the manual and website suggest problems like this are avoided.
Your CCL installation is incomplete or incorrect. Try asking on the CCL mailing list about it.
Related
Context
We are using NSIS 3.05 with Unicode true (this is important later).
We need to check if a certain process is running, let's call it "processToFind.exe".
In order to do that, we have been using nsProcess Plugin, which is set up correctly, found and integrated just fine.
We include Plugins from our git repository like this:
!addincludedir "C:\pathToRepo\NSIS\Include"
!addplugindir "C:\pathToRepo\NSIS\Plugins"
where pathToRepo is of course a valid path. We also tried using the default Plugin Directories (NSIS-Dir\Plugins\x86-unicode) to no avail (see below).
Documentation says, nsProcess (v 1.6) does suppport unicode. That's why we chose to use it.
NSIS UNICODE support (just rename nsProcessW.dll into nsProcess.dll)
When setting Unicode false or leaving the setting out (so default is ansi), it is working fine, too. ( = running processes found, not running processes not found )
The Installer is 32 bit, we are running on 64 bit Windows 10 machines.
Code
${nsProcess::FindProcess} "procexp.exe" $R0
MessageBox MB_OK "procexp: [$R0]"
which is defined in nsProcess.nsh (provided by plugin, not own code)
!define nsProcess::FindProcess `!insertmacro nsProcess::FindProcess`
!macro nsProcess::FindProcess _FILE _ERR
nsProcess::_FindProcess /NOUNLOAD `${_FILE}`
Pop ${_ERR}
!macroend
Problem
When having set Unicode true , nsProcess will always return 603 ("Process was not currently running").
That's the same, regardless if we try to find 32-bit or 64-bit processes.
That would be expected for 64-bit processes (they cannot be found from 32-bit installers, which is ok for us).
But I do expect it to find 32-bit processes.
Alternatives already explored:
Going through the list found at Check whether your application is running ...
Processes Plugin : Seems outdated, only sourcecode found.
"FindProcess.nsh" : Naming collision, didn't work, neither. Same symptoms.
DDE Server / Win32 Sync / Registry: Not an option.
"tasklist" command: Same symptoms. When executed in cmd, it works but not from installer.
nsExec::ExecToStack '"%SystemRoot%\System32\tasklist" /NH /FI "IMAGENAME eq ${processName}" | "%SystemRoot%\System32\find" /I "${processName}"' always returns "error". (* it's clear now why, see edit below)
"FindProcDLL" Plugin : skipped because
As of NSIS 2.46 this plugin no longer works...
Seemingly related Stackoverflow Questions explored:
NSIS : NsProcess UnExpected Output
Solution was to remove Unicode=true, which I cannot do.
NSIS- FindProc always returns 1
Uses FindProcDLL
NSIS - check if process exists (nsProcess not working)
Error was "Plugin not found" , which we do not have.
I am sure, we are making some "stupid" mistake since I cannot bring myself to believing we are the only ones with that requirement. So, any hints, suggestions and alternatives that are not listed above (or corrections to the above) are welcomed.
Edit
We totally messed up the tasklist call. As #Anders pointed out in comment: nsExec does not support pipes and on top of that, the syntax was also messed up.
Does official example work for you? It works on my machine.
Try this:
0) Delete all nsProcess.dll files (in NSIS, in your include folders, everywhere)
1) Remove line !addplugindir "C:\pathToRepo\NSIS\Plugins" from your script to use plugins in NSIS directories
2) Copy file nsProcessW.dll into **c:\Program Files (x86)\NSIS\Plugins\x86-unicode**
3) Rename file c:\Program Files (x86)\NSIS\Plugins\x86-unicode\nsProcessW.dll -> nsProcess.dll
4) Compile your script with Unicode true
I believe there is some file mismatch. To understand NSIS plugins structure see NSIS - check if process exists (nsProcess not working) .
I'm still using ANSI because I'm using some other plugins that don't have a Unicode variant, so nsProcess works for me, and I'm not sure how to answer your main question.
However, re: the tasklist command alternative you listed, the syntax isn't quite right. You're missing a closing quote after "IMAGENAME eq ${processName}["] and an opening quote before ["]${processName}" in the pipe to find.exe.
Also FYI note that if you use %SystemRoot%\System32\, a 32-bit process will be redirected to C:\Windows\SysWOW64\, and some programs have no 32-bit equivalent (e.g., pnputil). In this case, it doesn't really matter, but in any event to get around this, you should use $WINDIR\SysNative instead. You can also use ${DisableX64FSRedirection} from x64.nsh, but there are apparently some potential pitfalls there.
EDIT: Ah yes, and there's the issue with pipe and ExecToStack mentioned by Anders in the comments to the original question, requiring the call to be prefixed with cmd.exe /C
I decided my birthday would be a good time to try and fix my Lisp problems.
I've received a Lisp program from someone to run an experiment. It works well on his OS X environment. However, I can't get it to run on either Windows 7 or Ubuntu. The program uses Act-R 6.2 to run a model. When I try to load the .lisp file I receive the following error:
:Reader error on #<BASIC-FILE-CHARACTER-INPUT-STREAM ("*path*"/28 UTF-8)#xCFAD1AE, near position 1048, within "smile* (#initWithCo":
Undefined character #\/ in a #\# dispatch macro.
While executing: CCL:SIGNAL-READER-ERROR, in process listener(1)
The error is the exact same for Windows 7 and Ubuntu. Here is the console output if it is required:
http://i.stack.imgur.com/dFXVm.png
It seems load-turing-application.lisp loads multiple other files, one of which is turing-application-v1.lisp, in which the line (setf *smile* (#/initWithContentsOfFile: (#/alloc ns:ns-image)(ccl::%make-nsstring "smiley.jpg")))
seems to be the culprit. I suspect it has something to do with the #/-notation.
Any ideas would be appreciated.
This is answered in the comments, but #/ is a CCL syntax that only is available on OS X. This code is not expected to work on linux or windows.
I'm currently trying to get this script to work:
https://github.com/mj41/auto-unrar/blob/master/bin/unrar2.pl
The only problem is that I get the following error:
Entering directory 'Series'
Entering directory 'Series/SerieName'
Entering directory 'Series/SerieName/Season2'
Entering directory 'Series/SerieName/Season2/SerieNameS02E21.720p.HDTV.X264-DIMENSION'
Entering directory 'Series/SerieName/Season2/SerieNameS02E21.720p.HDTV.X264-DIMENSION/Sample'
Can't call method "List" on an undefined value at unrar2.pl line 973.
This line is rar_obj->List();
$rar_conf{'-verbose'} = $rar_ver if $rar_ver;
my $rar_obj = Archive::Rar->new( %rar_conf );
$rar_obj->List();
my #files_extracted = $rar_obj->GetBareList();
This is an old script, 3-4 years old and I changed a little like SHA1 to SHA and use Filesys::DfPortable; to Df
Does anyone know how I can fix this error :)?
EDIT:
I contacted the developer and he told me I needed to install a program that can handle rar commands. So how would I do that. I can't seem to be able to install unrar.
EDIT2:
What my problem is now, 2 of the 3 unrar packages aren't in my architecture, armhf.
To install the script yourself::::::::::::
https://github.com/jorricks/UNRAR
You need to pass the -archive parameter into the call to new() otherwise how will $rar_obj know which file it is supposed to be looking at?
I can't seem to be able to install unrar
That's not a particular good explanation of your problem. What did you try? What unexpected behaviour did you see?
From the tags on your question, it looks like you're running Debian. What do you see if you run sudo apt-get install unrar?
Update: My first comment was based on the code extract that you showed us. Looking at the full program code, I can see that %rar_conf has other values set in it (including the -archive option) before the section of code you gave us.
Looking at the source of the Archive::Rar module, it seems to assume that the program to use for dealing with the archives is called rar. So 7-Zip is not going to work.
I'm attempting to debug a problem with a .NET service starting up. I'm following the tip here, but I'm having trouble getting symbols. This particularly causes a problem with debugging .NET exceptions, because WinDbg refuses to download the correct mscordawks.dll.
The error I'm getting is: WARNING: Network path disallowed: 'SRV*C:\WebSymbols*http://msdl.microsoft.com/download/symbols'
Either it's doing this because I'm debugging something in session 0, or because I'm running WinDbg elevated. How do I resolve this issue?
I'm not clear exactly what you're doing to trigger that error message. I'll assume it's a .sympath command or similar.
Check the output of .netsyms
It's undocumented in the help file, but I spotted it in this blog entry and it seems to work. Maybe it defaults to off under certain security settings. Pure guesswork I'm afraid, but so simple to try that I thought I'd suggest it. It may be that the security context you are using forces .netsyms to be 0. John's trick will then be able to get you symbols from the network which you can use without needing a network symbol path.
Windbg should use the mscordacwks.dll that is part of your .NET installation - you are debugging on the machine that is running the service and therefore windbg has the same .NET installation available to it as your service. There should be no need for windbg to hunt for it anywhere else. Hopefully all that is actually needed is your symbol path to be set "correctly", rather than real problems finding mscordacwks.dll. We can look at that later if it's needed.
Check the current status like this:
0:001> .netsyms
netsyms = don't care
Turning it off produces something similar to your error message:
0:001> .netsyms 0
netsyms = no
0:001> !sympath srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Network paths are disallowed, symbol server is not available.
Set your symbol path to a symbol tree on the local machine.
Symbol search path is: srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
WARNING: Network path disallowed: 'srv*C:\Symbols*http://msdl.microsoft.com/download/symbols'
Turning it on again allows network symbol search paths:
0:001> .netsyms 1
netsyms = yes
0:001> !sympath srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Sounds like you are trying to debug one of the system services that may cause a deadlock when the debugger attempts to access the network.
Take a minidump of the process .dump /mf c:\tmp\mydump.dmp, Attach a debugger to the dump, set your symbol path as above and then .reload. This will cache all the symbols you need.
Then you can live debug using the path srv*c:\WebSymbols
My Cygwin environment (Windows 7 O/S) has developed a strange problem. A couple of days ago I was running a perl script fine, but today I'm getting
0 [main] perl 5056 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\perl
5\5.10\i686-cygwin\auto\Socket\Socket.dll to same address as parent: 0x8F0000 != 0x960000
Stack trace:
Frame Function Args
0088B508 6102749B (0088B508, 00000000, 00000000, 00000000)
0088B7F8 6102749B (61177B80, 00008000, 00000000, 61179977)
0088C828 61004AFB (611A136C, 6123E0FC, 008F0000, 00960000)
End of stack trace
I tried running rebase, as advised here but the problem persists. Any answers appreciated, as I have a demo tomorrow for which this script is needed. Wasn't expecting a problem like this!
This is a semi-informed answer, as I have had similar difficulty and eventually flailed around until the problem went away.
rebaseall with no arguments will rebase all of the dll files that were installed from cygwin packages. However you will often have many other dlls from other programs you have built and installed, including from installed Perl modules with XS code, and you will need to tell rebaseall about these modules somehow.
There may be an easier way to do this, and I hope I haven't forgotten any steps, but I think I had some success doing something like this:
Get a list of all the dll's in your system that run under cygwin. Maybe something like find /bin /lib /usr /home -name \*.dll > /tmp/file1
exit all cygwin processes, open as ash or dash shell from a Windows command prompt, and run /bin/rebaseall -v > /tmp/file2. The -v switch sets a Verbose flag in rebase that lists all the files that get rebased with the default setting.
Use /tmp/file1 and /tmp/file2 to create a new file, say /tmp/file3 with the complete list of files you will want to rebase. From what I remember it is important for the system dlls (all the files in /tmp/file2) to be listed first,
Now run rebaseall -v -T /tmp/file3 (in ash, after closing all cygwin procs, etc.). Pay attention to the output. If there are error messages about rebasing some particular dll, remove that entry from /tmp/file3 and try again.
This may not solve your problem, but maybe it will get you most of the way there. If you do eventually figure it out, I hope you will come back and fill in some of the holes in this solution.
I think it is useful to point out that for most people running into this a simple "rebaseall" without any arguments seems to resolve this issue. I'll post a link to a very useful blog post from My Life, Starting up (I have no relation to that blog):
http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html
The action list, (copied directly from the blog) is:
Let me tell you what you can do if you don't care what's actually happening.
1) Close out of Cygwin (and all cygwin processes).
2) Open a Windows command prompt (start -> run - > type 'cmd' or on vista : start -> type 'cmd' in the start search window)
3) Go to your cygwin bin directory. For me it is c:\cygwin\bin.
4) Type ash
5) Type '/usr/bin/rebaseall'
6) Resolve any errors (I had a warning that went unresolved and it still worked fine)
7) Reboot...and you should be good.
And if you DO care what's actually happening, read the blog entry, in addition to the answer by mob here on this same question.