freenode/lisp - IRC Chatlog
Search
20:52:17
krwq
Bike: so i.e. if you got a list of something which has a form let's say: ((:name "a" :foo "bar") (:name "b" :foo "asd")) - what's the best way to i.e. find something with name x (if doesn't exist then create and add new one) and modify field :foo into y
20:52:51
krwq
i wrote function which does that but i think i slightly overcomplicated as the code seems to be too long for such simple thing
20:54:33
Bike
(defstruct thing name foo), then (let ((result (find "x" list-of-things :key #'thing-name :test #'string=))) (if result (setf (thing-foo result) "y") (push (make-thing :name "x" :foo "y") list-of-things)))
20:55:45
afidegnum
hello, i m reading about clack, lack and woot web but there is no deep down documentation. anyone ever used them?
20:56:32
Bike
geez, given how much trouble i've had with git submodules i don't know if i can even say much
20:56:36
krwq
Bike: i'd rather keep it as a lisp tree as it is more flexible and i do not want to define all structs since i dont know them
20:58:57
krwq
if there exists a folder on my disk which is not a local repo it should automatically create a repo, and check if on my github account there is a repo with such name
21:01:13
Bike
I don't think I understand the problem very well, but the most basic thing is to avoid using list manipulation functions directly.
21:01:30
krwq
also each of this repos should be detected if it is lisp repo and if it is it should update .gitignore file if it isn't properly set
21:01:59
Bike
like, if you stick with your list-of-plists, you should have (git-name plist) rather than (getf plist :name). then you can swap the underlying representation more easily later.
21:06:45
krwq
i never know if i should use (with-slots) everywhere or rather prefer some accessors or maybe some other way
21:08:49
aeth
classes = general stuff; structs = if you know the types, and the types will never change, and you want/need them to be fast; arrays = use them like structs the numbers are all the same non-bignum type and you are okay with numerical indices (most implementations will support most arrays of non-bignums and the rest will just treat them as regular arrays)
21:08:49
krwq
Bike: i do not care about it when i represent program in form of code. after im finished and stuff is slow i wonder how can i not change the logic and still make everything fast - then i update my tooling
21:09:24
Bike
yeah, that's the basics, like i said you use accessor functions instead of getf or whatever directly. and don't worry about performance while you're putting it together.
21:09:36
aeth
and then of course there are simple vectors (that hold everything) and lists and strings, but those are fairly obvious in use cases.
21:10:13
Bike
one thing i do is just start writing out high level functions in terms of a nonexistent lower layer, and then i write the lower layer to fit whatever was convenient above.
21:10:29
krwq
compiler should figure out if it should use conses behind or plain continous block of memory
21:11:02
aeth
The tricky, non-obvious stuff in CL are hash-table vs. plist vs. alist and also... set representations. The built-in way to represent sets as lists is... not great. Probably the worst way of doing sets.
21:11:39
Bike
doesn't matter if it's nearly impossible, you know? that's the kind of decision a human programmer could go back and forth on for various subtle reasons, a stupid computer has no chance
21:11:46
aeth
Oh! Also, CL has two built-in ways to do stacks (via vectors and lists), but if you wanted to do queues via either, you'd have to put in some work, too. (Or use a library.)
21:12:58
aeth
For the most part, CL's sequences, plists, alists, and hash-tables are sufficient. As I said, there are at least two built-in ways to do stacks. It's just (for the most part) queues and sets that are missing (unless you want sets-as-lists, which you shouldn't except for very tiny sets)
21:13:02
krwq
you have maybe few choices - optimizer could try each possible data structure and check which one works best
21:13:57
Bike
mm, there have been compilers that tried to do such things since fortran. hasn't really been that popular.
21:15:04
Bike
the thing is that it takes an enormous amount of effort from the compiler programmer, a pretty big amount of effort from the compiler, and in the end it's probably still slower than if a human spent five minutes guessing. diminishing returns and all
21:15:27
aeth
krwq: It would be much, much better just to have a generic interface on top of indexable data structures (sequences and n-dimensional arrays where n =/= 1 and hash-tables and plists and alists, etc.) and then it would be easy for you to refactor the code later if your needs change.
21:16:22
krwq
aeth: if this is the simplest implementation - i do not care if i use generics function or a macro as it will do its job
21:16:46
aeth
I think the issue is that there's no way to add this to CL portably afaik without a performance cost.
21:17:00
aeth
And the people who care about switching data structures to avoid performance issues will want to avoid that, too.
21:17:54
krwq
you could make it so that you run the program for a minute it will pick best settings and compile itself permanently wuith it
21:18:59
Bike
ah, if you're intested though you should help me with compiler dev in your spare time. i don't mind sky pies.
21:20:05
krwq
i do want to do the git stuff, i have some pieces written already but there is plenty of work left
21:20:58
krwq
i will scope myself to what i need i gues but will try to keep logical order in case i will plan to finish the whole thing one day
21:31:13
jfe
i know this isn't #emacs, but has anyone seen the following error when launching SLIME?: READ error during COMPILE-FILE: The symbol "HOST-ENT-ADDRESS-TYPE" is not external in the SB-BSD-SOCKETS package.
21:32:50
Bike
http://stackoverflow.com/questions/42760607/slime-he-symbol-host-ent-address-type-is-not-external-in-the-sb-bsd-sockets-p and you're not alone (unless this is you)
22:05:47
aeth
Clearly, the solution is to make integers sequences and get rid of bit-vectors altogether.
22:07:15
pjb
Why do you say that? Bit-vectors are very nice. Also, there are bit arrays for those nice bitmap display and graphics.
23:04:25
aeth
Xach: that's why I did this: https://gitlab.com/zombie-raptor/zombie-raptor/blob/027c20ae395cede0443f58372890264fd3a2750a/math/boolean-set.lisp
23:04:49
aeth
Now, I'm not doing cryptic logical operations on integers. Instead, I'm doing set operations on something I called a "boolean set"
23:06:32
aeth
I actually caught iirc two logic errors by moving to set theory because it became very clear exactly what I was trying to do.
23:08:36
aeth
Also, I found that I was using subset a lot of the time when I could also just be checking for membership.
23:10:32
aeth
I could probably add two more variations, one that operates on &rest instead of two items, and one that doesn't have an upper size limit but is potentially less efficient.
3:57:36
nyef
Heh. Well, I managed to use the MacIvory for a bit, mostly looking at the document explorer, but also using the lisp listener to evaluate such classic forms as (+ 3 4) and (disassemble #'+).
4:21:09
beach
For Common Lisp mode of Second Climacs, I use the reader from SICL to parse the buffer contents. But SICL is big and not ready for general use, and only a small part of it is needed for Second Climacs. I could include the reader in Second Climacs, but then I would have code duplication. Or I could extract the reader from SICL into a separate repository and have Second Climacs depend on that repository. Any advice?
4:22:46
nyef
How important is it that Second Climacs be usable by other people outside of the context of SICL?
4:26:10
beach
But it will depend on the SICL reader and on some parts of Cleavir (which is still part of SICL) for the Common Lisp code analyzer.
4:27:43
beach
I still plan to extract Cleavir from SICL, because Cleavir is more generally useful in other implementations.
4:28:17
nyef
Ah, better question: How important is it that the Common Lisp mode for Second Climacs be usable outside of the context of SICL?
4:31:36
beach
Maybe I'll start by extracting the reader into a separate repository. It could be useful as an independent module.
4:32:17
nyef
What about "just" having a way to package only the reader as a separate distributable thing, but leaving it in the SICL repository?
4:34:09
nyef
Well, if they're pulling from source control, they'll need to pull all of SICL, but if they're just working from distribution archives, then you'd provide a just-the-sicl-reader archive that they could install somehow?
4:34:10
beach
Bike: The other day, I hinted at a feature where one could hold the mouse over a lexical variable and have potential definition points (LET bindings or assignments) be highlighted.
4:37:17
beach
I guess that initially I can just ask that people clone SICL, but then only use the reader. Ultimately, I might do something different, but since Second Climacs is not going to be finished in the near future, I can always thing about it later.
4:38:59
beach
Bike: I think it would be cute to include such functionality in Second Climacs. It would be unique in editors for Common Lisp as far as I can tell.
4:40:34
beach
True. I have the source info in Second Climacs already. I just need to pair it up with AST and HIR generation.
4:41:05
beach
The "parse result" of Second Climacs is very similar to the CST (Concrete Syntax Tree) that I started implementing in Cleavir.
4:41:56
beach
And I would like for Cleavir to use CST as input. If only S-expressions are provided, it is easy to generate CST from it (but it will have no source information).
4:44:51
beach
The Second Climacs "parse result" included stuff like comments and other things for which the reader macro returns no values. But I can include that in the definition of CST even if the default reader does not provide it.
4:47:58
beach
Bike: The reason I have not worked on an implementation-independent lambda-list parser for Cleavir is that I really want source code manipulation to work on CSTs, and that's a big change to make. Oh well, so much work, so little time.
4:51:17
beach
One cute thing I implemented for CSTs (but it has probably bitrotted by now) was "intelligent macroexpand" whereby a CST would be re-created from an initial CST and the macro expansion of its associated S-expression (as accurately as possible). That way, source information would be preserved around macro expansion.
4:54:38
Bike
for the DX analysis i had it just warn along the lines of "there's a bad dynamic-extent declaration somewhere"
4:55:42
beach
So, right now, the GENERATE-AST part of Cleavir has some functions that can handle both S-expressions and CSTs, but most of them still handle only S-expressions. I first thought I would do that for all functions. But now I think that I just make them handle CSTs and require an initial CST creation if all we have is an S-expression.
4:56:04
beach
That's a big change to make though, and I don't know how to do it without disturbing my client too much.
4:56:13
nyef
Ugh. That reminds me. I still need to work out the proper semantics for DX in SBCL. So far as I'm aware it's not exactly broken, but there are definite optimization opportunities that the current implementation can't take advantage of.
4:57:33
beach
Bike: Every function in the GENERATE-AST part needs to be modified so that uses (and sometimes creates) CSTs. That's the big part.
4:58:02
beach
Bike: Some of those functions could just extract the S-expression for now as long as they recognize CSTs.
4:58:34
nyef
Bike: I might have said that. I certainly said that it was a pile of hacks that nobody has ever understood completely.
5:00:14
beach
Bike: All of the code in CODE-UTILITIES need to be rewritten, or rather, a new library (say CST-UTILITIES) needs to be created. The big part is the implementation-independent lambda-list parser.
5:01:15
beach
Bike: Right now, the result of the lambda-list parser is a standard instance with a slot for each kind of parameter, but that won't do, because an implementation may introduce new lambda-list keywords, and their position in the lambda list may be important.
5:02:50
beach
So we need a lambda-list parser that preserves the order, presumably as a list of standard instances. And we need some parsing technology, probably Earley or combinator parsing so that client code can add new rules in a modular way.
5:05:24
beach
Anyway, a complete set of CST utilities would be very useful for other things as well, so it may be worth the effort.