freenode/#lisp - IRC Chatlog
Search
8:42:45
White_Flame
so I'm trying to join #lispweb and it says "Cannot join channel (+r) - you need to be identified with services", yet I am identified. Is freenode still having problems?
8:43:18
White_Flame
in any case, are there any examples of using hunchensockets with sec-websocket-protocol?
8:43:46
White_Flame
the code in the implementation looks like an unexposed hack, but without being documented as such
12:30:43
xificurC
http://ix.io/1d5U/lisp - cli-arglist works fine when called in the REPL but the macroexpansion produces (&key). I guess that's because '(...) gets into clidef as (quote '(...)). What would be the solution? I am quoting the clidef because I want to be able to do `(:options (,@common-options (special #\s "special option" :flag)))
12:34:15
xificurC
I often have this issue, I have a list that I want to be able to build at runtime and use that list in a macro. If I leave out the quoting then I cannot write lisp code, I just turned that piece into pure data. If I put a quote there I don't know how to use that piece of code in a function call - ,(func arg) where arg went in as '(1 2 3) and now is
12:35:12
White_Flame
rumbler31: it's a websocket option to tell the server which user protocol you want to use inside your messages
12:39:12
White_Flame
in order to deal with runtime data, macros should output code to handle runtime data
12:40:23
White_Flame
for instance, if you're trying to do a mapcar on a runtime list, you don't have that list at compile-time; you need to generate the mapcar code that will take the runtime list
12:44:24
White_Flame
usually it's just passthrough stuff for body; they pretty much never are written to destructure into quoted fields
12:46:59
xificurC
White_Flame: I would hope not :) I'm building a library for handling command line. What I pasted is a piece of the puzzle. Basically I want to write '(:name "foo" :args ((file ...)) :description "makes some foo" :options ((down #\d ...) (create #\c ...)) to get a function (lambda (file &key down create) ...) that will be able to handle a command li
12:49:45
xificurC
White_Flame: ok, if I take the quote off, how do I (defcli foo) and (defcli bar) both sharing (defparameter *common-options* '((help #\h "prints this help" ...) (verbose #\v "prints debugging information to stderr" ...)))
12:50:59
White_Flame
the very first thing you need to do is figure out what your generated code should be
12:51:46
White_Flame
you also need to ensure that your defparameter value is available at compile-time
13:15:04
xificurC
compile time is a moving target when the compiler is available at runtime :) a defun in a library will be AOT compiled and a defun at a lisp file will be JIT compiled
13:22:05
xificurC
I'm doing something similar to this https://github.com/fare/command-line-arguments , just wanted to avoid the replication of the options (he writes check, verbose, warn ... twice) and skip the creation of a +command-line-spec+
13:25:44
xificurC
nowhere_man: I meant (load "x.lisp") and (load "x.fasl"). A library loaded with asdf will be precompiled into a fasl, isn't that right?
13:27:32
beach
Here is my latest suggestion with respect to the stepping commands of a good debugger: http://metamodular.com/stepping.pdf
13:28:33
xificurC
LdBeth: why would that matter. I was talking about handing a lisp file or a fasl to e.g. sbcl
13:32:00
xificurC
LdBeth: how does that relate to my point? I was saying compile time is a moving target. Think eval-when
13:36:27
phoe
beach: 5.2.1 - the debuggers I know behave as "step over" in that case. If you cannot step into an instruction, you step over it.
13:36:48
phoe
Your debugger may behave differently, though - *especially* if it informs the user that the instruction at point cannot be stepped into.
13:37:52
beach
phoe: In that situation, step over also has no effect. So it does behave like step over.
13:40:03
xificurC
White_Flame: here's a simplified piece of generated code i need - http://ix.io/1d6h/lisp . Think of that being e.g. in a (setf (symbol-function 'foo) snippet-here). The problem that is still baffling me is how to design the macro to take the data that defines the API (the '(:args ... :options ...) part) in a way it can be reused between different i
13:49:00
White_Flame
(defvar *shared* '(:key val)) is in the same format as what (mymacro (:key val)) receives
13:49:58
White_Flame
it's a statement. There's no difference in format between lists that a macro sees, and lists that are stored in variables
13:50:16
White_Flame
the quote is needed when things are being evaluated, but it's still just a list
13:51:12
xificurC
White_Flame: there's no defun, as I wrote the expansion should have been (setf (symbol-function 'foo) :snippet-here)
13:51:57
xificurC
White_Flame: (mymacro (key val)) is different to (myfunction (key val)) though, that's the point.
13:52:26
White_Flame
sure. (mymacro (key val)) vs (myfunction '(key val)) if you want to interchanget hem
13:53:45
White_Flame
or with (defmacro mymacro (paramlist) `(myfunction ,paramlist)), you can use (mymacro list-var) vs (mymacro '(key val)). It's your call
13:54:12
White_Flame
but if you have parameters that need to be evaluated, then you can't evaluate them at compile-time
14:11:40
xificurC
White_Flame: those examples are fine, I used them, but I'm stunned here because I'm trying to pass in code and use it as code in one spot and as data in another one
14:12:17
xificurC
White_Flame: as you said if you do `(func ,val) then val can be '(a b c) or (defparameter *x* '(a b c)) and then just *x*
14:13:09
White_Flame
one big issue is that build-cli is being called at runtime and is getting passed source code for lambda functions
14:14:12
White_Flame
if it's used in compile-time, then you can simply walk the structure and place the lambda clauses where they need to go
14:16:17
White_Flame
but stlil, with the backquote, your macro can't really do anything with walking it
14:17:22
White_Flame
I think at compile-time, you should walk the list structure and generate code for the clauses it encounters
14:20:19
White_Flame
but even with what you curretnly have, it doesn't work with (defcli dockerfile-generate (:args ...)), with (apply #'build-cli ',clidef) inside defcli?
14:20:51
White_Flame
ah, no, because you still have the lambda problem, and the lambdas need to be pulled out at compile time
14:36:51
White_Flame
there's no barrier to do what you want; the fact that you've written so much to be runtime instead of compiletime is constraining you
14:37:14
xificurC
actually I'm giving up on the macro because the function I want to generate I might want to use with other arguments than what comes from argv, right
14:40:11
xificurC
White_Flame: because '(:args ((file)) :options ((down #\d ".." :flag) (create #\c ".." :flag))) *is* runtime data
14:41:46
White_Flame
of course, it could simply be a stated requirement that it can be dynamically generated, which would force you to handle it at runtime
14:42:29
xificurC
White_Flame: I don't see how can it be compile time constant if I want it to be composed
14:43:23
White_Flame
so if you want a function whose arguments are extracted from that, it must be EVAL'd up at runtime
14:43:42
xificurC
the purpose of code is to automate tasks. I don't want to copy-paste common arguments all over the place :)
14:44:22
White_Flame
a macro can simply add &allow-other-keys to your defuns, and pass those through to the common handler
14:47:12
xificurC
White_Flame: I just don't see how to not have the quote there if I want it to be runtime composable
14:48:03
White_Flame
a function in that sense would do exactly the same as a macro in your broken case
14:48:23
White_Flame
a macro takes a spec, generates source code, and returns it to the current evaluator
14:51:33
xificurC
http://ix.io/1d5U/lisp didn't work. If you replace ,(cli-arglist def) with ,(cli-arglist (eval def)) it works. If you replace it with ,(cli-arglist (cadr def)) it works too
14:52:44
White_Flame
basically, he has runtime code to handle the spec list, but he also wants compile-time code to create a DEFUN whose arguments are defined by teh spec. The spec must be runtime-evaluated, as it might not be lieteral
14:53:08
White_Flame
xificurC: that doesnt' help you actually execute a DEFUN or instantiate a lambda
14:56:16
Bike
CADR will only work if it's a quote form. If it will always be a quote forom, you should just not have it be quoted instead.
15:00:20
xificurC
I'll just avoid the macro for now and have 2 steps - defining the spec and defining a function. Then there can be a helper function that parses the argv based on the spec and hands it over to the function
15:01:00
xificurC
and the function will stand on its own so it can be called and tested outside of an "argv context"
15:09:34
Xach_
Since macros don't evaluate their arguments like functions do, you can't use function-style tricks for reducing repetition.
15:10:21
Xach_
You have to work within the evaluation rules, or wrap them in things that expand into what you want instead.
15:13:57
xificurC
Xach_: the problem was I didn't realize that I'm trying to reduce repetition across 2 different times, run- and compile-. Novice lisper
15:18:16
xificurC
FYI I will release this code at some point so more criticism will be more than welcomed
16:11:46
jmercouris
I tried to do something like (loop for i in #*0110110001101111 do ...) but it complains
16:14:23
sjl
it's so lisp knows the kind of iteration you need at compile time, instead of having to have both code paths available and only one used at runtime
16:15:46
sjl
otherwise every IN would have to support both walking lists by CDR, and walking arrays with an index variable
19:00:25
makomo
beach: found a typo in http://metamodular.com/environments.pdf, "that the extension* incurs"