libera/#sicl - IRC Chatlog
Search
15:13:34
scymtym
beach: as discussed, here (note the texinfo-documentation branch) is an initial rough texinfo conversion of the README: https://github.com/scymtym/s-expression-syntax/tree/texinfo-documentation/documentation
15:16:16
scymtym
all commits in the master branch are final. so i wouldn't want to push something half-finished that i plan to amend into the master branch
15:18:28
beach
I am not meant for this stuff: "git pull origin texinfo-documentation" results in fatal: couldn't find remote ref texinfo-documentation. It is possible that I misspelled things, because I am getting increasingly dyslexic over time.
15:20:32
scymtym
maybe you need git fetch --all before that to "discover" the new branch. i'm not sure
15:22:53
beach
"git fetch --all" did not give an error, but the subsequent "git pull origin texinfo-documentation" still results in the same message.
15:30:52
scymtym
yeah, i checking the logs to make sure /i/ wasn't assuming the wrong repository. but i was indeed referring to our discussion about documentation for the s-expression syntax library
15:31:23
beach
OK, I am again confused. "git branch" tells me I am still in the builder-protocol branch, but I see the documentation directory and its contents.
15:32:28
beach
Why do things have to be so hard? Especially things that are essentially uninteresting to the task at hand.
15:35:29
beach
But that doesn't explain why I can see the documentation files even though I am still in the builder-protocol branch.
15:36:51
scymtym
git pull integrates changes from a remote branch into the /current/ local branch, not the local branch corresponding to the remote branch
15:37:29
scymtym
git branch -m builder-protocol texinfo-documentation renames the local branch "builder-protocol" to "texinfo-documentation" which is the outcome you wanted, i think
15:39:21
beach
But then the renamed branch will also contain the previous contents of the builder-protocol branch, no?
15:40:25
scymtym
yes, but that should be ok. i made the texinfo-documentation branch by adding commits to the builder-protocol branch
15:44:22
beach
Oh, I guess I am not done. If one day I want to make a pull request, I also have to clone (copy?, what's the term) your repository into one of mine on GitHub, whereas now it is just on my local machine.
15:44:28
scymtym
i understand. i experience similar frustations in terms of not being able to make software do what i want it to do. in my case the issue is not with git but with crazy build processes surrounding the "unity" game engine
15:46:34
scymtym
you would have to "fork" the project on github, then change the "remote" configuration so that my project and your fork are each a remote, then push to your fork. but if it comes that, you can just publish an archive of the changes files on your webserver or send an email, if you want. whichever is easier
15:47:43
scymtym
current project for the university job. it would be hard to argue that the project is a research project, though
15:50:58
beach
I think today I will just build the documentation and see what it looks like. Improvements will have to wait.
16:07:34
jcowan
hayley: is your design better if you optimize it to apply only to standard-classes, since all other classes are immutable (not subject to `change-class`)?
16:16:48
moon-child
jcowan: afaik the plan for sicl is to make all classes which are not builtin-classes standard-classes
16:20:31
beach
Many instances of standardized classes are standard objects, but those standardized classes are not necessarily standard classes.
16:22:27
beach
For change-class to be allowed, the object would have to be an instance of a standard class. Though, it may be possible to allow other objects as well.
16:38:51
beach
So I guess the defined metaclasses are built-in-class, standard-class, structure-class, forward-referenced-class, and condition-class. I hope that's right. But instances of many built-in classes are also instances of standard-object. In fact, all of them are except instances of cons, character, fixnum, and single-float.
16:42:57
jcowan
It might be useful to have a cheap check whether an object is an instance of a subclass of standard-class, since those are the only objects whose racks are replaceable.
17:33:41
jcowan
beach (when you return): my point is that to verify if a rack is obsolete you have to check it against the class object, whereas if you know a rack cannot be obsolete (i.e. not a member of standard-class) you can spare the extra memory fetch.
17:34:17
jcowan
(e.g. something like all objects that aren't member of standard-class have generation 0)
22:11:52
sm2n
moon-child: here's some very wip code that uses it: <https://git.sr.ht/~sm2n/rapids/tree/trunk/item/rapids.lisp#L144>
22:37:09
moon-child
beach: I understood you intend to represent structure objects the same way as standard objects, and to uniformly allow redefinition and change-class on them
22:41:32
moon-child
sm2n: interesting. This almost reminds me of the co-dfns approach to parsing: start with a very rough understanding of the thing parsed, and then refine that
22:58:37
moon-child
so it does multiple passes over the input, each time gleaning a bit of information
23:19:23
hayley
jcowan: Without type inference I need another tag test before running the read barrier, which is also unsettling.
23:37:53
moon-child
I mean, presumably parse output is a tree, so you don't have to worry about having lots of pointers to the object
23:51:08
hayley
Are there any good heuristics to decide when to compact? I recall Immix would compact when the allocator couldn't make any use of one page, and LXR compacts when both RC and marking didn't free up enough space.
23:55:04
hayley
And I am a bit worried about how to copy a page when each (128 byte) line has its own generation, without making fragmentation worse. It might be okay to just copy one generation at a time, since the allocation rate will be higher for younger generations, and thus fragmentation will get worse faster for them.
23:55:50
moon-child
the object is only pointed to from one place. So, assuming you know what that place is, you can, instead of changing the existing object, make a new one, and change the pointer to point to it instead
0:05:15
sm2n
to do that I'd have to pull a bunch of data out of the old class to put into the new class
0:06:47
moon-child
and change-class doesn't do anything more than a slot-to-slot correspondence anyway (modulo update-instance-for-different-class), so
0:19:35
hayley
The LXR paper makes no mention of popular objects, which have been a bane for the incremental-ness of copying in G1 and the Train in recent history. Guess I should ask if I need to worry about attempting to copy those.
0:21:26
hayley
moon-child: With regards to "tail recursion" when tracing, the MMTk chat mentions "When scanning this [large] list [in one benchmark], you normally have to recursively generate 60000 process edge work packets, and each packet contains only one edge. Currently for LXR, I addressed this by processing the list in a loop, without creating any work packets, or pushing to any work queues."
0:28:57
hayley
SBCL already has that sort of tail recursion when copying, though I think it's intended to get the list laid out contiguously in memory, more than avoiding having to check the grey set more often.
2:19:15
hayley
Seems to work now, but I have to get home to test performance. And my ability to create GC bugs still is quite good.