#Vinix

1 messages · Page 2 of 1

toxic river
#

does V have escape analysis to remedy some of this?

#

also thanks, i will definitely use this flag soon on my code to make sure i'm not doing anything silly

upbeat crest
#

now it has v -warn-about-allocs which does the same thing as the command above

#

but no escape analysis via commandline flags yet

toxic river
#

but it does do it internally, right?

upbeat crest
#

yeah

lilac pewter
#

yeah obv

#

this is why I use C caret

toxic river
#

much better

lilac pewter
#

no one is forcing you to use that garbage tho

#

struct string_view

#

but im not sure about your point, are you suggesting that solving potential memory bugs requires hidden allocations?

toxic river
#

i meant that c isn't that much better with this

toxic river
#

you can even see in the go output that "SDF" + s1 is marked as "does not escape", i.e. does not allocate on the heap (probably... definitely doesn't hit gc though)

lilac pewter
#

Anyway if you stick to legacy C with strcat and shit then yeah, you will probably have memory bugs

#

but with modern apis and tools you can avoid that

toxic river
#

ofc

toxic river
lilac pewter
#

string_view like i mentioned

toxic river
#

still better than gets though

toxic river
lilac pewter
#

it was in some draft i think

toxic river
#

so no

lilac pewter
#

i mean lol

#

thats not a good point

#

C is not a language u can use solely with the standard library

#

its not like c++ with tons of shit there

toxic river
#

i mean

#

you can

#

i did :^)

lilac pewter
#

mfw c++ still has no networking there

toxic river
#

until i gave in and pulled in a json parsing library because fuck that shit

lilac pewter
#

oh yeah and that

toxic river
#

(i mean i was writing c++ but let's call it c style c++, no stl involved)

lilac pewter
#

like yaml and json are supported as first class stuff in a lot of langauges now

toxic river
#

idk about yaml tbh

#

json would be nice to have tho

lilac pewter
#

go is very nice with taht

toxic river
#

go only has json in the stdlib

lilac pewter
#

im not that familiar with it, but i worked with a codebase that had struct fields marked with yaml:whatever

toxic river
#

and the yaml parsing library i use (and iirc k8s uses) takes yaml

#

converts it to json

#

and then parses that with the stdlib

toxic river
#

you can query it yourself

lilac pewter
#

yeah

toxic river
#

its like fieldinfo.structtag or something

toxic river
lilac pewter
#

its for auto serialization right?

toxic river
#

but does work well enough

toxic river
lilac pewter
#

yeah

toxic river
#

for renaming json fields mostly

#

because for the stdlib to deserialize into a field it must be exported (i.e. start with an uppercase letter)

#

and {"Foo":"bar"} is not a common style in json

lilac pewter
#

true

orchid tartan
#

updated

upbeat crest
#

i think that covers 90% of them

#

i'll bring it up to 100% today
already found one missing (casts to sum types)

#

I'll add a per function option too, so that it doesn't spam

orchid tartan
#

on my end i have been fighting with trying to get better refcounting going for a few days now

orchid tartan
#

@upbeat crest uh i don't think this is working modules/time/time.v:25:18: warning: allocation (string concatenation) 23 | 24 | pub fn (mut this TimeSpec) add(interval TimeSpec) { 25 | if this.tv_nsec + interval.tv_nsec > 999999999 { | ^ 26 | diff := (this.tv_nsec + interval.tv_nsec) - 1000000000 27 | this.tv_nsec = diff

#

it literally warns for every addition

#

this is just an example, but this is an integer addition, not a concatenation

#

and it definitely doesn't allocate

upbeat crest
#

v up

#

and use -experimental for the interface nil fix to work for now, will remove that requirement later today

orchid tartan
#

it worked without -experimental earlier though

#

did you change that?

upbeat crest
#

not me, someone else

#

it broke tests

#

so he hid it behind a flag

orchid tartan
#

ah ok

#

odd

orchid tartan
#

@upbeat crest how do i make V's allocation warnings shut up if i am manually freeing?

#

(for a given allocation)

candid yoke
#

i think it should be made so it automatically shuts up once it sees you free it manually

orchid tartan
#

yeah but it doesn't do that, plus in certain cases it cannot do that either

#

so there needs to be a method to make it shut up

#

manually

upbeat crest
#

logic for detecting frees on allocating expressions is too complex

#

we'll get another rust this way 🙂

#

and it won't work anyway

if false {
 x.free() // will shut it up, but it's fake
}
orchid tartan
#

couldn't this be sort of made a bit better with some syntactic sugar?

#

@upbeat crest can you not have a C-style, stack allocated array in V?

upbeat crest
candid yoke
#

wtf

upbeat crest
#

! means fixed size stack allocated array

#

i couldn't come up with a better syntax

#

as opposed to [1,2,3]

candid yoke
#

why not just make [1,2,3] be a value

#

and then it becomes a dynamic array the moment you put it on the heap

upbeat crest
candid yoke
#

aka &[1,2,3]

#

uh nvm that would just make a pointer to a value of [1,2,3]

orchid tartan
candid yoke
#

but i mean &Foo{...} allocates

#

so i dont see why &[1,2,3] wouldnt

orchid tartan
#

that's bound to save a lot of memory leaks

orchid tartan
#

or maybe __uncheck

#

to avoid an extra "standard" keyword

upbeat crest
#

that would pollute lots of code

#

maybe a comment

#

Go style

orchid tartan
#

oh yeah

#

a comment would work

#

good idea

upbeat crest
#

x := [1,2,3] // __uncheck

orchid tartan
#

sounds good

upbeat crest
#

ok will do

lilac pewter
#

if its a comment cant it be a more human readable thing

#

not __uncheck

orchid tartan
#

C does it too for /* FALLTHRU */

#

idk what it could look like, up to alex really

lilac pewter
#

// unchecked?

upbeat crest
#

that's a common word though

candid yoke
#

// v: no-leak-check

#

:^)

upbeat crest
orchid tartan
#

too verbose

#

imho

lilac pewter
#

// unleaked halfmemeright

orchid tartan
#

maybe // v:uncheck

upbeat crest
#

oh yeah lets use a utf8

candid yoke
#

i mean that v: part is a very good idea

lilac pewter
#

yup

upbeat crest
#

// 🤡

orchid tartan
candid yoke
#

also what is this even checking, i think its a good idea for it to be verbose

orchid tartan
#

and yeah the v: is a good idea but i prefer it without space

candid yoke
#

what if you add more diagnostics in the future

upbeat crest
candid yoke
#

just make it work with both

orchid tartan
#

without space leaves less room for error

upbeat crest
#

although x := [1,2,3] // v:freed is probably clearer

orchid tartan
#

yeah that's fine too

lilac pewter
#

// v:trust me bro

candid yoke
#

short and clear as to what it does

#

nice

orchid tartan
#

there are so many arrays for events allocated on the local scope on tight loops

#

they could've been all []! but weren't

#

no wonder there's a lot of leakage lol

upbeat crest
#

nice

#

stack arrays ftw

lilac pewter
#

why are stack arrays not the default option?

upbeat crest
#

because python kids these days

#

want dynamic arrays

opal light
#

Are they allocated using alloca? Or only once at the entry of the function?

upbeat crest
#

V tries to balance between C and python

upbeat crest
#

no alloca

opal light
#

Nice

upbeat crest
#

known elements/known size

lilac pewter
#

very counter-intuitive imo, but if its like python then sure

upbeat crest
#

! thing was just a meme
(lets add this temp token for now)
4 years later i have no idea what's better
looks like it'll stay

#

i considered fixed([1,2,3])

#

[..][1,2,3]

#

etc

lilac pewter
#

dyn[1,2,3] halfmemeright

candid yoke
#

i still stand by my &[1,2,3] for heap allocated arrays

#

lines up with syntax for heap allocating other things

lilac pewter
#

i stand by anything that makes allocations opt-in

#

guess thats not something up for discussion?

candid yoke
#

yeah im confused about that too, clearly needs a change but i got no feedback on my idea (twice) :^)

upbeat crest
#

but would break so much existing code

#

and confuse python kids

#

i think 95% of arrays used are dynamic arrays, at least in vlang/v

candid yoke
#

you can use v fmt to convert the code

#

or can you hmm

#

not exactly, nvm

lilac pewter
#

and just assumed it was already fixed

candid yoke
#

i mean if you can't read the documentation it's your fault lol

lilac pewter
#

not the best philosophy for designing something lol

candid yoke
#

just read the damn docs and figure out that if you want a dynamic array you do the other thing instead

#

and if you can't read the docs you probably should pick another hobby

lilac pewter
#

no experienced engineer will go read "how to make array" most likely

#

they will just look at code examples

candid yoke
#

or that

#

but i mean if you get an error you can't push to an array

lilac pewter
#

and see arr = [1, 2, 3]

#

ok good ill do that

lilac pewter
#

tahts why i want opt-in dynamic arrays, not the other way around

candid yoke
#

you probably go figure out why, and you hit the docs page and you figure out [] is a fixed array, to make it dynamic you do &[]

#

or as you said, you just find code examples and see people doing &[]

upbeat crest
lilac pewter
#

error: cannot push to a fixed-size array, did you mean &[...]?

upbeat crest
#

unless you write old school pascal/c style code

#

with [255]elems // >255? lol good luck

toxic river
#

for both

#

and then do escape analysis to figure out if the value escapes or can be kept on the stack

#

or [size]type{1, 2, 3} like in go works okay enough too

upbeat crest
#

interesting, a bit against the "be as explicit as possible", but could work

#

as soon as you try to append to an array or allocate too much, it escapes

#

it's similar to my idea of auto (de)referencing
good in theory, nice for the developer
but comes with lots of hidden issues

toxic river
#

which is good, that's what you want

#

go slices work like this, afaik

upbeat crest
#

go differentiates between basic arrays and slices (dynamic arrays)

#

[...]int vs []int

toxic river
upbeat crest
candid yoke
#

they probably heap allocate if it's "big enough"

upbeat crest
#

once I added fmt.Println(arr), it changed to ./a.go:18:14: []int{...} escapes to heap

#

so probably yes

candid yoke
#

how do you get that print?

#

is this some compiler switch?

#

i didnt know go had something like that

upbeat crest
#

go build -gcflags -m a.go

candid yoke
#

ah fair

#

nice

toxic river
toxic river
upbeat crest
upbeat crest
#

I'll implement it, but not right now

#

by V 0.6

#

added it to roadmap

orchid tartan
#

@upbeat crest how do you make V output all the warnings instead of stopping (and failing) if there are too many?

upbeat crest
orchid tartan
upbeat crest
#

@orchid tartan v -message-limit 10000 foo.v

toxic river
orchid tartan
#

ok this is good

#

@upbeat crest i just need that comment-based warning suppression and then i promise i'll stop bothering :p

upbeat crest
#

it's a bit trickier than the previous fix

orchid tartan
#

ty!

orchid tartan
#

btw

#

i get a lot of warning: allocation (cast to interface)

#

these seem to be spurious if the previous fix is still in effect

upbeat crest
orchid tartan
#

i do pass -experimental...

#

it still seems to allocate though

orchid tartan
#

i'd like to do that before merging it

# 
modules/sched/sched.v:357:78: error: invalid expression: unexpected token `,`
  355 |     }
  356 | 
  357 |     mut new_thread := new_user_thread(process, false, pc, voidptr(0), stack, []!, []!, voidptr(0), false) or {
      |                                                                                 ^
#

omg

#

i think this should work?

upbeat crest
upbeat crest
toxic river
#

or convert them to a struct emptyarray {};

upbeat crest
# 
int main(int argc, char** argv) {
   int a[0];
   printf("a: %p; sizeof(a): %ld \n", (void*)a, sizeof(a));
   return 0;   
}

this compiles with:
#0 17:16:52 ^ master /space/v/oo> clang-18 -std=c99 -pedantic x.c
x.c:3:10: warning: zero size arrays are an extension [-Wzero-length-array]
    3 |    int a[0];
      |          ^
1 warning generated.```
#

this v:freed thing is very tricky because all comments are stripped for performance on the scanner level

#

unless the scanner is used for vfmt

#

i'd have to modify the scanner to look ahead at the comment and see if it has v:freed

toxic river
orchid tartan
#

i thought []! arrays still had internal V structure like cap and whatnot, just that they pointed to data preallocated on the stack

#

therefore it would make sense to have one with length of 0, because i'd agree that passing a C struct of 0 size to a function directly is wrong

#

but i guess they are actually plain C arrays

#

that complicates things

#

since the functions i pass them to check for the length of the array, but in this case they cannot

orchid tartan
#

i fixed it by just using a variable and freeing that

#

a bit ugly but works

#

@upbeat crest could you please take a look at why your interface cast fix doesn't work even with -experimental?

upbeat crest
#

Sure. Will be home in 15

orchid tartan
#

aight

upbeat crest
#

main__Resource* resource = /*nili*/((void*)0);

#

what's your code?

upbeat crest
toxic river
#

or doing escape analysis like go

#

yeah

upbeat crest
toxic river
#

oh well, yeah kinda

#

tbh if you have no length guarantee or its too long force gc

upbeat crest
#

so we ok with using alloca in vinix?

#

and in V code in general

toxic river
#

alloca bad

upbeat crest
#

exactly

toxic river
#

always

#

you can, however, make arrays by-value

#

i guess

#

and a zero length array is codegenned into an empty struct

#

and crucially, a slice can be coerced from a pointer to an array

toxic river
#

that just has cap=len

#

and then escape analysis on that to move it to stack if it's okay

#

and a slice literal is just

#

make an array

#

and slice it

upbeat crest
orchid tartan
orchid tartan
#

the allocation happens when i cast from voidptr(0) instead of unsafe { nil }

#

no problem, i'll just change it all to unsafe { nil }

upbeat crest
#

i think nil should always be used instead of voidptr(0)

orchid tartan
#

oh yeah so do i

#

the voidptr(0) code is a holdover from older code

upbeat crest
#

i see
i can update vfmt to replace it with nil

orchid tartan
#

we could yeah

#

i can also do it manually with a sed

#

it should be a relatively safe thing to do

upbeat crest
#

we gonna build a GC in pure V this year and replace boehm with it

#

or at least provide it as an option (-gc new) until its super stable

#

boehm doesn't compile with tcc on all platforms, and that's an issue

upbeat crest
#

@orchid tartan v:freed via comments is hard to add, also comments are not safe (not checked, typos etc)
what about attributes?

x := [1,2,3] @[freed]
in the future [] will be removed

#

and it'll just be
x := [1,2,3] @freed

toxic river
toxic river
upbeat crest
#

yeah me too

orchid tartan
#

i do not have strong preferences as long as the general jist of it as is the same

toxic river
upbeat crest
toxic river
#

and it lines up with other attributes more (e.g. function attributes)

upbeat crest
#

we don't have stmt attrs yet

#

how do other langs implement them

#

prefix or suffix

toxic river
#

prefix

#

rust has prefix, gcc/clang have prefix

#

go has comments mostly i think

upbeat crest
#

ok will do that

#

prefix

toxic river
#

also, note that the reason e.g. rust has [] around the name is because of operator precedence

#

because you could reasonably do like, @foo (3 + 4)

#

and then is it @foo(3+4) 5 or @foo (3 + 4);, you don't know until you parse the rest which is unfun

upbeat crest
#

yeah and i want to make it like # in python
entire line after @ is an attribute

toxic river
#

that matters if you have parametrized ones though

toxic river
upbeat crest
#

to avoid extra() []

toxic river
#

okay fair enough

#

you could force @[] around parameter-having attributes only though

#

and @foo is then always unambigously parameter-free

upbeat crest
#

yeah good idea

orchid tartan
#

but isn't @ already used to disambiguate identifiers from keywords?

toxic river
#

you can just use #

#

or [[, kinda not really

upbeat crest
upbeat crest
#

@orchid tartan lol i just made a 200 line GC in pure V that's only 2.5x slower than boehm and Go's GC (which both perform the same)

#

Go's GC has a better algo than boehm, but Clang's -O2 is a better optimizer

# 
Custom GC benchmark completed in 125.95225ms
Boehm GC benchmark completed in 53.423 ms
Go's GC benchmark completed in 50.614583ms
upbeat crest
#

this is insane:

Custom GC benchmark completed in 177.99275ms```
I'm almost at Go level
will need more advanced tests, perhaps I'm missing something
orchid tartan
#

interesting

#

i think i will still stick to manual memory management for the reasons we've already discussed though

upbeat crest
#

sure, V needs it in general
boehm doesn't compile with tcc on macos

opal light
#

There are some common tests that people use to test both single core and multi core, obv you would need to port the tests since I think they are mostly written for java

toxic river
#

and how bad your gc pauses are

opal light
#

That's where optimizing for single core and multi core differs

#

Or well, single thread or multi thread

upbeat crest
#

@orchid tartan new statement attrs and @[freed] will be available today
was a big project

orchid tartan
upbeat crest
#

will be live on vlang/v within ~2 hours (after tests)

# 
fn foo() {
    x := [1, 2, 3] @[freed]
    unsafe {
        x.free()
    }
    println('x is freed')
}
#

i decided to make it a suffix attribute
similar to our suffix attrs for struct fields (like in Go), and takes less space, less invasive than

@[freed]
x := [1, 2, 3]
toxic river
upbeat crest
#

@orchid tartan it's live

#

v up

upbeat crest
#

i'd be happy with 3x slower

toxic river
#

3x is like, v -js margin isn't it

orchid tartan
#

thanks

orchid tartan
#

@upbeat crest banter muted me in the Vinix discord lol

#

also, that banter is EOL, you may wanna kick it and either replace it with @strange hornet or just have no such bot

toxic river
#

banter2 ftw

upbeat crest
orchid tartan
#

ask pitust for support with the latter

#

he's the one hosting it

wild halo
#

@upbeat crest hey, if you add me on this new discord it would be nice

#

it would also be nice if we could continue working on Vinix!!

#

i miss working on the project, i have such a big backlog of fixes and improvements

#

@lilac pewter remind me to add uacpi

#

whenever i can work on this

#

i need to make all the bindings 😭

lilac pewter
#

letsgo

wild halo
#

at least it will be way less painful than Ada

warped jackal
#

Cynix dead?

wild halo
#

hm no

upbeat crest
upbeat crest
wild halo
upbeat crest
#

ok, what happened to your old one?

wild halo
#

i wanted a bit of a clean break so i moved to a new account (which already existed, it was just dormant)

upbeat crest
#

FR sent

wild halo
#

accepted, thanks!

wild halo
#

i made it so interrupts are automatically disabled on spinlocks and it increased stability significantly

#

i still need to diagnose the memory leak(s) and an issue with the scheduler where stuff seems to be descheduled randomly (but it may also be an event system issue)

toxic river
wild halo
#

poor man's mutexes

toxic river
#

synchronizing between different cores?

wild halo
#

i am not even sure myself

#

Vinix does not have mutexes, only spinlocks

#

which are used for synchr

toxic river
#

ah

wild halo
#

it's honestly fast enough like this rn

#

with just spinlocks (but disabling interrupts)

#

or rather

#

when i say fast enough i don't mean that i don't want mutexes

toxic river
#

it might become a bottleneck at some point, to be honest

wild halo
#

i mean that it is fast enough that you wouldn't really notice

#

at some point yes

toxic river
#

but if you arent heavily contending them

wild halo
#

especially with a lot of interrupts

toxic river
#

there's no real penalty

wild halo
#

also yes contention

toxic river
wild halo
#

this is more of a band aid to make it not crap the bed when you blow on it

toxic river
#

it probably increased stability because something somewhere incorrectly wrote to state shared with interrupt handlers

wild halo
#

the idea is to replace the spinlocks with more granular mutexes once stability is achieved

wild halo
#

@slow oriole i cannot believe you're not in the Vinix thread

#

now you are :)

slow oriole
#

me when the (when the)

wild halo
#

Vinix GTK3

lilac pewter
#

Damn

covert geyser
#

nice!

honest finch
#

nice

turbid vector
#

nice

wild halo
#

@glad peak

glad peak
glad peak
wild halo
#

ty lol

glad peak
#

how hard is it

#

to port

wild halo
glad peak
#

V looks funny

#

the compile time speed is crazy

wild halo
#

it kinda looks like Go

#

but not really

#

it's fast to compile if you use a lightweight backend yes

slow oriole
#

Rust in shambles crying and screaming

wild halo
#

@upbeat crest how can one use an enum from C in V?

#

something like enum C.whatever {} doesn't seem to work

#

@lilac pewter i encountered the first roadblock

#

trying to get enums to play nice

#

cc @candid yoke

wild halo
wild halo
lilac pewter
lilac pewter
#

Btw u aren't calling namespace initialize etc

upbeat crest
upbeat crest
#

@wild halo hm using a virtual C.enum would still require defining the values

so I'd just translate it with v translate

#

and use a V enum

#

once v translate is fully integrated into #include "foo.h" (right now it only translates function defs), it won't be necessary

upbeat crest
#

with the changes from today, type C.EnumName = int could work potentially

wild halo
#

interesting thanks, i just solved by not including the C header at all

#

and using different types, that way the compiler didn't complain...

#

...not ideal, but works

upbeat crest
lilac pewter
#

Congrats, that's p cool

wild halo
wild halo
#

@upbeat crest why does V not autogenerate function prototypes for external C functions?

#

it seems like it would make more sense than plain #includeing headers manually, which at the end of the day don't really matter because V doesn't really parse them

#

plus they only really work on the C backend and not any other hypothetical backend like the native one

#

imho V should just rely on the user provided interface by means of actual V code (and autoemit prototypes in the C backend)

#

it seems like a significantly sounder design, unless i am missing something

#

i also understand that dropping #include now may be an issue if a lot of things rely on it, but one could opt into the new behaviour (or alternatively opt out of it if made default)

#

one thing the new behaviour would also help with is binding functions that have prototypes that V doesn't necessarily play nice with, but would be very cleanly bound by relying on V code only and emit a C prototype based on that

#

something like #592294828432424960 message comes to mind

#

the aforementioned workaround was me literally not including the C header, but of course that is not ideal without proper prototypes being emitted

upbeat crest
#

#includes are translated with c2v then

wild halo
#

hm

#

what i am saying is more akin to "why are includes necessary at all to begin with"

#

like i'd rather not have includes and/or V attempt to autotranslate them, perhaps unreliably

#

i just want V to create (very easily) prototypes based on my function definition for interfacing with C

#

(for the C backend)

#

for the native backend it doesn't even need the step of creating the prototypes, it should already know by default

#

btw this is how it works in most other languages like Ada

wild halo
#

( @upbeat crest )

upbeat crest
wild halo
# 
C.myfunction(arg0 voidptr, arg1 u64, arg2 u32) bool

->

bool myfunction(void *arg0, uint64_t arg1, uint32_t arg2);```
upbeat crest
#

just the definition

wild halo
wild halo
#

@upbeat crest error: cannot call a function that does not have a body

rain mason
#

well well well

#

someone got vinix motivation

wild halo
#

i have been working on Vinix though

#

i have been reworking refcounting and that's annoying to debug and tedious

#

hence why not that many other commits

#

but it should make the system more stable

rain mason
rain mason
wild halo
#

not at all

#

it's quite annoying

rain mason
#

sorry shouldve added a tone indicator or smt

wild halo
#

oops

rain mason
tender hornet
#

but it does not generate a separate .h file, the prototypes are still part of the .c file

#

we could add another tag, that could add them to a separate .h file, but it is not clear to me, how it should be named, and should that be parametrizable etc

#

if you have link(s) to info, about how other language do what you need, please post them

candid yoke
#

extern <function decl> is basically how most languages do that

#

so @[c_extern] <function decl> is pretty much what i'd expect from V

wild halo
#

thanks, this seems to do what i wanted

#

one slight suggestion i have is to allow @[import: 'c_function_name']

#

you already have @[export: 'c_function_name']

#

which allows a V function to be available via a C symbol name (as well as the V function name)

#

while this c_extern is fine for what i needed, i think it would be prettier to have import, which then allows you to define a V function name, available properly via a module, without C. prefix

#

often C functions have libraryname_whatever prepended to it, which in V can turn into libraryname.libraryname_whatever which is annoying

#

the import mechanism solves this

#

(and yes, i tried it and it doesn't work)

#

personally, if added, i'd remove c_extern entirely as it is just redundant and worse

#

here's an example of export

#

just to show how sensible adding import would be

wild halo
#

@upbeat crest @tender hornet 5439ff9cdebb3072a015cc0166206e90d6c1034a breaks Vinix

#

also please note what i said above, i think it would be a great improvement to V

tender hornet
wild halo
#

well that i am not sure

#

it was working before, now it isn't, and i bisected V to that commit being the issue

tender hornet
#

do you have a pub fn (mut a []string) free() { method in builtin?

#

previously it was not used

wild halo
#

no i don't have that, i am also not sure what that means exactly, sorry

tender hornet
#

the commit passed on the V CI, but it only builds vinix, it does not run it

wild halo
#

yeah, it builds fine

#

the issue is at runtime

#

should've specified

#

i didn't debug that yet, specifically

#

i will generate C output from the 2 commits and compare it guess?

tender hornet
#

before that commit, V called pub fn (a &array) free() {, so if you had a := ['abc', 'def'] for example, and used -autofree, the generated a.free() call would have freed only the memory for a itself, but not for the elements; after that commit, it frees first the elements, and then the array too

wild halo
#

so what happens could be that i have a call to .free() for the strings inside first, then for the array

#

would that result in a double free?

tender hornet
#

yes

wild halo
#

okay that may be an issue

#

the behaviour has changed

tender hornet
#

after that commit, the loop that frees the elements is not needed anymore

#

since it is done inside the a.free() call

#

if you want, I can add a -d do_not_free_strings_in_array switch to restore the old behavior for now?

wild halo
#

i'd rather understand the actual issue

#

the diff isn't huge

#

it's mainly only a couple of calls to array_free being replaced with Array_string_free

tender hornet
#

yes, Array_string_free does a loop to free the elements first

wild halo
#

i fixed it

#

it was indeed about this issue in a spot in the kernel

#

btw

#

do you think it is possible to use a longer version of the commit hash in the commit messages of vc?

#

it only uses 7 characters but that could lead to collisions i think, given the amount of commits in v

tender hornet
#

yes, afaik they are not read by humans, only by automated systems

#

what do you think is a reasonable count?

#

the full commit?

wild halo
#

the full commit would be perfect because there is no chance of collision

tender hornet
#

@upbeat crest what do you think?

wild halo
#

else i guess something like 9 or 10? idk if there is a way to ask git how long the commit hash should be to have no collisions

tender hornet
#

can we replace the hash in the messages with the full one?

wild halo
#

i am saying this because i am automating pulling the right vc commit based on the v commit now, as seen in that commit above

#

i used this to make bisecting much easier

#

but i was always concerned about the possibility of collisions

tender hornet
#

afaik we do not shorten the hash ourselves, but use the result of git rev-parse --short HEAD

#

I'll have to see what its documentation is

#

but using the full hash is better for automation anyways

wild halo
#

thanks!

#

i appreciate that

tender hornet
#

happy to help when I can

upbeat crest
#

ah you did the full ones already

#

ok

wild halo
#

full ones are way better

wild halo
#

@upbeat crest @tender hornet it would be nice if, alongside labelled break/continue, you could support something like break 2

#

where 2 means to break to the 2nd level of loop

#

so it's unnecessary to manually label loops

#

so break without an argument is equivalent to break 1, then break 2, 3, and so on

wild halo
# 
__global (
    freelist_head = &u64(unsafe { nil })
)

fn freelist_free(page u64) {
    unsafe {
        mut ptr := &u64(page + higher_half)
        *ptr = freelist_head
        freelist_head = ptr
    }
}```
#

why would freelist_head get automatically dereferenced in *ptr = freelist_head?

#

like i get that i should be casting it to u64

#

but i would expect an error or warning rather than it silently dereferencing the var

upbeat crest
#

should be an error

#

report via github please

#

will fix today

upbeat crest
#

i think readability would suffer compared to labels

wild halo
#

the readability argument is matter of taste i guess, i personally find labels to be too cluttering but i accept a differing opinion

#

it's not a big deal, just a suggestion

wild halo
toxic river
#

i think the other thing this messes with is the ability to use break <value> like rust and zig can

#

(where you can break a loop with a specific value)

#

though i guess they both have special syntax for labels to disambiguate?

wild halo
toxic river
#

wtf how does the V compiler work if this is like

#

able to pass typeck

lilac pewter
wild halo
#

but this at least had a warning

upbeat crest
wild halo
#

awesome!

upbeat crest
#

@wild halo I fixed it: #592320321995014154 message

#

will be merged after tests pass

#

soon

wild halo
#

thanks!

upbeat crest
#

merged finally
had to fix a lot of stuff

wild halo
#

thanks, i'll update Vinix shortly

#

i'm glad this fix allowed you to fix bugs on the V side too

lilac pewter
warped jackal
#

Vinix more like goneix

lilac pewter
#

I really wanna see a mint kernel thats like astral level

#

So its sad

upbeat crest
#

@wild halo I've added arm64 support to Vinix

image.png
wild halo
#

damn

#

Claude been cookin huh?

lilac pewter
#

Vinix is back to life???