freenode/#sicl - IRC Chatlog
Search
7:40:39
jdz
I traveled from London to Paris (ELS2014), and it was absolutely better than a plane. The ride itself might be longer (I think 2.5h), but considering getting to and from airports, waiting in the airports, ample legroom on the train, comfortable seats, possibility to do stuff on laptop all the way. It was way more enjoyable experience.
7:48:42
no-defun-allowed
Here is an amusing but unimportant question: long ago one might use hardware acceleration for an efficient implementation of a dynamic language. But now that isn't necessary, of course. So could you remove a significant amount of hardware by using a safe language, and using the language for isolation instead of that hardware?
7:48:59
no-defun-allowed
I think something like this was mentioned in #sicl once, but I forgot what exactly.
7:50:16
Duuqnd
I mean, the Lisp machines lacked pretty much any security whatsoever, but if Genera had been built with security in mind I'm sure it could've been a very secure system.
7:50:35
beach
Let's see. I don't plan to remap memory with CLOSOS, so I think the memory-management unit is superfluous.
7:51:08
MichaelRaskin
Economies of production scale for computation power have made it cheaper to get performance from using same thing as everyone that an actually fitting thing
7:51:31
beach
I also plan to run it in supervisor mode, so the distinction between user/supervisor modes might be unnecessary.
7:53:04
no-defun-allowed
What would be used to map disk addresses to where they are cached in primary memory if not a MMU? I was thinking it could be simplified, but not eliminated.
7:54:57
moon-child
rather than a complete mmu based on pages, they have a flat memory space with byte-granular permissions (rwx, or just rw for the mill since it's a harvard arch)
7:54:58
no-defun-allowed
MichaelRaskin: Yes, it's as impractical as proposals to add more hardware support. But doing the opposite of that was, again, somewhat amusing.
7:56:10
moon-child
no-defun-allowed: also, proposed in _the birth and death of yavascript_ https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
7:57:29
splittist
(From Geneva to Porto by train a mere 42 hours with 7 changes. Or a 2:15 EasyJet flight.)
9:38:14
beach
Oh, and we are still debating whether default methods are specialized to the CLIENT parameter.
9:38:54
heisig
The we should finish this debate and write things down. Because I am pondering this very thing right now.
9:43:09
heisig
The trouble with specializing on the T client is that it makes it hard to debug custom protocols. Default methods might hide some bugs and prevent 'no-applicable-method' from being called when it should be.
9:45:20
heisig
The question is whether we should go even further and have each protocol define both a CLIENT class, and a STANDARD-CLIENT class inheriting from the former.
9:46:30
beach
Nah, a protocol class is good enough. Client code should create a "normal" class, using the protocol class as a superclass.
9:47:25
beach
CLIM is different in that it also defines its own instantiable classes, and it is expected that the very nature of those classes can differ.
9:49:28
heisig
beach: I recall you had this document about protocol design. Can you give me an URL for that?
9:56:35
jdz
beach: In section 5.3 do you intentionally write "simple dispatch" instead of "single dispatch"?
10:31:15
beach
heisig: Last time I thought about type inference, I found it useful to consider two different purposes. The first purpose is absolutely crucial, but also fairly simple, namely optimization by avoiding unnecessary type tests. The second purpose is good, but can be considered a bonus, and it is giving the programmer compile-time feedback about incorrect types. The second one is much harder, so you might want to consider only very
10:32:40
beach
heisig: For the first purpose, it is good to know whether an object is of one of the immediate types, or on the contrary, if it is a standard object. Also, the type LIST might be useful, because then a single test (for CONSP) is enough to distinguish the cases.
10:33:21
beach
Arrays of different element types are important. You can assume that we are not allowed to CHANGE-CLASS of an array.
13:18:37
lukego
SICL seems very interesting and I am going to have to read all the papers once I get back into a distractable state.
13:28:19
splittist
lukego: clime seems like a great development aid (inter alia) - being able to attractively (or, at least, graphically) PRESENT objects at the repl would be great.
13:29:26
lukego
maybe it will also work as a stepping stone between the Emacs and CLIM worlds i.e. an easy way for SLIME users to get their feet wet with CLIM.
13:31:16
lukego
but yeah presenting objects at the repl is working already now and once ACCEPT is also working then we'll be getting somewhere
13:32:22
lukego
I haven't dared to try yet :-) but I /think/ it's going to just work. kind of hoping someone else will volunteer to try that :)
13:32:44
lukego
I mean, CLIME is just translating CLIM drawing operations into SVG, and SVG has first class support for drawing text.
13:33:27
lukego
but once it hits Emacs it will be rendered into a bitmap. unless we did some more elaborate integration -- maybe even tying in with existing SLIME presentatoin features -- but that's beyond my ambitions for no
13:34:37
lukego
though by "just work" I mean after adding a few lines to emacs.lisp where it translates output records to svg elements here https://github.com/nuddyco/McCLIM/blob/clime/Backends/Emacs/emacs.lisp#L219-L232
13:35:17
lukego
up to and including fixing silly things e.g. if I've forgotted to commit some crucial file...
13:36:43
lukego
could potentially be useful for SICL even? I started down this interactive diagrams path originally for visualizing LuaJIT IR instructions.
13:38:08
lukego
that worked pretty well IMO e.g. click an IR instruction to see the SSA pruned to only show transitively referenced instructions, e.g. click on a branch to see all instructions that influence whether that branch is taken, etc.
13:39:23
jackdaniel
I think that there is such tool for SICL and Cleavir written in CLIM, but I don't remember details
13:39:59
lukego
it'll be interesting to see how much CLIM code ends up working with CLIME. maybe quite a bit or maybe only new code carefully written in a supported subset. I don't have much notion of CLIM usage.
15:24:54
lukego
are there PDFs of the SICL papers and manuals somewhere, or does one build them oneself?
15:28:01
lukego
I don't think it's a problem for me to run builds really, I just notice that the lack of links to PDFs is inhibiting me from impulse-reading
15:32:12
jackdaniel
ACTION wonders how useful is the url ending with ...pdf given there is no way to access a list of file names (403: Forbidden for the /SICL/ directory)
15:36:15
beach
My idea was that you would look in the SICL/Papers/? directory. Find the name of the TeX file, and then replace the suffix with pdf and add it to the link.
15:44:22
beach
The good news is that I might no longer need a system administrator though, since I now replaced my desktop and everything seems to work in the new machine.
18:09:28
beach
I have no intention of using a library written in C++ and that I will have to keep up with.
18:09:45
beach
If someone else wants to create such an independent module, then they are free to do so.
18:10:41
pjb
I guess all that would take is only one of us winning the lotto, to finance more backends to sicl :-)
18:10:45
beach
Plus, given all the problems the Clasp developers had with it, with respect to compile-time performance, exception handling etc., that's another thing I have no desire (nor time) to deal with.
18:12:54
beach
I plan to "support" a RISC-V backend, and the x86-64 one, as long as I need it for my own computers.
18:14:03
beach
Anyway, I'm off to spend time with my (admittedly small) family. I'll be back tomorrow morning (UTC+2).
18:36:36
Bike
I'm poking at the "mirtype" branch in Cleavir again, where decisions of unboxed types and values/non-values representations are delayed to MIR level. everything works but it's slower, which i think is basically because multiple-value-bind does a local call now instead of just some setqs
18:37:03
Bike
there are a couple hacky solutions I can do, but I think the right thing would be to use type inference information about the number of values returned by forms
18:37:55
Bike
Since values specifiers don't work in some implementations, I think it might be prudent to gives cleavir-ctype its own values type objects... which it sort of has anyway
18:54:59
heisig
Bike: I just started working on a protocol for types (although slowly, because I am technically on vacation).
18:55:55
Bike
oh yeah, if you're any less busy... I filed a PR for Trucler that I would appreciate a look at
18:56:17
heisig
The main difference so far is that I clearly separate ctypes and vctypes. I am also thinking about introducing fctypes (function ctypes).
18:56:47
Bike
mm, well that's what i'm just about to work on for cleavir-ctype, so if you do it first all the better i suppose
19:06:19
heisig
Bike: I just had a look at your changes. Let me rephrase your change to make sure I actually understood it.
19:06:51
heisig
We are only considering declarations that are not bound to a particular variable. Things like ftypes, types, special, dynamic-extent etc are already handled by other means.
19:07:49
heisig
The only one of these declarations in the standard is cl:optimize, but implementations might support further declarations.
19:08:31
Bike
I need to get that information from the environment somehow and this is what I came up with
19:11:25
heisig
But the compiler wouldn't be able to detect user-defined lexical declarations. So Trucler doesn't have to worry about that either.
19:12:03
Bike
well, it might want to record them in an environment where they could be used by compiler macros or whatnot
19:13:10
Bike
https://github.com/guicho271828/trivia/blob/master/level2/impl.lisp#L370-L390 for reference, here's a use of them in the wild i found when i was seeing if anyone actually did this
19:15:29
heisig
I think those are good changes. The only thing I wonder is whether we should conflate describe-optimize and describe-declarations.
19:18:12
heisig
The point is that describe-optimize returns an instance of a particular class, while the latter returns the X of some (declare X) just like it appeared in the source code.
19:19:03
Bike
oh, i was thinking of describe-declaration as returning a description object of some kind
19:19:35
Bike
I figure in the spirit of "CLTL2 but modern" it would always do so, and if you want a custom declaration you need to define a description class or something
19:20:40
heisig
Oh, I see. But what information other than the declare form would be stored in that declaration-description?