freenode/#lisp - IRC Chatlog
Search
19:04:39
Guest43479
Hey - just installed sbcl via homebrew on osx. I used `which sbcl` and used that with the shebang in the header `#!/usr/local/bin/sbcl --script` but it doesn't appear to load properly when run. Running this just via the command line works fine `/usr/local/bin/sbcl --script filename.lisp` not sure if anyone else had run into this?
19:40:03
Guest43479
./compile.lisp: line 3: syntax error near unexpected token `;;' ./compile.lisp: line 3: `;; testing comment'
19:47:43
malice
If all you want to do is run a script, you might also want to check out the Roswell project: https://github.com/roswell/roswell
19:51:34
malice
Also, since you're on mac, try to change the shebang for nonsense and see if it still works this way. On my system, giving wrong path shows "wrong interpreter[...]"; it might be that your interpreter is not loading properly
19:55:02
Guest43479
Interesting, thanks, yeah I'm getting a bad interpreter with nonsense for the shebang
19:58:59
Guest43479
Its not too big of a deal since `sbcl --script filename.lisp` is working, more curious than anything else
20:29:52
stacksmith
I am using CFFI to manage a foreign buffer. It contains multiple instances of a C structure at offsets not known until runtime (and changing often). WITH-FOREIGN-SLOTS seems to be a dead end as it has no provision to take an additional has no provision to take an additional offset - And it would have to be a dynamic offset as I need to access multiple instances of this structure... Any suggestions?
20:32:59
stacksmith
I am reluctant to use inc-pointer after learning that it conses up new pointers every time - I would prefer to avoid that...
20:36:54
stacksmith
Basically, I need the symbol-macrolets generated by with-foreign-slots to add an offset of the structure itself to the pointer...
20:42:52
stacksmith
In my SBCL it expands to (foreign-struct-slot-value ...) which in turn turns into (mem-ref ...)
20:46:00
stacksmith
I will restate my question: I have a custom way of doing this, but it seemed silly to have to define structures when CFFI already does that. Perhaps it's not so silly and I should continue without using CFFI for this.
20:59:50
stacksmith
fe[nl]ix: I can't figure out how much overhead it incurs as it goes deep into transforms and whatnot...
21:03:06
fe[nl]ix
stacksmith: use the default way and switch to a custom thing only if it proves to be slow, measurably
21:52:58
phoe
Does anyone have a macro that's like LET except it allows one to specify types for each variable as well?
22:07:59
Shinmera
I'm sure things like let+ and the three hundred other uber-let thingies can do that
22:09:03
phoe
yes. they seem to be much much more about destructuring than they are about typedness.
23:47:23
phoe
I might be silly and not seeing something, but: https://plaster.tymoon.eu/view/751#751
0:39:17
pierpa_
are you catching yourself writing (defun phoe (x) match x { Some(50) => println!("Got 50"); (otherwise (princ "got something else!"))}) ?
4:30:32
beach
I am still very pleased with the blazing fast incremental parser we now have for Second Climacs.
4:34:20
beach
Yeah. And it again shows that the right data structure (even without any low-level optimization) beats a mediocre data structure with lots of micro optimization.
4:34:48
beach
Perhaps this is a good time to point out that it is pure Common Lisp. No FFI involved.
4:52:18
beach
Yes, I know what an RFC is. But I don't know what subject you are interested in. Incremental parsing? Second Climacs? Using good data structure? Not using FFI?
4:53:49
asarch
I thought there was a centralized place where someone could send "suggestions" about a specif topic and then eventually be part of the standard
4:56:14
beach
I have a project called WSCL with the purpose of creating a standard with fewer cases of undefined behavior. But the only suggests I take are in that direction. I do not intend to add anything to the language.
6:07:50
beach
I am not sure how we should address the concerns of some of these referees. The editor that is mostly used for Common Lisp code is Emacs. When it parses Common Lisp code, it does not take into account the readtable, the package, the role of an expression, or anything like that.
6:07:52
beach
Our incremental parser does a much better job. But then the referees worry about what happens when there is a form in the buffer that changes the readtable, so that the wrong readtable might be used for the rest of the buffer. So essentially they are criticizing us for not solving the halting problem at typing speed, whereas apparently what Emacs does is acceptable.