failable functions instead of error union type

See https://github.com/zig-lang/zig/issues/632#issuecomment-350145538 for the current iteration of this proposal.
everybody hates %. what can we do about it?

leave % alone as far as types go. %T is still how you make an error union on T.
replace %%x with tryfail x
replace %return x with tryret x
replace a %% b with a tryor b
replace %defer with trydefer

It would be handy for readability if these new keywords could be also written as try-fail, try-ret, ..., or at least as try_fail, try_ret, ...

Proposal iteration:

Keep a %% b because it mirrors a ?? b which works the same as C#.
But change it to a !! b.
Remove %%x. Instead use x !! unreachable.

Remove the %T type. Instead, functions can fail:
fn foo(x: i32) fail -> i32 {
    if (x < 0)
        return error.ExpectedPositiveNumber;
    if (x % 2 == 0)
        return error.ExpectedOddNumber;
    return x - 1;
}

Here, we introduce the fail keyword. The compiler is able to determine the set of possible error values that foo can return.
@typeOf(foo) is: fn(i32) fail (ExpectedPositiveNumber, ExpectedOddNumber) -> i32
foo can be implicitly casted to fn(i32) fail -> i32 which allows any set of error codes.
foo cannot be implicitly casted to fn(i32) fail(OutOfMemory) -> i32 which is only allowed to fail with error.OutOfMemory.
foo can be implicitly casted to fn(i32) fail(OutOfMemory, ExpectedPositiveNumber, ExpectedOddNumber) -> i32 which is allowed to fail with a superset of the set of failures that foo can have.

Change %defer expr; to fail defer expr;
Change %return expr to try expr
If we wanted to keep %%x it could be fail x.

Now there is no more % to mean error, and we we only have !! infix operator to match ??.
Now it becomes straightforward to allow multiple return values from a block:
fn div(a: i32, b: i32) fail -> i32, i32 { ... }

Now consider:
var xxx: error = undefined;
fn bar() fail {
    return xxx;
}

This is a compile error; Zig cannot determine the set of possible error codes. To fix:
var xxx: error = undefined;
fn bar() fail(OutOfMemory, SomeOtherError) {
    return xxx;
}

Now there is a runtime safety check that makes sure that bar only returns errors from the allowed set.
You might want to make the set of possible errors depend on some other function:
var xxx: error = undefined;
fn bar() fail(OutOfMemory, SomeOtherError, @errorsOf(foo)) {
    return xxx;
}

Now I'm thinking about how the error type might want to know the set of possible errors it could be.
We want to make it so that if you switch(err) we can give compile errors for missing possible error codes.

+1 for separating the error channel from the return values.
We may want to avoid conflating the terms "error" and "fail". This gets especially confusing when writing test harnesses, so it'd be nice to stick to just one term. Other languages use the term "exception" for this kind of thing, or even "signal". I think "error" is a good word for this.
Thanks to error being a keyword, all of your example uses of fail can be replaced with error and we have no ambiguity, except for fail x, but I think we should remove that anyway.
I think the @errorsOf(foo) idea needs some work. Let's not include that in this proposal.

If the compiler always forces one to handle returned errors (either "consuming" them or passing them up) then it would be redundant to annotate a function with fail. User will be always reminded when he makes a mistake.
This detail plus list of all possible errors can be shown automatically by an IDE.

Semantics of the fail(list of all errors) construct should be fail(list of errors invisible to the compiler which can be also returned). Listing all possible errors can be tedious to almost impossible, if the error generating code is conditionally compiled.
Example:
var xxx: error = undefined; // can be ThisError or ThatError
fn foo(comptime bool b) fail(+ThisError, +ThatError)
{
  if (...) return xxx;
  if (b) return OutOfMemoryError;
  else return SomeOtherError;
}

Other syntax which eliminates fail(list) completely:
var xxx: error = undefined;
fn foo()
{
  if (...) return xxx <ThisError | ThatError>;
}

If and only if compiler cannot deduce which error is returned it has to be supplied manually by the programmer. Compiler would then check for obvious mistakes.
This moves the error list into the most relevant place. Local or non-local change do not affect function signature.

fail annotation is fragile to changes in environment.
fn foo(comptime  b : bool) fail???
{
  if (b) return SomeError;
}

Pessimization (when in doubt label it as fail) would result in awkward situations where function is annotated but the (smart enough) compiler refuses to accept any error handling when such function is called, because there's nothing to handle. Whole function chains could be subject to this.

If there's annotation which may be useful and non-fragile it would be no-fail for library APIs, giving the user assurance that whatever happens inside stays inside.
// no need to worry that something unexpected leaks out of this function
pub fn foo() no-fail
{
  ...
}

exported function should be no-fail by default.

Personally I prefer using sum types (was enum, now maybe enum struct?) to handle this:
fn foo(aVal: bool) -> enum { i32, err1, err2, err3 ... }
{
... some code ...
    return err1; <-- needs to automatically set the result type.
...
}

In the calling code you would use switch to take apart the return type.  The compiler can check all possible types returned from foo and that a caller handles all possible return types.   No extra syntax at all as far as I can tell.  I think this works now.
Note that this also covers the case that a function needs to return different types than just errors and one other type.   The caller still has to switch to figure out what was returned.
This does not cover the !!/%% case but there is probably something to be done there that would be relatively simple.

For someone who actually likes the % sigils and status-quo error handling, I quite like the direction that @andrewrk's proposal is going, and I agree with @thejoshwolfe that we should stick with one keyword.
@thejoshwolfe: Could you elaborate on why you think it's particularly valuable to separate the return values from the error channel?
On the other hand, I share @kyle-github's appreciation of sum types. The error enum concept is nice, and if the main objective is to remove the sigils, could just make them into actual keywords instead of changing the semantics of error handling.
A proposal with keyword based syntax:
a %% b becomes a error b
Remove %%a in favor of a error unreachable
Change %defer expr; to defer(error) expr;
Change %return expr to try expr;
Change %T to error T
fn foo(x: i32) -> error i32 {
    if (x < 0)
        return error.ExpectedPositiveNumber;
    if (x % 2 == 0)
        return error.ExpectedOddNumber;
    return x - 1;
}

Providing a set of valid errors:
fn bar() -> error(OutOfMemory) T {
    return allocate(T);
}

Basically, like in @kyle-github's example:
%T == error T == enum {T, error}
error(OutOfMemory) T == enum {T, error.OutOfMemory}

Now there is no more % to mean error, and everything still works the same way.

I like @raulgrell's points here.
I am also a fan of the existing % syntax.  But then I did a lot of Perl coding years ago so sigils in general are not a problem for me.   That said, typing sigils can slow down coding if you are a very fast typist (as I am).   They are not on the home row :-)
There are a few things that are really nice about the current system:

There is a very clear idiom for handling an error returned from a function.   Or several idioms.   These do not add to the expressiveness of the language but make common patterns really clean.  I am thinking of the %return and %defer keywords.
There is a very clear way to introduce error values as a sort of pseudo enum.   This is nice because it makes it possible to do this safely anywhere in the code and you do not need to worry about reusing values accidentally.   Ever try adding something to errno's valid set?   Yeah...

So, how does the addition of these keywords and removal of % keep these points?
Here is another approach to handling errors that is similar to what happens now, but also does not require extra sigils.
First, we make error a somewhat special enum that is automatically program-wide.   You declare all the errors you need to add in the compilation unit.   However, rather than just an enum, you can think of error as a special ordinal type and the type is error.   IDEs can eventually help with suggestions etc. to help prevent accidental error additions due to typos.
...
error ENoMem;
error ENullPointer;
error ENegative;
...

fn foo(bar:i32) -> error | i32 {
    if(bar < 0) {
        return ENegative;
    }
...
    return bar+42;
}

In this code, you simply use return as normal and the compiler figures out what you want to do.  You do need to declare that you return an error or an i32.   I use the | syntax from some other languages to indicate type alternates.   I.e. the return value type is either an error or an i32.   This could be written as enum { error, i32 } today I think.   I like using | for alternation and keeping enum for named constants.   I can see a strong argument for using union too.
When using this you get:
...
var x = foo(y);
if (@typeOf(x) == error) { defer cleanupAfterFoo(x); }

I am conflating a few idea I have with respect to defer here but they can be ignored for now.  (I like the idea of providing the arguments to the deferred function so that you can easily implement things like error counters etc. OOB.  This can also be extended to deferring a block instead of a function call though local functions would solve most of that too.)
Or you could use switch:
var x = foo(y);
switch(@typeOf(x)) {
     error => ... do something with the error like defer or return. ...
     i32 => ... do something with the value...
     ...
}

This shows a couple of things I was thinking about.   While I really like the short syntax of the error defers and returns, either you need special syntax to support it or you should drop down to using existing keywords and syntax.   One thing I am not sure about is how to avoid magic in handling the types.   In my examples there is an implicit cast of x to the tested type.   Perhaps that can be a special function:
if(@castTo(error, x)) | err | ...

But I am not sure I like that because it is somewhat hacky version of allowing multiple return values.
Rust is approaching this problem by starting off with very few shortcuts and then adding them as the idioms become clear and accepted.   It might make sense for Zig to do the same at first.   Premature optimization is the root of all evil etc.

Ideal error handling for me
There is conceptually one global error variable  in the program (well, one per thread).
This sets it:
return SomeError;
Its the simplest possible way.
Why not make error handling similarly easy? There's no need for ceremony: the compiler always knows what kind of errors can a function return (with some help in edge cases), and will always be able to check that all these errors are (somehow) covered.
// this will ignore all errors
var x = foo(bar(), baz());
if (err) { // catches all possible errors from foo, bar and baz, 'err' is keyword
  // no-op, the x is known to be undefined at this point
} else {
  // x is valid here
}

//--------------------------------------------
// this will pass all errors up, they will be added to caller's interface
var x = foo(bar(), baz());
if (err) {
  return err;
}

//--------------------------------------------
// this will handle all errors, compiler will make sure all cases are covered
var x = foo(bar(), baz());
switch (err) {
ThisError => , // no-op = handled by ignoring
ThatError => return err; // passed up, ThatError becomes part of caller's interface
}

//--------------------------------------------
// some errors are handled, the rest is passed up
var x = foo(bar(), baz());
switch (err) {
ThisError => ,
else => return err;
}

//--------------------------------------------
// this will not compile because errors are not handled
fn f()
{
  var x = foo(bar(), baz());
}

//--------------------------------------------
// handling all errors in one place is also possible
fn f()
{
  var x = foo();
  // in normal flow x is valid now
  var y = bar(x);
  // in normal flow x and y are valid now
  var z = baz(y);

  if (err) { // it will jump here if there's error anywhere above
    // z is certainly not valid here, compiler should tag x, y as undefined too
  } else {
   // x, y, z are certainly valid
  }
}

//--------------------------------------------
// stepwise handling of errors
fn f()
{
  var x = foo();
  if (err == ThisError) { // other errors go further down
    x = some substitute value
  }

  var y = bar(x);
  // catches anything but ThatError, may be risky, but user explicitly choose to do so
  if (err != ThatError) {
   y = ...
  }

  var z = baz(y);

  if (err) { // remaining uncaught errors (especially ThatError) are handled here
    ...
  }
}

There's no ceremony. No need to annotate functions, no need for elaborate return types, no need for strange tricks to extract the errors. Only one new keyword (err) is needed.
Every error must be handled somehow, and it is done in intuitive way, w/o need for special forms. Compiler ensures all valid errors are handled but no more.
There will be no way to use undefined variables (because error occured) in the program, unless the programmer explicitly writes it that way (by ignoring the error explicitly and continuing as if nothing bad happened). Compiler may still warn in such cases.
If a project has strict requirements it may force (via project settings) explicit individual handling of every possible error (not ignoring them en-masse or just passing them up).

I don't hate the % sigil, but if we are to ditch it, I prefer keywords that are easy to remember.
Replace %T with T or error
Replace %%x with error(unreachable) x
Replace %return x with error(return) x
Replace a %% b with a error(or) b
Replace %defer with error(defer)
The mnemonic is: The thing inside parens is executed on error.
Also, Java's checked exception is a controversial feature, and I don't want Zig to go that way.

Proposal iteration:

Remove error top level declarations.
Remove the error type.
Add the ability to create an "error set" type:

const Errors = error {
   OutOfMemory,
   InvalidInput,
};

In a function, declare and optionally document errors to return them:

fn foo(x: u32) error -> u32 {
    // This could be declared outside the function, or in, doesn't matter.
    const Errors = error {
        /// The input was the value 0, which is unsupported.
        Zero,
        /// Did you think 1 was ok? It's right out.
        One,
    };
    if (x == 0)
        return Errors.Zero;
    if (x == 1)
        return Errors.One;
    return x - 2;
}

error is the global error set. Every error set that is created, its entries get added to the global error set. The global error set does not allow field access, e.g. error.Foo is not allowed.

const Something = struct {
    condition1: bool,
    condition2: bool,
    err: error,  // Bad choice for the type of this field because now `bar`'s error set is the global error set.
};
fn bar(ptr: &Something) error -> u32 {
    if (ptr.condition2) {
        return ptr.err;
    }
    return 1234;
}

Each failable function creates an error set by the union of all the error sets of the possible return types.

const Something = struct {
    condition1: bool,
    condition2: bool,
    err: PossibleErrors, // better choice for the type of this field
};

const PossibleErrors = error {
    OutOfMemory,
    InvalidUserInput,
};
fn bar(ptr: &Something) error -> u32 {
    const Errors = error {Condition1WasTriggered};
    if (ptr.condition1) {
        return Errors.Condition1WasTriggered;
    }
    if (ptr.condition2) {
        return ptr.err;
    }
    return 1234;
}

@errors(bar) is error{OutOfMemory, InvalidUserInput, ConditionWasTriggered}
Error set declarations can inherit from other sets:

// MorePossibleErrors is all the errors from PossibleErrors, all the errors foo can return, and Derp.
// @errors(x) returns the error set of x
const MorePossibleErrors = error(PossibleErrors, @errors(foo)) {
    Derp,
};
const OtherErrorSet = error {
    OutOfMemory,
    Unique,
};

comptime {
    assert(MorePossibleErrors.Derp == error.Derp);
    assert(MorePossibleErrors.OutOfMemory == PossibleErrors.OutOfMemory);
    assert(MorePossibleErrors.OutOfMemory == OtherErrorSet.OutOfMemory);
    assert(MorePossibleErrors.Unique == OtherErrorSet.Unique); // compile error: error set MorePossibleErrors has no field Unique
}

A function can override the documentation comment for an error:

fn foo(x: u32) error -> u32 {
    const Fail = error {
        /// The user specified numbers that are not allowed because they are too big.
        InvalidInput,
    };
    if (x > @maxValue(u32) - 10) {
        return Fail.InvalidInput;
    }
    return (try bar(x)) + 10;
}
fn bar(x: u32) error -> u32 {
    const Fail = error {
        /// The user specified the number 0 which is not allowed.
        InvalidInput,
        OutOfMemory,
    };
    if (x == 0) {
        return Fail.InvalidInput;
    }
    return 1234;
}

The documentation for the InvalidInput error that can be returned for foo will be distinct from the documentation for the InvalidInput error that can be return for bar.
Note also that bar reserves the right to return OutOfMemory even though it is not yet possible for that to happen. This is important for comptime branches.
@errors(foo) is error {InvalidInput, OutOfMemory} because the errors from bar are inherited from the try.

One more optional thing:
Maybe make an error set with only 1 field implicitly cast to its value instantiation. So then you could do:
fn foo() error {
    return error{ItBroke};
}

Which both creates the ItBroke error and returns it. This reduces overhead of using errors, making people more likely to use them.

Another adjustment: I ran into an issue with syntax.
We want function prototypes to be able to specify the error set, for example if you accept a function pointer:
const ErrorSet = error { A, B };
fn foo(func: fn() ErrorSet -> i32) {
    // the function passed can only return errors A and B
};

This means fn proto has an optional expression and then an optional -> expression and then a body which starts with {. This is ambiguous:
fn foo() {

}

Is the { ... } part of the error set or the function body?
Here's how I'm going to fix it, at least for now:
// function that can return an error or an i32
// the error set is determined automatically by the compiler
fn foo() !-> i32 {

}
// function that can return an error or void
// the error set is determined automatically by the compiler
fn foo() ! {

}

// function that returns void
fn foo() {

}

// function that must return an error in ErrorSet or void
const ErrorSet = error { A, B };
fn foo() !ErrorSet {

}

// function that must return an error in ErrorSet or i32
const ErrorSet = error { A, B };
fn foo() !ErrorSet -> i32 {

}

I was actually thinking of a feature related to error sets. The idea was to be able to have error categories, so you could check if an error was part of a category like SDLError or something. With error sets this could be done by introducing a builtin function called @errorSetContains.
As far as i've read on other issues, we like to have non pseudo code examples if possible, so here is an example based on C code i've had to write before using SDL.
// Let's pretend that we are able to import sdl headers
const sdl = @cImport(@cInclude("SDL2/SDL.h"));
const mixer = @cImport(@cInclude("SDL2/SDL_mixer.h"));

const SDLError = error {
    UnableToInitSDL,
    UnableCreateWindow
};

const MixerError = error {
    OpenAudioFailed,
    LoadMUSFailed
};

fn openAndLoadMusic() -> &mixer.Mix_Music !! MixerError {
    var status = mixer.Mix_OpenAudio(mixer.MIX_DEFAULT_FREQUENCY, mixer.MIX_DEFAULT_FORMAT, 2, 1024);
    if (status != 0) {
        return MixerError.OpenAudioFailed;
    }

    trydefer mixer.Mix_CloseAudio();
    if (Mix_LoadMUS("path/to/music.wav")) |music| {
        return music;
    } else {
        return MixerError.LoadMUSFailed;
    }
}

fn initSdlAndCreateWindow() -> &sdl.SDL_Window !! SDLError {
    var status = sdl.SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO);
    if (status != 0) {
        return SDLError.UnableToInitSDL;
    }

    trydefer sdl.SDL_Quit();
    if (sdl.SDL_CreateWindow("Test",
        sdl.SDL_WINDOWPOS_UNDEFINED, sdl.SDL_WINDOWPOS_UNDEFINED,
        640, 480, sdl.SDL_WINDOW_SHOWN)) |window| {
        return window;
    } else {
        return SDLError.UnableCreateWindow;
    }
}

const Game = struct {
    const Self = this;

    music: &mixer.Mix_Music,
    window: &sdl.SDL_Window,

    fn init() -> Self !! {
        Self {
            .window = tryreturn initSdlAndCreateWindow(),
            .music = tryreturn openAndLoadMusic(),
        }
    }

    fn update(game: &Self) {
        // Updating!
    }

    fn draw(game: &Self) {
        // Drawing!
    }
}

pub fn main() !! {
    var game = if (Game.init()) |result| {
        result
    } else |err| {
        if (@errorSetContains(SDLError, err)) {
            var errMessage = sdl.SDL_GetError();
            // Print error
        } else if (@errorSetContains(MixerError, err)) {
            var errMessage = mixer.Mix_GetError();
            // Print error
        }

        return err;
    }

    while (true) {
        game.update();
        game.draw();
    }
}

@Hejsil: would it be enough to have structured error names, like MyErrorClass.SpecificError and then be able to use prefix part of the name, like if (err == MyErrorClass) ?

@PavelVozenilek What ever syntax works best, though idk if I want == to also mean "is part of" or "contained in" in certain context. Seems confusing for no real gain. Also, figuring out if an error is part of an error set would probably require some auto generated function that is then called, which we could argue is a hidden function call, though not one the user wrote.
It could also be implemented in userspace if we are able to get a slice of all values in an enum/error set at runtime:
fn contains(comptime T: type, values: []T, value: T) -> bool {
    for (values) |v| {
        if (v == value) return true;
    }
    return false
}

const Error1 = error {
    A,
    B
}

const Error2 = error {
    C,
    D
}

test "contains" {
    // Whatever syntax you would like goes here
    //                     VVVVVVVVVVVVVVVVVVV
    assert(contains(error, @getMembers(Error1), Error1.A));
    assert(contains(error, @getMembers(Error2), Error1.A)); // Fails
}

@Hejsil this @errorSetContains feature as you have described it makes sense, and the use case  is compelling. Thanks!
I think we might add a more generic reflection function for that. Maybe @memberIndexByTag which returns ?usize. So you could do @memberIndexByTag(MixerError, err) ! = null.
Either way, we'll make sure that this use case is covered.
Oh, and your userland solution would work, with the use of @memberCount and @memberName. We might need to add @memberTag for getting the tag value / error value of a member though.

Could you elaborate on why you think it's particularly valuable to separate the return values from the error channel?

Assigning to _ shouldn't be able to suppress errors. For example, if we change this to a %return and make the function failable, then we should get a compile error here until we %return there too.
Multiple return values (just a proposal at this point) clashes with error union but harmonizes with error channel.
There are weird cases where error unions get ugly:

fn HashMap(comptime K: type, comptime V: type) -> type {
    return struct {
        const Self = this;
        // ...
        fn get(self: &const Self, key: K) -> %V {
            if (something) return error.KeyNotFound; // supposed to be failure
            var actual_value: V = something;
            return actual_value; // supposed to be success
        }
    };
}

fn main() {
    var posix_error_codes = HashMap(i32, error).init();
    posix_error_codes.put(2, error.NotFound);
    posix_error_codes.put(5, error.IoError);
    // ...
    var posix_error: error = posix_error_codes.get(errno) %% |err| error.Unknown;
}

If your V is error, then -> %V means -> %error. When you get into that situation, it's literally impossible to return a "failure" error instead of a "success" error. The "supposed to be a failure" line above would actually behave like a success.
I propose we use a different keyword for returning something along the error channel. Instead of return error.Foo;, we should use something like raise error.Foo; or throw error.Foo;. I'm not happy with either of these keyword suggestions, but I think it needs to be a different statement than a normal-looking return.

I am getting a bit confused (a normal state) by why this is being done...
If you want to move toward multiple return values, then separating errors out a la Go makes more sense to me and fits with "one obvious way to do it."   Then you can use _ as the only real special magic:
fn foo(i:i32) -> i32, error {
   ...
   if(i == 0) {
       return _, error.DivByZero;
   }
   ...
   return 42/i, _;
}

If you want to move toward something like a union, why not just use a union?
const retType = union {
   err: error;
   val:i32;
}

fn foo(i:i32) -> retType {
   ...
   if(i == 0) {
      return retType{.err = error.DivByZero};
   }
   ...
   return retType{.val = (42/i)};
}

This feels a little like the "optimized" syntax is being discussed first without solving the underlying question of how errors need to be handled.   Are errors integral values that are passed along a channel?  Are they a sort of enum that is an alternate value (result is union-like)?   Are they individual types in a union (also union-like but with the possibility of carrying more data)?
@thejoshwolfe, thanks for the example with returning %error...   Hmm...


add target field to syncstate's datatrack info

will not merge before @boks1971 verified it works for him


Update LinkedIn v2 API

LinkedIn have a new v2 API on Microsoft, his new owner.
On docs.microsoft.com
https://docs.microsoft.com/en-us/linkedin/shared/api-guide/concepts?context=linkedin/context

LinkedIn have a new v2 API on Microsoft, his new owner.
On docs.microsoft.com
https://docs.microsoft.com/en-us/linkedin/shared/api-guide/concepts?context=linkedin/context

Hey @TiDJ It seems to be your first-time contribution welcome aboard.
I think https://docs.microsoft.com/en-us/linkedin/?context=linkedin/context seems more clear. What's your take on that?

This PR is inactive, so the API was added in another PR/commit.
More information at: #2002

Wow sorry ! Didn't notice. @pawelborkar is right !

No problem ;)


Graphviz executable not found due to space in path (returncode 1, and assertionError 1)

Hi, my code is as below,
import pydot pydot.Dot.create(pydot.Dot())
the error is,
`
['dot.bat', '-Tps', 'C:\Users\Jry\AppData\Local\Temp\tmppcmwp3ua'] return code: 1
stdout, stderr:
b''
b"'D:\Program' \xb2\xbb\xca\xc7\xc4\xda\xb2\xbf\xbb\xf2\xcd\xe2\xb2\xbf\xc3\xfc\xc1\xee\xa3\xac\xd2\xb2\xb2\xbb\xca\xc7\xbf\xc9\xd4\xcb\xd0\xd0\xb5\xc4\xb3\xcc\xd0\xf2\r\n\xbb\xf2\xc5\xfa\xb4\xa6\xc0\xed\xce\xc4\xbc\xfe\xa1\xa3\r\n"
Traceback (most recent call last):
File "", line 1, in
File "D:\Program Files\Anaconda3\lib\site-packages\pydot.py", line 1886, in create
assert p.returncode == 0, p.returncode
AssertionError: 1
`
I read Pydot.py,  found in line 1834,  the code is,
 prog += '.bat'
so I revise the line to
prog += '.exe'
then it works.
I use Anaconda,  the installation path is D:\Program Files\Anaconda3.
the reason, I think, is the space in command path - 'Program Files'  in dot.bat makes  subprocess.Popen down.
So hope this can be solve in next version :-)

The error message at the top is GB2312 (Simplified Chinese) encoded and does indeed indicate some problem with the space character in D:\Program Files:
$ python3
>>> print(b"'D:\Program' \xb2\xbb\xca\xc7\xc4\xda\xb2\xbf\xbb\xf2\xcd\xe2\xb2\xbf\xc3\xfc\xc1\xee\xa3\xac\xd2\xb2\xb2\xbb\xca\xc7\xbf\xc9\xd4\xcb\xd0\xd0\xb5\xc4\xb3\xcc\xd0\xf2\r\n\xbb\xf2\xc5\xfa\xb4\xa6\xc0\xed\xce\xc4\xbc\xfe\xa1\xa3\r\n".decode('gb2312'))
'D:\Program' 不是内部或外部命令，也不是可运行的程序
或批处理文件。

In English that would be:
'D:\Program' is not recognized as an internal or external command,
operable program or batch file

So, some command was given as a full path, but not properly wrapped in quotes. Who did it? pydot says it did not do it, because it only called dot.bat:
['dot.bat', '-Tps', 'C:\Users\Jry\AppData\Local\Temp\tmppcmwp3ua'] return code: 1

I suspect that something inside the dot.bat file did it. The dot.bat file was created by conda during GraphViz installation. See line 37 of the conda recipe for GraphViz:
echo %%~dp0.\graphviz\%%~nf.exe %%* >> %%~nf.bat

I don't know the syntax there exactly, but it looks like it is not wrapping the command in double quotes.
What to do next?
Judging by the error message and the mentioned line numbers, you must have been using a pydot version around 1.3.0. It is also clear that you installed it through conda. The official pydot releases never contained the line prog += '.bat'. There was prog += '.exe' (line 1833 of v1.3.0 for example), and it was conda who patched that line to prog += '.bat'. The conda-patch was dropped when pydot 1.4.0 started using .bat in Windows Anaconda environments itself (see pydot/pydot#194. pydot/pydot-ng#52). So, first of all, you should try upgrading your Anaconda pydot and GraphViz packages.
Please report back if the latest versions still give you the same error indicating a problem with the space in D:\Program Files. If so, this should probably be reported at https://github.com/conda-forge/graphviz-feedstock next.

A user of another Python package reported the issue in https://github.com/conda-forge/graphviz-feedstock/issues/43 recently. Also had a space character in the command path. I posted a possible solution there.
I think this issue here in pydot can be closed now.

As mentioned in my previous comment, it seems that the root cause in this particular case (a space character in the Graphviz path) is with conda-forge/graphviz-feedstock#43 and should be solved there.
To anyone here looking for a solution to assertionError: 1, but not having a space character in the path of their Graphviz executable: assertionError: 1 is a very generic error message that can have many different causes. To find the specific cause of your error with pydot 1.4.1, see https://github.com/pydot/pydot/issues/203#issuecomment-533164709 and later comments and links to other issues there.
Improvements to the way pydot handles Graphviz errors are discussed in pydot/pydot#218 (currently closed, but will be reopened soon).


Support progress reporting

Coverage remained the same at 100.0% when pulling a5dfd55d4a1a4ddca894b3c0ef383b426f256da2 on progress-reporting into ddd05019b7eee0d8bb2dfb5cebcc934a97ed4046 on master.

Coverage remained the same at 100.0% when pulling a5dfd55d4a1a4ddca894b3c0ef383b426f256da2 on progress-reporting into ddd05019b7eee0d8bb2dfb5cebcc934a97ed4046 on master.

Coverage remained the same at 100.0% when pulling a5dfd55d4a1a4ddca894b3c0ef383b426f256da2 on progress-reporting into ddd05019b7eee0d8bb2dfb5cebcc934a97ed4046 on master.


Logs don't get cleared

bevy_dev_console version
533603f4838b7379a9ef773d5bc7f50efb3089af
What you did
Simply log alot of messages
What went wrong
The messages dont get cleared no matter the amout logged, causing the fps to rapidly decline over time

Yeah this is a problem that I should fix, but whats more concerning is that you said it reduces your fps, which definitely shouldn't happen.
Does the fps decline only happen when the console is open?

Yes, it only drops fps when the console is open

Yeah I assume that's because the console renders all logs, no matter if you can see them or not. I'll probably try to implement some kind of system to only render the logs you can see


Delete dynamic-type expression and related

Codecov Report

Merging #12 into master will increase coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #12      +/-   ##
==========================================
+ Coverage   84.64%   84.67%   +0.03%
==========================================
  Files         144      143       -1
  Lines        7312     7282      -30
==========================================
- Hits         6189     6166      -23
+ Misses       1123     1116       -7


A couple things

When you click a lot in the minute picker (That is, repeatedly and quickly click at a lot of different positions) the animation sometimes skips, the minute hand just appears at the final position without animating from it's current position.
I think the correct behavior should be to take the current position of the minute hand (wherever that is, stationery or in the middle of another animation due to a previous click) and use that as starting position (stop the old animation if necessary) and then just go from there.

The second thing I noticed is that whenever you click at a number, say 5 or 30 or whatever (in both the minute and hour pickers) the font color of the number changes to white immediately on the click. So, for a few 100s of milliseconds, we see white text on the light grey-ish background, which doesn't look very good.
Here's an idea, change the color to white just before the hand reaches that number. I mean as the big blue circle is about to overlap with the number (as over 25 below), that is when the text should change to white. The change of color should coincide with the end of the hand's animation, or maybe a little bit before.

Let me know if you don't quite get what I mean and I'll make a video.

Is this a valid use case or just clicking around and seeing whether the component will explode? :wink:
I know exactly what you mean and this actually also bothers me. :sweat_smile: Android clips the font over the circle and displays it partially white and partially black. This is also possible in CSS (with some... fiddling) and I'll look into this.

A good idea I had to fix the color is to possible use CSS masks to invert the color of the text. I messed with the implementation a little but didn't land on anything solid

@PorterK Same here. I wasted several hours on that. :sweat:


Use .properties files instead of .env files

#85
I've tested it on android and iOS. It can now handle any UTF-8 character. It should probably do a lot more to be fully compatible with .properties files
.properties

Thx a lot, I'm not a contributor here, but I see that you only changed the name of the file + added encoding to iOS. So why not just add the encoding? How is changing the file name changing anything?
Changing the file name is a compatibility break, so it should be avoided if possible

I agree, it looked really strange. I got the problems when my swedish characters was not saved to github. From what I read you can circumvent this by settings some variables on your local machine, which is not obvious. I think the same problem is discussed (here)[https://github.com/fastlane/fastlane/issues/6688]

Can I ask why this is closed? I think use utf-8 characters in env file is quite common.


run snarkos clean before tests

Motivation
fix tests with snarkos clean

I think the better (and more efficient) way is to remove the cache (i.e. setup_environment and clear_environment), instead of running snarkos clean.


Remove all primary node attributes for properties

Created by: @andskaal Aug 18 2021 at 14:43 CET
Last updated: Jul 18 2022 at 11:19 CET
ClickUp ID: IK-1381
Assigned in ClickUp to: Bohumil Pospíšil
There are still some Property nodes that have the primary attribute on node levels, not relationship levels.
MATCH (p:Property{primary: true}) RETURN COUNT(p)
We changed the primary flag to relation, but it remain at some property node. And it can produce some inconsistency in SDK:
When reading, it can return the property as Primary. But then it will be possible to remove it without force flag.
There might be more properties of the same type with Primary:true.
We need to create cypher, which will
Add primary:true to relationship if:
Node has primary attribute set to true
AND there is no other node with same type, which has Primary:true at relationship level already for same DigitalTwin.
Remove the primary:true from node totally.
Implementation
Script 02_up_remove_primary_node_attributes.cypher
Script import\schema\v1.3.1\02_up_remove_primary_node_attributes.cypher
Add property primary:true to relationship
Remove the primary property from Property nodes
// Add property primary:true to relationship
CALL apoc.periodic.iterate("MATCH (d:DigitalTwin)-[r:HAS]->(p:Property {primary: true})
OPTIONAL MATCH path = (p)<-[r]-(d)-[rp:HAS {primary: true}]->(pp:Property)
WHERE p.type = pp.type
WITH r, path
WHERE path IS NULL
RETURN r",
"SET r.primary = true",
{batchSize:10000}
);
// Remove the primary property from Property nodes
CALL apoc.periodic.iterate("MATCH (p:Property {primary: true})
RETURN p",
"REMOVE p.primary",
{batchSize:10000}
);

Commented by: @bayegan Sep 08 2021 at 20:04 CET
@ Bohumil Pospíšil : can you please add story points. thank you.

Commented by: @bayegan Sep 29 2021 at 15:48 CET
Run for each release: cc @maprokes , related to the Apply Function


clean up CLEAN-SC

In GitLab by @esarradj on May 2, 2018, 20:51
Clean-sc is not too pretty at the moment.

In GitLab by @esarradj on Jan 18, 2021, 15:51
closed
By Ennes Sarradj on 2021-01-18T14:51:12 (imported from GitLab)


Unicode error with utf-8 encoding value

Hi,
i've some problem with not decoding utf-8 char
  File "/Users/gprudhomme/Documents/Missions/cloukr/temp/testlibcloud/lib/python2.7/site-packages/azure/__init__.py", line 608, in _get_node_value
    return data_type(value)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 6: ordinal not in range(128)

xml content
<SubnetNames><SubnetName>LBN_Id\xc3\xa9fix-Spare</SubnetName></SubnetNames>

Fixed in upcoming v0.10 release.

thanks @huguesv .


CircleCI in progress

@tannernelson I have the tests running in Circle in 05 minutes 19 seconds on Ubuntu 14.04. How does this compare to Travis?
One issue with Circle is that a build environment must be either OSX or Linux - it doesn't seem possible to run tests on both. I will investigate this further... If it is not possible, I assume it will be a shop stopper?

Looks like it is not possible: https://discuss.circleci.com/t/how-to-use-circleci-for-linux-xcode-in-one-project/693

@mpclarkson good find, I'm really surprised by that. It definitely seems like a deal breaker to me. I think testing on both platforms is more important than saving on build times. We should revisit when/if the feature gets added. In the meantime, let's all upvote the feature request to see if we can give it some priority:
https://discuss.circleci.com/t/support-for-multiple-oss/1779

Agreed.

I don't think that  Travis is very slow. It's the generated routes that slows builds down pretty drastically.

@ketzusaka It's not the build time we're trying to reduce, it's the time waiting in the queue. But it looks like this will be impossible anyway. Thanks for looking into it @mpclarkson. Gonna close this for now.


Checkbox "checked" updated triggers onClick event on parent div when inside a form

Bug report
Current Behavior
When a checkbox is inside a <form>, any update on its checked prop will trigger an onClick event that will propagate to its parent.
Bug found while making a form with a select all checkbox that would mark all the other checkboxes as checked.
The other checkboxes were located inside
 that were clickable.
The onClick event originates from the internal <input> used by the checkbox.
Expected behavior
The event on the internal <input> should not propagate to the parent.
It also shouldn't be triggered after an update on the checked prop.
Reproducible example
CodeSandbox example
Suggested solution
See Expected behavior.
Additional context
Might be the same issue as https://github.com/radix-ui/primitives/issues/3192 and https://github.com/radix-ui/primitives/issues/2704.
Your environment

Software
Name(s)
Version

Radix Package(s)
checkbox
1.1.2

React
n/a
17.0.1

Browser

Assistive tech

Node
n/a

npm/yarn

Operating System

Hi, on my side, I avoid this issue by removing the onClick from the div, like this :

          [ ✔ ]

test

Hi, on my side, I avoid this issue by removing the onClick from the div, like this :
<form>

        <Checkbox.Root checked={isChecked} onCheckedChange={setIsChecked}>
          [ <Checkbox.Indicator>✔</Checkbox.Indicator> ]
        </Checkbox.Root>
        test

    </form>

In my case I can't because I need the whole div to be clickable (it contains other elements than the checkbox).


"Permission denied"

I ran diarize_parallel on a wav file, and I get the following error:
Model was trained with pyannote.audio 0.0.1, yours is 3.1.1. Bad things might happen unless you revert pyannote.audio to 0.x.
Model was trained with torch 1.10.0+cu102, yours is 2.3.1+cu118. Bad things might happen unless you revert torch to 1.x.
Traceback (most recent call last):
  File "C:\AI\whisper-diarization\diarize_parallel.py", line 143, in <module>
    tokens_starred, text_starred = preprocess_text(
                                   ^^^^^^^^^^^^^^^^
  File "c:\AI\whisper-diarization\.conda\Lib\site-packages\ctc_forced_aligner\text_utils.py", line 205, in preprocess_text
    tokens = get_uroman_tokens(norm_text, language)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\AI\whisper-diarization\.conda\Lib\site-packages\ctc_forced_aligner\text_utils.py", line 149, in get_uroman_tokens
    with open(tf.name, "w") as f:
         ^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied: 'C:\\Users\\UberStorm\\AppData\\Local\\Temp\\tmpb4iv7zz4'

Please help

Should be fixed now, please reinstall ctc-forced-aligner

Now I get this:
Traceback (most recent call last):
  File "C:\AI\whisper-diarization\diarize_parallel.py", line 143, in <module>
    tokens_starred, text_starred = preprocess_text(
  File "c:\AI\whisper-diarization\.conda\lib\site-packages\ctc_forced_aligner\text_utils.py", line 212, in preprocess_text
    tokens = get_uroman_tokens(norm_text, language)
  File "c:\AI\whisper-diarization\.conda\lib\site-packages\ctc_forced_aligner\text_utils.py", line 163, in get_uroman_tokens
    subprocess.run(cmd, check=True, stdin=tf1, stdout=tf2)
  File "c:\AI\whisper-diarization\.conda\lib\subprocess.py", line 503, in run
    with Popen(*popenargs, **kwargs) as process:
  File "c:\AI\whisper-diarization\.conda\lib\subprocess.py", line 971, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "c:\AI\whisper-diarization\.conda\lib\subprocess.py", line 1456, in _execute_child
    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified

That means that your windows environment doesn't have perl installed or the path of the installation isn't included in the PATH environment variable
follow this guide

I installed perl and now I get:
perl: warning: Falling back to the system default locale ("Hebrew_Israel.1255").
Traceback (most recent call last):
  File "C:\AI\whisper-diarization\diarize_parallel.py", line 167, in <module>
    with open(os.path.join(temp_path, "pred_rttms", "mono_file.rttm"), "r") as f:
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\AI\\whisper-diarization\\temp_outputs\\pred_rttms\\mono_file.rttm'

did you check manually if the file exists?

did you check manually if the file exists?

Yes. It does not


Filing app routing - Phase 1: mock data

Part of #331
Changes

fix: Add missing parameter for POST/PUT calls in our shared request function
feat: Create routes for each step of the Filing process
feat: Derive the status of each step in the Filing process based on the proposed Filing object info
feat: Create a shared FilingStepWrapper to display the step indicator above each page's content

How to test this PR

Visit http://localhost:8899/filing/2024/TESTLEI1234/upload
Use Previous/Next to navigate between pages
Confirm that the url corresponds to the currently styled step

Screenshot

@shindigira Merge conflicts resolved here.


Make play button of unavailable nodes grey

Starting with the easy bit:

This is incomplete as there is no cloud icon yet, but I'll get to that.
Related: https://github.com/endlessm/kolibri-explore-plugin/issues/534

I tested this and the play button was grey on the page listing the resource:

But clicking on the resource to go to the resource page (not sure if that is the right name) the play button is still enabled:

In addition, there are two things that seem wrong with the UX here:

If I try to click on the disabled button on the Library page, the click "falls through" and the effect is the same as if I had clicked on the card (navigating to the resource page), even if the cursor does not turn to the little hand (aka pointer) indicating that area is clickable;
In the resource page, the whole card is enabled -- perhaps this is just a side-effect of the button there being enabled too, but we should keep that in mind and address it at the same time.

I tested this and the play button was grey on the page listing the resource:  But clicking on the resource to go to the resource page (not sure if that is the right name) the play button is still enabled:
Great catch!
In the future we want the resource page to be the same as upstream, so the behavior here would be:

For now, two options:


reporting - add summary report per watershed group

Summarize the status per watershed (but perhaps make the reporting area flexible):

number of crossings/type etc
length, pct stream accessible / potentially accessible
length, pct habitat accessible / potentially accessible
etc

Started with https://github.com/smnorris/bcfishpass/commit/62e37980e7dd379d269a844a038da8f5e4824d4e

Started with https://github.com/smnorris/bcfishpass/commit/62e37980e7dd379d269a844a038da8f5e4824d4e

These are some stats we have previously reported on per watershed:
- Area
- Elevation range
- Total stream length, summaried by
    + waterbody type
    + stream order
    + gradient
- Total fish habitat length, summarized by:
    + habitat type (observed, inferred@15, inferred@15-22, non-habitat)
    + stream order
    + stream gradient
    + waterbody type
- summary stats of order, gradient (min, max, avg, mean, median, etc.)
- Number of modelled crossings
    + open bottom vs closed bottom
- Length of modelled habitat upstream of all modelled crossings
    + habitat type
    + stream order
    + stream gradient
    + waterbody type
- Area of waterbodies coded as fish habitat upstream of all modelled crossings
    + habitat type
    + stream order
    + waterbody type
- Number of PSCIS assessed crossings
    + structure type (open bottom/closed bottom)
    + barrier status (BARRIER, PASSABLE, etc)
    + stream order
    + stream width
    (failure rate)
- Number of PSCIS habitat confirmations, designs, remediations
- observations
    + by species in watershed
    + by species upstream of watershed
- DRA roads
    + surface
    + class

These are some stats we have previously reported on per watershed:
- Area
- Elevation range
- Total stream length, summaried by
    + waterbody type
    + stream order
    + gradient
- Total fish habitat length, summarized by:
    + habitat type (observed, inferred@15, inferred@15-22, non-habitat)
    + stream order
    + stream gradient
    + waterbody type
- summary stats of order, gradient (min, max, avg, mean, median, etc.)
- Number of modelled crossings
    + open bottom vs closed bottom
- Length of modelled habitat upstream of all modelled crossings
    + habitat type
    + stream order
    + stream gradient
    + waterbody type
- Area of waterbodies coded as fish habitat upstream of all modelled crossings
    + habitat type
    + stream order
    + waterbody type
- Number of PSCIS assessed crossings
    + structure type (open bottom/closed bottom)
    + barrier status (BARRIER, PASSABLE, etc)
    + stream order
    + stream width
    (failure rate)
- Number of PSCIS habitat confirmations, designs, remediations
- observations
    + by species in watershed
    + by species upstream of watershed
- DRA roads
    + surface
    + class

There is currently an error in the summary with rearing habitat in LNIC reported as over 100%

Fixed the error in prelim report but leaving this open as placeholder for adding more stats to the summary

Fixed the error in prelim report but leaving this open as placeholder for adding more stats to the summary

Very general reporting is now in /reporting. More detailed reporting can wait until after data review/feedback.

Milestone/release associated with this issue is just for the Provincial access model. Current very basic summary of length accessible per watershed group is fine for now, more detailed reporting is currently per project (see rail project, WCRP queries). Closing for now pending direction from users/clients.


run: don't pass -q flag to systemd-nspawn for systemd < 209

The -q/--quiet flag was added to systemd-nspawn in version 209, and some
distros (like CentOS 7) ship with an older version than that. This
commit runs and parses systemctl --version to determine the version
number of systemd, and will only pass the --quiet flag if it's high
enough.
Fixes https://github.com/appc/acbuild/issues/140

Uses scanf now, and also refrains from passing the --register flag for versions of systemd below 209.

sure, lgtm if it works

I tested this and it works for me.


Add plumbing for epoch SNARK message entropy

Adds support for encoding unpredictable values, using the block hash, into the epoch SNARK message. Related to https://github.com/celo-org/celo-blockchain/pull/1158

Superseded by https://github.com/celo-org/celo-bls-go/pull/15


Please invite me to the community

Name
DevMan1130
Additional Context
I want to learn and contribute to this community.

Invitation sent to join the GitHub Organization. Welcome to Infraform 🎉Please check your mail to accept the invitation sent by GitHub! 🤖About usInfraform is an open source solution for serverless platforms, it is designed for developing solutions and enhancing creators to create their infrastructure 💻 Great to have you in our community ✨ Looking forward to your valuable contributions! 🤓 You can also check our community ✨ Github ✨ LinkedIn 💜 You can also share our community with other folks who want to learn about development, DevOps, tech, and contribute together and with us 👉💜👈


Drop support for IE 9 and 10

We can drop 10 already? That is great! Can you add links with information to the commit message, please? Thank you!

:tada: :tada: :tada:

@tute Updated, and provided better messaging.
I also renamed this PR and added another commit to drop iOS 7, which has little usage these days, as well.
cc: @brendastorer

:+1: Thank you!


Why does fill: currentColor default to black?

Why does fill: currentColor default to fill: #000000 ?

Black is the default fill colour for SVG shapes, not Snap's default but SVG's... just like HTML has a bunch of defaults through user agent stylesheet.

I'm trying to replicate an SVG from a website and on the website it's currentColour, which is actually blue?

Maybe it would be good to replicate the issue on a jsfiddle with a minimal example.

I can't replicate the issue in jsfiddle.

@ibrierley  Replicated it:
https://jsfiddle.net/90kc8kj1/1/

I think currentColor is only a style option, not an svg attribute (but as ever I may be wrong). So maybe this ?
https://jsfiddle.net/90kc8kj1/2/

Interesting. I'll give it a go, but in the original the fill property isn't applied within "style"?

That's fixed it! :D. Thank you.

@ibrierley Actually, if you look at http://snapsvg.io/start/ at stage 3 it shows fill being within the .attr method. Thoughts?

I think there's possibly a bit of confusion...SVG can have both attributes or styles for quite a few settings (and both can be present), and the same name can be used for either in many cases.
fill for example is one of these, so you can set fill as an svg attribute or a style.
Style will take precedence over an attribute following normal css cascading precedence (I think!).
So if you have style="fill: yellow" AND fill="green" on the element, it will appear as yellow. If you remove the style, it will appear as green.
Now to add to the confusion just mentioning it in case you dig deeper, I think there's at least one thing where if you set an attribute in Snap, it set it as a style underneath in the actual SVG. Fill may be one of them. I've always thought this incorrect (if I set an attribute, I want that attribute set, not a style!), but it's been open to debate. I can't remember if that was fixed, or if preferred that way.

@ibrierley I appreciate all your help with understanding Snap and more about SVG's :).
Could I pick your brain on a slightly different thought as well?
So I'm also trying to re-create a linearGradient with Snap and I'm finding it difficult when 1 linGrad doesn't have any <stop> children (or stop-colour attr/style) and instead references to another linGrad that has the colours. However, the linGrad with colours doesn't have any coords and therefore doesn't get built by Snap. Below is an example of the svg's I'm replicating. Thoughts?
<svg>
	<defs>
		<linearGradient id="linearGradient4505">
			<stop offset="0" id="stop4507"
				style="stop-color:#dcbf19;stop-opacity:1">
			</stop>
			<stop offset="1" id="stop4509"
				style="stop-color:#dcbf19;stop-opacity:0">
			</stop>
		</linearGradient>
		<linearGradient xmlns:xlink="http://www.w3.org/1999/xlink"
			xlink:href="#linearGradient4505" id="linearGradient4761"
			gradientUnits="userSpaceOnUse" x1="14.58" y1="14.06" x2="106.25" y2="94.79">
		</linearGradient>
	</defs>
</svg>

If there is anything specific that Snap can't do, which I would understand with more complicated filters, you can always Snap.parse() the raw svg, couple of example at http://svg.dabbles.info/snaptut-fobject and http://svg.dabbles.info/snaptut-parse
Append the fragment that is returned from a parse().
If those elements in the raw svg have id's you can still reference them and animate them or whatever, but some things you may need to delve into changing with pure j.s if it's something Snap doesn't understand.


Fred/crowdsim_gui modifications on traffic_editor for configuring crowd simulation

This PR includes the modifications on traffic_editor gui for the purpose of generating the "human_lanes" and "crowd_sim" tag in building.yaml. The building.yaml will then be processed with 'building_map_tools:building_crowdsim' to generate the navmesh and required config files for menge.
This integration can be used once passing the package building. A documentation on using the crowd_sim panel will be written, and a pop-up widget might be integrated in this. Currently a structure review may be helpful before I start adding more code to it.
An example crowd_sim configuration file for office scenario can be found in here:
https://github.com/FloodShao/traffic_editor/tree/fred/building_crowdsim_test/building_crowdsim_test_files/map

Hi @codebot , thanks for the comments on this PR.
In this PR, the major logic is to create a table to show the configuration, and put that table into a dialog with ok and cancel button widget.
I have made changes on this PR, the major changes includes:

separate all the required class headers, group them in "include/crowd_sim/"
separate all the tables into one class one file format, group them in "gui/crowd_sim"
create a pure virtual class for all the tables to reduce the code size
as for all the dialogs, the class declare and definition are quite similar (except for condition_dialog.h). I grouped them into "crowd_sim_dialog.h" and "crowd_sim_dialog.cpp" to avoid generating multiple headers and cpp. All the .cpp for dialogs (except for condition_dialog.cpp) only includes the constructor. I'm not sure if that's appropriate. If not, I can separate all of them.
for member functions only have less than 3 lines, I write them in the header file as inline function. Mostly are setters and getters. If that's not appropriate, I can modify them as well.

Thanks for your time and patience reviewing this PR.

Hi @codebot , I managed to make all the classes have their own header file and implementation. I reduced some redundant code and use a base class pointer for tables to be shown in the dialog, so that we won't have to create all the dialog classes.
Besides, I added all the license declaration into the front of each source file.
If you have further comments please let me know. Thanks for reviewing this PR.


Relatively "more bold" discussion

A follow up to #10498.
If the user already has a bold font selected, should we make the font for bold text even more bold?
Options:

when the user has a bold font, leave intense text just bold
increase the font weight EVEN MORE, so bold text becomes extra bold (up to a sensible max)

how does this play when the user's default font weight is something like extra-light? does extra-light -> light -> normal -> bold -> extra-bold?

possible have a setting to switch between the above behaviors? (might be overkill)
Allow the user to specify a custom "bold text font weight", so they could have extra-bold text by default, and "bold" text we could render as extra-light (if you're a crazy person) (also overkill)

Relevant comments:

https://github.com/microsoft/terminal/issues/109#issuecomment-743929268 is probably the comment you're looking for?

Just multiply by 1.75, cap it at 1000, and call it a day, perhaps. I run font weight 450 locally ("Retina" weight) rather than 400, so this would come out closer to Extra Bold than Bold, which seems reasonable to me. If the font doesn't support variable-width, let DirectWrite work out which weight instance to pick.
If it's helpful, CSS defines its own transformation for bold, but that doesn't allow for variable-weight fonts, it relies on their font rounding calculation to pick a "named" weight first, then enbolden it. I would expect DirectWrite to do that for us.

et al in https://github.com/microsoft/terminal/pull/10498/files#r657675585.

For the record, I dig this "multiply by 1.75, cap at 1000" option personally. I doubt this needs to be configurable, and the scaling font weight seems like it'll work in most cases. We could even limit it to solely the case where the font weight is already >=bold if we wanted.

Posting some thoughts I have on this...
I think when it comes to "bolder than the chosen weight" this is a sensible idea.
When a font has limited weights, then Normal and Bold tend to be the only options, but some fonts may only be a single weight.
Some apps have a "simulated bold" which could be used for the single weight fonts.
When the font range is a little wider, perhaps for anything below Bold, the bold command could switch to the next instance up?  - So Light, would use Semi Light or Regular;

Semi Light would use Regular or Bold;
Regular would use Semibold or Bold;
Semibold would use Bold or Black;

But then when the font weight chosen is bold, then what happens after would need some consideration.
If there is a Black or Extra Bold weight, then that gives you a place to go, but there may need to be a simulated bold option for fonts with only Regular and Bold options.  Adobe supports a Faux bold, and I am sure Direct Write supports this too.
This may impact readability, so perhaps there could be a warning in the settings UI when a heavy weight is chosen?
For Variable fonts you may have a Weight axis to increase on, as well as the established instances.

If you already are using a chonky font weight... couldn't wrapping over to the thin weights symbolize the same sort of emphasis of text that "bold" signaling would be used for? Like don't cap at 1000.... overflow back down to 100.

Or if your normal text is already heavy-weight, bold could be like ｔｈｉｓ?
That's a clearly perceptible difference, but probably not ideal in a fixed-width terminal layout.

Or if your normal text is already heavy-weight, bold could be like ｔｈｉｓ?
That's a clearly perceptible difference, but probably not ideal in a fixed-width terminal layout.

Spacing would break for richer output like with pseudo GUIs.

If you already are using a chonky font weight... couldn't wrapping over to the thin weights symbolize the same sort of emphasis of text that "bold" signaling would be used for? Like don't cap at 1000.... overflow back down to 100.

Wrapping around has a sort of logic too it, but I suspect it may lead to an onslaught of github issues calling it out as a bug.

I'm more concerned about how other terminals handle this particular scenario, especially the long-standing veterans, for example GNOME terminal.

I'm more concerned about how other terminals handle this particular scenario, especially the long-standing veterans, for example GNOME terminal.

If you're going to be looking at GNOME Terminal for inspiration, I'd suggest testing older versions too. I can't find the issue now, but I know there were complaints fairly recently about a VTE update that broke bold font handling in some way, and I'm almost sure the issue was with users that were setting their default font weight to bold, and VTE wasn't respecting that choice anymore (or something along those lines).

Thanks James for the info about GNOME terminals. Also the fact that people do care about the behavior when setting the default font weight to bold.
获取 Outlook for iOShttps://aka.ms/o0ukef

发件人: James Holderness @.>
发送时间: Thursday, July 8, 2021 5:47:51 PM
收件人: microsoft/terminal @.>
抄送: Chester Liu @.>; Comment @.>
主题: Re: [microsoft/terminal] Relatively "more bold" discussion (#10577)
I'm more concerned about how other terminals handle this particular scenario, especially the long-standing veterans, for example GNOME terminal.
If you're going to be looking at GNOME Terminal for inspiration, I'd suggest testing older versions too. I can't find the issue now, but I know there were complaints fairly recently about a VTE update that broke bold font handling in some way, and I'm almost sure the issue was with users that were setting their default font weight to bold, and VTE wasn't respecting that choice anymore (or something along those lines).
―
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/terminal/issues/10577#issuecomment-876297500, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABD6BL5NUCML7PALY23MH6DTWVX4PANCNFSM4767Q63A.

I just came across the CSS Fonts 4 draft and it has a "bolder" algorithm that accounts for variable-weight fonts.
Currently, that's

where "Inherited value" is the value to which bolder or lighter is being applied, i.e. the current font weight. It's pretty much the same rule from the current CSS Fonts spec, with rounding done for you.
So that is another externally-justifiable approach to "bold when the user overrides fontWeight but not boldFontWeight".
I'm not sure I like it more than the "multiply by 1.75" approach (which is nice and simple, but probably too linear as you move away from 400), but better to have this approach visible in this discussion than ignore it.

kitty handles this by offering configuration settings for the standard font face, bold, italic, and bold-italic: https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.font_family
I can see the merit of auto-calculating a "bolder" font when there isn't one manually specified, but wouldn't it be more straightforward to offer similar, per-font-type configurability? Even if an auto-bolder algorithm does get implemented, it still makes sense to have this configuration. A user might want to use a completely different font family to emphasize bold text, or they might want to specify a special script variant of a font for italics.

I'd say just do what every other terminal does: there are two weights you can set: one for normal, one for bold. Let users just do whatever weird stuff they want with that.

Makes sense to me, the font I'm using (a variable of Iosevka) provides 9 weights from Extra-Light to Extra-Black (and also has variable weight up to 990). Perfeably, I would set weight to Semi-Bold or Bold, but that's where I can barely tell the difference between intense text and normal one.
And if I increase weight more, the bold text was relatively thinner (laugh)

I think we should allow the user to choose the font(and weight) used for bold text. That would be a quick workaround.


Fix test

Fix all flask_admin test (except one on @base.expose_plugview)

Tests are already passing on master branch so I think this PR is no longer necessary. Let me know if I should re-open it.


Update Resources.md

OPS Build status updates of commit 3e57ee4:
:clock10: Preparing: average preparing time is 43 sec(s)

OPS Build status updates of commit 3e57ee4:
:clock10: Incremental building: average incremental building time is 18 sec(s)

OPS Build status updates of commit 3e57ee4:
:clock10: Incremental building: average incremental building time is 18 sec(s)

OPS Build status updates of commit 3e57ee4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows-iotcore/Resources.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Can we remove _ambiguate in the "plugins" repository?

The plugins repository has a 41 calls of a _ambiguate method. Flutter 3 is now stable and we have already the next stable release. Is it time to remove the _ambiguate method? In the code it says

"TODO(ianh): Remove this once we roll stable in late 2021."

cc: @ianh

Yes, this can be removed now. Thanks for filling this!

Should I do everything in one PR or for every package a separate PR?

Either is fine; 41 instances of a straightforward changes won't be hard to review.

New instances have been added for new framework changes, so these will have to be evaluated in a case by case basis now; not all are removable.

Most of the remaining usage in for WidgetsBinding.instance, which can be removed. The other cases will need to be checked for when the API changed.


Run integration tests using Harbor SDK

Problem
Integration tests are not using Harbor SDK to run tests.
E2E tests right now are very basic.
Proposed Solution
Upgrade current e2e test infra to use test infra setup by Harbor

[x] Configure testnet
[x] Bring up (or reconnect with) testnet as part of integration test bringup
[ ] Implement basic xcall e2e test as a test scenario
[ ] Merge Harbor PR to make testnet builds part of CI

Acceptance Criteria

[ ] Testnet on Harbor comes up successfully
[ ] Integration test scenarios are run on the testnet

Blocked, @jakekidd follow up with @preethamr


Workflow/packages should only show up in workspace if there is at-least one resource

There should be no default state for Workflows and Packages in a workspace

Hey team! Please add your planning poker estimate with Zenhub @ayushpahwa @nsarupr

Hey team! Please add your planning poker estimate with Zenhub @ayushpahwa @nsarupr @Parthvi12


Adding a paper request.

Hi, @chaofengc!
Thank you for all your great work!
Recently, we finish a work about IQA for regions of interest (ROI).
Could you add our paper to the repository?
Paper link: Arxiv
Method: SEAGULL
Type: IQA for ROIs
Published: Arxiv
Code: Github
Keywords: Regions of Interest, Fine-grained Assessment
Thank you for your consideration!

Thank you for your suggestion! Would you please create a pull request to add the paper? Your contribution would be greatly appreciated and would help improve the project for everyone. Thank you!

Sure, I have created a PR to add the paper.
Would you please check it? Thank you again!

Thank you so much for your contribution🤗!


Can this work with Mistral 7b instruct ? How to configure it with for example Yahoo Finance ?

Hi , Can function calling be implemented with mistral 7b instruct ? And do you have an example together with for example Yahoo Finance ?

Mistral's documentation now includes an function calling. You can check it out if that can help

@timtensor


Add API docs examples

The FastAPI docs demonstrate how to call the API using a curl request.
Add examples for other languages such as Python, Java, and JavaScript.

Resolved in #19


How to track Mobility translated attributes and Action Text?

Thank you for this gem! I am evaluating it to track attributes which PaperTrail does not track properly.
Using Mobility, with the default installation (key-value backend), how do I track translated attributes (without having conflicts between different locales and in a way where records can be restored)?
I tried this:
class Page < ApplicationRecord
  extend Mobility
  include ActiveSnapshot
  translates :title, backend: :key_value, type: :string

  has_snapshot_children do
    instance = self.class.includes(:string_translations).find(id)
    { string_translations: instance.string_translations }
  end
end

If I have e.g. 2 locales and ensure that the page has a title value in each of those 2 locales, then calling snapshot = page.create_snapshot! successfully creates 3 snapshot items: one for the main record and one for each of the associated string_translations. This is good news because I hadn't managed to do this so far with Paper Trail or Audited (but I would be happy to be proven wrong.)
However when calling snapshot.restore! I get the error PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint "pages_pkey".
Questions:

How to fix the reification error?
Would there be a way to track the logical title attribute instead of referring to string_translations which is meant to be an implementation detail? As the name suggests, Mobility is supposed to allow flexibly using different types of backends and the association name string_translations is only applicable to its key-value backend.
From a logical standpoint, these translations aren't really children. The page's title isn't a "child" of the page but an attribute of the page. Would it make more sense to rename has_snapshot_children to has_associated_snapshots or similar?
Similar question as in the Mobility example above but for Rails Action Text rich texts: they are similarly stored in a separate table using polymorphic relationship. How to track those?

Finally, I need to combine all 3 aspects: snapshots for Action Text rich texts which are translated. I manage to translate Action Text rich texts using this gem I built. I could try combining it with this gem when I have more clarifications on the questions above.

Here is a demo for Action Text:
class Page < ApplicationRecord
  include ActiveSnapshot
  has_rich_text :body
  has_snapshot_children do
    instance = self.class.includes(:rich_text_body).find(id)
    { rich_text_body: instance.rich_text_body }
  end
end

I manage to create the snapshot but again not to restore it.

Demo with translated Action Text:
class Page < ApplicationRecord
  extend Mobility
  include ActiveSnapshot
  translates :body, backend: :action_text # Using https://github.com/sedubois/mobility-actiontext/
  has_snapshot_children do
    instance = self.class.includes(:rich_text_body).find(id)
    { rich_text_body: instance.rich_text_body }
  end
end

I feel that in this scenario you should take this gems code and copy it into your project, remove it from the gemfile and then customize it for your individual applications needs. This is described in the README:

read this gems brief source code completely before use OR copy the code straight into your codebase


Implement fast registration

TL;DR
Implement fast-register in pyflyte
Type

[ ] Bug Fix
[x] Feature
[ ] Plugin

Are all requirements met?

[x] Code completed
[x] Smoke tested
[ ] Unit tests added
[ ] Code documentation added
[ ] Any pending items have an associated Issue

Complete description
https://docs.google.com/document/d/1n7DmKXaOv8dAb9eHD4TKqka6FsdJNs3Tugpf1I6nvMg/edit?usp=sharing
Tracking Issue
https://github.com/lyft/flyte/issues/554
Follow-up issue
NA

@wild-endeavor @kumare3 do you mind reviewing initially? i'll add unit tests to this PR if it looks okay overall

ping @kumare3 @wild-endeavor

mind taking another look @kumare3 @wild-endeavor

This really looks cleaner.

can we write the example CLI here

What will the user use to register fast
What will propeller use to launch the execution

PTAL @kumare3 @wild-endeavor

can we still get documentation first?


Added Contributors page

Issue: #1137
Description
I developed and optimized the Contributor Page, focusing on enhancing user experience, responsiveness, and performance.
The project involved the following key tasks:

Page Development:
a. Design and Layout: Crafted a visually appealing and user-friendly layout for the Contributor Page, ensuring consistency
with the overall theme of the website.
b. Fetching Contributor Data: Implemented functionality to fetch and display contributor data from the GitHub API. This
involved asynchronous data fetching, error handling for rate limits, and dynamically generating contributor cards.
c. DOM Manipulation: Optimized the DOM manipulation process to reduce reflow and repaint operations, resulting in
smoother and faster rendering of contributor information.
d. Caching: Added local storage caching to store contributor data, reducing the need for repeated API requests and
improving load times for returning users.

Responsiveness:
a. Responsive Design: Made the Contributor Page fully responsive, ensuring an optimal viewing experience across various
devices and screen sizes.
b. Mobile Optimization: Ensured that the layout, images, and text adapt seamlessly on mobile devices, providing a consistent
and intuitive user experience.

Adding the contributor option in the header in order to easily navigate to the contributor page.
Type of PR

[ ] Bug fix
[X] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
https://github.com/user-attachments/assets/72e5986e-2839-4ccd-b157-5b353e55f93f

Checklist:

[X] I have performed a self-review of my code
[X] I have read and followed the Contribution Guidelines.
[X] I have tested the changes thoroughly before submitting this pull request.
[X] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[X] I have commented my code, particularly in hard-to-understand areas.

@Suchitra-Sahoo Mam,
Now I have opened new PR with required changes , Please review this.
Thank You!

The navbar options are nto properly alligned as in homepage. Also change the backround as it is merging with navbar.


Add Effectful.Coroutine

Credit to @Lysxia for the original implementation

Closing in favour of https://github.com/haskell-effectful/effectful/pull/213


How to add metadata to already downloaded file

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm asking a question and not reporting a bug or requesting a feature
[X] I've looked through the README
[X] I've verified that I have updated yt-dlp to nightly or master (update instructions)
[X] I've searched known issues and the bugtracker for similar questions including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Please make sure the question is worded well enough to be understood
Let's say I happened to download "Blank spaces" audio by Taylor Swift:
yt-dlp -i -f 140 "https://www.youtube.com/watch?v=e-ORhEE9VVg"

and having a file named Taylor Swift - Blank Space [e-ORhEE9VVg].m4a
What should be my course of action to only add metadata without downloading the whole file with metadata. i.e. without:
yt-dlp --embed-metadata -i -f 140 "https://www.youtube.com/watch?v=e-ORhEE9VVg"

(to save the bandwidth)
Provide verbose output that clearly demonstrates the problem

[ ] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[ ] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
No response

if you haven't moved/renamed the downloaded file, are using the same output template (-o), and you aren't using --force-overwrite, then running the same command again with --embed-metadata will only embed the metadata and not re-download the video

@bashonly
Thank you very much for the suggestion.
Ended up:
find . -type f | grep -Po '\[\K[^]]{4,}' | xargs -I@ yt-dlp --embed-metadata -i -f 140 "https://www.youtube.com/watch?v=@"


chore: change coverage format

Codecov Report

Merging #156 into master will decrease coverage by 1.63%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #156      +/-   ##
==========================================
- Coverage   90.51%   88.88%   -1.64%
==========================================
  Files          48       48
  Lines        3701     3786      +85
  Branches      450      477      +27
==========================================
+ Hits         3350     3365      +15
- Misses        351      388      +37
- Partials        0       33      +33

Impacted Files
Coverage Δ

src/schema-manager/schema-manager-factory.ts
77.33% <0.00%> (-9.44%)
:arrow_down:

src/schema-manager/file-schema-manager.ts
82.66% <0.00%> (-7.62%)
:arrow_down:

src/cli/commands/report.ts
83.07% <0.00%> (-7.55%)
:arrow_down:

...guage-service-adapter/get-semantic-diagonistics.ts
83.80% <0.00%> (-6.29%)
:arrow_down:

src/schema-manager/extension-manager.ts
80.68% <0.00%> (-5.53%)
:arrow_down:

...raphql-language-service-adapter/simple-position.ts
88.23% <0.00%> (-5.52%)
:arrow_down:

src/schema-manager/http-schema-manager.ts
53.33% <0.00%> (-3.43%)
:arrow_down:

src/analyzer/markdown-reporter.ts
92.94% <0.00%> (-3.41%)
:arrow_down:

src/analyzer/validator.ts
91.42% <0.00%> (-2.69%)
:arrow_down:

src/schema-manager/request-introspection-query.ts
61.64% <0.00%> (-2.65%)
:arrow_down:

... and 32 more


python311Packages.django-sesame: 3.2.1 -> 3.2.2

Diff: https://github.com/aaugustin/django-sesame/compare/refs/tags/3.2.1...3.2.2
Changelog: https://github.com/aaugustin/django-sesame/blob/3.2.2/docs/changelog.rst
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 282569 run on x86_64-linux 1

2 packages built:

python311Packages.django-sesame
python311Packages.django-sesame.dist


Allow empty 'action', skip items if 'info' is empty

Pass through both the prefix and key if 'action' is not set or set to an empty string.

Skip items where 'info' key is an empty string

These two changes are both to facilitate:
def GenReg(): any
	var list = []
	for r in '"0123456789-.' .. range(0x61, 0x7a)->map((_, v) => v->nr2char())->join('')
		var c = r  # Capture reference for lambda
		add(list, {key: r, info: () => c->getreg()->substitute('[ \t\n]\+', ' ', 'g')})
	endfor
	return list
enddef
call popsikey#register('"', GenReg(), {padding: [0, 0, 0, 0], border: [0, 0, 0, 0]})

Pressing " will show a list of registers with their contents, and then you can use it like with any command: "5p, "zyy, etc.
Without these changes empty registers would get displayed, which is rather pointless especially for the a-z ones,
Passing through the prefix + key isn't necessarily needed, but just removes a bit of duplication.

Without wholly absorbing this, I can't speak to a "good design" for what you want. But it seems like the crux is

some keys (with dynamically generated info) should not be presented
some keys should behave as if the prefix + key was pressed

This seems at least slightly orthogonal; for example, if a non-presented key was pressed but set to behave as prefix+key, would that help with your dilemma?
At any rate, the action entry is currently the best place for flexibility, since a non-string type can be used. The only change to current behavior would be to turn an error into a new behavior, which I find acceptable.


Update npm package

Seems that npm i react-native-multi-slider --save returns an outdated version.

Should be updated several days ago.  #22


No documentation of props such as "className"

What is happening?
I was hoping to add stuff like margins or padding. I found by sheer accident a code snippet of someone using "className" and that seemed to work. ie className="m-5" to add bootstrap classes that aren't specific to component
What should be happening?
Most common and seemingly very important props are not explained at all in the documentation. For example, if you wanted to add margin or padding like I did, and search reactstrap docs, you will not find anything helpful. className is simply mentioned as a prop that is a string with no further explanation. The purpose of it is not clear unless you already know exactly what it does.

added documentation. :)


Problem finding all AcroFields in document

I tried to extract acro fields from IRS 1040 form (https://www.irs.gov/pub/irs-pdf/f1040.pdf) but failed.
Is it because of the version? The irs form is version 1.7
I had no problem to get fields from a 1.3 version PDF file.
The code I used:
const getAcroFields = (pdfDoc) => {
    if (!pdfDoc.catalog.get(PDFName.of('AcroForm'))) return [];
    const acroForm = pdfDoc.context.lookup(pdfDoc.catalog.get(PDFName.of('AcroForm')));

    if (!acroForm.get(PDFName.of('Fields'))) return [];
    const acroFields = acroForm.context.lookup(acroForm.get(PDFName.of('Fields')));

    return acroFields.array.map(ref => acroForm.context.lookup(ref));
};

Hello @jumpypixels!
The problem has nothing to do with PDF versions. It's actually due to the fact that the f1040.pdf file you shared contains nested acroform fields. I wrote a script to traverse the nested field tree and produce a single flat array of all the acroform fields in the document:
import fs from 'fs';
import { PDFArray, PDFDict, PDFDocument, PDFName } from 'pdf-lib';

const recurseAcroFieldKids = (field: PDFDict) => {
  const kids = field.lookupMaybe(PDFName.of('Kids'), PDFArray);
  if (!kids) return [field];

  const acroFields = new Array<PDFDict>(kids.size());
  for (let idx = 0, len = kids.size(); idx < len; idx++) {
    acroFields[idx] = field.context.lookup(kids.get(idx), PDFDict);
  }

  const flatKids: PDFDict[] = [];
  for (let idx = 0, len = acroFields.length; idx < len; idx++) {
    flatKids.push(...recurseAcroFieldKids(acroFields[idx]));
  }

  return flatKids;
};

const getRootAcroFields = (pdfDoc: PDFDocument) => {
  if (!pdfDoc.catalog.get(PDFName.of('AcroForm'))) return [];
  const acroForm = pdfDoc.context.lookup(
    pdfDoc.catalog.get(PDFName.of('AcroForm')),
    PDFDict,
  );

  if (!acroForm.get(PDFName.of('Fields'))) return [];
  const acroFieldRefs = acroForm.context.lookup(
    acroForm.get(PDFName.of('Fields')),
    PDFArray,
  );

  const acroFields = new Array<PDFDict>(acroFieldRefs.size());
  for (let idx = 0, len = acroFieldRefs.size(); idx < len; idx++) {
    acroFields[idx] = pdfDoc.context.lookup(acroFieldRefs.get(idx), PDFDict);
  }

  return acroFields;
};

(async () => {
  const pdfDoc = await PDFDocument.load(fs.readFileSync('f1040.pdf'));

  const rootFields = getRootAcroFields(pdfDoc);

  const fields: PDFDict[] = [];
  for (let idx = 0, len = rootFields.length; idx < len; idx++) {
    fields.push(...recurseAcroFieldKids(rootFields[idx]));
  }

  fields.forEach((field) => {
    console.log(String(field));
    console.log();
  });

  console.log('Total fields:', fields.length);
})();

Here's some of the script's output:
<<
/AP <<
/D <<
/1 929 0 R
/Off 930 0 R
>>
/N <<
/1 928 0 R
>>
>>
/AS /Off
/DA (/ZaDb 5.6 Tf 0 g /ZaDb 5.6 Tf 0 g )
/F 4
/FT /Btn
/MK <<
/CA (4)
>>
/P 927 0 R
/Parent 131 0 R
/Rect [ 95.599 716.002 103.599 724.002 ]
/StructParent 1
/Subtype /Widget
/T (þÿc1_01[0])
/Type /Annot
>>

...

<<
/DA (/HelveticaLTStd-Bold 8.00 Tf 0.000 0.000 0.502 rg)
/F 4
/FT /Tx
/MK <<
>>
/MaxLen 10
/P 1 0 R
/Parent 129 0 R
/Q 1
/Rect [ 509.745 306 576 317.999 ]
/StructParent 117
/Subtype /Widget
/T (þÿf2_37[0])
/Type /Annot
>>

Total fields: 116

As you can see, it finds 116 total fields.
I hope this helps! Please let me know if you have any additional questions.

Thank you for the help.
I have a suggestion related to the same document. From the output of your script, you will notice some special characters(/T (þÿf2_37[0])) in the name value. I can remove them with regular expression but it will be better it can be done by pdf-lib itself.  I'm not sure it's a bug or come from the document itself. I used pdfjs and Winking's PDF Analyzer, they both have no special characters in the value.
Regards
Henry

@jumpypixels The special characters you're encountering are actually the raw encoded name of the field in the PDF file. pdf-lib doesn't currently contain APIs to decode these text strings. However, support for this will hopefully land when https://github.com/Hopding/pdf-lib/pull/336 is completed.

pdf-lib now has form creation and filling APIs that should be used instead of the above example(s). See the form filling JSFiddle for a working example. Additional information is available in the README and API docs. The PDFForm.getFields method is of particular relevance to this issue.


Find another way to get Kissmanga chapter name

Current code uses the chapter selector dropdown option that's selected, but none of them is selected by default now.
▶ python nosetests.py fundoshi.tests.test_kissmanga.TestKissmangaChapter
E..
======================================================================
ERROR: test_middle_chapter (fundoshi.tests.test_kissmanga.TestKissmangaChapter)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/nhanb/pj/fundoshi/fundoshi/tests/test_kissmanga.py", line 97, in test_middle_chapter
    _test_chapter(self, site, url, expected)
  File "/home/nhanb/pj/fundoshi/fundoshi/tests/__init__.py", line 28, in _test_chapter
    chapter = site.chapter_info(html)
  File "/home/nhanb/pj/fundoshi/fundoshi/sites/kissmanga.py", line 106, in chapter_info
    name = self._chapter_name(soup)
  File "/home/nhanb/pj/fundoshi/fundoshi/sites/kissmanga.py", line 128, in _chapter_name
    return select.find('option', selected=True).text.strip()
AttributeError: 'NoneType' object has no attribute 'text'

----------------------------------------------------------------------

Actually, no, they just updated the Naruto chapters with new URLs. Simply changing the test case's URL will work.


Enable to specify SAML2 mapping using env variables

Problem:
I can't find the better way how to specify  SAML attrib mappins, in current format (for djangosaml2):

SAML_ATTRIBUTE_MAPPING = {     'uid': ('username', ),     'mail': ('email', ),     'cn': ('first_name', ),     'sn': ('last_name', ), }
using env variables, specially this is  important in case of k8s deployment type.

Workaround:
Usage of old way of mapping, than in configuration to use additional function to rewrite it into the new format.

Old format:
DD_SAML2_ATTRIBUTES_MAP=(dict, {         # Change Email/UserName/FirstName/LastName to corresponding SAML2 userprofile attributes.         # format: SAML attrib:django_user_model         'Email': 'email',         'UserName': 'username',         'Firstname': 'first_name',         'Lastname': 'last_name'     }),
and linux env var representation:
DD_SAML2_ATTRIBUTES_MAP=  email=email,username=User.username,first_name=first_name,last_name=last_name
Additionally in this PR additional logger for SAML is added, and additional switch:
DD_SAML2_ALLOW_UNKNOWN_ATTRIBUTE, default False
That allows attributes that are not defined in attribute_maps to be parsed.

Good Idea @dsever!
Maybe we should also extend the documentation and add a part about the linux env var representation.

@dsever is it still a draft?

@dsever is it still a draft?

If you agree with this approach, I can mark it as official PR.

@dsever is it still a draft?

If you agree with this approach, I can mark it as official PR.

It is the best option we have at the moment, so yes :)

@dsever Can you please update the documentation too?

@dsever Can you please update the documentation too?

Sure, will do it.

Thanks @dsever!


How to exclude all node_modules?

Hi. I want to create a bundle without any modules from node_modules being bundled, and I have a lot so I can't just ignore them all one at a time.
I'm only using this bundle as a transpiled (6to5) source for generating translation files (gettext) so I don't need all the external dependencies to slow down the build.

Did you determine how this can be done?


Prefer included distutils even without importing setuptools. Closes #2259.

Summary of changes
In #2259, Paul outlines the problem - users that import distutils before importing setuptools, a common if not recommended practice, will receive a warning and will end up with objects from different implementations of distutils.
When enabled, this change installs a .pth file (except for editable installs of setuptools) to the user's environment to ensure that the setuptools-provided distutils is preferred before setuptools has been imported (and even if setuptools is never imported).
This feature relies on the same SETUPTOOLS_USE_DISTUTILS flag for opt-in now and opt-out in the future (set to "local" for opt-in and "stdlib" for opt-out).
This patch was originally submitted as #2260 but backs out the refactoring that left the implementation in an unsuitable state.
Pull Request Checklist

[ ] Changes have tests
[x] News fragment added in changelog.d. See documentation for details

Per my comments in #2260, I strongly disagree with this course of action. I don't think we should move forward with this change without testing, and even if we did, I think we should at least clean up the history so it's easier to revert specific subsets of the changes if necessary.

I very much respect your opinion @pganssle, so I'm going to take another stab at writing a suite of tests for the distutils expectation.

In #2315, I've written three tests that capture the user-facing behavior, including xfailing on the limitation identified in #2259. I expect that test to start xpassing with this change.

I observe that the tests are failing on Windows, even though I thought they were passing in the previous PR. The test failures are in test_virtualenv.test_pip_upgrade_from_source. It's possible I missed this failure before because I mis-recognized the failure in appveyor as a "fail fast" (where it stops running and marks as fail if a newer version is pushed). Regardless, we'll need to investigate that issue too.

The error occurs when it tries to run sdist and fails with this error:
error: could not create 'build\bdist.win-amd64\wheel\.\import os; enabled = os.environ.get('SETUPTOOLS_USE_DISTUTILS') == 'local'; enabled and __import__('_distutils_hack').add_shim(); \easy_install.py': No such file or directory

It seems the _restore_install_lib method isn't working properly under Windows.

Here are the values of install_lib and install_libbase during the execution:
{'install_lib': 'build\\bdist.win-amd64\\wheel\\.\\import os; enabled = '
                "os.environ.get('SETUPTOOLS_USE_DISTUTILS') == 'local'; "
                "enabled and __import__('_distutils_hack').add_shim(); ",
 'install_libbase': 'build\\bdist.win-amd64\\wheel\\.'}

Weird - I notice that suffix has no space at the end:
'suffix': "import os; enabled = os.environ.get('SETUPTOOLS_USE_DISTUTILS') == 'local'; enabled and __import__('_distutils_hack').add_shim();"

But when I run it locally, I get a different result:
>>> install_lib = "build\\bdist.win-amd64\\wheel\\.\\import os; enabled = os.environ.get('SETUPTOOLS_USE_DISTUTILS') == 'local'; enabled and __import__('_distutils_hack').add_shim(); "
>>> install_libbase = 'build\\bdist.win-amd64\\wheel\\.'
>>> ntpath.relpath(install_lib, install_libbase)
"import os; enabled = os.environ.get('SETUPTOOLS_USE_DISTUTILS') == 'local'; enabled and __import__('_distutils_hack').add_shim(); "

Well, that's annoying. The pypy3 tests on macOS only are failing the new test. I guess that's expected, since we know pypy imports stdlib distutils on startup.

Hmm, is that because it imports distutils before the pth file is executed?

Hmm, is that because it imports distutils before the pth file is executed?

That's right.
$ pypy3 -V
Python 3.6.9 (?, Apr 18 2020, 02:46:07)
[PyPy 7.3.1 with GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1<IP_ADDRESS>)]
$ pypy3 -S -c "import sys; print('distutils' in sys.modules)"
False
$ pypy3 -c "import sys; print('distutils' in sys.modules)"
True

If I recall correctly (low confidence), pypy for Python 3.7 no longer has this issue.
But here's something weird:
$ pypy3 -S -c "import site, sys; print('distutils' in sys.modules)"
False

I thought the only thing -S did was skip import site.

TIL:

-S: Disable the import of the module site and the site-dependent manipulations of sys.path that it entails. Also disable these manipulations if site is explicitly imported later (call site.main() if you want them to be triggered).

~ $ pypy3 -S -c "import site, sys; site.main(); print('distutils' in sys.modules)"
True

It's the calling of sysconfig.getconfigvar that causes the import of distutils:
$ pypy3 -S -c "import sys, sysconfig; print('distutils' in sys.modules); sysconfig.get_config_var('foo'); print('distutils' in sys.modules
)"
False
True

Right - now I remember:
$ pypy3 -S -c "import sys, _sysconfigdata; print('distutils' in sys.modules)"
True

It does appear that even on the unreleased PyPy for Python 3.7 still imports distutils early.

Perhaps there are some optimizations or tweaks we can make for PyPy, but for now, I'd prefer to push forward with this approach.

Released as 49.3.0

This PR shouldn't have closed the issue. The issue is not fixed and manifests just as it did before. It's now only able to be bypassed by setting an environment variable. So to fix it still requires me an arbitrary environment variable change in my code...

Thanks Bernát, though I'm not sure I follow. #2259 reported an issue that when the new distutils is included, it only works when setuptools is imported prior to importing distutils. This patch fixed that condition. #2259 was not about ensuring that distutils was preferred in all environments, though that's still a goal.
I have added new issues to the milestone to capture ongoing efforts. If that doesn't capture the missed use-cases, please elaborate.


Smaller UI elements

The page should be redesigned with smaller UI elements so that more information can fit on the screen. I'm not sure how to implement this best yet.

I made the elements smaller by using Font Awesome and Tooltips so as to free up space for text. I also did a better job of grouping them by element. With the newly added piano keyboard, an option to show it or hide it is present.


Multiple rounds of training

Hello, if I want to train vicuna for multiple rounds of dialogue, how should I format the data set? Can you give me an example? Thanks

Thanks for your interest in LMFlow! You may utilize our recently integrated "ShareGPT" format, whose *.json file has a format as follows,
Conversation

Work in Progess: We are rapidly working on this data format.

Conversational data are commonly used in sft process. We currently support conversational data in ShareGPT format:
{
  "type": "conversation",
  "instances": [
    {
      "conversation_id": "CONVERSATION_ID",
      "system": "SYSTEM_PROPMT",
      "tools": ["TOOL_DESCRIPTION_1","TOOL_DESCRIPTION_2","TOOL_DESCRIPTION_X"],
      "messages": [
        {
            "role": "user",
            "content": "USER_INPUT_1"
        },
        {
            "role": "assistant",
            "content": "ASSISTANT_RESPONSE_1"
        },
        {
            "role": "user",
            "content": "USER_INPUT_2"
        },
        {
            "role": "assistant",
            "content": "ASSISTANT_RESPONSE_2"
        }
      ]
    },


More info at: https://travis-ci.com/Qiskit/qiskit-terra/jobs/188199958

This is a duplicate of https://github.com/Qiskit/qiskit-terra/issues/2029 closing so we can track it there.