carp-lang/Carp
1
1
Fork 0
mirror of https://github.com/carp-lang/Carp.git synced 2024-11-04 01:25:04 +03:00
Code Issues Projects Releases Wiki Activity
formatting
Carp/core/Binary.carp

378 lines
15 KiB
Plaintext
Raw Permalink Normal View History

Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
(system-include "carp_binary.h")
Use StdInt types in binary conversion functions
2020-02-18 00:04:09 +03:00
(load "StdInt.carp")
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
;; Helper functions for making working with Maybe easier
;; TODO: Replace all of these with a single type-generic
;; zip-n macro.
(defmodule Maybe
refactor: make Maybe.zip a macro (#1138)
2021-01-19 17:59:37 +03:00
(defndynamic zip- [f args names]
(if (empty? args)
`(Maybe.Just (~%f %@names))
(let [n (gensym-with 'zip)]
`(match %(car args)
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(Maybe.Nothing) (Maybe.Nothing)
refactor: make Maybe.zip a macro (#1138)
2021-01-19 17:59:37 +03:00
(Maybe.Just %n) %(Maybe.zip- f (cdr args) (cons-last n names))))))
(defmacro zip [f :rest args]
(Maybe.zip- f args '()))
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
)
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
;; Temporary fix for issue #698
;; The underlying issue is deeper, and should probably be fixed.
(doc ByteOrder
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
"The type of byte orders.
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
LittleEndian designates the little endian ordering, and indicates the least
significant byte appears first in a given byte sequence.
BigEndian designates the big endian ordering, and indicates the most
significant byte occurs first in a given byte sequence.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(deftype ByteOrder LittleEndian BigEndian)
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
docs: document core modules (#1271)
2021-07-05 15:48:35 +03:00
(doc Binary "provides various helper functions to work with bits and bytes.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(defmodule Binary
Use StdInt types in binary conversion functions
2020-02-18 00:04:09 +03:00
(register to-int16 (λ [Byte Byte] Uint16))
(register to-int32 (λ [Byte Byte Byte Byte] Uint32))
(register to-int64 (λ [Byte Byte Byte Byte Byte Byte Byte Byte] Uint64))
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(register int16-to-byte (λ [(Ref Uint16)] Byte))
(register int32-to-byte (λ [(Ref Uint32)] Byte))
(register int64-to-byte (λ [(Ref Uint64)] Byte))
Add a function for retrieving the system endianness The technique here feels a bit hacky, but it's the common way to do it. We exploit the fact that ints are 16bits and chars are 8bits to grab the first byte in a systems int representation, which is indicative of its endianness.
2020-02-17 23:38:55 +03:00
(register system-endianness-internal (λ [] Int))
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
(defn unwrap-success [x]
(Result.unwrap-or-zero @x))
(defn unwrap-error [x]
(Result.from-error @x (zero)))
(doc byte-converter
"Returns a function that, when called, attempts to convert an array of bytes using `f` and `order`
If the conversion is successful, returns a `Result.Success` containing the converted value.
If the conversion fails, returns a `Result.Error` containing the byte array passed as an argument.")
(defn byte-converter [f order]
(fn [bs]
(match (~f order bs)
(Maybe.Nothing) (Result.Error @bs)
(Maybe.Just i) (Result.Success i))))
(doc interpreted
"Returns the interpreted value from a sequence of byte-converion results")
(private interpreted)
(defn interpreted [results]
(==> results
(Array.copy-filter &Result.success?)
(ref)
(Array.copy-map &unwrap-success)))
(doc remaining-bytes
"Returns the number of uninterpreted bytes from a seuqence of byte-conversion results")
(private remaining-bytes)
(defn remaining-bytes [results]
(==> results
(Array.copy-filter &Result.error?)
(ref)
(Array.copy-map &unwrap-error)
(ref)
(Array.copy-map &Array.length)
(ref)
(Array.reduce &(fn [x y] (+ x @y)) 0)))
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
(doc system-endianness
Use StdInt types in binary conversion functions
2020-02-18 00:04:09 +03:00
"Returns the endianness of the host system.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig system-endianness (λ [] ByteOrder))
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
(defn system-endianness []
Add a function for retrieving the system endianness The technique here feels a bit hacky, but it's the common way to do it. We exploit the fact that ints are 16bits and chars are 8bits to grab the first byte in a systems int representation, which is indicative of its endianness.
2020-02-17 23:38:55 +03:00
(if (= (system-endianness-internal) 1)
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
(ByteOrder.BigEndian)))
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(doc unsafe-bytes->int16
Binary: Make names consistent. Update docs. Specifically, we now reference the explicit unsigned int types we return in the docs for each function, and I've dropped the term byte-seq in favor of bytes in all cases.
2020-02-18 19:50:24 +03:00
"Interprets the first two bytes in a byte sequence as an Uint16 value.
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
**This operation is unsafe.**")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig unsafe-bytes->int16 (Fn [ByteOrder (Ref (Array Byte) a)] Uint16))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(defn unsafe-bytes->int16 [order bs]
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
(match order
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
Use StdInt types in binary conversion functions
2020-02-18 00:04:09 +03:00
(to-int16 @(Array.unsafe-nth bs 0) @(Array.unsafe-nth bs 1))
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.BigEndian)
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
(to-int16 @(Array.unsafe-nth bs 1) @(Array.unsafe-nth bs 0))))
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(doc bytes->int16
Binary: Make names consistent. Update docs. Specifically, we now reference the explicit unsigned int types we return in the docs for each function, and I've dropped the term byte-seq in favor of bytes in all cases.
2020-02-18 19:50:24 +03:00
"Interprets the first two bytes in a byte sequence as an Uint16 value.
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
If the first two bytes are inaccessible, or the given array contains less
than two bytes, returns Maybe.Nothing.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig bytes->int16 (Fn [ByteOrder (Ref (Array Byte) a)] (Maybe Uint16)))
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(defn bytes->int16 [order bytes]
(match order
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(Maybe.zip &to-int16 (Array.nth bytes 0) (Array.nth bytes 1))
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.BigEndian)
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(Maybe.zip &to-int16 (Array.nth bytes 1) (Array.nth bytes 0))))
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(doc int16->bytes
"Converts a Uint16 to a sequence of bytes representing the value using the provided `order`")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig int16->bytes (Fn [ByteOrder Uint16] (Array Byte)))
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(defn int16->bytes [order i]
(match order
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(Array.copy-map &int16-to-byte &[i (Uint16.bit-shift-right i (Uint16.from-long 8l))])
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.BigEndian)
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(Array.copy-map &int16-to-byte &[(Uint16.bit-shift-right i (Uint16.from-long 8l)) i])))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(doc unsafe-bytes->int16-seq
Group functions by int type
2020-02-18 21:50:07 +03:00
"Interprets a sequence of bytes as a sequence of Uint16 values.
**This operation is unsafe.**")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig unsafe-bytes->int16-seq (Fn [ByteOrder (Ref (Array Byte) a)] (Array Uint16)))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(defn unsafe-bytes->int16-seq [order bs]
Group functions by int type
2020-02-18 21:50:07 +03:00
(let [partitions (Array.partition bs 2)
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
f (fn [b] (unsafe-bytes->int16 order b))]
Group functions by int type
2020-02-18 21:50:07 +03:00
(Array.copy-map &f &partitions)))
(doc bytes->int16-seq
"Interprets a sequence of bytes as a sequence of Uint16 values.
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
Returns a pair containing interpreted values and the number of bytes that were not interpreted.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig bytes->int16-seq (Fn [ByteOrder (Ref (Array Byte) a)] (Pair (Array Uint16) Int)))
Group functions by int type
2020-02-18 21:50:07 +03:00
(defn bytes->int16-seq [order bs]
(let [partitions (Array.partition bs 2)
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
f (byte-converter &bytes->int16 order)]
(let [results (Array.copy-map &f &partitions)]
(Pair.init (interpreted &results) (remaining-bytes &results)))))
(doc bytes->int16-seq-exact
"Attempts to interpret a given byte sequence as an exact sequence of Uint16 values.
If successful, returns the interpreted values. If unsuccessful, returns the number of excess bytes.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig bytes->int16-seq-exact (Fn [ByteOrder (Ref (Array Byte) a)] (Result (Array Uint16) Int)))
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
(defn bytes->int16-seq-exact [order bs]
(let [r (bytes->int16-seq order bs)]
(if (= 0 @(Pair.b &r))
(Result.Success @(Pair.a &r))
(Result.Error @(Pair.b &r)))))
Group functions by int type
2020-02-18 21:50:07 +03:00
(doc int16-seq->bytes
"Converts an array of Uint16 values into byte sequences.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig int16-seq->bytes (Fn [ByteOrder (Ref (Array Uint16) a)] (Array (Array Byte))))
Group functions by int type
2020-02-18 21:50:07 +03:00
(defn int16-seq->bytes [order is]
(let [f (fn [i] (int16->bytes order @i))]
(Array.copy-map &f is)))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(doc unsafe-bytes->int32
Binary: Make names consistent. Update docs. Specifically, we now reference the explicit unsigned int types we return in the docs for each function, and I've dropped the term byte-seq in favor of bytes in all cases.
2020-02-18 19:50:24 +03:00
"Interprets the first four bytes in a byte sequence as an Uint32 value.
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
**This operation is unsafe.**")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig unsafe-bytes->int32 (Fn [ByteOrder (Ref (Array Byte))] Uint32))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(defn unsafe-bytes->int32 [order bs]
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
(match order
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
(to-int32 @(Array.unsafe-nth bs 0) @(Array.unsafe-nth bs 1)
@(Array.unsafe-nth bs 2) @(Array.unsafe-nth bs 3))
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.BigEndian)
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
(to-int32 @(Array.unsafe-nth bs 3) @(Array.unsafe-nth bs 2)
@(Array.unsafe-nth bs 1) @(Array.unsafe-nth bs 0))))
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(doc bytes->int32
Binary: Make names consistent. Update docs. Specifically, we now reference the explicit unsigned int types we return in the docs for each function, and I've dropped the term byte-seq in favor of bytes in all cases.
2020-02-18 19:50:24 +03:00
"Interprets the first four bytes in a byte sequence as an Uint32 value.
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
If the first four bytes are inaccessible, or the given array contains less
than four bytes, returns Maybe.Nothing.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig bytes->int32 (Fn [ByteOrder (Ref (Array Byte))] (Maybe Uint32)))
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(defn bytes->int32 [order bs]
(match order
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
refactor: make Maybe.zip a macro (#1138)
2021-01-19 17:59:37 +03:00
(Maybe.zip &to-int32 (Array.nth bs 0) (Array.nth bs 1)
(Array.nth bs 2) (Array.nth bs 3))
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.BigEndian)
refactor: make Maybe.zip a macro (#1138)
2021-01-19 17:59:37 +03:00
(Maybe.zip &to-int32 (Array.nth bs 3) (Array.nth bs 2)
(Array.nth bs 1) (Array.nth bs 0))))
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(doc int32->bytes
"Converts a Uint32 to a sequence of bytes representing the value using the provided `order`")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig int32->bytes (Fn [ByteOrder Uint32] (Array Byte)))
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(defn int32->bytes [order i]
(let [shift (fn [lng] (Uint32.bit-shift-right i (Uint32.from-long lng)))]
(match order
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(Array.copy-map &int32-to-byte
&[i (shift 8l) (shift 16l) (shift 24l)])
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.BigEndian)
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(Array.copy-map &int32-to-byte
&[(shift 24l) (shift 16l) (shift 8l) i]))))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(doc unsafe-bytes->int32-seq
Group functions by int type
2020-02-18 21:50:07 +03:00
"Interprets a sequence of bytes as a sequence of Uint32 values.
**This operation is unsafe.**")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig unsafe-bytes->int32-seq (Fn [ByteOrder (Ref (Array Byte) a)] (Array Uint32)))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(defn unsafe-bytes->int32-seq [order bs]
Group functions by int type
2020-02-18 21:50:07 +03:00
(let [partitions (Array.partition bs 4)
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
f (fn [b] (unsafe-bytes->int32 order b))]
Group functions by int type
2020-02-18 21:50:07 +03:00
(Array.copy-map &f &partitions)))
(doc bytes->int32-seq
"Interprets a sequence of bytes as a sequence of Uint32 values.
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
Returns a pair containing interpreted values and the number of bytes that were not interpreted.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig bytes->int32-seq (Fn [ByteOrder (Ref (Array Byte) a)] (Pair (Array Uint32) Int)))
Group functions by int type
2020-02-18 21:50:07 +03:00
(defn bytes->int32-seq [order bs]
(let [partitions (Array.partition bs 4)
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
f (byte-converter &bytes->int32 order)]
(let [results (Array.copy-map &f &partitions)]
(Pair.init (interpreted &results) (remaining-bytes &results)))))
(doc bytes->int32-seq-exact
"Attempts to interpret a given byte sequence as an exact sequence of Uint32 values.
If successful, returns the interpreted values. If unsuccessful, returns the number of excess bytes.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig bytes->int32-seq-exact (Fn [ByteOrder (Ref (Array Byte) a)] (Result (Array Uint32) Int)))
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
(defn bytes->int32-seq-exact [order bs]
(let [r (bytes->int32-seq order bs)]
(if (= 0 @(Pair.b &r))
(Result.Success @(Pair.a &r))
(Result.Error @(Pair.b &r)))))
Group functions by int type
2020-02-18 21:50:07 +03:00
(doc int32-seq->bytes
"Converts an array of Uint32 values into byte sequences.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig int32-seq->bytes (Fn [ByteOrder (Ref (Array Uint32) a)] (Array (Array Byte))))
Group functions by int type
2020-02-18 21:50:07 +03:00
(defn int32-seq->bytes [order is]
(let [f (fn [i] (int32->bytes order @i))]
(Array.copy-map &f is)))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(doc unsafe-bytes->int64
Binary: Make names consistent. Update docs. Specifically, we now reference the explicit unsigned int types we return in the docs for each function, and I've dropped the term byte-seq in favor of bytes in all cases.
2020-02-18 19:50:24 +03:00
"Interprets the first eight bytes in a byte sequence as an Uint64 value.
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
**This operation is unsafe.**")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig unsafe-bytes->int64 (Fn [ByteOrder (Ref (Array Byte) a)] Uint64))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(defn unsafe-bytes->int64 [order bs]
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
(match order
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
(to-int64 @(Array.unsafe-nth bs 0) @(Array.unsafe-nth bs 1)
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
@(Array.unsafe-nth bs 2) @(Array.unsafe-nth bs 3)
@(Array.unsafe-nth bs 4) @(Array.unsafe-nth bs 5)
@(Array.unsafe-nth bs 6) @(Array.unsafe-nth bs 7))
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.BigEndian)
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
(to-int64 @(Array.unsafe-nth bs 7) @(Array.unsafe-nth bs 6)
@(Array.unsafe-nth bs 5) @(Array.unsafe-nth bs 4)
@(Array.unsafe-nth bs 3) @(Array.unsafe-nth bs 2)
@(Array.unsafe-nth bs 1) @(Array.unsafe-nth bs 0))))
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(doc bytes->int64
Binary: Make names consistent. Update docs. Specifically, we now reference the explicit unsigned int types we return in the docs for each function, and I've dropped the term byte-seq in favor of bytes in all cases.
2020-02-18 19:50:24 +03:00
"Interprets the first eight bytes in a byte sequence as an Uint64 value.
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
If the first eight bytes are inaccessible, or the given array contains less
than eight bytes, returns Maybe.Nothing.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig bytes->int64 (Fn [ByteOrder (Ref (Array Byte) a)] (Maybe Uint64)))
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(defn bytes->int64 [order bs]
(match order
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
refactor: make Maybe.zip a macro (#1138)
2021-01-19 17:59:37 +03:00
(Maybe.zip &to-int64 (Array.nth bs 0) (Array.nth bs 1)
(Array.nth bs 2) (Array.nth bs 3)
(Array.nth bs 4) (Array.nth bs 5)
(Array.nth bs 6) (Array.nth bs 7))
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.BigEndian)
refactor: make Maybe.zip a macro (#1138)
2021-01-19 17:59:37 +03:00
(Maybe.zip &to-int64 (Array.nth bs 7) (Array.nth bs 6)
(Array.nth bs 5) (Array.nth bs 4)
(Array.nth bs 3) (Array.nth bs 2)
(Array.nth bs 1) (Array.nth bs 0))))
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(doc int64->bytes
"Converts a Uint64 to a sequence of bytes representing the value using the provided `order`")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig int64->bytes (Fn [ByteOrder Uint64] (Array Byte)))
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(defn int64->bytes [order i]
(let [shift (fn [lng] (Uint64.bit-shift-right i (Uint64.from-long lng)))]
(match order
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.LittleEndian)
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(Array.copy-map &int64-to-byte
&[i (shift 8l) (shift 16l)
(shift 24l) (shift 32l)
(shift 40l) (shift 48l) (shift 56l)])
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(ByteOrder.BigEndian)
Add UintN->Byte conversions Note that we do not need an unsafe variant of these conversions since they are simple projections to and from the Uint types.
2020-02-18 21:35:35 +03:00
(Array.copy-map &int64-to-byte
&[(shift 56l) (shift 48l)
(shift 40l) (shift 32l)
(shift 24l) (shift 16l) (shift 8l) i]))))
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(doc unsafe-bytes->int64-seq
Binary: Make names consistent. Update docs. Specifically, we now reference the explicit unsigned int types we return in the docs for each function, and I've dropped the term byte-seq in favor of bytes in all cases.
2020-02-18 19:50:24 +03:00
"Interprets a sequence of bytes as a sequence of Uint64 values.
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
**This operation is unsafe.**")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig unsafe-bytes->int64-seq (Fn [ByteOrder (Ref (Array Byte) a)] (Array Uint64)))
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
(defn unsafe-bytes->int64-seq [order bs]
Move partition function into the Array module Since the function is generic over arrays, it makes more sense to house it here. I've also fixed an issue with its definition whereby we produced extra empty arrays when n was greater than the original array length. We now return an array of a length that matches precisely the number of partitions with values we're able to create.
2020-02-16 23:57:38 +03:00
(let [partitions (Array.partition bs 8)
Use unsafe as a prefix in unsafe functions This brings our function naming scheme into parallelism with other core modules (e.g. Array.carp).
2020-02-18 21:56:52 +03:00
f (fn [b] (unsafe-bytes->int64 order b))]
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
(Array.copy-map &f &partitions)))
Use partitions in byte-seq->int16-seq-unsafe This change brings the implementation of `byte-seq->int16-seq-unsafe` into parity with the implementations of its 32 and 64 bit brethren. I've also cleaned up some of my previous sloppiness: - Correct function names in doc and sig annotations. - Remove extra spaces before newlines.
2020-02-18 03:03:52 +03:00
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(doc bytes->int64-seq
"Interprets a sequence of bytes as a sequence of Uint64 values.
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
Returns a pair containing interpreted values and the number of bytes that were not interpreted.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig bytes->int64-seq (Fn [ByteOrder (Ref (Array Byte) a)] (Pair (Array Uint64) Int)))
Add safe variants of byte conversion functions I've also adopted a new naming strategy for these functions--the seq in byte-seq was redundant, so we now just name these bytes->intN-seq.
2020-02-18 19:41:29 +03:00
(defn bytes->int64-seq [order bs]
(let [partitions (Array.partition bs 8)
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
f (byte-converter &bytes->int64 order)]
(let [results (Array.copy-map &f &partitions)]
(Pair.init (interpreted &results) (remaining-bytes &results)))))
(doc bytes->int64-seq-exact
"Attempts to interpret a given byte sequence as an exact sequence of Uint64 values.
If successful, returns the interpreted values. If unsuccessful, returns the number of excess bytes.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig bytes->int64-seq-exact (Fn [ByteOrder (Ref (Array Byte) a)] (Result (Array Uint64) Int)))
Refactor bytes->int-seq, add exact variants Instead of returning an array of Maybe UintNs, we now return a pair comprised of the array of interpreted int values and the number of bytes that were'nt read/interpreted. We also provide an `exact` variant of this function that returns a Result instead of a Pair. If there are excess bytes in the sequence one attempts to interpret, the `exact` functions return a `Result.Error` containing the number of extra bytes. If the byte sequence is exact , a `Success` containing the interpreted values is returned instead.
2020-02-20 22:12:38 +03:00
(defn bytes->int64-seq-exact [order bs]
(let [r (bytes->int64-seq order bs)]
(if (= 0 @(Pair.b &r))
(Result.Success @(Pair.a &r))
(Result.Error @(Pair.b &r)))))
Add functions for converting intN seq(uence)s to byte seqs
2020-02-18 21:45:18 +03:00
(doc int64-seq->bytes
"Converts an array of Uint64 values into byte sequences.")
Move Byte Order type outside of the Binary module Issue #698 points out an bug related to reloading. The illustious hellerve@ has discovered that the issue relates to types defined in modules--for some reason, upon reloading, the type's delete, copy, etc. functions are doubly defined, resulting in too high or a number of functions for Carp to work out the dependencies.
2020-03-21 02:02:55 +03:00
(sig int64-seq->bytes (Fn [ByteOrder (Ref (Array Uint64) a)] (Array (Array Byte))))
Add functions for converting intN seq(uence)s to byte seqs
2020-02-18 21:45:18 +03:00
(defn int64-seq->bytes [order is]
(let [f (fn [i] (int64->bytes order @i))]
(Array.copy-map &f is)))
feat: add bytes->hex-string (#1354)
2021-11-06 13:24:17 +03:00
(defn to-hex-str [b]
(let [hi (Byte.bit-and b (from-int 0xF0))
lo (Byte.bit-shift-left b (from-int 4))
nib-one (case hi
(from-int 0x00) @"0"
(from-int 0x10) @"1"
(from-int 0x20) @"2"
(from-int 0x30) @"3"
(from-int 0x40) @"4"
(from-int 0x50) @"5"
(from-int 0x60) @"6"
(from-int 0x70) @"7"
(from-int 0x80) @"8"
(from-int 0x90) @"9"
(from-int 0xA0) @"A"
(from-int 0xB0) @"B"
(from-int 0xC0) @"C"
(from-int 0xD0) @"D"
(from-int 0xE0) @"E"
(from-int 0xF0) @"F"
@"FATAL ERROR IN BIT LAND! ALL IS LOST")
nib-two (case lo
(from-int 0x00) @"0"
(from-int 0x10) @"1"
(from-int 0x20) @"2"
(from-int 0x30) @"3"
(from-int 0x40) @"4"
(from-int 0x50) @"5"
(from-int 0x60) @"6"
(from-int 0x70) @"7"
(from-int 0x80) @"8"
(from-int 0x90) @"9"
(from-int 0xA0) @"A"
(from-int 0xB0) @"B"
(from-int 0xC0) @"C"
(from-int 0xD0) @"D"
(from-int 0xE0) @"E"
(from-int 0xF0) @"F"
@"FATAL ERROR IN BIT LAND! ALL IS LOST")]
(String.concat &[nib-one nib-two])))
(doc bytes->hex-string
"Converts an array of bytes to a string of its hexadecimal representation")
(sig bytes->hex-string (Fn [(Ref (Array Byte) q)] String))
(defn bytes->hex-string [bs]
(let [f (fn [b] (to-hex-str @b))]
(String.join " " &(Array.copy-map &f bs))))
Add Binary module The binary module implements functions for interpreting byte sequences as int16, int32, or int64 values depending on a given endianess (the Byte module implements support for interpreting bytes as int8 values). It'd be nice if we could implement these functions in pure Carp, using the Bytes module--but unfortunately we need to rely on some type conversions in C, which are only possible by registering C functions for performing the necessary conversions. At the moment, all of these functions are unsafe (they access byte arrays using unsafe-nth).
2020-02-16 23:15:54 +03:00
)
Reference in New Issue Copy Permalink