freenode/#clasp - IRC Chatlog
Search
10:14:34
frgo
Hello all. Interesting MOP stuff you guys were discussing here during last two days ...
10:28:49
beach
"MAKE-METHOD-LAMBDA revisited", "SICL method combinations", and maybe "Bootstrapping Common Lisp".
10:31:51
beach
Actually, it is quite impressive how much stuff there is in the literature and in existing implementations that has not been thought upon for decades.
10:33:05
beach
All those things influence how software is written, so it often suffices to take a close look to see how things can be improved.
10:36:42
beach
And there is some bad science out there. I hear that the vast majority of CS books don't get a thing as simple as binary search right. And most of those that get it right have solutions with way too many more operations than necessary.
10:52:07
makomo
beach: agreed with frgo. i like the formal style of your documentation very much and i think we need more of such stuff.
10:52:49
makomo
basically the "mathy" style of it -- the various explicit definitions and introduction of terminology, etc.
10:54:00
makomo
beach: if i had to choose, i would probably pick the last paper since bootstrapping is always a cool subject. then again, i don't yet understand the problems of the first two, so i can't really judge it that well :-)
12:07:32
beach
makomo: One of the thing I have learned over the years, is that it is much easier to understand what the objects do if you give them a nam. Hence the many definitions in what I write.
12:09:35
makomo
beach: i've come to the same conclusion myself and 100% agree with it. i always like to use math as an example where that practice is extremely important
12:10:00
makomo
and of course, lisp, where we can, along with functional abstractions, also give source code patterns a proper name through macros
12:25:38
beach
heisig: Did you read my suggestion to Bike for making it possible for the method function to refer to the method?
12:41:21
beach
When DEFMETHOD is expanded, it augments the environment that make-method-lambda uses.
12:42:04
beach
That environment contains a symbol (gensymed) that it then uses to bind the value of the make-instance call.
12:52:32
beach
Different subject: suppose I wanted to use host FASLs to speed up SICL bootstrapping. Currently, when I load a source file into some SICL first-class global environments, I compile it a huge host function with one parameter, the environment to "tie" it to. Tying is done by executing that huge function on the environment of choice.
12:52:33
beach
What if I instead compiled it to (funcall <that-huge-function> *environment*) where *environment is some SICL special variable? I could then use the host file compiler to produce a host FASL that I can load later on.
12:53:09
beach
Then I would just say (let ((*environment* <environment-of-choice>)) (load <fasl-file>))
12:55:09
beach
It might get complicated though, because the macros used by a particular source file could have different definitions in different environments.
12:57:42
heisig
What would be the difference between the former ant the latter approach? In both cases, the host compiler has to compile <that-huge-function>. To me, it seems both approaches are just different conventions of how to pass an environment to the huge function.
12:58:34
beach
When I modify a single thing and run the procedure again, I could avoid the compilation step in most cases.
12:59:54
beach
What I have currently for the new bootstrapping procedure takes 3 minutes on my machine, and it is going to take longer as I add more processing.
13:02:35
heisig
Ah ok, so in the current scheme you cannot exchange the environment without rebuilding the FASL. Then the *environment* approach sounds like a good idea. As long as the macro definitions do not change, everything should be fine.
13:03:35
beach
Yeah, I would have to keep the FASLs distinct for each environment. It might not be worth it.
13:03:56
beach
But 3 minutes is enough to lose concentration and not enough to go do something else. :)
13:06:29
beach
I could also work on making the code smaller for the SBCL compiler to compile of course.
13:07:17
heisig
Random idea: You could use the SXHASH of the source forms of all macro definitions in an environment to decide whether an environment is compatible with a FASL.
13:23:08
Bike
the dynamic variable thing is basically what i did when i was experimenting with sandboxing. it seemed to go okay.
13:23:09
minion
Bike, memo from beach: MAKE-METHOD-LAMBDA takes an environment object. We could augment the compile time environment with a binding holding the name of a variable that call-next-method can refer to to for the method object. The expansion of DEFMETHOD can then bind that variable.
13:33:15
beach
Sometimes I think I should create a #sicl channel to avoid filling #clasp with this stuff. But I haven't been able to face figuring out how to do it and then manage the spam, the bots, etc.
13:35:07
Shinmera
if you want to register it, /msg NickServ register should tell you what to do, it's really not hard
13:36:00
beach
I also don't know how to get operator privileges (I guess the creator automatically does), nor what to do with such privileges.
13:38:12
Shinmera
I don't see why not. I'm sure there's also people interested in sicl that don't care about clasp
13:38:28
beach
I guess it won't hurt, and if SICL traffic gets too high here, the discussion can always move.
16:03:29
drmeister
I added you to clasp-developers and added usocket to clasp-developers with write access.
16:06:08
drmeister
General: I switched to 'mosh' yesterday - I did a test where I connect to an AWS machine through my home network and then switch my laptop to connect to the internet through my phone hotspot - it reconnected fine. That's great!
16:06:39
drmeister
I guess it just uses ssh to connect the first time and then uses ports 60000-61000 to maintain the connection.
16:07:00
drmeister
The downside is I have to open ports 60000-61000 on the AWS machine to the world.
16:16:42
Shinmera
drmeister: what is the status of the usocket implementation for clasp? is it complete or?
16:19:19
drmeister
Clasp mimics the ecl/sbcl socket low level functionality. I think it is complete - if it isn't then it's a bug in clasp.
16:20:53
drmeister
When I asked what do we use it for - we use slime, quicklisp, cl-jupyter. Clasp has run McClim with a caveat.
16:21:30
drmeister
I haven't run staple-server but I plan to. I have tried drakma and can't remember the result.
16:22:24
Shinmera
well, I'm working on staple-server now. I just loathe having clones of essential libraries, so I really want this upstream asap
16:36:54
Shinmera
looks like the usocket tests require a system called "portable-threads", which does not load.
16:45:37
drmeister
Although Bordeaux-Threads may be more popular today, but Portable-threads offers more portable APIs (e.g. atomic-incf) and supports older versions of implementations. GBBopen also has a " scheduled-periodic-functions" module based on portable-threads, it literally supports creating "scheduled periodic functions" which is very useful in a Lisp server environment.
16:54:49
Shinmera
Alright, I can at least load staple-server. Calling staple-server:start just seems to hang idly though?
16:59:52
Shinmera
So the usocket implementation is not yet right. http://plaster.tymoon.eu/view/922#922
17:11:21
drmeister
Are you doing this on macOS or Linux? On macOS you could get a backtrace easily if its locking.
17:13:24
drmeister
Could you create a clasp issue? We are going to get back on track with fixing issues now that Martin is coming on board next week.
18:51:31
kpoeck
In https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/clos/print.lsp#L189
18:53:47
kpoeck
If I drop the "slotds" in the condition, both print the same and some more ansi-tests reports sucess
18:57:58
kpoeck
I see that pprint in c++ is defined as CL_DEFUN void cl__pprint(T_sp obj, T_sp stream)
19:01:36
Bike
https://gitlab.com/embeddable-common-lisp/ecl/commit/5986c0d6e3cc5bbc613361453c55305c29918f0b well i have no idea what this means.
19:03:53
drmeister
kpoeck: Looking at the wrapper code (it's been a while). void functions return (values).
19:04:33
drmeister
https://github.com/clasp-developers/clasp/blob/dev/include/clasp/core/multipleValues.h#L324
19:05:20
Bike
clhs says "If an object to be recursively printed has components and is at a level equal to or greater than the value of *print-level*, then the object is printed as ``#''. "
19:10:00
kpoeck
If I do CL_DEFUN T_sp cl__pprint(T_sp obj, T_sp stream) and put a return Values0<core::T_O>(); in the end, should that work?
19:13:49
Bike
but if void returns should return no values and aren't, we should fix that, because this isn't the only void function
19:14:20
drmeister
My system is still compiling - kpoeck - could you try another void returning function?
19:17:37
kpoeck
(multiple-value-list (core::print-unreadable-object-function 23 t nil nil nil)) -> (nil)
19:18:19
drmeister
Looking at the binding code void returning functions should return (values) - if they aren't, then I've made an error somewhere after the wrapper code.