Austral (a simple-ish language with a linear type system)

Well IMHO it's quite explicitly spelt out: > No destructors. > > No implicit function calls.

How to preallocate cstring for FFI call that fills it up

A C program would record the amount of memory it allocates, because there's no way to retrieve this information. A traditional method is to use zero or null the last element, but it hurts speed.

Austral (a simple-ish language with a linear type system)

i don't think their goal was a commentary on destructors. it seemed like they were trying to bridge copy-and-move with borrow checking in the simplest way someone could come up with.

How to preallocate cstring for FFI call that fills it up

The best way to allocate cstrings in Nim is to do var a = newString(len) someProcThatTakesCstr(a.cstring, a.len) Run > when passing the cStringArray (in earlier call glShaderSource), I need to > pass the size of that array. I know it is 1 so I hard code it, but is

How to preallocate cstring for FFI call that fills it up

I am trying to create some types/procs to be able to use OpenGL functionality in Nim. I started with the Opengl Program object. I created a proc that compiles a vertex and fragment shader, then links it into a program and stores the id in the Program object. This works. But to perform some erro

Tesseract and Leptonica

I just created some "dirty" bindings for tesseract (for OCR) and leptonica (dealing with images): * * Some bits are just copied from (the memory mana

forum mirror

As a little side (side, side) project I've hacked a small mirror of the forum. Its quite simple and updates the most recent posts ever ~2 hours. Have a look, maybe its useful:

Destructors for "ref object" types?

For completeness, here is how the destructor for a `ref object` subtype would be coded: type ARef = ref object of RootRef aname: string proc `=destroy`(x: typeof ARef()[]) = `=destroy`(x.aname) type BRef = ref object of ARef bname: string

avr_io v0.3.0 + avrman release

This is gonna be incredibly useful for my future projects! Thank you for working on this!

Destructors for "ref object" types?

Thanks @enthus1ast, what you suggest is precisely how I would do it if I was coding from scratch. However, I'm working with an existing code base that has a whole pile of `ref object` declarations. I was hoping to avoid the effort of converting them all to that form. @SolitudeSF, your suggestio

avr_io v0.3.0 + avrman release

Hi thanks! The plan is to eventually add them all, at least for the mega/tinyAVR families. Were you thinking about a specific microcontroller? Maybe I can have a look; note that I will only test what I got on hands tho!

Destructors for "ref object" types?

if you dont care about looks proc `=destroy`(x: typeof ARef()[]) = Run

Austral (a simple-ish language with a linear type system)

It's interesting but ultimately some misguided attempt to "make destructors" visible like they do something interesting. But they don't. Sure, they have overhead but there is not much you can do about it except for rewriting quite a bit of the program so that it allocates less. But this informat

Austral (a simple-ish language with a linear type system)

Cause I disagree with parts of the linear type system. RAII exists so let's use it instead of pretending that doing what a compiler can do for you makes good code. Like I mentioned it does not need to be discardable. I think compilers should protect you from yourself in a non interfering way. If

Austral (a simple-ish language with a linear type system)

Why did you make the return of write discardable? Austral semantics require all linear types have _exactly one_ consumer, so discarding it would be a compile-time error. I think the interesting part with the linear type mechanics is that the compiler forces proper use of a state machine. A file

Challenge: Weak linking on Windows

Well we can care about that problem later. But why does it not work?

Challenge: Weak linking on Windows

> The idea behind it is that we can leave the merging of duplicated generic > instantiations to the linker and simplify the frontend. This means though that the (c) compiler has to re-parse, re-codegen and potentially re-optimize them leading to quite a lot of extra work for it before it gets t