freenode/#lisp - IRC Chatlog
Search
14:27:09
jmercouris
I'm getting "Heap exhausted during garbage collection: 0 bytes available, 16 requested."
14:29:27
jmercouris
beach: It's perfectly normal in this case, I'm loading a massive data structure into memory for distribution with my application
14:29:48
jmercouris
It is just an alpha so I don't want to go through the hassle of bundling the database with the application
14:30:04
jmercouris
Well, probably because my hash table is growing all the time, and I did not set a default size
14:31:02
shrdlu68
beach: I've gotten that as well before, didn't realize that heap exhaustion during garbage collection ought not to happen.
14:32:04
jmercouris
if I limit the size of my initial query for populating the hash table, I don't have this error
14:35:23
jmercouris
well, now my application is 300MB, and I need a --dynamic-spzie-size of 5000, but oh well
14:41:54
shrdlu68
I'm wondering whether I can use stmx in a multi-threaded program and not worry about race conditions and data corruption. Is it really that simpe?
14:42:54
shrdlu68
"Note that concurrency related bugs are still possible in programs that use a large number of transactions, especially in software implementations where the library provided by the language is unable to enforce correct use." -- from the Wiki page on transactional memory.
15:05:57
beach
I think I have memory allocator similar to that of Doug Lea, but written in Common Lisp. It has contains than 400 lines of source code. It uses a few functions for reading and writing memory that I am currently simulating. Next, I'll clean up the code, remove some magic literal numbers, add comments, etc. Later, I'll add meters to collect statistics and figure out how to write a test suite.
15:19:31
beach
I think I have a memory allocator similar to that of Doug Lea, but written in Common Lisp. It contains less than 400 lines of source code. It uses a few functions for reading and writing memory that I am currently simulating. Next, I'll clean up the code, remove some magic literal numbers, add comments, etc. Later, I'll add meters to collect statistics and I'll figure out how to write a test suite.
15:23:47
beach
Josh_2: The SICL global garbage collector will use a heap similar to that of malloc()/free() for C. One of the best memory allocators is the one written by Doug Lea. I adapted it to my needs and wrote it in Common Lisp for ultimate inclusion in SICL.
16:08:49
oni-on-ion
i wonder if i shared that quote with you that ive seen the other day, that really turned my mind from C to Lisp ?
16:11:22
dim
the recent quote I read that really took a different meaning thanks to having done Common Lisp before was from Alan Kay, and I can't find it again, so paraphrasing: “The operating system is there to provide anything that is missing in your programming language”
16:12:42
oni-on-ion
hey beach ! some info. the word 'chunk' is used 109 times in allocator.lisp, the next most-used word is 20 times. =P
16:13:28
oni-on-ion
dim: nice! also adding to that, someone said once "the unix/posix system is the C runtime" -- which is quite large eh!
16:13:36
beach
I think it is normal that "chunk" appear that often, since it is basically the only data structure it manipulates.
16:14:33
oni-on-ion
beach: im just being dyslexic or ocd , having to type and read 'chunk' each time, rather than c + M-/ or abbrevs ? however i think repetition is important in some cases. idk =)
16:15:38
oni-on-ion
beach: i cant find the quote at the moment, it was something about how you were saying that C does quite a bit of "extra" stuff and undefined behaviors, optimizations, and shortcuts and whatnot, that it is not really low level at all.
16:21:46
oni-on-ion
cant find it, it was at the top of some visited web page, no way the browser can find that by search. should have saved the quote, i may come across it some day. oh well the idea is there, and if anything C has *more* undefined behavior.
17:10:45
oni-on-ion
what is this? so im paging through this file, and i cant tell the screen even moved, four times! have we never heard of macros ? i dont know what to say. i await to hear a good reason for this. are macros poison?
17:10:51
oni-on-ion
https://github.com/robert-strandh/SICL/blob/master/Code/Character/character.lisp
17:11:29
oni-on-ion
did one not have to go out of their way and consciously copy and paste ? how does that even become a good idea?
17:12:38
_death
it's fine to do that initially.. then you feel more acquainted with the problem and may define a macro.. maybe the author stopped there.. perhaps a macro for a fixed set of operations is overkill
17:15:18
oni-on-ion
there is literally one or two characters to change on each code block. the 180 lines would be 45, much easier to maintain. maybe having more lines is a good metric to have for posterity ?
17:16:03
oni-on-ion
if it was written off-hand, casually, not used much, or just enough to work -- still, the conscious effort to copy and paste, change one single character or two, is there.
17:16:09
_death
I'm not the author but I wouldn't be surprised if "patches welcome" is an appropriate reply
17:16:59
oni-on-ion
_death: sure. let jesus take care of it. lets just give up on life and working toward goodness and trying to better ourselves? why not just lay down and sleep forever?
17:23:42
jackdaniel
sjl: I like your post[1] about macros, it is easy to understand and fun to read :-) [1] http://stevelosh.com/blog/2018/07/fun-with-macros-if-let/
17:26:31
jackdaniel
I'm bookmarking it as something to point not-that-newbies to CL who grasped functions and want to start working on macros
17:27:43
oni-on-ion
_death: that is not very nice. im not an evangelistical fanatic about turning everyhting into macros or something. did you see the link i posted? do you even code? =P
17:30:28
oni-on-ion
_death is making it a personal thing and i wasnt talking to him i was ranting at beach. could have taken it privately but i assumed there are other computer literate people here
17:31:03
jackdaniel
oni-on-ion: fyi _death usually has very decent remarks and rarely speaks without thinking through what he wanted to say
17:50:15
beach
_death is right. This is work in progress. I usually come up with a workable solution first, and then clean it up as I come up with new ideas.
17:50:18
phoe
I remember that Naggum, somewhere on the newsgroups, once posted a version of FBIND that does not use SYMBOL-MACROLET (like serapeum's FBIND does). Could anyone point me to it?
17:50:46
beach
oni-on-ion: Feel free to submit a pull request. But read the "Contributing to SICL" chapter in the specification first.
17:51:22
oni-on-ion
i am alright thank you. i feel that neither of you has understood a lick of what i said. i will just keep to myself
17:53:01
beach
oni-on-ion: Oh, I think I understood. There is lots of duplicated code that can be captured in auxiliary functions or macros.
17:53:42
phoe
beach: I think he means generating code alexandria-style. alexandria often uses Lisp code to generate DEFUNs and DEFMACROs.
17:53:59
Bike
or no, maybe this one https://www.xach.com/naggum/articles/3237542136210443@naggum.no.html
17:54:59
Bike
though it's not quite fbind since they're not actually bound in the function namespace
17:55:42
beach
phoe: I do know that I got a pull request for coding the sequence functions as macros, and it made them incomprehensible.
17:56:12
phoe
beach: that's exactly my worry - that code is compact, but it's hard for me to figure out what this thing does.
17:56:46
beach
phoe: Right. It took me years, but I came up with the right thing to do with the sequence functions.
17:59:32
Bike
you'd translate (fbind ((foo #'bar)) ...) as (flet ((foo (&rest a) (apply #'bar a))) ...) and hope inlining is really smart, yeah
18:10:43
jackdaniel
makomo: the thing is that symbol-function was part of cltl2 while fdefinition was added during ansi standarization
18:14:45
phoe
Bike: yep, but I don't really know how to apply once-only to an arbitrary number or arguments that are hidden inside a variable
18:19:27
makomo
is it even possible to use "vanilla" ONCE-ONLY here though? since you have an arbitrary number of arguments
18:22:01
makomo
but somehow not using ONCE-ONLY makes it ugly. i know it's not possible, but a ONCE-ONLY that evaluates an expression to get the list of symbols would be nice
18:24:24
makomo
phoe: that's what i tried too, but then you'll have to use EVAL to somehow get the result of that expression into the call to ONCE-ONLY
18:25:32
phoe
time to drop one frame in my yak-shaving session and go back to what I was doing previously
18:25:35
makomo
and then i guess you could define the usual ONCE-ONLY using this "evaluating ONCE-ONLY"
18:27:07
_death
there are other, worse possibilities.. (let ((expansion (copy-tree (macroexpand '(once-only ,@names ...))))) (setf (cdadwhatever expansion) ...) ...) ;)
18:27:44
mfiano
phoe: Yeah, my utility library re-exports a bit from both alexandria and serapeum instead of reinventing the wheel.
18:34:45
makomo
_death: is there a proper way to solve this problem at all? it comes up again and again
18:36:31
_death
you could come up with something like get-setf-expansion that returns parts to be used in your own expansion
18:39:28
makomo
_death: hmm, how exactly would that work? for example in the context of this problem with FBIND and ONCE-ONLY?
18:41:23
makomo
because you basically have to reinvent ONCE-ONLY every time when you macro takes an arbitrary amount of arguments
19:14:37
_death
makomo: I'm not sure the particular case fits once-only since it's not just a bunch of names but actual structure.. for example if you work with bindings you could have something like https://plaster.tymoon.eu/view/842#842
19:16:05
makomo
_death: what do you mean by "actual structure"? the way i see it, you have some expressions and you want to generate such an expansion that will bind some gensyms to the result of evaluating those expressions
19:17:03
phoe
...hm, a random question - in (lambda (&rest x) x), the value of X is immutable, correct?
19:17:22
TMA
phoe: well, the list bound by a &rest parameter has not a dynamic extent but rather an indefinite one specifically to permit (defun list (&rest list) list); it is written somewhere in the hyperspec/cltl2
19:17:27
White_Flame
phoe: in my view, an extension of identity to multiple parameterswould be (defun identity (first &rest rest) (declare (ignore rest)) first)
19:17:35
_death
makomo: the structure is ((name form) ...) which you need to parse even after once-onlying the names
19:18:30
makomo
_death: but why is that a problem? you'd parse it normally, no? isn't the main problem the fact that you have an arbitrary number of those "pairs"?
19:19:22
makomo
if there was a fixed number of them, you could destructure each one of them and give each one of them a name, and then use ONCE-ONLY on those names (since there's a finite amount of them)
19:26:00
makomo
_death: well, something like (once-only-fun exp ...), where EXP would be evaluated to get a list of symbols to use
19:27:04
TMA
White_Flame: well, other than that (and the description of PROG2 being wrong in the hyperspec) (PROG1 ...) does the same as ((lambda (a &rest b) (declare (ignore b)) a) ...)
19:27:44
White_Flame
looking at the original question, the only reason you'd use IDENTITY is if you're passing it into something that wants a function object
19:28:05
White_Flame
so presumably, any substitute that does multiple parameters would want the same
19:29:41
_death
makomo: so in the example I pasted, you pass it the specs and get back the a list of the original names as well as a bindings list
19:31:17
TMA
White_Flame: I have forgotten that PROG1 is a macro. I have implemented it as a ordinary function in my old interpreter
19:31:32
makomo
_death: right, which is basically what i want, but you still have to (1) have a "functional" version of this macro you want to use and (2) have to use the returned expansion "manually"
19:32:10
makomo
you have to reinvent ONCE-ONLY and provide a function which returns its expansion (or rather, parts of its expansion)
19:34:28
_death
makomo: with once-only, usually you don't care about the forms the names are bound to, just want to refer to their evaluation.. but here you still want to do something with the names so they can't be eliminated.. you could have a (once-only-bindings (names) bindings . body-using-names) that saves you the let*.. but doesn't seem worth it
19:35:52
loginoob
Whenever I do M-x slime I get "end of file during parsing" while loading the history. Continue? (y/n)
19:44:25
Xach
asdfghjkl: i add (setq indent-tabs-mode nil) in my mode hooks. (this is not a slime-specific thing.)
20:04:13
Xach
Are there any debian experts who might be able to privately help me through some quicklisp build-server setup issues?
20:08:11
_death
makomo: macros are just programs.. a lot of common functionality can be factored into functions, so there's nothing wrong with functions that return parts of an expansion.. you only need to separate macro definition from macro use so you don't need ugly eval-whens
20:08:46
pjb
Just remember to wrap the functions used by the macro at macroexpansion time in a (eval-when (:compile-toplevel) …).
20:09:05
pjb
(or in a different file loaded in the compilation environment (how do you load a file in the compilation environment with asdf?))
20:09:22
makomo
_death: yeah, i understand that, that's not the problem. the problem is that *you* have to write a function that returns ONCE-ONLY's expansion
20:09:35
aeth
If it's a function only usable in one macro, it should be in the same file as the macro unless it's a *very* complicated macro, like the one I use that converts s-expressions to GLSL strings at compile time.
20:11:32
makomo
and there's no way to escape that (assuming the author didn't provide that function that you showed)
20:12:54
_death
makomo: I once pasted some once-only variant, but it only provided parsing of the specs as a function.. https://gist.github.com/death/8551cf20e2bf296455a3e8cf3f3be11b
21:51:57
makomo
well, anyway, this achieves my goal of using ONCE-ONLY directly, without any rewriting or reinventing the macro
23:27:44
oni-on-ion
literally just reading about 'when-bind' and some very similar examples in On Lisp, pp.94 section 7.6
23:33:09
oni-on-ion
sorry it was jackdaniel who posted this article earlier but i just came across it now from the wild. i thought it was somewhat related to ONCE-ONLY that was being discussed here