| Age | Commit message (Collapse) | Author |
|---|
|
|
|
main.c and test.c generate binary executables so they can stay in the
main folder, but the rest can go into their own dedicated folder to
make it look nicer
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
substr didn't work properly, nor did seek. Just use the same
principle as stream_next
|
|
Principle was that we may have read all the content from the
underlying pipe (s.t. it set the EoF flag) but we haven't actually
iterated the content.
|
|
Need to fix what's going on with the example in main.c using stdin.
|
|
|
|
Couple macros to make printing nicer, use assertions instead to fail
if a test doesn't work.
|
|
Also adjust the build system to do some more (cleaning, building,
testing, running).
|
|
|
|
|
|
Why? This way, until we use symbols, the system doesn't generate the
table and thus grow the memory usage by a couple kb.
|
|
|
|
|
|
If it isn't a CONS, we return NIL instead of failing. This way, we
can use it in our general iteration functions. Eventually the actual
runtime would use this as well. The macros are mostly for internal
use to do assignment etc.
|
|
|
|
Happens because we have no null terminator on the string - rookie
mistake.
|
|
|
|
|
|
|
|
|
|
Avoid 2 levels of indirection, and having to allocate twice for small
payloads, by having an inlined array on the vector directly!
Beautiful and simple.
Required a bit of refactoring around the board, but overall the result
makes me feel happier.
|
|
bit nicer to look at, should have about the same painful performance
hit anyway.
|
|
Stable vectors will be used in the lisp runtime to implement actual
vectors, instead of using the disgusting lvec trick. This way we at
least can get attributes about the vector through one pointer hop.
|
|
|
|
|
|
I'm going to implement a normal stable vector instead of an inline
vector so we have both options for use. I think that's smarter than
just sticking to one.
|
|
We're storing them as sv_t's anyway, we're fucked with regards to
indirection. Thus, let's be nice to ourselves, and deal with the
structures. We get the size of the structure for free anyway!
|
|
Makes more sense when you think about including it as an external
library
|
|
We can register memory we've allocated onto the heap into a ~sys_t~
instance for examination (read: garbage collection) later. We can
also add items to the symbol table it has internally.
|
|
|
|
|
|
|
|
Unfortunately, due to how vectors are implemented, pointers to them
are unstable. We need to box them one more time (therefore adding a
level of indirection) in order to stabilise them. This is annoying
but currently necessary.
Even if we implemented vectors as {u64, u64, ptr} instead of {u64,
u64, bytes...}, we'd still have the same problem at access - two
levels of indirection. I guess size and capacity checks would be one
level of indirection which is nice at least, but we're already screwed
at the point of doing lookup either way.
|
|
Copied from oats, just the basics required for tagging integers or
symbols.
|
|
I think we fall into a few traps if we return an sv_t directly. Think
intent is clearer by returning the c-string directly.
|
|
|
|
|
|
We're going to be using C to compile our Lisp eventually, so I need to
have a header file for compilation to work. We can still separate out
the implementation details into separate files (then generate a shared
library for usage in the link stage) but we need this header file to
be singular and clean.
|
|
Setup build system (POSIX sh), gitignore, basic C file with an
implementation of something I really wanted to setup.
It just hashes a snippet of lorem ipsum. Testing seems to indicate
it's working. That's all it does lol.
This is a really pressing matter; all my previous Lisps always just
made the strings on the fly and that irked me deeply. I want a smart
implementation that really tries to save memory on something as
intensive as symbols.
|
