~roselandgoose

Chicago

Recent activity

Re: crash on io::close on memio::dynamic even after duplicating buffer content 3 days ago

From Rosie Keith Languet to ~sircmpwn/hare-users

Also Hi! I offer a small addition to Lorenz's comments, for you and for 
future hare learners.

> the right move here would be to just work with the memio::stream
> directly instead of taking a pointer to it :)

Indeed this is the more common pattern across the ecosystem. Alternatively,
you could also alloc() the stream and free() it after closing it.

With Lorenz's suggestion the stream is copied from foo's stack to main's.
Since the stream will not out-live main, you can safely take its address
there and use it as you had:

```

[PATCH] add enum_to_str a month ago

From Rosie Keith Languet to ~vladh/hare-project-library

Signed-off-by: Rosie Keith Languet <rkl@rosiesworkshop.net>
---
 README.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README.md b/README.md
index a2cb97a..ed89d58 100644
--- a/README.md
+++ b/README.md
@@ -83,6 +83,7 @@ If you're interested specifically in 3D graphics, check out

* [~yerinalexey/afl_harec](https://git.sr.ht/~yerinalexey/afl_harec): Hare instrumentation for [AFL](https://github.com/google/AFL)
* [~yerinalexey/hare-annotate](https://git.sr.ht/~yerinalexey/hare-annotate): A library for implementing code generators
* [`~roselandgoose/gen_enum_strs`](https://git.sr.ht/~roselandgoose/hare2c2/tree/main/item/cmd/gen_enum_strs): A Hare `fn $enum_to_str($enum) str` code generator
[message trimmed]

Re: [RFC] Generalizing default initializers and adding unsafe initializers a month ago

From Rosie Keith Languet to ~sircmpwn/hare-rfc

Im very excited to see this proposal!

> For example, it is often necessary to statically allocate
> variables whose initializers cannot be evaluated at compile-time,

Another case where ^this^ has been true for me is when initializing
global unstable (exported but undocumented) structs. I recently wrote
the following to interface with debug:: and debug::image:


```
def self: *image::image = &self_buf: *image::image;

let self_buf: [size(image::image)]u8 = [0...];

Re: The next hare compiler test suite a month ago

From Rosie Keith Languet to ~sircmpwn/hare-dev

Hi Bor,

>> One thing bootstrap harec does somewhat well is making sure invalid code is
>> actually rejected - we have an established way of doing that and we're also
>> strict about requiring those tests during code review. There is however no way
>> to track which error is associated with which test, and that means tests
>> frequently get outdated and irrelevant. Solving this will require some
>> thinking.

> I have some thoughts on how to achieve this... Hopefully today I'll have
> time to flesh them out here:
> https://git.sr.ht/~roselandgoose/hare2c2/tree/main/item/hare/check/errors.ha
Well I ran out of time last week, but I have now prototyped some
riggings. Let me know what sort of cases the following would be

Re: The next hare compiler test suite 2 months ago

From Rosie Keith Languet to ~sircmpwn/hare-dev

Thanks Bor & Drew!

> In hosted checker [calling compiler's internal functions directly from
> the tests] should be much easier fortunately. Having a lot of unit tests is imo
> more important than importing the old tests and slowly making them pass one by
> one.
I think you're right. You've convinced me to build up the (intrusive)
unit tests alongside the typechecker.

> One thing bootstrap harec does somewhat well is making sure invalid code is
> actually rejected - we have an established way of doing that and we're also
> strict about requiring those tests during code review. There is however no way
> to track which error is associated with which test, and that means tests
> frequently get outdated and irrelevant. Solving this will require some

The next hare compiler test suite 2 months ago

From Rosie Keith Languet to ~sircmpwn/hare-dev

Hi all,

I can't seem to find it now, but I believe Drew has previously mentioned
intentions to re-work the harec test suite into something more general.
I am planning on starting a fresh write of the hosted typechecker and I
would like to start by creating a test suite of sorts.

For my initial hacking I had thrown together this little driver [1], but
I think something a _little_ bit more sophisticated (and a lot less
slapped-together) would be wise.

[1]: https://git.sr.ht/~roselandgoose/test_hare_unit

Any thoughts or suggestions?

Re: working on hare::unit 5 months ago

From Rosie Keith Languet to ~sircmpwn/hare-dev

Thanks Ember!

> flexible type hashes are just based on the storage/flags (this is where
> the distinguishing between the variants happens) along with a unique id
> that's incremented each time a new flexible literal type is created.
Ah I see. It's just that last part that's missing from hare::types::hash

I see the relevant switch case(s) in harec:src/types.c:type_hash() which
is missing, as well as the harec:include/types.h:type_const struct that
it depends on. (I last pulled before the s/const/literal/ spec changes -
these types may have changed names since but ¯\_(ツ)_/¯ )

> this hash can never make it into the abi, so the only requirement is
> that each call to type_create_flexible creates a type with a unique

Re: working on hare::unit 5 months ago

From Rosie Keith Languet to ~sircmpwn/hare-dev

Oops,

Please disregard this bit:
> Next I'm going to experiment with using the scan phase of
> unit::check() to resolve type/decl dependencies and generate a
> feasible plan/job queue for the validate phase to execute.

Rereading harec/docs/declaration_solver.txt I can already see that my
description above is wrong. I think the rest of that part will remain
correct tho:
> I suspect that work will involve tweaking unit::object, so may also
> mark a good chance to implement another of Seb's ideas:
> > unit::object_kind should be removed since unit::object can just use a
> > tagged union instead

working on hare::unit 5 months ago

From Rosie Keith Languet to ~sircmpwn/hare-dev

TLDR: I'm leisurely working on the self-hosted type checker, which is
shaping up to be somewhere between a fleshing-out of hare::unit and a
complete re-write. No proposals/RFCs at this point - just having fun
experimenting, though I'm happy to receive feedback from more seasoned
eyes.

Hi all,

I've been having a lot of fun for the past few months working on
hare::unit mostly for my own learning, so thanks for such a wonderfully
hackable language :) I'm writing this email after some conversation on
IRC to document parts of that conversation, overview the progress that
I've made, and announce my intentions for futher work. If anyone sees
any problems with the approaches I mention in this email, please feel

[PATCH hare v1] hare::types: a few fixes. 6 months ago

From Rosie K Languet to ~sircmpwn/hare-dev

fixes an incorrect and untested builtin_never which previously had its
id copy-pasted from builtin_opaque.

removes redundant and divergent computations for arch-independent
builtins from fromast().

remove a missleading and unreachable branch from dealias().

Signed-off-by: Rosie K Languet <rkl@rosiesworkshop.net>
---
For the last several months I've been casually working on the many
TODOs in hare::{unit,types}. The curious can see my work over at [1],
but it's mostly not ready to send here.
[message trimmed]