freenode/#lisp - IRC Chatlog
Search
3:08:29
loke
pjb: Right, but in the discussion I had the person was arguing that the object orientation in Objective C was somehow fundamentally different from that of, say, Java because it's “message passing”.
3:18:27
aeth
It's harder than it looks in edge cases. I don't currently have typed keyword/optional/rest, for instance. I'll probably copy the syntax from pillton's specialization-store there. Similar syntax already, except I don't provide a return type
3:19:25
aeth
My return-type will probably be in a keyword argument to the name-and-options instead of its own field after the lambda-list like in specialization-store because I rarely need it
3:20:56
mfiano
and typed-args can be any OLL arguments aside &aux, because I'm lazy and never use them
3:22:18
White_Flame
loke: wikipedia says the major difference is that the target method is determined at runtime by the object's code, instead of at compile-time. So that's a bit more CLOSsy, in the runtime aspect
3:22:50
aeth
specialization-store is (name-and-options typed-lambda-list result-type &body body) and mine is (name-and-options typed-lambda-list &body body)
3:26:21
aeth
All that's really missing is a defmethod that supports inline and classes for keyword/optional (which iirc are not supported, possibly because of the ambiguity in a straightforward attempt)
3:34:15
proshlo
I'd like to write a Common Lisp interpreter on a graphing calculator so I can use Macsyma on it. Where should I start? I have an almost-finished Scheme interpreter in C++. Do I add special forms to make it a Lisp-2 and add defmacro facilities to bootstrap the rest? Should I go off the Clisp source code instead?
3:36:47
aeth
Graphing calculators are essentially identical to how they were 15+ years ago, stuck in time, afaik
3:37:40
aeth
Well, you can't have a significantly better one because they're mostly used on standardized tests or in classrooms.
3:37:43
proshlo
aeth: I think the most powerful version of the TI-84s has a 15mhz CPU and 24mB of ram.
3:37:46
Bike
proshlo: i mean, a lisp interpreter isn't really much harder than a scheme interpreter. having actual library functions is more work than the basic "if you type Z that evaluates to Y" stuff.
3:37:55
blep-on-external
i'm not saying get it from arxiv, but get it from arxiv and say if it's any good
3:37:57
White_Flame
proshlo: Scheme was intended as a minimalist language. Continuations can be kinda confusing, but would be a lot easier to implement in an interpreter than in a compiler
3:38:28
Bike
i also thought modern graphing calculators had some basic CAS in them. i know mine does
3:40:38
proshlo
loke: yeah Bike: Mine can do numerical integration, but not symbolic. I'd like to have that because Calc II is hard. :)
3:43:45
loke
the HP-58 language was stack based. So { X DUP MULT } was a list of three symbols, or a program that squares X
3:44:50
aeth
And it's an old enough app that it doesn't have ads or microtransactions or other nonsense! (I don't think I would have found it in today's Android.)
3:45:09
loke
Me and a friend implemented LISP-EVAL on the hp48. It wasn't much code, and it gave us Lisp.
3:45:24
aeth
loke: Do you still have the program? It would be interesting to see if it runs in Droid 48
3:45:55
loke
aeth: LISP-EVAL? No... we wrote it on the actual device, and lost the code before we could save it.
3:47:31
loke
One interesting aspect of the HP-48 language is if A contains the symbol B, and B contains the symbol C, then evaluating A results in C.
5:52:22
makomo
i just found parse-macro-lambda-list, but i'm interested in the one using a proper grammar and an early parser
7:33:23
beach
Murii_: ↑ Notice how it says that CAR is an "accessor". That means you can use it with SETF as I showed.
8:46:51
aeth
car is old enough that there's also another, legacy way. rplaca. yeah, use (setf (car x) 42) instead of (replaca x 42)
8:51:43
shka_
easy to remember because order is the same as argument list to setf-at-something functions
9:05:02
aeth
but I guess Lisp is proof that everything in software bloats into something way past its original purpose
9:09:03
pjb
Funny to use the music of Blade Runner in this clip. In Blade Runner, space didn't go beyond the solar system!
9:34:44
oni-on-ion
https://github.com/whily/yalo speaking of Mezzano and other lisp OS the other day
10:00:56
Murii_
shka_, that can happen with Java as well and thb I don't see the problem if you know what I mean ;)
10:02:18
MichaelRaskin
I think at the same level of implementation effort Pascal is better than C and Object Pascal chimera is better than C++.
10:05:27
MichaelRaskin
The scary part that I am not sure there is anything better for quickly mashing together a native GUI app than Lazarus and FPC (Lazarus being a free/libre Delphi look-alike)
10:19:10
MichaelRaskin
beach: how do you expect debugger thread to learn that the debugged thread has reached a breakpoint?
10:21:55
MichaelRaskin
What happens now with it? It waits on a lock? What if the step-over doesn't complete in any reasonable time?
10:32:39
beach
MichaelRaskin: I think that before going blocked, they will inform the debugger thread.
10:34:36
MichaelRaskin
OK, I can probably translate the properties of notification mechanism into thread primitives.
10:35:07
MichaelRaskin
When debugger says «step over», can it ever continue execution before step-over is complete?
10:36:09
MichaelRaskin
In a way, this is a separate layer so if you answer a few yes-or-no questions I can implement something, and this layer can be swapped out if needed
10:37:19
MichaelRaskin
Because the lowest layer (inject poll points, inject whole-function-skipping for undebugged threads, control debuggedness) works now.
10:39:53
MichaelRaskin
So, yes-or-no: debugger thread invoking setp-over has a chance to change its mind before step-over operation is complete?
10:42:01
beach
I think what I wrote in the specification is that the debugger creates volatile breakpoints and all those are removed when the debugged thread stops at any kind of breakpoint. So it's enough for the debugger to remove the volatile breakpoint before the application thread reaches it.
10:43:50
MichaelRaskin
My plan is to show you a demo where you will agree that details like breakpoint volatileness can be implemented independently of underlying implementation.
10:45:09
beach
OK. I think whether a breakpoint is volatile or not is just a bit set by the debugger in whatever representation it has for breakpoints.
10:45:15
MichaelRaskin
On the other hand, debugger thread constantly doing something (polling a variable) as fast as possible (a state known as spinlock) and maybe deciding to change its mind based on another variable it polls is probably a bad idea (spinlocks are often very efficient at hogging a core fore doing nothing)?
10:45:42
MichaelRaskin
Basically, if you reach a breakpoint, it is an expensive event and you can put whatever logic you want.
10:46:15
beach
I don't see why the debugger thread would lock at all. The user may want to interact with it when the application is running.
10:47:37
MichaelRaskin
Does user need to actively request status update to see if the breakpoint has been reached?
10:49:40
MichaelRaskin
Unfortunately, if the thread is interacting with a user, there is always a risk it will enter a blocking wait for input.
10:51:28
beach
Or the debugger could have several threads, one waiting for the application to stop and one interacting with the user.
10:52:27
beach
No, I definitely do not want the debugger to be another process (in the Unix sense of "process").
10:53:17
beach
I have absolutely no interest in designing a communication protocol between a debugger and an application.
10:54:37
beach
Correct. It's just the thread(s) that happen to run the code of the debugger. There is nothing special with it (them).
10:55:54
MichaelRaskin
There are instrumented functions. (SICL case: all of the user functions and some of the implementation functions. Portable prototype: the functions from files loaded in «wrapped» mode, the functions from files that declare themselves «wrapped», the functions that were declared wrapped on their own)
10:56:52
MichaelRaskin
Each instrumented function checks if it is in the debugger mode, if not — executes uninstrumented copy of its body, otherwise executes the body with polling points.
10:57:35
MichaelRaskin
Each polling point calls a hook (settable for each debugged thread separately)
10:59:31
MichaelRaskin
If a breakpoint (in some sense) is reached, the hook includes notification logic (simplest case: print to *trace-output*)
11:01:00
MichaelRaskin
After the pause it checks if a variable (tied to the thread) has been set to something it can evaluate. If it is null, it re-pauses itself (it is a loop), otherwise it evaluates the code put into the variable and clears it
11:01:50
MichaelRaskin
That code might tell it to set some breakpoints, or to evaluate stuff in context, or to exit the breakpoint and continue running
11:04:24
MichaelRaskin
Good question. Examination of thread context (like thread-local values of global variables is still needed, though)
11:04:59
MichaelRaskin
Where you keep the breakpoints is free choice, so yes, you can set them from debugger thread.
11:05:21
MichaelRaskin
Unless you want to have a thread-local global variable with breakpoints, then you need to do it from the debugged thread
11:05:52
MichaelRaskin
But anyway, debugger thread is nothing special unless your _notification_ logic is «unfreeze thread X»
11:06:34
beach
Yes, I see, it would be highly implementation specific to examine the special variables of a different thread.
11:07:16
MichaelRaskin
And I want something portable almost for free, so code injection for special-variable examination is my choice
11:10:16
MichaelRaskin
Anyway, if you want a global breakpoint table keyed on the debug session name — my current code doesn't care yet, and SBCL provides auto-locked hashtables, so it can be done externally.
11:14:47
beach
Yes, I see why it is necessary if you want your implementation to be portable the way you have said.
11:16:43
MichaelRaskin
The other option is there is an object that the thread keeps in a thread-local global variable, and the external world accesses via a hashtable.