3 ms·

You solved the memory management for one particular program written in exactly the style necessary to avoid leaks for the demo. You'll find as you fix other pro

You solved the memory management for one particular program written in exactly the style necessary to avoid leaks for the demo. You'll find as you fix other programs, you'll introduce UAFs into this one which is, I suspect, one reason your commit activity around autofree has basically dropped to 0 recently.

amedvednikov 5y ago
> Can you list items that don't work at all or are in alpha state? Nothing, as I expected.
- vlang1dot0 5y ago
  No reply to the autofree comment? Unsurprising. Since you want it so much, here you go: - "No undefined behavior" -> How does V prevent this? V currently can't even generate well formed C code for all valid V so how do you prevent UB in the generated C? As of now, for any reference x in V, *x and ******x are both accepted by the checker. int32.MAX + 1 is instant UB yet V does nothing to prevent this. What is your plan to prevent UB in the generated C? - Generics -> The example shown in your own docs expresses how "wip" this is (https://github.com/vlang/v/blob/master/doc/docs.md#generics https://github.com/vlang/v/blob/master/doc/docs.md#generics). Why is `T.name` allowed? `T` can be literally anything since there is no constraint on it. You're obviously deferring type checking the function until it's monomorphized which is far more like C++ templates than "generics". How do you plan to deal with template bloat slowing down compilations? - -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site. - "go" keyword -> From your docs: "V's model of concurrency is very similar to Go's. To run foo() concurrently in a different thread, just call it with go foo()". At least you've documented it but have completely buried the lede that unlike Go, `go` spawns an OS thread not a green thread. Speaking of green threads, how do you propose to keep the efficiency you claim ("within 3% of C") while still having transparent C interop? Are you going to use segmented stacks to allow 100,000s+ green threads and then run into the same issues Go has calling into C or are you going to larger stacks to make C interop feasible which limits how many green threads you can run before using enormous amounts of memory? - "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that. - native backend -> Can handle hello world and programs that use string interpolation. Given that it can't handle the average 100 line V program, you should not be extrapolating the performance of 1,000,000 V programs.*
  - amedvednikov 5y ago
    > No reply to the autofree comment? Unsurprising. autofree was placed a bit lower on the prioritization list due to the focus on C2V and amazingly well integrated -gc boehm, which solves all leaks for now. - "No undefined behavior" -> How does V prevent this? By not having UB. You have any examples of UB in V? `x and *x` type checker bug in the compiler means the compiler doesn't work? Then by this definition none of the compilers do, because all of them have bugs. > How do you plan to deal with template bloat slowing down compilations? Is that your example of an alpha or a broken feature? > - -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site. No I didn't. V hello.v uses -usecache. And v self was removed for now because it's unfair: V modules are in vlib, all of them get cached, and the compilation is too fast. How is it 20% implemented? > - "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that. Not anymore, a large amount of these bugs have been recently fixed. Native backend is being worked on by a very experienced developer, author of radare2, so we will definitely see v self -native work this year.*
    - vlang1dot0 5y ago
      Can you explain how a conservative garbage collector solves all leaks?

amedvednikov 5y ago

> Can you list items that don't work at all or are in alpha state? Nothing, as I expected.

vlang1dot0 5y ago
No reply to the autofree comment? Unsurprising. Since you want it so much, here you go: - "No undefined behavior" -> How does V prevent this? V currently can't even generate well formed C code for all valid V so how do you prevent UB in the generated C? As of now, for any reference x in V, *x and ******x are both accepted by the checker. int32.MAX + 1 is instant UB yet V does nothing to prevent this. What is your plan to prevent UB in the generated C? - Generics -> The example shown in your own docs expresses how "wip" this is (https://github.com/vlang/v/blob/master/doc/docs.md#generics https://github.com/vlang/v/blob/master/doc/docs.md#generics). Why is `T.name` allowed? `T` can be literally anything since there is no constraint on it. You're obviously deferring type checking the function until it's monomorphized which is far more like C++ templates than "generics". How do you plan to deal with template bloat slowing down compilations? - -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site. - "go" keyword -> From your docs: "V's model of concurrency is very similar to Go's. To run foo() concurrently in a different thread, just call it with go foo()". At least you've documented it but have completely buried the lede that unlike Go, `go` spawns an OS thread not a green thread. Speaking of green threads, how do you propose to keep the efficiency you claim ("within 3% of C") while still having transparent C interop? Are you going to use segmented stacks to allow 100,000s+ green threads and then run into the same issues Go has calling into C or are you going to larger stacks to make C interop feasible which limits how many green threads you can run before using enormous amounts of memory? - "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that. - native backend -> Can handle hello world and programs that use string interpolation. Given that it can't handle the average 100 line V program, you should not be extrapolating the performance of 1,000,000 V programs.*
- amedvednikov 5y ago
  > No reply to the autofree comment? Unsurprising. autofree was placed a bit lower on the prioritization list due to the focus on C2V and amazingly well integrated -gc boehm, which solves all leaks for now. - "No undefined behavior" -> How does V prevent this? By not having UB. You have any examples of UB in V? `x and *x` type checker bug in the compiler means the compiler doesn't work? Then by this definition none of the compilers do, because all of them have bugs. > How do you plan to deal with template bloat slowing down compilations? Is that your example of an alpha or a broken feature? > - -usecache -> Another one of the 20% implemented features. This was done to give V a huge boost in compiling simple programs but the implementation is so busted, you yourself disabled it on the benchmarking site. No I didn't. V hello.v uses -usecache. And v self was removed for now because it's unfair: V modules are in vlib, all of them get cached, and the compilation is too fast. How is it 20% implemented? > - "immutable" references -> As shown on Discord, "immutable" references can easily by laundered into mutable ones by assigning the reference to a mutable variable and then assigning into that. Not anymore, a large amount of these bugs have been recently fixed. Native backend is being worked on by a very experienced developer, author of radare2, so we will definitely see v self -native work this year.*
  - vlang1dot0 5y ago
    Can you explain how a conservative garbage collector solves all leaks?