freenode/#lisp - IRC Chatlog
Search
8:35:47
phoe
I have a string containing bytes in hex. What is the agreed way to convert that into a ub8 array?
10:48:22
no-defun-allowed
If you want that, Haskell has that by default. Even their wiki admits that's a bad idea for big strings.
10:50:06
jackdaniel
nly: array representation and list representation are different things in common lisp, but both are sequences
10:50:29
jackdaniel
some CL implementations provide extension called "extensible sequences" as well, to define your own sequence types
10:55:14
_death
you can also coerce a string to a list of characters, though that's usually not what you should want
11:03:50
no-defun-allowed
I solved the problem of not having a Netfarm MOP yet by using a hash table as an intermediate form for schemas.
12:40:32
didi
So... if I call `with-open-file' with a filespec like "foo.png" and :direction :output, my implementation could generate an output stream with :element-type byte, right?
12:43:29
Josh_2
you could write a function that determines the filetype based on the extension and use that in place of 'unsigned-byte?
12:44:08
Bike
it's possible an implementation does that, but i wouldn't count on it. file type extensions are kind of unregulated, for one.
12:45:02
Bike
"The element-type specifies the unit of transaction for the file stream. If it is :default, the unit is determined by file system, possibly based on the file."
12:48:26
didi
Seems like a cool thing to do, tho I have no idea on how many things would break after such change.
12:50:48
scymtym
Bike: :default should actually mean bivalent as in (with-open-file (stream "/etc/motd" :direction :input :element-type :default) (list (read-char stream) (read-byte stream)))
12:57:34
didi
I hit the quote because I'm trying to use `uiop:run-program' to run a program that reads text from :input and outputs bytes to :output, but I'm struggling. Silly mismatching streams.
13:03:24
didi
`uiop:run-program' seems to apply :element-type to both streams, even if I supply a stream for :output.
13:07:08
didi
Hum, and according to SBCL manual, the same applies to `sb-ext:run-program': ‘:external-format’ The external-format to use for ‘:input’, ‘:output’, and ‘:error’ :STREAMs.
13:24:58
splittist
I like the example in stream-element-type of '(integer 0 1) to allow for (but not mandate) bitwise output (as it were)
13:26:46
didi
_death: What's the name of the construct that restrict evaluation of forms to certain compiler features?
13:29:10
_death
but there are better ways to do that.. for example have a file per implementation/platform and have a reader conditional or :if-feature (or whatever it's called) in the asdf definition
14:01:27
didi
How would you connect a function that writes to a stream and one that reads from a stream? I'm using a combination of `with-output-to-string', `make-string-input-stream', and `with-open-stream', but I feel there might be a better way.
14:14:53
_death
https://gist.github.com/death/2709ae6a9124968a86070bbb760b1629 for some sbcl-specific fun
14:17:17
didi
Ah, threads. I should have thought it. I think I kinda wished streams could accumulate stuff.
14:56:24
didi
How do I rewrite https://paste.debian.net/hidden/01f61fd9 to remove the duplicated `with-open-file'? I feel like I need `macrolet', but I can't figure it out. I don't want to always pass `if-exists' to `with-open-file' because it behaves differently whenever it receives `if-exists' or not.
14:59:18
Xach
didi: one option: instead of defaulting to NIL, default to the default value of if-exists
15:00:19
didi
Xach: The thing is, as far as I understand, there's no default value, because `with-open-file' behaves differently if it doesn't receive a value at all for :if-exists.
15:01:09
didi
"if-exists---one of :error, :new-version, :rename, :rename-and-delete, :overwrite, :append, :supersede, or nil. The default is :new-version if the version component of filespec is :newest, or :error otherwise. "
15:22:06
didi
Heh, SBCL calls the first argument of OPEN as FILENAME. It confused me a little as I expected FILESPEC.
15:35:15
gendl
Hi, is there anything in SBCL and/or CCL which can get the real time in microseconds?
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