freenode/#lisp - IRC Chatlog
Search
14:45:58
dim
_death: not so much no, https://github.com/dimitri/AdventOfCode/blob/master/2018/d05.lisp
14:46:19
dim
just saying the main parameter is a string, but then nothing else, neither in the flets nor in the loops
14:49:57
jmercouris
I think CCL is a monumental task for RME to go at it alone, I look at the commit history, and he seems to be far and above the most active
14:52:19
_death
dim: I think when ccl is helped with declarations it can generate OK code.. anyway, for day 5 I created a screencast https://adeht.org/casts/aoc2018.html
14:54:26
dim
I found day5 quite difficult, I think I attacked it the wrong way and then my mental model was kind of stuck
14:56:25
_death
interesting.. to me it immediately screamed "string rewriting", even before reading the problem, so I found it a bit boring
14:57:25
dim
my first approach didn't resist to the string beginning with a reaction (e.g. Aa), and then it was busted and I needed something else, from scratch
15:02:35
_death
here's a gist with minor cosmetic changes https://gist.github.com/death/e0e216ca41eee99da609f01c64d2725a
15:10:01
_death
I am not talking about tail call optimization, but about the process described by the code
15:11:21
_death
https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-11.html#%_sec_1.2.1
15:14:15
Odin-
Fair enough, but in practice you can only make that distinction if you have tail call optimisation.
15:16:21
_death
the process is iterative, and what the compiler decides to do with its description is an implementation detail, which in practice matters of course
15:16:28
dim
_death: https://github.com/dimitri/AdventOfCode/commit/99cb79a5414f3f249d3b22ec83e0d172dd5c6b4e
15:17:07
dim
with char-equal and a very small code clean-up now CCL and SBCL are about on-par, 1414.644ms became 100.259ms; thanks!
15:18:47
dim
_death: I see what you mean yeah, but I refrained myself for doing it that way and I don't know why really, I like recursive definition for their simplicity usually, not today though…
15:20:00
alandipert
_death I'll check out your screencast! I haven't done it 2 yet, have this so far https://github.com/alandipert/advent-of-code-2018/blob/master/day05.lisp
15:24:03
Odin-
_death: If we get right down to it, the only reason you ever need to use iterative processes is an implementation detail. :)
15:24:46
Odin-
(That is, the fact that any actual implementation is going to have a finite limit on call stack depth.)
15:26:10
_death
Odin: what is meant is that the process, by its "nature", is iterative.. i.e. without any relation to computers or compilers, just logic
15:27:56
_death
Odin: and Guy Steele in one of his lambda papers, flipped the situation with regards to implementation techniques and showed that the "stack" can be artificial
15:36:00
heisig
Damn, you guys lured me into this advent of code thing. Well, here is my take on it: https://github.com/marcoheisig/adventofcode
15:37:21
Odin-
_death: Algorithmic analysis is one way of looking at it. Looking at it from the implementation is another.
15:38:38
Odin-
_death: I'll concede that saying "no, it's not" wasn't justified, but at the same time it's not _wrong_. :p
15:40:56
Odin-
Because the implementation is recursive and leaves it to the compiler to recognise that the underlying process is iterative.
15:42:14
Odin-
If it doesn't, the process that actually gets run _is_ recursive, with significant practical consequences.
15:53:04
jkordani_
_death: its funny this topic came up. I'm going through sicp right now and last night I finally understood what they were saying about iterative v recursive
15:54:48
jkordani_
I was confused because the iterative examples look recursive to me, if I go by my old definition which was "the function calls itself" but I see now that that's an incomplete model to describe the behavior
15:57:54
Odin-
And tail call optimisation makes the code behave different from what it looks like it should. :p
15:58:36
_death
if you understand this, then the semantic arguments about appropriate terms etc. are unimportant..
16:44:58
_death
doesn't look too bad.. as for the margin, maybe it's best to ignore that rule for now, so that you indent things in a way that makes the code shape familiar
16:47:19
elderK
_death: Thanks for taking a look. I appreciate it. Aye, I'm aware of the "familiar" shape. But... the margin.
16:47:40
elderK
What I want to do, is break this out into multiple files. One that deals with the slot stuff, one that deals with the structure stuff.
16:47:52
elderK
But of course, some of the slot stuff needs to access the structure, and vice versa.
16:48:39
elderK
I have learned, however, that storing the offset for the slots doesn't really buy me much.
16:49:38
elderK
:( I've been at this for about twelve hours. I should take a break, ponder more. But at the same time, I'm determined to get something decent. At least /some/ progress.
16:50:44
_death
elderK: in make-array-initform you should likely use `(vector ,@(loop repeat count collect initform)) for initial contents.. which also does away with double backquotes
16:53:30
_death
elderK: indeed, so putting the function call form in a vector literal is wrong.. and also, you need to decide whether to evaluate it multiple times (as it is right now) or once (say, using once-only)
16:53:55
elderK
_death: Good point about the literal. But it's intended to evaluate the initform multiple times.
16:56:15
elderK
_death: Is it bad form for a file to use a function that's defined in another file, if that other file is compiled / loaded after the first?
16:56:26
elderK
Or is it best to declaim something in that case, to let the compiler know that ahead of time?
16:57:01
elderK
It's crazy. I can deal with much larger files in other languages. But, Lisp... it is so much more dense, if that makes any sense.
17:00:14
Odin-
Lisp and assembly sometimes seem to have similar requirements for exactly the opposite reasons.
17:01:15
Odin-
Assembly because it's doing things at such a low level that you need to see a lot of it to understand what the hell is going on, and Lisp because it's doing things at such a high level ... that you need to see a lot of it to understand what the hell is going on.
17:09:35
_death
elderK: well, it's not too big yet.. with practice you'll find it easier deal with chunks like that
17:33:51
elderK
_death: Another problem is that, atm, I haven't really developed an intuition for what *is* horrible.
17:37:25
_death
but did you read the Tutorial on Good Lisp Programming Style ( http://norvig.com/luv-slides.ps ) ?
17:39:00
pfdietz
elderK: the use-before-def of functions is interesting if it's a generic function. There, the idea is to put the defgeneric forms early, sort of like the declaration of function signatures in C go in .h files. The actual methods can be all over the place.
19:36:09
elderK
Like, one that checks all the provided keyword args are of the correct type. Then forwards them all?
19:36:47
elderK
(Generating a bunch of keyword parameters with suitable defaults, checking them /all/ always, and then calling the "real" constructor)
19:38:48
elderK
Well, it seems like it is excess work. Like, if the keyword args default, I know they are avlid.
19:39:54
elderK
It would be interesting to see how implementations implement the constructors for like, structures.
19:41:55
elderK
_death: Basically, if all the structure's slots are say, A, B and C. I generate a gigantic list of keyword parameters, (A initform) (B initform), etc. I also generate a giant list of (check-type A type), etc.
19:50:56
zhlyg
Does this CPS vs SSA comparison holds true today http://mlton.org/pipermail/mlton/2003-January/023054.html
19:53:58
dim
zhlyg: no idea, but I like the work on Andy Wingo on this topic, at https://www.wingolog.org among other things
19:57:56
elderK
_death: This is what I have now. I'm feeling a bit happier about it's shape now. https://pastebin.com/1YeL8zC1
20:07:26
elderK
_death: There's still stuff to do, like writing make-load-forms and stuff. And a bit of rearranging, too.
20:16:10
anamorphic
In my project I have a bunch of static files I need at runtime. I have them all referenced in ASDF e.g ((:static-file "foo") (:static-file "bar"...), but it's starting to get a bit unwieldy. They're all in the one path though -- Is there a way to just specific, "all the files in this path" somehow?
20:22:47
_death
elderK: yep.. it's a good idea to replace #<%structure ...> in the expansion with the form to create that instance
20:24:40
elderK
I'd like to evaluate the "literal" only once, but I'm not sure how to do that when I've got the eval-whne as it is.
20:26:01
elderK
Right - but then how would you handle redefinitions? You'd have to be able to differentiate between "This was defined in the compile, now we're loading" and "We're redefining the entire thing"
20:26:07
_death
could have a FIND-BINARY-STRUCTURE and a (SETF FIND-BINARY-STRUCTURE), like FIND-CLASS and (SETF FIND-CLASS)...
20:27:02
elderK
It's used to associate type metadata with a symbol in general - for any "binary type." Not just structures.
20:35:09
elderK
Aye. You're right. Given defstruct's semantics, if you redefine it, you really should reload the system, rihgt?
20:37:21
buffergn0me
zhlyg: That CPS vs SSA comparison still has some valid points (IDK of any recent work on common subexpression elimination, which seems to be a sore point), but there is recent work to show you can do things with CPS that don't have SSA equivalents yet: https://smartech.gatech.edu/bitstream/handle/1853/16289/might_matthew_b_200708_phd.pdf https://dimvar.github.io/ (CFA2)
20:37:27
_death
in some implementations it's ok to redefine, if you also recompile code using the access functions and such
20:51:50
elderK
I imagine it is the same if you like, redefine deftypes and stuff you've used elsewhere. Obviously, if you have check-types and stuff using them, compiled into functions, you'd need to redefine them I guess.
20:56:50
_death
elderK: kind of a broad question.. I wrote things like that years ago after I read PCL, and I tried different approaches when I needed to do "binary parsing", but I did not need to create anything like that in recent years..
20:58:24
elderK
_death: Broad indeed. I basically want to use CL for the stuff I'd normally use C for. That is why I need something like this.
20:58:43
elderK
And, while I could use say, frodef's binary-types or... a few others, I thought building my own would be a good learning experience.
20:58:59
elderK
I get the feeling though that I simply need to let go of any... desire for "static typingness" :P
20:59:17
_death
elderK: there are many libraries to do that, and other languages also have features of interest (e.g., I remember erlang's bit pattern syntax was neat, or some python library that used similar syntax to define packet structure), but I guess you already checked them out.. so if you're writing it to fix issues with other people's libraries you should already have a good idea of what you want
21:00:04
elderK
_death: I haven't looked into how other languages like Python deal with this. But, I have spent quite a bit of time studying various "binary parsing libraries" on Cliki, and Github.
21:00:46
elderK
Of course, it's not a once-off "skim the code", I refer to them often, over and over, as I encounter new things or want to double-check something
21:01:29
dim
elderK: you'll find very good inspiration in Erlang binary syntax (with pattern matching) for binary, really
21:01:40
_death
elderK: well python had that struct thingy.. which I tried some years ago https://github.com/death/constantia/blob/master/struct.lisp but I'm thinking about some specific library whose name I don't remember.. at the time I thought it was cute
21:02:47
_death
elderK: sometimes it's easy to just use nibbles or simple stuff like with-binary-readers in https://github.com/death/dbus/blob/master/utils.lisp
21:04:11
_death
elderK: nowadays the things I write are aimed at concrete problems, so I don't have any grand designs for such a library..
21:04:53
elderK
:( I feel that my ambitions here are pretty modest, really. I'm not trying to create anything overly advanced. Just, useful for my purposes.
21:05:57
_death
elderK: the define-binary-class -like stuff I wrote were proprietary (it was 10 years ago or so) so can't give a link.. but they were similar to the PCL stuff, I guess
21:08:06
elderK
:P I will have type checks and stuff where it makes sense. But trying to force Lisp to be a statically typed langauge is frankly a waste of time.
21:08:37
elderK
If someone like, populates a "binary structure" with garbage and tries to serialize it, it'll fail - but they might write some bogus stuff in the process.
21:09:05
elderK
Mostly, it'll be fine. But I mean, it's not transactional. STuff that is valid, will be written and then FAIL! Something isn't the right type.
21:09:49
elderK
_death: Thank you so much for your help over the past few hours. I really, really appreciate it.
21:10:13
_death
me, I'm very inconsistent with style and documentation for my personal projects, and I don't mind other people's undocumented lisp code (I like code), so I'm a preacher giving advice ;)
21:10:46
elderK
_death: Well, as you can see, I've docstring documented some stuff. But, I intend to tear that out and do better, nicer docstrings "out of line."
21:11:05
elderK
And of course, eventually, I'll write a README that covers the basics of how to use it, examples, etc.
21:15:36
_death
yeah.. I don't think there's one way to do things, but when that approach works it's pretty cool
21:17:35
elderK
Perhaps one of these days I'll rewrite it all using the MOP, as shka_ originally suggested.
23:34:04
elderK
ebrasca: I've finally made some progress with my "binary" library. There are a few more things to add support for, and a few other "chores" I want to do. But, it should be ready for "alpha use" very soon :)
23:35:02
elderK
I'll try using it for some actual stuff, though. Dog-food it :) Fix / refine it as necessary.
23:37:05
permagreen
I'd like to say my name is often displayed as green in chat clients, for whatever reason, but really I think people are just more prone to point it out to me when it is