freenode/#lisp - IRC Chatlog
Search
15:40:03
gendl
it returns multiple values, apparently an offset in seconds then an incremental value in milliseconds
15:41:04
gendl
They've added this microtime stuff to AllegroServe - I'm trying to resolve latest AllegroServe with zacl
15:42:45
dim
is there a way to edit-in-place list elements when looping through them? I think I forgot how to do that with for/on/by cddr and setf
15:43:50
Josh_2
"Produces a timestamp instance with the current time. Under sbcl, the new timestamp will be precise to the microsecond. Otherwise, the precision is limited to the second."
15:43:57
_death
dim: if you use ON then you have the cons, so you can alter its car.. but maybe you actually want MAP-INTO
15:46:04
gendl
and zacl is currently supported on SBCL and CCL, so ideally I would need an equivalent in CCL too.
15:50:02
_death
my monotonic-clock library uses clock_gettime (on linux).. on my system the unit of time is nanoseconds
15:50:58
_death
(well, that's actually part of clock_gettime's interface.. the resolution of course may be different)
16:23:23
gendl
(local-time:now) seems to be returning microseconds on CCL and SBCL on Windows as well (despite the documentation saying microseconds only works on POSIX systems and only on SBCL)
16:24:14
gendl
Well, i'm running these in a cygwin shell - maybe i'm getting a false positive here...
16:30:08
gendl
only difference on Windows is the timestamps are coming back in Zulu time, like @2018-10-16T16:27:42.833074Z
16:31:10
gendl
But that might just be my Windows configuration (and the fact that I keep my Windows VM cut off from being able to see the outside Internet)...
17:22:28
dlowe
gendl: there's no way I know of to get the windows timezone. You'll want to download the tzinfo files and load the timezone yourself
17:32:14
gendl
Hi, is any .asd file in any Quicklisp repo supposed to be loadable with (ql:quickload) ?
17:34:15
Xach
That's only for loading allegro's aserve, which is not part of quicklisp (and can't be until it's portable).
17:37:23
gendl
Now there are a few other incompatibilities which have crept up in latest original allegroserve - most of them will be fixed with a few updates to zacl (I'll be submitting a pull request for those) - a couple others look like they'll need pull requests to original aserve itself, which I'll also submit.
17:38:14
gendl
that will leaves the longstanding issue of renaming the legacy portableallegroserve to make room for mirroring pristine current original allegroserve in quicklisp.
17:39:01
Xach
What's franz's incentive to accept patches to make allegroserve portable to not-Allegro?
17:39:16
gendl
which in principle I think the handful of legacy portableallegroserve users have agreed to, but I guess i have to tie up loose ends with everyone and get actually to happen in their official repo (still at sourceforge, I guess).
17:40:11
gendl
I can't really speak for Franz, but I can speculate that they see that it's already portable, with just a few tweaks,
17:40:48
gendl
there are already #+allegro's in their own code - so apparently someone over there is already running it on other Lisps too
17:41:37
Xach
The biggest obstacle I remember was a handful of allegro-specific feature expressions. They can be worked around by clobbering the readtable to handle them specially, but still a pain.
17:42:00
gendl
from their perspective, having more people exposed to aserve in the wild (maybe on other Lisps) means some percentage of those folks might eventually check out commercial Allegro CL
17:42:02
Xach
That's aside from the things that were nearly impossible to emulate in non-supporting lisps, like foo::(bar baz) syntax
17:43:14
gendl
The main things remaining (which can't be fixed with a few zacl enhancements) are the addition of some #+allegro's in their code.
17:43:26
Xach
They're "handled" in the sense that it can be forced to load, but it cannot be loaded standalone.
17:43:58
gendl
that's because zacl itself seems to insert :allegro into the *features* list while loading
17:44:02
Xach
It can't be considered portable if it can only be loaded by a readtable-clobbering shim.
17:45:26
Xach
That's the difference between "make it work, no hack too gross" and "suitable for general portable use"
17:46:27
gendl
because I can pretty much guarantee that those #+allegro-version<= aren't going away (I can still ask, though).
17:47:24
Xach
gendl: Thta's my impression, too. But maybe they'd be swayed by patches that use Xof-style feature flags instead? Where you test for a specific functionality, rather than a specific version, to handle incompatibility.
17:48:54
gendl
Ok i'll check into it. But I'm thinking in the meantime, make a portable fork (call it paserve2 or something) just as an interim solution, to be able to have a working setup in Quicklisp...
17:49:20
gendl
then work toward getting rid of that (and Franz might be swayed to help get rid of it, in the interest of limiting the number of aserve forks floating around)
17:49:52
Shinmera
could also have a #+allegro file that translates the version checks to regular features and then use those throughout
17:50:48
gendl
the other issue with getting original aserve into QL is the name clash with legacy portableaserve. One of the two has to be renamed (I've already reached out to anyone who I think cares, and in principle we're good to rename the old one paserve, but hasn't happened yet).
18:07:29
Bike
right, so the bt:make-thread is irrelevant. it's just a closure the same as any other closure.
18:19:44
gendl
Xach: what would it actually mean for aserve to be able to load “standalone?” I mean, it will always need zacl on non-allegro lisps, so how could it ever be wholly “standalone?”
18:20:34
gendl
how about just packaging it for quicklisp together with zacl, and call the whole thing “zaserve” or something?
18:22:50
gendl
and get the aserve part of it as close as possible to the canonical franzinc version (maybe not 100%) and someone “hopefully” (me for the foreseeable future) will just keep merging the upstream franzinc one into it every month or so.
18:34:08
whartung
can aserve load in a generic lisp (not run, but load)? Will it build, compile, and (ideally) fail tests? or does the “read table hacks” prevent it from loading?
18:52:26
Xach
gendl: truly standalone would mean load aserve and it loads its own prerequisites and runs.
18:53:16
Xach
gendl: bundling it with zacl and calling it zaserve seems to me the same strategy as paserve, which introduced the allegro-compat library.
18:54:20
gendl
...and as long as we’re trying to use pristine franzinc aserve, that’ll by definition never be possible, bcos pristine aserve will never have a :depends-on (:zacl) in its aserve.asd.
18:56:08
pjb
Posterdati: it should work, version 1.2.7 http://www.sbcl.org/platform-table.html Download the binaries.
18:57:24
gendl
yep, we’re pretty much landing back at “new & improved portableaserve”... but I can’t really see another way, unless Franz will accept :depends-on (#-allegro :zacl) in their official aserve.asd
18:59:26
gendl
— which they actually might, because I doubt they use that .asd themselves. I’m not sure why it was actually added. I’ll try to find out.
19:00:43
gendl
It also disables output-translations, which borders on malicious and needs to be deleted.
19:04:51
Posterdati
pjb: it complains about memory limits, but if you change them, you've get the same error
19:29:40
ThJ
i had a look at the book Practical Common Lisp, and the example programs were relevant about 20 years ago. then i looked at Slime and the screenshot on the main page is also ancient (macOS hasn't used that style of scrollbars in at least a decade). also, all the documentation i can find looks like it was made in the 90s and would load in the Lynx browser... should i just continue expecting this kind of thing?
19:35:19
shka_
ThJ: hyperspec was done in the 90s and because it is copyrighted nobody can publish it in more modern form
19:38:56
_death
I guess you could have some react.js thingy lazy load the text, so that you won't be able to view it in lynx
19:43:42
_death
well, if you want your programs to work in 10, 20, 30 years.. maybe stability is a good thing.. if you think your program will be worhtless by next year, as it will be rewritten ("better").. then javascript makes sense
19:46:51
ThJ
but even languages that do try to be stable over time have made adjustments to the ecosystem.
19:48:17
ThJ
but it surprises me that searches for pretty basic lisp concepts don't turn up near the top of google search results, etc.
19:51:22
ThJ
granted, i didn't start it on the most positive note, but i don't feel that i was particularly harsh either, and it was a genuine first impression..
19:53:26
_death
if you want to discuss the lisp language, that's one thing.. if you want to vent about failure to satisfy the need for new it's another
19:53:55
ThJ
will i get shot at noon if i say that i've mostly been a vim user, and the thought of switching to emacs to use slime doesn't seem terribly alluring?
19:55:02
shka_
from what i understand new vim and neovim integrate with external process much better nowdays so it may be actually acceptable
19:55:48
_death
I think some vim people are ok with emacs modes that make it closer to what they're used to
19:58:43
ThJ
i'm not a particularly advanced vim user. yes, my vimrc has a fair bit of stuff in it, but i haven't got a bajillion vim commands committed to muscle memory.
19:59:02
ThJ
ah, yes, the old quote about emacs being an excellent operating system only lacking a decent editor
20:03:15
shka_
anyway, installing spacemacs is easy (copy one file), then you will be asked to choose your preferences (vim style, emacs style, hybrid style)
20:04:43
ThJ
but i reckon i'll need to break out my META keys if i'm going to actually use Slime or such, right?
20:18:20
emaczen
ThJ: It looks like you are using OSX? You may want to check out CCL, a common-lisp implementation that can interoperate with the cocoa libraries
20:39:02
sukaeto
Emacs' buffer management is much better, IMO. And setting up Emacs to run in daemon mode and then aliasing emacsclient (to, say, vi) has been a lot more convenient for me than trying to locate that one file I know I've got open in one of these tabs in one of these vim windows
21:09:50
slightlycyborg
Anyone familiar with SBCL sockets? I want to use a socket-stream on a UDP client, but I don't know if it is possible. I can use a stream on the server after I bind, but I may just have to use the socket-send function.
21:17:21
jmercouris
slightlycyborg: I'm not very familiar, but I remember there being some basic documentation in the source IIRC
21:20:31
jmercouris
I wish I could help you, I gave up (temporarily) on using bsd sockets in SBCL, as it is an ext and I didn't want to be too tightly married to SBCL
21:21:07
jmercouris
slightlycyborg: did you look at this: https://github.com/cffi-posix/cffi-socket?
21:21:55
slightlycyborg
Ok. I will probably make the switch. I have just enjoyed using other specific sbcl features like their threads
21:23:19
Bike
a list of at least two elements, where the first element is a sequence and the second is a ub16.
22:15:07
aeth
It's pretty hard to scale past 6k LoC because at that point you can start really abstracting and make each change fairly neutral in line count
22:47:22
_death
"can't even parse a single proper Prolog term".. because prolog syntax is so essential to it?
22:49:57
_death
also, when it uses the term "functions" it seems to mean functions in the mathematical sense..
23:58:39
montxero
Hi, I have a question regarding docstrings. Which one of these formating is more "canonical"? https://pastebin.com/g43tEgJn
0:30:33
stylewarning
montxero: I actually don't add newlines to my docstrings at all unless im starting a new paragraph
0:48:56
emaczen
ealfonso: It isn't something you would regularly do, but I'm sure there is an applicable scenario to do so
0:54:53
ealfonso
I''ve seen the pattern of exporting within a file rather than centrally in a defpackage form
1:18:00
aeth
Don't use something that's deprecated because a future version of the standard might remove it!
1:20:40
no-defun-allowed
so to really be in good form, your code better not use remove-if-not or importing outside defpackages :P
1:22:17
rpg
Bike: I'm not finding this in CLHS, either. But I recall getting warnings about uses of `IMPORT` and `EXPORT` at top level
1:23:56
rpg
There's some language in the DEFPACKAGE-ADDITION issue that explains why it's better to use DEFPACKAGE, but not to the extent of deprecating top level use of IMPORT and EXPORT.
1:24:59
rpg
ACTION kind of wishes the committee hadn't made the default for package use be implementation-dependent...
1:25:18
aeth
no-defun-allowed: Well, that's controversial because all the foo-if-nots are deprecated, but the foo-if (complement #'bar) equivalent forms aren't optimized, which you'd expect if they were idiomatic. So they're deprecated functions where everyone ignores the deprecation and good luck actually removing them in the future.
1:26:49
aeth
So do you do (remove-if (complement #'evenp) #(1 2 3 4)) and future-proof your code against a removal that probably won't happen or do you do (remove-if-not #'evenp #(1 2 3 4)) and get a faster program?
1:32:29
aeth
rpg: It's not up to you if there will be a future standard or not. It's up to the core developers of SBCL, CCL, etc. (Unless you are one, in which case it's fractionally up to you.)
1:33:00
aeth
rpg: I don't see any talks about a standard in any of their channels, so it's doubtful to happen in the next 5 years, but forever is a long time.
3:04:26
slightlycyborg
I basically want to call a function that writes to a socket whenever I write to a stream
3:11:31
slightlycyborg
I don't know what that would mean. However, I think I can just make a socket-stream
3:13:48
buffergn0me
slightlycyborg: You can use MAKE-BROADCAST-STREAM to take a bunch of streams. When you write to that broadcast stream, the same thing is written to all of them
3:23:01
Elronnd
Has anyone used ningle? Is there a good way to serve binary files with it aside from loading them into memory and returning them?
3:25:50
anamorphic
I have this function, (defun (setf attribute) (new-value handle attribute-name) ...) and it would be more useful if I returned `handle' instead of `new-value' (then I could chain things if I needed to). Is there anything wrong with returning an argument other than new-value from a setf function?
3:38:57
slightlycyborg
I know have the jankiest augmented reality machine imaginable. I took an rpi with a 3.5 inch lcd, mounted that to a bike helmet so that it hangs directly in front of my face. I then used SBCL sockets to create a *helmet-stream* so I can print things to my helmet console using (format *helmet-strea* ...)