| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Adds ECL as a second supported implementation, specifically a statically
linked ECL. This is interesting because we can create statically linked
binaries, but has a few drawbacks which doesn't make it generally
useful:
* Loading things is very slow: The statically linked ECL only has byte
compilation available, so when we do load things or use the REPL it is
significantly worse than with e. g. SBCL.
* We can't load shared objects via the FFI since ECL's dffi is not
available when linked statically. This means that as it stands, we
can't build a statically linked //web/panettone for example.
Since ECL is quite slow anyways, I think these drawbacks are worth it
since the biggest reason for using ECL would be to get a statically
linked binary. If we change our minds, it shouldn't be too hard to
provide ecl-static and ecl-dynamic as separate implementations.
ECL is LGPL and some libraries it uses as part of its runtime are as
well. I've outlined in the ecl-static overlay why this should be of no
concern in the context of depot even though we are statically linking.
Currently everything is building except projects that are using cffi to
load shared libaries which have gotten an appropriate
`badImplementations` entry. To get the rest building the following
changes were made:
* Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now
use `bundled "asdf"` for all implementations except SBCL. From my
testing, SBCL seems to be the only implementation to support using
`(require 'uiop)` to only load the UIOP package. Where both a
dependency on ASDF and UIOP exists, we just delete the UIOP one.
`(require 'asdf)` always causes UIOP to be available.
* Where appropriate only conditionally compile SBCL-specific code and
if any build the corresponding files for ECL.
* //lisp/klatre: Use the standard condition parse-error for all
implementations except SBCL in try-parse-integer.
* //3p/lisp/ironclad: disable SBCL assembly optimization hack for all
other platforms as it may interfere with compilation.
* //3p/lisp/trivial-mimes: prevent call to asdf function by substituting
it out of the source since it always errors out in ECL and we hardcode
the correct path elsewhere anyways.
As it stands ECL still suffers from a very weird problem which happens
when compiling postmodern and moptilities:
https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651
Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: eta <tvl@eta.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adds some of the most common DNS types in the enum (others TBD), and
starts decoding RDATA for TXT and A.
|
|
|
|
This enables arbitrary DNS lookups (with the caveat that RRDATAs are
currently not deserialised into a record-type-specific format).
An error condition has been defined for error-responses from the HTTP
server which provides interactive restarts for attempting a new call
with different parameters.
|
|
Implements support for the compresion scheme used in binary DNS
messages.
This makes it possible to decode messages entirely, but not yet
actually resolve the labels to their "real" values.
All qnames are stored with file-offsets pointing at the position at
which their reading started, which enables the implementation of a
function to resolve pointers internally.
|
|
Adds a struct that represents QNAMEs, tracks the stream offset at
which the QNAME parsing began and makes it possible to resolve
pointers inside of the QNAME.
Note that resolving pointers needs to happen *after* the call to
lisp-binary currently. It might be possible to implement this inside
of lisp-binary in the future by switching on the top two bits of the
qname field, but since this is happening *inside* of a reader function
I'm not currently sure how to implement it.
|
|
This uses lisp-binary to define serialisation types for the DNS
messages defined by RFC 1035.
Currently the compression scheme used for QNAMEs is not supported,
hence deserialisation of even simple records fails after the header
and question sections are read.
|
|
Adds a package definition file and moves the current client into
client.lisp
Note that the client is not working at all at this commit as this is a
work-in-progress snapshot.
|
|
This includes very barebones support for querying TXT and MX records
right now. The returned structure is not turned into a more convenient
format and error handling is, well, NIL.
|
