proposal: type for null terminated pointer

Currently the type of c"aoeu" is &const u8.
Instead, the type should indicate that the pointer is null terminated. Here are two ideas to represent that:

&0 const u8
&null const u8

This type would be implicitly castable to &const u8. You can explicitly cast the other way, and in debug mode this inserts a safety check to make sure there actually is a null byte there.
It should probably work for any type that supports T == 0 or T == null.
We want to steer users away from this type and instead use []const u8, which includes a pointer and a length. However, we still have to deal with null terminated things from C land, which makes this useful, and some kernel interfaces. For example, we currently have this:
pub fn open_c(path: &const u8, flags: usize, perm: usize) -> usize {
    arch.syscall3(arch.SYS_open, usize(path), flags, perm)
}

pub fn open(path: []const u8, flags: usize, perm: usize) -> usize {
    const buf = @alloca(u8, path.len + 1);
    @memcpy(&buf[0], &path[0], path.len);
    buf[path.len] = 0;
    return open_c(buf.ptr, flags, perm);
}

Having the open_c prototype be &0 const u8 would make it more type-safe. Further, we could provide an open function that supported either type for path, and if it happened to be null terminated then it could avoid the stack allocation.
We could also make the type of string literals be []0 const u8 meaning that the pointer value for the slice has a 0 after the last byte. The length would still indicate the memory before the null byte. If you slice this type then the pointer component would change from &0 const u8 to &const u8.
It would be extra helpful if automatic .h import could identify when a pointer in a function is supposed to be null-terminated, and we could emit a compile error if the user passes a pointer that is not null terminated. I'm not sure how we could detect this automatically though.

in debug mode this inserts a safety check to make sure there actually is a null byte there.

How would that work? Wouldn't that be an unbounded linear search?

Maybe if you cast from []T to []0 T then len then we check for 0 in the last spot (since we have len) and then in the new slice, len is -1.

Proposal rejected in order to discourage use of null terminated things.

How do you plan to interface with C-style null-terminated strings?

Can you elaborate with this question? We have the cstr module for getting string length and converting to a slice.

Solved thanks to that.

Reopening for #518.
My proposal is to leave the type unnamed; you have to refer to it as @typeOf(c""). This discourages people from using the type, and it clearly associates the type with the c"" syntax.
Instances of the type should not be usable in any way, except for implicitly converting to &const u8. No slicing syntax x[0..5], no array subscripting syntax x[0], no field access x.foo.
Literals with c"foo" syntax should obviously be of this type. Nothing implicitly casts to this type. Creating an instance of this type should be done through @typeOf(c"")(x), where x is of type []const u8. This is the only explicit conversion that should be allowed. In safety mode, the conversion should do this safety check:
assert(x.len > 0);
for (x[0..x.len - 1]) |b| {
    assert(b != 0);
}
assert(x[x.len - 1] == 0);

There is no way to create a @typeOf(c"") directly from a pointer. You have to slice the pointer, explicitly giving it a length, and then convert it. This way the safety check is always bounded.
There are many cases where you don't want to bother with this safety check, but you still want a @typeOf(c""). For that we can add these functions to the cstr module:
pub fn fromSliceUnsafe(x: []const u8) -> @typeOf(c"") {
    @setDebugSafety(this, false)
    return @typeOf(c"")(x);
}
pub fn fromPointerUnsafe(x: &const u8) -> @typeOf(c"") {
    return fromSliceUnsafe(x[0..0]);
}

The name "Unsafe" should properly inform people that they're taking a risk using these utilities.
I'm not sure we need any solution to null-terminated arrays of things other than u8. These cases exist, but I don't think we need special support for them.

I think this counter proposal has 2 competing ideas:

Introduce a type safety feature that makes it more ergonomic to have safer code.
 I think the original proposal is better, where the type is named.
There's also no reason to limit it to u8. A null terminated array is not inherently an evil C concept that is intruding in the Zig language. It's a general data storage technique that is valid for some memory constrained use cases.
I can probably find a Windows API that uses NULL as a sentinel for an array of pointers. The argv in libc main would be represented with &null ?&null u8. (And not just libc - this is how it is represented in the official x86_64 ABI specification).

There is no way to create a @typeOf(c"") directly from a pointer. You have to slice the pointer, explicitly giving it a length, and then convert it. This way the safety check is always bounded.

So the generated code would first have to do essentially a strlen to find the length, use that to convert to a slice, then cast that to the null-terminated type, and then the debug safety check would do a redundant strlen? That doesn't seem right.
If we had the[]null u8 type as originally proposed, this would be more straightforward. I think a better way this can go is:

Set the null terminator in memory.
Cast the &u8 to []null u8. This cast does linear search for the terminator and sets len appropriately.
Now @typeOf(slice.ptr) == &null u8

From llvm/include/llvm/Support/MemoryBuffer.h
/// This interface provides simple read-only access to a block of memory, and
/// provides simple methods for reading files and standard input into a memory
/// buffer.  In addition to basic access to the characters in the file, this
/// interface guarantees you can read one character past the end of the file,
/// and that this character will read as '\0'.
///
/// The '\0' guarantee is needed to support an optimization -- it's intended to
/// be more efficient for clients which are reading all the data to stop
/// reading when they encounter a '\0' than to continually check the file
/// position to see if it has reached the end of the file.

That may be a better place to put my comment -
Does the null/0 have to be at index x.len? C strings are stored in fixed length array but the string length can vary, it is not necessarily equal to the array size. The same applies to null-terminated C arrays.

@jido In C, nothing prevents you from removing all null terminators from a char array, and then passing it to strlen. This is the motivation for the null terminated type. The compiler will insert a null terminator at x.len to prevent this bug. You, as a user of a null terminated type can still insert null terminators between 0 and x.len and strlen will stop at your null terminator instead of the one at x.len. The one at x.len is there for safety, and trying to override it is undefined behavior (aka a runtime crash in debug mode).

Moving some work from Pointer Reform (#770) to here:

[ ] add syntax for [N]null T, []null T, and [*]null T
[ ] add implicit casting

[ ] []null T to []T
[ ] [*]null T to [*]T
[ ] [N]null T to [N]T
[ ] *[N]null T to *[N]T
[ ] []null T to [*]null T
[ ] [N]null T to []null const T
[ ] [N]null T to [*]null const T

[ ] make string literals [N]null u8
[ ] remove C string literals and C multiline string literals

A runtime check in debug mode is not a bad idea, as long as its easy/cheap to get a []null u8 slice from another slice. Its not uncommon in to insert a null in the middle of a larger array...

Is there a reason [N]null T, []null T, and [*]null T cannot simply be wrapper types around [N]T, []T, and [*]T? E.g. consider some code like this for []null T:
fn TermPtr(comptime T: type, comptime term: T) type {
    return struct {
        ptr: [*]T,
        fn len(self: @This()) usize { implement strlen here }
        fn from_slice(slice: []T) @This() {
            assert(slice[slice.len - 1] == term);
            assert(there are no interior nulls);
            return Self { .ptr = slice.ptr };
        }
        etc.
    };
}

This has the same layout as a C pointer and can be passed to and from C code as-is.
What changes if this type is implemented directly in the compiler? The reasons I can think of are basically syntactic sugar.

You get the []null T syntax, which is concise.
[]null T implicitly coerces to []T.
String literals would be automatically null-terminated and coerce to either []u8 or []null u8. But you can already do this conversion safely with a comptime function.

Are there any other significant differences? And are the things listed above advantageous at all? The current sentiment seems to be that the feature should be intentionally ugly, so adding convenient syntax doesn't seem all that compelling.

Null terminated data is too fragile. Here some arguments

unchecked memset could corrupt data
sending and receiving null terminated data over network creates complications (for example unknown length incoming data requires more calls to allocate new buffers)
it also creates obstacles for bounds checking (repeating calls to strlen, or store length & defeat any reason or 'saving' that zero-terminated data provides)

Even more: in C it is not a part of the language, but an api (of the past). So i think that interop with legacy C APIs should not get dedicated feature in the language. Robustness should not be traded for runtime efficiency.
Response for @daurnimator's comment:
POSIX standard dates back to late 1980s. Linux syscalls are based on POSIX, so i consider 'open' and other as legacy APIs. Take a look at article about file IO in Google's in-development OS. There the kernel itself doesn't know anything about 'files' and file IO is implemented in userland.
Thoughts on [N]null T, []null T, and [*]null T:
Consider use case: i have some data (for example [N]null u8) and i want to create a zero-terminated slice and pass it to an api that wants it. Creating such slice would require writing 0 to array (act of taking a slice corrupts data), even not considering const array. So mem alloc&copy required anyway. Basically []null T can be used only to annotate some api that it takes zero-terminated data.

Null terminated data is too fragile. Here some arguments

I think you will find that the Zig community in general (and especially myself) agrees with you on this, and APIs in general should prefer slices to null terminated pointers. Even if you are using Zig to create a C library, and even in actual C libraries, I would recommend pointer and length arguments rather than null terminated pointers, like this: https://github.com/andrewrk/libsoundio/blob/1.1.0/soundio/soundio.h#L795
That being said, I want to repeat what I said earlier about null terminated pointers:

A null terminated array is not inherently an evil C concept that is intruding in the Zig language. It's a general data storage technique that is valid for some memory constrained use cases.

I also stumbled on a Real Actual Use Case inside LLVM.
The bottom line for me is that null terminated pointers exist in the real world, and especially in systems programming. You can see this in interfaces with the operating system in the standard library:
[nix-shell:~/downloads/zig/build]$ grep -RI 'issues.*265' ../std/
../std/c/index.zig:// TODO https://github.com/ziglang/zig/issues/265 on this whole file
../std/event/fs.zig:            /// must be null terminated. TODO https://github.com/ziglang/zig/issues/265
../std/event/fs.zig:            /// must be null terminated. TODO https://github.com/ziglang/zig/issues/265
../std/event/fs.zig:            // TODO https://github.com/ziglang/zig/issues/265
../std/special/bootstrap.zig:// TODO https://github.com/ziglang/zig/issues/265
../std/os/linux/index.zig:// TODO https://github.com/ziglang/zig/issues/265
(about 100 occurrences in this file)
../std/os/index.zig:// TODO https://github.com/ziglang/zig/issues/265
../std/os/darwin.zig:// TODO https://github.com/ziglang/zig/issues/265 on the whole file

@matthew-mcallister

Is there a reason [N]null T, []null T, and [*]null T cannot simply be wrapper types around [N]T, []T, and [*]T? E.g. consider some code like this for []null T:

I think it's a reasonable use case to want to decorate external functions with this null terminated attribute. Pointers are the biggest cause of unsafety in Zig, with the danger of security vulnerabilities, and we don't have a borrow checker like Rust. So we have to compensate by having pointer attributes to provide metadata about pointers to prevent footguns. I've seen the align(n) pointer attribute save myself and others from difficult to diagnose undefined behavior, and I think the null attribute will be similar. I think if it was between using a TermPtr struct from the standard library, or a [*] pointer and documenting that it has to be null terminated, most programmers, including myself, would stick with the bare pointer. Making the syntax more convenient to represent this API is to encourage people to opt in to some compiler-checked safety.
I want to note another use case: The Vulkan API is defined by an XML document that generates the .h file to include, and they independently came up with the idea of annotating null terminated pointers in this way: https://github.com/KhronosGroup/Vulkan-Docs/blob/v1.1.100/xml/vk.xml#L661
With Zig language support for null terminated pointers, I believe the Vulkan API can be represented in Zig types with no loss of information.
So here's the trade-off we're making as I see it:

language becomes slightly bigger, with the null attribute to pointer types
language becomes slightly smaller, with no more C string literals
one less footgun (passing non-null terminated pointer when null-terminated pointer expected)

I feel pretty confident about this trade-off being net positive.
Now that I've just made an argument in favor of moving forward with this proposal, I want to say that I am pleased with the community resisting new features. I strongly believe in keeping Zig simple, and the voices here saying "can't we get away with not having this?" echo my own thoughts.

Just seen that the new C pointer type is being implemented, i think that's where this null attribute belongs.
const envp_optional = @ptrCast([*c][*c_null]u8, argv + argc + 1); // bootstrap.zig@62

Maybe a better name is needed (c_zero), as null can be confused with abstract null in zig.
Having 0 right after end of the string literals is good idea, and it would allow to automatically cast string literals to [*c_zero]u8 (and to [*c]u8? but not [*]u8?). Creating zero terminated data at runtime would be handled manually in userland where it belongs.
About Real Actual Use Case inside LLVM:
Is it made for while ((ch = readChar(&buf)) != 0)?
 Here while with error unions would be more appropriate.
const Buffer = struct {
    // implementation
    fn readChar() !u8 {
        if (now >= len) return error.EndOfBuffer;
        // implementation
    }
}
///////////
while (buffer.readChar()) |char| {
    // use the char
} else |err| {
    // handle end of buffer
}

It will be a compile error to have a null terminated C pointer. C pointer means "I'm sorry, I actually don't know whether this is supposed to point to one thing, or many things, or if it's supposed to be null terminated. The .h file didn't tell me." If you know that a pointer is null terminated, and you have access to edit the pointer type, then make the type [*]null T.

Well my idea is to discourage use of 0 terminated data and associate it with C interop (all of the use cases that i've seen). If you know really what are you doing and know solid benefits then you would use [*c_null]T.
And for converted .h files you would do
open(path: [*c]u8, flags: u32) [*c]File
open(path: [*c_null]u8, flags: u32) [*]File
Random thoughts:
why c pointer is [*c]T and 0 terminated is [*]null T? why not [*]c T or [*null] T?

I must say that I would like zero better than null for 0-terminated array. To me null denotes a pointer with a null value.

@Rocknest your counter proposal isn't taking into account everything. Have a look at the issue description and the checklist and show how your counter proposal solves the use cases. For example what about slices.
@jido one problem with zero (or 0 as in the original post) is that it doesn't make sense when the type is optional, e.g. [*]null ?T

About slices: maybe 0 terminated arrays are not evil at all, but 0 terminated slices are evil for sure. Taking 0 terminated slices in theory impossible without destroying original data. Debug safety with such slices (check every write? iterate over data when doing casts?) is complicated.
About pointers: it is nice to have type safe pointer that indicates 0 terminated data, but it should be discouraged.

@andrewrk I wholly agree with your stance on first-class support for null-terminated strings in Zig. I see excellent C interop as mission-critical for basically any programming language, but even moreso a systems language like Zig. However, I'm not sure I fully understand your response, or at least I partially disagree with it.

I think it's a reasonable use case to want to decorate external functions with this null terminated attribute. Pointers are the biggest cause of unsafety in Zig, with the danger of security vulnerabilities, and we don't have a borrow checker like Rust. So we have to compensate by having pointer attributes to provide metadata about pointers to prevent footguns. I've seen the align(n) pointer attribute save myself and others from difficult to diagnose undefined behavior, and I think the null attribute will be similar.

So, am I wrong in saying this is true whether the type is implemented in the compiler or in stdlib? Say c_str = TermPtr(u8, '\0'), or equivalent. Functionally, what is the difference between these two prototypes?
extern "c" fn chdir(path: [*]null const u8) c_int;
extern "c" fn chdir(path: c_str) c_int;

Both are at least type safe: I cannot pass a [*]const u8; I would have to either do an unsafe cast or go through a library function with a safety check, assuming c_str is properly encapsulated.
We're talking about using the type system to enforce an invariant on the data pointed at by the pointer, and I guess I'm not sure what compiler would do that cannot be accomplished by a good user API. Borrow checking is different, as the algorithm requires variable scoping and lifetime information only accessible to the compiler; there's no way to enforce that kind of invariant with plain-Jane encapsulation.

I think if it was between using a TermPtr struct from the standard library, or a [*] pointer and documenting that it has to be null terminated, most programmers, including myself, would stick with the bare pointer. Making the syntax more convenient to represent this API is to encourage people to opt in to some compiler-checked safety.

That's a very reasonable proposition, and it may even be the case, but I'm not convinced there's actually a major difference in convenience/usability. Getting into naming would be bikeshed territory, but if the choice is between (say) c_str and [*]null u8, I doubt a new Zig user would find either hard to get used to. And library/binding authors have to be diligent either way; a clumsy or inexperienced author could still easily use [*]u8 or [*c]u8 in place of [*]null u8 when, say, blindly translating C headers.
Granted, there are some clear downsides. Most obviously, you would have to wrap C string constants with a comptime function to do the type conversion (e.g. c_str("quux") instead of just "quux"), but the type checker will catch you if you forget. Moreover, if it's a huge deal, the language could later add overloaded string constants like Haskell has, but perhaps that's a bridge too far.

I believe the Vulkan API can be represented in Zig types with no loss of information.

Not directly relevant, but I know of this use case. I've written two Vulkan binding generation programs before [1] [2], and I'm starting one for Zig.

So here's the trade-off we're making as I see it:
* language becomes slightly bigger, with the null attribute to pointer types
* language becomes slightly smaller, with no more C string literals
* one less footgun (passing non-null terminated pointer when null-terminated pointer expected)

Basically, I think that a user datatype solution accomplishes the last two goals without having first problem at all. There will be syntax concerns, but, hey, maybe it'll be possible to work around them. Further, a userland solution can be trialed right now with no changes to the compiler, which would be easy enough that it wouldn't cost much to have a change of heart later and go the builtin route. (The two could actually coexist, meaning there's a very mild violation of the "one obvious way to do things" principle here.)
And sorry for the wall of text. As I see it, though, it's worth taking an hour to type up a reply if it might save a lot more work in the future.

What about type safe opaque pointers? And allow to define functions in their namespace.
const c_string = TermSequence(u8, 0x00);

fn open(path: const c_string, flags: c_int) [*c]File {
    _ = path.strlen();
    // ...
}

@matthew-mcallister

Functionally, what is the difference between these two prototypes?

If I answer the question literally, the answer is that one of them would compile and the other would be non-extern struct not allowed in function with C calling convention. If you changed TermPtr implementation to use extern struct then it's not actually guaranteed that the C ABIs are compatible. For example if you look at the x86-64 architecture specification, it describes the C ABI for the C calling convention. It's a bit convoluted, but structs and pointers are treated separately by the spec. I believe it happens to be true that for x86-64 in the C ABI environments I am familiar with, a small enough struct will pass its fields as registers, it's not guaranteed to be the same, and one would have to research all the C ABIs to make sure that struct with a pointer field and a pointer directly, happen to have the same ABI for all the targets.
So at the very least, it's a lot less immediately obvious that one of them is passing a pointer.
I think a userland null terminated pointer would need to be more complicated than your example. For example, what about const, volatile, alignment?

If I answer the question literally, the answer is that one of them would compile and the other would be non-extern struct not allowed in function with C calling convention.

Sorry, I had no idea; it seems the extern modifier for structs isn't documented yet.

If you changed TermPtr implementation to use extern struct then it's not actually guaranteed that the C ABIs are compatible. ...

True, I naively assumed that all platforms are the same as x86, which in my (limited) experience does always pass this via registers. But I believe that is an orthogonal issue. If we had a "newtype" or "transparent" struct layout modifier which caused a struct to have the same binary semantics as its (sole, primitive) member, it would be generally quite useful by allowing you to create ABI-compatible, typesafe wrappers for, e.g., clock_t and various bitflag types, and it would handle this point as a side effect. I would definitely like to see that happen whichever way null-terminated pointers are implemented.

I think a userland null terminated pointer would need to be more complicated than your example. For example, what about const, volatile, alignment?

Couldn't you could ask the same about any custom pointer wrapper (e.g. unique_ptr, shared_ptr)? In principle, you can always make the type template function more flexible and add typedefs for common cases. Plus anyone can define their own type if all else fails. Also, doesn't alignment go on the data type and not the pointer? But yeah, if you want to support all possible pointer attribute combinations, present and future, it might be more convenient as a new attribute.
Anyways, I'm open to discuss/answer more, but I can relent if you feel like you've read enough.

I would definitely like to see that happen whichever way null-terminated pointers are implemented.

This is definitely an interesting proposal which I would invite you to file separately from this null terminated pointers issue (and indeed if it was accepted, it could potentially reverse the decision on this one).
I think you've made a pretty strong case for userland null-terminated pointer. It's enough to make me go back and consider all the use cases that I have for it. I don't know if I'm ready to reverse the "accepted" label here yet, but I'll admit that I'm going back and questioning this decision.

This is definitely an interesting proposal which I would invite you to file separately from this null terminated pointers issue (and indeed if it was accepted, it could potentially reverse the decision on this one).

That sounds good! I'd be happy to write up a proposal and work on implementing it as well.
Also, I just tried this out in Compiler Explorer and it seems like a one-member extern struct already gets passed the same way as a plain int on x86_64, so the suggestion here could be tentatively evaluated without waiting for that idea to be implemented.

In principle, you can always make the type template function more flexible and add typedefs for common cases.

For the record, what I was thinking by this was that the template would take a struct specifying pointer attributes and you'd write one typedef per set of parameters. Without working out details, something like
const PtrAttrs = struct {
    is_const: bool,
    is_volatile: bool,
    // etc.
}
const c_str_const = TermPtr(u8, '\0', PtrAttrs { is_const: true, is_volatile: false });
const w_str_const = TermPtr(u16, '\0', PtrAttrs { is_const: true, is_volatile: false });
// etc.

This should generalize to various custom pointer types.

Ability to define types such as 0 terminated pointers would a powerful addition to the language. Also it would probably solve #1595.
How it could possibly look like:
pub fn TermPtr(comptime T: type, comptime termValue: T) type {
    return @TransparentStruct(struct { // builtin ensures that there is only one field
        ptr: [*]T // could be any type, for example 'c_int' to pass type safe values to some c api
        fn from(comptime slice: []T) @This() {
            return @This() { .ptr = (slice ++ termValue).ptr };
        }
    });
}

Not sure about modifiers such as const, align. Maybe something like this:
pub fn TermPtr(comptime T: type, comptime termValue: T) type {
    return @TransitiveStruct(struct { // allows to forward type modifiers from the outside
        ptr: [*]T
        // methods
    });
}
///////
const c_str = TermPtr(u8, 0x00);
extern fn someApi(path: const c_str);

It could even allow to use operators on such type, however it should be optional. For example [index] operator on c_str is ok, but + on type safe c_int wrapper for c api is not ok.

@matthew-mcallister It seems important to me that C types that can be represented in C, can be represented in Zig language without having to import any code. This precedent is set for C integer types,  float types, and C pointer types. There must be a C string literal, or Zig string literals must work for C APIs.

Something I hadn't considered yet:
* Would the null terminated slice/array types assert that a null/0 byte does _not_ occur in any of the elements before the `len` index?

If so, this would guarantee the property that after casting a []null T to [*]null T, finding the length based on the null termination would give the same len value as before. However this would mean that casting []null T to [*]null T should have a runtime safety check, which probably means it shouldn't be an implicit cast. Hmm.
Or the type could have a weaker guarantee, which is only that there shall be a null/0 byte at the len index, and makes no guarantees about items otherwise. However, then the "length" may change when implicitly casting from []null T to [*]null T.

Continuing from IRC:
To echo the common usage of null terminated strings, I think the length should always be computed at runtime (at least before the optimizer kicks in). I propose:

[]null T (null slice) should be struct { ptr: [*]T } where .len performs a strlen-like operation.
[*]null T doesn't need to exist
[]null T implicitly casts to [*]T
[]null T can be cast to []u8 via nullslice[0..nullslice.len]. The .len here is invoking a strlen-like operation.
[N]null T is an array of max size N where the first null should be considered the length. It is similar to []null T except uses a strnlen-like instead of strlen-like.`

For safety, you could make indexing a null slice do a length check: null_u8_slice[5] could emit code that does: assert(strnlen(null_u8_slice, 5) == 5) before the access.

@daurnimator Why not keep [*]null T and dispense with the others? If the intended purpose of this feature is to decorate pointers in C FFI definitions, then that would be the minimal solution, plus it would encourage use of "real" slices in Zig code and discourage overuse of strlen.
I feel like null-terminated literals can still conceivably be handled well by a builtin function. Say c"hello" produces a raw [*]null u8 pointer. Then a hypothetical @cstrToSlice function can safely convert this to a Zig slice at compile time. Or all string literals can have an implicit terminating null and @sliceToCstr will again safely do the conversion at comptime.

why would we need @cstrToSlice? std.mem.len already works fine, it'll just have an improved prototype that uses [*]null T instead of [*]const T. @sliceToCstr as you described it could also easily be a userland function.

I meant those names as placeholders; I only added the @ to satisfy the requirement that you wouldn't need to import from std. As far as my suggestion goes, it's agnostic to how they're implemented.

Moving some work from Pointer Reform (#770) to here:

[ ]  add syntax for [N]null T, []null T, and [*]null T

[ ]  add implicit casting

[ ]  []null T to []T
[ ]  [*]null T to [*]T
[ ]  [N]null T to [N]T
[ ]  *[N]null T to *[N]T
[ ]  []null T to [*]null T
[ ]  [N]null T to []null const T
[ ]  [N]null T to [*]null const T

[ ]  make string literals [N]null u8

[ ]  remove C string literals and C multiline string literals

coming in late to this, but wouldn't it be easier to create a hybrid string type?
the hla language for example uses a hybrid string type that is null terminated with a header containing the max length, the current length and a pointer to the start of the string. this really simplified interactions between C libraries and internal libraries.

Thought it might be helpful to share my experience with this problem.  In D I implemented a module to support null-terminated strings.
https://github.com/dragon-lang/mar/blob/master/src/mar/sentinel.d
The general term for arrays that end in a particular value that I've found is a "sentinel array" and or "sentinel ptr".  In D I just implemented them as a wrapper struct arround pointers and arrays.
The 2 main benefits I see from having sentinel pointers as a part of the type system are:

functions that take sentinel pointers can declare this requirement, meaning that if a client passes a non-sentinel pointer then they will get a compile error rather than a runtime bug
it allows the application to control when and how sentinel arrays are allocated, rather than having to convert normal zig arrays to sentinel arrays every time a C function is called

My library solution for this in D would be equivalent to something like this in Zig:
pub fn SentinelPtr(comptime T: type) type {
    return struct {
        ptr: [*]T,
        // create a sentinel pointer from `ptr`, assume it ends in a sentinel value
        pub fn init(ptr: [*]T) {
            return @This() {
                .ptr = ptr,
            }
        }
    };
}
pub fn SentinelSlice(comptime T: type) type {
    return struct {
        array: []T,
        // create a sentinel slice from `slice`
        pub fn init(slice: []T) @This() {
            std.debug.assert(slice.ptr[slice.len] == 0);
            return assume(slice);
        }
        // create a sentinel slice from `slice`, assume it ends in a sentinel value
        pub fn assume(slice: []T) @This() {
            return @This() {
                .array = array,
            };
        }
    };
}

It just boils down to wrapping the pointers/slices into other types and creating helper functions to create/unwrap them.
This is one way to implement it, though, if you do it in a library like this then it will be a bit more verbose than a language solution, and you'll probably want to find a way to allow the types to perform automatic const conversion, i.e.
var chars = [2]u8;
chars[0] = 'a';
chars[1] = '\0';
var x : SentinelPtr(char).init(chars.*);
var y : SentinelPtr(const u8) = x; // is there a way to support this in zig?

Just to extend and visualize @Rocknest 's syntactical proposal:
[]const u8
[*]const u8
[5]const u8
[_]const u8
[*c]const u8
[null]const u8
[*null]const u8
[5 null]const u8
[_ null]const u8

I appreciate having the null inside the brackets because it describes a property of the array/slice type itself (like 5/_/*), as opposed to the const which qualifies the element type. (Minor thing)> 🐤

I appreciate having the null inside the brackets because it describes a property of the array/slice type itself (like 5/_/*), as opposed to the const which qualifies the element type.

But e.g. align is on the outside of the []

But e.g. align is on the outside of the []
Ah, true

Implemented in #3728, landed in 5a98dd42b38b9188cfb96c9ab57dc91af923029f.
Related follow-up issues:

#3731
#3766
#3767
#3768


Add SMC-PHD components

This PR adds the following components:

SMCPHDPredictor: Performs the SMC-PHD prediction step
SMCPHDUpdater: Performs the SMC-PHD update step
SimpleHypothesiser: A configurable hypothesiser that generates a sequence of SingleHypothesis objects (used to generate the hypotheses required by the SMCPHDUpdater)

A running example can be found here

@sdhiscocks @jswright-dstl, I have applied the requested changes and improved the documentation slightly.


Unable to play content after widevine update

I'm submitting a ...

[X] bug report
[ ] feature request
[ ] support request

General infomration
Prerequisites

[X] Are you running the latest version?

Description
Netflix does no play a files
Steps to Reproduce

Open netflix
try to play anything

Expected behavior:
Video to be played
Actual behavior:
Nothing, went back to the menu
Context (Environment)
Installation

[ ] I installed the plugin via zip from the Releases page
[X] I´m using the Netflix Repo
[ ] I´m using a different source (Please tell which)

Operating System

[ ] Linux (x86/x64)
[ ] OSX (x86/x64)
[ ] Windows (x86/x64)
[X] Linux (ARM)
[ ] Android

Additional informatin on the environment
LibreElec 9.0.1 on Pi3b+
Debug log
https://pastebin.com/20MgFNPu
Other information
Occured after updateing to latest widevine. It reported an update was available, updated it and the problem occured.
Inputstream adaptive settings can be opend from the pluging however it looks for it in
/usr/lib/kodi/addons/inputstream.adaptive/
I don;t know why, but this folder does not exists. I only have:
./share/kodi/addons/kodi.binary.instance.inputstream
Could this be solved by changing a setting?

Looks that you dont have KODI 18 running , please share complete log file.

It is not widevine related
2019-03-24 12:02:10.414 T:1546642288   ERROR:   File "/storage/.kodi/addons/plugin.video.netflix/resources/lib/MSLv2.py", line 244, in load_manifest
2019-03-24 12:02:10.414 T:1546642288   ERROR:     data = self.__decrypt_payload_chunks(resp['payloads'])
2019-03-24 12:02:10.414 T:1546642288   ERROR:   File "/storage/.kodi/addons/plugin.video.netflix/resources/lib/MSLv2.py", line 332, in __decrypt_payload_chunks
2019-03-24 12:02:10.414 T:1546642288   ERROR:     decrypted_payload = decrypted_payload[1]['payload']
2019-03-24 12:02:10.414 T:1546642288   ERROR: KeyError: 1
go to addon data directory and delete mpd and json files and restart... it will resolve this issue, it is related to MSLv2 encryption, if this dont work, change your ESN.

I delete the files, which dit not work. Delete the complete userdats of netflix, and still it did not work.
Logging:
https://pastebin.com/in2LXMSF

does the "/usr/lib/kodi/addons/inputstream.adaptive/" directory exists?
It should include this files
RPI3:~ # ls /usr/lib/kodi/addons/inputstream.adaptive/
inputstream.adaptive.so         inputstream.adaptive.so.2.3.11
inputstream.adaptive.so.18.0    libssd_wv.so
If not, try to update your kodi to 9.0.1 again.. does not matter you already have 9.01

got the same error on windows kodi 18.1

Working fine for now, last kodi x64 dev release KodiSetup-20190401-cdab1f19-master

Fresh Install KodiSetup-20190401-cdab1f19-master-x64.exe no other plugins
still not working.. here is a log hope someone can help me :)
https://pastebin.com/B46Ht92H

Fresh Install KodiSetup-20190401-cdab1f19-master-x64.exe no other plugins
still not working.. here is a log hope someone can help me :)
https://pastebin.com/B46Ht92H

Looks that you are having problems on logon, are you able to browse "My List"... if yes, delete the files on userdata directory, just leave the settings file , restar and try to browse from AddOn, not from remote clients, exported links or playlists and share the log please.

same result here is the new log
https://pastebin.com/XzBUQz1m

reboot it, once KODI Starts wait 5 minutes, then browse netflix addon.... and tell us if you were able to login and browse.

yes im able to login and browse , but cant play anything

I just  uninstall Kodi RC, delete ProgramFiles\Kodi and C:\Users\Myname\AppData\Roaming\Kodi folders, install 20190401 version, install repository, then netflix addon and  wait until finishes, open and  try to play but I got inputstream adaptive error, it vwas not installed, so I Installed it, open netflix, and it works...
I did it as it...no config changes no extra addons, just as I just tell.... could you do it as it?
If you installed it without deleting the Roaming dirs, you will run in issues.
keep us posted

does the "/usr/lib/kodi/addons/inputstream.adaptive/" directory exists?
It should include this files
RPI3:~ # ls /usr/lib/kodi/addons/inputstream.adaptive/
inputstream.adaptive.so inputstream.adaptive.so.2.3.11
inputstream.adaptive.so.18.0 libssd_wv.so
If not, try to update your kodi to 9.0.1 again.. does not matter you already have 9.01

The dir does not exists. I found several files in ./storage/.kodi/addons/inputstream.adaptive/:
./storage/.kodi/addons/inputstream.adaptive
./storage/.kodi/addons/inputstream.adaptive/addon.xml
./storage/.kodi/addons/inputstream.adaptive/inputstream.adaptive.so.2.3.15
./storage/.kodi/addons/inputstream.adaptive/changelog.txt
./storage/.kodi/addons/inputstream.adaptive/libssd_wv.so
Reinstalled inputstream and netflix, but this din't work.
I reinstalled librelec 9.0.1, the directory still didn't exists.

try Netflix 0.14b23, I installed Librelec 9.0.1 from libreelec page, then I upgraded it to LibreELEC-RPi2.arm-9.1-Milhouse-20190327210311-#0327-g5ccaa74, after that I installed Netflix from ZIP and thats it... it worked
plugin.video.netflix-master(14.0b23).zip

How can I update to a specific version?

Updated to latest libreelec (LibreELEC-RPi2.arm-9.1-Milhouse-20190403210401-#0403-gbd69cfd.tar) installed netflix 0.14b23, looks rather promising but I still cannot play video:
I kept all settings to default.
2019-04-04 15:19:20.325 T:1790935920 WARNING: Attempt to use invalid handle -1
2019-04-04 15:19:36.583 T:1937302096  NOTICE: VideoPlayer::OpenFile: plugin://plugin.video.netflix/play/movie/80223052/
2019-04-04 15:19:36.585 T:1480954736  NOTICE: Creating InputStream
2019-04-04 15:19:37.993 T:1519383408   ERROR: EXCEPTION: argument "line2" for method "ok" must be unicode or str
2019-04-04 15:19:37.993 T:1519383408   ERROR: [plugin.video.netflix (0)] Traceback (most recent call last):
File "/storage/.kodi/addons/plugin.video.netflix/resources/lib/services/msl/http_server.py", line 47, in do_GET
data = self.server.msl_handler.load_manifest(int(params['id'][0]))
File "/storage/.kodi/addons/plugin.video.netflix/resources/lib/services/msl/msl_handler.py", line 45, in error_catching_wrapper
netflix_error=isinstance(exc, MSLError))
File "/storage/.kodi/addons/plugin.video.netflix/resources/lib/kodi/ui/dialogs.py", line 100, in show_error_info
line3=common.get_local_string(30103))
TypeError: argument "line2" for method "ok" must be unicode or str
2019-04-04 15:19:37.994 T:1480954736   ERROR: CCurlFile::FillBuffer - Failed: HTTP returned error 400
2019-04-04 15:19:37.994 T:1480954736   ERROR: CCurlFile::Open failed with code 400 for http://localhost:39713/manifest?id=80223052:
2019-04-04 15:19:37.994 T:1480954736   ERROR: AddOnLog: InputStream Adaptive: Cannot download http://localhost:39713/manifest?id=80223052
2019-04-04 15:19:37.994 T:1480954736   ERROR: AddOnLog: InputStream Adaptive: Could not open / parse mpdURL (http://localhost:39713/manifest?id=80223052)
2019-04-04 15:19:37.997 T:1480954736   ERROR: CVideoPlayer::OpenInputStream - error opening [plugin://plugin.video.netflix/play/movie/80223052/]
2019-04-04 15:19:37.997 T:1480954736  NOTICE: CVideoPlayer::OnExit()
2019-04-04 15:19:37.999 T:1519383408   ERROR: Traceback (most recent call last):
2019-04-04 15:19:37.999 T:1519383408   ERROR:   File "/usr/lib/python2.7/SocketServer.py", line 290, in _handle_request_noblock
2019-04-04 15:19:37.999 T:1519383408   ERROR:   File "/usr/lib/python2.7/SocketServer.py", line 318, in process_request
2019-04-04 15:19:37.999 T:1519383408   ERROR:   File "/usr/lib/python2.7/SocketServer.py", line 331, in finish_request
2019-04-04 15:19:38.000 T:1519383408   ERROR:   File "/usr/lib/python2.7/SocketServer.py", line 654, in init
2019-04-04 15:19:38.000 T:1519383408   ERROR:   File "/usr/lib/python2.7/SocketServer.py", line 713, in finish
2019-04-04 15:19:38.000 T:1519383408   ERROR:   File "/usr/lib/python2.7/socket.py", line 283, in close
2019-04-04 15:19:38.000 T:1519383408   ERROR:   File "/usr/lib/python2.7/socket.py", line 307, in flush
2019-04-04 15:19:38.000 T:1519383408   ERROR: error: [Errno 32] Broken pipe

ok
Let's do something...
Download this file
http://releases.libreelec.tv/LibreELEC-RPi2.arm-9.0.1.img.gz
create the SD card
and  boot with it... once finished boot, configure IP, timezone and then ssh into it
go /storage/.update
type
wget http://milhouse.libreelec.tv/builds/master/RPi2/LibreELEC-RPi2.arm-9.1-Milhouse-20190327210311-%230327-g5ccaa74.tar
once done
type
chmod 777 /LibreELEC-RPi2.arm-9.1-Milhouse-20190327210311-%230327-g5ccaa74.tar
type
reboot
then install from zip the netflix addon
once done... wait 5 mins and then restart...then go addons netflix ... type your credentials, wait for succesful login, and browse for a title... It should work
then  ssh

I found the cause.
When connected to a VPN netflix addon dit not play anyhting. Disconnection it from te VPN solved this issue

ok, cool
You might close the issue now...


Feature Request: Synchronous Worker Client methods

It would be awesome if .observe() and .connect() weren't async.
Additionally if .connect() returned the worker client again then this pattern could be used.
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css'],
})
export class AppComponent {
  constructor(private workerManager: WorkerManager) {}
  private readonly worker = this.workerManager.createClient(PrimesWorker).connect();
  public readonly outputs$ = this.worker.observe((w) => w.event);
}

Looking at .connect() it looks like it returns a promise because .sendRequest() does
https://github.com/gleosmith/angular-web-worker/blob/e599c29e095224c8fbb4e5fd53793b826a998035/angular/src/lib/worker-client.ts#L61-L93
Same with .observe()
https://github.com/gleosmith/angular-web-worker/blob/e599c29e095224c8fbb4e5fd53793b826a998035/angular/src/lib/worker-client.ts#L310-L322
And .sendRequest() creates a promise, but I am not sure it needs to. I am not noticing any promises inside it so couldn't it be synchronous?
https://github.com/gleosmith/angular-web-worker/blob/e599c29e095224c8fbb4e5fd53793b826a998035/angular/src/lib/worker-client.ts#L348-L434

No unfortunately not possible, both observe and connect communicate with the worker script through the onmessage and postMessage mechansim which needs to be async. Additionally, the connect method can trigger the onWorkerInit hook which can have an async implementation and is only resolved once this hook is resolved.

After reviewing the code further I see that sendRequest() is using .subscribe() and a callback which is where it's async nature comes from.
I have spent quite some time working with this code and cleaning it up with Strict mode in TypeScript.
I have completed most of that work however it did require a considerable amount of additional checks and optional chaining since the constructor() is not providing values and it isn't until connect() is fired that values are assigned.
If you don't mind, I would like to continue to work with this code and try to simplify it so these checks aren't needed for Strict mode.
I would also like to see if I can't find a way to enable that clean pattern I detailed above. When working under TypeScript strict mode (like I do with nearly all my angular projects) it becomes a pain when value initialization needs to be deferred to the ngOnInit() as then you need to account for the value possibly being undefined as technically between the constructor, and the first ngOnInit() (which occurs after the first ngOnChanges() it is undefined.

I have a working prototype for this feature over here.
https://github.com/wSedlacek/angular-web-worker/blob/cleanup/libs/angular-web-worker/src/client/lib/worker-client/worker-client.ts
I took some liberties with the API in attempting to tidy things up a bit.
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css'],
})
export class AppComponent {
  constructor(private workerManager: WorkerManager) {}
  private readonly client = this.workerManager.createClient(AppWorker);
  public readonly output$ = this.client.observe((w) => w.output$);

  public pushValue(): void {
    this.client.next((w) => w.input$, `New value ${Date.now()}`);
  }
}

The major changes are:

.connect() was removed and all of it's functionality was wrapped up into the constructor
.subscribe() was removed since .observe() does more or less the same thing and leaves the subscription up to the client encouraging the use of the async pipe.
.observe() returns an Observable (not wrapped in a promise)
.next() was introduced to pass values into workers via subjects.

If you are interested in these features let me know and we get a PR going on this repo.
If you aren't interested in these API changes would you mind if I published a fork of this library with these changes?

The removal of the async nature .connect() removes the ability to know when the afterWorkerInit() method has been completed (which can be async). An example would be loading data from an external service each time the worker is created, after which you can only call a method or implement some other behavior. There is no specific reason why it can't all be included in createWorker as you have done but it must be async.
I'm not sure on the idea removing .subscribe() but not completely closed to it. A subscription also exists in the worker so only exposing the observable through async pipe does not mean you don't have to worry about unsubscribing as you still need call client.unsubscribe(obs). It can also increase code overhead if need to subscribe in the ts as you will have to unsubscribe from the client by providing the observable and also unsubscribe from the independent subscription. So I guess I am questioning the need to remove something that doesn't really result in a benefit but requires more code in a particular circumstance?
I like the ideas of .observe() not wrapped in a promise and the new feature .next()
I am not keen on all the other changes you have called cleanup. The entirety of the repo structure, code and tools have been changed even to the extent of changing from jasmine to jest. Are there any non-subjective reasons for these changes? There is no reason to essentially replace the repo based on preferences as it creates additional overheads unnecessarily. Happy to consider any changes for issues, new feature, performance enhancements.

Thank you for reviewing this!
Most of the changes I made in this example simply to wrap my head around the project with code I was more familiar with.
😅  In all honestly it was quite difficult to understand what was going on at first.
Of course the entire repo structure wouldn't change for a feature PR.
I would simply make a few small PR with only the required changes for each feature based on the work I have done here.
Many of the test previously for worker-client were testing internal private methods.
I believe testing implantation is a bit of an Anti Pattern.
Source<EMAIL_ADDRESS>I stand by rewriting the test in the way I did, more test I believe need rewrites, however using Jest over Jasmine wasn't the important change as these test could be written in either.
In all honestly I just used jest because it allowed me to work with a quicker feedback loop.
I do stand by some of my renames, such as @AngularWebWorker() into @WebWorker() and angular-web-worker/angular into angular-web-worker/client
These are subjective, but I believe these names are less repetitive and more closely align with the naming structure in other Angular libraries.
You make a good point about needing to know when afterWorkerInit is complete. I will rework that.
As far as .subscribe(), I believe .destroy() removes all these subscriptions and users should be encouraged to always use this as it also calls onWorkerDestory(), Maybe .unsubscribe() should be removed from the public API to further encourage this.

You make a good point about needing to know when afterWorkerInit is complete. I will rework that.

Actually after reviewing the changes I have made it is very possible to know when the connection is completed with the new connectionCompleted() promise.

An example would be loading data from an external service each time the worker is created, after which you can only call a method or implement some other behavior.

This would look something like this.
public ngOnInit(): void {
  // Promise based for loading after the initial connection.
  this.client.connectionCompleted.then(() => this.dataService.load());

  // Observable based for loading whenever a new connection is made
  this.client.isConnected$
    .pipe(filter((connected) => connected))
    .subscribe(() => this.dataService.load());
}

Would this be sufficient?

An example would be loading data from an external service each time the worker is created, after which you can only call a method or implement some other behavior.

Sorry I want very descriptive in this use case, was meant to say that the loading data would happen in the hook . So you create the worker ->listen to connectionCompleted$ or something similar while the worker loads some external resources in the init hook -> once the worker got it data you can make calls to its methods e.t.c.
But yeah I like your idea, maybe just make connectionCompleted$ an observable so its similar to isConnected$
Where destroy won't be applicable is if you have a WorkerClient managed my a service and various components subscribe (or use async pipe) for observable from the worker. The worker may live as long as the app and in that case destroy may never be called. Although, the resources consumed by the subscriptions in the worker are very minimal as it basically just posts a message back to the client without any heavy computational logic, it still best to ensure that they are cleaned up.

Sorry I want very descriptive in this use case, was meant to say that the loading data would happen in the hook . So you create the worker ->listen to connectionCompleted$ or something similar while the worker loads some external resources in the init hook -> once the worker got it data you can make calls to its methods e.t.c.

In sendRequest() before sending the request connectionCompleted is awaited which times out after 500 ms.
      if (!opts.isConnectionRequest && !(await this.connectionCompleted)) {
        reject(
          'WorkerClient: Could not connect to the worker... Has it already been destroyed it?'
        );

        return;
      }

This would prevent any request from being made before the workerInit is completed thus I believe the scenario you are describing wouldn't be possible as if you were to make a request while the Init hook was still being settled it would just wait for the connectionCompleted then make the request whenever that was finished.
I do suppose 500ms may be a bit aggressive, it could be the default with an option passed in to createWorker() to adjust it.

I am going to attempt the extending the Observable class with hooks and see what that looks like.

Maybe something like this with proxies?
export interface SubjectHooks {
  unsubscribe?(): void;
  next?(): void;
}

export const createHookedSubject = <T>(hooks: SubjectHooks) => {
  const subject = new Subject<T>();
  const hookedFunctions = new Map<string, () => void>(Object.entries(hooks));
  const hook = (obj: Subject<T> | Subscription, prop: string | number | symbol) => {
    if (typeof prop === 'string' && hookedFunctions.has(prop)) {
      return () => {
        hookedFunctions.get(prop)?.();
        obj[prop]();
      };
    }

    return obj[prop];
  };

  return new Proxy(subject, {
    get(subjectTarget, subjectProp): any {
      if (subjectProp === 'subscribe') {
        return (...args: any[]) => {
          const subscription = subjectTarget[subjectProp](...args);

          return new Proxy(subscription, {
            get(subscriptionTarget, subscriptionProp): any {
              return hook(subscriptionTarget, subscriptionProp);
            },
          });
        };
      }

      return hook(subjectTarget, subjectProp);
    },
  });
};

// ... In `WorkerClient`
  private createObservable<ObservableType>(propertyName: string): string {
    const key = this.generateSubscriptionKey(propertyName);
    const subject = createHookedSubject<ObservableType>({
      unsubscribe: () => this.unsubscribe(key, propertyName),
    });
    this.observables.set(key, {
      subject,
      propertyName,
      observable: subject.asObservable(),
    });

    return key;
  }

The resulting behavior is whenever .unsubscribe() is called from the resulting subscription from the observable created with .observe() it would run the request to unsubscribe the observable in the worker thus completely removing the need for the consumers of the library to do anything special.


New linter: SublimeLinter-contrib-ruby-lint

https://github.com/jawshooah/SublimeLinter-contrib-ruby-lint
This linter provides an interface to ruby-lint.

:disappointed: I'm sorry this one slipped by me... Everything looks good, the codacy badge is broken though. Please make a release and I'll get this out asap.

No worries! I've been busy too. Codacy badge works fine for me, what happens when you click it?

https://github.com/SublimeLinter/package_control_channel/commit/f638e6e98dcd5a4819da12556f6b1b1dd24c3e8e
Thanks!


Fix type hint regression

Not sure what happened here but some of the file got overwritten by #2859 which broke filtering logic.
Here is it fixed back to normal.
@hwchase17 can we expedite this if possible :-)

Ok it looks like the tests are failing because pydantic is getting confused by the new optional syntax with union.
Looks like discussed here:
https://github.com/pydantic/pydantic/issues/3300
There may be a fix, but don't have time now :) Will use the old union type.


Chinese breaks multi language detection

Hello,
it looks like that chinese in a text breaks multi language detection. I know: its experimental, but it works most of the time pretty good.
Example:
`text="Płaszczowo-rurowe wymienniki ciepła Uszczelkowe der blaue himmel über berlin 中文 the quick brown fox jumps over the lazy dog"
detector=LanguageDetectorBuilder.from_languages(Language.ENGLISH, Language.GERMAN, Language.POLISH).build()
detector.detect_multiple_languages_of(text)
[DetectionResult(start_index=0, end_index=48, word_count=4, language=Language.POLISH), DetectionResult(start_index=48, end_index=77, word_count=5, language=Language.GERMAN)]
`

Hi Lutz, thank you for your report. I will try to improve the multi language detection algorithm in future releases. Your example might help in this respect.

It turns out that the cause of this issue is the same as for the issue #154 which I've just fixed with commit 67fdebc30610cc11d0b0f02756adfe62d77df247.
The output of your code after the fix is:
[
  DetectionResult(start_index=0, end_index=48, word_count=4, language=Language.POLISH),
  DetectionResult(start_index=48, end_index=80, word_count=7, language=Language.GERMAN),
  DetectionResult(start_index=80, end_index=123, word_count=7, language=Language.ENGLISH)
]

POLISH Płaszczowo-rurowe wymienniki ciepła Uszczelkowe
GERMAN der blaue himmel über berlin 中文
ENGLISH the quick brown fox jumps over the lazy dog


Separate dependencies from JS/CSS code

I would make clear what is a library/dependency and what's part of the repo. Eventually, we could add a bit of dependency management and injection (npm, bower, browserify, gulp, webpack, etc.).

I agree, the reason I included the source JS/CSS files for the dependacies was that I still wanted people to be able to clone the repo and start using it locally, without having to use a too such as npm/bower to install the dependencies.

PR #2 adds in browserify which I suggest is a good middle ground. If we upload bundle.js (as the PR does) then it's ready to run locally without any additional commands as soon as the user clones it, but we still get the modularity of browserify (which I used to avoid name collisions between the engines).

@fblecha @rts-rob I'm not necessarily suggesting to use CDNs for external libraries. I am suggesting to remove them from the repo and use a proper dependency management tool.
This way, you'd only install dependencies once at clone-time. Also, we'll be able to update libs versions over time without manually copying huge files.


Error building android plugin

Environment
node version: v16.8.0
Is used with npx or as a local dependency?

[X] npx
[ ] local dependency

Affected commands

[X] android
[ ] ios

Current behavior

As shown in the image above, the file for the Plugin nor the Package cannot be opened since the directory doesn't exist. Checking the android directory I realized the the directory was created, but the name was written lower case (.../android/app/src/main/java/com/rncamera0/xyzframeprocessor instead of .../android/app/src/main/java/com/rncamera0/XyzFrameProcessor).
Considering the previous, it works well when using a name with only lowercase characters, for instance: xyzframeprocessor.
Also I think the problem is here in the file https://github.com/mateusz1913/vision-camera-plugin-builder/blob/main/src/android.ts, specifically in the lines 221, where the folder is created with the pluginName in lowercase, and 230, where pluginName is used as the name for the folder without using the method toLowerCase on it (shown below).

*I would love to fix it myself, but I'm not quite sure how to test the command once I clone and edit it, I've only use it through npx so far.
Expected behavior
I would expect the command to work following the convention in the example in the docs of react-native-vision-camera (QRCodeFrameProcessor), or in the example in the wizard of the command (XyzFrameProcessor), which is PascalCase.
Reproduction repository link
https://github.com/Lucianofc138/vcpb-issue-reproduction-0

Hey @Lucianofc138, thx for that detailed report 🚀
If you would like to make a PR and run cli locally, you can just clone the repo and build it with yarn build - it will produce build folder with index.js inside. Then you can just type node <path-to-cloned-repo-build-index-js-file> android from your library/app directory and it will use your locally built cli
If you'll have any problems, feel free to ask. And if you'll not able to make a PR, I will try to fix later this week

(I miss clicked and close the issue. My bad. )
I made a PR with the changes needed to fix the issue. I tried them and it worked for me. I hope it doesn't break anything.

@Lucianofc138 thx for your contribution! Your fix is available in v0.1.1 🚀  - if you use cli with npx, you might have old version cached. Try to npx vision-camera-plugin-builder@latest <command>, if it won't update to 0.1.1, try to clear npx cache (npm config get cache will ist directories with cached libraries - try to find one for cli and remove it)


Is there a paper presenting bark?

Is there a paper presenting bark?

Closing as duplicate of https://github.com/suno-ai/bark/issues/177


⚠ Bofrost.de has degraded performance

In b4b2731, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1394 ms

Resolved: Bofrost.de performance has improved in 0086274.


Feature Request - Custom Fonts per screen

Some screens benefit from a tiny font. For example when you want to display a 5-digit number.
Other screens only need 3-4 digits (temperature, humidity, etc) and look nice with a larger font.
This FR is to allow an optional screen_font: that would override the default font.

Well, i thought about this but first only for the clock. For the clock you need a font with numbers at 6 pixels high. For normal screen 7 to 8 pixels are also fine.
I will consider this in an upcoming release!

I think the x/y offset setting should also be configurable or maybe even a subkey of the font.  Thanks for your hard work on this, the results are amazing, so easy to configure from home assistant.

in the upcoming 2023.5.0 will be two fonts e.g. one with 6 pixel height (for date and time) and a font 8 pixel heigh for the rest. its working in the alpha version.

@lubeda you are the real MVP.  <3 my esphomatrix devices


Service Events - Register/Unregister API update

Based on comments in https://github.com/hyperledger/aries-framework-go/pull/240#discussion_r325332114
The current code behaviour is as follows.

If consumer doesn't call RegisterEvent or RegisterAutoExecute - service will not handle messages and throw error for incoming messages.
If consumer doesn't call RegisterEvent and calls RegisterAutoExecute - service will auto execute the messages.
If consumer doesn't call RegisterAutoExecute and calls RegisterEvent - service will trigger the event and wait for callback
If RegisterAutoExecute and RegisterEvent both are called - service will behave same as pt#2 or pt#3 based on which was registered last.
If RegisterAutoExecute and RegisterEvent both are called AND service calls either UnregisterAutoExecute or  UnregisterEvent - service will behave same as pt#1.
If consumer calls RegisterEvent twice - last channel registered will receive the message.
If any consumer calls UnregisterEvent - service removes the event irrespective of the consumer

The changes required.

Throw error if Register event is called second time with different channel (pt#6)
Support to pass channel as argument in UnregisterEvent(pt#7) - throw error if trying to unregistered with different channel than the one used in RegisterEvent
If RegisterAutoExecute and RegisterEvent both are called AND service calls either UnregisterAutoExecute or UnregisterEvent -- fallback to  pt#2 or pt#2 based on unregister function call.

@troyronda Please have a look and let me know if anything is missing or incorrect.

Note: this point from the top post doesn't make sense considering pts 1, 2 and 4

If RegisterAutoExecute and RegisterEvent both are called AND service calls either UnregisterAutoExecute or UnregisterEvent - service will behave same as pt#1.

Aren't these the possible states?

AutoExecute
RegisterForEvents
Result

enabled
disabled
execute protocol automatically

disabled
enabled
fire events, wait for callbacks

disabled
disabled
return error

enabled
enabled
impossible

This suggests that calling RegisterEvent should also call UnregisterAutoExecute() and RegisterAutoExecute() should call UnregisterEvent(). Note that the Unregister* functions should not call their Register* counterparts because it looks like we want to keep the disabled/disabled state?

Note: this point from the top post doesn't make sense considering pts 1, 2 and 4

If RegisterAutoExecute and RegisterEvent both are called AND service calls either UnregisterAutoExecute or UnregisterEvent - service will behave same as pt#1.

Yes, this was in pt#3 in my second post. We can discuss about the ideal behaviour for this case.

Aren't these the possible states?
AutoExecute	RegisterForEvents	Result
enabled	disabled	execute protocol automatically
disabled	enabled	fire events, wait for callbacks
disabled	disabled	return error
enabled	enabled	impossible
This suggests that calling RegisterEvent should also call UnregisterAutoExecute() and RegisterAutoExecute() should call UnregisterEvent(). Note that the Unregister* functions should not call their Register* counterparts because it looks like we want to keep the disabled/disabled state (not to mention a nice stackoverflow if we follow my previous suggestion)?

That's an implementation details. From behaviour/requirement point of view, the question is should the service implicitly change the behaviour or should we make the consumer to UnregisterX and then call RegisterY (X/Y = AutoExecute/Event).

@rolsonquadras looks like you and I are on the same page: we're trying to make sense of all scenarios here and pick the ones we want to implement.
I attempted to make sense of it all in my previous comment. I suggest we map them out as such to improve clarity because it is getting hard to follow what's going on.

Added diagram for current and proposed behaviour.
Current Behaviour:

Proposed Behaviour:

@troyronda @llorllale any feedback on the proposed behaviour ?

Are you proposing using Deregister rather than Unregister? I assume this was a typo?
It appears that you are proposing two functions that do the same thing. UnregisterEvent vs UnregisterAutoexecute. Are you planning to have a difference?

I would consider replacing the AutoExecute mechanism with a utility function that simply calls the callbacks.
The auto execute APIs are a bit of a wart, IMO.

@troyronda @llorllale As per our discussion and above input, I have updated the proposed design flow.


[tests-only][full-ci]remove api bug demonstration scenarios that are covered by exected-to…

Description
This PR removes the apiBugDemonstration tests as they're present in core and mentioned in expected-to-fail file.
Changes made by this PR:

Remove feature files that contain scenarios present in the core and covered by expected-to-fail-file.
Refactor duplicate entries in expected-to-fail-file

Related Issue

part of : https://github.com/owncloud/ocis/issues/2313

Motivation and Context
We have some local API tests in ocis  that demonstrates the bugs but those tests are already present in core and are mentioned in expected-to-fail-file. If the tests start passing we'll know and the local API bug demonstration tests are not necessary in ocis.
How Has This Been Tested?

CI

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[x] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[ ] Acceptance tests added
[ ] Documentation ticket raised:

@phil-davis
Scenarios in this feature file
https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiBugDemonstration/apiWebdavPreviews-previews.feature
are tagged @skipOnOcis
https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavPreviews/previews.feature
so I haven't removed them.

@phil-davis
Scenarios in this feature file
https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiBugDemonstration/apiWebdavPreviews-previews.feature
are tagged @skipOnOcis
https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavPreviews/previews.feature
so I haven't removed them.

I made PR https://github.com/owncloud/core/pull/39092 to core. That should help as to then remove apiWebdavPreviews-previews.feature from OCIS tomorrow.


Add ACL groups

Codecov Report

Merging #103 into master will not change coverage.
The diff coverage is 100%.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 54d347a...bb956d7. Read the comment docs.


Empty ComboField throws when requireSelection:true and option selected

Can reproduce in Toolbox forms tab:

Add requireSelection: true to the "State" comboField
Type a character in empty-to-start field to pop up list of options
Choose one - exception thrown to console

In that same example -

I defaulted the starting value of state on the model to 'CA'
Form load showing California as intended
I am unable to change the value away from California by interacting with the form. 🤕

I do not know if this is a general issue with the form or if it could be something specific to toolbox.

This seems to be related to how we are checking if the input is a valid choice, i.e. a selection from the available options. When a user inputs a value (without selecting), we check that it matches the label of a given options, as we don't expect the user to be aware of underlying values. At that time the internalValue of the field is the users input.
However when the user selects an available option the internal value is then set to the VALUE of the underlying option. Sometimes the value and the label are the same in which case we have no problem. In our particular case the values and labels do not match (e.g. CT and Connecticut). Therefore we revert to the previous external value. Which is why ATM cannot seem to navigate away from California in his example. Not sure about the exception, but that might be because we are reverting to the inital value of 'null'?
Not sure what the solution is yet, but I wanted to leave this here for reference.

The exception is indeed cause by the initial null, but not because of the reversion (we don't get that far). It's caused because doCommit is triggered onBlur before we get so far as setting the internal value. So two separate problems.
A third issue is when we find an Exact match to the label but 'do nothing' as we 'have a match'. Our internal value matches the label, but that value doesn't necessarily match the underlying value. This is the easiest of the three to fix.


develop is behind main by many months, where do I put PR?

The develop branch is several months behind main.
Should I submit my PR to the old develop or the current main or ??

Feel free to point it to main


Use getOurPreimage for this node

In Ledger.validateBlockSignature we can use getOurPreimage for the current node.
Although the preimage should also be available via the getPreimageAt which
we must use for other nodes we should be able to get our preimage from our cache.

Works locally. Needs unittest fixes.

I'd like to avoid special casing the node's preimage / key as much as possible. Why use getOurPreimage if it is available via the ValidatorSet ?

Do you have any pending fixing for the fact that we do not always have the node's preimage in the validatorSet? If not I can take a look at how we get into this situation.

Do you have any pending fixing [...]

Yes. We have We have https://github.com/bosagora/agora/commit/9101d1ad0d325301d24ffdc9a009b8b6fa192164 now, but I missed one case (catchup), will submit the PR now.

Closing this PR as other PRs in progress by @Geod24 will prevent the situation where the node does not have it's own preimage stored in the validatorSet. The overhead of fetching from the db is not significant enough to justify having a special case for using our cache of preimages.


How to use voxelsdk for android platform

I'm trying to use 3dtof for my android TV application. What should I do? Thanks for your anwser.

It is not directly supported. However, there have been previous successful
attempts.
One on issue tracker - https://github.com/3dtof/voxelsdk/issues/45
If you want to built for native Android:

Get necessary dependencies ready for Android. If you need PCL, see
https://github.com/PointCloudLibrary/pcl/wiki/Android. If PCL is not needed
then you can comment out add_subdirectory(VoxelPCL) and
add_subdirectory(Apps) in the main CMakeLists.txt. This would mean thst the
Apps will not be built. But several simple programs in Tests/ will still be
built.
Second thing to do is to get cmake work with android NDK. See
https://github.com/taka-no-me/android-cmake which could help in this
context.
Once your have libraries (.so) built for Android and you are able run
simple Voxel SDK (non-GUI) programs to capture, etc.  from adb shell, next
step is to write a NDK native (Java) wrapper for your app which invokes SDK
API.

This is unofficial and you may need to put some effort to get things in
place.
On 28 April 2016 at 07:34, wu.liu<EMAIL_ADDRESS>wrote:

I'm trying to use 3dtof for my android TV application. What should I do?
Thanks for your anwser.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/3dtof/voxelsdk/issues/73

--
~ Prasad Bhat

Thanks for replying soon,I will try it.

help ! I got a problem .
if(!depthCamera->isInitialized())
{std::cerr << "Depth camera not initialized for device " << toConnect->id() << std::endl;
return env->NewStringUTF("Depth camera not initialized for device ");
}
I can not initialize Depth camera.
Please give me some help., thank you.

My App was run on Android L.

@tryBetter , I was having this error too, in my case it was the previleges to access the usb port, I solve it by modifying boot.img and giving root access to all users on USB port, then I flashed this new image and everything works like a charm. To edit boot.img I've used a tool called bootimg.exe, there are tutorials for doing this on internet. Almost forgot, it was needed to change libusb to a specific version and also in android L I need to set the Permissive mode using the setenforce command.

@AlexanderSilvaB , Thank you ! It workes for me . Change my usb dev permission to '0666' and setenforce .

@tryBetter Hi，I'm trying to use voxelsdk on android platform, but don't kow how to get started. Could you give me some instructions or compiled voxelsdk for android? Thank you very much!

@tryBetter Hi, Hi，I'm trying to use voxelsdk on android platform, but don't kow how to get started. Could you give me some instructions or compiled voxelsdk for android? Thank you very much!


ASP.NET Core sample

Still no asp.net core example of this, despite this being the current direction of active development. Can we please have one ASAP please

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c8d9b842-de22-59e7-e36a-662e2060ae7a
Version Independent ID: bda934c5-a268-721f-1a3e-1f73fc25c15f
Content: ASP.NET MVC tutorial for Azure Cosmos DB: Web Application Development
Content Source: articles/cosmos-db/sql-api-dotnet-application.md
Service: cosmos-db
GitHub Login: @SnehaGunda
Microsoft Alias: sngun

@jjgriff93 Thank you very much for your detailed feedback. I have assigned this to the content author to evaluate and update as appropriate.
Just a note, there is this tutorial but it doesn't include Cosmos DB.
Regards,
Mike

@jjgriff93 I think this is related to other issue you opened, sample to build a  .Net core app is here: https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-dotnetcore-get-started

Thanks @Mike-Ubezzi-MSFT , @SnehaGunda - the problem is it's only for .NET Core, not an ASP.NET Core webapp. Currently we seem to only have an ASP.NET example with Cosmos DB so would be nice to have an updated ASP.NET Core Cosmos DB tutorial showcasing the latest technologies

@jjgriff93 I had a chat about this with our dev team and they confirmed that same sample should work with ASP.Net core as well. Did you had a chance to try it or run into any issues?

@SnehaGunda please see my response on the other thread - the example will not work in ASP.NET Core without some changes

You mentioned that ASP.NET Core without some changes. What are these changes?  I am trying to run some test cases for an ASP.NET Core application and the MongoClient keeps timing out when using the connection string to use the CosmosDb emulator from within the Build. (if this is not the correct location for this query, please excuse me -- where might be the correct location?)

hi @shivangipatwardhan2018 the link is here: https://github.com/MicrosoftDocs/azure-docs/issues/16435#issuecomment-429269348 - however it sounds to me like the issue is unrelated to that. I'd post up a separate issue on the cosmos DB GitHub page to see if they can help

@jjgriff93 and @shivangipatwardhan2018 I have shared this feedback with our engineering teams, we have a work item in our backlog to provide new samples for .Net core. Currently, we are revamping some conceptual docs, once those are done, we will get to these tutorials probably around end of this month.
We will close this issue and track it as an Azure DevOps work item.

#please-close

Where is the .NET Core example?


Support non-flat topologies

Explore topological possibilities and decide how to support them in site navigation, directory tree structure, and links.

So as I've been working on this, I'm realizing the problem isn't (wasn't) just site navigation, but also navigation within Obsidian. I want to be able to use Obsidian's nav/linking powers too.
You can now just link absolute paths in the source Markdown, and both Obsidian and web will read them correctly. So, the additional problem raised in this comment has also been resolved.
Back to the original issue, we now have this order of operations:

If foo.md is requested, foo.md will be served.
If foo is requested, try these:

foo/index.md
foo.md

If you want foo.md, you'll have to link to it specifically. foo/index.md can be used as a directory of its children. How or whether to integrate this into the sitewide nav bar is unresolved.

I'm not sure how exactly I feel about it, but this has been fixed enough for now.


french translation of "state" is wrong

now the state translation in french is "était",  should be "état"
this mistake is enoying because the state shown "était ouvert" means "was opened", with this wrong label people think that this info is the right one and confuse a lot, because they are waiting for the state now and not the state before.
could you just change the translation.
I think it's not a very big change but it's a very big consequence.
many thanks

Duplicate of #104

sorry but i don't understand is it still wrong or is it upadated with the right message ?


Integration test for DataCap actor

:link: zboto Link

We should check if data cap actor is exported as singleton on the ref-fvm package. If it is, we can close this issue. If it is not, we will need to add it, as we have done for other actors like power and market.


[DOC] Explain "Contract-Based Accounts"

Is your feature request related to a problem? Please describe.
We use the term "contract-based accounts" constantly in marketing materials now but there's actually nowhere that it's explained (that I can find) in the docs and it's led to some confusion.
Describe the solution you'd like
A section within an existing flow (or a new section) which explains how the contract model works and which is linkable from lots of external places would be ideal.  Something terse and technical but which still nods to the business value of this since people linking may be only semi-technical and just wanting to learn one level deeper.
Ideally this should be linked from many places in the docs so it's really easy to find (like "if you want to learn more about NEAR's Contract-based account model, go here...")
Additional context
Contract-based accounts are described as offering lots more flexibility for enabling permissions, automations, etc but what are they actually?  This is Illia's explanation via a Slack thread which can probably be the basis for a few paragraphs and an example block:
each account has contract_hash
this hash can be 0x0 - then there is no code
or not 0x0 - and then there is code
when we say “contract” we usually mean an account with some deployed code e.g. contract_hash != 0x0, which doesn’t really behave as an account of an individual but represents some applications storing data
contract-based account is an abstraction to describe specific behavior: an account that has contract that controls access to this account
underlying it’s all treated the same.
the easiest to understand is to think that on every account has some code, this code can be empty (contract_hash == 0x0)  . Because you can still try calling methods on a account that has empty code - it just will fail without finding that method.

So I imagine:

High level explanation of how every account is linked to a contract, which means that methods can be called on that account.  If there isn't a contract linked, that's fine, you just get a standard method-not-found.
A few ways this comes up in code (nod to Illia's description of how this is more of an app-oriented behavior than individuals, though it does apply to lockup contracts atop early holder accounts.)

@eriktrautman does this page address some / all of your request?
https://docs.near.org/docs/concepts/account

there's also this bit that includes a bullet point list of related information
https://github.com/near-examples/workshop--exploring-near-apis#accounts

Thanks! Noting Evgeny's explanation too: https://docs.google.com/document/d/1gGGQrKS5twgiLEtgwP0PEZVG176K1Nea9lRgiDsFznA/edit
I think perhaps adding a section that specifically uses the term "contract-based accounts" and notes what Illia said would be helpful (especially so it's searchable) but within this page is likely a good spot.


Implement finite source point lens

Implemented in 72025bc30b880255402ed818c613bb6b641c7202. There are further optimizations possible, for example only evaluating the lens equation for half of the source boundary.


fix failed test for network package darwin

qiwang@Qi15Pro network % go test -cover
--- FAIL: TestConnectionReadWrite (0.00s)
    network_test.go:293: "connection read/write" expect "a good news from udp client.", got ""
    network_test.go:293: "connection read/write" expect "天下风云出我辈，一入江湖岁月催。", got ""
--- FAIL: TestSendBranch (0.04s)
    network_test.go:787: "detect server detached from client" client send
        "detect server detached from client" to server, server got
        ""
    network_test.go:803: "detect server detached from client" expect log
        "#send server now detached from client", got
        ""
    network_test.go:809: "detect server detached from client" client receive
        "detect server detached from client" from server, client got
        ""
--- FAIL: TestRecvCongestionPacket (0.02s)
    network_test.go:1062: "receive congestion packet branch" expect
        "#recvOne received explicit congestion notification", got
        ""
--- FAIL: TestRecvSRTT (0.22s)
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "0 round from server to client", got ""
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "1 round from server to client", got ""
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "2 round from server to client", got ""
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "3 round from server to client", got ""
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "4 round from server to client", got ""
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "5 round from server to client", got ""
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "6 round from server to client", got ""
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "7 round from server to client", got ""
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "8 round from server to client", got ""
    network_test.go:1128: "receive packet to calculate SRTT/RTTVAR" expect "9 round from server to client", got ""
    network_test.go:1133: "receive packet to calculate SRTT/RTTVAR" RTTHit=false SRTT=1000.000000, RTTVAR=500.000000
    network_test.go:1138: "receive packet to calculate SRTT/RTTVAR" expect timeout 50, got 1000
--- FAIL: TestConnectionRecvSeqFail (0.00s)
    network_test.go:1223: "connection recv seq fail" expect "first message.", got ""
    network_test.go:1229: "connection recv seq fail" expect
        received explicit out-of-order packets, got
        time=2024-03-11T11:26:45.674+08:00 level=DEBUG source=/Users/qiwang/dev/aprilsh/network/network.go:469 msg=dialUDP pid=17890 ip=localhost port=60800 localAddr=[::1]:55971 remoteAddr=[::1]:60800

--- FAIL: TestSenderSendEmptyAckShutdown (0.02s)
    sender_test.go:408: #test recv repeat expect<PHONE_NUMBER>3709551615, got 0
    sender_test.go:409: #test receivedState length=1
--- FAIL: TestSenderSendToReceiverShutdown (0.02s)
    sender_test.go:528: #test recv repeat expect<PHONE_NUMBER>3709551615, got 0
--- FAIL: TestSenderTickVerify (0.09s)
    sender_test.go:645: #test client send "Keystroke:\"first mock input.\", Resize:, size=17" to server, server receive "Keystroke:\"\", Resize:, size=0" from client
    sender_test.go:654: #TestSenderTickVerify expect contains "tick Warning, round-trip Instruction verification failed", can't find it
    sender_test.go:654: #TestSenderTickVerify expect contains "tick Warning, target state Instruction verification failed", can't find it
--- FAIL: TestSenderSendInterval (0.12s)
    sender_test.go:693: #test sendInterval expect "0 round from server to client", got ""
    sender_test.go:693: #test sendInterval expect "1 round from server to client", got ""
    sender_test.go:693: #test sendInterval expect "2 round from server to client", got ""
    sender_test.go:693: #test sendInterval expect "3 round from server to client", got ""
    sender_test.go:693: #test sendInterval expect "4 round from server to client", got ""
    sender_test.go:693: #test sendInterval expect "5 round from server to client", got ""
    sender_test.go:693: #test sendInterval expect "6 round from server to client", got ""
    sender_test.go:693: #test sendInterval expect "7 round from server to client", got ""
    sender_test.go:693: #test sendInterval expect "8 round from server to client", got ""
    sender_test.go:693: #test sendInterval expect "9 round from server to client", got ""
    sender_test.go:701: #test sendInterval expect interval 250 < 20
--- FAIL: TestTransportClientSend (0.09s)
    transport_test.go:68: #test client send "Keystroke:\"Test client send and server empty ack.\", Resize:, size=38" to server, server receive "Keystroke:\"\", Resize:, size=0" from client
    transport_test.go:76: #test client sentStates expect first num 1, got 0
--- FAIL: TestTransportServerSend (0.08s)
    transport_test.go:124: #test server send expect remote address <nil>, got nil
--- FAIL: TestTransportRecvVersionError (0.02s)
    transport_test.go:226: #test recv error expect "aprilsh protocol version mismatch.", got "i/o timeout"
--- FAIL: TestTransportRecvRepeat (0.07s)
panic: runtime error: index out of range [1] with length 1 [recovered]
        panic: runtime error: index out of range [1] with length 1

goroutine 226 [running]:
testing.tRunner.func1.2({0x100394180, 0xc00001a138})
        /usr/local/go/src/testing/testing.go:1545 +0x238
testing.tRunner.func1()
        /usr/local/go/src/testing/testing.go:1548 +0x397
panic({0x100394180?, 0xc00001a138?})
        /usr/local/go/src/runtime/panic.go:914 +0x21f
github.com/ericwq/aprilsh/network.TestTransportRecvRepeat(0xc0006011e0)
        /Users/qiwang/dev/aprilsh/network/transport_test.go:263 +0x625
testing.tRunner(0xc0006011e0, 0x1003d1638)
        /usr/local/go/src/testing/testing.go:1595 +0xff
created by testing.(*T).Run in goroutine 1
        /usr/local/go/src/testing/testing.go:1648 +0x3ad
exit status 2
FAIL    github.com/ericwq/aprilsh/network       4.876s
qiwang@Qi15Pro network %

for linux the network package is ready.
ide@openrc-nvide:~/develop/aprilsh/network $ go test -cover
PASS
coverage: 100.0% of statements
ok      github.com/ericwq/aprilsh/network       2.272s

for linux:
ide@openrc-nvide:~/develop/aprilsh/network $ go test -cover .
ok      github.com/ericwq/aprilsh/network       2.475s  coverage: 100.0% of statements

for macOS:
qiwang@gauss network % go test -cover .
ok  	github.com/ericwq/aprilsh/network	2.632s	coverage: 99.4% of statements


initial stickyScroll support for notebooks

re: #182444

Looks good.

Polish

[ ] CSS for Hover
[ ] Click entry to navigate (`INotebookEditor.reveal*)
[ ] Drop shadow
[ ] Right click to show context menu and hide

Debt

[ ] Unify initialize and update
[ ] Unit test
[ ] globalToolbarHeight


Describe new way to clone objects and add benchmark to show why.

Show why JSON.parse(JSON.stringify(object)) is a good alternative of lang.clone(object) when trying to clone objects (3x times faster???).
Reviewers

[x] @alvaroortega
[x] @basil-conto
[ ] @floridemai
[x] @full-of-foo
[ ] @io41
[ ] @jrochenrfm
[ ] @ldoran
[x] @marzetas
[ ] @PieceOfMeat

:sheep:

:shipit:

Shouldn't this be a common library function? CMN.utils.clone() or something like that?

@io41 Good point; I would be in favour of that.

@io41 really? Do you think is necessary CMN.utils.clone? I think is not fully necessary but I'm not against.

Closing old PRs


DataTable: No error if the number of columns and cells doesn't match

Please could you throw an error in the case that the number of columns in the heading row and cells per row are not the same.
I got only a grey area where the datatable should be.
(Version 0.5.0.dev1211)
Thanks

Should be solved in the latest version:
https://github.com/flet-dev/flet/blob/fdf54b6948b0b4e985dd736475e427c386321cbe/sdk/python/packages/flet-core/src/flet_core/datatable.py#L458-L461


ClientModel: experiment with moving retry policy

Closing in favor of https://github.com/Azure/azure-sdk-for-net/pull/40308


Harness: Add orgP and projectP

Adding TF files for orgP and projectP

✅ Terraform plan complete!
Planned Changes
5 Added ~ 0 Changed ~ 0 Deleted ~ 40 Unchanged

Change
Provider
Type
Name
Module
Changes

-
registry.terraform.io/harness/harness
harness_platform_organization
organization[0]
module.organization_orga
0

-
registry.terraform.io/hashicorp/time
time_sleep
organization_setup[0]
module.organization_orga
0

-
registry.terraform.io/harness/harness
harness_platform_organization
organization[0]
module.organization_orgb
0

-
registry.terraform.io/hashicorp/time
time_sleep
organization_setup[0]
module.organization_orgb
0

-
registry.terraform.io/harness/harness
harness_platform_organization
organization[0]
module.organization_orgc
0

-
registry.terraform.io/hashicorp/time
time_sleep
organization_setup[0]
module.organization_orgc
0

-
registry.terraform.io/harness/harness
harness_platform_organization
organization[0]
module.organization_orgd
0

-
registry.terraform.io/hashicorp/time
time_sleep
organization_setup[0]
module.organization_orgd
0

-
registry.terraform.io/harness/harness
harness_platform_organization
organization[0]
module.organization_orge
0

-
registry.terraform.io/hashicorp/time
time_sleep
organization_setup[0]
module.organization_orge
0

-
registry.terraform.io/harness/harness
harness_platform_organization
organization[0]
module.organization_orgf
0

-
registry.terraform.io/hashicorp/time
time_sleep
organization_setup[0]
module.organization_orgf
0

-
registry.terraform.io/harness/harness
harness_platform_organization
organization[0]
module.organization_orgg
0

-
registry.terraform.io/hashicorp/time
time_sleep
organization_setup[0]
module.organization_orgg
0

-
registry.terraform.io/harness/harness
harness_platform_organization
organization[0]
module.organization_orgh
0

-
registry.terraform.io/hashicorp/time
time_sleep
organization_setup[0]
module.organization_orgh
0

added
registry.terraform.io/harness/harness
harness_platform_organization
organization[0]
module.organization_orgp
5

added
registry.terraform.io/hashicorp/time
time_sleep
organization_setup[0]
module.organization_orgp
4

-
registry.terraform.io/harness/harness
harness_platform_project
project[0]
module.project_projectA
0

-
registry.terraform.io/hashicorp/random
random_id
color_picker[0]
module.project_projectA
0

-
registry.terraform.io/hashicorp/time
time_sleep
project_setup[0]
module.project_projectA
0

-
registry.terraform.io/harness/harness
harness_platform_project
project[0]
module.project_projectB
0

-
registry.terraform.io/hashicorp/random
random_id
color_picker[0]
module.project_projectB
0

-
registry.terraform.io/hashicorp/time
time_sleep
project_setup[0]
module.project_projectB
0

-
registry.terraform.io/harness/harness
harness_platform_project
project[0]
module.project_projectC
0

-
registry.terraform.io/hashicorp/random
random_id
color_picker[0]
module.project_projectC
0

-
registry.terraform.io/hashicorp/time
time_sleep
project_setup[0]
module.project_projectC
0

-
registry.terraform.io/harness/harness
harness_platform_project
project[0]
module.project_projectD
0

-
registry.terraform.io/hashicorp/random
random_id
color_picker[0]
module.project_projectD
0

-
registry.terraform.io/hashicorp/time
time_sleep
project_setup[0]
module.project_projectD
0

-
registry.terraform.io/harness/harness
harness_platform_project
project[0]
module.project_projectE
0

-
registry.terraform.io/hashicorp/random
random_id
color_picker[0]
module.project_projectE
0

-
registry.terraform.io/hashicorp/time
time_sleep
project_setup[0]
module.project_projectE
0

-
registry.terraform.io/harness/harness
harness_platform_project
project[0]
module.project_projectF
0

-
registry.terraform.io/hashicorp/random
random_id
color_picker[0]
module.project_projectF
0

-
registry.terraform.io/hashicorp/time
time_sleep
project_setup[0]
module.project_projectF
0

-
registry.terraform.io/harness/harness
harness_platform_project
project[0]
module.project_projectG
0

-
registry.terraform.io/hashicorp/random
random_id
color_picker[0]
module.project_projectG
0

-
registry.terraform.io/hashicorp/time
time_sleep
project_setup[0]
module.project_projectG
0

-
registry.terraform.io/harness/harness
harness_platform_project
project[0]
module.project_projectH
0

-
registry.terraform.io/hashicorp/random
random_id
color_picker[0]
module.project_projectH
0

-
registry.terraform.io/hashicorp/time
time_sleep
project_setup[0]
module.project_projectH
0

added
registry.terraform.io/harness/harness
harness_platform_project
project[0]
module.project_projectP
8

added
registry.terraform.io/hashicorp/random
random_id
color_picker[0]
module.project_projectP
8

added
registry.terraform.io/hashicorp/time
time_sleep
project_setup[0]
module.project_projectP
4

Outputs
No outputs present
View details in Harness


[Fix](inverted index) fix memory leak in inverted index writer for array values

Proposed changes
Issue Number: close #xxx
Add ownership flag to Field's TokenStream value and Analyzer's Reader value, free them when tokenizer finalize.

run  buildall

run buildall


What is coldstart.class used for?

hey, I've been reading your project code recently, it's awesome work and I don't know the usage of cold start, so cloud you please explain it? It would be very helpful for me， Thanks

For example, you want sync a table in MySQL to ES for search. For two reasons, we need cold-start:

First, in production env, the binlog of MySQL always has expire settings, which means you don't have all writes/updates to sync.
Second, a table with 10 rows may have tens of GB binlog, which is not fast to sync

I got it, thanks!