(ql:quickload "aserve") fails
I'm trying to install AllegroServe. According to http://quickdocs.org/portableaserve/ and to this SO thread the simplest way to get aserve would be to get it with quicklisp: (ql:quickload "aserve")
But (ql:quickload "aserve") fails yielding the following error in the debugger buffer:
COMPILE-FILE-ERROR while compiling
#<IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "digest">
[Condition of type UIOP/LISP-BUILD:COMPILE-FILE-ERROR]
Whereas in the REPL it says:
; Loading "aserve"
; caught ERROR: READ error during COMPILE-FILE: Symbol "BIGNUM-TYPE"
; not found in the SB-BIGNUM package. Line: 53, Column: 52,
; File-Position: 2151 Stream: #<SB-INT:FORM-TRACKING-STREAM for
; "file
; C:\\Users\\user\\AppData\\Roaming\\quicklisp\\dists\\quicklisp\\software\\ironclad_0.33.0\\src\\digests\\digest.lisp"
; {25AFCD91}>
What I've tried so far
Apparently ironclad is another package, a "cryptographic toolkit written in pure Common Lisp". I downloaded ironclad-v0.34 from http://quickdocs.org/ironclad/ and even found digest.lisp and digests.lisp in the ironclad folder which made me think that I am on the right track.
My problem is I don't no where to go from here. How and where do I "install" ironclad?
Quickdocs says
[ironclad] comes with an ASDF system definition, so (asdf:oos 'asdf:load-op
:ironclad) should be all that you need to get started. The testsuite
can be run by substituting asdf:test-op for asdf:load-op in the form
above.
but since I'm not familiar with asdf I don't know what to make of it.
Am I even on the right track? Is installing the ironclad package the right way to make the error COMPILE-FILE-ERROR while compiling #<IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "digest">go away? If so what do I do with the ironclad-v0.34 folder?
(I'm using sbcl on a windows 10 machine.)
Thanks to #jkiiski leading me down the right path I was able to install aserve. The problem was indeed an old version of ironclad which, as #jkiiski pointed out, was using SB-BIGNUM:BIGNUM-TYPE which had been removed from SBCL.
However, the way I updated ironclad is probably NOT(!) a good way because I did it all manually (error prone).
Not knowing how quicklisp works exactly I searched for every occurence of ironclad-0.33.0 and replaced it with ironclad-v0.34, which meant replacing
the .../dists/quicklisp/software/ironclad-0.33.0 folder with .../dists/quicklisp/software/ironclad-v0.34
the irconcladd-0.33.0 tgz in .../dists/quicklisp/archives/ with ironclad-v0.34.tgz
the entry dists/quicklisp/software/ironclad-0.33.0/ in .../dists/quicklisp/installed/releases/ironclad.txt with dists/quicklisp/software/ironclad-v0.34/.
I also updated ironclad.txt and ironclad-text.txt in .../dists/quicklisp/installed/systems/
Well, it worked, but I only did it this way because I don't know any better (but am sure there has to be a better way).
Related
I'm trying to run the code below from BioSeqClass package, however I get an error message:
Error in system(command, intern = TRUE) : '“C:\Program' not found
selectWeka(data, evaluator="CfsSubsetEval", search="BestFirst", n)
This is a problem with how BioSeqClass is calling java: it is leaving the file names unprotected/unquoted, and R's system and system2 commands are horrible by not forcing quoting. (If you ever think of using these commands directly yourself, I strongly recommend something like processx.)
One should create an issue or bug-report, but I don't know how to do that with Bioconductor, and their mirror on github (https://github.com/Bioconductor-mirror) is defunct, so I'm at a loss there. Hopefully somebody with more info can weigh in on this.
Workarounds
It is not obvious if the problem is due to where weka.jar is located or perhaps one of the other arguments. You can find out where the problem is by debugging the selectWeka function and inspecting the value of command before the system call. Look for the Program Files component of a path.
If the problem is with weka.jar, then this suggests that you are installing packages somewhere under C:\Program Files\, which is in my experience bad practice on two counts:
For many problems I cannot recall (but this one re-ignites the discussion), I never install R in the default location under C:\Program Files\...; instead, I install it under a new directory, C:\R\R-3.5.3 (version-based) and go from there. You may not have control over this if on a university/company system.
Since this is not in a base-R package, this suggests that either you are not using a personal library location (collection of packages), or have placed your personal library for some reason under C:\Program Files. If the former, I strongly suggest you never install new packages inside the base-R installation directory, instead using your own. See ?.libPaths and many other tutorials/discussions on the topic online. Using packrat or checkpoint might also mitigate this problem.
If the problem is with trainFile (if I'm reading the source correctly), then your "permanent" fix is to change where Windows puts temporary files, as this trainFile is a temporary file created specifically for this function-run. If this is your problem, I'll leave it up to you to fix.
Regardless, you may not have time or need to make a more permanent solution, you just want to run this once or twice and then move on. For that fix:
Again, debug(selectWeka), and once command is defined (the next command to be executed is tmp <- system(command,intern = TRUE)), run this code to fix the value of command:
if(search=="Ranker"){
command = paste("java -cp ", shQuote(file.path(.path.package("BioSeqClass"), "scripts", "weka.jar")),
" weka.attributeSelection.", evaluator, " -i ", shQuote(trainFile),
" -s \"weka.attributeSelection.", search, " -N ", n, "\"", sep="" )
}else{
command = paste("java -cp ", shQuote(file.path(.path.package("BioSeqClass"), "scripts", "weka.jar")),
" weka.attributeSelection.", evaluator, " -i ", shQuote(trainFile),
" -s weka.attributeSelection.", search, sep="" )
}
(For the record, all I changed was adding shQuote twice to each paste.) Confirm that command now has quotes around things, something like
Browse[2]> command
[1] "java -cp \"C:\\Program Files\\...\\weka.jar" weka.attributeSel... -i \"c:\\path\\to\\some\\tempfile\" ...
Then you can continue-out of the debugger and let it run its course.
(I hope you don't have hundreds of calls to selectWeka.)
Caveat: I am not a use of BioSeqClass, so I'm saying all of this from speculation and inference. I might have mis-located the source of the error. And since I don't know what I'm doing with it, I have not tested the modified command assignment within selectWeka. I believe shQuote(...) is the right way to go, but you might need to use sQuote or dQuote instead, I'm not sure how your system is setup.
I got the following error wich is common with generated sources:
spec of this package does not allow a body
I would like to know if it exist a rule to put in the gpr file to ignore this error.
Like a ignore flag.
As I mentionned this files are generated so i have no right on them (not alowed to suppress them neither rewrite them).
More over it would be nice to have a rule that work for every generation.
If you were to compile
package Guillaume is
end Guillaume;
package body Guillaume is
end Guillaume;
in Ada 1983 mode, you would get e.g.
gnatmake -gnat83 guillaume.ads
gcc -c -gnat83 guillaume.ads
guillaume.ada:1:09: warning: package "Guillaume" does not require a body
guillaume.ada:1:09: warning: body in file "guillaume.adb" will be ignored
Having a body that isn’t required by the spec was made illegal with Ada 95 (it would be possible to change a body and for the compilation process not to notice that it needed to be recompiled, leading to confusion). If your code generator was designed to produce Ada 83, then I guess you may have to face compiling in Ada 83 mode - but GNAT doesn’t, as far as I know, guarantee to be 100% compatible, particularly as far as the run time system is concerned.
Are the offending package bodies all actually empty? If so, you might be able to list them and use the Excluded_Source_List_File attribute in your project. If not, you are in trouble, because there’s no way (without changing package sources) to get the code in them to execute.
(Later): actually, Excluded_Source_List_File doesn’t help; it stops gprbuild looking at the file, but not the compiler; and it’s the compiler that rejects the body. Sorry. But if you could make such a list you could use it to delete the bad bodies.
You can exclude the body from the list of source files:
for Excluded_Source_Files use ("my_body.adb");
I want to use R's mathematical functions as provided in libRmath from Ocaml. I successfully installed the library via brew tap homebrew science && brew install --with-librmath-only r. I end up with a .dylib in /usr/local/lib and a .h in /usr/local/include. Following the Ocaml ctypes tutorial, i do this in utop
#require "ctypes.foreign";;
open Ctypes;;
open Foreign;;
let test_pow = foreign "pow_di" (float #-> int #-> returning float);;
this complains that it can't find the symbol. What am I doing wrong? Do I need to open the dynamic library first? Set some environment variables? After googling, I also did this:
nm -gU /usr/local/lib/libRmath.dylib
which gives a bunch of symbols all with a leading underscore including 00000000000013ff T _R_pow_di. In the header file, pow_di is defined via some #define directive from _R_pow_di. I did try variations of the name like "R_pow_di" etc.
Edit: I tried compiling a simple C program using Rmath using Xcode. After setting the include path manually to include /usr/local/include, Xcode can find the header file Rmath.h. However, inside the header file, there is an include of R_ext/Boolean.h which does not seem to exist. This error is flagged by Xcode and compilation stops.
Noob alert: this may be totally obvious to a C programmer...
In order to use external library you still need to link. There're at least two different ways, either link using compiler, or link even more dynamically using dlopen.
For the first method use the following command (as an initial approximation):
ocamlbuild -pkg ctypes.foreign -lflags -cclib,-lRmath yourapp.native
under premise that your code is put into yourapp.ml file.
The second method is to use ctypes interface to dlopen to open the library. Using the correct types and name for the C function call, this goes like this:
let library = Dl.dlopen ~filename:"libRmath.dylib" ~flags:[]
let test_pow = foreign ~from:library "R_pow_di" (double #-> int #-> returning double)
I'm making a Turbo Pascal 7.0 program for my class, it has to be on Graphic Mode.
A message pops up
BGI Error: Graphics not initialized (use InitGraph).
I'm already using InitGraph and graph.tpu and I specified the route as "C:\TP7\BGI".
My S.O is Windows 7 and I'm using DosBox 0.74, I already tried to paste all the files from the folder BGI into BIN.
What should I do?
Since dos doesn't have system graphic drivers, the BGI functions as such for BP7.
So in short, use a BGI suitable for your videocard. The ones supplied with BP7 are very old, there are newer, VESA ones that you could try.
Afaik 3rd party BGI needs to be registered explicitly in code though.
At first I have had this "missing Graph.tpu"- ... and later the "Use Initgraph"-issue too.
After hours trying (and reading some not politeful comments in the internet) I finally got Turbo Pascal 7 succesfully running (in Windows 10, x64). In summary I want to share "some secrets":
install the "TP(WDB)-7.3.5-Setup.msi" (comes from clever people in Vietnam)
make sure, that there's the CORRECT PATH to the "BGI"-directory in your program-code. For example:
driver := Detect;
InitGraph (driver, modus, 'c:\TPWDB\BGI');
(By the way: This is ALL, what's there to do with "Initgraph".)
make sure, that in TP7 under "Options" --> "Directories" are the CORRECT PATHS both to "C:\TPWDB\UNITS" and Your actual working dir e.g. "C:\TPWDB\myPrograms"
THAT's IT.
Annotations: The "Graph.TPU" (usually) is already in "UNITS" (together with "Graph3.tpu" by the way).
Hazzling around old driver's isn't needed even... :)
Just the correct paths... :)
Hope, that can help ...
When you ask ESS to evaluate the following from a buffer (C-c, C-b, or similar)
par(ask=TRUE)
plot(1,1)
plot(2,1)
The interpreter goes into a infinite loop because ESS starts the R session with the argument --no-readline. The loop can be broken with C-g, but is there any way to get the interpreter to actually request user input?
A solution is to edit ess-r-d.el and remove the hard-coded --no-runtime option given to R, it is line 127 of the latest implementation.
Change
(let* ((r-always-arg
(if (or ess-microsoft-p (eq system-type 'cygwin))
"--ess "
"--no-readline "))
to
(let* ((r-always-arg
(if (or ess-microsoft-p (eq system-type 'cygwin))
"--ess "))
If there is a compiled version, you have to compile the .el to generate and replace the binary .elc file.
The file may be (the location of the directory depends on your OS)
in the site-lisp directory. Edit the .el file in emacs (^X^F) then do M-x byte-compile-file to generate the .elc.
if you installed from the whole zip/tar source package, in the lisp directory. In this case, after the change, perform a make followed with a make install.
You need of course to have write access to the .el and .elc files.
If you do not feel comfortable with the compilation of the .el file, you may simply remove it (.elc) and use only the .el version (should be only a slight performance difference).
(Strategies gathered from Google and RSiteSearches):
Do you see the prompt : "hit Return" in any of your session windows? If so ... hit .
If not, then try clicking in the plot window.
And if that fails, you should get control back with c-G.
Edit: A further strategy, admittedly not solving the ESS-non-interactivity problem: If you want to hold for user input, then readLines can be used:
input=file("stdin")
print(readLines(input,1))