freenode/#lisp - IRC Chatlog
Search
16:05:17
beach
That might work. Before and/or after evaluating an expression, the code consults a hash table in the thread object. If the hash table contains TRUE, then the threads stops, waiting for the debugger to allow it to continue.
16:06:55
beach
mfiano: It is inconclusive. In SBCL it is sometimes faster and sometimes slower than the native technique.
16:07:28
beach
I guess it must also indicate where it stopped (the HIR value) so that the debugger can consult a table to figure out the corresponding source location.
16:09:29
Bike
it's faster than what we had. the main issue with it is warmup time, which is exacerbated by unrelated factors. and sbcl has warmup time too. such is caching
16:11:04
beach
mfiano: The beauty of Common Lisp is that several techniques could coexist. Some generic functions could use one technique and some others some other technique, so the best one can be chosen on an individual bases. The same generic function can even use different techniques at different times, depending on the applicable methods.
16:12:03
beach
One might for instance choose one technique for a simple slot reader, and a different technique for (say) PRINT-OBJECT.
16:13:31
beach
I use that fact when I run SICL generic functions inside SBCL. I use the fast generic dispatch technique to create the discriminating function, and SBCL uses its own technique of course.
16:19:47
beach
What someone should do some day is to figure out how to recompile call sites when the callee changes, and doing so while still respecting the semantics of Common Lisp. I am pretty convinced that just recompiling the calling function from scratch would violate the semantics.
16:22:00
beach
How would it violate the semantics? Well, for one thing, if you start from source code, you will have violated the "minimal compilation" restriction, because some macros might have changed in the meantime.
16:30:52
beach
We could represent the discriminating function of the callee as HIR, inline it, and then do things like type inference on the result.
17:05:14
asarch
asarch@hell:~/Projects/clisp-2.49$ ./configure --cbc built-with-gcc > compilacion.log 2>&1
17:27:27
phoe
also you're in Lisp-2 now so these two different forms of def start making little sense now
18:35:42
makomo
is there a way to create a never-before-seen package just like you can do for symbols with GENSYM?
18:36:18
makomo
i can do (make-package (gensym)) but the SYMBOL-NAME is used as the package's identifier right?
18:36:58
makomo
so any other symbol with the same name will return the same package when FIND-PACKAGE is used
18:45:08
edgar-rft
makomo, try (progn (make-package 'foo) (make-package 'foo)) ans see what happens.
18:49:03
makomo
and i want a fresh package every time i READ to make sure that i get a new environment of sorts
18:49:25
makomo
i guess i could reserve a name for myself and then DELETE-PACKAGE when i'm done and ready to READ again
18:49:42
makomo
but i could have multiple "simulations" running, which would require multiple fresh packages at the same time
18:51:03
makomo
i see this as the same problem of "well, just come up with a funny name that nobody else will think of"
18:51:26
MichaelRaskin
I would generate a random name (as in (format nil "~36r" (random (expt 36 20))) ) add prefix, check for collisions, hope for the best
18:52:58
makomo
but i wonder why strings were chosen as package identifiers? would it really be weird if symbols named packages?
18:54:58
MichaelRaskin
By the way, as make-package signals if there is a conflict, you can write a make-random-package function that is guaranteed not to collide with its own things
18:56:09
dlowe
That would be better than using the built-in reader and hacking it to do what you want.
18:56:37
scymtym
makomo: another option would be https://github.com/robert-strandh/eclector which can be customized to not intern symbols
18:57:43
MichaelRaskin
One day beach will release SICL with first-class global environments and there will be much rejoicing
19:03:53
sjl
asarch: ASDF has a manual. It's worth sitting down and reading the whole thing at some point https://common-lisp.net/project/asdf/asdf.html
19:42:32
didi`
So I'm reading CLtL2's section 22.1.1 What the Read Function Accepts, and it contains a description of the reader algorithm. It looks interesting.
19:51:05
didi`
I am trying to write a reader for JSON, using CLOS, but I stopped at writing various (defmethod read-number (stream (x (eql 0))) ...), (defmethod read-number (stream (x (eql 1))) ...), ... CL's algorithm might be a better one.
20:01:38
butterthebuddha
Yeah I thought so; I am implementing an interpreter and was wondering if there was any functional difference between a vector and an "atom" that I wasn't aware of
20:16:38
aeth
atoms were useful... before Lisp added arrays, hash-tables, structs, CLOS objects, streams, ...
20:17:43
MichaelRaskin
https://gitlab.common-lisp.net/mraskin/agnostic-lizard/blob/master/debugger-hooks.lisp — the core of core of portable debugger hooks support. Not as simple as I hoped, not as horrible as I feared (and forced me to add some more useful data in Agnostic Lizard)
20:17:54
aeth
It might still be a meaningful distinction in elaborate macros, but you'd generally be testing for lists and then handling the rest differently, not testing for atoms
20:19:51
MichaelRaskin
For some reason, such names feel good for my attempts at something small that traverses something
20:22:54
MichaelRaskin
When a minimal extension for adding hooks is over a hundred of lines, obviously the thing itself has to be larger
20:23:52
MichaelRaskin
I guess it helps that the choice is either that or «yet another portable code walker, but actually working this time»
20:24:26
aeth
Lines aren't a good measure in Lisp. The problem is that by the time you get to 6k-8k lines, you never have to leave.
20:29:48
MichaelRaskin
And I guess if my mess of throwing together «escape browser dump web to text editor» is ever worth a release, I keep the package name thoughtful-theridion (theridia is the taxon of cobweb spiders)
20:34:35
dim
can I (open "..." :direction :probe :if-exists :rename) and expect the rename to happen?
20:40:31
dim
it seems not, so I'm using with-open-file and a dummy instruction to avoid the warning about the variable being unused
22:26:14
stylewarning
On SBCL, I have a function F which allocates lots of memory, but doesn't maintain the references. (loop (f)) causes a heap exhaustion, while (loop (gc :full t) (f)) does not. Any hints on why this could be?
22:31:52
didi`
stylewarning: One thing that I observed is that it consumes memory before freeing memory.
22:34:18
stylewarning
I wonder if SBCL tries to do a full GC. It looks like all of my objects are in gen1 or 2, and SBCL is just ignoring those.
23:25:45
pierpa
the hash tables that the function F creates are pretty big, so even a small percentage of them being kept because of false positives could explain the phenomenon.
23:26:34
stylewarning
pierpa: It would have to be holding on to a few of the large tables from a previous call to F
23:26:46
pierpa
this theory agrees with the forst two of your starred points, while I don't understand the third one
23:27:00
Bike
if it was conservatism, how would calling gc manually fix it? it's not any less conservative just because it's forced
23:28:27
stylewarning
I'm trying to figure out in the SBCL source where GC gets called upon a failed allocation
23:57:23
stylewarning
Looks like all the interesting stuff about GC triggering on allocation starts here: https://github.com/sbcl/sbcl/blob/master/src/runtime/gencgc.c#L3739
0:05:54
didi`
In my case, usually I have some percentage of the heap allocated, say 80%, then the GC is triggered and the heap is exhausted.
0:08:31
stylewarning
didi`: That variable seems like the wrong one to tune for a bug like this, no? IIUC, the default is 5% of the heap size, and that means when 5% of the heap is used, a GC of some sort will be attempted.
0:10:16
didi`
stylewarning: Oh, I don't know how to fix it. My workaround has been trying to use less and less programs during my work and aggressively cut my memory usage inside my program.
0:14:29
didi`
stylewarning: Another "fix" I employ is calling the GC from time to time inside the REPL.
0:14:57
stylewarning
didi`: this bug is unfortunately being trigged in the depths of a complicated compiler pass
0:42:42
stylewarning
makes me think there's something awry with collecting large objects, which I know are allocated specially
0:49:29
pierpa
as, in the previous case you needed a RANDOM integer to trigger it. In this case, uninitialized arrays. So, vectors containing random fixnums would seem to play a part in this.
0:51:16
stylewarning
pierpa: the random integer bit was because i needed different objects for EQUALP
0:51:37
stylewarning
but I changed that to EQ so all objects, even with the same contents, are basically different
1:04:36
aeth
I'm guessing that other threads (e.g. SLIME+Swank?) would trigger GC even in a non-allocating workload, but running it in a separate process entirely and seeing if the GC is triggered could be yet another test for consing.
1:05:25
aeth
Doesn't help with your problem (unless I wasn't reading it carefully), but it would be an interesting test to run on some things
1:12:10
aeth
stylewarning: Does SBCL have built in file logging or is it done as part of the *after-gc-hooks* that's mentioned in the manual?