I'm working on a Racket script (on a Linux machine) that requires the math/number-theory library. My entire script at the moment is thus:
#!/usr/bin/racket
(require math/number-theory)
Yes, it's literally just requiring the library.
When I try to run it, I get an error that reads "expected a `module' declaration found: something else".
However, when I actually start up Racket in the terminal like so:
/usr/bin/racket
and enter (require math/number-theory) in the command line, it treats it like it's totally valid.
What's going on here?
Make sure the top of your racket files contains a #lang statement as well.
In other words, you need this at the top of the file:
#!/usr/bin/racket
#lang racket
Related
I've recently set up Portacle 1.3 for learning common lisp on Win 7. However, whenever I run my code I get the error, even if there is no code.
Running individual lines works fine, however. The error only shows when I run the whole file.
I tried putting some code in an EVAL function, but I believe that only accepts one argument at a time, so I couldn't run a whole program in it.
I've found a similar error in this stackoverflow page, but their code contains colons and that's where their error lies.
I think it might be an error in the code that runs mine, seeing as I get the error even if I compile with no code, however I know nothing.
The full error:
main.lisp:1:1:
read-error:
READ error during COMPILE-FILE:
illegal terminating character after a colon: #\
Line: 1, Column: 13, File-Position: 12
Stream: #<SB-INT:FORM-TRACKING-STREAM for "file [path to file]\\main.lisp" {1005F5F0D3}>
Compilation failed.
Portacle is a standalone Emacs packaged with everything needed for Common Lisp development and which uses SBCL as the Common Lisp implementation.
I believe what you do when you say 'compile the whole file' is call slime-compile-and-load-file which is bound to the key sequence C-c C-k by default. There are a lot of moving components here:
Emacs is the text editor here. It also takes care of launching all the necessary components for Common Lisp development.
Slime is one such component. It serves as interface between Emacs and your Common Lisp implementation (SBCL in this case, but supports any Lisp in theory). Basically it sends the code you wrote in Emacs to your Lisp for evaluation.
SBCL is the Common Lisp implementation. In this case it is a compiler. This is what evaluates the code it receives and spews out the answers to the user interface in Emacs, through Slime. It also 'lives', in the sense that you interact with it by modifying the state of the loaded Lisp image, keeping track of defined functions, global dynamic variables and much more. This is why you can have the REPL, and why you need Slime to interact with it.
So to debug your problem, I would try to:
Launch SBCL from the Windows shell and run a simple .lisp file to check that everything works. You can put for example (format t "~a" (lisp-implementation-type)) in a .lisp file and run it in SBCL from the shell by calling (load "...\\file.lisp"). It should return "SBCL".
Create a completely new file using Emacs (and not weird Windows programs that could mess up the files) (C-x C-f), and try to call the compile from there (C-c C-k).
And I believe you made the right choice of IDE. Portacle is arguably the simplest tool out there if you are a total beginner in Common Lisp and do not know Emacs configuration. The keybindings are a bit daunting though.
I installed an Agda compiler, binarys can be from here: http://ocvs.cfv.jp/Agda/how-to-install-windows.html
... and I'm trying to make it compile a simple hello world app (I found the Agda 'Hello World' code online)
But I've never used Emacs before, and I don't know where to begin, or which commands to use to compile and run. I'm new to Agda, which seems to have limited options for compilers, and is lacking any step by step tutorial. Below is a screenshot of the Emacs compiler with the code I found:
open import System.IO using ( _>>_ ; putStr ; commit )
module System.IO.Examples.HelloWorld where
main = putStr "Hello, World\n" >> commit
I'm looking for step by step instructions to run a simple 'Hello World' program
A working example with another compiler would also be an acceptable answer
Thanks!
This looks like you attempted something like the general M-x compile rather than any specific Agda functionality.
The Agda:run mode indicator in the Emacs mode line suggests that you have a running Agda process in another buffer, but you're not looking at it. The Agda mode probably has something like agda-eval-buffer which should pass your current program to that process, and bring up the results in the lower half of the pane. (Try switching to a buffer called something like *inferior-agda* manually if you somehow cannot reach that buffer by other means.)
The site you link to says it's Agda 1 and you should probably actually look for Agda 2 on a different site.
Below the line is my original answer, which may still provide some useful insight.
The error message indicates that you need to install make.
I'm guessing there may be additional missing dependencies after you fix this one. Ideally the documentation should explicitly specify exactly what you need to install.
make is just a wrapper to run whatever cormands are found in the local Makefile. If there is no such file, you will probably want to change the compilation command to something else. (Typically Emacs asks you for a command to run, but supplies a plausible default.)
Given I am running on Linux and am no agda expert, this solution might not be worth it. But still I will give it a try.
When I installed agda and agda-stdlib on my system, it provides me with a file called agda2.el in /usr/share/agda/emacs-mode. That said I just had the following in my ~/.emacs.d/init.el file:
(load-file (let ((coding-system-for-read 'utf-8))
(shell-command-to-string "agda-mode locate")))
Since, you already have agada mode setup in Emacs the above wont be useful unless your version of agda mode is old.
We can compile the current file you have opened in Emacs using M-x agda2-compile. Doing this will open up another prompt asking you for a Backend. I used GHC as input and it compiled it. Yes, and I got some errors I don't know how to fix. So, I queried on a search engine and came up with:
module memo where
open import IO.Primitive using (IO; putStrLn)
open import Data.String using (toCostring; String)
open import Foreign.Haskell using (Unit)
main : IO Unit
main = putStrLn (toCostring "Hello, Agda!")
I need to point out that the first line module memo where should be same as the filename which for your case is memo.agda.
I now have a hello world program running on my machiene.
The following code compiles and works
open import Common.IO
main = putStrLn "Hello, world, strings working!"
is the code, stored in the file 'hello.agda', which I compile in emacs to 'hello'. I compile in emacs by selecting agda > compile, an option that is available on emacs when agda is installed correctly.
I can't give a detailed tutorial as to how to install agda on emacs as a friend did it for me, but the above code works, and compiles on emacs on linux, which is the set up which is working for me.
I have created a module which provides various functions, including #%module-begin. I want to use it with at-exp syntax, which I can do using the following #lang line:
#lang at-exp s-exp "my-library.rkt"
However, this does not read unknown symbols as strings, as would happen for example when using the scribble/text language. How can I provide this functionality from my library, to save me writing quote marks around all my strings?
I think it may have something to do with the #%top function. Perhaps I can require it somehow from scribble/text and then provide it from my library?
What scribble/text does, is it starts reading the file in "text" mode, whereas at-exp starts reading the file in "racket" mode. Messing with #%top is not what you want here. To do the same thing as scribble/text, you would need a version of at-exp that starts in text mode. That doesn't exist (yet) though.
The function read-syntax-inside from scribble/reader does this. However, you will have to define your own #lang language that uses it. For that, you might find this documentation helpful, but there's no quick answer.
Update:
I looked at the implementation of scribble/text, and the answer seems a lot quicker than I thought it would be. Something like this should work:
my-library/lang/reader.rkt:
#lang s-exp syntax/module-reader
my-library/main
#:read scribble:read-inside
#:read-syntax scribble:read-syntax-inside
#:whole-body-readers? #t
#:info (scribble-base-reader-info)
(require (prefix-in scribble: scribble/reader)
(only-in scribble/base/reader scribble-base-reader-info))
Testing it:
#lang my-library
This is text
#(list 'but 'this 'is 'not)
I tested this with my-library/main.rkt re-providing everything from racket/base.
#lang racket/base
(module x scribble/text
#(display 123))
It seems like #lang statements are not valid in nested sub-modules, and the expanded module version above is missing something:
error: module: no #%module-begin binding in the module's language
update:
looks like this more or less works, but is there a better way? does scribble do something with output ports that isn't being handled?
#lang racket/base
(module x scribble/text/lang
(#%module-begin
#reader scribble/reader #list{
hi
#(+ 1 456)
}))
First, your code has a redundant #%module-begin which can be removed.
#lang does several things -- one is control the semantics of the file
by determining the set of initially imported bindings, and that's
something that the module form has done before #lang came up. With
submodules, it became possible to use module for parts of a file too.
However, #lang can also determine the reader that parses the file, and
that's not possible to do with submodules, so you're stuck with only one
toplevel #lang to set the parser for the whole file.
(Sidenote: There is a technical reason for that. A #lang reader reads
the rest of the file until it reaches an eof value, so a nested
#lang would require getting an eof value before getting the end of
the file, or adding a new kind of eof-like value. That means that it's
a change that should be done carefully -- it's possible to do, of
course, but the need didn't come up often enough. Hopefully it will, in
the future.)
But in your case you don't want a completely new concrete syntax, just
an extension for s-expressions -- and an extension that was chosen to
have a minimal impact on regular code. So in almost all cases it's fine
to just enable the #-form syntax for the whole file, and then use
#-forms where you want it. Since it's just an alternative way for
reading sexprs, you can even use that with module, leading to this
code that doesn't need to use #reader:
#lang at-exp racket/base
#module[x scribble/text/lang]{
hi
#(+ 1 456)
}
(require 'x)
One thing that is a bit strange here is using scribble/text/lang and
not just scribble/text. Usually, #lang foo is exactly the same as
(module x foo ...) after reading the code with foos reader. But in
the case of the scribble/text language there is another difference:
using it as a #lang makes the semantics of the module body be "output
each thing". The idea is that as a language you'll want to spit out
mostly-text files, but as a library you'll want to write code in it
and do the printout yourself.
Since this code uses module, using scribble/text means that you're
not getting the spit-all-out functionality, which is why you need to
explicitly switch to scribble/text/lang. But you could have instead
just do the spitting yourself using the language's output, which would
give you this code:
#lang at-exp racket/base
(module x racket/base
(require scribble/text)
(output #list{
hi
#(+ 1 456)}))
(require 'x)
Note that scribble/text is not used as a language here, since it
doesn't provide enough stuff to be one when used (outside of a #lang).
(Which you've found out, leading to that redundant #%module-begin...)
This version is slightly more verbose, but I'm guessing that it makes
more sense in your case, since using it for some part of the code means
that you want to use it as a library.
Finally, if you really don't want to read the whole file with the #
syntax, only some parts, then the #reader that you've found is
perfectly fine. (And this is made simple with scribble/text that
treats lists as concatenated outputs, so you need just one wrapper for
each chunk of text.)
since I began using dbus with Emacs some days ago (meaning I recompiled with dbus-support), when I open a latex-file or try to switch manually to latex-mode, I get
File mode specification error: (invalid-function dbus-ignore-errors)
and emacs stops there remaining in fundamental mode.
I use dbus for Zeitgeist-Support and that works fine and up to the recompilation, Auctex worked equally fine. I checked if the dbus-functions are available with the result: They show up in the help (including "dbus-ignore-errors") but they don't seem to be available for execute-extended-commad (M-x) meaning they don't show up in completion and cannot be executed. On the other hand they are available for lisp-eval.
I don't know if that's normal behavior for these functions, but anyway there seems to be some sort of a problem with the availability of the functions for auctex?
The situation does not change by disabling the zeitgeist-plugin.
Any suggestions?
Best regards
Matthias
The error invalid-function usually means that a piece of Emacs Lisp code was compiled before a certain macro was defined, and is now trying to call that macro as a function. To solve this, find the module in question and recompile it after making sure that the macro (dbus-ignore-errors in this case) is defined.
In the case of Auctex, this happens because tex.el contains the following:
;; Require dbus at compile time to prevent errors due to `dbus-ignore-errors'
;; not being defined.
(eval-when-compile (and (featurep 'dbusbind)
(require 'dbus nil :no-error)))
That is, it tries to load the dbus library, but ignores failures. If the Emacs under which Auctex is being compiled doesn't support dbus, dbus-ignore-errors will thus be compiled into a function call when compiling tex.el. That's no problem, because the dbus-ignore-errors call is protected by a featurep test.
If this byte-compiled file is then loaded into an Emacs instance that does support dbus, we suddenly reach the line in question, and try to call the macro as a function, which fails with invalid-function. That's why the file needs to be recompiled before being loaded into a dbus-enabled Emacs.
One way to solve this is to wrap the dbus-ignore-errors line into eval, changing this line:
(dbus-ignore-errors (dbus-get-unique-name :session))
to this:
(eval '(dbus-ignore-errors (dbus-get-unique-name :session)))
That would postpone the decision on how to evaluate that expression until runtime, when Emacs will know that dbus-ignore-errors is a macro.