freenode/#lisp - IRC Chatlog
Search
7:13:51
jackdaniel
ober: I didn't work with fat which is well implemented afaik. mostly drm (direct rendering mechanism) and writing custom drivers. it is well written, but it is a frustrating work: i.e you have to restart device to reboot the kernel and check your changes. debugging is hard too (though jtags help)
7:14:29
LdBeth
EvilTofu: A lower level machine code generator and optimizer for CL, may or may not be llvm
7:14:36
jackdaniel
johnjay: it is based on 2.6.x I think. it is good, you'll get a grasp of the abstractions which exist there, but there is much more to learn from the code (like with any non-trivial source code)
7:15:12
johnjay
i was thinking of writing some drivers for reactos, and i wondered how much studying linux driver model would help for that
7:16:08
jackdaniel
reverse-engineering custom protocol is way harder. but this is offtopic on this channel. sorry for bringing this up
7:35:15
jackdaniel
EvilTofu: opengenera is a full operating system with a development environment etc etc, it is not a CL implementation (however it has CL implementation in it)
7:47:05
aeth
I would imagine that quite a few libraries would be broken. Maybe even the majority on Quicklisp.
7:55:26
Demosthenex
hrm. i'm having to learn about GC and scaling now. i hadn't realized my latest rest-api downloads were over 300mb... no wonder it's taking ages. parallelism doesn't help
7:56:15
Demosthenex
parallel wget's can download it in 5.6 seconds, but in lisp it's running a half hour or more. but that's download, parse, and insert into db.
7:57:33
Demosthenex
no-defun-allowed: dexador is pulling it down gzipped. but it appears to uncompress before passing it to me
8:27:23
schweers
CatchMe: I’ve never done this, but my guess would be: make a lisp function which can be called from C (implementation dependent), have that object create/obtain said object and return it. But I’m not sure this works in general.
8:28:30
schweers
I’m not sure what has to be done so the object will not be collected while some C code still holds a reference to it, and how to collect it once C no longer has a reference.
8:39:28
schweers
you can always pass pointers? This kind of code is probably always going to be pretty ugly.
8:53:29
no-defun-allowed
i can read some french but probably not enough to read a book. "je ne parlais francais"
8:53:32
beach
I have vague plans for translating it to English, but I would need to get the copyright back from the editor.
8:53:34
smokeink
quick question: https://github.com/norvig/paip-lisp/blob/master/lisp/macsyma.lisp#L211 <- shouldn't this line be (1 `(- ,(integrate (exp-lhs exp) x))) ? Otherwise (simp '(int (- x) d x)) returns `(1/2 * (X ^ 2)) instead of `(-1/2 * (X ^ 2))
8:54:40
smokeink
I'm surprised that this bug has survived up to the latest code on github. It's in the book as well
8:55:12
loke
smokeink: The latest version of Macsyma is called Maxima, and I don't think it has such bugs.
8:55:57
no-defun-allowed
if i had to guess, the PAIP copy would be a clone in the spirit of ma{csyma,xima}
8:56:12
smokeink
I mean the sourcecode for the book PAIP , which has been studied by many students and teachers
12:28:26
jackdaniel
you may find plenty of examples how to work with cl_objects directly in ECL's code and documentatino about ffi
12:32:04
jackdaniel
beach: it's the other way around. that bridge could be used to access Lisp from C++ (i.e from LLVM module)
12:32:23
jackdaniel
we already can interface with C++ from ECL if compiler is built with C++ support
12:36:48
jackdaniel
that said I have plans to generalize compiler's backend interface in ECL (to be able to plug into something else than C compiler), but you already know that
13:05:56
makomo
i posted this http://plaster.tymoon.eu/view/917#917 yesterday but i think it was pretty late for most of #lisp, so here it is once again. if anyone has any suggestions i'd be happy to hear about them
13:06:39
makomo
shka_: regarding the code walker solution, here's what i came up with (it took some diging
13:08:11
shka_
makomo: sadly i can't comment as each time i am attempting code walking something bad happens
13:09:59
makomo
Xof: thanks for the initial example. also, i just realized you were the author of that code walking article (let over lambda + sbcl). :-)
13:10:36
makomo
shka_: heh. if only there was a code walker within the standard. i think it would make many things a lot easier :^(
13:12:08
beach
makomo: I can't really understand the description, unfortunately. Too many unknowns like "signal" and "process"
13:12:16
makomo
at a first glance, it doesn't appear to have a lot of documentation, but then again, SB-WALKER isn't any better
13:13:38
makomo
beach: the problem isn't very domain specific. the one thing that you need to know is that i need to somehow "preprocess" the body of a :process and find all of the <signal>s within function calls of the form (<- <signal> <value>)
13:14:03
makomo
this has to be done *before* the body of a :process is actually run (and that happens within the simulation)
13:14:16
heisig
agnostic-lizard is as portable as it can be. The only thing where it fails (and where all code walkers fail) is when a macro stores its environment in a global variable and another macro uses it.
13:15:16
makomo
beach: the simulation has to know what signals a process is trying to assign to, because that information is necessary to set up the simulation
13:15:51
beach
heisig: If it has its own representation, then things will fail when a macro passes the environment it receives to the MACROEXPAND of the system.
13:17:27
beach
makomo: Do the <- calls need to be replaced, or is that operator defined in the environment that you compile the thing in?
13:18:05
jackdaniel
makomo: if it is your dsl, and if you can mandate, that (<- …) is always toplevel (i.e it is not nested in other instructions) it is as trivial as traversing the "BODY" list and counting CAR's being eq to '<-
13:19:11
makomo
beach: hm, i haven't decided yet whether <- is even going to be a function. it will probably have to a macro actually, because the first argument is always going to be a symbol, and i don't want the user to have to quote it every time. currently, it's a global function within the whole program
13:19:35
beach
makomo: Also, what does it mean to "find" them? Get a copy of the form? find the location within the process? Something else?
13:20:08
makomo
beach: get a copy of the form, but only if that form represents an actual function call (rather than being a quoted list or something else)
13:21:05
jackdaniel
because if you want to calculate, how many output pins you need, then such if should count as 1
13:21:14
beach
makomo: What if you make it into a macro or a compiler macro that expands to (eval-when ...) and have some side effects at compile time, like consing them onto a list held in a special variable?
13:22:07
makomo
perhaps "count" is an unfortunate word. i don't know how many times it's called, only the signals that are being assigned to
13:22:47
jackdaniel
he wants copies of all forms, if you count them twice, you have twice the copies you need. that depends on what he wants to do
13:23:04
makomo
beach: that could work (and is the 2nd idea in my comment) but i worry that it might be tricky. the body of a :process isn't valid lisp code right away, for example. i first need to wrap it within a LET that will bring all of the implicitly used signals into scope
13:23:47
makomo
beach: which means that all that work has to be performed at macroexpansion-time (by DEFCOMPONENT for example)
13:24:23
makomo
i.e. DEFCOMPONENT would somehow arrange for (<- ...) to be expanded, but the only way i know of doing this is by placing that code within a lambda for example
13:26:10
beach
You can use Generate-AST of Cleavir to do things like that. It will allow you to capture references to undefined variables. But it's a bit involved to set up a first-class global environment for Cleavir to work against.
13:28:01
heisig
beach: agnostic-lizard simultaneously maintains its own environment (called metaenv) and the host environment. I have not fully understood the details, but macroexpand-1 uses eval at some place to patch the host environment appropriately.
13:28:28
makomo
beach: hm, sounds interesting. that would be a variant of the code walking solution right?
13:29:07
makomo
right, so it's either (1) code walking or (2) macroexpansion-time trickery. so far i haven't thought of anything else
13:29:12
beach
heisig: That sounds very strange, because the host lexical compile-time environment is not a portable thing.
13:46:40
makomo
beach: hm, thinking about the EVAL-WHEN solution (which is a variant of the macroexpansion solution) -- wouldn't expanding into an EVAL-WHEN fail for non-top-level forms, since calls to <- can appear anywhere within the body?
13:54:17
beach
But as I understand it, you can't use that solution anyway, because you can't compile the process until you know the signal variables, so that you can wrap the process code in a binding form for them.
13:57:27
makomo
beach: i wasn't very explicit about what i meant there. the knowledge about which signals are potentially assigned is required for the simulation. for actually generating the full :process body (which is part of defining the component), only the signals declared within the :signals clause + the component's pins (2nd argument to DEFCOMPONENT) are required
13:58:18
makomo
defining the component happens before the simulation. so the macroexpansion solution would work, but it would require the body generation to happen at macroexpansion-time
13:58:41
makomo
i guess that's not really a problem, but it just appears "complex" to me, for some unjustified reason
14:05:10
beach
Well there is also the problem jackdaniel mentioned, that the macro can be expanded any number of times.
14:21:00
makomo
beach: mhm, i thought of that too, but fortunately i only to know whether the signal appears *at all*, not how many times
14:22:28
makomo
jackdaniel: oh, i didn't refuse. i already created a solution that uses a code walker, but it uses SB-WALKER http://plaster.tymoon.eu/view/919#
14:22:49
makomo
jackdaniel: i was going to try angostic-lizard next, but i don't know where to start
14:23:52
makomo
i think <- will end up being a macro anyway, because i don't want the user to have to quote the symbol's name every time
14:30:35
jackdaniel
unfortunately agnostic-lizard doesn't provide a hook for unexpadned macros (there is some hardwiring interface though)
14:36:07
jackdaniel
solution to that could be wrapping body in `(flet ((<- (&rest args) nil)) ,body)
15:15:15
schweers
does lisp has something similar to this? http://mirror.racket-lang.org/docs/5.1/html/reference/fasl.html
15:16:16
makomo
jackdaniel: regarding DSL design and the requirements/constraints on its usage: you mention that it's reasonable to require that one doesn't try to FUNCALL/APPLY #'<-. would you fit (1) local functions that call <- and (2) lambdas that call <- into that category as well (whether or not either of those gets actually invoked)?
15:16:59
makomo
jackdaniel: i think it's reasonable as well. the documentation will simply say something like "using <- in such and such context is undefined"
15:34:04
jackdaniel
so it is enough to say, that <- is a macro (and that should be enough for a Lisp programmer to know, that funcall/apply doesn't, khm, apply here)
15:34:11
makomo
jackdaniel: true, but let's say someone just uses it within a local function or a lambda (which might or might not be called eventually)
15:34:49
makomo
for example, something like (let ((func (lambda () (<- a 1)))) <body which never actually calls func>)
15:35:20
jackdaniel
also mind, that if you have body like: (progn (foo) (bar) (<- g)) code walker will count *one* <- invocation
15:36:44
makomo
so, global functions, local functions and lambdas (which are almost like local functions in the context of this problem)
15:37:19
makomo
jackdaniel: i'm wondering whether to just declare the usage of <- within any of those as invalid/undefined behavior
15:38:23
jackdaniel
in your defwhatever macro you may simply macrolet <- , otherwise it is undefined
15:38:30
makomo
jackdaniel: yeah, the question is a bit tricky since the constraint really depends on how i want to design the DSL, which requires a bit of domain-specific knowledge to answer properly
15:39:13
jackdaniel
I'm sure mrSpec could give you a hint or two on that, but he rarely speaks here ;)
15:43:31
Xach
A bunch of failures in http://report.quicklisp.org/2018-09-11/failure-report.html are of the form: Trying to use AUTOCOLLECT without TRIVIAL-GARBAGE
16:55:00
aeth
cl-sdl2 is *really* bad with caches. I've had problems with it 3-4 times that were solved by deleting caches for it. I'd delete caches and retry before reporting bugs with it (but that itself might be a bug?)
16:58:09
cage_
sometimes i got the repl unusable, i mean the input is blocked but i think this was related to ffi
17:55:52
AeroNotix
trafaret1: however, there is an emacs spreadsheet-mode. You might find that useful
18:17:40
mfiano
Xach: Myself and a few others have tested the no-finalizers branch for a week after posting about it on Reddit, and given no warnings or errors by multiple people, it was merged yesterday
18:18:10
mfiano
If you can provide a test case I can look into it, but it does work for the others that have tried so far