why does the first work, and the second not?
(require/typed (planet williams/science/random-source) [random-integer (Integer -> Integer)])
(require/typed math/base [random-integer (Integer Integer -> Integer)])
The second produces an error telling me that there is no such file or directory for math/base in my collects folder. Is it possible I am missing that from my racket distribution (v 5.3)? If so, for what reason? And how would I best resolve that?
Or am I just making a real bone-head mistake here? Sorry for all the noob questions...
I am basing my attempt here on http://docs.racket-lang.org/math/base.html?q=Random
Oh, and I'm running the 64 bit distro, I do believe, on OSX, if that's relevant.
I did not have the module installed. I was on 5.3, and the module existed only since 5.3.2
Related
I'm new to using coq/coqIDE and I'm not computer savvy either so I don't know whats wrong or what to call the issue. I was trying to go through the Software Foundations book, but coqIDE isn't working right. I'm using the latest windows 10, and coqIDE 8.10.2
The first issue is when I go to the tab compile -> compile buffer in Basics.v, coqIDE doesn't create a .vo file or a .glob. None of the other buttons worked either. Running coqIDE as admin didn't make it work either, but I figured out I can get around this by manually dragging Basics.v into the coqc application file.
I had no issues with coq working during the first lesson, but in the next lesson we're meant to import the definitions from Basics.v into Induction.v, when I run what they say
From LF Require Export Basics.
I get the error The file C:\Users\...\Coq Files\Tutorial\lf\Basics.vo contains library Basics and not library LF.Basics even though the _CoqProject file contains "-Q . LF" as it should.
I can get around this error too by just writing "Require Export Basics."
which properly loads, up until I actually try calling a definition from Basics
Running
Require Export Basics.
Example example: evenb 2 = true.
works until I get to evenb, and then gives the error
The reference evenb was not found in the current environment. even though it's in Basics.v
If I get even more anal and try
Add LoadPath "C:\Users\...\Coq Files\Tutorial\lf".
From LF Require Export Basics.
I get the error
Cannot find a physical path bound to logical path matching suffix <> and prefix LF.
And then finally if I try
Add LoadPath "C:\Users\...\Coq Files\Tutorial\lf".
Require Export Basics.
Example example: evenb 2 = true.
Loads properly.
So I'm wondering how should I fix the load path so that the project works without putting that junk in every file and how do I make the compile tab work.
There were some people talking about "hitting make in the top-level" but I have no idea what that means. I tried it anyway and ran the Makefile as a .bat even though I already downloaded it properly so there shouldn't be any need, but the Makefile didn't change anything anyway.
I don't think I'm forgetting anything, thanks in advance.
Instead of choosing Compile > Compile buffer, try Compile > Make instead (when browsing any one of the vernacular files in Logical Foundations) - I think that is what others meant by "hitting make in the top-level". But first, you may want to remove the workarounds you added in e.g. Induction.v, and save a trivial change in Basics.v such as adding/removing a newline somewhere in order to convince make to recompile it.
I would like to check for moderation with Stata using the interaction # and two continuous variables:
version 10.1: xi: regress ................///
c.var1_m#c.var9_m c.var2_m#c.var9_m c.var3_m#c.var9_m ///
var9_m , vce(robust)
However, it seems that only the newest Stata versions support this command, as I get the following error message:
cvar1_m#c: operator invalid
Does anyone know a way to fix this command as such that it also works with Stata 10.1?
(For example to fix the i. command, I typed in version 10.1: xi: and then it also worked on my older version - does something similar exist for c.?)
What version of Stata are you using? Stata 10.1, it seems.
Factor variables were introduced in Stata 11. Regardless of what version you are using this is documented accessibly (e.g.) here.
The question that then arises is why are you using the prefix version 10.1?
If you are using version 10.1, that prefix is redundant; otherwise, it can at most set the clock back to the syntax of earlier versions. It should be clear that it cannot possibly set it forward to the syntax of later versions.
A more fundamental mix-up is that (a) syntax using xi: as aegis and (b) factor-variable notation are (a) old and (b) new versions of the same idea. They should not be mixed. It may be that this alone is the problem, but experts on either [not me] might wish also to see your complete syntax and/or a reproducible example.
In short, if you are using 10.1, or indeed some earlier version, your only option (other than upgrading your Stata) is to cast your problem in syntax acceptable to xi:.
I have recently installed fedora 21 in my new system followed by emacs 24 text editor. When I try to do spell check, I am getting the following message at the bottom:
ispell-phaf: No matching entry for nil.
I understand that it has something to do with dictionaries linked with the ispell spell checking tool but unable to figure out exactly what the problem is. Please help me out friends....
Like #lawlist mentioned, the error is coming from the function ispell-parse-hunspell-affix-file. What ispell is trying to do is it's pulling in your set dictionary from ispell-dictionary or ispell-local-dictionary and then passing that value into the above function. That function then pulls the alist that is defined in ispell-local-dictionary-alist, which it then passes to hunspell.
So what you need to do in particular is to add an entry to ispell-local-dictionary-alist, something like this (example taken from here:
(setq ispell-local-dictionary-alist '(
("american"
"[[:alpha:]]"
"[^[:alpha:]]"
"[']"
t
("-d" "en_US" "-p" "D:\\hunspell\\share\\hunspell\\personal.en")
nil
iso-8859-1))
Where you need to make sure that where it says "american", you have the dictionary name that matches exactly with the value that you inputted into ispell-dictionary or ispell-local-dictionary, and make sure that you pass the arguments that you want into hunspell through this line: ("-d" "en_US" "-p" "D:\hunspell\share\hunspell\personal.en"). You can see what commands hunspell will take here. Hopefully that should at least get you a more meaningful error message so you know what else is going wrong.
I had a similar issue when migrating to a new OS as well. The migration also upgraded my emacs from 24.3 to 24.4 (and now I'm on 24.5).
I resolved this by installing the following:
rw-language-and-country-codes
rw-ispell
rw-hunspell
And then restarting emacs. I was stuck for a long time because I forgot to restart emacs - so don't forget! The wiki might also be helpful: http://www.emacswiki.org/emacs/InteractiveSpell
This worked for me finally (details in the following blog)...
http://blog.binchen.org/posts/what-s-the-best-spell-check-set-up-in-emacs.html
I chose the 'suggestion for non-programmers' in the above blog...
Thank you all for your support... #lawlist #Allan Zhang #Lucas #Rob Spanton
Even though the error has to do with a Hunspell function, this pops up when aspell can't be found by Emacs. Hunspell isn't used by default even when it's present on the system (as far as I can tell). Make sure it and some dictionaries are installed:
sudo yum install aspell aspell-en
or other dictionaries for other languages.
You might be interested in the Fedora package search:
https://apps.fedoraproject.org/packages/aspell
I had a similar issue after install Fedora 22. I resolved this by installing the hunspell-en-GB package from the Fedora repositories.
I have an org-mode file that I'm trying to export to a Beamer LaTeX PDF through XeTeX. It was working fine last night on this machine, and just as well on another machine on which I edited it afterward. Both are running org-mode 8, Emacs 24, same export process (3 runs of XeLaTeX)
When I synced back to this machine and tried to export again, I got the error Wrong block type at a headline named "". I checked all my headlines and gave them all names, but still got the same result.
Thanks to the wonders of indexed searchable FLOSS code, I immediately found the snippet online:
(env-format
(cond ((member environment '("column" "columns")) nil)
((assoc environment
(append org-beamer-environments-extra
org-beamer-environments-default)))
(t (user-error "Wrong block type at a headline named \"%s\""
raw-title))))
I'm not really solid on elisp at all, though, and I don't know most of what's going on here. From this snippet, what would I do to start debugging? (I realize I can start the emacs debugger, but it's not a PKE meter, I can't just wave it around.)
IMHE the best way to figure out what's wrong when you've found the relevant snippet of code is to use Edebug.
You should read the documentation to learn more about it, but basically here is my procedure:
identify the part of the code that crashes
instrument the code with Edebug (C-uC-M-x)
re-execute the code and go step by step to figure out what's going on (n)
If the problem is in another function, jump to it GOTO 2.
Iterate until you've understood the code and find a way to fix it.
Posting this answer just so that the specific solution to the particular problem the error was flagging is understood.
Apparently the version of Beamer I have on the other machine has a "normal" Beamer environment that specifies an otherwise blank, unformatted block. This is not present in this machine's install, or at least org/XeLaTeX don't know about it.
My steps were:
Search for all unnamed headings
Name each of them uniquely
Reproduce the error with the identifying string
Check the block type property against the available type list given in org-beamer-mode
Remove the offending type and replace it with another one
This is great and all, but I don't think it's the "best answer" because it involves no actual understanding of what the emacs interpreter was trying to tell me. If I didn't have a good idea of what was going on generally with the TeX, there's no way it would have worked. Dunno if this technique would impress anybody at an interview ;)
When I type 'f' in a C source file, my emacs with semantic installed and working
will show 25 completion matches, for functions like fclose, fread, and so on (only stdio.h
included)... but not fopen! Why?
Plus, same problem with opendir and readdir, with sys/types.h and dirent.h included.
P.S. semantic has all my sympathy, as upon my personal reading glibc header files showed
as a horrible mess of #ifnded and alikes.
'fopen' is turning up fine for me. Are you by any chance working on OS X? I remember that there were some preprocessor macros there which confused Semantic. Otherwise, your best chance for help is posting to the CEDET-devel mailing list, stating the CEDET version you're using and posting the exact definition of the 'fopen' function which apparently cannot be parsed.