* feat: add box templates and box type
This commit adds an implementation of Boxes, memory manged heap
allocated values.
Boxes are implemented as C pointers, with no additional structure but
are treated as structs in Carp. To facilitate this, we need to add them
as a clause to our special type emissions (TypesToC) as they'd otherwise
be emitted like other struct types.
Co-authored-by: Veit Heller <veit@veitheller.de>
* fix: slight memory management fix for Box
Make sure we free the box!
* test: add tests for box (including memory checks)
* Revert "fix: Ignore clang nitpick"
This reverts commit 70ec6d46d4.
* fix: update example/functor.carp
Now that a builtin type named Box exists, the definitions in this file
cause a conflict. I've renamed the "Box" type in the functor example to
remove the conflict.
* feat: add Box.peek
Box.peek allows users to transform a reference to a box into a a
reference to the box's contained value. The returned reference will have
the same lifetime as the box. This function allows callers to manipulate
the value in a box without re-allocation, for example:
```clojure
(deftype Num [val Int])
(let-do [box (Box.init (Num.init 0))]
(Num.set-val! (Box.peek &box) 1)
@(Num.val (Box.peek &box)))
```
This commit also includes tests for Box.peek.
Co-authored-by: TimDeve <TimDeve@users.noreply.github.com>
* feat: implement blit on ByteOrder
ByteOrder is effectively just an enum that indicates desired endianness.
We can freely copy it around without penalty.
Co-authored-by: Veit Heller <veit@veitheller.de>
Co-authored-by: Erik Svedäng <erik@coherence.io>
Co-authored-by: TimDeve <TimDeve@users.noreply.github.com>
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.
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.
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.
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.
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.
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.
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).
