Is there any kind of common lisp docs like javadoc, man or even intellisense-like popups? I've just started learning common lisp and do not have enough hand memory.
I am using emacs and slime — it has tab completion, but it seem not very informative.
Thanks!
Just in case this question was meant to ask where the reference is - there are several Hyperspecs available online. If you search Google for something like "hyperspec function-name" there's a good chance you will land on one of them.
http://clhs.lisp.se/Front/index.htm
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/FrontMatter/index.html
for example.
Depending on your editor, you can usually configure it to display it the hyperspec contents too. With SLIME in Emacs you can do M-x slime-hyperspec-lookup RET symbol-to-look-for
Another handy tool is apropos - by running (apropos "substring-in-the-symbol-name") you will get the list of all symbols that match the "substring-in-the-symbol-name".
SLIME itself provides good autocompletion. What might be tripping you is that the default keys may be bound to something that your system doesn't dispatch to Emacs (like M-TAB), in order to rebind it to something else you can do (in your .emacs file):
(define-key lisp-mode-map (kbd "C-x .")
'slime-complete-symbol)
(define-key lisp-mode-map (kbd "C-x /")
'slime-complete-form)
(define-key lisp-mode-map (kbd "C-x ,")
'slime-fuzzy-complete-symbol)
Besides, Emacs provides "lexical" completion on its own - if you hit M-/ this will try to complete the word to a word with the same suffix - it works surprisingly well, especially if you have to type in long variables/function names :)
Also, SLIME binds C-c C-d f to slime-describe-function-at-point and C-c C-d d to slime-describe-symbol-at-point and C-c C-v d to slime-describe-presentation-at-point.
Besides... something that came as a revelation to me after quite some time... if you press RET while in the buffer containing the error stack trace, point on the stack entry, it will display the value of the local variables inside the function at that stack level. If you then press RET when the point is on either of those variables, it will open a buffer describing that variable.
Look into manifest for package-based documentation. Keep in mind that Common Lisp is meant to be used as a dynamic system, and incorporates optional docstring slots into every declaration primitive it has. AFAIK, the standard way of getting documentation about a given function is to just run (describe #'function-name-here) at the repl (without the # if you're looking for documentation about a symbol).
That will give you access to docstrings as well as argument lists (in the case of methods, you get a compilation of the generic function's documentation, as well as each specific methods').
Look into autocomplete-mode, and possibly yasnippet for completions.
Related
I'm looking for a way to "enter" a module in the REPL, so that I can access all symbols without qualification (not just the exported ones), and any function (re)defined at the REPL gets in the specified module. (Basically this is the functionality of Common Lisp's in-package macro.)
This would be useful in a REPL-oriented workflow, as I would be able to write the same code in the REPL as in the module I am developing.
The manual recommends a workflow where I qualify everything, but that seems annoying.
I started a package called REPLMods.jl for this a while back. It should probably be polished up, but I haven't had the time.
I spoke to core Julia members and there was interest in getting it merged into base once things were clean, but again, no time!
I know this isn't quite what you're asking, but just in case the 'obvious' had not occured to you (or future visitors to the question), assuming you loaded a module with an annoyingly cumbersome name, e.g.
import LaTeXStrings
and you don't want to have to type LaTeXStrings all the time just to explore its accessibles, i.e.
LaTeXStrings.[TAB]
you can just assign the imported module as a whole to another variable, i.e.
const l = LaTeXStrings
I'm sure in the absence of a more appropriate built-in solution, at least typing l.[TAB] as opposed to LaTeXStrings.[TAB]is a lot more tolerable :)
(I find it odd, in fact, that julia doesn't seem to support the import LaTeXStrings as l syntax ...)
It's 2020, I'm using Julia 1.4, and was unable to get REPLMods.jl to work. I think the following seem good enough for the time being:
ExportAll.jl - see Exporting all symbols in Julia for a discussion (just that one shouldn't ExportAll to replace normal export)
and Revise.jl
I'm trying to add additional functionality to the already defined method "compile" in smalltalk.
here is the code I wrote:
compile: code notifying: requestor trailer: bytes ifFail: failBlock
self log:(self substring: code delimiter: $?).
super compile: code notifying: requestor trailer: bytes ifFail: failBlock.
as you can see compile has 4 parameters, I only know what to give the first parameter when calling the method compile (which is the code as a string).
whatever functionality I added isn't relevant, I'm not able to run any tests for my method because I dont know what to give the last 3 parameters.
So my question here is how can i call my method with the right set of parameters.
This is where I got stuck while writing a test for it:
co := ContractObject new.
code := 'rate: aRate
"?This is the Compiler Comment. Log me?"
hourlyRate := aRate. '.
co compile: code. "3 parameters missing here"
Since you mentioned this is a homework assignment, I will not deprive you of discovering the joys of a live, dynamic system like Smalltalk ;) The best tutor is your image itself. For many messages (including the one in question), there are helpful examples right under your finger tips that can give you clues about how to send them.
To find these real world examples, you "Browse Senders" of the message in question and see how these clients handle the parameters you're confused about. In Squeak (you didn't say which dialect and Pharo doesn't have that message), I see two senders in particular that show how to handle those parameters.
If you don't know how to "browse senders", there are many great references to teach you. For me, "Pharo By Example" is my go-to reference for basic "how do I" questions like yours (or "Squeak By Example" if you're using Squeak). This "fishing pole", if you will, will provide you with faster answers, and more understanding, then begging for fish on SO ;)
n.b. When asking Smalltalk questions, please tag the dialect (e.g. Pharo, Squeak, Amber) because not all dialects have the same set of messages (e.g. Pharo does not have the message you asked about)
While looking in the sample code for FunkyOverlayWindow, I just found a pretty interesting declaration:
pascal OSStatus MyHotKeyHandler(
EventHandlerCallRef nextHandler,
EventRef theEvent,
void *userData
);
Here, pascal is highlighted as a keyword (pink in standard Xcode color scheme). But I just found it's a macro, interestingly enough defined in file CarbonCore/ConditionalMacros.h as:
#define pascal
So, what is (or was) it supposed to do? Maybe it had some special use in the past?
While this discussion might not be well suited here, it would be interesting to know why Apple still using Carbon if this relates to the answer. I have no experience in Carbon, but this code appears to set a keyboard event handler which makes me wonder if there are any advantages over the Cocoa approach. Won't Carbon be ever removed completely?
Under the 68k Classic Mac OS runtime (e.g, before PowerPC or x86), C and Pascal used different calling conventions, so C applications had to declare the appropriate convention when calling into libraries using the Pascal conventions (including most of the operating system). The macro was implemented in contemporaneous compilers (e.g, MPW, Metrowerks, Think C).
In all newer runtimes, and in all modern compilers, the keyword is no longer recognized, so the ConditionalMacros.h header defines it away. There are a few comments in that file which may help explain a bit more -- read through it, if you're game.
You have encountered a calling convention.
The pascal calling convention for the x86 is described here.
It is very interesting that it was defined-away-to-nothing, which you notice means that it is not used anymore. It was common in the old days in x86-land, especially in the Microsoft Windows APIs, because of the ability of the processor to remove parameters from the stack at the end of a call with its special RET n instruction. Functions with the pascal calling convention were sometimes advantageous, because the caller wasn't explicity adjusting the stack pointer after each call returned.
If someone with more knowledge of why the macro still exists in the codebase, but is defined away comes along and gives you a better answer, I will happily withdraw this one.
I am frustrated with string-to-number and number-to-string conversion in GIMP scripting. I am runnning GIMP 2.6.8 in Windows Vista.
I understand that GIMP's internal Scheme implementation changes over the versions and I can't seem to nail down the documentation. From what I can gather GIMP's Scheme is a subset of TinyScheme and/or supports the R5RS standard procedures. In any case, I usually just look in the packaged script directory for examples when I want to try something new, because that should work for sure, right?
For example, grid-system.scm comes with the latest GIMP release and has the expression,
(string-append (number->string obj) " ")
which is exactly what I want. However, if I use number->string in my own script, or even type it into GIMP's script console (which is how I usually test out new stuff I want to do) it tells me number->string is an unbound variable:
> (number->string 3)
Error: eval: unbound variable: number->string
Other standard procedures from, say R5RS, work just fine:
> (string-append "frust" "rated")
"frustrated"
So,
1) Is there some lurking documentation for current GIMP Scheme scripting other than something drastic like searching GIMP's source code?
2) Can I use the GIMP console to spit out a list of all defined procedures to find something I need?
3) Anyone else confirm that number->string is not defined for the current Windows build, even though it appears in the packaged scripts? My web searches haven't turned up any related problems, and a complete uninstall of all GIMP versions, back to latest puts me in the same scrape.
You can rebind variables and monkeypatch top level standard library functions in Scheme, but I don't think you can unbind top level variables. Maybe there is some library file that isn't loading right.
My TinyScheme in GIMP 2.6.8 on OS X executes number->string just fine.
number->string is defined in share/gimp/2.0/scripts/script-fu.init as
(define (number->string n) (anyatom->string n number?))
so you could just run that code to rebind the variable. Or maybe you could reload script-fu.init
I'm writing a Linux kernel module that needs to open and read files. What's the best way to accomplish that?
Can I ask why are you trying to open a file?
I like to follow Linux development (out of curiosity, I'm not a kernel developer, I do Java), and I've seen discussion of this question before. I was able to find a LKML message about this, basically mentioning it's usually a bad idea. I'm almost positive that LWN covered it in the last year, but I'm having trouble finding the article.
If this is a private module (like for some custom hardware and the module won't be distributed) then you can do this, but I'm under the impression that if you are going to submit your code to the mainline then it may not be accepted.
Evan Teran mentioned sysfs, which seems like a good idea to me. If you really need to do harder custom stuff you could always make new ioctrls.
EDIT:
OK, I found the article I was looking for, it's from Linux Journal. It explains why doing this kind of stuff is generally a bad idea, then goes on to tell you exactly how to do it anyway.
assuming you can get pointers to the relavent function pointers to the open/read/close system calls, you can do something like this:
mm_segment_t fs = get_fs();
set_fs(KERNEL_DS);
fd = (*syscall_open)(file, flags, mode);
if(fd != -1) {
(*syscall_read)(fd, buf, size);
(*syscall_close)(fd);
}
set_fs(fs);
you will need to create the "syscall_*" function pointers I have shown though. I am sure there is a better way, but I believe that this would work.
Generally speaking, if you need to read/write files from a kernel module, you're doing something wrong architecturally.
There exist mechanisms (netlink for example - or just register a character device) to allow a kernel module to talk to a userspace helper process. That userspace helper process can do whatever it wants.
You could also implement a system call (or such like) to take a file descriptor opened in userspace and read/write it from the kernel.
This would probably be neater than trying to open files in kernel space.
There are some other things which already open files from kernel space, you could look at them (the loop driver springs to mind?).
/proc filesystem is also good for private use, and it's easy.
http://www.linuxtopia.org/online_books/Linux_Kernel_Module_Programming_Guide/x773.html
All of the kernel developers say that file I/O from kernel space is bad (especially if you're referring to these files by their paths) but the mainstream kernel does this when you load firmware. If you just need to read from files, use the
kernel_read_file_from_path(const char *path, void **buf, loff_t *size, loff_t max_size, enum kernel_read_file_id id)
function, which is what the firmware loader code uses, declared in include/linux/fs.h. This function returns a negative value on error.
I'm not really sure of the point of the id variable at the end, if you look at the code it's not really used, so just put something like READING_FIRMWARE there (no quotes).
buf is not null terminated, instead refer to its size in size. If you need it to be null terminated, create a string size + 1 bytes long and copy it over or rewrite the kernel_read_file() function (used by kernel_read_file_from_path(), defined in fs/exec.c) and add one to i_size where memory is allocated. (If you want to do this, you can redefine the kernel_read_file() function in your module with a different function name to avoid modifying the whole kernel.)
If you need to write to files, there is a kernel_write() function (analogous to kernel_read(), which is used by kernel_read_file() and therefore also by kernel_read_file_from_path()), but there is no kernel_write_file() or kernel_write_file_from_path() function. You can look at the code in the fs/exec.c file in the Linux kernel source tree where kernel_read_file() and kernel_read_file_from_path() are defined to write your own kernel_write_file() and kernel_write_file_from_path() functions that you can include in your module.
And as always, you can store a file's contents in a char pointer instead of a void pointer with this function by casting it.
You can also find some informations about sys_call_open in this Linux Kernel Module Programing Guide.