I am using SWI Prolog 6.6.4 on Windows 7. When I run programs with trace, all I seem to get is a load of jumbled Chinese/Arabic characters. Example output includes lines like:
Call: (6) ...锠销锿销锠销
ꀊꀀ Call: (7) ...꜠꜀ꜿ꜀꜠꜀ꀀꁥꀀꁥꀀꁰꀀ
ꀊꀀ Exit: (7) ...뀠뀀뀿뀀뀠뀀ꁣꀀꁲꀀꁥꀀꁥꀀꁰꀀ
Does anyone know what to do to eliminate these characters so that the trace runs as normal?
I had the same problem and found this discussion:
http://swi-prolog.996271.n3.nabble.com/Weird-characters-displayed-when-trace-is-on-td14628.html
It seems to be a bug in the current version which will be solved in the next (actually, it is already solved in the beta-versions).
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've had this issue for a while now. Every time I use SOAP::Lite in debug mode (whether normal debugging or with something like NYTProf) it ends up calling the on_fault handler.
I've stepped through and it is due to this error:
Attempt to reload SOAP/Lite/Deserializer/XMLSchema2001.pm aborted.
Compilation failed in require at (eval 1343)[C:\\Perl\\site\\lib/SOAP/Lite.pm:2328] line 3.
...propagated at C:\\Perl\\site\\lib/SOAP/Lite.pm line 2328.
I'm wondering if this is normal and what the best workaround is? Thanks.
Edit: Forgot to mention this is Activestate Perl 5.10.1 on Windows and upgrading is not an option at this time.
Found it! Running perl with both -d and -w flags seems to cause an issue in the debugger with the scope of warnings. It complains about redefined subs in this mode, but ignores them if we supply just one or neither of the -d/-w flags.
The issue is in SOAP::Lite::Deserializer::XMLSchema2001, the BEGIN block maps the as_* methods. dateTime is in the list twice so we get an error about as_dateTime being redefined.
This breaks the initial module compilation, and upon our 2nd attempt produces the error above.
I have various matlab installations for Linux 64 bit, running Fedora 19/
For now, lets say I'm using MATLAB2010R.
I tried wiping my .matlab/ config and that didn't help.
>>>system('ls')
bash$ <hangs>
bash$ exit
foo
foobar
ans = 0
>>>
So I have to manually exit for the system call to return to the Matlab prompt.
This breaks various things, such as copyfile.
This is a dumb problem acutally...
From within matlab:
>>system('ls')
bash$ps Aux | grep user
we can see that I tcsh was called, then tcsh called a bash instance.
I set this up a long time ago, b/c I couldn't change my default shell very easily.
That is the whole problem...
Though question is quite old, I am still answering in the hope to help someone having same issue.
I had the same issue. I managed to solve this issue by uncommenting one line in .matlab7rc.sh file in directory.
open .matlab7rc.sh file and search for line
LDPATH_PREFIX='$MATLAB/sys/opengl/lib/$ARCH'
Above line is present three times in .matlab7rc.sh file for Matlab 2016. Uncomment all of them.
And it is also stated in above mentioned file as
To always use the OpenGL libraries shipped with MATLAB uncomment the next line.
This works like charm. Now, Matlab is exiting normally.
First time perl user and I am trying to debug some script to follow project logic and of course syntax.
Using cygwin after entering at command line $
$ perl -d sample.pl
Loading DB routines from perl5db.pl version 1.3
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
main::(sample.pl:5): print 'Hello world.'; # Print a message
DB<1>
It hangs at the DB<1> line. I cannot enter anything at the prompt.
Is there a reason why this post is inappropriate? or how is this not clear?
This is the actual program code:
#!/usr/local/bin/perl
#
# Program to do the obvious
#
print 'Hello world.'; # Print a message
I upgraded my cygwin installation at home and ran into a similar problem (though maybe not the exact same problem -- the perl debugger still responds to my input but does not display my input, and fubars my input even after I quit the debugger). In the meantime while I figure what is going on, my workaround is to fire up xemacs, launch a shell (M-x shell), and run the perl debugger from the emacs buffer.
If this works for you, then there is something funky going on with your cygwin terminal settings. If your debugger hangs even in an emacs buffer, then something else funky is going on but I have no idea what it could be.
Sorry for reviving this three-year-old question, but I believe to have been hit with the same problem, and to have found the solution.
In my case, perl -de0 invokes infocmp from ncurses, which hangs in a weird way (can't kill it). And infocmp seemed to be a victim of my Avast anti-virus which is listed under BLODA as affecting Cygwin. Disabling it resolved the issue -- see if you have any of the listed applications and try disabling it (perhaps also try safe mode).
Also, simply renaming infocmp.exe allowed perl -d to run normally. In the end I used this approach and left my Avast running.
It could also be a different executable that perl -d is starting -- try to run whatever hangs with strace, see what is the last executable mentioned and try to see if that is the culprit.