freenode/#lisp - IRC Chatlog
Search
2:56:51
mathZ
`pkg info maxima` => maxima-5.41.0, why doesnot maxima run ~/maxima-init.mac automatically after started ?
4:21:09
beach
I guess lots of smart people with lots of time have already tried that. Not that this fact guarantees that it can't be done. Just that it might take some time. :)
4:21:48
beach
I mean, I make my living questioning what lots of smart people have agreed upon for decades, but that happens to no longer be true.
4:29:51
MichaelRaskin
Well, it is not definitive enough that I publically say yes without any qualifications on such a statement, but omst likely yes.
4:33:13
MichaelRaskin
As for smart people agreeing — well, my ICALP talk this year will be a set of ideas I had in around a week or two, together they (with something in the paper but not in the talk because technical details) disprove the conjecture most people in the field were inclined to believe… You never know.
4:37:41
beach
Our colleague idurand worked with Aart Middledorp for some time. His standard format for a talk started with "In <year>, <person> wrote a paper in which it was proved that <theorem>. Here is a counterexample to that theorem." Very impressive.
4:39:14
MichaelRaskin
Heh. Yeah, that is impressive, but this is what I definitely cannot do — it needs studying something deeply.
4:42:00
MichaelRaskin
Well, in the sense that you need to actually look at a field, have a good grasp of what is known and what is not over a large area of related things, and read a lot of papers with this in mind. It is too much specialisation for me, I am more of «wait, you are applying this from adjacent field Y instead of a better fit in an almost-adjacent field Z» person.
4:43:25
beach
That is definitely also a winning strategy in CS. Few people have the broad knowledge to do that, so there are lots of good results to be found.
4:45:08
MichaelRaskin
But few people know basic discrete probability well, or remember their second-year algebra — at all. Which is the reason for my ICALP papers in 2017 and in 2018.
4:49:32
MichaelRaskin
Then again, I am grateful to the people more immersed into the fields in question for telling me how to actually write that down (oh I did write it down on my own, but the target audience for that specific order of explanation turned out to be empty…)
4:52:23
beach
When I did my PhD and wrote an early paper, I wrote it so that people could understand what I was doing, and I was told that this is not how it is done. You reverse the order of your explanations in the paper.
4:53:22
MichaelRaskin
Reversing is enough for linear enough things, flattening a DAG is even more fun
4:54:19
MichaelRaskin
(Can we please actually learn how to use hypertext, pretty please? I am not saying I know what exactly to do, I am saying there is not enough diversity of attempts)
4:55:34
beach
Sure. All I meant was that conventions are different in different domains, just like conventions are different for different programming languages. And one just has to learn and adapt.
4:56:22
MichaelRaskin
Yes, and when I am not insider in any specific field, that learning often needs direct explanations from insiders — every time.
4:59:13
MichaelRaskin
It is definitely not a common knowledge in the I know they know I know sense; I wonder if it is universally obvious knowledge that just doesn't become common knowledge because pf coordination problems.
5:02:16
beach
I am convinced that not many colleagues even give it a thought. I mean, they don't even give any thought to the basic quality of their writing, as Steven Pinker so amusingly points out in his book and in his talks.
5:05:39
MichaelRaskin
Well, then there is a clear incentive problem around basic quality of explanation.
5:06:49
MichaelRaskin
Not in the sense of lack of incentive — this can be overcome with appeals to morality, in the sense of visible negative incentives.
5:09:26
MichaelRaskin
(then again, the problem of negative results is easier to define and it is still not going anywhere)
5:09:29
beach
I am not sure that's enough. As pinker explains, most colleagues just don't know how to write, and learning that is not obvious.
5:10:07
MichaelRaskin
I can explicitly declare that the style I prefer to read is generally considered bad writing.
5:11:55
MichaelRaskin
And I have my doubts whether «good writing» is good for 80%-of-the-people-in-the-field, and not something like 45%-good with some alternatives having 15% and 20% target audience.
5:12:26
beach
Learning new things is hard. Most people, even scientists, mathematicians, and computer scientist, are "performance oriented" (have a "fixed mindset" as Carol Dweck puts it) in most domains, and they have trained themselves to overcome it in their own narrow domain.
5:13:41
beach
MichaelRaskin: I think there are different kinds of bad writing. I think you are referring to the bad writing that just does not follow conventions in the field. But what Pinker refers to is a much broader concept of bad writing, that I am very sure you would not appreciate either.
5:15:03
beach
Anyway, I finished my coffee, and I should get to work on the specification of the SICL garbage collector(s).
5:15:41
MichaelRaskin
It is not about locla conventions, it goes across the fields. The question is what is entangled mess and what is a good explanation that attaches all the associations where they are needed (yes, this is the same thing)
5:47:00
fiddlerwoaroof
I thought I remember announcements to this effect, but I can’t find any trace of it.
5:47:42
MichaelRaskin
In that direction, not the other way round? Probably not a Common Lisp, just some kind of Lisp, Common Lisp is just too large.
5:56:28
aeth
https://irclog.tymoon.eu/freenode/%23lisp?from=2017-12-01T01%3A53%3A36&to=2018-06-29T13%3A53%3A36&search=prolog
6:17:00
pillton
LdBeth: You should be able to run the inspector which is bundled with your CLIM implementation.
6:56:08
beach
LdBeth: Climacs has M-: as I recall, bit since it's a CLIM application, you would be much better off to start the CLIM listener instead.
6:59:40
beach
Well, the first thing to do then is to get rid of the idea that everything goes through the editor.
7:00:23
beach
With CLIM/McCLIM, you have the listener, so that Climacs can be used only for editing and not for the other tasks.
7:00:58
beach
So there is the listener for REPL interaction, Clouseau for inspecting objects, a "debugger" for inspecting backtraces, etc.
7:01:24
beach
You can run them separately or from the listener, but it would be unusual to run them from Climacs.
7:17:23
beach
You can call drawing primitives directly, for instance, and see the result immediately.
9:29:15
beach
I need some advice. In SICL, a heap-allocated object is either a CONS cell or a GENERAL INSTANCE. A CONS cell is represented as two consecutive words. A general instance is represented as a two-word header where the first word points to the class and the second one to a RACK. The rack contains all other information like the slots of a standard object, the elements of an array, etc. etc.
9:29:21
beach
I was thinking of representing the rack pointer as an untagged value, but this is problematic for the garbage collector in that I would have to have information in each stack frame concerning what stack location and register contain rack pointers. Plus, after various optimization tricks, there might be raw pointers to an ELEMENT of a rack and not only to the beginning of it.
9:29:22
beach
However, I currently have one unused tag. I could use it for all rack pointers (to the beginning or to an element). This way of doing it would also make it possible to recognize whether a particular 2-word item is a CONS cell or a general instance because only general instances contain a rack pointer in the second word. Is this a good idea or am I missing something?
9:33:15
beach
This recent conundrum, by the way, shows the intimate relationship between data representation and the constraints on the garbage collector.
9:37:45
beach
Yes, that's a frequent operation. But I think all RISC processor that don't have an offset in the instruction optimize this case.
9:37:55
flip214
my first reaction is "that is so low-level optimization that a special case in the compiler or a bit of assembly might fix that"
9:38:18
flip214
but I'm not that proficient about RISC -- not even sure whether eg. ARM would fall into that category
9:39:10
beach
Well, it is not "fixable". What I could do is to make sure all rack pointers have to be recomputed after a function call.
9:39:19
flip214
I guess that main memory access has such a big penalty already (on cold caches at least) that the one ADD wouldn't be a problem
9:39:48
beach
flip214: Yes, exactly. The addition would be a very fast operation compared to the memory access.
9:40:20
beach
And I presume such RISC machines are superscalar, so that they can do the addition in parallel with other stuff.
9:40:23
flip214
a stack frame _can_ contain rack pointers - as long as there's a visible reference to the _base_ of the rack too. then the other pointers could just be hidden
9:41:01
flip214
ie. as long as a _visible_ reference to the rack is on the stack, you can have any number of (GC-) _invisible_ pointers to the same rack as well
9:41:32
flip214
that would mean you have a bit more stack usage, but no register addressing or GC issues
9:42:10
flip214
well, how many racks will a tight loop access simultaneously? at most 3 or 4, else it wouldn't be a tight loop anymore, right?
9:43:29
flip214
well, the compiler needs to have a few local variables (or make them thread-local?!), where references to things addressed opaquely by registers are referenced
9:44:05
flip214
so you'd only need a few pointers in the TLA, and a store to them every now and then
9:44:51
flip214
for the easiest (and perhaps worst) case, have one pointer in the TLA for each addressing register
9:45:12
flip214
when a rack address is loaded into the register, emit a store of the rack base address to the corresponding TLA pointer
9:46:20
flip214
first of all, they'd only be _concurrently_ read on the start of a GC (fetch all roots), and never concurrently _written_ by another thread.
9:48:06
beach
You said "the compiler needs to have a few local variables... where references to things addressed opaquely by registers are referenced".
9:49:05
beach
Can I assume that you mean that those variables are not used during compilation, but that are needed so that the compiler can emit code using them?
9:50:50
beach
flip214: Sorry about all this. It's an occupational hazard. I was trained as an engineer and a scientist and I must understand every word.
9:52:14
beach
This happens to me so often that I wonder why I seem to be one of the few people who can't understand quick exchanges like this.
9:53:30
flip214
beach: the problem might as well be me, as I don't have formal training and so might have differences in my vocabulary.
11:14:32
jackdaniel
if you press `v` on the frame (given you use sldb) it should open a buffer with the source location in question
11:16:17
loke
I sometimes get expresment positively surprised when it comes to SBCL's ability to find the correct source line... Sometimes I get very disappointed too.
11:51:14
jackdaniel
loke: amusingly enough, in this lecture the speaker mentions how vovels and slips of a tongue are related to subconcious clash of words you could use: https://www.youtube.com/watch?v=n8m7lFQ3njk
11:59:46
dim
it doesn't mean extremely thou, like “actuellement” in French means “currently” in English, and other traps like that ;-)
12:24:00
beach
jackdaniel: I will definitely watch it at some point. I have read a few books by Douglas Hofstadter and I like his writing very much.