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.