Switch to Dart v2.6

[vaind]

Dart v2.6 is going to break compatibility in FFI (it was in "preview" after all, so no surprise there). From what I've seen with the current dev version (.8), it was rather significant so I have a feeling we'll have to drop Dart v2.5 compatibility to be able to switch to v2.6

See the changes that have already landed in the dev release and the FFI project board for what's coming.

[liquidiert]

Memory management has been removed 😍

[greenrobot]

There's no definite timeline yet on the 2.6 release, I suppose?

How about

1. When we get really close to a 2.6 release, e.g. RC2 or final release. We do a 2.5 release, make the adjustments for 2.6 and release this asap. Afterwards we focus on 2.6 only.
2. Like 1.), but prep a 2.6 branch in parallel

This way, we have another 2.5 release.

[vaind]

There's no definite timeline yet on the 2.6 release, I suppose?

Assuming it's D26 milestone, it's 9 days past due. They don't do RC or anything like that, just go from 2.5.0-dev.4.0 to 2.5.0. But from what I see, I'd say we're pretty close to a final release right now. Considering the last 3 releases (2.3.0, 2.4.0, 2.5.0) all happened on Friday, that may be tomorrow or the next week at most I'd say.

So if we want to do a release before, we should probably do it ASAP. I'd say today.

[vaind]

Some volunteers who'd like to pitch in with the 2.6 support? @liquidiert or @Buggaboo maybe? :smile:

[Buggaboo]

Sure, I'd like to get property query out of the way first.

[liquidiert]

Would be happy to help 😁

[Buggaboo]

Sure, I'd like to get property query out of the way first.

I changed my mind, I'm stuck. @vaind Can you open a new dev-2.6 branch? Dakujeme.

We should start with the imports.

I expect free and allocate to break. Probably Struct, anything related to ffi really. Let's see if attachFinalizer or something like that is available, so we can deallocate, or by whatever free has been replaced with.

I'm reluctant to use brew's dart-2.6-devX builds; I prefer to wait for the non-dev, stable(?) 2.6 version. I can't be arsed to compile my own either.

[vaind]

... Dakujeme.

dev-dart26 You're welcome :rofl: But it's just dev because I haven't really had time to look into this yet.

I'm reluctant to use brew's dart-2.6-devX builds; I prefer to wait for the non-dev, stable(?) 2.6 version. I can't be arsed to compile my own either.

I just download and extract the SDK & set its path in the IDE. Maybe that works for you as well: https://dart.dev/tools/sdk/archive#dev-channel

[Buggaboo]

Done. Except the Utf8 thing. I'm taking a break.

[liquidiert]

@Buggaboo what's it with utf8? For me all tests work with your latest changes 👍

[Buggaboo]

@Buggaboo what's it with utf8? For me all tests work with your latest changes 👍

It works, I give no guarantees that it does not leak. I don't understand/see how the Struct knows about the Pointer<Uint>, for all I know free cleans up the Struct and not the alloc'ed Pointer<Uint> of size n + 1. In my C/C++ days, I could run valgrind.

[Buggaboo]

I thought about this, for a bit. The cast only changes the underlying type (generic arg) of the Pointer, it should not change the allocation size.

[greenrobot]

Does #57 work with the final Dart 2.6? Anything outstanding?

Btw, ouch...

[Buggaboo]

I used brew's final 2.6. Still works. Some refactoring might be necessary, and dartfm after merging.

[vaind]

It works, I give no guarantees that it does not leak. I don't understand/see how the Struct knows about the Pointer<Uint>, for all I know free cleans up the Struct and not the alloc'ed Pointer<Uint> of size n + 1. In my C/C++ days, I could run valgrind.

FYI, running valgrind wasn't very helpful, at least not the way I tried...

dart2native test/box_test.dart -o box-test
valgrind ./box-test

==25284== HEAP SUMMARY:
==25284==     in use at exit: 91,012 bytes in 188 blocks
==25284==   total heap usage: 12,658 allocs, 12,470 frees, 158,942,897 bytes allocated
==25284== 
==25284== LEAK SUMMARY:
==25284==    definitely lost: 0 bytes in 0 blocks
==25284==    indirectly lost: 0 bytes in 0 blocks
==25284==      possibly lost: 0 bytes in 0 blocks
==25284==    still reachable: 91,012 bytes in 188 blocks
==25284==         suppressed: 0 bytes in 0 blocks
==25284== Rerun with --leak-check=full to see details of leaked memory
==25284== 
==25284== For lists of detected and suppressed errors, rerun with: -s
==25284== ERROR SUMMARY: 10913 errors from 240 contexts (suppressed: 0 from 0)

and each report looks somewhat like:

==25284== Mismatched free() / delete / delete []
==25284==    at 0x48399AB: free (vg_replace_malloc.c:540)
==25284==    by 0x29CB13: ??? (in objectbox-dart/box-test)
==25284==    by 0x29D2D5: ??? (in objectbox-dart/box-test)
==25284==    by 0x48AE152: (below main) (in /usr/lib/libc-2.30.so)
==25284==  Address 0x4bc2630 is 0 bytes inside a block of size 48 alloc'd
==25284==    at 0x483950F: operator new[](unsigned long) (vg_replace_malloc.c:433)
==25284==    by 0x299A18: ??? (in objectbox-dart/box-test)
==25284==    by 0x29C745: ??? (in objectbox-dart/box-test)
==25284==    by 0x29D2D5: ??? (in objectbox-dart/box-test)
==25284==    by 0x48AE152: (below main) (in /usr/lib/libc-2.30.so)

[Buggaboo]

Cool! I didn't know that we could target dart2native with this codebase! I have to read up on the dart2native memory management; it might be allocating a memory pool and releasing on exit.

Or there is no leak... with the free after the cast. Counter-test by removing the free, then check again with valgrind?

[vaind]

Support of Dart2.6 is implemented and released. Thanks @Buggaboo

followup for valgrind: #72