IR and Color Same Time

Is there any possibility to stream both color and ir image simultaneously?

due to the limit of OpenNI2,  can't stream both color and ir at same time


Fix bug in mapping studentIdsByRoom to students

Fixing bug in https://github.com/studentinsights/studentinsights/pull/1664
Who is this PR for?
K1-6 teachers.
What problem does this PR fix?
JS bug led to unexpected movement after letting go of the drag.
Checklists

[x] Author improved specs for code in need of better test coverage

selfie


Is the change feed reliable?

The changes seem to be captured via a database trigger which happens after say and insert or update.
https://github.com/WeWatchWall/stark-db/blob/f0924b6e9ce7acfc0148d0c5336fb7360cc69066/src/utils/queries.ts#L195
Database tirggers are not guarentted to trigger in a transaction/atomically - leading to lost updates.
https://stackoverflow.com/questions/72300628/are-sqlite-triggers-guaranteed-to-always-be-executed-with-their-corresponding-tr
You'd be better off modifying the insert to transcationally write to both tables like in the outbox pattern.
https://microservices.io/patterns/data/transactional-outbox.html

@murraybauer
FIY: https://sqlite.org/forum/info/2a650a70a6136537fa2d08789b63f1863ad28a55b871a7e7e9564664c8c7a87e


Strange delay/lag in reducer output

Is there any reason there would be a slight lag in Redux's reducer output? The action fires off immediately, as I can see in the browser console. See GIF below.

The action and reducer in question:
Action:
export const PLAY_URL = 'PLAY_URL';
export function playUrl(id) {
  return {
    type: PLAY_URL,
    id,
  }
}

Reducer:
export default function (state = initialState, action) {
  switch (action.type) {
    case PLAY_URL:
      return Object.assign({}, state, {playingId: action.id});
    default:
      return state;
  }
}

Never mind, my own dumb mistake! :)

i have save issue. could you say your fault and solution


Use #[serde(flatten)] for composition

I have a branch of rust-analyzer that uses this at https://github.com/kjeremy/rust-analyzer/tree/flatten
Fixes #82

Released in 0.59


Support for setjmp / longjmp

Motivation
https://github.com/rust-lang/libc/pull/1216 proposes adding setjmp and longjmp to libc. These functions are required to interface with some C libraries, but sadly these functions are currently impossible to use correctly. Users deserve a solution that works and warns or prevents common pitfalls.
Issues with current solution
The first issue is that libc cannot add LLVM returns_twice attribute to setjmp:

This attribute indicates that this function can return twice. The C setjmp is an example of such a function. The compiler disables some optimizations (like tail calls) in the caller of these functions.

Basically, LLVM assumes that setjmp can return only once without this attribute, potentially leading to miscompilations (playground):
unsafe fn foo() -> i32 {
    let mut buf: jmp_buf = [0; 8];
    let mut x = 42;
    if setjmp(&mut buf) != 0 {  // Step 0: setjmp returns 0
        // Step 3: when setjmp returns 1 x has always been
        // modified to be  == 13 so this should always return 13:
        return x;
    }
    x = 13; // Step 1: x is modified
    longjmp(&mut buf, 1); // Step 2: jumps to Step 0 returning 1
    x // this will never be reached
}

// In debug builds foo returns 13 correctly, but
// in release builds foo returns 42
assert_eq!(unsafe { foo() }, 13); // FAILs in release

Because setjmp is not returns_twice, LLVM assumes that the return x; will only be reached before x = 13, so it will always return 42. However, setjmp returns 0 the first time, and returns 1 when jumped into it from the longjmp.
Using a volatile load instead works around this issue (e.g. playground). Basically, if stack variables are modified after a setjmp, all reads and writes until all possible longjmps will probably need to be volatile.
One way to improve this could be to add an stable attribute #[returns_twice] that users can use to mark that extern "C" { ... } functions can return multiple times and for Rust to handle these functions specially (e.g. by emitting the corresponding LLVM attribute). An alternative would be for Rust to provide these functions as part of the language.

Modulo LLVM-level misoptimizations, C only allows setjmp in specific "contexts" [0], and these features interact badly with languages with destructors. Rust does not guarantee that destructors will run (e.g. mem::forget is safe), so skipping destructors using longjmp is not unsound [1]. However, unsafe code will need to take into account that code outside it can use longjmp to skip destructors when creating safe abstractions (e.g. see Observational equivalency and unsafe code).
More worrying is how longjmp subverts the borrow checker to, e.g., produce undefined behavior of the form use-after-move without triggering a type error (playground):
fn bar(_a: A) { println!("a moved") }
fn foo() {
    let mut buf: jmp_buf = [0; 8];
    let a = A;
    if unsafe { setjmp(&mut buf) } != 0 {  // Step 0: setjmp returns 0
        bar(a);  // Step 3: a is moved _again_ (UB: use-after-move)
        return;
    }
    bar(a); // Step 1: a is moved here
    unsafe { longjmp(&mut buf, 1) };  // Step 2: jumps to Step 0 returning 1
}

This prints "a moved" twice, which means that the variable a was moved from twice, so the second time an use-after-move happened which type-checked. Obviously, longjmp is not the only way to achieve this in Rust, e.g. it is trivial to use the pointer methods to do so as well, but longjmp combined with Drop types makes this happen with no effort (playground):
struct A; impl Drop for A { ... }
fn bar(_a: A) {
   // _a is dropped here
}
fn foo() {
    let mut buf: jmp_buf = [0; 8];
    let a = A;
    if unsafe { setjmp(&mut buf) } != 0 {
        // use-after-move: a has been moved (and dropped) below
        // but a is used (and dropped) in this branch again
        // => double-drop => UB
        return;
    }
    bar(a); // moves a
    unsafe { longjmp(&mut buf, 1) };
}

That is, using setjmp+longjmp to create double-drops (undefined behavior) is trivial.
Finally, there are problems with creating wrappers around these functions (playground):
fn foo(buf: &mut jmp_buf) {
    let mut a: i32 = 42;
    if unsafe { setjmp(buf) } != 0 {
        dbg!(a);  // use-after-free
        panic!("done");
    }
    a = 13;
}

fn main() {
    let mut buf: jmp_buf = [0; 8];
    foo(&mut buf);
    let b: i32 = 666;
    dbg!(b);
    unsafe { longjmp(&mut buf, 1); }
}

Prints b = 666 and a = 0. The problem here is that this code saves the stack pointer inside foo, but then foo returns, and afterwards the longjmp jumps to a stack frame that is no longer live, so dbg!(a) reads a after it has been free'd (use-after-free).
There are probably many other problems with these two functions, that does not mean that they are impossible to use correctly. Still, it would be good to have a solution here that at least warns about potentially incorrect usages since reasoning about these and the surrounding unsafe code is often very tricky.
It would also be good to have a way to soundly model these in miri and detect when they are used incorrectly.
At a minimum we should be able to write down documentation for these functions in Rust. Where exactly can they be used, what does the unsafe code surrounding them need to uphold to be correct, etc.

cc @nikomatsakis (wrote blog post about observational equivalence and unsafe code), @rkruppe , @RalfJung @ubsan - the unsafe code guidelines should probably say whether extern "C" functions are allowed to modify the stack pointer etc. like setjmp/longjmp do.

[0] C11 <IP_ADDRESS>p4 states the following about setjmp:

An invocation of the setjmp macro shall appear only in one of the following contexts:

the entire controlling expression of a selection or iteration statement;
one operand of a relational or equality operator with the other operand an integer constant expression, with the resulting expression being the entire controlling expression of a selection or iteration statement;
the operand of a unary ! operator with the resulting expression being the entire controlling expression of a selection or iteration statement; or
the entire expression of an expression statement (possibly cast to void).

While C11 <IP_ADDRESS>p5 states:

If the invocation appears in any other context, the behavior is undefined.

That is, let x = setjmp(...); would be UB in C. In Rust having a result of a function be usable only in some contexts would be weird.

[1] In C++, skipping destructors with longjmp is undefined behavior, e.g., [support.runtime] states:

If any automatic objects would be destroyed by a thrown exception transferring control to another (destination) point in the program, then a call to longjmp(jbuf, val) at the throw point that transfers control to the same (destination) point has undefined behavior.

FWIW, here is the macro I am currently using, which seems like a valid use of sigsetjmp(), and the MVP above would satisfy my requirements.
#[macro_export]
macro_rules! longjmp_panic {
    ($e:expr) => {
        let retval;
        unsafe {
            use postgres_extension::utils::elog
                ::{PG_exception_stack,
                   error_context_stack,
                   PgError};
            use postgres_extension::setjmp::{sigsetjmp,sigjmp_buf};
            let save_exception_stack: *mut sigjmp_buf = PG_exception_stack;
            let save_context_stack: *mut ErrorContextCallback = error_context_stack;
            let mut local_sigjmp_buf: sigjmp_buf = std::mem::uninitialized();
            if sigsetjmp(&mut local_sigjmp_buf, 0) == 0 {
                PG_exception_stack = &mut local_sigjmp_buf;
                retval = $e;
            } else {
                PG_exception_stack = save_exception_stack;
                error_context_stack = save_context_stack;
                panic!(PgError);
            }
            PG_exception_stack = save_exception_stack;
            error_context_stack = save_context_stack;
        }
        retval
    }
}

It is intended to wrap a FFI function call which, when evaluated, may call siglongjmp() in accordance with the postgresql convention for throwing an exception. It can be used in a function like this:
#[inline(never)]
fn wrap_elog() {
    longjmp_panic! { elog_internal(file!(), line!(), ERROR, "test error") }
}

(In the above example, elog_internal() will always throw an exception and longjmp(). It's not a direct FFI call in this particular example, but it's close enough for illustration.)
I looked at the optimized IR, and it looks fine to me, but someone who understands this better might see a problem:
; udf_error::wrap_elog
; Function Attrs: noinline nonlazybind uwtable
define internal fastcc void @_ZN9udf_error9wrap_elog17he7efb2354edb7c3eE() unnamed_addr #\
8 {
start:
  %local_sigjmp_buf = alloca %"postgres_extension::setjmp::sigjmp_buf", align 8
  %0 = load i64, i64* bitcast (%"postgres_extension::setjmp::sigjmp_buf"** @PG_exception_\
stack to i64*), align 8
  %1 = load i64, i64* bitcast (%"postgres_extension::utils::elog::ErrorContextCallback"**\
 @error_context_stack to i64*), align 8
  %2 = bitcast %"postgres_extension::setjmp::sigjmp_buf"* %local_sigjmp_buf to i8*
  call void @llvm.lifetime.start.p0i8(i64 208, i8* nonnull %2)
  %3 = call i32 @__sigsetjmp(%"postgres_extension::setjmp::sigjmp_buf"* nonnull %local_si\
gjmp_buf, i32 0)
  %4 = icmp eq i32 %3, 0
  br i1 %4, label %bb3, label %bb4

bb3:                                              ; preds = %start
  store %"postgres_extension::setjmp::sigjmp_buf"* %local_sigjmp_buf, %"postgres_extensio\
n::setjmp::sigjmp_buf"** @PG_exception_stack, align 8
; call postgres_extension::utils::elog::elog_internal
  call void @_ZN18postgres_extension5utils4elog13elog_internal17h0f179afe9978ab59E([0 x i\
8]* noalias nonnull readonly bitcast (<{ [10 x i8] }>* @1 to [0 x i8]*), i64 10, i32 14, \
i32 20, [0 x i8]* noalias nonnull readonly bitcast (<{ [10 x i8] }>* @2 to [0 x i8]*), i6\
4 10)
  store i64 %0, i64* bitcast (%"postgres_extension::setjmp::sigjmp_buf"** @PG_exception_s\
tack to i64*), align 8
  store i64 %1, i64* bitcast (%"postgres_extension::utils::elog::ErrorContextCallback"** \
@error_context_stack to i64*), align 8
  call void @llvm.lifetime.end.p0i8(i64 208, i8* nonnull %2)
  ret void

bb4:                                              ; preds = %start
  store i64 %0, i64* bitcast (%"postgres_extension::setjmp::sigjmp_buf"** @PG_exception_s\
tack to i64*), align 8
  store i64 %1, i64* bitcast (%"postgres_extension::utils::elog::ErrorContextCallback"** \
@error_context_stack to i64*), align 8
; call std::panicking::begin_panic
  call fastcc void @_ZN3std9panicking11begin_panic17hc642c894ac6ffd69E()
  unreachable
}

This usage is quite constrained, but it serves my purposes. Because the wrapper function is always almost identical (just the FFI call expression changes), and because it's marked #[inline(never)], there are unlikely to be any more optimizations applied that could cause a problem.
Note that sigsetjmp() is declared as:
; Function Attrs: nounwind nonlazybind uwtable
declare i32 @__sigsetjmp(%"postgres_extension::setjmp::sigjmp_buf"*, i32) unnamed_addr #4

but it should have the returns_twice attribute as well. This means that it may be undefined behavior, but in such a constrained use I don't see an obvious way that it would misoptimize it.

In practice, returns_twice in LLVM only affects a few things, but the things it does affect are important:

Disables stack slot coloring, aka reusing the same stack slot for unrelated variables with disjoint lifetimes (and ditto for WebAssembly locals);
When AddressSanitizer is on, disables allocating locals on the heap (for somewhat dubious reasons);
Disables tail call optimization;
Ensures that functions that call returns_twice functions cannot themselves be inlined into other functions (i.e. what @jeff-davis replicated manually with #[inline(never)]);
On SPARC, don't assume that the register window mechanism will automatically restore registers.
When X86SpeculativeLoadHardening is enabled (Spectre paranoia mode), change a gadget added after roughly every call, which normally tries to read from the callee's return address stack slot to ensure the return to the current IP wasn't mispredicted.

At least the AddressSanitizer, X86SpeculativeLoadHardening, and SPARC ones seem potentially relevant even to a simple function like wrap_elog, so I would recommend ensuring that the returns_twice attribute is added.

At least the AddressSanitizer, X86SpeculativeLoadHardening, and SPARC ones seem potentially relevant even to a simple function like wrap_elog, so I would recommend ensuring that the returns_twice attribute is added.

The path of least resistance would be to add a #[rustc_returns_twice] attribute to rustc, and add these functions to libc, exposing them only for libc's that are built as part of the Rust standard library, using that attribute in that case. We then would need to expose those functions through standard somehow.

#[returns_twice] would also alert the borrow checker to the multiple-return nature of functions annotated with it, so it should be able to figure out that the example given is invalid:
fn bar(_a: A) { println!("a moved") }
fn foo() {
    let mut buf: jmp_buf = [0; 8];
    let a = A;
    if unsafe { setjmp(&mut buf) } != 0 {
        bar(a);  // error[EO382]: use of moved value: `a`
        return;
    }
    bar(a); // Note: `a` was previously moved here
            // Note: `setjmp` may return multiple times
    unsafe { longjmp(&mut buf, 1) };
}

@eaglgenes101 I don't think it can work like that, at least if the lint is only based on #[returns_twice]. This is a different way of writing that example:
fn bar(_a: A) { println!("a moved") }
fn foo() {
    let mut buf: jmp_buf = [0; 8];
    let a = A;
    if unsafe { setjmp(&mut buf) } == 1 {
        bar(a);
        return;
    } else {
        bar(a);
    }
}

At best we could error stating that different branches depending on a #[return_twice] "value" move the same value (if the value is not Copy), but I doubt the error message can get better than that without actually specifying how setjmp and friends work (e.g. returning 0 on first call, and non-zero when being jumped into). We'd probably need a #[setjmp_like] attribute for that.

Why is it important for Rust to support setjmp/longjmp at all? The motivation says "Users deserve a solution that works and warns or prevents common pitfalls." However, that is not motivation as far as an RFC is concerned; it is just a statement of opinion with no supporting evidence.
Strawman: Document in the libc crate that they are intentionally omitted. Document that using them at all is undefined behavior. Motivation: Avoiding this functionality saves a lot of complexity and time, and it is unlikely that any attempt to implement it would be correct any time soon.

@briansmith some C libraries emulate exceptions using setjmp/longjmp and use that as their error reporting mechanism (e.g. Postgres).

some C libraries emulate exceptions using setjmp/longjmp and use that as their error reporting mechanism (e.g. Postgres).

Some C++ libraries use C++ exceptions too, but Rust doesn't support them either, even though they're much more reasonable than setjmp/longjmp.
Of course it's nice to support Postgres but I think we should try to find ways of doing it that don't involve adding setjmp/longjmp to Rust.

Some C++ libraries use C++ exceptions too,

Rust has C FFI, AFAIK it does not have C++ FFI (yet).
These are C functions available on all systems with a C standard library and are easily callable via C FFI. If we want Rust to be able to interoperate with all correct and potentially legacy C code out there via its C FFI, we need to support them in some form.

Of course it's nice to support Postgres but I think we should try to find ways of doing it that don't involve adding setjmp/longjmp to Rust.

I would be interested in better ways of interfacing with Postgres, and I think @jeff-davis would be interested too. My first suggestion was for @jeff-davis to write a C wrapper that performs the setjmp/longjmp without propagating it to Rust, so that Rust code calling the wrapper does not have to use these functions.

If we want Rust to be able to interoperate with all correct and potentially legacy C code out there via its C FFI, we need to support them in some form.

I don't think that is a goal, and I don't think it should be, especially in cases where one can work around the issues by writing a little bit of C that wraps the other C code and resolves the issue. I don't know about va_args issue and the decision making in it. I think setjmp/longjmp has a lot broader negative impact on Rust than va_args. (I am no fan of va_args either, BTW.)

I would argue it really doesn't have a lot of impact. One might add some extra cases to the borrow checker, but other than that it's fairly similar to simple exception handling, something that Rust already has.
On the other hand, would it be possible to make it #[rustc::returns_twice]? That seems like the best way to do namespacing here.

On the other hand, would it be possible to make it #[rustc::returns_twice]?

So currently all rustc internal attributes start with #[rustc_...], if this were to be changed, it would make sense to do that for all internal attributes at once.

Although it seem better to call it #[returns_twice] or something along those lines, for FFI?

That's an open question. Is #[returns_twice] as an attribute useful enough to warrant going through the stabilization process ? Also, I worry that doing this might be stabilizing an LLVM-ism. Would this attribute be useful for Cranelift (cc @sunfishcode ) ?

Here's what compcert's documentation has to say about setjmp/longjmp:
http://compcert.inria.fr/man/manual005.html:
§7.13 Non-local jumps <setjmp.h>
The CompCert C compiler has no special knowledge of the setjmp and longjmp functions, treating them as ordinary functions that respect control flow. It is therefore not advised to use these two functions in CompCert-compiled code. To prevent misoptimisation, it is crucial that all local variables that are live across an invocation of setjmp be declared with volatile modifier.

GCC, for one, supports a returns_twice attribute.

@briansmith A lot of languages work well with C in the easy cases. I love rust because it works well with C in the hard cases.
I would really like to allow pure rust extensions to be written for postgres. Introducing C creates a lot of headaches that I'd rather not deal with.

@comex rust-lang/libc does not expose vfork, but that comment suggest that #[returns_twice] would also be required there. The blog post vfork considered dangerous by Rich Felker (main author/developer of musl), is a great read, it explains:

[vfork] works like fork, but without creating a new virtual address space; the parent and child run in the same address space. Unlike with pthread_create, where the new thread runs on its own stack, vfork behaves like fork and “returns twice”, once in the child and once in the parent. This seems impossible, since the parent and child would clobber one another’s stacks, but a clever trick saves the day: the parent process is suspended until the child performs exec or _exit, breaking the shared-memory-space relation between the two processes.
vfork was omitted from POSIX and modern standards because it’s difficult to use [...] However, many systems (including Linux) still provide a similar or identical interface at the kernel level, and new interest in its use has arisen again due to the fact that huge processes cannot fork on systems with strict commit charge accounting due to lack of memory, and the fact that copying the virtual memory layout of a process can be expensive if the process has a huge number of maps created by mmap. As such, both musl and glibc use vfork to implement posix_spawn, the modern interface for executing external programs as a new process.

If it were only setjmp, then a hack in the form of a #[rustc_returns_twice] private attribute might have been ok, but it appears that there are multiple low-level platform APIs that can invalidate the optimizers assumptions by being able to return multiple times and people might want to create bindings to these in their own code instead of only accessing them via the standard library or libc.So i'm leaning towards having a real #[returns_twice] attribute for this.
Does anybody know why it is called returns_twice in GCC? AFAICT vfork can only return twice, but setjmp can return multiple times. I don't know if this distinction matters.

Unrelated question, the GCC docs for returns_twice also mention:

The longjmp-like counterpart of such function, if any, might need to be marked with the noreturn attribute.

Since C++17, the signature of longjmp is:
[[noreturn]] void longjmp( std::jmp_buf env, int status );

so in Rust longjmp should return -> !.

Does anybody know why it is called returns_twice in GCC? AFAICT vfork can only return twice, but setjmp can return multiple times.

Yes, it's legal in C to longjmp to the same jmp_buf multiple times, which would cause setjmp to return more than twice.  I think "twice" is used just because it's shorter than, say, "multiple_times" would be.

so in Rust longjmp should return -> !, right?

I believe so.

So I wrote an RFC for this: https://github.com/gnzlbg/rfcs/commit/e9ac14eabf58a40c1cd1b28db36bd1d2230d2a9f
Early feedback (e.g. as a comment on that commit) would be really appreciated.
Rendered

@jeff-davis Here's how I dealt with postgres errors in rust: https://github.com/main--/rustgres/blob/master/src/error.rs
Basically since postgres errors already emulate unwinding I simply catch them, then panic to unwind through the Rust world, then on the lower end catch the panic and translate it back into a postgres error. Works just fine with virtually no performance overhead.

An implementation of my RFC has a rust-lang/rust PR: https://github.com/rust-lang/rust/pull/58315

From the RFC:

Well, currently it returns 13 in debug mode, and 42 in release. This is because Rust assumes that setjmp can only return once. Under this assumption, if it returns a value that's not zero, then the value of x at that point must be 42 because the x = 13 assignment will never be reached.
The #[returns_twice] attribute specifies that a function might returns multiple times, inhibiting optimizations that assume that this is never the case.

What you wrote accurately describes what returns_twice does in GCC, where it "ensures that all registers are dead before calling such a function", i.e. saves all variables across the call on the stack rather than in callee-saved registers.  (When longjmp is called, it doesn't affect the stack, but it resets registers to their state as of the call to setjmp.)  But LLVM does not seem to implement this behavior, based on the search I did through its codebase to find checks for returns_twice.
For concrete evidence, look at this:
https://gcc.godbolt.org/z/E4ZvMm
In GCC, changing setjmp to notsetjmp (i.e. a function not marked with returns_twice) changes the generated code: x is saved in the register r12d instead of on the stack at [rsp+12].  But if you switch the compiler to clang, the only difference in the assembly from changing setjmp to notsetjmp is which function is called, and in both cases x is saved in the register ebx.
In short, while GCC tries to provide consistent behavior for all variables, Clang/LLVM is relying on users manually marking variables as volatile to prevent them going back in time, as prescribed in the C standard:

All accessible objects have values, and all other components of the abstract machine have state, as of the time the longjmp function was called, except that the values of objects of automatic storage duration that are local to the function containing the invocation of the corresponding setjmp macro that do not have volatile-qualified type and have been changed between the setjmp invocation and longjmp call are indeterminate.

What returns_twice does in LLVM is to inhibit optimizations which could break code even if it uses volatile as prescribed, such as tail call optimization (which clobbers the caller function's stack frame: no good if the callee might longjmp to earlier in the caller).
Interestingly, the GCC behavior is buggy anyway, as it doesn't properly inhibit constant folding:
https://gcc.godbolt.org/z/g9IK_4
Anyway, I suggest changing the RFC text to enforce the same requirement as the C standard.  Rust does have an equivalent of volatile, but it's worth noting that in practice, most users of setjmp don't actually need to use volatile; they can just avoid the dangerous situation, i.e. setting variables before setjmp and then mutating them after, altogether.

@clobber The example in the RFC has UB even if #[returns_twice] is used because, as you point out, there should be a read_volatile in the return x statement. We need a better example, and the RFC should make it clear that it is not an RFC about specifying the semantics of setjump and longjump.

It looks like #2633 and #2637 are still pretty far away from resolution. Is there something we can do in the short term to make progress on just the special cases of setjmp and sigsetjmp getting into stable libc?
Is it reasonable to do some kind of special case here that passes returns_twice down to LLVM until we can work out #2633 and #2637? Or am I asking for too much?
Just like in C, it would also need documentation on how to use it without invoking undefined behavior, but I think that's unavoidable.

Maybe it would be a good start to just get setjmp/sigsetjmp in unstable libc using #[ffi_returns_twice].
Then we can work on a way to somehow allow a crate to use it in stable rust (perhaps by specifying a crate feature)?

Is there something I can do to help this move forward?

I have seen a fair amount of interest in my project (postgres-extension.rs), including multiple conference talks and internal presentations to several groups at my place of employment. There are also similar projects, like pg-extend.rs.
Unfortunately, it's hard to make the case that these projects actually work without a working setjmp making its way to stable rust. I was excited to see this RFC, and the other related ones, but it seems like activity has stopped and I'm not really sure how to move things forward. The recent commit 9db595fe makes me worried that we're giving up on the idea.
Any suggestions?

What that commit is doing is the safe bet, because right now the situation is unclear. If I were to do this right now, I would just write a tool that auto-generates a C shims that automatically insert setjmp/longjmp on the C side, only communicating error codes back to Rust.
I think that the best way to attack this problem would be an RFC to add setjmp/longjmp APIs to the language, guaranteeing the interaction of these APIs with the rest of the language. This would probably be a massive language change that's not on the roadmap.
In the meantime, one can play with returns_twice on nightly, but that's just the bare minimum for this to be able to work at all. There are no guarantees that such code is correct.

I don't see why we'd want to make setjmp defined in all cases -- we just need it to be defined in some cases, just like other unsafe code. So for me, the bare minimum of something like returns_twice is fine, but without some kind of progress toward stable rust, I don't see the point.

I don't see why we'd want to make setjmp defined in all cases -- we just need it to be defined in some cases, just like other unsafe code.

Currently the behavior of jumping over Rust code is undefined in all cases, and there is no RFC that changes that in any way. There is an RFC for a returns_twice attribute that allows passing an attribute to LLVM, but that RFC does not allow jumping over Rust code.

I don't need setjmp to jump over rust code. I just need it to catch jumps out of C code into rust code.

Still, something like this:
let b = setjmp(&mut buf);
c_ffi_fn(buf);

has a jump in Rust code if c_ffi_fn is allowed to jump back to setjmp.
The jump is minimal, but it is still there =/

What if we just defined very tight restrictions for the use of a returns_twice function that are unlikely to be subtly broken later. Something like:
For any function that calls a returns_twice FFI function:

Don't inline it into another function
Don't apply any optimizations to the rust code for that function (though LLVM may optimize it)
Undefined if that function refers to any data types that are allocated on the heap or have a destructor
Whatever other restrictions are necessary to make this work.

In other words, I could live with even the most sweeping restrictions if they help avoid the problems that you are worried about. The pattern for something like setjmp is very narrow.

I'm just pointing out that somebody would need to write an RFC explaining what it means to jump over at least some subset of Rust code, however minimal that is, and push it through the process.
Like even if we were only to allow this pattern:
setjmp(&mut buf);
c_ffi_fn(&mut buf, some_arg);

if some_arg is copy you end up with something like this:
setjmp(&mut buf);
{
    let _tmp = copy some_arg;
    c_ffi_fn(&mut buf, _tmp);
}

such that c_ffi_fn can jump over let _tmp = copy some_arg; statement. If we do not define anywhere that doing so is ok, the behavior is not defined.
We have explored here a lot of things that would be ok, and a lot of things that would not. So there is definitely enough material for someone to try to write down such an RFC. We don't have a WG FFI yet, but such work could be part of it, which could help push it through the process (cc @joshtriplett ).

Thank you. That sounds like a good way to move forward.

Just checking in to see if any off-thread progress has been made?
I'm happy to help - just not sure what that help would be at this stage ...

I don't know how useful this feedback is, but I use setjmp() regularly in nasty kernel selftests that I've written, and I don't actually want the returns-twice behavior.  For example, I use it to exit a block of code from a signal handler.  The fact that sigsetjmp returns twice just makes the code more convoluted than it deserves to be.
The feature I would actually want is a lot closer to panic!/catch_unwind.  Here's an example that might be semantically sensible even though it has atrocious syntax:
sig_try(|jmpbuf| {
    some code;
    if (condition) { jmpbuf.jump_out() }
})

The sematics are that, if no one calls jmpbuf.jump_out(), then sig_try just runs the code in the closure normally.  Otherwise, if the closure calls jump_out, it jumps to the end of the sig_try with similar semantics to panicking and unwinding. except that it's guaranteed to hit the correct landing pad and that it is explicitly permitted to jump out from a signal handler.  (The latter bit probably gets tricky if the signal happens at a bad time, so maybe that needs more care.) This could conceivably even be usable from safe Rust.
Some benefits over sigsetjmp: nothing actually returns twice.  jump_out doesn't return at all.  Each bit of Rust code executes zero or one times.  I think that jmpbuf could be a plain (&) reference to a non-Send non-Sync type, so it's impossible for the closure to stash it away anywhere or otherwise cause jump_out to be invoked more than once or to be invoked after the closure returns.
And I think this would give me all of the functionality I have ever wanted from setjmp or sigsetjmp.

IIRC, that's all that's needed when trying to use libpng, as long as you can choose where the jumpbuf is stored and call jump_out on a new reference to that. My guess is the vast majority of setjmp/longjmp uses also fit that pattern.

You can implement sig_try using inline assembly, you don't even need naked functions. It's very similar to coroutine stack switching (e.g. libfringe) except you stay on the same stack.

I assume jmpbuf is not allowed to leak from the closure? If so, we'd call this a "delimited continuation" in PL research, which indeed is less powerful and better behaved than general continuations.

just some questions (perhaps rust internal is a better place? But here is already an open issue.)
I am investigating to create bindings forkoka-lang/libmprompt. Currently, the work is at https://github.com/SchrodingerZhu/libmprompt-sys
The example translated from C is very promising and it works:
https://github.com/SchrodingerZhu/libmprompt-sys/blob/main/src/lib.rs
But considering that the library relies heavily on the operations in the manner of longjmp, I am afraid that such operations may easily break up rust runtime.
So is there any previous discussion on the potential danger of such operations?

Was there ever any resolution to this.
In R, for example, errors are thrown using setjmp/longjmp and we would like a way to catch
errors that come from C code in this way.
Currently, I am using a panic as a poor cousin alternative but panics from C-called functions
are very much not guaranteed and fail completely to be caught in many cases (such as Win32).
@amluto, @Amanieu I like the sig_try solution to the problem and would vote in its favour.

The question is, where should sig_try (or whatever we chose to name this) actually reside? It seems like a poor fit for the standard library since this is only useful when interacting with C code.
Ideally it should be in libc as some sort of setjmp_wrapper as the only way setjmp can be called from Rust, but this would require that libc use unstable features (either asm! or #[ffi_returns_twice]) which is not currently possible.
A final possibility would be for this to belong in a third party crate which wraps the setjmp call in a C function that is built from build.rs.

The question is, where should sig_try (or whatever we chose to name this) actually reside? It seems like a poor fit for the standard library since this is only useful when interacting with C code.

Well, CStr is basically only used when interacting with C code, yet it's in the standard library -- I don't see how setjmp should be any different.

The question is, where should sig_try (or whatever we chose to name this) actually reside? It seems like a poor fit for the standard library since this is only useful when interacting with C code.

Well, CStr is basically only used when interacting with C code, yet it's in the standard library -- I don't see how setjmp should be any different.

Maybe VaList is a better example, it's in the same category as setjmp: things which require special compiler support.

Not exactly: VaList and CStr don't rely on external support in libc, they are entirely implemented within the standard library. This isn't the case for setjmp which is tied to the particular implementation in the libc of the target.
Then there's also vfork, which suffers from the exact same issues as setjmp: the only way to call it safely would be to wrap it so that the child process only executes within a closure, just like sig_try. Should a vfork wrapper also be provided in the ggi module?

Not exactly: VaList and CStr don't rely on external support in libc, they are entirely implemented within the standard library. This isn't the case for setjmp which is tied to the particular implementation in the libc of the target.
Then there's also vfork, which suffers from the exact same issues as setjmp: the only way to call it safely would be to wrap it so that the child process only executes within a closure, just like sig_try. Should a vfork wrapper also be provided by the standard library?

hmm, maybe instead there could be a macro kinda like this:
macro_rules! returns_twice_wrapper {
    ($vis:vis extern $abi:literal unsafe fn $id:ident($($args:ident: $arg_tys:ty),*) -> $ret:ty;) => {
        $vis unsafe fn $id<R>(f: impl FnOnce($ret) -> R, $($args: $arg_tys),*) -> R {
            extern $abi {
                #[returns_twice]
                fn $id($($args: $arg_tys),*) -> $ret;
            }
            let v = $id($($args),*);
            f(v)
        }
    };
}

use like:
returns_twice_wrapper! {
    extern "C-unwind" unsafe fn setjmp(v: *mut jmp_buf) -> c_int;
}

fn test_setjmp() {
    unsafe {
        let mut jb: MaybeUninit<jmp_buf> = MaybeUninit::uninit();
        let jb = &mut jb as *mut _;
        setjmp(|v: c_int| {
            if c == 0 {
                println!("between setjmp and longjmp");
                longjmp(jb, 1);
            } else {
                println!("after longjmp");
            }
        }, jb)
    }
}


DataPrep  extract info from image in the docs

extract info from image in the docs

It's implemented in this pr https://github.com/opea-project/GenAIComps/pull/120.


Native hooks: Fix build error due to missing std::string declaration

This fixes a build failure when building VFSForGit with Xcode 10 and the macOS 10.14 SDK. std::string should only be used after #include <string>.
I noticed the problem while trying to run a full Scripts/Mac/BuildGVFSForMac.sh on macOS 10.15 GM, with Xcode 10.2.1 set as the default toolchain. (The CI uses Xcode 9 and the macOS 10.13 SDK, which is fine as we're still targeting 10.13, but we'll presumably eventually move up.)

/azp run GitHub VFSForGit Mac Functional Tests


I think it must be some kind of package import problem but I don't understand how go dependencies work so I'm not sure how to fix it. It's probably trying and failing to use this errors package: https://pkg.go.dev/errors

The issue is related to the old go version available via apt on RPi, to fix it just uninstall old version and grab the latest from: https://golang.org/doc/install


kvstore: prevent deletion delay for node-unrelated events

Please, refer to the commit messages for more information.

kvstore: prevent deletion delay for node-unrelated events

/test

/ci-verifier

/test-1.16-4.19

k8s-1.16-kernel-4.19 hit https://github.com/cilium/cilium/issues/23845

/test-1.16-4.19

k8s-1.16-kernel-4.19 hit https://github.com/cilium/cilium/issues/23845
/test-1.16-4.19

/test-1.16-4.19

/test-1.16-4.19

/test-1.16-4.19

Rebasing to pick the fix for https://github.com/cilium/cilium/issues/23845

/test

/ci-verifier


(helper-)cli: Remove redundant mentions of available / default values

Please have a look at the individual commit messages for the details.

Merging despite the unrelated PipFunTest failure.


Bugfix 224

[x] Closes #224
[x] Tests added
[ ] Passes black .
[ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

Ok so I have patched this behavior, but the handling of kwargs throughout the module is kind of a mess still.
The 'default' value is set in many spots (like here and here), where I am wondering if it should be a kwarg (Id suggest making it an argument).
It will be a larger undertaking to refactor all of this, but I think is should be a medium high priority, which will enable new contributors to understand the code much easier.

It also gets set in the Axis/Grid _init_, so I feel this is confusing in the long term. But yes. Lets add this fix and then discuss further refactoring in another issue (I added some text to #207 to remind us/me).


texturemipmapgen demo is crashing at vkQueueSubmit "ERROR_DEVICE_LOST"

Error Popup:
Assertion failed!
Program : ...lkan-master\Vulkan-master\bin\texturemipmapgen.exe
File: texturemipmapgen.cpp
Line: 425
Expression: res == VK_SUCCESS
Validation output:
WARNING: [ParameterValidation] Code 9 : vkQueueSubmit: returned VK_ERROR_DEVICE_LOST, indicating that the logical device has been lost
Fatal : VkResult is "ERROR_DEVICE_LOST" in texturemipmapgen.cpp at line 425
Platform is windows 10 and using latest vulkan sdk version (<IP_ADDRESS>) and built with visual studio 2017
Gpu is AMD r9 280, with driver version 17.1.1

Working fine for me with an AMD R9 390X using the latest driver and the same SDK version. Is this also happening with the pre-built binaries or only when running from the IDE?

It crashes with both the binary and the IDE

+1
Win 10, vulkan sdk <IP_ADDRESS>, visual studio 2015.
GPU AMD Radeon HD7800, driver <IP_ADDRESS>

Running the demo again on the same hardware works for some reason with Vulkan SDK version 1.1.70 and AMD drivers 18.3.4.


Issues in modification of the Hazard3 ALU code for addition

Hi,
I am quite new to this RISC-V space and trying to understand how the architecture is working. To obtain it, I am attempting to change the ALU addition operation so that it reads op_a + op_b + 5 rather than op_a + op_b. I have tried so many ways to see the effect on the terminal. But it's not displying anything and displaying max cycles reached. Any idea how to modify the existing ALU addition code will be really helpful as the kickstart.

What are you trying to achieve? If you just modify the result of all add instructions then any compiled software which relies on the add instruction operating normally will fail to run.

Hi @Wren6991 , Thanks for reverting back.
Our objective is to modify the ALU such that I can get the effect of the change in the terminal. And that could be anything, like changing the LSB bit of op_a to 0 or the addition operation or any modification inside the ALU code. The reason I am doing this is because of two reasons:

In the future, we may explore the effects of approximate computing on the existing applications to get the performance numbers on the Hazard3 processor.
And along with this, we were trying to build a simulator to predict the performance metrics for any RISC architecture along with its extensions.

Any pointers on where to start if I want to change the LSB bit of op_a to 0. Will be really helpful.

Our objective is to modify the ALU such that I can get the effect of the change in the terminal

You mean you would like to print from software on the processor to stdout? This requires you to run a substantial amount of compiled code, which is not going to tolerate any deviation between the calculation specified in the ISA manual and the actual ALU result. Addition is not just used for + operators in your program, it's also used for address generation behind the scenes.
If 2 + 3 does not equal 5 then the core is not a RISC-V core.

If you would like to add new operations with different results, you should add these as custom instructions so that they can be used alongside the standard instructions required by the compiler. Take a look at the code controlled by the EXTENSION_XH3BEXTM parameter for an example of this.
You mentioned approximate computing, but as the ALU will still have to implement both the precise and approximate versions of the calculation, I don't expect this would improve your energy per instruction.

If you would like to add new operations with different results, you should add these as custom instructions so that they can be used alongside the standard instructions required by the compiler. Take a look at the code controlled by the EXTENSION_XH3BEXTM parameter for an example of this.
You mentioned approximate computing, but as the ALU will still have to implement both the precise and approximate versions of the calculation, I don't expect this would improve your energy per instruction.

Thanks for the amazing and brief explanation @Wren6991 . One last question: could you please suggest a way so that I can add my own custom instruction in such a way that I won't violate the existing logic? Is there any documentation available? And from a FPGA developer who is quite comfortable with the Verilog, how much time do you think it would take to implement on top of the existing Hazard3 processor modules?


Update entrypoint.sh

@rabiejavadian
I'm not looking to take away from your solution. (Really cool!)
Another alternative is to simply comment out the pip3 install PyYAML line and add python3-yaml to the earlier apt-get command.
RUN apt-get update && apt-get install -y \
    python3.10 \
    python3-pip \
    git \
    python3-yaml


Cannot connect to GigE Blackfly S

I am trying to use a GigE Blackfly S with this driver and the nodelet is crashing without any error messages. I've correctly set the camera serial and experimented with both binning 1 and 2 and left all other parameters at default. I can confirm that the camera works perfectly fine in spinview. Here is the log output:
started roslaunch server http://alex-desktop:35887/

SUMMARY
========

PARAMETERS
 * /acquisition_node/binning: 2
 * /acquisition_node/cam_aliases: ['cam0']
 * /acquisition_node/cam_ids: [19220523]
 * /acquisition_node/color: True
 * /acquisition_node/delay: 1.0
 * /acquisition_node/distortion_coeffs: [[-0.021141875266...
 * /acquisition_node/distortion_model: plumb_bob
 * /acquisition_node/exposure_time: 0
 * /acquisition_node/frames: 3400
 * /acquisition_node/image_height: 1536
 * /acquisition_node/image_width: 2048
 * /acquisition_node/intrinsic_coeffs: [[1886.9232141485...
 * /acquisition_node/live: False
 * /acquisition_node/live_grid: False
 * /acquisition_node/master_cam: 19220523
 * /acquisition_node/max_rate_save: False
 * /acquisition_node/projection_coeffs: [[913.700317, 0.0...
 * /acquisition_node/rectification_coeffs: [[1.0, 0.0, 0.0, ...
 * /acquisition_node/save: False
 * /acquisition_node/save_path: ~
 * /acquisition_node/save_type: bmp
 * /acquisition_node/skip: 20
 * /acquisition_node/soft_framerate: 30
 * /acquisition_node/target_grey_value: 0
 * /acquisition_node/time: False
 * /acquisition_node/to_ros: True
 * /acquisition_node/utstamps: False
 * /rosdistro: melodic
 * /rosversion: 1.14.3

NODES
  /
    acquisition_node (nodelet/nodelet)
    vision_nodelet_manager (nodelet/nodelet)

auto-starting new master
process[master]: started with pid [12907]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 07f42e1e-bd37-11e9-b8e2-7085c2ae64f9
process[rosout-1]: started with pid [12918]
started core service [/rosout]
process[vision_nodelet_manager-2]: started with pid [12922]
process[acquisition_node-3]: started with pid [12926]
[ INFO] [1565637967.211156336]: Initializing nodelet with 8 worker threads.
[ INFO] [1565637967.288913402]: Initializing nodelet
[ INFO] [1565637967.289453491]: [ OK ] USB memory: 1000 MB
[ INFO] [1565637967.289478199]: *** PARAMETER SETTINGS ***
[ INFO] [1565637967.289484704]: ** Date = 20190812
[ INFO] [1565637967.289844771]:   Save path set via parameter to: /home/alex
[ INFO] [1565637967.289859725]:   Camera IDs:
[ INFO] [1565637967.290148244]:   Camera Aliases:
[FATAL] [1565637967.363517338]: Failed to load nodelet '/acquisition_node` of type `acquisition/capture_nodelet` to manager `vision_nodelet_manager'
[vision_nodelet_manager-2] process has died [pid 12922, exit code -11, cmd /opt/ros/melodic/lib/nodelet/nodelet manager __name:=vision_nodelet_manager __log:=/home/alex/.ros/log/07f42e1e-bd37-11e9-b8e2-7085c2ae64f9/vision_nodelet_manager-2.log].
log file: /home/alex/.ros/log/07f42e1e-bd37-11e9-b8e2-7085c2ae64f9/vision_nodelet_manager-2*.log
[acquisition_node-3] process has died [pid 12926, exit code 255, cmd /opt/ros/melodic/lib/nodelet/nodelet load acquisition/capture_nodelet vision_nodelet_manager __name:=acquisition_node __log:=/home/alex/.ros/log/07f42e1e-bd37-11e9-b8e2-7085c2ae64f9/acquisition_node-3.log].
log file: /home/alex/.ros/log/07f42e1e-bd37-11e9-b8e2-7085c2ae64f9/acquisition_node-3*.log
^C[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

Any ideas what could be causing this? I know others have successfully used GigE Blackfly cameras with this driver just fine.

Updated sdk, rebuilt, and problem fixed

I already update the SDK to the latest spinnaker-<IP_ADDRESS>-amd64
But I still meet the same problem.
OS: Ubuntu20.04

I already update the SDK to the latest spinnaker-<IP_ADDRESS>-amd64 But I still meet the same problem.
OS: Ubuntu20.04

I met the same problem .  My SDK is spinnaker-<IP_ADDRESS>-amd64  ubuntu 18.04


feat: Add kfn as function editor CLI

Add a mini CLI kfn to help users write KRM functions.

kfn init initialize a KRM function project. It contains some basic scaffolding, including an instance that implements the fnRunner, golden test framework and some test data, go mod on Go1.19.
kfn build build the function to a Docker image, using a embedded Dockerfile.

kfn build will expose the embedded Dockerfile for editing.
kfn build allows users to specify their own Dockerfile.

The current kfn init uses kpt to pull a package to get started, another option is to use go generate to create FnConfig and its methods (like kubebuilder does).
In current stage, I prefer using the kpt packages. because it makes the scaffolding and kfn CLI  independent. So we can easily make changes to the scaffolding package and ship it to users without requesting users to update their kfn CLI.
Eventually, I plan to use the go generate FnConfig, so as users can more rely on the CLI rather than making inline changes and it's more straightforward for users to understand the FnConfig as "the KRM fnConfig itself is a KRM resource".

Some thoughts/nits but LGTM!


Error 401 on Tesla car

Hi,
I'm able to acces Teslamate via google chrome and get prompted to use password.
But in my car I get acces dinied. Did a hard reset of the car - tried shifting Tesla password as well. Any idea what I'm doing wrong?
Also data are missing in Grafana as if it doesn't pull all data like energy consumption.

The Tesla browser does not support basic auth. You need a more advanced authentication mechanism if you want to use Teslamate in the car.

Any suggestions on how to fix it?

You either need to remove the "basic auth" middleware from your TeslaMate setup (warning: not recommended, since it leaves your TeslaMate instance open to anyone knowing the URL), or you need to use an external auth provider with ForwardAuth middleware for Traefik. The latter is a bit complicated, depending on which provider you choose to use and how much experience with Traefik you have.
Do you really need access to TeslaMate from the car's browser? There is not much info you can see there that the car itself doesn't already show. And to check if it's working or not, I find it easier to pull it up on my phone, where BasicAuth works just fine.

I've never tried it, but I wonder if the in car browser would support it if passed via the URL? aka<EMAIL_ADDRESS>

Just tested it in my Model 3, it works! Thanks for the idea @Dulanic.
The only issue is that you can see the password in plaintext in the URL bar and in the bookmark list if you bookmark it, but I guess it's a compromise.


add support for infecting via p2p

Tested On:

p2p

i'm a bit confused what you mean by this.  you mean with something like https://github.com/nobonobo/ssh-p2p ?

I had too much wine when I made this issue, please disregard ^_^


#281 causes warning when bundling with Vite

In version 2.4.1 with PR #281 I get the following warning when running my Vite build.
Module level directives cause errors when bundled, "use client" in "node_modules/react-hot-toast/dist/index.mjs" was ignored.

I'm also facing the same issue, and the version of Vite I'm using is 4.2.1.

Same here! I'm using Vite v4.1.4

Same here using rollup 4.24.0


Cocoadocs aren't generated properly

If you go to Alamofire's Cocoadocs page, you'll see there's an error parsing the pod. I ran into the same problem with my project, ForecastIO. The issue is that there are two .xcodeproj files at the root of the repo ("Alamofire.xcodeproj" and "iOS Example.xcodeporoj"). In order for Cocoadocs to properly generate docs for Alamofire, "iOS Example.xcodeproj" needs to be moved out of the root.

Thanks for letting us know. We'll get this fixed ASAP.

It looks like Cocoadocs now supports .jazzy.yaml config files. Instead of moving the example project out of the root, you can add a jazzy config file that specifies which project should be used.

FWIW, CocoaDocs works for Alamofire version 3.1.3: http://cocoadocs.org/docsets/Alamofire/3.1.3/

@jshier has already created one approach in #1027. I'm going to close this issue out for now. Please direct all future comments to #1027. 👍🏼


GetGridFunction in RAWall Object critically limited

🔍 Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

🐞 Description of the bug
Postprocessing like this works fine (like in the examples):
particles = Study.GetParticles()
velocity_gf = particles.GetGridFunction("Velocity : Translational : Absolute")
BUT with:
geometry_workpiece = Study.GetGeometry(geometry_name)
GF = np.array(geometry_workpiece.GetGridFunction(GF_name).GetArray())
Sadly only those Grid Functions are available:
Available: Coordinate : Nodal : Z
Area : Cell
Coordinate : Nodal : X
Area : Nodal
Coordinate : Nodal : Y
So no time depended values available, which are necessary for post processing like "Duration : Mean", "Stress : Normal" and many, many more.
If I try:
wall = Study.GetWallFromFilename(geometry_name)
wall = wall[0] # since we get a list
wall_duration = wall.GetGridFunction("Duration : Mean")
to get the object with another way same issue occurs. HasResults and RefreshResult was also used for double check.
📝 Steps to reproduce

Run any simulation with a wall that should gathet results
Try accessing GetGridFuction not on particles but walls like e.g. "Duration : Mean"

💻 Which operating system are you using?
Linux
📀 Which ANSYS version are you using?
Ansys Rocky 22R2
🐍 Which Python version are you using?
3.12
📦 Installed packages
#ansys-rocky-core==0.2.0
matplotlib==3.6.3
mpmath==0.0.0
msgpack==1.0.3
numpy==1.26.4
pandas==2.1.4+dfsg
pymeshlab==2023.12.post1
Pyro5==5.15
redis==5.1.1
trimesh==4.4.9
zstd==<IP_ADDRESS>

Dear @florianreinle,
Try following the code snippet below:
import ansys.rocky.core as pyrocky
rocky = pyrocky.launch_rocky()
project = rocky.api.OpenProject("Path/to/rocky_project.rocky")
geometry = project.GetStudy().GetGeometryCollection().GetGeometry("wall_name")
gf_names = geometry.GetGridFunctionNames()

I tested it here with PyRocky 0.2.0 (the latest release) and Rocky 24.2. PyRocky is able to access both static and transient grid functions on walls.
To access any array at any given output, say the 20th:
gf = geometry.GetGridFunction("grid_function_name").GetArray(time_step=20)

The code structure should follow the same as in https://developer.ansys.com/docs/prepost-scripting-2024-r2/RAStudy.md

Dear @viniciusdaroz
Thank you so much! Now it works. In my case GetGeometryCollection() was not necessary. There was a mistake in the module setup so no result data available even if simulation was run. (I'm working a lot with automated simulations ATM). There was a chain of old mistakes/assumptions and communication errors with project partners involved. Your advice helped making me look for the right things:-) And what matters, it works now!
Thanks for the help and Greetings
Florian


Support multichannel audio

There are several ways of representing multichannel audio:
Channels last
shape like [batch_size, num_samples, num_channels]

Common when loading/saving audio from/to wav

Samples last
shape like [batch_size, num_channels, samples]

Convenient for convolution. E.g. for STFT, the time dimension is commonly the last dimension (in torchaudio, torch-stft and asteroid's STFT), according to @mpariente
"I always prefer channel first because in case one wants to apply an operation to each channel independently can do straight reshaping. Otherwise you have to transpose then reshape." - @popcornell
Librosa uses this convention

I would choose samples last based on this information

How should we represent multichannel audio in spectrograms though? I would suggest channels last, since that is very common in computer vision, and is compatible with the way conv2d is implemented in pytorch and tensorflow

For waveforms, I'd prefer (batch, channels, samples)
I would also suggest channel first for the multichannel spectrograms:
audio : (batch, channels, samples) -> spec-like : (batch, channel, freqs, time)

This would at least be consistent with Asteroid's filterbank API and the vision of TF transforms as 1D convolutions.
CMIIW but Conv2d is channel first by default in pytorch.

Thank you for your insights :) I haven't actually done much computer vision in pytorch, so I was probably wrong in my previous comment. Btw, Keras supports both channels_first and channels_last when running/training computer vision models. It's a config parameter one can set.

According to this docs page, this will also be the case for PyTorch. So it's a choice that we have to make.

One advantage of channels last is that it's easy to write a 2-channel spectrogram to PNG, since it's already in a compatible format 😄
Example:

If we don't want to make this decision, I guess an "easy" way out would be to support both (have it as a parameter), and permute axes when needed.

Channels first pros:

This is typically what you get out of conv1d-based STFT implementations in pytorch
GPU (cuDNN) without Nvidia tensor cores support (e.g. Nvidia Pascal and earlier): channels first is faster

Channels last pros:

CPU with AVX/SSE: channels last is faster
GPU (cuDNN) with Nvidia tensor cores support (e.g. new GPU generations like Nvidia Turing, Volta and Ampere): channels last is faster
Same shape as typical image formats (e.g. in Pillow)

Some sources regarding performance:

https://stackoverflow.com/questions/44774234/why-tensorflow-uses-channel-last-ordering-instead-of-row-major
https://stackoverflow.com/questions/44280335/how-much-faster-is-nchw-compared-to-nhwc-in-tensorflow-cudnn
https://pytorch.org/tutorials/intermediate/memory_format_tutorial.html

Is there anything else that is worth mentioning here?

Channel first pros: only need to reshape to batch dimension for applying an augmentation to each channel independently.
Channel last you have to permute then reshape.

Another pro of channels first: It's consistent with waveforms having channels first
So I'm going to go ahead and call the shot (at least in the short term): Support channels first in spectrogram transforms.
Since multichannel audio is already a first-class citizen in torch-audiomentations, I'll close this issue now


completion does not work due to hover.lua error

init.vim
all plug#begin('~/.vim/plugged')
    Plug 'neovim/nvim-lsp'
    Plug 'nvim-lua/completion-nvim'
call plug#end()
lua require'lspconfig'.sumneko_lua.setup{on_attach=require'completion'.on_attach}
au Filetype lua setl omnifunc=v:lua.vim.lsp.omnifunc
" Use <Tab> and <S-Tab> to navigate through popup menu
inoremap <expr> <Tab>   pumvisible() ? "\<C-n>" : "\<Tab>"
inoremap <expr> <S-Tab> pumvisible() ? "\<C-p>" : "\<S-Tab>"

" Set completeopt to have a better completion experience
set completeopt=menuone,noinsert,noselect

nvim --version
NVIM v0.5.0-828-g0a95549d6
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-5 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/travis/build/neovim/bot-ci/build/neovim/build/config -I/home/travis/build/neovim/bot-ci/build/neovim/src -I/home/travis/build/neovim/bot-ci/build/neovim/.deps/usr/include -I/usr/include -I/home/travis/build/neovim/bot-ci/build/neovim/build/src/nvim/auto -I/home/travis/build/neovim/bot-ci/build/neovim/build/include
Compiled by travis@travis-job-abaca5c2-51e7-4cf1-bc06-8cf3e644ab24

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/share/nvim"

Run :checkhealth for more info

How to reproduce
run neovim with the given configuration
Description
At start nvim throws an error and completion does not work.
Error detected while processing /home/gohm/.config/nvim/init.vim:
line    5:
E5108: Error executing lua ...hm/.vim/plugged/completion-nvim/lua/completion/hover.lua:250: attempt to index field 'handlers' (a nil value)

So I guess the root cause of an issue:
M.default_handler = vim.lsp.handlers[handler]

Remove of this line allows to avoid an error during launch but still, completion does not work.

Hi,
See #274,  the problem is because the nvim nightly with the matching API hasn't been released yet. Temporary workaround is possible.

I am on the latest Neovim master commit 7caa622afcbbc1f789c24a3f29525759486208da and I still have this issue

Same issue here :eyes:

Same here.

As @sl8vz  pointed out we need a newer version of neovim. I did install neovim-git via AUR on arch and it resolved the issue.

The manual bash script way to install the latest and greatest of Neovim.
I know they have a CMakeFile but it didn't work for me so I just did it manually this way, hope that helps.
git clone https://github.com/neovim/neovim.git
cd neovim
mkdir .deps
cd .dep
cmake ../third-party
make
cd ..
mkdir build
cd build
cmake ..
make
sudo make install
cd ../../
rm -rf neovim


fixed tests dkg/pedersen

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+5.3%) to 63.985%

Totals

Change from base Build<PHONE_NUMBER>:
5.3%

Covered Lines:
3189

Relevant Lines:
4984

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+5.3%) to 63.985%

Totals

Change from base Build<PHONE_NUMBER>:
5.3%

Covered Lines:
3189

Relevant Lines:
4984

💛  - Coveralls


fix LDAP attributes and complex_identifier errors in spec files

https://github.com/antleaf/nims-mdr-development/issues/288

@nabeta over to you to review Rob's changes and merge. I've run this and seen fits is no longer an issue


App delete not working. Deployments page not working.

Delete the app functionality not working at all.
I created the app using Github repo. Another dev pushed his changes to main - no deployment. When I push my changes to main brunch - it starts deploy.
Today the deployment tab shows only infinity loader.

what is the repo you were working with? i can take a look


Silent bug in pretrained feature usage

I am using AMPL 1.6.0

I created a dataset and featurized it for later use (rdkit_raw)
I realized I curated the dataset incorrectly and re-created it, saving it with the same name
I forgot to update the featurized file in the scaled descriptor folder
The featurized dataset is matched by file name; it did not contain an equal number of rows as the real dataset
a. it contained more compounds than the dataset
b. It might have contained the real compounds plus additional rows, or
c. It might have not contained all the real compounds - only some of them, missing some and having others instead
The model training (basic NN) process basically failed. Train r2 was -0.000 for every epoch. But, no error and the training completed successfully.

We should

include a check if the real data is contained in the featurized data but allow extra compounds to exist in the featurized file
throw an error if there are unfeaturized compounds in a merged dataset file or throw a warning and re-featurize during the model process
think about replacing the file-name match with something more robust

I create a branch prefeat_smiles_check and checked in an exception.
I put the exception in model_datasets.py inside load_featurized_data but load_featurized_data is called by get_featurized_data which "Does whatever is necessary to prepare a featurized dataset."
So basically our previous philosophy was to fix an error like this or acommodate the user's mistake by creating the featurized dataset, but that would involve overwriting a user's featurized dset file. @stewarthe6 @mcloughlin2 thoughts?