<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
<phoe>
permagreen: SPLIT-SEQUENCE is famous for being the kind-of LEFT-PAD of Lisp.
<verisimilitude>
JavaScript idiots pulled in a library for padding a string, permagreen.
<verisimilitude>
It caused a mess when it was pulled from a repository and thousands of programs broke.
<permagreen>
Ooh, that does sound silly
<verisimilitude>
In JavaScript, it's normal to have thousands of dependencies, apparently.
<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
<verisimilitude>
Here's leftpad in Common Lisp: (FORMATTER "~V@A")
<aeth>
s/into the browser/into the JS to feed to the browser/
<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
<aeth>
(well, not *my* implementation, but the same approach that I used there)
<phoe>
aeth: do open an issue there
<aeth>
Any sequence function needs to be written like this (etypecase sequence (list (%list-version sequence)) (sequence (%vector-version sequence)))
<phoe>
it could be worthy writing a specialized list version of that
<aeth>
(you do sequence, not vector, in case the implementation has extensible sequences. It's better to have slow support than no support)
<verisimilitude>
You could always use a generic function, instead.
<aeth>
verisimilitude: no
<verisimilitude>
Why not?
Lycurgus has joined #lisp
<aeth>
Only use generics when they need to be used.
<phoe>
the way in which you dispatch doesn't really matter here - if it's generic dispatch or typecase dispatch
<Xach>
like when it is cool
<aeth>
It's easy to wrap a function with defmethod if you want to. It's a higher level interface.
<verisimilitude>
Making code that provides an interface which needs to behave differently based on the class of object isn't appropriate?
<verisimilitude>
Why would that be the case, aeth?
<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
<phoe>
so, basically, speed
<verisimilitude>
An implementation doesn't need to inline if it doesn't want to, anyway.
<phoe>
Also when your interface is not exposed to the outside world and therefore fully internal.
<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)
<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.
<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
<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
<aeth>
Everyone will disagree where to draw the line, though
<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)
Bike has joined #lisp
<verisimilitude>
I don't really see much opportunity to use CLOS is part of why I'd try to reach for it, I suppose.
<verisimilitude>
I have a program planned that should benefit from it, but I just avoid using it for almost everything.
ralt has quit [Remote host closed the connection]
<aeth>
verisimilitude: Well, it's also if you expect the user to extend it or not
<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.
mrcom has joined #lisp
<aeth>
But if you're writing for your own class you can't possibily anticipate what the user could add
<aeth>
*possibly
<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?
Rudolph has joined #lisp
ah_ has joined #lisp
ah_ is now known as akoana
<no-defun-allowed>
sbcl exports a way to hook into the sequence interface, do other implementations do that?
<Xach>
no-defun-allowed: no
<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.
<no-defun-allowed>
that's a shame
<aeth>
verisimilitude: So you'd need a more robust implementation for that to work as it does now without hurting performance
<Bike>
i think abcl does it? not sure
<Xach>
no-defun-allowed: I get the impression that few use the capability
<no-defun-allowed>
that's fair but it does sound like there's use cases for it
<aeth>
Kind of an oversight imo that this sort of behavior isn't even standard or as optimized as it could be.
<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.
<aeth>
Xach: It's a chicken and egg situation. Why use something that only works in SBCL?
<aeth>
Every library should, at a minimum, work on SBCL, CCL, and ECL imo.
<Bike>
also the protocol is kind of weird. like you return a bunch of functions as values for some reason
<Xach>
aeth: because sbcl is awesome and making your life easier is also cool
<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.
<aeth>
(because sometimes it's easier to just take something to 200 digits and then round the result)
<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.
Rawriful has joined #lisp
Rudolph has quit [Ping timeout: 250 seconds]
anewuser has quit [Ping timeout: 240 seconds]
anewuser has joined #lisp
elfmacs has joined #lisp
robotoad has joined #lisp
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
elfmacs has quit [Quit: WeeChat 2.3]
anewuser has quit [Ping timeout: 268 seconds]
Rudolph has joined #lisp
anewuser has joined #lisp
<stylewarning>
aeth: a portable MPFR would be nice
<stylewarning>
(with a nice API)
<stylewarning>
computable-reals is sufficient to get small jobs done (:
anewuser has quit [Ping timeout: 268 seconds]
Rudolph has quit [Ping timeout: 250 seconds]
Rawriful has quit [Quit: WeeChat 1.4]
Essadon has quit [Quit: Qutting]
stardiviner has joined #lisp
robotoad has quit [Ping timeout: 240 seconds]
robotoad has joined #lisp
Rudolph has joined #lisp
eminhi_ is now known as eminhi
shifty has joined #lisp
makomo has quit [Ping timeout: 244 seconds]
robotoad has quit [Ping timeout: 245 seconds]
robotoad has joined #lisp
mrcom has quit [Read error: Connection reset by peer]
clintm has joined #lisp
Rudolph has quit [Ping timeout: 240 seconds]
anewuser has joined #lisp
<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.
<clintm>
err, why 10 is an index out of bounds, rather.
<Bike>
because they are zero indexed?
anewuser has quit [Ping timeout: 246 seconds]
<clintm>
I see my confusion. For some inconceiveable reason, I was thinking dotimes starts a 1
Rudolph has joined #lisp
mrcom has joined #lisp
anewuser has joined #lisp
vtomole has joined #lisp
eminhi has quit [Ping timeout: 250 seconds]
robotoad has quit [Quit: robotoad]
milanj has quit [Quit: This computer has gone to sleep]
robotoad has joined #lisp
rnmhdn has joined #lisp
hectorhonn has joined #lisp
<hectorhonn>
morning everyone
psqueak has joined #lisp
smokeink has joined #lisp
jochens has joined #lisp
Lord_of_Life has quit [Ping timeout: 250 seconds]
Lord_of_Life has joined #lisp
jochens has quit [Ping timeout: 246 seconds]
charh has quit [Remote host closed the connection]
space_otter has joined #lisp
psqueak has quit [Remote host closed the connection]
clintm has quit [Remote host closed the connection]
clintm has joined #lisp
dacoda has joined #lisp
anewuser has quit [Ping timeout: 250 seconds]
Bike has quit [Quit: Lost terminal]
elderK has quit [Quit: WeeChat 1.9]
smokeink has quit [Ping timeout: 246 seconds]
<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
smokeink has joined #lisp
pjb has quit [Ping timeout: 252 seconds]
debsan has quit [Ping timeout: 250 seconds]
rnmhdn has quit [Ping timeout: 240 seconds]
smokeink has quit [Ping timeout: 246 seconds]
aindilis has joined #lisp
smokeink has joined #lisp
dale has joined #lisp
debsan has joined #lisp
<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?
lemoinem has quit [Ping timeout: 240 seconds]
lemoinem has joined #lisp
ealfonso has quit [Disconnected by services]
dale has quit [Quit: dale]
vtomole has quit [Quit: Page closed]
pjb has joined #lisp
dacoda has quit [Ping timeout: 250 seconds]
smokeink has quit [Ping timeout: 246 seconds]
smokeink has joined #lisp
luhuaei has quit [Remote host closed the connection]
luhuaei has joined #lisp
Lycurgus has quit [Quit: Exeunt]
luhuaei has quit [Remote host closed the connection]
ealfonso has joined #lisp
<ealfonso>
I am considering using Puppeteer but was wondering if someone knows of an equivalent library in CL?
<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
<jackdaniel>
you may configure your server to have these files behind ssl
<nydel>
oh i see, there are no certificates at all for the domain (at least its www or blank hostnames)
<jackdaniel>
exactly
<nydel>
jackdaniel: i think http ssl is really important, do you disagree, or have you simply not gotten around to it?
robdog has quit [Remote host closed the connection]
<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.
robdog has joined #lisp
<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.
<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
<jackdaniel>
if you have user sessions ssl is a must, I can't disagree with that. is this project hosted somewhere?
<nydel>
yes, github user nydel, project muclr -- or search for "nydel muclr"
<jackdaniel>
thank you
<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.
<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)
<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.
pjb has joined #lisp
hhdave has joined #lisp
<jackdaniel>
having something like muclr to be more useful would require global environments I can imagine
akoana has left #lisp ["Leaving"]
<jackdaniel>
just like you have separation for users in database but you may import i.e table from another user
hhdave_ has joined #lisp
<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.
<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.
<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.
hhdave has quit [Ping timeout: 272 seconds]
hhdave_ is now known as hhdave
Rudolph has quit [Ping timeout: 246 seconds]
<ogamita>
nydel: did you experiment with other REPL features than the classic REPL we find in CL implementations?
<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
<nydel>
if you have anything/s in mind i would appreciate being pointed at things of which i'm ignorant
<ogamita>
Well, there could be something about multiple threads and I/O. allegro does something about it, but only in the debugger IIRC.
mingus has joined #lisp
<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).
<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.
<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.
<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
<ogamita>
Ie, in addition to print-object, we could have a render-object method to show multimedia objects in the repl.
<ogamita>
You can use emacs to implement the UI, or McCLIM or something else.
<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.
<ogamita>
(a front-end for Hemlock in Clozure CL.app would be nice too).
<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.
<ogamita>
Perhaps a speech REPL, both listening and speaking.
<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 ;-)).
<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
<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.
<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
<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.
<ogamita>
Just take note, and you'll see what you can do; I'm just brainstorming here.
hectorhonn has quit [Quit: Page closed]
<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
<LdBeth>
Good evening
<shka_>
LdBeth: hello
<nydel>
(( LdBeth )) !!
<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).
<ogamita>
For example, on iOS, you cannot fork a child!
<ogamita>
On the other hand, on Android it's possible and probably a good choice, given the constraints.
<LdBeth>
Just back to China, tired, and found I don’t miss Chinese food that much
<LdBeth>
Hi shka_ nydel
<nydel>
LdBeth: i think you're in denial. give yourself permission to admit how much you miss chinese food.
<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.
<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
Rudolph has joined #lisp
<LdBeth>
nydel: Thanks for your advice
<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).
<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
pjb has quit [Ping timeout: 252 seconds]
Rudolph has quit [Ping timeout: 250 seconds]
<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.
<nydel>
may i assume you mean AI or is IA a different field
<ogamita>
And I've been a lisper since 1996.
<ogamita>
yes, AI. IA = French AI.
<nydel>
is AI a threat to mankind? short answer.
<White_Flame>
mankind is a threat to mankind, no matter the tool
<kayront>
<ogamita> yes, AI. IA = French AI
gxt has joined #lisp
<kayront>
does it come with 60% tax?
<kayront>
:p
<nydel>
White_Flame: isn't mankind the tool? i think the planet is "people-ing" y'know?
JohnMS_WORK has joined #lisp
<White_Flame>
probably more for #lispcafe
<jackdaniel>
homo homini ai :-)
<nydel>
"probably more for #lispcafe" is such a polite way to tell someone they're boring you
mingus has quit [Remote host closed the connection]
<White_Flame>
no, just offtopicness
pierpal has quit [Read error: Connection reset by peer]
Zaab1t has joined #lisp
cage_ has joined #lisp
Rudolph has joined #lisp
gxt has quit [Quit: WeeChat 2.3]
kajo has joined #lisp
cage_ has quit [Read error: Connection reset by peer]
resttime has quit [Ping timeout: 272 seconds]
cage_ has joined #lisp
<LdBeth>
Go sleep, see you all
wigust- has joined #lisp
wigust has quit [Ping timeout: 272 seconds]
cage_ has quit [Read error: Connection reset by peer]
cage_ has joined #lisp
pjb has joined #lisp
akanouras has joined #lisp
Rudolph has quit [Ping timeout: 272 seconds]
Josh_2 has joined #lisp
<dim>
kayront: it's not tax, it's social contributions, but anyway
cage_ has quit [Read error: Connection reset by peer]
<ogamita>
kayront: yes, and no private data to process :-)
milanj has quit [Quit: This computer has gone to sleep]
jmercouris has joined #lisp
<jmercouris>
can someone please remind me where the cache is located?
<jmercouris>
and how to clear it?
<jmercouris>
I can't recall from me the dir
<jmercouris>
s/from me/for the life of me
<jmercouris>
what is happening to my english...
<jdz>
~/.cache/common-lisp
<jmercouris>
I can safely delete the whole dir right?
<jdz>
SLIME has its own cache at ~/.slime
<jmercouris>
should I also delete that?
<jmercouris>
I assume its the dir titled "fasl"
<jdz>
It depends on what you want to achieve, but sure.
<jmercouris>
well, I have this one macro in my project
<jmercouris>
that never ever seems to want to update..
<pfdietz>
You could just build a new version of your lisp and it gets its own fresh slice of the cache. :)
<jmercouris>
and I always have to clear the cache for things to work
<jmercouris>
build a new version of your lisp?
<pfdietz>
That might mean you're missing a dependency somewhere.
<jmercouris>
I have all dependencies
<jmercouris>
I quickloaded the system
kushal has quit [Remote host closed the connection]
<jmercouris>
clearing the cache indeed fixed the problem
kushal has joined #lisp
<jmercouris>
I also emptied the fasls folder in slime
<jmercouris>
one thing that has annoyed me for months is this
<pfdietz>
If you build a new SBCL, with changes from previous, it will give it a new (lisp-implementation-version), which will go into a fresh subdirectory under .cache/common-lisp
<jmercouris>
every single time I load my system
<jmercouris>
; compilation unit finished ; caught 8 STYLE-WARNING conditions
<jmercouris>
I think it is because I depend on swank, because I ship swank with my system
<jdz>
Pretty sure it's not Swank related.
<jmercouris>
jdz: what do you think its related to?
<jmercouris>
it only happens when loading this system
<jmercouris>
no others
<jdz>
I have not seen any variables named $1 or $2 when compiling my code. Probably the result of one of those lambda-shortening macros.
<jmercouris>
lambda-shortening macross?
gxt has joined #lisp
<jdz>
I don't know. You are the one compiling the code, you should know where they come from.
<jmercouris>
you are saying I have lambda shortening macros
<jmercouris>
I am asking, what are those?
<pfdietz>
Things like { ... } reader macros, I'm guessing.
<jmercouris>
I have no reader macros
<jmercouris>
unless a dependency I pull in has them
<jdz>
Or maybe cl-string-match (just guessing).
<jdz>
That's the deal with dependencies.
<jmercouris>
yes :(
<pfdietz>
src/pre.lisp in cl-string-match
<jmercouris>
pfdietz: how did you know?
<pfdietz>
"The variable $1 is defined but never used."
<jmercouris>
so that I can know how to do what you did in the future
<jackdaniel>
grep-fu is strong
<jmercouris>
did you quickload each dependency independently to see if they would emit warnings?
<pfdietz>
I have cl-string-match here, and I used the magic of grep... like he said. Confirmed with (ql:quickload "cl-string-match" :verbose t) (which gives me 38 style warnings, btw).
<jackdaniel>
grep -rn "my error" ~/quicklisp/dists/quicklisp ; is the most effective silly way to find where warning comes from
<jmercouris>
wait a second, why would the error be contained within the dist?
<jmercouris>
are the compilation messages persisted in a text file?
stardiviner has quit [Ping timeout: 245 seconds]
* jackdaniel
sights. in dists directory you have sources of your depenencies
robdog has quit [Remote host closed the connection]
<jackdaniel>
if you observe some text message it is probably somewhere in the source tree
eminhi has joined #lisp
<jackdaniel>
so grepping for the message (carefully, message may have i.e ~A and not the literal you see) is a good heuristic
<jmercouris>
I see okay
<jmercouris>
so you can't LITERALLY grep for the message
<jackdaniel>
if you keep your dependencies somewhere else then grep in there
<jmercouris>
just wanted to make sure there wasn't something huge I was missing
<jmercouris>
ok, then my follow up question, anyone have any suggestions to replace cl-string-match?
<jmercouris>
cl-ppcre?
<pfdietz>
Oh man, cl-string-match needs some (DECLARE (IGNORE ...))
<jmercouris>
anything else preferred?
<jdz>
pfdietz: Or at least IGNORABLE.
<jdz>
OK, looking at the code I see the code itself uses $x as variable names :/
<jmercouris>
yes, I'm getting the impression that cl-string-match is not a well taken care of lib
<jmercouris>
or perhaps even well written, I wish to replace it, so any suggestions?
<jackdaniel>
from the library name I can guess it may be replaced by cl-ppcre
<jmercouris>
ok, cl-ppcre it is
<jmercouris>
thank you
<jackdaniel>
or, if you are looking for pattern matching with optima (eventually trivia)
<jackdaniel>
keep in mind that I don't know what cl-string-match does, only guessing
<jmercouris>
well there were some other interesting things it had in addition to regex, but I'm not using those
<jmercouris>
so cl-ppcre should suffice for now
<pfdietz>
If you want to push up changes, I've forked a copy of it on github (added a new algorithm I needed).
<jmercouris>
and maybe when I wish to do those interesting things I may wish to implement them myself..
<beach>
jmercouris: I tried your browser. Looks nice!
<jmercouris>
actually yes, hash-table-count is what I was looking for
<jmercouris>
I should have checked the hyper spec instead of my blind faith :D
<jmercouris>
the size may be greater than the count, and what I want is really the count
<shka_>
jmercouris: worry not, i also tripped on this
<pfdietz>
I pushed a change to my copy of cl-string-match that gets rid of the style warnings (and fixes two tests).
<pfdietz>
Er, on the branch
<jmercouris>
pfdietz: maybe I will just suck it up and make my own ql dist...
<jmercouris>
I'm thinking about the convenience for users to have to clone your version to compile from source
<jmercouris>
that's what gets me
<pfdietz>
If you need control you should do that.
<pfdietz>
The QL model with someone elses' dist is not really compatible with good configuration management.
<jmercouris>
yeah
atgreen__ has joined #lisp
robdog has joined #lisp
<jmercouris>
shka_: that makes me feel a bit better :D
<jmercouris>
here's another thing I am thinking about, interested in thoughts
<jmercouris>
so I would like to make a package manager for Next
<jmercouris>
I am thinking, why not just use quicklisp? and have a custom dist only with systems designed to work with next?
<jmercouris>
seems like a simple solution, no?
<jmercouris>
the idea being creating so mething like elpa/melpa for Next
Lycurgus has quit [Quit: Exeunt]
<ogamita>
quicklisp is quite dangerous, when you start to develop seriously. Imagine, you use a dozen libraries, and next month you update quicklisp, and half of them are removed from the distribution!
<ogamita>
There's quite some prunning occuring each month (I'm not saying it's unjustified, but if you depend on those libraries, you won't be happy).
<jmercouris>
yes, I see the point there
Rudolph has joined #lisp
<shka_>
jmercouris: it is fine as long as you have restricted dist
<shka_>
IMHO
Bike has joined #lisp
robdog has quit [Remote host closed the connection]
themsay has joined #lisp
themsay has quit [Read error: Connection reset by peer]
themsay has joined #lisp
<pfdietz>
Things get pruned when they stop working, so if you depended on them and they're removed, you'd probably be in trouble regardless.
eminhi has quit [Ping timeout: 250 seconds]
<ogamita>
pfdietz: they stop working ON SBCL! You may be using another implementation.
kajo has quit [Ping timeout: 250 seconds]
nicksmaddog has joined #lisp
<beach>
Where in the Common Lisp HyperSpec does it say that a DEFMETHOD form is evaluated in the normal lexical environment, as opposed to the null lexical environment?
<Bike>
i don't know if it's explicitly stated.
<beach>
Ah, I found it in the MOP.
<Bike>
oh well yeah it's in there.
<Bike>
some discussion about it as i remember, since it's why make-method-lambda is so weird
<beach>
Yes, well, we are writing a paper about MAKE-METHOD-LAMBDA and I want to get things right.
<Bike>
makes sense.
<Bike>
is this the one that's a reply to "make-method-lambda considered harmful"?
<beach>
Yeah.
<beach>
Hmm, now that I re-read the phrase, I don't think it says what I thought it said...
<ogamita>
that's a good question. Who said it methods are closures? They're not AFAIK.
<Bike>
yeah they are.
<beach>
We think they are.
<ogamita>
Implementations indeed do it, but I don't see it specified. I guess, they don't use make-method in defmethod or defgeneric…
atgreen__ has quit [Remote host closed the connection]
<Bike>
it's in mop.
<ogamita>
Ok.
atgreen__ has joined #lisp
<Bike>
also, if normal evaluation rules were bypassed i'd expect there to be a note
<beach>
Yes, you are right.
<ogamita>
Yes but it's inconsistent with make-method which specifies the NIL environment.
<ogamita>
(but I agree, it's nice that methods defined by defmethod and defgeneric be closures).
<beach>
Where do you see that?
<Bike>
make-method is used in a completely different context.
<ogamita>
Yes.
<Bike>
beach: the make-method clhs page.
<beach>
I see.
<Bike>
we talked about it before because it is pretty weird.
<beach>
There is an inconsistency though.
<Bike>
with what?
<ogamita>
"The form used with make-method is evaluated in the null lexical environment augmented with a local macro definition for call-method and with bindings named by symbols not accessible from the COMMON-LISP-USER package."
<beach>
ogamita: Yes, but it can have closures as arguments.
<Bike>
but the form used with make-method is a part of the result of compute-effective-method. it doesn't have a method body in it.
<Bike>
that's what i meant by different context.
<beach>
Yes, it's not the same.
<ogamita>
I don't know enough CLOS and MOP. Pascal Costanza could probably tell more.
shifty has joined #lisp
<beach>
Heh, it is his and Herzeel's paper that we are going to write about.
<beach>
It suggests that COMPILE can be used on the lambda expression.
<Bike>
that make-method-lambda description also redefines how call-method and sort of how make-method works but doesn't have enough detail
<ogamita>
he he!
<Bike>
i don't like make-method-lambda's description
<Bike>
and not it itself either, really
<ogamita>
function would be better indeed. Even coerce doesn't make a closure.
<beach>
Bike: Maybe after you read our paper, you will like it better.
<Bike>
maybe
<beach>
Look at the description of the first argument GENERIC-FUNCTION.
<beach>
It says, The generic function and method the method function will be used with are not required to be the given ones.
<beach>
So, what can MAKE-METHOD-LAMBDA do with the first argument?
<Bike>
nothing, i thought? it's just for specialization.
<Bike>
or basically nothing
milanj has joined #lisp
<beach>
Exactly.
<beach>
So, we can use the class prototype for that as well as for the method argument.
<Bike>
yeah, ecl and clasp incorporated that, which removes one of the objections in costanza's paper
<Bike>
sbcl has it too i think
<beach>
Yes, I believe SBCL uses the prototype.
<beach>
The other objection is that the method-class must be known so the generic function must be known, or else a method of the wrong class will be created.
<beach>
But the compiler could save the :method-class argument to DEFGENERIC just as it might save the lambda list, without creating the generic function.
<beach>
Then, make-method-lambda can be passed the class prototype of that class.
<Bike>
hm, don't think i implemented that much
<beach>
But you see what I mean, right?
<Bike>
Yeah
<beach>
That's the essence of our paper.
<Bike>
that makes sense.
LiamH has joined #lisp
sjl_ has joined #lisp
rnmhdn has joined #lisp
jmercouris has quit [Remote host closed the connection]
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.2)]
<ogamita>
hi
Denommus has quit [Ping timeout: 244 seconds]
rnmhdn has quit [Ping timeout: 246 seconds]
kajo has joined #lisp
edgar-rft has quit [Quit: Leaving]
rnmhdn has joined #lisp
scymtym has quit [Ping timeout: 268 seconds]
Denommus has joined #lisp
ebrasca has quit [Read error: No route to host]
robotoad has joined #lisp
jochens_ has quit [Remote host closed the connection]
scymtym has joined #lisp
jochens has joined #lisp
jochens has quit [Remote host closed the connection]
jochens has joined #lisp
nowhere_man has quit [Ping timeout: 252 seconds]
<nitrix>
(irc #freenode (privmsg #lisp "Hi!"))
<nitrix>
Look at me, already writing my first DSL :>
v0|d has joined #lisp
anewuser has quit [Ping timeout: 246 seconds]
ebrasca has joined #lisp
pjb has quit [Ping timeout: 252 seconds]
mrcom has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 246 seconds]
<verisimilitude>
If I were building an iOS or Android program for someone, I'd try to use mocl; the main issue is they're not so free with their documentation if you don't buy it, apparently, even if you ask nicely.
Zaab1t has joined #lisp
<clintm>
We inquired about using mocl for Android about three or four months ago and were told it had bitrotted. Let me see if I can find the email.
<verisimilitude>
I just wanted to look at its documentation for completeness' sake in a library I've written, but didn't even receive a response.
mrcom has joined #lisp
sindan has joined #lisp
<clintm>
Ok, so, sort of bitrotted. Constant changes to android studio, and the (lone?) developer now works at a full time job that doesn't involve mocl.
nicksmaddog has quit [Ping timeout: 250 seconds]
jmercouris has quit [Remote host closed the connection]
atgreen has quit [Ping timeout: 272 seconds]
<verisimilitude>
Alright.
anewuser has joined #lisp
orivej has joined #lisp
<Xach>
darn
<Xach>
selling cl tools always seems like a tough row to hoe, i was hoping mocl could make it work
<fe[nl]ix>
what happened ?
<fe[nl]ix>
oh I see
<verisimilitude>
Allegro and Lispworks still exist.
<jasom>
I just watched drmeister's LLVM talk. It's absurd how fast clasp has made progress.
<jasom>
I'm curious how LTO works with clasp, since lisp lacks anything quite like a link time
<jackdaniel>
just saying, but ECL also exists, works on android and you while it has some rought edges you are physically able to fix these because it is a foss software
<jackdaniel>
rough*
<Bike>
jasom: it links in functions written in C++, not other lisp functions
<Bike>
standard library stuff and intrinsics and things
khisanth__ has quit [Ping timeout: 250 seconds]
<verisimilitude>
I'm fortunately spared from iOS and Android development, but I'd use ECL or SBCL if I couldn't get the employer to buy mocl, yes.
jochens has quit [Remote host closed the connection]
<verisimilitude>
That does have me wondering, jackdaniel; mocl advertises its special declarations for linking to the native code well; does ECL have anything comparable to those?
<jackdaniel>
mocl is not a conforming common lisp implementation afaik
nowhere_man has joined #lisp
anewuser has quit [Ping timeout: 268 seconds]
<jackdaniel>
I don't know what are mocl's special declarations for linking, but ECL shares runtime with other C programs
terpri has joined #lisp
<jackdaniel>
so it may be linked to other program, compiled to shared and static library and such
hhdave has quit [Ping timeout: 250 seconds]
<verisimilitude>
I refer to the CALL-IN declaration.
<clintm>
jackdaniel: Do you happen to know of any projects that try to tie the android UI with ECL? I wouldn't expect it to be part of ECL itself, but I looked around when we were evaluating our options and didn't find much in the way of projects, examples, or the like that did anything with the UI.
<jackdaniel>
it doesn't have Apple's Xcode integration, but it allows defining lisp functions which are called like other C functions
jochens has quit [Ping timeout: 240 seconds]
<jackdaniel>
clintm: I wrote even a demo with ECL repl and swank
<jackdaniel>
EQL5-Android project developed it further and has great demos with user interface
<jackdaniel>
sudoku, repl and such
<clintm>
Oh yea, I think I messed with that on one of our test devices! It worked quite well, as I remember.
<clintm>
Ohh, right, is that the one that needs the specific version of the ndk? Not saying that's a problem or anything, it's just been three or four months since I was poking at this.
<clintm>
Looking...
<jackdaniel>
the one I wrote requied specific ndk version because the newer one had some bug, but it was around 2y ago, I would suspect it should work now
<jackdaniel>
and if not pull requests are welcome and source is available (if it is ecl fault)
<clintm>
Hrm, yea, I built and messed around with that. I may have to dig into it again - I can't remember why I passed on it.
<clintm>
Yea, right! I built the skoban and repl examples, installed and ran them and they worked as advertised as I remember. Ok, now I'm really curious. Time to shave some yaks and set it up again.
<jackdaniel>
the most notable drawback with ECL on android is that usually you are forced to use bytecompiler at runtime (nothing technical, devices just usually doesn't have gcc), but you may load precompiled libraries
atgreen has joined #lisp
<jackdaniel>
and the second drawback is generic function dispatch performance. we plan to address that after upcoming release
<clintm>
I don't remmeber that being a problem, but I also don't remember doing anything special because of it.
<jackdaniel>
but it is not android-specific
ebrasca has quit [Remote host closed the connection]
pjb has joined #lisp
orivej has quit [Ping timeout: 245 seconds]
<jasom>
also GF performance is kind of mediocre everywhere
<Bike>
GF?
<jackdaniel>
we know how to improve it (thanks to beach papers and clasp team experimentation)
anewuser has joined #lisp
<Bike>
generic function. yeah you'd better use all this shit i've been doing
<jackdaniel>
I'd say drmeister, but there are more developers who do teremendous job with it (for instance Bike)
<jackdaniel>
but first we need to push 16.2.0 out of the door
<jackdaniel>
first thing after that I will bore you with questions :)
frgo has quit [Remote host closed the connection]
nowhere_man has quit [Ping timeout: 245 seconds]
gxt has joined #lisp
<Bike>
i can sometimes inline effective methods now, so that's nice
<drmeister>
Howdy ho neighbors
pjb has quit [Remote host closed the connection]
<Bike>
i'd like to see about inlining method bodies themselves so it's like a real jit, but that's a lot of work
<drmeister>
Yeah - it's not all me anymore. Bike is doing a tremendous amount - Cleavir was written by beach. kpoeck has been fixing lots of bugs. The list goes on.
pjb has joined #lisp
<Bike>
i guess rather than full method bodies it's accessors really, or maybe gfs more generally
<Bike>
could just patch rather than doing full recompiles... would be neat
Lycurgus has quit [Quit: Exeunt]
<Bike>
it would be pretty cool for accessor calls within methods to be turned into inline memorhy accesses
another-user has joined #lisp
<another-user>
hi, is it possible to collect unique items using loop?
Necktwi has quit [Remote host closed the connection]
<pfdietz>
You can remove duplicates after you collect the list.
<Bike>
or pushnew to an accumulator list rather than using hte 'collect'
<another-user>
Bike: right, thanks!
<pfdietz>
remove-duplicates is likely to be more efficient, for large lists.
<another-user>
pfdietz: noted, thank you
m00natic has quit [Remote host closed the connection]
irdr has joined #lisp
<drmeister>
I got (ql:quickload "babel") to work with compile-file-parallel.
<Bike>
#clasp?
makomo has quit [Quit: WeeChat 2.2]
frgo has joined #lisp
mooch2 has joined #lisp
anewuser has quit [Ping timeout: 250 seconds]
frgo has quit [Ping timeout: 250 seconds]
<another-user>
is it possible to collect string with loop?
<pfdietz>
another-user: that is, if you're using one the standard equality functions (eq, eql, equal, equalp), so it can build a hash table for membership testing.
<pfdietz>
Collect INTO a string?
<another-user>
pfdietz: yeah, i would like to get "012" from (loop for i from 0 to 2 collect (format nil "~a" i))
<verisimilitude>
The first thing that comes to mind is collecting into a list and then using COERCE, another-user.
<pfdietz>
Not directly, but you can set up an extensible character vector with a fill pointer and use vector-push-extend.
<another-user>
got it, thanks!
<pfdietz>
You could also use a fancy format string in that case.
<verisimilitude>
You'd need to collect characters if you want to COERCE, note.
<pjb>
another-user: (coerce (loop for i from 65 to 74 collect (code-char i)) 'string) #| --> "ABCDEFGHIJ" |#
<pjb>
another-user: but actually: (with-output-to-string (out) (loop for i from 65 to 74 do (write-char (code-char i) out))) #| --> "ABCDEFGHIJ" |#
<another-user>
with-output-to-string is what i need, thank you!
<pjb>
another-user: or: (with-output-to-string (out) (loop for i from 65 to 74 do (format out "~D " i))) #| --> "65 66 67 68 69 70 71 72 73 74 " |#
<verisimilitude>
I always use *STANDARD-OUTPUT* as the symbol bound with these types of macros.
<verisimilitude>
Or, rather, I usually do.
<pjb>
If you do a single collection at a time, yes. But giving another name let you collect several strings at once.
<verisimilitude>
Then you don't introduce an unnecessary symbol into the system and you can type less.
<verisimilitude>
I've yet to run into a nesting situation such as that, pjb, but that would be an example of when not to necessarily do it, yes.
scymtym has quit [Ping timeout: 268 seconds]
<pjb>
(block nil (with-output-to-string (odd) (return (values (with-output-to-string (even) (loop for i from 65 to 74 do (write-char (code-char i) (if (oddp i) odd even)))) (get-output-stream-string odd))))) #| --> "BDFHJ" ; "ACEGI" |#
rnmhdn has quit [Ping timeout: 250 seconds]
atgreen has quit [Ping timeout: 250 seconds]
seok has joined #lisp
<seok>
Hi friends!
<seok>
What is everyone building at the moment?
edgar-rft has joined #lisp
anewuser has joined #lisp
<jackdaniel>
babel tower
<Xach>
webserver that returns only errors
<verisimilitude>
I suppose I may work more on my ACUTE-TERMINAL-CONTROL and clean my CL-ECMA-48 of unnecessary symbols a tad before the year's end, seok.
<Bike>
compiler that outputs only code that returns only errors
Denommus has quit [Ping timeout: 268 seconds]
varjag has joined #lisp
<drmeister>
Does anyone have tips on finding threading contention? macOS or linux.
anewuser has quit [Ping timeout: 268 seconds]
<drmeister>
I'm implementing compile-file-parallel - it compiles AST's in serial and then tosses the AST->native code compilation into threads. I'm seeing contention and so I'm exploring ideas on how to track down the source and fix it.
<drmeister>
I'm using pthreads in C++ exposed to Common Lisp so dtrace is an option.
<drmeister>
Clasp's stacks are pretty deep and we blow through the bullsh*t 512 frame limit of Xcode's Instruments - what a load!
shifty has quit [Ping timeout: 240 seconds]
yvy has joined #lisp
dmiles has quit [Read error: Connection reset by peer]
scymtym has joined #lisp
v0|d has quit [Ping timeout: 250 seconds]
khrbt has joined #lisp
themsay has quit [Ping timeout: 250 seconds]
dmiles has joined #lisp
Zaab1t has quit [Quit: bye bye friends]
makomo has joined #lisp
milanj has quit [Quit: This computer has gone to sleep]
jlarocco has joined #lisp
vlatkoB has quit [Remote host closed the connection]
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
gxt has quit [Ping timeout: 268 seconds]
atgreen has joined #lisp
another-user has quit [Remote host closed the connection]
milanj has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
yvy has quit [Read error: Connection reset by peer]
frgo has joined #lisp
<jasom>
drmeister: a statistical profiler should show it right away
<jasom>
it won't show you directly, but you should see threads spending a lot of time in lock acquisition
<jasom>
if you don't have a good one, just break all threads into the debugger randomly a dozen times and see what locks are contended (if contention is more than half the problem, you should see 5 or more of the same lock contended)
<drmeister>
Would this suggest that I don't have a contention problem?
gxt has joined #lisp
<drmeister>
I have dtrace - it's not a problem.
<jasom>
drmeister: not easy to tell from that graph; depending on the lock implementation you get very different CPU profiles for contention
<drmeister>
I think might have an Amdahl's law problem.
<jasom>
e.g. some userspace mutexes will spin a few times before blocking, others will always do a syscall even in the non-contended case
<drmeister>
I'll take a close look at the backtraces.
gendl has joined #lisp
<jasom>
shouldn't need to look at backtraces; the lock acquisition code should be on the top of the stack when waiting
<drmeister>
I mean when I use dtrace I get lots of backtraces and the lock acquisition should be at the top of the stack in many of them.
* jasom
nods
orivej has joined #lisp
kajo has quit [Ping timeout: 252 seconds]
nowhere_man has joined #lisp
yvy has joined #lisp
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]
Lycurgus has joined #lisp
kajo has joined #lisp
eminhi has joined #lisp
nowhere_man has quit [Ping timeout: 252 seconds]
themsay has joined #lisp
sjl_ has quit [Ping timeout: 240 seconds]
Bike has quit []
themsay has quit [Ping timeout: 244 seconds]
orivej has quit [Ping timeout: 268 seconds]
yvy has quit [Ping timeout: 245 seconds]
orivej has joined #lisp
marusich has quit [Remote host closed the connection]
themsay has joined #lisp
themsay has quit [Remote host closed the connection]
kajo has quit [Ping timeout: 250 seconds]
varjag has quit [Remote host closed the connection]