Fix: Ensure verbose Parameter is Passed Correctly When vad=True to Suppress Forced tqdm Progress Bar

When vad=True, the verbose parameter is not passed correctly, causing the tqdm Progress Bar to be forcibly displayed even when verbose=None.
By implementing this fix, the verbose parameter will be correctly passed through, providing the expected control over the display of progress bars when using the vad option.
How to reproduce
import stable_whisper

model = stable_whisper.load_faster_whisper('base')
model.transcribe_stable('test.wav', vad=True, verbose=None)

Before Fix
The following unwanted progress bar displays occur:
VAD: 100%|█████████████████████████████████| 4.76/4.76 [00:00<00:00, 12.68sec/s]
Adjustment: 100%|███████████████████████| 4.38/4.38 [00:00<00:00, 13197.59sec/s]

After Fix
The progress bar will no longer be forcibly displayed when verbose=None.

@jianfch
Thank you for merging the PR and for your suggested changes. I noticed that in #80201f1 modification, using verbose=verbose is not None causes verbose to be True even when it was passed as False, which can lead to unintended behavior. To preserve the original intent of the verbose parameter, it would be better to use verbose=verbose as it directly passes the original value.
Could you please consider this adjustment?

@charly24
To clarify, this is the intended behavior for verbose in all transcribe functions:
If True, display all info or display progress bars if there are no info.
If False, only display progress bars.
If None, do not display anything.
https://github.com/jianfch/stable-ts/blob/48d70a89fd8715ab83da19a86fc4a4ade8b16be5/stable_whisper/whisper_word_level/original_whisper.py#L91-L93
For adjust_by_silence(), verbose has no distinction between None and False because there are no other info to display except the progress. Since adjust_by_silence() is called in the scope of a transcribe function, the adjustment progress bar (from adjust_by_silence()) has to be also enabled when verbose=False because the transcription progress bar is also enabled when verbose=False. This informs the user why the transcription is still processing even after the transcription progress bar has indicated completion. The adjustment can take a significant time depending the audio and settings which can leave users confused as to why it is stuck if there is not progress bar.

@jianfch
Thank you for the detailed explanation. I understand the intended behavior for the verbose parameter. However, I noticed that within NonSpeechPredictor#compute_vab_probs, there is a check for self.verbose is not None.  https://github.com/jianfch/stable-ts/blob/48d70a89fd8715ab83da19a86fc4a4ade8b16be5/stable_whisper/stabilization/init.py#L152
Given this, if we set verbose=verbose is not None, it will change the original verbose=None to True or False when passed to adjust_by_silence. This could lead to verbose being interpreted as True in NonSpeechPredictor, regardless of the initial setting.
Is this the intended behavior, that VAD-related progress is shown regardless of the initial verbose setting?
With the current latest code, VAD's Progress is always displayed.
VAD: 100%|█████████████████████████████████| 4.76/4.76 [00:00<00:00, 14.65sec/s]

@charly24 Thanks for pointing that out. It should be fixed after f53f2ee3d1401cdbdbb9979efe7dc35fce46c2d9. The VAD's progress bar should be disabled when verbose=None.


typo in the article

Common setup

I’ll be using 3D transforms to achieve Folding and Shaking, as such we need to introduce perspective disortion into play.

disortion should be  distortion

another problem, when run this demo, crashed on Xcode7.2,iOS9.2.

thanks, should be fixed. As for crash you'd need to give me some details on what was the exception?

It works on iPad Simulator. And I just copy the .swift and .xib file to a new project, it works.
your project demo crash is on real iOS device: iPhone 5s.
2015-12-17 15:55:17.781 SwiftExample[630:183950] *** Assertion failure in void swizzle(__unsafe_unretained Class, SEL, __strong RSSwizzleImpFactoryBlock)(), /Users/xxx/DetailsMatter/SwiftExample/Pods/RSSwizzle/RSSwizzle/RSSwizzle.m:190
2015-12-17 15:55:17.784 SwiftExample[630:183950] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Selector performInjectionWithClass: not found in instance methods of class SFDynamicCodeInjection.'
 Has nothing to do with the tutorial though, I'll probably remove dyci later on


Consider writing return types from the perspective of the user instead of the implementor

From this comment you say:

[...] one thing I've tried to strive for as much as possible is that if a function has -> T then return t: T works anywhere in the function [...]

while I do appreciate that as a decent goal, I think I would prefer if the function signature was written to match the intended signature. If we take the example from the readme, instead of the current:
#[async]
fn fetch_rust_lang(client: hyper::Client) -> io::Result<String> {
    ...
}

this would mean having
#[async]
fn fetch_rust_lang(client: hyper::Client) -> impl Future<Item=String, Error=io::Error> {
    ...
}

(the ergonomics here could probably be improved in the future via Trait aliases).
The main downside of this is, as you say, the type allowed to be passed to return is no longer actually declared anywhere (I assume it would either have to be a matching Result, or potentially any type implementing a matching Try).
The upside for me is that I'm always designing an API first from the side of the consumer, so I might first write something like (ignoring the fact this fails currently, I hope some combination of never_type and future impl Trait improvements could make this work)
fn fetch_rust_lang(client: hyper::Client) -> impl Future<Item=String, Error=io::Error> {
    unimplemented!("TODO")
}

If I can then implement it as a small iterator adapter then everything's fine, I just replace the body and it's done. If it takes a little more implementation work then maybe I want to use #[async], and suddenly I've got to change the signature
+#[async]
+fn fetch_rust_lang(client: hyper::Client) -> io::Result<String> {
+    ...
-fn fetch_rust_lang(client: hyper::Client) -> impl Future<Item=String, Error=io::Error> {
-    unimplemented!("TODO")
 }

Potentially if the signature specifies the final type then it may be possible to have a single macro that returns either a Future or Stream based on the return type

Finally, specifying the final signature also has more consistency with other languages:
C#:
async Task<int> AccessTheWebAsync()
{
    HttpClient client = new HttpClient();
    string urlContents = await client.GetStringAsync("http://msdn.microsoft.com");
    return urlContents.Length;
}

TypeScript:
async function foo(): Promise<number> {
    await delay(100);
    return 5;
}

Dart:

If the expression being returned has type T, the function should have return type Future<T> (or a supertype thereof). Otherwise, a static warning is issued.

Hack:
async function curl_A(): Awaitable<string> {
  $x = await \HH\Asio\curl_exec("http://example.com/");
  return $x;
}

Although there is one language that I think counts more towards the current side:
Scala:

On the level of types, async and await are methods with simple, intuitive types:
def async[T](body: => T): Future[T]
def await[T](future: Future[T]): T

One additional step that could be taken with this syntax is to have the body behaving something like the proposed "throwing functions". That would give a full rewrite of the README example something similar to:
#[async]
fn fetch_rust_lang(client: hyper::Client) -> Future<Item=String, Error=io::Error> {
    let response = await!(client.get("https://www.rust-lang.org"))?;
    if !response.status().is_success() {
        throw io::Error::new(io::ErrorKind::Other, "request failed");
    }
    let body = await!(response.body().concat())?;
    String::from_utf8(body)?
}

using throw for returning an error and returning the unwrapped String directly at the end.

Things I like about this approach:-

This should fix https://github.com/alexcrichton/futures-await/issues/11 just as async_block works fine right now. I think this is HUGE.
I see you are using the ? operator in your body. Unless we do some serious macro voodoo in the async macro (which I doubt @alexcrichton would approve :smile:), unless I'm missing another way of achieving this, we would have to implement std::ops::Try for futures and streams, which means https://github.com/alexcrichton/futures-await/issues/3#issuecomment-322419631 will become a thing as well.

Things I don't like:-

I'm not a big fan of that "throwing functions" proposal. I like the way errors are currently handled in Rust. The only improvement I hope to see is [derive(Error)] in the std library.
Directly returning a type (String in this case) that is not actually an implementation of a Future like what the return type says will probably take getting used to and that will probably confuse new users quite a bit. I know we are simply returning Future::Item here but that's not how we write and read other Rust code.

Having said that, if we could fix those issues I highlighted in the things I like using Result as a return type then I will prefer the current approach. While it does have a slight drawback of having Result as a return type where as the final function would actually be a Future or a Stream, it's easy to map these return types mentally. For me the huge benefit is that it optimizes for writing code.

I've just pushed a branch implementing the first part of this, including supporting returning both impl Future and impl Stream using a single macro:  https://github.com/Nemo157/futures-await/tree/alternate-signatures
It does lose support for returning Boxed variants (might be possible to support, but I'm not very good with whatever sort of trait based trickery might be used to detect whether or not the return type is Box). It also almost certainly has terrible error messages if it fails to compile.

@rushmorem my second post there is really a potential extension that I'm not all that confident of either. I don't think it would actually be implementable via macro today (do catch + rewriting all returns might get 99% of the way there, but as far as I know you can't expand macros in the body yet so you'd miss any returns hidden behind them). I didn't really spend much time thinking about it, just realised since there was going to be some sort of breakage between the signature and body that it's the sort of space that the "throwing functions" proposal could slide into.
My current implementation would basically end up looking like what you wrote without the use, it's still going via Result internally instead of using future adapters.

I've just pushed a branch implementing the first part of this for comparison purposes; including supporting returning both impl Future and impl Stream using a single macro: https://github.com/Nemo157/futures-await/tree/alternate-signatures

Awesome! I will try to play with that tomorrow.

It does lose support for returning Boxed variants (might be possible to support, but I'm not very good with whatever sort of trait based trickery might be used to detect whether or not the return type is Box).

Instead of trying to detect it, you could keep the boxed argument and use that instead.

It also almost certainly has terrible error messages if it fails to compile.

You are probably right. Personally, I try to avoid Boxing as much as possible (because of the allocation) but it does have valid use cases so I think it will be good to keep.

My current implementation would basically end up looking like what you wrote without the use, it's still going via Result internally instead of using future adapters.

In my example I was using the futures adapters to show that you could still write code that returns Futures using the current style. However, I was hoping that the code would actually be able to return any implementation of a Future when returning impl Future<...> and any implementation of a Stream when returning impl Stream<...>. So code like
#[async]
fn fetch_rust_lang(client: hyper::Client) -> impl Future<Item=String, Error=io::Error> {
    // While this example is so trivial that you don't really need to use the `async`
    // macro, we are only interested in what is being returned. Pretend that there
    // is lots of other code above this line that `async` helps you write more easily.
    client.get("https://www.rust-lang.org")
}

would still be valid. If we manage to achieve this, then we would be able satisfy @alexcrichton's goal of being able to return anything that's in the declared return type at any point in the body. Even more importantly, I think, returning Futures and Streams directly would remove any need to await at the end of the function (so we can get a Result). This is a performance win when you want to use the output of that function inside other async code.
Here, is an example. Correct me if I'm wrong, but you can't implement the example above currently. You will be forced to write the following instead
#[async]
fn fetch_rust_lang(client: hyper::Client) -> io::Result<String> {
    // We are forced to await here even though we don't have to.
    // This will block the coroutine in any `async` code that use this
    // function, even though we don't actually await the invocation
    // of this function.
    await!(client.get("https://www.rust-lang.org"))
}

As you can probably tell from my other RFC above, I really like the direction you are headed with this. One thing that's been bugging me even from your other experiment in https://github.com/alexcrichton/futures-await/issues/7 is using a macro to yield elements. Having read your code, I totally understand why you are doing this. However
yield item;

is easier to read than
stream_yield!(item);

If we can't easily implement this in a way that would get rid of the macro, we can resort to rewriting yield item; to yield Async::Ready(item); in the async macro itself. You don't have to implement this yourself if you don't have enough time to do so. You can simply add a TODO linking to this comment as a comment on the stream_yield! macro as this can be done in a separate pull request.

Thanks for the issue here @Nemo157! I actually thought what's currently implemented was how most other languages do it as it seemed the most intuitive to me, so I'm surprised to hear the opposite!
I'm still somewhat wary myself though of writing down a return of a future vs a return of a Result. I'm afraid that returning a future will encourage you to write down what future you're returning as opposed to impl Future, and rationalizing that could get... interesting. Also the loss of boxed futures is sort of sad as they're required for traits and object safety today!
@rushmorem I'm not sure I understand what you say though about how this would fix https://github.com/alexcrichton/futures-await/issues/11? Is there something we can't do today to do that?

I'm not sure I understand what you say though about how this would fix #11? Is there something we can't do today to do that?

I didn't mean to imply that it can't be fixed otherwise. It's just that I thought that issue will automatically be fixed if we use the return type like this directly since a return type like impl Future<Item=T, Error=E> + 'a would be used directly as is without trying to detect the lifetime parameters separately.

I'm still somewhat wary myself though of writing down a return of a future vs a return of a Result. I'm afraid that returning a future will encourage you to write down what future you're returning as opposed to impl Future, and rationalizing that could get... interesting.

@alexcrichton What do you think about being forced to await!() at the end of the function if you have a future rather than a result at the end of your function as explained in https://github.com/alexcrichton/futures-await/issues/15#issuecomment-327037927?

@rushmorem

would be used directly as is without trying to detect the lifetime parameters separately

Ah ok, makes sense!

@alexcrichton What do you think about being forced to await!() at the end of the function if you have a future rather than a result at the end of your function as explained in #15 (comment)?

I agree it's unfortunate!
Despite this, though, I feel like working with futures has proven to be "difficult enough" that I'd want to make the concepts here as streamlined as possible. In the sense that if we've got little gotchas like you can return Ok(..) here but you can also return t: impl Future here it may add to the confusion early on and only end up helping power users?
I'm not entirely sure how to balance this :(

I've re-added boxed futures/streams by assuming any non-impl Trait return type must be a Box. It seems like there must be a better way to detect it but I wasn't able to come up with one.

@alexcrichton

Despite this, though, I feel like working with futures has proven to be "difficult enough" that I'd want to make the concepts here as streamlined as possible. In the sense that if we've got little gotchas like you can return Ok(..) here but you can also return t: impl Future here it may add to the confusion early on and only end up helping power users?
I'm not entirely sure how to balance this :(

I totally understand your position and I actually feel the same way. As you can see from my comments in https://github.com/alexcrichton/futures-await/issues/15#issuecomment-326772627 and https://github.com/alexcrichton/futures-await/issues/15#issuecomment-327037927 I have been arguing for returning only return t: impl Future from the word go. I'm actually strongly against also returning Result because if we don't return it then code like
#[async]
fn fetch_rust_lang(client: hyper::Client) -> impl Future<...> {
    // We are forced to await here even though we don't have to.
    // This will block the coroutine in any `async` code that use this
    // function, even though we don't actually await the invocation
    // of this function.
    await!(client.get("https://www.rust-lang.org"))
}

won't even compile because Result doesn't impl Future. This is one of the biggest reasons why I'm so excited about going in this direction.
Having said that, I would also like to reiterate that this approach is more flexible as it allows us to also write code that uses the result style as well using FutureResult rather than std::result::Result. You will notice that whenever I talk about returning Ok(...) or Err(...) when mentioning this approach I also make sure to point out that Ok and Err are actually futures combinators automatically imported by the async macro through use futures::future::{ok as Ok, err as Err};. You can see this in https://github.com/alexcrichton/futures-await/issues/15#issuecomment-326772627 and https://github.com/alexcrichton/futures-await/issues/20#issue-255144150. The example I have been using is
// Just putting this here so you can see where the Ok and Err in the body are coming
// from but this will be imported by the `async` macro so these won't interfere with
// your other code
use futures::future::{ok as Ok, err as Err};

#[async]
fn fetch_rust_lang(client: hyper::Client) -> impl Future<Item=String, Error=io::Error> {
    let response = await!(client.get("https://www.rust-lang.org"))?;
    if !response.status().is_success() {
        return Err(io::Error::new(io::ErrorKind::Other, "request failed"))
    }
    let body = await!(response.body().concat())?;
    let string = String::from_utf8(body)?;
    Ok(string)
}

As you can see from the code above, only  return t: impl Future is used because FutureResult is a Future. We can actually return any Future, not just FutureResult.

@rushmorem I'm a bit confused about your example
#[async]
fn fetch_rust_lang(client: hyper::Client) -> impl Future<...> {
    // We are forced to await here even though we don't have to.
    // This will block the coroutine in any `async` code that use this
    // function, even though we don't actually await the invocation
    // of this function.
    await!(client.get("https://www.rust-lang.org"))
}

This doesn't involve blocking any more than any other future does, and modulo optimizer inlining of the Future shim + Generator this is identical to:
fn fetch_rust_lang(client: hyper::Client) -> impl Future<...> {
    client.get("https://www.rust-lang.org")
}

A caller can delay starting and run these both in parallel in the exact same way:
#[async]
fn fetch_rust_lang_twice(client: hyper::Client) -> impl Future<...> {
    await!(join_all([
        fetch_rust_lang(client.clone()),
        fetch_rust_lang(client)
    ]))
}

I was hoping that the code would actually be able to return any implementation of a Stream when returning impl Stream<...>

This wouldn't really work since an #[async] -> impl Stream function never returns a value, it only yields items and returns to signal stream completion.

we can resort to rewriting yield item; to yield Async::Ready(item); in the async macro itself.

That would work, and I'm tempted to do it. But it has the same issue I mentioned about rewriting return above: it will miss any yields in macros. That's actually important so that it doesn't rewrite the yield Async::NotReady; in the await! macro, but could introduce issues if any user wants to have a yield inside another macro for any reason.

There are a couple of issues with just returning any Future from an #[async] -> impl Future function:

Unifying different Future implementations

Your example would work because your two returns are both returning FutureResult values. I feel like the #[async] syntax would exacerbate the already existing issue of trying to return multiple different Future implementations with the same Item and Error types. I would especially expect to see FutureResult used for error values a lot even when a different Future is used for the success value.

Allowing usage of ? in the body

Again, your example could likely be made to work since #[async] can make the ? -> Result -> FutureResult flow work. If the user was returning any other kind of Future it would again hit an issue with trying to return multiple Future implementations (a more solvable one since we knows there's at most 2 types and can just wrap them in an Either, but that would require rewriting return nodes to wrap the user's return values...).

There have been proposals around "anonymous enums" that I feel could provide a relatively nice way to work around both those issues, but they're not even in RFC yet (/have been postponed) and would probably require variadic generic support as well, so...
Luckily there is a super easy way to just avoid the whole issue and come up with a single concrete Result type to return from any Future you have: await!.

@Nemo157 I see. Thanks for explaining this. If we are going to end up returning Result anyway then I prefer having Result as the return type.

Another thought I just had, this should also allow easy integration of nominal types once the new impl Trait type aliases are available. Something like
type RustLang = impl Future<Item=String, Error=io::Error>;
#[async]
fn fetch_rust_lang(client: hyper::Client) -> RustLang {
    ...
}

compared to requiring use of async_block! with the current implementation:
type RustLang = impl Future<Item=String, Error=io::Error>;
fn fetch_rust_lang(client: hyper::Client) -> RustLang {
    async_block! {
        ...
    }
}

(whether this is very useful or not, I'm undecided yet)

Because of how impl Trait and trait objects handle lifetimes, this interacts very poorly with lifetime elisions. Specifically, the return type only captures explicitly called out lifetimes, but the returned generator necessarily captures all lifetimes.
So say you have a method like this:
#[async]
fn foo(&self, arg: &str) -> Result<i32, io::Error>

You'd have to write it like this:
#[async]
fn foo<'a, 'b>(&'a self, arg: &'b str) -> impl Future<Item = i32, Error = io::Error> + 'a + 'b

The alternative would be to make lifetime elisions not work the same way the work with regular impl Trait return types, but that seems clearly out to me, since the whole idea of this change is to make the return type accurately reflect with the function returns.

I think this is an extremely exciting development for Rust, but I would like to add that I find it (from my perspective as a heavy async user but Rust newbie) very distracting to have the async macro change the return type of the method.
I appreciate that the goal of async await is to make async code more ergonomic. While requiring a long form impl trait return type may be at odds with this goal in some respects I believe long term it will benefit users to have the actual return type visible in the code.
My reasoning is as follows:

The person who writes the #[async] method is the most likely to be familiar with how async works. Details such as whether or not it alters return types or not. The person consuming the method is more likely to be unaware of how #[async] works. For them, if the method signature is accurate from their point of view, they can use the method successfully without understanding generators, state machines or #[async]
It's less magic and follows the principle of least surprise
If the return type is long and unergonomic, and returning the impl Future is not chosen because of this reason, then Rust as a whole won't feel the appropriate pressure to make language choices such as trait aliases that might alleviate these issues.

The methods will already be sprinkled with await!()
There would be a certain symmetry to some kind of final macro that turns a concrete result into the correct future return type:
finally!(result)

@withoutboats I actually like that part of this proposal because it makes #[async] behave more like other Rust code, if I were to see
#[async]
fn foo(&self, arg: &str) -> Result<i32, io::Error>

I would assume that foo only uses the references while it's running, and doesn't keep them bound after returning.
I would also hope that combined with some way to refer to the "elided lifetime" (e.g. eddyb's old Anonymous/placeholder lifetime RFC) the signature would not look anywhere near as bad as you show:
#[async]
fn foo(&self, arg: &str) -> impl Future<Item = i32, Error = io::Error> + '_

@Nemo157 your code example is equivalent to this:
#[async]
fn foo<'a, 'b>(&'a self, arg: &'b str) -> impl Future<..> + 'a

Note that the future is not bound 'b. This is because return type elision only considers the self argument.

I would assume that foo only uses the references while it's running, and doesn't keep them bound after returning.

It does use them while its running - while the future is running. This will be the natural way to think about things when the natural thing to do is to await the future.

Yep, I was misrembering how lifetime elision works. Still, I think that improving how impl Trait handles lifetimes would be a better path than hiding the lifetimes away in the macro/compiler expansion for this one specific case.

It does use them while its running - while the future is running. This will be the natural way to think about things when the natural thing to do is to await the future.

I definitely have places where retaining a distinction between the future's preparation phase and executing phase is useful to avoid borrowing data too long. I have been meaning to start a thread on irlo about "hot generators" to somehow allow this with the #[async] macro (currently it's possible with the async_block! macro, but that has some downsides). I have a feeling that attempting something like that would not interact well with self-borrowing generators though.

It does use them while its running - while the future is running. This will be the natural way to think about things when the natural thing to do is to await the future.

I definitely have places where retaining a distinction between the future's preparation phase and executing phase is useful to avoid borrowing data too long.

Specifically, there is an example in https://github.com/alexcrichton/futures-await/issues/11#issuecomment-326399783 that I've talked about with @withoutboats in #rust before.

Referring back to my old comment about nominal impl Future types, I just accidently attempted to use this today, so it's definitely something that would be useful (once abstract/existential types and generic associated types are both implemented):
pub trait CountDown {
    type Future<'a>: Future<Item = (), Error = !> + 'a;

    fn start(&mut self, count: Duration) -> Self::Future;
}

impl CountDown for Timer {
    abstract type Future<'a> = impl Future<Item = (), Error = !> + 'a;

    #[async]
    fn start(&mut self, count: Duration) -> Self::Future {
        ...
    }
}


Figure out how to export jpgs of editors

Or embed ace editor in other sites if jpg export is unfeasible


Starter pack description error is generic and late

Steps to Reproduce

Try to create a starter pack with a description longer than 300 graphemes
Receive "Invalid app.bsky-graph. list record: Record/description must not be longer than 300 graphemes" error

Attachments

What platform(s) does this occur on?
iOS, Android, Web (Desktop), Web (Mobile)
Device Info
Macbook
What version of the app are you using?
Build version: 1.92.1; Bundle info: dfbfcdd (prod); Bundle date: 24110420; Platform: web
Additional Information
Would be nice if that description text area would just have validation. I could work on a PR if that's desired?

I noticed the same issue yesterday, and it seems displaying a validation error message early on in the description page would provide a better user experience. I had no idea why the starter pack update was failing until I checked the developer logs.


Rendering script fails on Mac

Hi,
Thanks for your great work and for sharing all the code to generate the data.
I am trying to get the rotation matrix  from the metadata. I've been struggling a bit with this so I tried reusing the rendering script you provide i.e generate.py to  render a shapenet object with simple parameters. The script gives several errors on Mac, hence my question :

did you render shapenet on Linux or Mac?

These errors are for instance :
  File "utils/render_utils.py", line 66, in make_area_lamp
    nodes = lamp.node_tree.nodes
AttributeError: 'NoneType' object has no attribute 'nodes'

This can be solved by setting :
 lamp.use_nodes = True but there are other errors after this.
If you have any pointers to go from the metadata files to the rotation matrix, that would be great. I tried inversing the sequence of Euler-angle transformations in generate.py but the resulting matrix is not consistent with the renderings so far.
Cheers,
Thibault

Hi Thibault,
Thank you for your kind words and interest in our work! I have a few questions:

Are you trying to use our scripts with Blender 2.79b specifically? If so, then the scripts should work identically on Mac and on Linux. (more detail: the rendering itself was done on Linux, but we've done some developing/debugging on Mac and had the code work in both cases)
When you say rotation matrix, do you mean the the appropriate R, t (and K for projection) that would allow you, for example, to take a surface point cloud from the 3D model being rendered, transform and project it into the image? If this is the case, we have some code internally that builds on this release which allows for that functionality (dumps the camera intrinsic/extrinsic matrices in addition to the images/depths/normals for each frame). Do you think that would be useful for you?

Best,
Stefan

Hi @sstojanov,
Thanks for your fast reply.

Yes i was trying to use your script on Mac with a freshly installed Blender 2.79b from the link you provide. I am not sure why it fails then, but this was mostly done as a way to debug point 2.
Yes exactly,  i am trying to write code that takes as input hard_vc_metadata.txt and metadata.txt and outputs the correct rotation matrix applied to the base shapenet model in a right-handed coordinate system (z forward, Y up, x left). I think your code could be very useful.

Thanks again!

Unfortunately I'm not sure why there are issues with the MacOS. For me it worked with 10.14.06 Mojave and previous versions. What version of MacOS are you using?
Regarding extracting the camera information, following is more detail. We are working on integrating this into the release, but the current answer is in terms of github gists.
Here are links to gists for an updated generate.py (link) and functions that need to be added to render_utils.py (link) for the camera rotation and calibration matrices to be output.
You can test these functions by doing the following:

Take an .obj from ShapeNet
Extract a point cloud using trimesh and save it as  pointcloud3.npz
Convert that point cloud into the same orientation as the mesh in Blender using the following code.
Project the point cloud points using the following code

Following are some files that can help unit test/determine whether things are working properly

The following contains an example output rendering with the camera information output as cam.npz
02691156.zip
Point cloud in original pointcloud3.npz and pointcloud3_R.npz Blender rendering orientation (this is before and after step 3 in the steps above)  pointclouds.zip

If everything works correctly, the projected point cloud should correspond to the object in the image like in the example below. The image on the right was obtained following the testing steps 1 through 4 above.

Please let me know if you have further questions!
Best,
Stefan

Hi Stefan,
Loads of thanks for the detailed answer. I will go over the script and close the issue as soon as I reach the objective if that’s ok.
Best
Thibault

Hi Thibault, have you been able to make any progress on this?
Best,
Stefan

Hi Stefan,
I've been working with Thibault on this (he's on vacation) and yes, your scripts were very helpful. We were able to get what we needed.
Thank you!

Marissa


Build fails with 'A problem occurred evaluating project ':library'. > Could not find method bootJar()'

When I try to build the code in the "complete" directory, it fails with
A problem occurred evaluating project ':library'.
> Could not find method bootJar()

I get the same error on a fresh VM.  Looks like the CI build failed with the same error as well.

Looks like you can fix it by just removing the bootJar section from library/build.gradle

Hi @mryanprice
This issue come from this PR.
https://github.com/spring-guides/gs-multi-module/commit/a4606ee679d367df2d3bf5812cdd96e86750c8ad
You could change to "jar" to avoid this issue.
Regards,
Huka


Use http-only cookie for jwt token

The current implementation of JWT lets the frontend to manage the JWT token on the client-side, which can store jwt in localStorage, etc.
This could be a security issue.
To tackle this, the backend API should attach the JWT token to an HTTP-only cookie so that the frontend or any other client-side js is not able to extract the token

I would like to do this

I would like to do this

@joharikushagra sorry for the delay in replying. Would you still like to work on this issue?

hey please i want to work on this please assign me

@subhangi2731 I am assigning this issue. Please make sure you read the contributing guidelines before contributing. Write tests if required and make sure no test cases are failing.

@subhangi2731 What's the status?

@gauravdas014 you may assign this to someone else.

@gauravdas014 you may assign this to someone else.

Yes, sure!

I have worked on this @gauravdas014 will send the pr by tommorrow. Please reassign me I was out of station for a few days so I was not able to communicate

@subhangi2731 Please give the PR by tomorrow.

I have worked on this @gauravdas014 will send the pr by tommorrow. Please reassign me I was out of station for a few days so I was not able to communicate

Okay, no issue!

I have worked on this @gauravdas014 will send the pr by tommorrow. Please reassign me I was out of station for a few days so I was not able to communicate

Okay, no issue!

@subhangi2731 Please give the PR by tomorrow.

Okay sure, Thanks

@subhangi2731 Have you completed the task?

@gauravdas014 I need little more time will send the pr by tomorrow can u please give me one more day?

@subhangi2731 okay, it's fine if you send PR by tomorrow. @shashankmotruri @nanda-mik. Please help her. She is facing some issues.

I would like to work on this issue, I also have practical experience regardless this issue

@jhasuraj01 Please go ahead

@jhasuraj01 Please go ahead

Thanks, will update you soon

@gauravdas014 I have made necessary changes in backend\controllers\authController.js shall I make a PR?

@jhasuraj01  Sure!


carla Ubuntu package already exists in newer Ubuntu versions (starting 19.04)

In newer Ubuntu versions starting with 19.04 there is already a package named "carla"
https://packages.ubuntu.com/de/disco/i386/carla
This makes it impossible to easily install the Carla debian packages from the repository as described in your documentation: https://carla.readthedocs.io/en/latest/start_quickstart/
Manually downloading the carla .deb and installing it via dpkg works, if the required packages are installed before.
Maybe thing of renaming your package to sometging else like carla-simulator.
Thanks
Johannes

Hi @derFrickler,
We have updated the package name to carla-simulator to avoid the conflict. We will change the documentation accordingly. Thank you for the information!


Constants.py consolidation

Once again, don't merge this one. Needs more work but this PR gives some idea of one way of re-factoring constants out of openbazaard.py into constants.py. Purpose is as a discussion point.

Re-written this, starting new PR


Add pypi package workflow

closes gh-73:
On release, publish package to pypi. Changes:

adjusted readme to install fabricator via pypi
added workflow to publish package
minor changes to setup (long description)

The package publish process only happens if linting and building are successful right?

yep, included the linting check before deployment

yes


update getting-started-icp for new version kubeflow installing

Installed new kubeflow on ICP, seems there are some changes. Update related docs to fit new version.

This change is

Reviewed the preview, that looks good. Thanks.

/assign @sarahmaddox
Could you please help review, thanks a lot!

Anyone can help review? Thanks a lot!
/cc @joeliedtke
/cc @pdmack

/lgtm

/lgtm
/approve


Bitmap.DecodeToWidth crashes on macOS m1 without any runtime exceptions

Describe the bug
Bitmap.DecodeToWidth will crash on Apple M1 Systems without any runtime exceptions. Only with the macOS crash report.
To Reproduce
Here are the codes for me to load an image to the Bitmap:
... // async context

try
 {
    await using var fs = File.OpenRead(path);
    var image = Bitmap.DecodeToWidth(fs, 256);

    await Dispatcher.UIThread.InvokeAsync(() => { ImageSource = image; });
}
catch (Exception e)
{
    Console.WriteLine(e);
    throw;
}

...

Application will always crash after the execution of Bitmap.DecodeToWidth even without jumping to the catch section
Environment

OS: macOS Sonoma 14.0
Avalonia-Version: 11.0.5

Additional context
macOS generated crash reports: err.log

But in SkiaSharp most likely: https://github.com/mono/SkiaSharp/issues/2645

I had to implement this workarround : https://github.com/manuc66/ImgTagFanOut/commit/fb58f4bb7c331ea3881c1d0f45c3f4812e9300a1

Arg, this bug is annoying, I am not sure I can use Skia 2.88.5 if Avalonia is using the 2.88.6 version.

if anyone wants to try SkiaSharp 3 preview if it would fix the issue: https://github.com/AvaloniaUI/Avalonia/pull/13900#issuecomment-1850339413

Avalonia version 11.0.0 is working normally, but 11.0.6 crashes

@AlexeiScherbakov known but we had to upgrade SkiaSharp version for a good reason and we cannot downgrade even if we wanted to.

Had the same crash on Linux with 11.0.6 and an upgrade to 11.0.7 fixed the issue. Thanks!

@laolarou726 if issue is still reproducing in 11.0.7 ping me


want to get the current page number from pdf file

I'm displaying the PDF from a file stored in storage,
but every time while opening, i'm getting the PDF from 1st page,
I just want to store the current page number when the user presses the Android BackButton.
I'm using this function PDFView.fromFile(FileName).load();

There are a couple of ways to do this,
Simple way pass the page number and filename between activities then just .load (pagenumber) or how ever it loads pages and compare the filename otherwise any pdf you open will load on the stored page number.
Kind starts you off in the right direction....

Closing due to no response from author


Change mouse_to_joy.py permission as executable

unity_simulation_scene.launch executes `mouse_to_joy.py" script but this script don't have permission as executable.

Thank you @chikuta !


TS-4930: Unfolds request headers that are using obs continuations

I also removed a file that is basically a duplication of another file, and this duplicated file is not used at all. This confused me as I was testing and updating the regression tests. Basically, that old test app is already incorporated into the regression tests.

FreeBSD build failed! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/931/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/825/ for details.

Try build on freebsd again [approve ci].

FreeBSD build failed! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/932/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/826/ for details.

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/933/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/827/ for details.

[approve ci]


Fix portforward list

We were not filtering out the list view of portforward based on the cluster they are part of, this patch fixes that and only shows portforwards that are part of the current cluster.

I've tried it and have the exact same issue in the backend when starting a new forward.

@joaquimrocha #927 fixes the above, but we still need this PR


remove current repodata hacks

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

License exception is not an SPDX exception.

Documentation on acceptable licenses can be found here.

I guess missed a bit my other PR. Lgtm!

That was #70 in order to Xref the GitHub links.

nvm, I was using an older commit

So now that both this and #72 have been closed, what's the way forward for https://github.com/conda-forge/ctng-compilers-feedstock/pull/147?
I maintain that #72 would be the proper way to do it (and would also rectify the situation that it's hard to tell where sysroot-with-crypt builds come from, as the existing ones just got the label added manually), but if you prefer to do it on top of v2.17 then I don't care. It should just be done one way or another (I guess a third option is something like #75 but for v2.17?).
(BTW, while looking at the branches I noticed that the tzdata changes have never been forward-ported from #66 to main)

See https://github.com/conda-forge/linux-sysroot-feedstock/pull/73


setting trainer name

When I run node pogo.js I get the following error:
Failed to complete the tutorial... ERROR: { [StopError: Status code 3 received from RPC]   name: 'StopError',   message: 'Status code 3 received from RPC' }
I believe my pogobuf is running the latest version:
$ npm list pogobuf<EMAIL_ADDRESS>C:\Users\Jason\Code\IVs\ptc-acc-gen --<EMAIL_ADDRESS>When I login to the account, it looks like they have caught the starter pokemon but the trainer name is not yet set.

I suppose this is a bug in pogoplayer (aka NOT MY PROBLEM ;) ), but in reality trainer name is unneeded. I'll look into it but no promises here, especially since I can't push to the pogoplayer repo.

Trainer name is required if your scanner is doing -gi. Without trainer name set it seems that trying to scan and pull gym info will give errors.

Usage guide:
Make sure you've latest node.js and npm!
Download .zip or clone
Run this inside directory: npm install
Rename accounts.csv.example to accounts.csv
Input data in accounts.csv in one of these formats:
auth,username,password,lat,lng,trainerName (will try to assign trainer name)
auth,username,password,lat,lng (wont try to assign trainer name)
run node pogo.js
Todo:
??? - send an issue with suggestion!

The original Text from PogoPlayer, i think when you run with the changes, it will runs ;-)

When you get that error the trainer-name is already set! ptc-acc-gen runs pogo.js after creating users.

PogoPlayer issue, closing.


Make auto-formatting more convenient with pre-commit

Hi,
I had two issues with the format_python_files.py approach which let me to change this in my template.

It is annoying to execute the formatting when you already agreed that files should look this way.
isort does not really work when used inside tox as it misrepresents first, second, third party applications which caused tests to fail.

Therefore, I now use a different approach using pre-commit. The tool allows you to define several git hooks which will be execute when trying to commit. In case any of the defined hooks catches an error, the commit is aborted.
All you need is a config file and you need to install all packages under repo: local. Then, type pre-commit install and the hooks will run before each commit. The posted config runs black, black on documentation, flake8 and doc8. Furthermore, isort is replaced with reorder_python_imports which is simpler and easier to implement.
There are a lot of other hooks available under https://pre-commit.com/hooks.html as yaml checks, syntax upgrades, etc..
Best

I tested pre-commit in one installation of the template with the configuration file and it worked perfectly. Do you want it to be used in the templates by the user or just in the repo for us developers?

Cool! Please enable it for users who opt for "add_python_code_formatter_to_project" and set up git.
I suppose this scans the directories for *.py - patterns. Would it be possible to include "wscript" as well?

I put the pre-commit setup into the post-hooks. It will be installed when both "add_python_code_formatter_to_project" and "set_up_git" are opted for. (f5ce6ae709107bddf5db37f1430dfa281bc376ac)

All you need is a config file and you need to install all packages under repo: local. Then, type pre-commit install and the hooks will run before each commit. The posted config runs black, black on documentation, flake8 and doc8. Furthermore, isort is replaced with reorder_python_imports which is simpler and easier to implement.

Hi Tobias, I had to search for a long time for a small bug, that stopped flake8 and black to work properly. I think you excluded all files NOT starting with a dot by mistake, so I changed the exclude regex in the config file

Yes, I also noticed it and changed it some time ago. Now, I exclude only .mywaflib explicitly, but I will look into your approach as it could be more flexible.

I kind of like the "everything with the dot" approach better, I do not think you would ever want to have a script starting with that.

Before closing this, could you (@raholler) please make sure this works as expected and check for any other useful hooks? UTF8-BOM comes to mind, I got bitten by that one a couple of times. Suggestions welcome.

@raholler: Please add an exception for .pre-commit-config.yaml in the .gitignore file
@tobiasraabe: pre-commit runs like a charm, but ... the commit is not carried out. The only way I got it to carry out the commit (not much time to play around), was to uninstall pre-commit temporarily. I installed it as part of the miniconda environment. Did you ever see this? The first few google results were unhelpful...

I am not sure what you mean. The commit is always aborted if one check fails.  But that is probably not what you mean. I never had problems with pre-commit related to miniconda.
Also can you confirm that doc8 is always skipped because no files were passed to the exec? I thought the list of types is evaluated with OR but maybe it is AND, but no file is markdown and rst.

Ah,
In case any of the defined hooks catches an error, the commit is aborted.

I did not see that. Had a bunch of files I moved over and the output was so long that I did not dig through everything. Thought there were only warnings, though, but maybe some file had a syntax error.
Is there any way to override that setting on a per-commit basis? Or anything less invasive than uninstalling pre-commit altogether?

Maybe git commit --no-verify.

Thanks! Will try that out!

Here is a list of  [https://pre-commit.com/hooks.html]( pre-commit hooks)
I would suggest:

check-byte-order-marker - Forbid files which have a UTF-8 byte-order marker
check-added-large-files - Prevent giant files from being committed (happened to me once accidentally)
check-merge-conflict - Check for files that contain merge conflict strings.
check-json - This hook checks json files for parseable syntax.
pretty-format-json - This hook sets a standard for formatting JSON files.
trailing-whitespace - This hook trims trailing whitespace. (or is this alrady covered by flake8?)

Maybe:

check-yaml - This hook checks yaml files for parseable syntax.
check-ast - Simply check whether the files parse as valid python.
fix-encoding-pragma - Add # -- coding: utf-8 -- to the top of python files

Sounds all good, except for the two last maybes (Syntax is checked implicitly by black, utf8 is redundant for python 3).
If 6. only is about python files and does not touch docstrings, it would be redundant indeed.
For 2. we should definitely find out how to override things. Sometimes I do want to add data.
Thanks!

Regarding 2., you can exclude certain files in the .pre-commit-config.yaml from this hook. However, this may not be very convenient and too complicated for the casual user. Alternatively, it should be possible to customize the hook (see https://github.com/pre-commit/pre-commit-hooks/blob/master/pre_commit_hooks/check_added_large_files.py). However, this may need too much effort for only a small convinience hook. What do you think?

I like the possibility to exclude things. Is it possible to print something out on that if the commit fails because of it?
Btw, we should check that black likes the entire template...

black likes the entire template

What do you mean?

Is it possible to print something out on that if the commit fails because of it?

It should say that the commit fails because it failed this check. Do you mean that or do you have something else in mind?

black likes the entire template

What do you mean?

That if you go through the sequence like:

Set up a project
Set up and activate all pre-commit hooks
Commit

The last step works immediately. Usually that would be hidden by the fact that the initial commit is done before the second step and if people change a file later, the commit might fail because the template did not adhere to the highest standards :-)
That will be a bit annoying to achieve because of the cookiecutter stuff in the raw version, but should be doable.

Is it possible to print something out on that if the commit fails because of it?

It should say that the commit fails because it failed this check. Do you mean that or do you have something else in mind?

Basically, ideally you would want the solutions along with the failure message. I.e.,

if you added the file on purpose, add an exception to ... in .pre-commit-config.yaml
if you added the file by mistake, type git reset and add the file to .gitignore


Multiagent pr 2

Separate PR for the multi-agent upgrades. @AboudyKreidieh I felt for you.

two multiagent examples: an adversarial example and an example of shared moels
compliance of visual_rllib with multiagent
complain of base_env with multiagent

Pull Request Test Coverage Report for Build 1507

85 of 300 (28.33%)  changed or added relevant lines in 7 files are covered.
3 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-2.1%) to 79.957%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

flow/envs/loop/loop_accel.py
8
23
34.78%

flow/visualize/visualizer_rllib.py
28
48
58.33%

flow/envs/base_env.py
29
57
50.88%

flow/envs/loop/wave_attenuation.py
14
54
25.93%

examples/rllib/multiagent_exps/multiagent_stabilizing_the_ring.py
0
54
0.0%

examples/rllib/multiagent_exps/multiagent_figure_eight.py
0
58
0.0%

Files with Coverage Reduction
New Missed Lines
%

flow/envs/loop/wave_attenuation.py
1
42.52%

flow/visualize/visualizer_rllib.py
1
72.39%

flow/core/vehicles.py
1
91.42%

Totals

Change from base Build 1491:
-2.1%

Covered Lines:
6263

Relevant Lines:
7833

💛  - Coveralls

Don't merge; I just wanted to check that the tests will pass. Will be ready for merge tonight after additional tests are added.

HAHAHA

I'll also add some descriptions of this to the documentation first

@AboudyKreidieh we should have this discussion before I merge:
MultiEnv is for when you have multiple agents, everything else just subclasses Env. I am adding examples of this to the docs. There doesn't appear to be a cleaner solution at the moment.


Issue#36

Adds working Prile Creation and All Changes

Most minor UI changes working, the issue is that when Update user profile it need to check if the password field is null,
-For image field it better to be uploaded file field so image files can be tested.
-In AdminIst.cshtml file you can see there how i added the admin name to the confirmation message.

Could you elaborate on what you mean by this? I am not sure I understand. "Most minor UI changes working, the issue is that when Update user profile it need to check if the password field is null,"


HTML Validation issues

I ran the @nuxtjs/html-validator on this project and there is alot of HTML errors.

Feel free to open a PR @devinschumacher 💚

Feel free to open a PR @devinschumacher 💚

alright @Atinux i have never done an open source pull request before and am still relatively new to anything dev related in the grand scheme of things so... i fixed a small part and submitted a PR #63. let me know how i did and if you have any advice for future PRs/etc.!


Mock specific function in module

Hello,
I have a function (foo) that uses imports and use a function (bar),
I'm trying to mock 'bar'.
I have seen two approaches:
1. using jest.mock
2. explicitly reassign a mock
the second way is -
import * as thing from './thing.js';
beforeEach(() => {
things.bar = jest.fn(() => mockPromise);
});
What approach should I use ? (I need to mock specific function in 'things.js')

Please read and respect the issue template.


Cannot find import using golang 1.13

use go get -u github.com/kataras/iris
in emacs go-import-add not find iris
No .a file found in gopath/pkg
Ask how to generate a .a file.

or
go-import-add can find iris

Are you using modules or gopath? Does it work if you (setq go-packages-function 'go-packages-go-list)?
Take a look at https://github.com/dominikh/go-mode.el/issues/298 for some context. There are two underlying functions that go-import-add can use to determine the set of available packages. The current default for this is (go-packages-native) which tries to determine the packages available just in elisp by looking at your $GOPATH/pkg directory. This strategy has been working less and less well with recent Go releases. (go-packages-go-list) should work correctly although it may be slower if you are still in GOPATH mode.
There's a PR to switch the default to go-packages-go-list that should be merged soon.

It’s my fault, I don’t know how to use mod.

After learning to use mod, great


Personal/mihansen/aad proxy

Description
Introduces SMART on FHIR AAD Proxy
Related issues
Addresses #222
Testing
E2E Tests using Selenium Added.

I think it is time to let the review process start on this. Some comments:
The AAD proxy works by:

Proxying the request to AADs /authorize endpoint. In that process, the aud= parameter is renamed to resource= and the launch= context parameter is appended to the state= parameter (which means it will be returned with authorization code.
The Reply URL is changed from https://myapp/reply to https://fhir-server/AadProxy/callback/<Base64(https://myapp/reply)>
The authorization code is returned to the AAD proxy where the launch context is unpacked from the state parameter and a compound authorization code is created. This compound code contains both the authorization code and the launch context.
The AAD proxy sends the compund code to the SMART app reply URL, https://myapp/reply
The SMART App sends the compound code to https://fhir-server/AadProxy/token.
The proxy unpacks the compound code and send sthe original authorization code to AAD, where it obtains a token.
Selected fields from the launch context are added to the token response and returned to the SMART App.

There will be a follow up PR to once all of this is merged. This PR, will:

remove the default CORS settings (https://localhost:6001) from the template and add the CORS settings as template deployment parameter in the build system.
Disable the AAD proxy as a default setting and add it as a deployment parameter in the build systemt.

@johnstairs The launch context is now passed as part of the state= parameter in the authorization request. This removes the nasty wildcard reply URL which was previously required. I also experimented with URL encoding (instead of base64) the app reply URL in the proxy reply URL, but that doesn't work. However, current scheme should be B2C compatible, albeit with some readability and possible case sensitivity issues. Room for improvement.

@johnstairs, I switched to Base64UrlEncoder and addressed most other issues. What are your thoughts on the catch (Exception ec) {} when trying to get the OpenIdConfiguration statement. What should we be catching?

@johnstairs, Also added a feature filter to deny access to the controller unless the feature is switched on. It could have been done simpler but it should do the trick. Let me know what you think.


'ember-cli-sass-and-compass-compiler' should be the name for the repo

I think it will be a good idea to rename the repo to ember-cli-sass-and-compass-compiler, since it's the complete solution of Sass + Compass, not just compass. I initially didn't want to use this because I thought it was compass only, and I still needed to find a way for Sass. But then I read the note, and now I am using it.
Take a look at what I did to the readme with a fork here :  https://github.com/ankushdharkar/ember-cli-sass-and-compass-compiler

There is no need to refer sass explicitly since compass already implies it. This [SO answer] (http://stackoverflow.com/questions/13777215/what-is-compass-what-is-sass-how-do-they-differ) explains it beautifully:

Quote from Sass and Compass in Action:
Compass helps Sass authors write smarter stylesheets and empowers a community of designers and developers to create and share powerful frameworks. Put simply, Compass is a Sass framework, designed to make the work of styling the web smooth and efficient. Much like Rails as a web application framework for Ruby, Compass is a collection of helpful tools and battle-tested best practices for Sass.

Compass website also says on the homepage that Compass uses Sass.
I think we can expect people using compass to know that compass uses sass.

I think Rails need RVM installed before itself. Does it have its own compiler which is backward compatible and runs Ruby programs?
I guess you are right though.

README actually mentions that there is no need for additional sass libraries:
Note: This addon will compile your .scss files, in addition to making Compass's libraries available to your project. This means you do not need additional broccoli libraries for compiling sass, such as broccoli-sass.

RVM is Ruby Version Manager that helps you to maintain multiple versions of Ruby on the same machine. Rails does not require RVM but many people prefer RVM for its convenience.
I think I did not get your question:

Does it have its own compiler which is backward compatible and runs Ruby programs?


Add convenience methods for replacing ViewStack with one view

Add convenience methods for replacing ViewStack with one view

Merged - will go in to next release.


fix(Dockerfile): Add mime-support apt package at dockerfile to resolve svg not showing

Types of changes

[x] Bugfix
[ ] New feature
[ ] Refactoring
[ ] Breaking change (any change that would cause existing functionality not to work as expected)
[ ] Documentation Update
[ ] Other (please describe)

Description
PyCon icon (SVG) not showing on the top-left corner of the PR page (applied to all SVG)
The bug happens when static files are served using uWSGI but not the debug server.
The uWSGI resolves the .svg response to text/plain instead of image/svg+xml.
Related Issue
#1139 and #1151
After the enhancement of the Dockerfile, some required package is no longer included in the base image, causing unexpected behaviors.
More Information
The hotfix has been applied to the staging server, as it only occurs in the production environment that is run by uWSGI.
Solution
Reference here
add apt-get install mime-support to Dockerfile could solve this issue, and it did.

除了 icon 顯示問題外，也有遇到其他 static file 的 permission denied 問題（e.g. 在 admin site 上傳 sponsor logo 會失敗），這會一起解掉嗎？


Bump mapping schema version

Signed-off-by: bowenlan-amzn<EMAIL_ADDRESS>Issue #, if available:
Description of changes:
CheckList:

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Good catch. I know this isn't a priority but we could harden our backwards compatibility tests by indexing the schema version at each release and then assert that the schema version should be changed if:

there was a release with this schema version and
the schema itself has changed since that release


Exclude {style=table} formatting from preview

To render markdown tables using a different engine, we add {style="table-layout:fixed"} or {style="table-layout:auto"} on its own line below a markdown table. Please don't show this syntax in preview.

@geverit4 - Yes, that is representative except for 2 things:

We require table rows to have open and close pipe characters ( | )
We require a blank line between the table and the {style} syntax

Example:

Action
Planner
Worker
Reviewer
Requestor
External user

Create
✓*
✓*

Delete
✓*
✓*

Log hours
✓
✓

Accept an assignment
✓
✓

Make an assignment
✓
✓
^only in in-line edit
^only in in-line edit

Attach a custom form
✓
✓

View finance
✓
✓
✓

Updates/comments
✓
✓
✓

{style="table-layout:auto"}

This was addressed in the Markdown-it-adobe-plugin.


Multiple Selection Filter Drop-Down Widget should close on click outside drop-down

The Multiple Selection Filter Drop-Down Widget should close when a user clicks outside of the drop-down rather then requiring a click on the drop-down button.

This request has been made by two atlases supported by ELOKA.


gperf: fix build with clang 16

Description of changes
Clang 16 defaults to C++17, which does not allow the register storage class specifier. This is fixed upstream, but the change doesn’t apply cleanly to the 3.1 release. Fortunately, the fix is trivial (remove the disallowed keyword).
Things done

Built on platform(s)

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

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.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

[x] Fits CONTRIBUTING.md.

I see the commit, but has there been an official release? There isn’t a v3.2 tag or tarballs.

Ah, good point. I though that https://git.savannah.gnu.org/gitweb/?p=gperf.git;a=commitdiff;h=6d53a2dbe0ad692d0f36fd394b7e1962d9a81730 implied there is a proper release. My apologies.


Example

Query
Hey, would you Like to write me an example about how to use this autoimageslider? Im new to Java and dont understand Unit class , i used viewflipper Ver. 1.4.1 and it lags to much in scroll , wanna Try ver1.6.0. please
Version of the library used
Add the library version which is causing the bug

Hey @Blado, I'm so sorry you had to face lag while scrolling in v1.4.1.
Regarding the example, I've given one example as to how to use the library in the Readme file. Please tell me if you don't understand something then and there. Also, please do tell me if you face any further issue in the Library


Cmd line parsing fail in sample_encode.cpp with open source windows b…

…uild is fixed

I like general idea to split checks, but please return PrintHelp() call in case of unknown parameters passed to sample.

Fixed, thanks.

Status update packet looks lost. Windows build finished successfully.

It seems to be a Github issue, because status has been updated in the commits view


Adds the ability to run Masked LM models

Roberta-base does better than random on a few tasks:
mlm (pretrained=roberta-base), limit: None, provide_description: False, num_fewshot: 0, batch_size: 64
|     Task      |Version| Metric |Value |   |Stderr|
|---------------|------:|--------|-----:|---|-----:|
|anli_r1        |      0|acc     |0.3350|±  |0.0149|
|anli_r2        |      0|acc     |0.3340|±  |0.0149|
|anli_r3        |      0|acc     |0.3375|±  |0.0137|
|arc_challenge  |      0|acc     |0.2235|±  |0.0122|
|               |       |acc_norm|0.2543|±  |0.0127|
|arc_easy       |      0|acc     |0.3342|±  |0.0097|
|               |       |acc_norm|0.3081|±  |0.0095|
|mnli           |      0|acc     |0.3544|±  |0.0048|
|mnli_mismatched|      0|acc     |0.3522|±  |0.0048|
|openbookqa     |      0|acc     |0.2080|±  |0.0182|
|               |       |acc_norm|0.3280|±  |0.0210|
|piqa           |      0|acc     |0.6246|±  |0.0113|
|               |       |acc_norm|0.6219|±  |0.0113|
|race           |      0|acc     |0.2928|±  |0.0141|
|truthfulqa_mc  |      1|mc1     |0.2681|±  |0.0155|
|               |       |mc2     |0.4307|±  |0.0141|
|sst            |      0|acc     |0.4908|±  |0.0169|

I am no longer sure this approach makes sense at all. Let's say we have a classification task, with the possible labels being entailed and not entailed. I'm trying to find out whether "featherless biped" entails "man". So the two sequences for which I want to find a likelihood are

[CLS] featherless biped [SEP] man [SEP] [MASK] [SEP] (to probe for "entailed")
[CLS] featherless biped [SEP] man [SEP [MASK] [MASK] [SEP] (to probe for "not entailed")

We might break this up into two requests to be summed up: not [MASK] and [MASK] entailed.

 Looking at a single sequence, there is only one possible answer for the [MASK] tokens, and it has nothing to do with the prompts. The fact alone that "not entailed" is two tokens and "entailed" is one token gives away the game. This whole thing only works if the encoding of the possible answers has exactly the same number of tokens.

Hey @dirkgr. Thanks for trying to set this up. As you've discovered, there's no great way to deal with computing log-likelihoods here, but I don't think you're too far off. I think something along the lines of a pseudo-log-likelihood a la (Masked Language Model Scoring)[https://arxiv.org/abs/1910.14659] is reasonable, where you'd score across the concatenated context + continuation, and not just the continuation. Note that this may be prohibitively slow on large context tasks but is otherwise very useful. What do you think?

I can see that Salazar et al. are saying this works, but why? Doing it over all the tokens instead of just the continuation doesn't address the concerns I outlined in my comment.
I'm happy to change the code to do this, but it might take me a bit since I'm pretty slammed at the moment.

Closing as abandoned.


fix: v.1.9.5 Map Widget can't choose color on Markers and Unresponsive on updating (by requerying)

Description
When we worked on replacing the underlying library of google map component, we accidently replaced the custom icon with the one provided by google due to which color functionality got lost. This PR fixes this and also tracks for changes in position or color in the marker values.
Fixes #20271
Type of change

Bug fix

How Has This Been Tested?

Manual

Test Plan

https://github.com/appsmithorg/TestSmith/issues/2180

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[x] Test plan has been approved by relevant developers
[x] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=8c6037f


Outdated Power BI Client Documentation

This documentation is helpful, but outdated and hard to find.
Please update it for v3 and add a link on https://www.nuget.org/packages/Microsoft.PowerBI.Api/

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

ID: 5f23ae7f-4493-e285-c093-6fa10e20cbcc
Version Independent ID: f3a805d2-5c34-ab67-41a8-a8880917dae2
Content: Power BI Embedded libraries for .NET - Azure for .NET Developers
Content Source: api/overview/azure/powerbi-embedded.md
Service: multiple
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

@CamSoper: Would you mind taking a look or helping to route to the right contact?

@ali-hamud @MahirDiab @laurent-mic  Hello recent contributors to Microsoft/PowerBI-CSharp!
Would somebody be able to please help us update this overview? Looks like it's pretty out of date.


How to manually enqueue a file

In the documentation of Dropzone.js  it says you can add files to the queue with enqueueFile(file). However, when I do the following: this.$refs.myVueDropzone.enqueueFile(file) I get the following error: this.$refs.myVueDropzone.enqueueFile is not a function. I already checked and enqueueFile is indeed not listed as a function, nor is there anything similar. How can I manually add a file to the queue?

You could get the dropzone instance on vue-dropzone and call the method directly as:
this.$refs.myVueDropzone.dropzone.enqueueFile(file)


Allow users to define timeout value while installing karpenter helm c…

…hart.
Description of changes: This change will allow the users to define timeout value while installing karpenter helm chart through  karpenter addon and KarpenterAddOnProps.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/do-e2e-test

/do-e2e-tests


RFC: log.h

See issues: #7

RFC: Request For Comment
@NicoHaui @EtienneHouriet @LarsAeschlimann : Any comment?
@NicoHaui : As you are our administrator, you leads the discussion ;) It's up to you to merge when you think a RFC reaches a consensus

Hi Samuel, it's ok for me. We will lead the and merge the discussion. Have a good weekend


[DO NOT MERGE] Run all PostCommit and PreCommit Tests against Release Branch 2.13.0

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.


title doesn't work as expected

More context here: http://stackoverflow.com/questions/29126824/using-title-with-scalatags
import scalatags.Text.all._
title("My Awesome Website")

But
import scalatags.Text.tags2.title

works

Yeah, it seems like a natural consequence of stuffing all tags and attributes and styles into the sam giant namespace. Same problem with style and other things.
What do you think we should do? Maybe we could leave the tag-version in, and add an implicit to convert it from tag to style automatically?

I think the cleanest way is to separate tags and attributes. That's way we can use
tags.title and attrs.title in the same file.

You can already do that; import scalatags.Text.{tags2 => tags, attrs => attrs} and you're on your way ^_^

Closing because it seems there's a solution that does exactly what you want.

:+1:


Sending Strings to bugsnag.notify('String') are ignored

Expected behavior
If I send a string to bugsnag.notify('Some string') it is logged.
Observed behavior
It seems that STRINGS are ignored. After changing my tests to new Error ('Something') I got some results in the backend.
Additional information
The docs https://docs.bugsnag.com/platforms/nodejs/express/#reporting-handled-errors states that you can use error objects OR strings.

To send non-fatal exceptions to Bugsnag, you can pass any Error object or string to the notify method:

Either the documentation or the code is wrong.

Hi @marcusx, thanks for the report. The docs are correct – this is the intended behaviour and I have done a quick sanity check to verify that this works as expected with the latest Node (v10.4.1) and latest bugsnag-node (v2.4.3).
If you can provide a reduced test case or more information on how/where this doesn't work, I'll take a closer look, but it appears to be functioning correctly to me. Thanks!


Change output handling

Rework output handling to include:

date / timestamp
status
message

Distinct between normal, quiet, verbose and debug as well log files. Consider using function with printf rather than echo.

issue releated to #131 and #88


JobResult Page Slow Loading

Environment

Python version: 3.8.10
Nautobot version: 1.1.4

Steps to Reproduce

Execute Jobs via Golden Config Plugin, or self written
Navigate to primary JobResult page (Extensibility -> Job Results)
Page takes a long time to load compared to other pages (43 results)

Expected Behavior
Expected the page to load with relative expedience.

Observed Behavior
At least 45 seconds to load, the timer executed was at 50 seconds

Fixed by #1030.


edit_history: Fix a few UI issues in the modal.

This fixes a few UI issues with the edit history modal, along with some refactoring and cleanup:

Fix topic-only edits never showing a date row.
Don't repeat date rows.
Respect time format setting (12h/24h). (Fixes #15171)
Highlight topic edit diffs by using correct CSS selector.

Testing Plan:
I applied each commit to the dev server and checked that the edit history modal was working as expected.
Screenshots:
Both screenshots were taken with the time format set to 24-hour.
In the first, note: the 12-hour time; lack of date rows on the topic-only edits; "repeated" date row on the bottom visible edit (it would be repeated if topic-only edits showed date rows); and lack of diff highlighting for the topic edits.

In the second, note: the 24-hour time; the date row on the topic-only, first edit of June 3; no repeating date rows; and the diff highlighting for the topic edits.

Future Plans:
The UI does not currently take stream edits into account; I'm planning to fix that. I also have some ideas for UI/UX improvements.

This is great work!  I particularly appreciate the well-written commit messages that provide all the context one needs to understand the changes.
Apparently due to some GitHub/CircleCI operational problem, CI didn't run at first, so I pushed back here to retrigger that; I plan to merge once that finishes.

Merged, thanks @cyphase!


GraphiQL: Allow to prefix a subpath to the /graphql endpoint

Pull Request type

[ t] Bugfix
[X] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Other (please describe):

Changes in this PR
Current scenario:

Graphql server gets traffic redirected from domain.com/backend/*
If we load GraphiQL at domain.com/backend/graphiql, it tries to run queries against domain.com/graphql (contextPath + graphql path)

Proposed solution:
Make the subpath configurable, for example
dgs.graphql.graphiql.subpath: /backend
So in the previous scenario, GraphiQL will run queries against domain.com/backend/graphql
Alternatives considered:
Maybe get the full path instead of servletContext.contextPath in GraphiQLConfigurer#addResourceHandlers, eliminating the need of a new property. I thought it could be cleaner but less customisable (and I'm not sure if it's possible in all cases).
Also, other names for the property that came to my mind:

dgs.graphql.graphiql.graphql-subpath
dgs.graphql.graphiql.graphql-url-prefix
I discarded them because I thought it was a bit confusing having 'graphql' again in the same prop

Relates to issue #831

Why this feature cannot merged or reviewed yet? I need this feature too.

Why this feature cannot merged or reviewed yet? I need this feature too.

Hi - Apologies for the delay. A lot has changed since the PR was created. We have recently integrated with spring graphql and will be relying on that for our webmvc/webflux stack handling functionality. Please refer to our docs here for more details on the integration: https://netflix.github.io/dgs/spring-graphql-integration/.
Although it is opt-in for now, we plan to switch everyone to use the spring-graphql integration by default in the coming months. As a result, this PR is outdated and will be closed. I'd recommend switching to the spring-graphql starter and trying out any further customizations via spring-graphql by adding a custom route handler as documented here: https://docs.spring.io/spring-graphql/reference/graphiql.html#page-title


Problem of log_sum_exp

I also encountered the same problem with #85 using my own dataset.
Furthermore, in my case, inf didn't appear in the loss output because of the choices in hard negative mining although the inference result was very poor and it took much time to find where is wrong...
x_max = x.data.max()
return torch.log(torch.sum(torch.exp(x-x_max), 1, keepdim=True)) + x_max
This code solves the inf problem of exp but there are still the risks of -inf problem of log.
So, I changed the code as follows and the program could predict properly.
#x_max = x.data.max()
x_max, x_max_indices = torch.max(x, dim=1, keepdim=True)
return torch.log(torch.sum(torch.exp(x-x_max), 1, keepdim=True)) + x_max
I'm glad if this info is useful.

Thank you, you method worked!
and i think change the code in multibox_loss.py will also work:
loss_c = log_sum_exp(batch_conf) - batch_conf.gather(1, conf_t.view(-1, 1))
loss_c=F.cross_entropy(batch_conf,conf_t.view(-1))

Thank you, you method worked! and i think change the code in multibox_loss.py will also work: # loss_c = log_sum_exp(batch_conf) - batch_conf.gather(1, conf_t.view(-1, 1)) loss_c=F.cross_entropy(batch_conf,conf_t.view(-1))

take cross entropy will result in one number, what we want is the loss for each box.


ast-codegen: visit it.body.body instead of it.body in CatchClause

CatchClause
https://github.com/oxc-project/oxc/blob/07506ece83e7101f618093afa74be23babfc58c3/crates/oxc_ast/src/ast/js.rs#L1307-L1313
In semantic builder:
https://github.com/oxc-project/oxc/blob/07506ece83e7101f618093afa74be23babfc58c3/crates/oxc_semantic/src/builder.rs#L1351-L1363
In Visit
https://github.com/oxc-project/oxc/blob/07506ece83e7101f618093afa74be23babfc58c3/crates/oxc_ast/src/generated/visit.rs#L3691-L3707
The difference between them is that one calls visit_statements(it.body.body) and the other visit_block_statements(it.body)
Because we will create a scope within the CatchClause, we do not need to create a scope again in the BlockStatement.
Is there a better way to resolve this problem? Such as changing the body to Vec<'a, Statements<'a>>

@rzvxa @Boshen cc

I think the bigger question here is that do we want the block in a catch clause to be processed as its own thing or a dedicated block. I went with this because it makes more sense to visit the catch block on visit_block_statement. If it isn't the desired outcome we can change it to Vec<'a, Statements<'a>> as @Dunqing has suggested.

Oh sorry I just saw your edit, Let me reconsider my answer and reach back to you.

I'm not sure about this one either, spec wants two scopes here 🤔
https://tc39.es/ecma262/#sec-runtime-semantics-catchclauseevaluation

I'm not sure about this one either, spec wants two scopes here 🤔
https://tc39.es/ecma262/#sec-runtime-semantics-catchclauseevaluation

I took a look at boa. Yes, you are right. I think I know what to do.

Leave this issue to me. I'll fix this according to the spec.


http.nonProxyHosts support

Hi,
Does this connector support the -Dhttp.nonProxyHosts option, I can see there are instructions for using a proxy by specifying the JVM options for host and port, however we also need to be able to specify a list of nonProxyHosts as we are working with an OnPremise kafka cluster which is talking to GCP via a proxy, however the licensing servers for the kafka cluster are based OnPremise and shouldn't go through that proxy. We have had problems with the confluent provided pubsub kafka connector as it ignores the nonProxyHosts jvm parameter so we were interested in trying out this one to see if it correctly handles it.

Hi Nicholas -
The connector will ultimately run packaged with the Kafka Connect binary and relies on the network client/server provided. Please note that Kafka traffic is non-HTTP and uses a custom TCP-based binary protocol - https://kafka.apache.org/0100/protocol.html#protocol_network. This should not be affected by the HTTP proxy setting (if it is restricted correctly to HTTP-only traffic). Please note that it is likely that you have configured authentication with SASL/SSL and so might need to allow inbound/outbound traffic of that type to the broker addresses.


TODO: implement station labels

via README.md:

To do
Things I am still working on or someone should work on in the future, roughly in order of perceived importance:

Improve algorithm: “Smoother” edges, higher distance for parallel lines, implement station labels.

What's required to make this happen?  I assume the algorithm informs x, y and font size... does it need the rendered size in return?  How is that returned?
Also, is this a feature that was dropped for lack of time or was there a technical snag behind it?
TL;DR I could work on this in the future, where do I start?

Hey, thanks for your interest (: (I'm sorry that it took me 1 month to respond ._.)
There are two ways to approach the labeling problem, one easy but suboptimal and one hard but optimal.
easy but suboptimal
It would be possible to adapt the library used for generating the SVG to draw station labels in some smart way. The lib could take in the name for each station and pick the best place besides the station node to put the text. In the worst case, you would get overlapping text, though (or labels that are really far away from their station node). Maybe this would work out sufficiently well, I can't really tell 😄
hard but optimal
The problem of overlapping labels could of course be avoided by taking them into account in the main optimization model. This - at least in the simplest approach I could come up with in very limited time - makes the optimization problem (which is already really complex without them - many networks are still too big to be optimized with the current script) even more complex, making the computation take multiple days, months, years or even centuries. Unfortunately, I didn't have the time yet to think of a smarter way to achieve this within the constraints of our mathematical model.

If you're interested in working on any of these two approaches, let me know if/how I can assist you with that. (And if something in my text was phrased weirdly and hard to understand, which is probably the case, also don't hesitate to ask for clarifications 😅)

That's sort of what I was thinking -- you know the name (in ASCII) of the station, which will render at some known pixel width and height (given a typeface).  So that leaves 2 problems:

getting the pixel width / height from the typeface and text
using those dimensions to optimize the map (regardless of how: adjusting station positions, text rotation, position relative to station dot, etc)

Even if the second problem isn't actionable now, it still seems like I couldn't event attempt it without solving the first problem -- finding a way to calculate those rendered dimensions.  If I'm understanding you correctly, the place for that calculation is this repo... and the the place for rendering it onto the image is in the svg-transit-map repo.  Right?

can again be implemented in two different ways: If you take into account that the labels can be line-wrapped and/or abbreviated, that seems to be yet another optimization problem.


net: gptp: Fix type mismatch calculation error in gptp_mi

NSEC_PER_SEC is an unsigned integer macro. Thus, -NSEC_PER_SEC will be
treated as unsigned integer as well which lead to calculation error on
64bits integer variables. Added the correct type casting into the formula
to fix the calculation error.
Signed-off-by: Kweh Hock Leong<EMAIL_ADDRESS>

The type mismatch causing nanosecond existed 9 digits value when passing to ptp_clock_set() API:

Associated issue https://github.com/zephyrproject-rtos/zephyr/issues/44310


Add a dropdown arrow to hide nested segments

The timer component gets long quickly when working with nested segments. We can add a dropdown arrow similar to the one used by Obsidian for bullet point lists to hide or show sub-segments.
Here's a demo of how that might look like.

I would also like to hide an entire list of segments to make notes less cluttered, but I think that might be a separate issue since there needs to be a change in the overall layout of the component. What do you think?

Hello everyone, this issue seems to be fixed already. @Ellpeck so the issue could be closed. #53 is described in an extra issue.


Inner join

When im doing an inner join between two tables that has some equal column names the object that is returned has values from the second column instead of the first. is this the expected behaviour?
example:
Where<Category> query = new Select().from(Category.class).as("C")
  .join(Spot.class, Join.JoinType.INNER).as("S")
  .on(Condition.column("S." + Spot$Table.MCATEGORYID).eq("C." + Category$Table.MID),
        Condition.column("S." + Spot$Table.MSTATE).eq(ConstantsApi.STATE_ACTIVE) )
                .where()
                .groupBy("C." + Category$Table.MID)
                .orderBy(true, "C." + Category$Table.MORDER);

the category.id has the value of spot.id

I have the same problem. My solution is to build and array of ColumnAlias using ColumnAlias.columnWithTable() (in your case with Category columns) and use the Select(ColumnAlias... columns) constructor.


Support dotenv files discovery

I'm using the pylint in VSCode to run a custom plugin of pylint. In the built in python extension, I set my the PYTHONPATH value in the .env file to the pylint plugin directory, and the extension is able to read the plugin and lint correctly.
However, when I tried migrating to the new pylint extension, it doesn't discover the env file, and as the PYTHONPATH variable isn't set, I do not get results from the custom plugins.

The temporary workaround until we resolve this is to set PYTHONPATH in your terminal before launching vscode from the terminal:
Linux/mac:
> cd <project dir>
> export PYTHONPATH=<path to your plugins>
> code .

Windows:
> cd <project dir>
> set PYTHONPATH=<path to your plugins>
> code .

Seeing similar issues with my current project, any idea on when we can expect the linked PR to make it into a release so we don't have to keep using the workaround? It's currently the only thing stopping us from switching to use the new extension.

@karthiknadig Can you tell us when we can expect a fix for this issue? It would be nice if the new extension worked in the same way as the old deprecated one.

Found another workaround which doesn't involve manually setting the PYTHONPATH in the terminal before starting VS Code with the code . command, it's not perfect but it works for us. You just need to add the following to your workspace settings (credit to Shinebayar G's answer on Stack Overflow):
"python.analysis.extraPaths": ["<whatever-you-were-manually-setting-the-pythonpath-to-before>"]


Basic fungible faucet smart contract [WIP]

We need a faucet to provide assets for the builder's testnet

Duplicate of #177


Explicitly say that CLI --exclude option disables only 3-part codes, entire sniffs, not 4-part ones

Is your feature request related to a problem?
Hello, IDK if it's the right place for me to talk about this, but we use phpcs without ruleset.xml and couldn't figure out why a 4-part code exclude wasn't working. The error message only says about rule not being found.
Describe the solution you'd like
Explicitly say in wiki and in CLI help that --exclude option doesn't work with 4-part codes.
To be frank, our version of phpcs is quite old (3.4.0) so it may be fixed in newer versions, but I only could find about it from this comment in old repo:
https://github.com/squizlabs/PHP_CodeSniffer/issues/1755#issuecomment-482394520
This could save others time to find out why their exclude is not working.

[x] I have read the Contribution Guidelines and this is not a support question.
[ ] I intend to create a pull request to implement this feature.

@jrfnl while I agree with this, the error was very hard to Google. Maybe I should've read the wiki yes, but without pointing out the specific section, in advanced usage nonetheless (I wouldn't consider it advanced btw), it's hard to find it for me.
My user story is like this: see error, wonder why it's invalid, Google it, can't find my use case, go to github, usage is in wiki, search by exclude, nothing comes up aside from the console help. Continue googling, trying to change the search query, until I find the issue I mentioned.
Even when I went to advanced usage now (btw hard to find that page on mobile), I couldn't make out which section do I need. Limiting results to specific sniffs sounds like an include list only.
After the error text change it could be easier to find why, I agree. And I know how hard it is to maintain open source projects :D

@arsel-5lvxa7b1 I hear you and improving the error message, as per #344, is a "blessed task", so once the work on that is finished, it will be merged and included whichever release we're at by that time.
Having said that, I understand your inclination to use a search engine to find answers, but the GitHub website is not super-SEO friendly (which is outside my control), so I'd always recommend checking the project documentation (README/wiki) first.
If the documentation can be improved, I'm happy to accept suggestions, but the prerequisite for that will always be reading the docs first....

Alright, let's close this then, if I'll have an idea how to improve the wiki, I'll do a pull request, assuming I'll have the time :D


Fix: Koios backend failed integration test (#89) +  Move Koios Urls to a Constant class in koios main module bloxbean (#90)

@edridudi I mean "koios" subproject's main folder. Not root project's main folder. The above Constants class is for Blockfrost. So we need an equivalent one for Koios in Koios subproject.

what package?
com.bloxbean.cardano.client.backend.impl.koios.common ?
or should I create it in
com.bloxbean.cardano.client.backend.koios ?

Thanks @edridudi. Looks good to me


Configuration guidance for Sharewave Ethernet-to-RS485 converter

Hi,
My setup:

Nilan EC9 / CTS602
Waveshare RS485 TO ETH (B) converter https://www.waveshare.com/wiki/RS485_TO_ETH_(B)
Raspberry Pi 3 + Home Assistant
Nilan integration installed from HACS

I get "Invalid Response from Device" when trying to add the integration. Any ideas where the problem would be?
The modbus integration used to work in Openhab and previous USB-converter but I changed to ethernet-based for this specific integration in HA.

Hi,
It propably is that your bridge is not ModBus TCP, but instead ModBus RTU over TCP. I havnt enabled official support for that yet, but you can try it by editing the device.py and replacing "tcp" with "rtuovertcp".
Nilan EC9 is not supperted yet, but I think you will help me with that.

If that does not help, then you will have to try modifying the settings on your bridge. Please share the settings if you get it to work, it may help in future issues.

Also I could add support for usb adapters, but I cannot debug this my self, so you would have to help me with that also and it might be difficult to do.

If that does not help, then you will have to try modifying the settings on your bridge. Please share the settings if you get it to work, it may help in future issues.

This was on my mind because Sharewave seems to be quite popular and your integration very easy to install.
The manual doesn't clearly state that the converter could act in Modbus TCP state (if it isn't the NONE mode)

Kiitos jo näistä vinkeistä.

I would guess transparent is "rtuovertcp" and Modbus TCP is "tcp" so it should work. There might be some other setting that is wrong.

Baudrate should be 19200 i think. And also destination and source ports should be both 502.

Also make sure that your device id is 30. You can find this setting in the HMI menu.

Changed the ports to 502.
With all custom components/nilan files as defaul I get:
Waveshare / Multi-host settings / Protocol = none
-> Invalid response From the device
Waveshare / Multi-host settings / Protocol = Modbus TCP to RTU
-> Unsupported Device
Something is changing..

Hi, unsupported device is correct. Open a new issue with the information from the read-me instructions.


Fixed use of Q#any and added test.

Q#any (.any on a promise instance) previously would never resolve due to any requiring its parameter to be an array.

That test failure is due to debug version 4 dropping support for older versions of Node. Q depends on promises-aplus-tests at 1.x which gets 1.3.2 which depends on mocha at ~1.11.0 which gets 1.11.0 which depends on debug at * which gets 4.0.1.

Same issue here for my kriskowal/q/pull/841
So I created a promises-aplus/promises-tests/pull/89

It also looks like CI has gone stale because we’re testing on a version of Node.js that does not support the syntax used by one of our testing libraries.
Wouldn’t it be nice if people used semver to indicate when they’re using new JavaScript syntax that their users might not support ;-)


Rename Datastore Revision() method

A new name should more accurately represent the intention of the method.
CRDB datastores uses a quantized time as the revision, while Postgres/Memory datastores use random fuzzing to determine their revision

/assign

@yuchen-sun are you still interested in taking this on?

@yuchen-sun are you still interested in taking this on?

yeah, I was looking at the previously mentioned papers and studies oidc.
Of course, if you have an arrangement, you can always remove me from the program

We realized that "QuantizedRevision" is not a universally better name because that's not how each datastore uses it.
I moved the state of this issue back to "needs discussion" as a result of this realization.


Minor improvements to Badger store.

Nothing significant, just somethings I came across as I was perusing the code.

@burmanm could you please review this one?


Output bugs

The new updates cause the output layout error, including misplaced legends and labels of the circle fitting plot, wrong scale, and label of the phase plot. Can someone help? Also, is there an option to output png images instead of pdf files?
Thanks.

This issue is probably arising from the incomplete separation of fitting and plotting. PR #166 divided Sdata into two Python files, but there are still remnants of plotting in the 'fit' function. I will keep investigating and try to find a fix. In the meantime, reverting to Commit 04b9561 should put you at a version of the code predating this problem.