freenode/#lisp - IRC Chatlog
Search
0:03:09
permagreen
It's kind of crazy to me that of all the things in the standard, there is no split-sequence equivalent. I guess it was different time. When real programmers split their own sequences. Or something
0:06:09
verisimilitude
It caused a mess when it was pulled from a repository and thousands of programs broke.
0:07:05
aeth
That's apparently because when you bundle it into the browser, you don't want to include anything you're not using, and the easiest way to treeshake is one-function-per-project
0:09:00
aeth
phoe: And it's not even written properly. It uses my subseq vector implementation, and not my loop-over-sublist list implementation, so it will only be efficient for vectors, where indices are cheap
0:10:14
aeth
Any sequence function needs to be written like this (etypecase sequence (list (%list-version sequence)) (sequence (%vector-version sequence)))
0:10:33
aeth
(you do sequence, not vector, in case the implementation has extensible sequences. It's better to have slow support than no support)
0:12:02
phoe
the way in which you dispatch doesn't really matter here - if it's generic dispatch or typecase dispatch
0:12:03
aeth
It's easy to wrap a function with defmethod if you want to. It's a higher level interface.
0:12:08
verisimilitude
Making code that provides an interface which needs to behave differently based on the class of object isn't appropriate?
0:12:53
aeth
verisimilitude: You can inline the outer function that does the etypecase and then it does inline dispatch and removes the dispatch at compile time if the type is known. You can't do that for defmethod
0:13:25
phoe
Also when your interface is not exposed to the outside world and therefore fully internal.
0:13:33
aeth
When you only have two, and can only have two, the function is better, and if you need to define a method interface you can defmethod on sequence (rather than list and vector or whatever)
0:14:43
verisimilitude
I mean, sure, ETYPECASE is a good way to do it for several reasons, but I don't think that entirely discounts dispatch. I was thinking about having generic functions that are eventually extended for more than just those two, though, which influenced this.
0:14:50
aeth
In fact, you probably should also provide a method, defined on a sequence, and performance won't be hurt because the one line function call is (probably) inline
0:15:41
aeth
verisimilitude: Imo you use ETYPECASE/CTYPECASE when it's trivial dispatch, like exactly two possibilities dispatching on one argument. You use defmethod when you start getting into combinations, like dispatching based on two arguments and with many types of classes, especially if the user is expected to extend them
0:16:25
aeth
(Even for type dispatch where defmethod's class-based dispatch won't work, you can use something like specialization-store in the latter case of complicated combinations)
0:16:58
verisimilitude
I don't really see much opportunity to use CLOS is part of why I'd try to reach for it, I suppose.
0:17:14
verisimilitude
I have a program planned that should benefit from it, but I just avoid using it for almost everything.
0:18:20
aeth
If you're writing for sequences it can be reasonable to assume just list or sequence, where sequence is probably a vector unless their implementation handles sequences extensibly.
0:18:35
aeth
But if you're writing for your own class you can't possibily anticipate what the user could add
0:19:04
verisimilitude
Yes; it would've been nicer, I think, if SEQUENCE functions had been defined as generic functions, instead; do you think so as well, aeth?
0:20:56
no-defun-allowed
sbcl exports a way to hook into the sequence interface, do other implementations do that?
0:21:03
aeth
verisimilitude: Well, that's tricky because you would need generic functions to be inlinable, and you might want that to work not just based on class but also based on type in the case of the generic functions for arithmetic and sequences.
0:21:22
aeth
verisimilitude: So you'd need a more robust implementation for that to work as it does now without hurting performance
0:22:04
aeth
For type dispatch, mostly useful for arrays and numbers, there's this library: https://github.com/markcox80/specialization-store/
0:22:24
aeth
Kind of an oversight imo that this sort of behavior isn't even standard or as optimized as it could be.
0:22:54
verisimilitude
As it stands, you can still just do it yourself by shadowing the relevant symbols, so it's hardly out of reach, just relatively inconvenient.
0:23:15
Bike
also the protocol is kind of weird. like you return a bunch of functions as values for some reason
0:24:04
aeth
Recently I had to use both package local nicknames and sb-mpfr. In fact, I had to use the former because of the latter. "sb-mpfr" is, well, it's not easy to type because it's just a bunch of random letters to me. "mp" is much nicer.
0:25:32
aeth
(because sometimes it's easier to just take something to 200 digits and then round the result)
0:28:31
aeth
I think this is different, though, because an extensible sequence is something you want to use in a library, but this was just a one-off thing.
2:25:44
clintm
It would seem that I'm missing something fundamental with reguard to arrays. Either that, or I've never completely understood them to begin with. (defparameter *t* (make-array (list 10 10))), (setf (aref *t* 10 10) "1"). I'm missing some intuition about why this is.
2:39:02
clintm
I see my confusion. For some inconceiveable reason, I was thinking dotimes starts a 1
4:00:39
aeth
stylewarning: sb-mpfr's API isn't very good. e.g. it has a dynamic global that's named like a constant (iirc, precision) and it's fairly hard to extend it with shadowing so +'s generic
4:25:51
PuercoPop
pfdietz: afacit you are mutating the code as if everything is made up of cons cells. Have you run into any problems due to SBCL's quasiquote represenation?
5:05:59
ealfonso
I am considering using Puppeteer but was wondering if someone knows of an equivalent library in CL?
9:48:21
nydel
pardon me, i am having trouble evaluating this form and i am unable to see anything wrong with it: https://pad.disroot.org/p/commonlispSBCLissue#
9:51:39
jackdaniel
btw, this tool (disroot.pads) you have linked is ridiculusly slow to load given you wanted to share a text of small length
9:54:12
nydel
yeah sorry about that, i do most of my work at SDF and our service for pad/url-shorten has its HTTPS expired so i hastily found a backup
9:55:38
jackdaniel
I have a trivial script "hellpost" which puts text file on my server and returns url
9:55:55
nydel
( the SDF service is at tx0.org but if you check it out please use a remote browser until we sort out our HTTPS )
9:56:38
nydel
ah, i could do that as well but it wouldn't format the code as automatically as something like pad.ubuntu
9:57:56
nydel
jackdaniel: is that working correctly? i see a checksum and the URI of a .lisp file but that file when followed is not behind SSL
9:59:24
nydel
oh i see, there are no certificates at all for the domain (at least its www or blank hostnames)
9:59:54
nydel
jackdaniel: i think http ssl is really important, do you disagree, or have you simply not gotten around to it?
10:02:00
jackdaniel
I don't disagree nor agree, I don't have a strong opinion on the matter. That said we are getting into offtopic now.
10:08:00
nydel
well.. my main project right now is a sort of shared commonlisp REPL. i become interested in http security just as i become interested in how to go about authorizing users by session, permission levels etc in my multi-user CL package.
10:09:10
nydel
as i was working on that a few months ago, i made sure all my www things had tls/ssl to keep from "downgrade" attacks and other textfile-read uninspired hacker drollery for fifth graders
10:09:14
jackdaniel
if you have user sessions ssl is a must, I can't disagree with that. is this project hosted somewhere?
10:11:24
nydel
i'm between version control systems but the project there will load and evaluate (muclr-server:start-server 9903) with 9903 as an arbitrary local port.
10:12:04
nydel
you can connect a couple parallel sessions using telnet localhost 9903 then /login (see the other API functions for how to evaluate and send messages to other users etc)
10:12:57
nydel
jackdaniel: actually here is a little demonstration i had to put together for some potential contributors: https://mastodon.sdf.org/system/media_attachments/files/001/902/074/original/3df2d3a5eb0f385c.png?1542364453
10:18:41
nydel
originally when i stopped only-lurking just recently, i was working on a package i'm calling "repl-ui" ... REPL user interface, of course ... i write so many interactive REPL so frequently that i figured it was time to standardize it. that's a bit more pragmatic and less lofty than something like MUCLR.
10:20:47
jackdaniel
having something like muclr to be more useful would require global environments I can imagine
10:21:23
jackdaniel
just like you have separation for users in database but you may import i.e table from another user
10:23:56
nydel
i hear that. in my mind this far i've been thinking that each user has different permissions. so one might submit a bunch of forms for evaluation, but the creator of the shared-instance (or one of their aproved people) has to sign off on the submitted forms before they are evaluated in the shared interpreter.
10:24:18
nydel
and of course each user will also have their own local REPL separate from the shared -- that is the client, part of which i write as the REPL-UI package now.
10:24:39
nydel
i.e. i hope users can connect to a MUCLR server directly from SLIME by using muclr-client. but i haven't written all of that yet.
10:30:47
ogamita
nydel: did you experiment with other REPL features than the classic REPL we find in CL implementations?
10:31:32
nydel
ogamita: i think the answer is probably no, because i can't think of a much different way to build or imagine an REPL
10:31:58
nydel
if you have anything/s in mind i would appreciate being pointed at things of which i'm ignorant
10:33:06
ogamita
Well, there could be something about multiple threads and I/O. allegro does something about it, but only in the debugger IIRC.
10:34:03
ogamita
In slime, there's the "presentations", ie. printing a lisp object in the REPL inserts there a link to inspect the object (could also have a popup menu associated to each presentation to manipilate it).
10:34:25
nydel
the threading has been a bit of a nightmare. the package relies so heavily on bordeaux-threads to keep all the connections separate, each thread a socket and an object attaching various other things to that socket.
10:34:39
ogamita
Something nice would be multimedia: if you print an image object, it would display it, if you print a sound object it would let you hear it, etc.
10:35:05
nydel
ogamita: oh that is such a great series of ideas. i wonder whether i could accomplish such things with pure CL or if emacs lisp would be needed
10:35:07
ogamita
Ie, in addition to print-object, we could have a render-object method to show multimedia objects in the repl.
10:36:07
ogamita
Idealy, the UI would have a front-end and a back-end, and you could use the same back-end with all the target front-end.
10:36:51
nydel
yes, i need a spec. a universal API to handle all the common types of requests that could happen between client & server, server & clients.
10:38:10
ogamita
So, something about input methods could be done, to let you input easily lisp code and data, from other devices than a keyboard (touch screen, microphones, camera (real gesture recognition ;-)).
10:39:42
nydel
i'd like, at first anyhow, for MUCLR to assume for a terminal-only environment. i hope it could be of use to public access unix users who are trying to either share an interpreter with a peer or learn from a mentor etc
10:39:52
ogamita
For example, a smart "abbrev" system that would let you dictate or type on an tablet easily, by smart guessing what is wanted depending on the state of the lisp image (the existing packages and symbols, etc). Ie. more guessing the meaning of the programmer, and generating the sexp he wants.
10:41:02
nydel
huh/hmm. i am really open to these ideas. it would be such a one-two punch if commonlisp could be made multiuser AND smart-device compatible simultaneously
10:41:22
ogamita
nydel: ah good. In this case, "screen sharing" would be great. You'd want to allow the mentor see all the screens of his students, and students could also share their screen between themselves. Both read-only and read-write. And possibly also, letting one user cl:inspect the image of the other.
10:43:04
nydel
yes, strong yes's to all that! i can write most of the sharing easily, but i wonder how easy it will be to make mobile-compatible versions for on-the-go lisp hackers. should an "app" or a mobile web implementation (open source and federated) be best
10:44:56
ogamita
Well, of course, it's complicated. Neither Android nor iOS are easy for us. On Android, the UI or at least the "main" function must be written in Java anyways. On iOS, there are a lot of security restrictions, (and UI is better written in Objective-C than in C, even if it would be possible to use only C (FFI)). (or Kotlin and Swift).
10:45:32
ogamita
On the other hand, on Android it's possible and probably a good choice, given the constraints.
10:46:22
nydel
LdBeth: i think you're in denial. give yourself permission to admit how much you miss chinese food.
10:46:35
ogamita
nydel: it seems clear that the easy way is to put the UI on Android and iOS, and the CL image on a server, but this implies on-line work only, and more difficult communications between the lisp image and the UI.
10:47:51
nydel
ogamita: i had planned for -- if people want to use it mobile-style -- they can ssh to SDF or some pubnix and connect using an emacs/slime & :MUCLR-CLIENT
10:49:57
ogamita
nydel: yes, for now, it should be sufficient. But this doesn't address the specific UI problem of mobile. Terminal emulations are good, but you really want a physical keyboard connected to the mobile to do any serious work. (and then, it works well enough, ergonomically).
10:51:27
nydel
ogamita: may i ask what sort of work you do for a living (or for whatever) ... you're very admirably-skilled at brainstorming on the line between inside-box and outside-outer-space & i wonder the reason why
10:53:53
ogamita
I'm a free-lance developer. I can write programs for macOSX, iOS, Android, Linux. Currently I'm working on integrating Smartcard Login on FreeRDP for a customer. Next year, I'm starting a company to develop IA software.
11:00:26
nydel
"probably more for #lispcafe" is such a polite way to tell someone they're boring you