freenode/#lisp - IRC Chatlog
Search
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
19:23:27
Xach
mfiano: thanks. what does http://report.quicklisp.org/2018-09-11/failure-report/sketch.html#sketch mean?
19:37:37
mfiano
Xach: it means cl-sdl2-imagr has an error in that it assumes trivial-garbagr is available instead of more correctly depending on it
19:54:41
borodust
what if i want to reexport only some symbols from a certain package, what solutions do I have except for :import-from those symbols and then :export manually later?
19:55:27
Xach
borodust: what do you mean by "manually later"? you can do it in the same defpackage form.
19:57:51
johnjay
and i thought, well do you have to really use a system a lot to clone it or is it kind of irrelevant
19:58:00
borodust
Xach: i'm just asking if anyone has a solution for that :p i know it's just a macro away
19:58:00
johnjay
like, you don't have to use a tractor to repair the engine, you know what im' saying?
19:58:23
pjb
borodust: if copy-and-paste of the list of symbol names seems untasty for you, you can always use #1=(…) and #1# in the defpackage form!
20:00:30
johnjay
"Many design choices of Climacs are based more on the editor of the Genera operating system, Zmacs, and the other original Lisp emacsen, such as Hemlock, than on GNU Emacs. "
20:02:19
beach
johnjay: And I know very little about Zmacs, so I would be surprised if I wrote that too.
20:04:42
johnjay
the funny thing is i'm trying to figure out how to download and install it. the INSTALL file says we assume you have already obtained the tar or cvs sources
20:09:21
beach
Once we had McCLIM working, I challenged the community. "So now that we have McCLIM, it could not be too hard to write an Emacs clone, now could it".
20:10:29
johnjay
hrm, got an error when getting mcclim compiled. RENDER-SET-IMAGE-TRANSFORM is not external in the XLIB package
20:15:32
beach
I have used McCLIM with very old SBCL versions, and in fact a recent SBCL commit broke McCLIM as I recall slyrus said.
20:20:48
beach
johnjay: It is clear from the way you refer to jackdaniel, that you have not been attending ELS regularly.
20:22:08
johnjay
beach: i'm just a lowly novice, indeed. elisp and scheme are where i first encountered lisp
20:24:39
beach
johnjay: You will have tons of new friends that you can visit, or that might come visit you. You might be invited to dinner during ELS. etc.
20:25:49
beach
johnjay: I have no idea what 34c3 might be. ELS is very informal, though it *is* an academic conference, so the papers are peer reviewed.
20:25:49
johnjay
ah this must be the videos from 2 years ago: https://www.youtube.com/channel/UC55S8D_44ge2cV10aQmxNVQ/videos
20:27:37
johnjay
beach: c3 is a popular hacker conference that happened this year, it's sort of like defcon in the US but it's in germany
20:30:11
beach
ELS is about Lisp, and it is a peer-reviewed conference with respect to scientific contents.
20:34:03
beach
The important piece of information (that surprises people who are not used to it) is that a conference is not mainly for authors to present papers to people in the audience, but for people to meet other people.
20:35:52
beach
Most people in the audience of my talk were perhaps thinking "yawn, why the hell is he re-implementing LOOP? But he's a cool guy. I'll try to sit at his table during the conference dinner. I know he will pay the bill."
20:38:13
beach
ELS is a mixture of people with solid employment and people in flux, like students. In fact ELS has a very good student rate.
20:39:53
beach
j`ey: So if you are a person i flux and you find yourself at a table with people like me, Xof, splittist, etc., it is likely that you will be offered a large part of your share of the bill.
20:41:14
j`ey
unless ELS was in the UK, and stylewarning was there, I'm not into CL enough yet to go :P
20:46:32
beach
I am definitely going to contribute to froggey. I don't know you well enough to decide yet.
20:48:36
makomo
j`ey: i've been complaining about the videos for some time now. :-) i've emailed didier verna about it, but it turns out he's the wrong person to ask. he did tell me he would try and put some pressure on the people in charge of the videos though
20:48:52
makomo
j`ey: i was thinking of mailing Ravenpack (as suggested by beach) soon -- didn't get around to it yet.
20:49:45
makomo
oh, to be clear, i've only emailed him once. i meant that i complained to #lisp about it :-D
20:50:28
beach
Every conference has a "person totally in charge", a "program chair" and a "local chair".
20:53:00
makomo
beach: mhm. it wasn't very clear to me what their roles are and what the relationship between 1 and 3 is
20:55:08
makomo
ah, i see. and the other companies listed on the webpage help out by sponsoring the local organizer then?
20:56:09
beach
The student free is so low it often does not even cover the cost of the meals included.
20:58:15
AeroNotix
hmm, very interesting. Just realised that ELS lines up perfectly next year with my intended cross-Balkans drive
21:00:12
housel
johnjay: See, for instance, http://blog.quicklisp.org/2018/08/new-projects-cari3s-generator-for-i3.html
21:00:24
AeroNotix
I need to get my health in order before I take any on any tasks that people would depend on me for
21:01:09
AeroNotix
johnjay: not sure if github still expose that feature where you can filter projects by language and age of commit
21:01:46
beach
makomo: For instance, Martin Simmons is a sponsor of ELS, a regular attendant, a nice guy to have dinner with, etc.
21:03:00
johnjay
the latest 4 minutes ago is rakugobot/shibuyarakugo-parser, a html parser for eurolive.jp
21:06:31
AeroNotix
https://github.com/search?l=&q=language%3A%22Common+Lisp%22&type=Issues haha, could be a useful thing to just spend a few hours hammering through issues here
21:10:48
makomo
beach: it's really nice how a community "feels" different depending on its size. since the lisp community is relatively small, you feel a greater sense of "connectedness" i would say. on the other hand, having a big community has its ups too, like having a bigger ecosystem or similar
21:22:30
AeroNotix
I've come to appreciate :package-inferred-system and every-file-is-a-system organization
21:25:35
Xach
no-defun-allowed: there is one every day in #lisp where distance is no object (although time can be)
21:25:50
no-defun-allowed
*Australia. The closest thing is a "functional programmer meetup" and it's probably just Haskell people jerking each other off and they haven't done anything regular for a year.
21:26:47
johnjay
no-defun-allowed: that sounds like the least attrative haskell meetup i can think of
21:27:48
no-defun-allowed
"Listen to some people talk about type theory" haha yes, that's all FP is. Fuck outta here with first class functions and other stuff, it's all types
21:29:19
no-defun-allowed
Anyways, Lisp isn't fp, blah blah, there's no meetups. There's no meetups in general around here.
21:31:57
aeth
The most important part of Common Lisp depends on what you're doing, and that's the point of Common Lisp imo.
21:32:00
no-defun-allowed
<freenode_aet "#'no-defun-allowed: Common Lisp "> Of course type inference is always good but it's probably a bad idea to bring Lisp in if everyone is talking types.
21:32:40
no-defun-allowed
Once I went into #haskell asking about how to write an article on functional programming and I was attacked for not knowing any Haskell and only Scheme. That wasn't very nice.
21:33:15
no-defun-allowed
Of course type inference is always good but it's probably a bad idea to bring Lisp in if everyone is talking types.
21:35:29
no-defun-allowed
Yes, then ML weirdos use type to prove their programs will run and so forth.
21:36:06
aeth
CL probably has the richest type system of any dynamically typed language and is probably one of the first to support optional gradual typing. The main weakness with respect to types is probably non-generic data structures.
21:36:35
aeth
You could use the type system in CL to do most of what the ML-derived languages do as far as using types for reliability.
21:37:51
aeth
I'd say the main problem is that half of that will only work on SBCL and about 0% of it will work on CLISP (okay, check-type probably works there), with the other implementations somewhere between CLISP and SBCL.
21:38:23
aeth
no-defun-allowed: Yes, the CL type system is superior. For one, you don't need a graduate degree in mathematics.
21:39:01
aeth
And attacking Haskell in particular, CL isn't lazy and doesn't demand immutability in most areas.
21:39:15
no-defun-allowed
(If the Haskell people realise they didn't need their PhDs to write functional programs, they'd be very upset.)
21:41:42
aeth
There are probably places where modern ML-like/Haskell-like languages can do more things with types than CL. I'd like to know those so CL's type system can be extended.
21:41:47
no-defun-allowed
Someone said I should start one then, but I don't know anyone who would go and I've got no money
21:42:06
aeth
The CL way to handle a new paradigm is to glue it to the existing Lisp language and pretend like it was there the whole time.
21:43:02
aeth
If ML-like/Haskell-like languages have something to offer as far as type systems go (and they almost certainly do), extend Lisp and keep the 60 year old tradition going. It worked with OOP.
21:43:57
aeth
(I'm not proposing a new standard. CLOS started out as several non-standard extensions to CL, not as part of the standard. It would probably take 5-10 years for it to be worthy of being standard.)
22:23:34
no-defun-allowed
frankly though, if you force your users to specify variable types without a good reason (it's absolutely not inferable, multiple dispatch exists in your lang) and you're doing static typing nowadays, you did something wrong
22:25:00
aeth
I don't think it's controversial that some languages are hard to learn than others. (Devil's advocate: You only have to learn a language once.)
22:25:31
AeroNotix
aeth: I wasn't being controversial. I was just throwing it out there as a jumping off point
22:26:38
aeth
johnjay: You'll find many name conflicts even with 'aeth'. I like that because in today's world if you use a unique name you'll find far too much too quickly.
22:27:00
AeroNotix
talking about name conflicts, to tag aeth it usually takes me 3-4 times not to tab complete to my self
22:27:08
pjb
aeth: that's wrong. you have to learn some languages each time you use them. For example C++.
22:29:58
aeth
AeroNotix: C++ is a language that's hard to *use*. One could argue that Haskell is a language that's hard to *learn*. But this is getting very off-topic.
22:30:15
AeroNotix
well it ties into the fact that CL is relatively easy to learn and easy to remember
22:30:52
AeroNotix
it all logically seems to fit together, designed flowing together as a cohesive unit
22:31:18
aeth
AeroNotix: There are probably lots of corners of CL that you don't know that you don't know.
22:32:30
AeroNotix
aeth: indeed, I'm absolutely sure of it. The metaobject protocol is something I've literally never used, ever, or even looked into.
22:32:45
aeth
Switching syntaxes quickly is the source of bugs even if you *know* all of the syntaxes thoroughly
22:33:51
johnjay
oh ok. i thought the idea of that post was that scott was just getting old and couldn't concentrate
22:35:05
aeth
I'd say the main problem with C++ is syntax inherited from C. For instance, pointers. People have trouble "learning pointers". Pointers aren't hard to understand if you can understand arrays (imo). C *syntax* for pointers is hard.
22:35:55
AeroNotix
johnjay: his immediate problem is that he has lost interest but the bigger problem is that, despite being a world renowned C++ expert for years (really, his books are great) he cannot easily read C++ and understand immediately what it does.
22:39:31
aeth
AeroNotix: REPL oriented languages like CL seem superior for this sort of thing in general, though. If I want to figure something out in C or C++ or Java, I have to write a skeleton file with all of the necessary boilerplate to get it working. In CL, it usually (but not always) can be done in the REPL.
22:41:05
aeth
(REPLs exist for all of those languages, but it's not going to help for several reasons. One, the language isn't really designed for REPL usage. Two, those are almost always interpreters that might behave differently in strange corner cases. In SBCL, the REPL just compiles it for you.)
22:43:21
aeth
What's great about SBCL is that I can disassemble it and see the generated, commented assembly! (DISASSEMBLE isn't guaranteed to work, and only SBCL comments it afaik.)
22:44:25
aeth
If there are two ways to write something, I sometimes write a foo and a bar with each approach, disassemble them, and see if there's a difference or not.
22:46:25
aeth
Is there a way to disassemble a method? I assume that it's a lambda stored with into an object created by defgeneric, or something close to that.
22:47:02
aeth
I think I've managed to get to the asm via the SLIME inspector before, but that's not ideal.
22:50:03
AeroNotix
When disassemble outputs the addresses of functions/constants, can I use those addresses somewhere to access the object via the pointer rather than the symbol? Always wondered this
22:50:55
aeth
AeroNotix: I don't think you can assume that addresses stay constant because of the GC unless it's an object intended for CFFI, in which case it will probably be at a fixed location to prevent problems on the C side.
22:51:45
aeth
(Although recompiling functions for that probably would be noticable so it probably doesn't happen.)
22:51:48
AeroNotix
If it's comparing constants, I'd assume it could keep those around in specific places
22:52:41
Bike
keywords aren't usually accessed from foreign code, so there's no big reason to specially keep them pinned
22:53:12
aeth
Bike: How do symbols generally work? It's intentionally unspecified, but I wouldn't be surprised if there's a general implementation strategy.
22:54:27
aeth
In my head I sort of treat symbols like global enums. So 'foo is really 'my-package::foo which is really 3456673 or something. And I assume that's resolved at compile time if possible (so (whatever :foo) is really working with a fixnum which I cannot directly access)
22:55:23
White_Flame
or at least, a slot "holding" a symbol should be indistinguishable from "holding" any boxed object
22:55:53
White_Flame
the only special handling that constrains symbols is the symbol-cons equivalence of NIL
22:56:05
aeth
White_Flame: so it's just a pointer to an address and usually the address is all that matters because you're mostly using it for EQ?
22:56:06
AeroNotix
aeth: strangely that's kind of how atoms work in Erlang (which keywords are analogous to)
22:56:34
Bike
aeth: occasionally the data in the pointer, such as pointers to the symbol-name, is useful
22:57:33
White_Flame
but it's usually a pointer to an object, not necessarily a pointer to an address
22:58:01
White_Flame
or are you asking about symbol-value bindings and how those are looked up, rather than the symbol object itself?
23:13:50
jasom
aeth: The way they are usually implemented is that :foo will be resolved to a pointer, but every time you have :foo appear in your code it gets resolved to the *same* pointer, so you can compare just by checking if the pointers are equal (no need to dereference them).
23:15:04
White_Flame
and if GC moves the :FOO symbol object on the heap, all pointers referring to it will be updated during stop-the-world
23:15:07
jasom
Bike: there are reasons to resolve symbols to an index in a table rather than a pointer, and it involves moving GC and hash-tables.
23:16:58
White_Flame
are the issues with symbols + GC + hashtables any different than normal objects + GC + hashtables? Presuambly you're talking about EQ hashtables
23:19:35
jasom
an eql hashtable that isn't indexed by a symbol or a number would be rare (maybe character?)
23:21:31
White_Flame
composite + interning -> eql hash table; composite -> equalp hash table I guess
23:22:44
jasom
right, and symbols are the most commonly interned object, so it might make sense to optimize the case of symbol hash tables.
23:23:25
White_Flame
maybe "interning" might be the wrong word here, but given (1 30 :foo), canonicalizing that to a specific EQ-able instance of that list, using that as a key
23:23:28
jasom
if you hash other composite objects like an equalp hash table, then your implementation is still correct, and you don't need to do any rehashing on GC
23:24:26
White_Flame
the one weakness I often hit is the lack of a caching structure for the hash of a composite
23:25:42
White_Flame
so all of this drives me towards implementing my own application-specific key & hashtable implementations :-P
0:08:54
cobax
Why is Lisp image-based? Why did it start this trend? What was this feature trying to solve?
0:14:19
aeth
cobax: Faster development time. There are other ways, but they came much later afaik. And most involve an IDE.
0:16:28
jasom
cobax: once you have a dynamic environment and automatic memory management, the idea kind of falls out naturally; I'm not sure if smalltalk or lisp did it first.
0:21:24
cobax
from stack overflow I found this bit, and I wonder if this was part of the motivation:
0:21:26
cobax
"There were at one time Prolog systems that saved "working memory" as disk images. It used to be common practice, especially when the OS system calls didn't do a good job with compression and memory-management of special data structures, which is why LISP and Smalltalk did it too."