Diagonal iterators

This PR introduces new iterators (Diagonal, DiagonalMut) for Matrix/MatrixSlice/MatrixSliceMut. It is intended to resolve #53 .
Here are some benchmarks for collecting the main diagonal of a matrix:
test linalg::iter::mat_diag_iter_100_500           ... bench:         272 ns/iter (+/- 34)
test linalg::iter::mat_diag_manual_100_500         ... bench:         309 ns/iter (+/- 87)
test linalg::iter::mat_diag_iter_10_50             ... bench:          62 ns/iter (+/- 8)
test linalg::iter::mat_diag_manual_10_50           ... bench:          68 ns/iter (+/- 21)

The manual version uses unsafe get_unchecked indexing and is slower!
Following is kept in place for prosperity but this PR is no longer WIP (pending review).

This PR is currently a work in progress and the following should be addressed:

How do we handle iteration of off-diagonals?
How do we expose these iterators?

I'm thinking we do the following:
Add the following:
pub enum DiagOffset {
    Above(usize),
    Below(usize)
}

The iterator will then have this enum as a field - which will determine which diagonal offset we use. When creating we will have to check that Above(x) has x < mat.cols(), and Below(y) has y < mat.rows().
In terms of exposing the iterator - I think the following is a good approach:

Add fn iter_diag(&self, k: DiagOffset) to BaseMatrix.
Add fn iter_diag_mut(&mut self, k: DiagOffset) to BaseMatrixMut.

We will keep the diag function as returning a Vec for now - mostly to prevent breaking changes and we can reassess in future.
We will probably need to move the iterators into matrix/mod (they are currently in matrix/iter). This is so that we can construct them in matrix/slice.

Had a brief look. Looks good to me!
One comment though. Should we also have a DiagonalOffset::Main for the sake of symmetry? It feels very arbitrary to pick Above(0) or Below(0) if you want the main diagonal (which is probably what users want in the majority of cases).
Also, I generally like this pattern better than the signed integer approach, but I'm curious if there are algorithmic patterns which are not easily covered by the more type-safe approach you propose. I can't think of any, so perhaps we should just go ahead and re-assess if we receive any complaints.
If you recall my previous example using signed integers, I think actually it looks much more clear this way!
use DiagonalOffset as D;
for diag in (D::Above(1), D::Main, D::Below(1) {
    for ref mut element in mat.iter_diag_mut(diag) {
        *element *= scale_factor;
    }
}

In the issue thread I had suggested this - and thought it looked a little ugly, but actually now I think it would be better. I'll use the enum with the Main entry too.
I also can't think of any cases where this approach fails and the signed one wins. As you say I guess we'll implement it and respond to complaints later :).

Also, I understand that you want to avoid a breaking change right now, but I really think that diag should return an iterator by default in the future! For one, because I think in many (most?) cases you don't even need to collect into a separate collection, you just want to iterate over the values anyway. Secondly, because you can collect it into different data structures (Vector, Vec, etc.), or even .chain() or .zip() different diagonals together, or similar interesting patterns. Third, I guess we want to keep the API smaller, and as such we avoid somewhat redundant methods.

A question.
How should we respond if the user asks for a diagonal offset which is out of bounds? For example, Above(2) for a 3x3 matrix? I guess the most comparable in the standard library is slice.get(idx), which returns an Option<T>. So we could return an Option<Diagonal>, but this is very inconvenient when you are only interested in Main, in which case the diagonal always exists. One possible approach here is to remove Main from the enum again, and have separate methods, i.e.
/// Iterator over the diagonal
fn diag_iter(&self) -> Diagonal;
/// Iterator over off-diagonals
fn off_diag_iter(&self, offset: DiagonalOffset) -> Option<Diagonal>;

It feels a little verbose, but it's clean, at least. I'm not sure what the best approach here is.

I was planning on returning an Option<Diagonal> even for the Main diagonal. I agree that it is a little unnerving for the Main case but most of the time when we have to unwrap an Option we are sure that the value does exist. I don't think this goes against that too strongly - I'm happy to discuss a little more and see what the finished product looks like though.

I looked a bit more at std::slice. I'd say panicing is acceptible for invariant-breaking input, see for example slice.split_at().

There is a conceptual difference in returning Option<Diagonal> for the main diagonal and Diagonal directly. In the first case, the user needs to actually sit down and think: "Is it safe to unwrap this?", whereas if we provide a Diagonal directly, the user knows that it is indeed safe to unwrap.
I think we should definitely strive to not impose redundant considerations for our users whenever possible!

Actually - I think the most idiomatic approach would be to return an empty iterator. And I think we can achieve that by setting the diag_len to zero if it is out of bounds. I'll try implementing that so we can see how it looks.
Otherwise I'm happy to go with the panicking approach (which will be low effort to change).

I think this might be dangerous. I think in most cases if you try to get a diagonal that does not exist, this is a bug in your code. Depending on your subsequent actions, you can get very unexpected results that will happily go along without letting you know! For example, consider the following example:
We wish to compute the sum of the off-diagonal elements (the trace) of some off-diagonal. We do the following:
use DiagonalOffset::Above;
let sum = mat.iter_diag(Above(some_num)).sum();

This is very simple and convenient! But what if some_num is out of bounds? We only get a zero sum, with no warning whatsoever that something went wrong!
I'd rather go with the panic or the diag/offdiag split, I think.

Also I think I agree with your points. Returning an empty iterator could be a little confusing and is very difficult to detect (without consuming the iterator).
I would prefer to go with panicking for now - the rulinalg api already feels quite large to me and so I'm always anxious to add lots of similar functions. (This is an issue we'll hopefully find a way to address in the future).

Agree with your assessment. I think also panicking is perfectly acceptable, and also my preference.

I still need to add tests for the slice nth and last functions. Then write up some docs explaining how these things work.
After that I'll remove the WIP tag!

I think this is ready for a proper review now. Also I've added benchmarks (on my system) to the PR description.

From a quick look, it looks good, and the benchmarks are awesome! I have a couple of things I'm curious about though. Will do a proper review tonight!

@AtheMathmo: one thing though, what exactly is row_stride? The docs only say "Row stride in the matrix". I can guess, but it would be nice to have a precise definition.

From my understanding: row stride is a conventional name for the number of elements in a row in your underlying data structure. It's needed because if we have a matrix with 5 columns and 3 rows, but we take a slice with only 3 columns then we need to know that our underlying Vec actually has 5 elements in each matrix row, that is the row stride.
We should document this a little more. Though from memory the only place that it is exposed to the user right now is in the from_raw_parts function.

That makes sense. Thanks! Yeah, some documentation on that would be nice, even if it's just internal for developers. (That might exist already though, I didn't look through all the source)

Manual is faster on my system.
Any reason why you didn't borrow a BaseMatrix to store Matrix data (like row_stride and the pointer)?
I will try an alternative, can you wait for 1 or 2 days?

Manual is faster on my system.

Thanks for letting me know! Is it by a considerable amount? Maybe you could try some different sizes in case it is cache differences?

Any reason why you didn't borrow a BaseMatrix to store Matrix data (like row_stride and the pointer)?

I just went with pointers directly as it was the approach I had taken before. In terms of safety they should be mostly equivalent as we have lifetimes etc. There is a little more room for error in that I am manually computing the offsets when we could be using get_unchecked - this is fairly minor though (I would argue). [As an aside we should probably look into inlining those get functions].
There may also be some borrowing issues when we use a BaseMatrixMut but I haven't tried it out so can't say for sure.

I will try an alternative, can you wait for 1 or 2 days?

Sure - I'm happy to wait.

Something like https://github.com/AtheMathmo/rulinalg/pull/59

Thank you both for the feedback!
I agree that it makes a lot of sense to borrow the BaseMatrix and use this for the matrix fields. And also to modify the start point rather than having branches within each of the iterator functions.
I have some concerns about how well @tafia 's approach (and the get approach @Andlon suggested) will work with the compiler. In the current implementation the compiler seems to magically remove a lot of the bound checks from the diag_pos < diag_len. Hopefully this is still the case with the suggested versions but if not it isn't a big deal.
I'll implement these changes and rerun the benches to confirm!

I think in any case, unless really possible to avoid because of performance reasons, I think we should try to avoid working directly with pointer offsets, as it exposes/breaks the encapsulation of how matrices are stored internally (which is a maintenance burden).

I agree - if the mutable iterator plays nice with borrowing the BaseMatrixMut I think your version is equivalent? And if @tafia 's version works too then it means our iterator allocates less (we only need one usize for the start and one for the end).
I'm trying your version first - if that works I'll try it with get instead of get_unchecked. And then if all is good @tafia's version in #59 should be optimal!

@Andlon  We have to use raw pointers sadly. From #59:

rustc can't be sure that our iterator isn't returning two mutable references to the same point. Raw pointers it is!

I will merge in @tafia's PR once I can confirm there are no regressions on my machine.

@AtheMathmo: ah, yes. That makes sense! Fair enough :)
I found this: http://smallcultfollowing.com/babysteps/blog/2013/10/24/iterators-yielding-mutable-references/. It's from 2013, but it appears it is the same basic problem, and I don't expect there's any better solution available yet.

I am happy to merge this now - am I missing anything else @tafia @Andlon ?

I think it looks good! I added a couple of comments mostly out of curiosity. They don't need to impede the merge.

Wow, perfect timing. I'm itching to use this.
Two dissenting opinions:

Is it culturally such an issue to return an Option or Result instead of panicking for a Rust programmer? Theoretically speaking, a matrix with zero rows and columns (not a mathematically implausible concept) would have no main diagonal, so it's not unreasonable to make that case realizable using Rust patterns. I think that not doing this externalizes the effort of wrapping the result of the function call--every programmer who has to plan for unpredictable input to this function has to do the same effort.
Regarding the signed super/subdiagonal differentiation, I agree it's more idiomatic to Rust to use an enum than overloading the signed integers to describe this. (Although, technically, all programming is at heart an overloading of the integers when you think about it.) It's worth mentioning that any user who wants to do interesting numeric patterns (say, quick alternation across sub/superdiagonals, or something even stranger) in populating a matrix will indeed have to spend extra effort to map some pair of numbers to Above and Below.

Thanks for the input @bright-star !
With regards to your points:

I am also a little unsure on this one - but I'm leaning towards panicking being the right course of action. Generally a panic represents a programmer error which I think in this case makes sense: the programmer has gone out of bounds and we should let them know. We should check this is the case - but I believe currently an empty (0 rows/cols) matrix will return an empty iterator if you request Main, and panic otherwise. This might be a little inconsistent but is reasonable I think.
I think as you discuss this is really a trade-off between simplicity for 99% of our users vs. added complication for the remaining 1%. I think in this case the added complication is reasonable and Rust makes it fairly easy to do this enum magic (match, map etc.). It is still a worthwhile consideration though.

@bright-star: good points! The zero-diagonal is an edge case we should probably have a test for, and also perhaps explicitly describe the behavior in the documentation, although it already says it will never panic in the case of DiagOffset::Main. This also sort of makes sense if you define a 0x0 matrix to have a 0-length main diagonal. I think iterating over the other diagonals is relatively rare in comparison to the main diagonal, and even rarer in the cases where you have to deal with unpredictable input. Like @AtheMathmo mentioned for point 2, I guess it's a tradeoff in simplicity for the many vs flexibility for the few. That said, we might be making the wrong decision here, but perhaps we could just see what kind of feedback we get from users when it's more used in actual applications?
As for point 2, we could simply impl From<integer> for DiagOffset I guess, and take Into<DiagOffset> instead of DiagOffset in diag_iter? It might actually be such a common case that it's still worth supporting it. I don't know.

@Andlon I actually really like the idea of Impl From<integer> for DiagOffset. I'll want to see what it looks like once it's there but it seems like it would make things a little simpler if the user doesn't have to know about the enum.

Just for reference, here is some code I'm porting over from MATLAB that uses diagonal addressing: https://github.com/bright-star/computational-em/tree/master/finite-difference

@bright-star thanks to your post we caught a bug with empty matrices, thank you!
What did you think of the idea of implementing From<integer> for DiagOffset? Does this alleviate your concerns about playing with more interesting numeric patterns?

Thanks! I'm fine with that. It's definitely something that should be the responsibility of the library user to decide if they want to use.

Is there anything I can do to help this PR get merged?

@bright-star Sorry I've been a little slow with this as I am currently on vacation. I return on Tuesday so should be able to settle it shortly after that.
As for the delays - I still need to implement From<integer> for DiagOffset. Otherwise there is another PR, #61 which proposes a tidier implementation. However this seems to have some performance regression and so I would prefer to leave the PR as is. @tafia are you ok for me to close that? I've played with it a little - switching to mem::transmute etc. but still see the regression.
I also switched this PR to use mem::transmute. Though I saw no performance difference it removes the null check and so seems worth including...

@AtheMathmo, yes you can close #61. Better to have the iterator available sooner than later as changing how it is implemented, in case we managed to understand the regression, won't be a breaking change.

@tafia Thanks, I agree though it is a shame. I think your current contributions to this PR have already made a lot of difference though!
I've implemented the conversion to DiagOffset so that users can now directly use integers on the iter_diag functions. I think this is ready to merge now but please let me know if anyone sees anything off.

@Andlon - do you mind if I poke you for confirmation on merging this?
I'd like to get it in soon. It seems to be a popular feature!

Thanks for the comments - I gave responses. I think it's better to converge somewhat on these thoughts before we merge :)

Something just occurred to me. Does DiagOffset::Above(0) address the main diagonal? Should it? I think it might be a safe thing to do, and likewise with DiagOffset::Below(0).

@bright-star yes that is how it works.
Sorry I haven't made much progress on this PR. I'm having a hard time deciding exactly how the API should look. I'm not too sure about removing the From implementation for unsigned ints. At the end of the day it doesn't matter much at all so I'll settle with the common ground.

Maybe https://github.com/AtheMathmo/rulinalg/pull/69 will help crystallize your thoughts :wink:

I want to try and get this in today, it seems we have two points to discuss.

Should the iter_diag functions take an Into<DiagOffset>, or just a DiagOffset.
Should we implement From<unsigned> for DiagOffset.

For the first point, I have no issue personally with allowing the generic Into parameter. But similarly I don't think it is too aesthetically damning to remove it. I'm happy to get rid of it and have a more explicit parameter here.
For the second point, it is also fairly minor. Again personally I don't see any issue with allowing unsigned types to cast into DiagOffsets. I also see no huge issue with not doing so. The only thing holding me back on this is the worry that it might impact us later. We index across the board using usize right now - I worry that there may be some cases were a user wants to use a usize index with the `DiagOffset. I don't see an obvious use case, and there wouldn't be much of an issue with having the user cast into a signed integer anyway.
If there are no additional thoughts on this I'll act on both points, removing the Into parameter and revoking the From implementation for unsigned ints.

Will comment on this when I'm home in a few hours!
On 30 Oct 2016 8:56 a.m., "James Lucas"<EMAIL_ADDRESS>wrote:

I want to try and get this in today, it seems we have two points to
discuss.
Should the iter_diag functions take an Into, or just a
DiagOffset.
Should we implement From for DiagOffset.
For the first point, I have no issue personally with allowing the generic
Into parameter. But similarly I don't think it is too aesthetically damning
to remove it. I'm happy to get rid of it and have a more explicit parameter
here.
For the second point, it is also fairly minor. Again personally I don't
see any issue with allowing unsigned types to cast into DiagOffsets. I also
see no huge issue with not doing so. The only thing holding me back on this
is the worry that it might impact us later. We index across the board using
usize right now - I worry that there may be some cases were a user wants to
use a usize index with the `DiagOffset. I don't see an obvious use case,
and there wouldn't be much of an issue with having the user cast into a
signed integer anyway.
If there are no additional thoughts on this I'll act on both points,
removing the Into parameter and revoking the From implementation for
unsigned ints.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AtheMathmo/rulinalg/pull/55#issuecomment-257137473, or
mute the thread
https://github.com/notifications/unsubscribe-auth/AAjTBTanQNlV2azTqjV_Yd3kAaa4mQYeks5q5E21gaJpZM4KHTOt
.

I think this is not an issue of aesthetics, but encouraging our users to leverage type safety for more readable and less ambiguity. I think removing Into is the safer choice.
Well, since DiagOffset maps one-to-one to signed integers, I think it makes sense to be conservative and avoid the usize implementation for now, and then see if we get any requests from users due to the lack of From<unsigned>? Then we could imagine legitimate usecases. This means less risk, but I think the risk is very low in the first place, so I'm not too fussed about it either way.

In any case, I'm still OK with whatever decision you want to make here. I also think it's OK to merge at this point.
That said... Please forgive me for bringing this up, as it may further confuse us all and cause further delays, but I've been thinking about diagonal iterators from the perspective of user experience. You don't need to take the following into account for this PR, but I think it brings up some important points.
Imagine you are a user of rulinalg. I think it's not unreasonable to assume that 90+% of the use cases for diagonal iterators will be iterating the main diagonal. You first write
for el in mat.d<autocomplete>

Unless your IDE is very smart, iter_diag() will not show up in the autocomplete prompt. After looking at the docs, you find iter_diag(), and without looking thoroughly at the documentation, you write
for el in mat.iter_diag() {}

Obviously, this doesn't work, because you need a diagonal offset, so you try again:
// I personally don't even know in what module DiagOffset is in off the top of my head!
for el in mat.iter_diag(rulinalg::DiagOffset::Main) {}

If you get the module right, then you should be good to go. Now, I argue that this user flow is not optimal. A good user experience implies that the user is intuitively guided so that his first choice is the right choice whenever possible. Constrast the above with the following:
// Main diagonal, `diag_iter()` shows up immediately when autocompleting
for el in mat.diag_iter() {}

// Off-diagonals cover the remaining use cases
for el in mat.offdiag_iter(rulinalg::DiagOffset::Above(2)) {}

My argument is that the current proposal has two flaws:

The naming does not put the main feature in focus and does not play nice with autocomplete functionality.
Working with the main use case, which is iterating over the main diagonal, is overly cumbersome.

I know the two-function proposal has more or less been abandoned already, but the more I think about it, the more I think it makes for a better fit. Note that this is solely because Rust does not allow default arguments, in which case a single function would suffice.
Again, I'm very sorry for dragging this up again! Feel free to ignore it.

Again, I'm very sorry for dragging this up again! Feel free to ignore it.

Not at all! I think it is well worth discussing.
I'll go with your approach for points 1 and 2. It seems the more popular choice :).
As for the diag_iter vs iter_diag. I don't disagree that the former may be a little clearer and work better with IDEs. However making this change would probably also mean making changes elsewhere. I don't think it would make sense to have diag_iter and iter_rows for example.
I think you're right about the primary use case however my plan for tackling that is to modify the current diag function. I think it will be better to have diag return an iterator over the main diagonal. From here it is a small step for the user to retain the existing functionality: mat.diag().collect::<Vec<_>>(). Of course this is a breaking change and so should come with a version bump.

Ah, I didn't know about your plans for diag. Then I whole-heartedly agree!
As for iter_rows. Yes, I agree, and I did actually think about this too. In fact, I think all iter_* functions should be changed to *_iter (well, iter_rows(), would probably be row_iter(), but you get my point). I think this feature is ready to merge, but I strongly suggest we consider renaming the iterator functions in a later release (this would of course be an annoying breaking change).

I have created #75 and tagged as part of the 0.4 release. I'll write up a similar issue for the diag() change too.
I've just pushed changes to tighten up some of the conversion generics. I made some minor doc tweaks to reflect that too. I think this is ready to merge now, let me know if you spot anything!

@AtheMathmo: great! I looked over the latest commit and it looks good to me :)

Ok, lets get this in!


The "Register DOI" button on the Item status page is not displayed

Describe the bug
The "Register DOI" button on the Item status page is not displayed when 'identifiers.item-status.register-doi' is turned on.
This happens at 7.6.1 (7.6.0 works fine)
To Reproduce
Steps to reproduce the behavior:

Set true the property identifiers.item-status.register-doi at config/modules/identifiers.cfg
Redeploy when neccesary and restart tomcat
Login as admin
select an item -> edit -> status
(button is not shown)

Expected behavior
Button "register DOI" must be shown
Related work

Closing, as this was already fixed on 7.x and main.  See #2766 (fixed on main) and #2802 (ported on 7.x)
This ticket is a duplicate of #2765


Problem with eslintrc: "indent" is invalid: Value "4" must be an enum value

I use gulp-eslint as follows:
var standaloneScript = 'public/api/config-api.js';
gulp.task('eslint', function () {
    return gulp.src(standaloneScript)
        .pipe($.eslint())
        .pipe($.eslint.format())
        .pipe($.eslint.failOnError());
});

In my root folder I have a eslintrc specified. But eslint crashes because of the indent rule. It says:
    Configuration for rule "indent" is invalid:
    Value "4" must be an enum value.

//...
"rules": {
        "indent": [4, 4],
//...

What can I do? Removing indent works, but this is not an option for me. Could you help me to resolve this issue?

Great, the error message exactly tells us what you should do. I love such a good design of ESLint.
That's an issue with your .eslintrc. Read the ESLint documentation carefully.

http://eslint.org/docs/user-guide/configuring#configuring-rules
http://eslint.org/docs/rules/indent

@shinnn thanks for the hint. Now it works. If someone has the same problem, defining the indent rule as
{
//...
"indent": [2, 4]
//...
}

worked for me. Why I didn't thought it is a problem with the rule is, that I used this exact .eslintrc with ember-cli-eslint also and there I had never any problems.

I found the cause. ember-cli-eslint uses broccoli-lint-eslint, that still uses eslint v0.22.x. And, the config validation feature is only available from eslint v0.23.0 or newer. http://eslint.org/blog/2015/06/eslint-0.23.0-released/#configuration-validation

@shinnn very interesting! Thanks a lot for the detailed information :+1:

@shinnn please in future let me know or better yet submit a patch. Things have been busy in the last two months however I hope to get stuff patched soon to be v1 safe.

@jonathanKingston I won't, because I'm currently not an actual user of ember-cli-eslint. I just needed to look into your code to answer the question reported here.


Add additional_routes and cpu_architecture variables to root module

Hi there! Thanks for this project, it was great to quickly get Tailscale up and running in our AWS VPC.
I did run into a problem using a couple of the variables added in https://github.com/hardfinhq/terraform-aws-tailscale-subnet-router/pull/7, though. This was my first time using Terraform (hope to do a lot more!) so I'm not too familiar how these things are supposed to be set up, but the changeset here seemed to get things working for me. Let me know if there are any problems.

@kevincupp I just tagged a release v1.20230306.1 that you can pin to

https://github.com/hardfinhq/terraform-aws-tailscale-subnet-router/releases/tag/v1.20230306.1
https://registry.terraform.io/modules/hardfinhq/tailscale-subnet-router/aws/1.20230306.1


Baseline: EncT5

I would be happy to contribute on this one which seems great to start with !
Don't hesitate to tell me if I'm going the wrong way:

We would add an extra argument namely T5 to the function build_model of glue.py script and create a dedicated t5_module.create_t5_classification.

I have found a reference code available at t5-fine-tuning, would it be consistent with building a Baseline EnCT5?

Hey @raphaelsty ! Yes, @NohTow is correct, this is about setting up baselines with only the Encoder + the EncT5 recipe for:

PileT5-base
T51.1-large (there's an unknown issue with PileT5-large where it performs surprisingly weakly)
PileT5-XL
To serve as a very strong comparison point for our own base/large/XL variants.


Kernel symbolication fixes

This PR introduces three changes:

Calling the Kernel symbolizer (and the user function symboliser for JITs), which got lost in https://github.com/parca-dev/parca-agent/pull/663
Dealing with unsorted /proc/kallsyms
Skipping symbols with a non-code (.text) type

More details can be found in the respective commit messages
Test plan
Before these changes

After these changes

Added multiple tests for the Kernel symboliser fixes.

Run e2e tests

@javierhonduco Let me know when you're done, so that I can approve it.


Unbreak build on FreeBSD

Was fixed on FreeBSD side (since 13.0, 12.2, 11.5).
https://github.com/freebsd/freebsd/commit/af43194a69251afdb621f7fef4f1b87613f1a96c


Yahoo Finance query failure

As reported Yahoo finance error since v0.30.1.
Home Assistant release (hass --version):
0.31.0.dev0
Python release (python3 --version):
Python 3.5.1
Component/platform:
sensor.yahoo_finance
Description of problem:
Query failed with error: "'No definition found for Table yahoo.finance.quotes'".
Expected:
Data retrieval.
Problem-relevant configuration.yaml entries and steps to reproduce:
sensor:
  - platform: yahoo_finance
    name: Red Hat Inc.
    symbol: RHT
  - platform: yahoo_finance
    name: Google
    symbol: GOOGL
  - platform: yahoo_finance
    name: Yahoo
    symbol: YHOO

Traceback (if applicable):
16-10-10 21:07:51 ERROR (Thread-1) [homeassistant.components.sensor] Error while setting up platform yahoo_finance
Traceback (most recent call last):
  File "/home/fab/Documents/repos/home-assistant/lib64/python3.5/site-packages/yahoo_finance/__init__.py", line 120, in _request
    _, results = response['query']['results'].popitem()
KeyError: 'query'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/fab/Documents/repos/home-assistant/homeassistant/helpers/entity_component.py", line 107, in _setup_platform
[...]
packages/yahoo_finance/__init__.py", line 123, in _request
    raise YQLQueryError(response['error']['description'])
yahoo_finance.YQLQueryError: Query failed with error: "'No definition found for Table yahoo.finance.quotes'".

CC @tchellomello

@fabaff  thanks for the heads up. It seems to be an issue with Yahoo API.  It is also reported at https://github.com/lukaszbanasiak/yahoo-finance/issues/72
I've already opened a ticket with Yahoo. Thanks for filling this issue.

Several issues has been reported to Yahoo API about this problem.
https://forums.developer.yahoo.net/discussion/10308/finance-quotes-returning-bad-request#latest
https://forums.developer.yahoo.net/discussion/10403/yahoo-finance-quotes-is-unstable-description-no-definition-found-for-table-yahoo-finance-quote#latest
Currently waiting to hear from Yahoo. The issue can be reproducer directly on their Yahoo YQL webconsole as reported at https://forums.developer.yahoo.net/discussion/10403/yahoo-finance-quotes-is-unstable-description-no-definition-found-for-table-yahoo-finance-quote#latest

It seems that Yahoo fixed the issue with their API servers.  I'm still observing it but I have been running it for a day already without any issues.
Let's keep it open for a few more days and I'll post back here.

@fabaff  I think we can close this issue. Yahoo API has been working for 2 days without issues. On Yahoo community forum, people confirmed it is working for them as well.

Very well. Thanks for get to the bottom of this.


Set correct size for terminal which fixes text wrapping.

Sometimes it was going off the sides/bottom.
Fixes #765

LGTM


[Bug Report]: yarn create-farm not found

Steps to reproduce
After executing the command:
yarn create farm@latest
installs the framework but when trying to use it it gives the following error:

Reproduce link
No response
What is actually happening?
Can't create project using yarn
System Info
System:
    OS: Linux 5.15 Linux Mint 21.3 (Virginia)
    CPU: (4) x64 Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
    Memory: 3.52 GB / 7.71 GB
    Container: Yes
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 20.15.0 - ~/.nvm/versions/node/v20.15.0/bin/node
    Yarn: 1.22.22 - /usr/bin/yarn
    npm: 10.7.0 - ~/.nvm/versions/node/v20.15.0/bin/npm
    bun: 1.0.30 - ~/.bun/bin/bun
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 126.0.6478.182
  npmPackages:
    @farmfe/core: ^1.3.0 => 1.3.3

Use yarn create farm instead.

Hi, I tried yarn create farm@latest on my local machine and it worked:

I found that it seems you're using<EMAIL_ADDRESS>maybe you should try to upgrade your yarn to the latest version. I think this is not a bug of farm so I'll close this issue. Feel free to comment here later if more issues happened :)

You are right, but there was a problem that I encountered when trying to update the version of Yarn.
We intentionally don't release modern releases on the npm yarn package, so as not to break older projects which didn't migrate yet.
Complete information: https://yarnpkg.com/blog/release/4.0#installing-yarn
To update to the latest version of YARN, use the script I found: https://gist.github.com/wojtekmaj/c38351dd715c1b108ab1ab089fcaf6fc
Avoiding the "git add..." part, everything worked perfectly. Thank you


[TINY] Fix to #3464 - StringCompareExpression throws 100% of the times

StringCompareExpression was missing Type property overload.

@anpete

:shipit:


Microsoft hosted agent builds are failing on macos-latest 20210314.1

Description
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CheckTokenMembership. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
Area for Triage:
Apple
Bug:
Virtual environments affected

[ ] Ubuntu 16.04
[ ] Ubuntu 18.04
[ ] Ubuntu 20.04
[* ] macOS 10.15
[ ] macOS 11.0
[ ] Windows Server 2016 R2
[ ] Windows Server 2019

Image version

Image version where you are experiencing the issue.
20210314.1
was passing till the image 20210307.1
Expected behavior
build to be passed
Actual behavior
failing cos of below error
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CheckTokenMembership. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CloseHandle. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _DuplicateHandle. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _DuplicateTokenEx. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _GetCurrentProcess. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _GetCurrentThread. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _GetTokenInformation. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _ImpersonateLoggedOnUser. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _LocalAlloc. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _LocalFree. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _LsaClose. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _LsaFreeMemory. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _LsaFreeReturnBuffer. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _LsaGetLogonSessionData. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _LsaLookupNames2. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _LsaLookupSids. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _LsaOpenPolicy. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _OpenProcessToken. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _OpenThreadToken. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _RevertToSelf. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _RtlNtStatusToDosError. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
MTOUCH : error MT5202: Native linking failed. Please review the build log. [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]
clang : error : linker command failed with exit code 1 (use -v to see invocation) [/Users/runner/work/1/s/Source/ProarcMobile.iOS/ProarcMobile.iOS.csproj]

is it possible to specify a specific image version similar to choosing the image label in the yaml file

Hello @keerthinathganjam. Thank you for your report. Could you please provide us minimal repro steps to speed up investigation process?

Hello @keerthinathganjam. Thank you for your report. Could you please provide us minimal repro steps to speed up investigation process?

Is it possible to specify a particular image to be used?
Example, 20210307.1

@JRallee it's not possible to choose image version.

Hello @keerthinathganjam.
As @catthehacker mentioned before you cannot choose a specific image version in your yaml file.
Previously we've updated our Xamarin iOS from 14.10 to 14.14 version. Most likely, this may have affected your builds. To see available Xamarin versions follow to our toolset for macOS 10.15.
You can try the previous Xamarin tools bundle with symlink 6_12_6 (contains Xamarin iOS 14.10) by running this command:
/bin/bash -c "sudo $AGENT_HOMEDIRECTORY/scripts/select-xamarin-sdk.sh 6_12_6"

Mentioned in this documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#xamarin
Please let us know if you have any questions.

Thanks @nikita-bykov  this solved our issue, i had tried this earlier but coudnt get to the exact version no you mentioned, is there any documentation to know which version of xamarin sdk we need to use for which version of xamarin iOS

Unfortunately, there is no such documentation now, but soon we will update our documentation for Xamarin to be more informative. I'll close this issue, but if you have any questions, feel free to ask us.
Thank you @keerthinathganjam!


Project Details

[x] Product Details
[x] Language Details
[x] Sprint Details
[x] Team Details
[x] #15

Project Details.pdf


Relocate chart type and dataset type defaults

Spinoff from discussion around #8536
The proposal (@simonbrunel ):
config: {
  options: {
    datasets[dataset_type]
    plugins[plugin_type]
  }
}
Chart.overrides: {
  [chart_type]: {
    datasets[dataset_type]
    plugins[plugin_type]
  }
}
Chart.defaults: {
  datasets[dataset_type]
  plugins[plugin_type]
}

The chart type defaults are moved from Chart.defaults.controllers[type] to Chart.overrides[type]
The dataset type defaults are moved from Chart.defaults.controllers[type].dataset to Chart.defaults.datasets[type]

This simplifies the fallback logic and adds another advanced configuration dimension, for overriding dataset type defaults per chart type. So you could set defaults for a line dataset in a bar chart, for example.
TODO:

[x] update types
[x] separate overrides from defaults (descriptors too while at it?)
[x] derived chart type sample

* The chart type defaults are moved from `Chart.defaults.controllers[type]` to `Chart.overrides[type]`

@kurkle just for my understanding, Chart.defaults.controllers[type] doesn't exist anymore, doesn't it?

* The chart type defaults are moved from `Chart.defaults.controllers[type]` to `Chart.overrides[type]`

@kurkle just for my understanding, Chart.defaults.controllers[type] doesn't exist anymore, doesn't it?

It still does exist, but would not if this gets merged.

I'm hesitant about the concept of chart_type. Mixed charts were hard to get working for awhile, but seem to work better as we've moved more stuff to dataset types. The example of setting different defaults for a line dataset in a bar chart sounds like it could add confusion. What's the use case that we need this for?

@benmccann I don't think the chart_type would be a new concept, many things come solely from the config.type (aka chart_type). This would make clear what those things are and at the same time extend the configuration possibilities.

Filename
Size
Change

dist/chart.esm.js
65.8 kB
+18 B (0%)

dist/chart.js
83.4 kB
-27 B (0%)

dist/chart.min.js
59.5 kB
+101 B (0%)

dist/chunks/helpers.segment.js
18.7 kB
-26 B (0%)

dist/helpers.esm.js
1.07 kB
-1 B (0%)

My memory is a bit fuzzy. What are the things that come from the chart type today?

Plugin options, aspectRatio etc things, that can not be changed per dataset. Scale options, but that one is considered by the dataset types.


Add remove text icon when search bar is not empty

I can handle this one.

Do you have any specific icon that you want to use for it? @aykutkardas

You can use the x-circle icon in Heroicons Outline.
https://svgps.app/store/heroicons/outline/


The working notes tab should exclude published working notes

In production we'll start having a "Riffs" section which are published working-notes (and has a tab that has a start_card of 'about-riffs')
So we don't want duplicate cards showing up in Working Notes and the Riffs sections for non editors, so we want to add unpublished to the default working notes tab.
But the published/unpublished filter is also an auto TODO which means that it bails early for cards that aren't content cards.

Can CARD_FILTER_FUNCS just use the naked filter func and not use makeBasicCardFilterFunc? ... But also when does does-not-need-to-be-published (or any of the needs-todo does-not-need-todo) filters get set?

[ ] Make 'unpublished' a constant

29a693e wasn't right behavior, because now working-notes that aren't published also match published even though they shouldn't. (What happened before?)

The config on Mac Pro needs to be switched to start_cards = ['about-riffs'] and fix the published/unppublsiihed thing in the comment above.
(Should we make it so hideIfEmpty can be true even if count is not?)


Case guide

Adding a basic build guide for Thomas' case

I also created this gist, which has some useful info on making a miryoku keymap using vial with the standard firmware:
https://gist.github.com/glennmca-dev/ddddcafe46dd1e2e36ed853bf55077e3

Hey, this is great! Thank you very much!
P.S. Your build turned out great.

Thanks Tom! I'm very happy with it now that i have some decent keycaps :)


ESP Record voice by vs1053

Hello,
According to your shematic, i have an wierd esp wroom and vs1053 mudule (geeethec) , then use your esp radio code (that is great and useful source code) , it works fine.
You wrote a comment on your code about start up modules in midi mode , i have to change PGIO DDR and ODATA for record voice?
I am trying to record voice  but i have a problem . Dreq pin gone low when start to record.
At the first, in my code :
cs pin ==> HIGH
dcs pin==> HIGH
dreq pin define as an INPUT
SPISettings => 250000, MSBFIRST, SPI_MODE0
and then soft reset (SCI_MODE= SM_SDINEW | SM_RESET)
Now, SCI_STATUS register equals 72 (0010 1010). Sine Test is OK,
record initiation :
SCI_CLOCKF = 0xC000 // set max clock
wait for rising DREQ pin
SCI_BASS = 0 // clear Bass
SCI_MODE= SM_SDINEW | SM_RESET // soft reset
wait for rising DREQ pin
SCI_WRAMADDR =0xC01A
SCI_WRAM = 0x02
SCI_AICTRL0= 1024
SCI_AICTRL1= 1024
SCI_AICTRL2= 0
SCI_AICTRL3= 0;
loadPlugin...
Active
SCI_MODE = SM_ADPCM | SM_SDINEW
SCI_AIADDR = 0x34
wait for rising DREQ pin ==> INFINITY LOOP, because the DREQ pin stay down.
I can not find my mistake , If is possible guide me, Thanks

I did some experimenting with recording (ogg-format).  Not with the best results....  You can examine my code on http://smallenburg.nl/Ogg-encoder.zip.
Note that you have to supply a file for your WiFi SSID containing the password, for example SSID.pw.

At line 18, you specifies "Pin to program". What does that mean? What is hooked on those pins?

It is the pinnumber that you use in the sketch to address the pin.  Note the issue I mentioned at the top of the Ogg-encoder sketch: "Sometimes the conversion will not start"....
GPIO[0] and GPIO[1] are being set to LOW in the sketch.

So it basically, it's the same pin out then the Radio-player, except for Xrst that is set to pin 3, instead of the reset pin of the ESP8266.

Could be, this is a different project, so the pin configuration and software will differ.

Before I buy another VS1053, tel me will this broadcaster project, the zip file you just sent, and the radio project connect and play along together?

Yes, I had it working for a while.  But it was not very reliable.  I think it will be a challenge to get it working.

Well ok then, it will be part of my late xMass shopping. Thank you Ed


fix: adjust some fields sort in tables

Summary
fix: adjust some fields sort in tables
Does this close any open issues?
Closes xx
Screenshots

Other Information
Any other information that is important to this PR.


ARROW-17117: [C++] Add timestamp column datatype support for AsOfJoin

Previously, AsOfJoin only supported int64 as it's on column. Here, we add support for arrow::timestamp(TimeUnit::NANO, "UTC").
If there is a more generalized way of dealing with particular timestamps, please let me know!

@icexelloss , yeah I was hoping it would be easier. I think we would really only need a way to tell if a data type is a timestamp at runtime, and we should be able to supply this information to TimestampBuilder.
Worst case scenario, we can enumerate over all possible timestamps (one for each time unit and timezone we'd like to support), but I don't think this is a good solution.

Do we want to do the enumeration, or is supporting this one timestamp (Nanosecond, UTC) okay for now?

@icexelloss I adjusted DoRunBasicTest to run with the same data, but with the timestamp as the time column data type in the schema. Is there anything additional that might interesting to test?

Let's close this PR. Will pick up and do a new one.

Do we want to do the enumeration, or is supporting this one timestamp (Nanosecond, UTC) okay for now?

It would probably be best to support temporal, integer and perhaps(?) float types.

Let's close this PR since this is the last week of Ivan's internship. Will pick this up and open a new one.

Nice work @iChauster!
Feel free to ping me on the new PR @icexelloss.


Aggregate dependencies updates

Overview

Definition of Done

[x] There are no TODOs left in the code
[x] Changelog is updated if needed (in case of notable or breaking changes)
[ ] The continuous integration build passes

Coverage remained the same at 85.761% when pulling d7b464a22b6348b96a4ab2b3abb8b8fb8652e13d on dmitry-timofeev:update-dependencies into 941a2783f00adbc0720c58d431ffddd2f48f9547 on exonum:master.


Update sbt-scalafmt to 2.4.5

Updates org.scalameta:sbt-scalafmt from 2.4.4 to 2.4.5.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (2.4.4).
You might want to review and update them manually.
docs/website/package-lock.json

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "sbt-scalafmt" } ]

labels: sbt-plugin-update, early-semver-patch, semver-spec-patch, old-version-remains

Codecov Report

Merging #590 (038388b) into release/next (d27b10b) will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff              @@
##           release/next     #590   +/-   ##
=============================================
  Coverage         58.52%   58.52%
=============================================
  Files                60       60
  Lines              1379     1379
  Branches             54       54
=============================================
  Hits                807      807
  Misses              572      572

Continue to review full report at Codecov.

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

🚀🚀🚀 Benchmark Results
Concurrency: 256
Requests/sec: 428168.80


After reorg Last payments are not removed

but they disapear on after Liana restart

Even when you leave home and come back? Surprising.
-------- Original Message --------
On 9/4/24 1:30 PM, pythcoiner  wrote:

image.png (view on web)
but they disapear on after Liana restart
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

i think it's because we keep the states of each panel

Ah, then it's a newly introduced bug in the gui. I was surprised cause i did remember testing this last year.
-------- Original Message --------
On 9/4/24 1:45 PM, pythcoiner  wrote:

i think it's because we keep the states of each panel
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

i guess introduced in #959

It stays even if you click again on the panel title or if you leave home and come back ?

yes


Add trufflehog workflow to secret scan

Fixes #296

Couple of comments guys: -

Should we pin to a version (instead of main).
Does this replace all GitLeaks functionality and if so are we killing that off as part of another PR?
This would ace as a pre-commit but you've probably already started on that.

I think pinning to main/latest here makes sense because we're always going to benefit from the latest updates from upstream trufflehog repo whereas if we pin to a version we risk falling behind or introduce a need to keep updating over time.
We could remove Gitleaks from the workflow. In practice I've seen trufflehog and git leaks pick up on different things so it may be worth keeping both for now?
As mentioned, pre-commit hook won't work because trufflehog scans the git commit history for leaks rather than the staged files of a commit, so we've introduced a pre-push hook to scan all commits before they are pushed up to Github. The pipeline check should remain in case someone tries to bypass the pre-push hook.

I think pinning to main/latest here makes sense because we're always going to benefit from the latest updates from upstream trufflehog repo whereas if we pin to a version we risk falling behind or introduce a need to keep updating over time.

I would counter that slightly @samiwelthomasHO in that we have chosen to pin the versions of all dependencies to avoid any breaking changes to builds. Dependabot picks up any new releases to published GitHub Actions.


how to get mask in production

Does this model also require a handwritten text detection model to generate mask?

yes, it requires text bounding boxes.
jackson @.***> 于2024年7月30日周二 18:57写道：

Does this model also require a handwritten text detection model to
generate mask?
—
Reply to this email directly, view it on GitHub
https://github.com/lcy0604/CTRNet/issues/17, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ7RD3TAUK6U3ZXVDT6Q7VDZO5WRBAVCNFSM6AAAAABLWDRDJKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQZTONJUGA4TSMQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


More examples

Hello,
I have seen that on the TODO list "more examples" is noted. I'm currently learning Pyimgui and writing my own executable examples. I would add these to your project, but I wanted to ask if you want to have several small examples containing different things, OR a "fully translated" version of the ImGui demo into Python/Pyimgui ?

I'll rewrite the ImGui demo window into Python/Pyimgui (as much as possible so far) and add it to the examples.

Sorry for the delay. We can of course rewrite the whole demo window but IMO the best would be small examples that show basic concepts of Imgui like how to handle widget changes an state. Useful would be also some examples that show how to effectively use flags or the examples that show some pitfalls like reusing same ids for different widgets.

OK will be done. I've already noticed the trap with "multiple use same ID" ^^.


Make it easier to use the DSL with Facts of different types in a RuleBook

If you are using POJO Rules, this is a non-issue. But if you are using the Java DSL, then mixing types of Facts is cumbersome since generics suppose all Facts are of the same type.
This should be an easier thing to do. I'm thinking that a RuleBook can be of an unspecified type and then Rules of any type can be added. Facts of all types would be chained across Rules. But only Facts of the type of the Rule would be available in the When and Predicate, still keeping the lambda syntax pretty streamlined.

I think this is going in with v0.4 as part of the DSL updates. This is really done except for some needed refactoring
In terms of the refactoring, I am looking to converge the functionality between StandardDecision and StandardRule. I'm thinking StandardDecision will probably end up being a decorator for StandardRule.


Failed to read stdout: read |0: file already closed

I've updated to the latest version of gleam with cleanup code added, but now I always get one less item in my reducer. Not sure it is related to the cleanup yet, I get something suspicious from the log:
2017/09/02 23:53:42 sendExecutionRequest stream receive: rpc error: code = Unknown desc = Failed to read stdout: read |0: file already closed

added a fix for this particular error.
but "one less item" is not reproducible.

I've updated to the latest version of gleam and rebuilt, this error seems persist.
2017/09/04 10:35:07 sendExecutionRequest 2:28-3:28-4:28 stream from ##.##.51.16:45327: rpc error: code = Unknown desc = Failed to read stdout: read |0: file already closed

If you need more information, please let me know.


'type' attribute

When building rosters of dwarfs I get:
Warning: <class 'dmsky.targets.Dwarf'> does not have attribute type

I think we should be popping type here


supercharged-dhbw:3.3.1

I am submitting

[ ] a new package
[x] an update for a package

Description

Fix expect company attribute in author if at-university is true (https://github.com/DannySeidel/typst-dhbw-template/pull/16)

I have read and followed the submission guidelines and, in particular, I

[x] selected a name that isn't the most obvious or canonical name for what the package does
[x] added a typst.toml file with all required keys
[x] added a README.md with documentation for my package
[x] have chosen a license and added a LICENSE file or linked one in my README.md
[x] tested my package locally on my system and it worked
[x] excluded PDFs or README images, if any, but not the LICENSE

[x] ensured that my package is licensed such that users can use and distribute the contents of its template directory without restriction, after modifying them through normal use.

Hi @elegaanz,
the package check failed, suggesting I exclude the files in the examples folder, which I already did with examples/**.
Could it be possible that the package check does not recognize the wildcard to exclude all contents in the folder?

Yes this seems to be a false positive, I'll fix the bug. And thank you for the package update :)


Possible idea

I am a longtime LXC/LXD user.
I've used many different Mesh VPN solutions (vpncloud, nebula, wireguard etc)
All are relatively complex to configure or update which hinders adoption.
Recently, I found Hyprspace:
https://github.com/hyprspace/hyprspace
This is unique because you don't have to configure or add anything to the LXD Host.
Install Hyprspace in any/all LXD containers local or remote.
Edit each LXD container's /etc/hyprspace/hyprspace.yaml (see the GitHub README.md) and change the IP
(10.x.x.x, 172.16.x.x or 192.168.x.x)
In the PEER section of each YAML add the:
ID & IP from the Hyprspace YAML of some local/remote LXD container's Hyprspace YAML you want "this" LXD Container to PEER with.
In each YAML's peer section, add as many PEERS as you want.
Obviously, you could automate much of this configuration in lots of ways.
cloud-init, Ansible etc etc
When you execute the command to bring up each Container's Hyprspace Interface...
All LXD containers will connect using the Hyprspace IP network you assigned in each YAML.
Connection usually takes 20-60sec
Afterwards, each local/remote LXD Container will be directly interconnected in a fully encrypted MESH VPN.

Anyway wanted to fyi you in case it helps your project.
A closely similar project to Hyprspace architecturally (IPFS, DHT, libp2p) but which also has an API so it can be integrated is EDGEVPN:
https://github.com/mudler/edgevpn
Brian

Thanks, but I am currently not planning to continue this project, I don't have any use case for it.
I did a few test runs, it worked well, however, I don't have any HA applications as of right now that need that uptime.
I rather trust wireguard with the vpn stuff, already made tools for it but thanks, good to know that this stuff exists.


Fail to paste one empty emulator blob container to one storage account

Storage Explorer Version: 1.24.0-dev
Build Number: 20220316.1
Branch: main
Platform/OS: Windows 10
Architecture: ia32
Azurite Version: 3.15.0
How Found: From running test cases
Regression From: Previous release (1.23.0)
Steps to Reproduce

Install and run Azurite 3.15.0 -> Launch Storage Explorer.
Expand 'Local & Attached -> Storage Accounts -> (Emulator - Default Ports) (Key)' -> Blob Containers.
Create one blob container -> Right click the blob container -> Click "Copy Blob Container'.
Expand one storage account.
Right click Blob Containers node -> Click 'Paste Blob Container'.
Check whether succeeds to paste the blob container.

Expected Experience
Succeed to paste the blob container.

Actual Experience
Fail to paste the blob container.

Additional Context
This issue doesn't reproduce for tables.

I tried it on my machine with Azurite 3.15.0 and the most recent 1.24.0 dev build and it doesn't reproduce. Could you try to get a fiddler trace for the failed creation request?

@JasonYeMSFT , this issue still reproduces on the lasted build, but I have no way to get the fiddler trace.
Here is the record:

I found the cause of it. The problem is that Azurite doesn't recognize the new API version 2021-04-10, which is the default API version of the new SDK package. Given that this scenario is not common, I am going to close this issue. If any major scenarios of the Emulator is broken in the same way, we will add some special logic to fallback to a lower API version for Emulator.
Checked normal Emulator scenarios. We detect if the target resource is from an emulator by its default key credentials and override the api version if so. Since the copy src only has SAS credential, it cannot be detected and won't work. This seems to only impact copy and I think we can close this one for now.


Node JS SDK NPM Run start Error

When install Node JS SDK, I encounter an error.
Steps to reproduce:

In node folder, run npm install and fill the .env file.
Run npm run start or npx tsx src/index. It should return the following error

> start
> tsx src/index.ts

xxx\node_modules\elevenlabs\api\resources\pronunciationDictionary\client\Client.js:98
                        throw new errors.ElevenLabsError({
                              ^

ElevenLabsError: Status code: 400
Body: {
  "detail": {
    "status": "Unable to parse lexicon file",
    "message": "Unable to parse lexicon file. Lexicon file formatted incorrectly"
  }
}
    at PronunciationDictionary.<anonymous> xxx\node_modules\elevenlabs\api\resources\pronunciationDictionary\client\Client.js:98:31)
    at Generator.next (<anonymous>)
    at fulfilled (xxx\node_modules\elevenlabs\api\resources\pronunciationDictionary\client\Client.js:31:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  statusCode: 400,
  body: {
    detail: {
      status: 'Unable to parse lexicon file',
      message: 'Unable to parse lexicon file. Lexicon file formatted incorrectly'
    }
  }
}

Node.js v18.16.0

@cahyosubroto this looks like an issue with the lexicon file or the core API -- i'm going to close this issue since issues here are generally scoped to the TypeScript SDK!


⚠ Bofrost.de has degraded performance

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

HTTP code: 200
Response time: 2222 ms

Resolved: Bofrost.de performance has improved in 9937852 after 58 minutes.


Enable dbproxy for production

Pull Request Test Coverage Report for Build 3370

44 of 79 (55.7%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.04%) to 67.181%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/almond/platform.ts
3
4
75.0%

go/sql/mysql.go
39
73
53.42%

Totals

Change from base Build 3351:
-0.04%

Covered Lines:
7203

Relevant Lines:
10117

💛  - Coveralls


feat(scheduler): use /scale endpoints for RC and Deployments to only update replicas during scale events

Prior to this a full resource update was being done during a scale event, this could lead to potential pod template updates that were not desired
Fixes #1012

Current coverage is 87.10% (diff: 81.81%)

Merging #1029 into master will increase coverage by 0.03%

@@             master      #1029   diff @@
==========================================
  Files            41         42     +1
  Lines          3473       3491    +18
  Methods           0          0
  Messages          0          0
  Branches        579        580     +1
==========================================
+ Hits           3024       3041    +17
  Misses          293        293
- Partials        156        157     +1

Powered by Codecov. Last update 689df78...54cb968


YuNet incorrrect face landmarks

when the face is very close to the camera, it gives incorrect landmarks. here is the screenshot: https://ibb.co/VgttHnS
here is the correct one: https://ibb.co/vZwdTW0
it affects SFace's alignCrop and makes distance between two face features below threshold

This is limited by the training data and the training scheme. I cannot tell exactly the scale of your example image, but YuNet is trained to detect faces of pixels between around 10x10 to 300x300. Note that this is the face size, not the size of the whole image.

it occurs above 150px face size. tried using different type of webcam and still gives incorrect landmark at bigger face size. btw im using raspberry pi 4.  but strangely i dont find it incorrect landmarks using my laptop (thinkpad x230).

I think you need to somehow control the face size on your Raspberry PI 4 deployment. By the way, did you do the same test on your laptop using the same webcam and testing with the faces above 150 pixels?

I think you need to somehow control the face size on your Raspberry PI 4 deployment. By the way, did you do the same test on your laptop using the same webcam and testing with the faces above 150 pixels?

it turns out that the model used on the raspberry pi is the quantized version while on the laptop is not. tried using quantized on laptop and gives incorrect landmarks. i think the problem is solved..

Okay, thanks for the feedback. It turns out the quantized model needs to be optimized then.


Add support for run-script commands

My project has a bunch of them defined in the packages.json and I'm not able to execute them with the install command alone. https://docs.npmjs.com/cli/run-script. I'll fix it in my fork and create a PR.

@wvandrunen
A PR with your additional features will be greatly appreciated, as my initial use case for this addin was simply to execute client side build steps via gulp I focused on the install command.

@Philo @wvandrunen I've opened PR #6 to add basic run-script command support. Hopefully it works for you @wvandrunen ..


How to use it with unified manually?

In the doc, it only mentions how to use it with @next/mdx, but if I don't use @next/mdx, how should I do?
The following code is how I use it:
import { Octokit } from "octokit"
import rehypeAutolinkHeadings from "rehype-autolink-headings"
import rehypePrettyCode from "rehype-pretty-code"
import rehypeSlug from "rehype-slug"
import rehypeStringify from "rehype-stringify"
import remarkGfm from "remark-gfm"
import remarkParse from "remark-parse"
import remarkRehype from "remark-rehype"
import { unified } from "unified"

const token = process.env.GITHUB_API_TOKEN ?? ""
const org = process.env.GITHUB_TARGET_ORG ?? ""
const repo = process.env.GITHUB_TARGET_REPO ?? ""

const sdk = new Octokit({ auth: token })

export async function getIssue(slug: string) {
  const res = await sdk.rest.issues.get({
    owner: org,
    repo,
    issue_number: Number(slug),
  })

  const processedContent = await unified()
    .use(remarkParse)
    .use(remarkGfm)
    .use(remarkRehype)
    .use(rehypeSlug)
    .use(rehypeAutolinkHeadings)
    .use(rehypePrettyCode, { theme: "one-dark-pro" })
    .use(rehypeStringify)
    .process(res.data.body ?? "")
  const htmlContent = String(processedContent)

  return {
    ...res.data,
    htmlContent,
  }
}

When I build it, it reports the following error:
./src/lib/github-issues.ts:42:10
Type error: Argument of type 'Plugin<[(Options | undefined)?] | void[], Root, string>' is not assignable to parameter of type 'Preset | PluggableList'.

  40 |     .use(rehypeAutolinkHeadings)
  41 |     .use(rehypePrettyCode, { theme: "one-dark-pro" })
> 42 |     .use(rehypeStringify)
     |          ^
  43 |     .process(res.data.body ?? "")
  44 |   const htmlContent = String(processedContent)
  45 |
 ELIFECYCLE  Command failed with exit code 1.

VS Code also report the same error:

Although this is a nextjs 13 app router project, but I don't use @next/mdx. It works fine if I replace the rehype-pretty-code by rehype-highlight or rehype-prism-plus.

Thank you!

I resort to ChatGPT, it inspires me, and then I make it work. I am astonished by ChatGPT!
work code:
  const processedContent = await unified()
    .use(remarkParse)
    .use(remarkGfm)
    .use(remarkRehype)
    .use(rehypeSlug)
    .use(rehypeAutolinkHeadings)
    .use([[rehypePrettyCode, { theme: "one-dark-pro" }]])
    .use(rehypeStringify)
    .process(res.data.body ?? "")

Conversation with ChatGPT: https://chat.openai.com/share/39425667-83e4-41e8-9205-9e3ef476f4ee

but it's weird, the original code works in dev mode, just can't pass the build, don't know why.
btw, I think maybe we can add this usage to the doc, it's helpful for users like me.

The types should be fixed in 0.9.7

Cool~
The original code I mean the code before I modified to use([[rehypePrettyCode, { theme: "one-dark-pro" }]]). aka the following code:
  const processedContent = await unified()
    .use(remarkParse)
    .use(remarkGfm)
    .use(remarkRehype)
    .use(rehypeSlug)
    .use(rehypeAutolinkHeadings)
    .use(rehypePrettyCode, { theme: "one-dark-pro" })
    .use(rehypeStringify)
    .process(res.data.body ?? "")
  const htmlContent = String(processedContent)

Although the VS Code reports the type error, and it fails when running npm build (aka next build), but it works with no error when I run npm dev (aka next dev).

Yeah I think it was because the types were wrong, but runtime is fine, so it failed when typechecking but not when running. Hopefully 0.9.7 work fine?

Get it, look forward the new version!

It's already published, you can test it out :D

It's already published, you can test it out :D

wow, so fast, just go back from vacation, will test it today!

works great, thanks for your work!


Win11 & SQL 2022 on Win2025

Win11 24h2 preview build
Using n2d for Win11 22h2-24h2 and support OS level machine family decision
SQL 2022 on Windows Server 2025 Preview

/lgtm


Extending further

I resolved an issue I was facing with using https://github.com/Sewdn/meteor-collection-behaviours. This library uses the wrapCollection() function a second time, which in Meteor 1.6.1 leads to discarding the extended version meteor-collection-hooks applies. My changes ensure that when creating a collection, the version in meteor-collection-behaviours will call the version in meteor-collection-hooks as well.

OK. So this PR is fixing two things.
The first is not related to Meteor version 1.6.1, it is related to lai:collection-extensions trying to use same variable name for storing the old constructor as collection-hooks, so they conflict with each other. Anyone using both packages (collection-extensions and collection-hooks) will have the problem of hooks not running because of this.
You fixed this by using a different variable in collection_hooks now. This solves the issue. (Another solution would have been using lai:collection-extensions for wrapping, as was the plan for quite some time, but it did not happen for some reason, so there is now an exact duplicate of the wrapping code in the two packages, using the same variable names -> causing the problem)
The other issue that this PR is solving is to be able to call Mongo.Constructor without "new", which is a Meteor 1.6.1 related thing indeed. I'm not sure if later meteor patches fixed this already?
But the first problem needs fixing badly for many of us. Can that be pulled into master? Otherwise no one can use collection-hooks together with any other package using collection-extensions at the same time.


test: proxy test against k81 layer

Not includes: kubectl edit, flipping around summary and raw tabs
Continue with #2184
Signed-off-by: Mengting Yan<EMAIL_ADDRESS>
Description of what you did:

My PR is a:

[ ] 💥 Breaking change
[ ] 🐛 Bug fix
[x] 💅 Enhancement
[ ] 🚀 New feature

Please confirm that your PR fulfills these requirements

[x] Multiple commits are squashed into one commit.
[x] The commit message follows Conventional Commits, which allows us to autogenerate release notes; e.g. fix(plugins/plugin-k8s): fixed annoying bugs
[x] All npm dependencies are pinned.

covered by #2390


UX Scenario to consider

Description:
When a user accesses the analytics  some may want to by default view "My APIs" first rather than "All APIs" but some may want the current view. Can we have a way for the users to configure this for their products so that they dont want to allways click on "MyAPIs" for each analytics graph.
This way we can improve the User experience and cater based on the customer needs.

This is improved in 3.2.0 onwards by restricting dashboards to business analytics and API analytics. It provide a separate view for API owners and Others.
Hence closing.


Bump github.com/AzureAD/microsoft-authentication-library-for-go to v1.2.2

Issue: #45077

Problem

While migrating away from the old Azure SDK, it was discovered that github.com/AzureAD/microsoft-authentication-library-for-go was pinned to an older version which caused build errors when importing the azidentity package.
Solution

Bumped github.com/AzureAD/microsoft-authentication-library-for-go to v1.2.2 and migrated code as per https://github.com/AzureAD/microsoft-authentication-library-for-go/issues/380. This allows us to import azidentity without any issues.
Testing

Engineering Testing
Manual Testing

Automated Testing

Test types added/modified:

None

If "None" - Reason: No application logic is modified by this change (refactoring).

If "None" - GH Issue/PR: LINK TO GH ISSUE/PR TO ADD TESTS

Summary: TODO
QA Testing Considerations

Use Azure AD as the auth provider in Rancher. Ensure that after token expires (after 1h) and a new token is being issued, the user remains logged in and no errors occur.

Regressions Considerations

TODO
Existing / newly added automated tests that provide evidence there are no regressions:

TODO

PR approved from security point of view, but we also need someone from the Auth to review it too, please.


setResolution doesn't call SHT2x_WRITE_USER_REGISTER

I haven't checked the SHTx datasheet, but in the function setResolution, when calling writeCmd, the command used is SHT2x_READ_USER_REGISTER:
https://github.com/RobTillaart/SHT2x/blob/71a1d9433f4595f74732c355119cdfbdc8bd314e/SHT2x.cpp#L480
Shouldn't it be SHT2x_WRITE_USER_REGISTER?
Also, this SHT2x_WRITE_USER_REGISTER compiler definition is not used anywhere in the code.
A bit weird.

Thanks for the issue. I will dive into it asap, might take some days.

There is a (long open) issue with the resolution #13
It could be related. As I have not investigated that yet l cannot say for sure. Finally  I do not have such sensor available for testing  (no excuse, but it does not help either).
That said, you might have pinpointed the cause.

Had a look and indeed the SHT2x_WRITE_USER_REGISTER should be used in both setResolution() and some heater functions.
I will create a develop branch + PR asap.
Are you able to test that branch?

Created the develop branch + PR https://github.com/RobTillaart/SHT2x/pull/19

Thank you for your fast response!

Finally I do not have such sensor available for testing
You should test all your library updates with the proper hardware.
Doing blind updates is never a good idea for open-source, especially in communities like Arduino where people are using libraries to avoid understanding too much of the underlying hardware.

Thank you for your fast response!

You should test all your library updates with the proper hardware.
Doing blind updates is never a good idea for open-source, especially in communities like Arduino ...

I know,
you are 100 % right, also not a good idea in closed source, never,
However, I have about 200 libraries written (partly on request) and for most of them I have bought the hardware to test but not for all (for various reasons). For this library I don't have the hardware, so in the readme.md file is a disclaimer. Same is true for all different boards, there are hundreds of them with sometimes minor differences, and I only have a few to test.
(not an excuse, just reality)

Otherwise do not hesitate to ask questions, especially with a well done analysis/diagnosis - appreciated 👍


Update the README file

The cobbler's children have no shoes. I need to add some useful information to the README, such as:

[x] Link to the fully built, hosted documentation (pending some kind of resolution to issue #2)
[ ] Local build directions (i.e., install dependencies and run make html)
[x] Author(s) information
[x] License information (pending issue #1)

@ddbeck


Is it still needed with Glimmer 2 and Ember 2.12?

Is it still needed with Glimmer 2 and Ember 2.12?

Yes. What makes you think it wouldn't be?

href-to is only useful if performance is a concern for your app. If you don't have many links, link-to is fine to use
As href-to does much less work than link-to, it is always going to be much faster than link-to. The router service is being implemented and it will bring a url-for helper which will remove the need for this addon, we'll work on deprecating href-to once it lands


I think this annotation may be wrong

     """
     Calls either forward_train or forward_test depending on whether
     return_loss=True. Note this setting will change the expected inputs.
     When `return_loss=False`, img and img_meta are single-nested (i.e.
     Tensor and List[dict]), and when `resturn_loss=True`, img and img_meta
     should be double nested (i.e.  List[Tensor], List[List[dict]]), with
     the outer list indicating test time augmentations.
     """

I think you just write the opposite. It should be:
When return_loss=True,  img and img_meta are single-nested .
when resturn_loss=False, img and img_meta should be double nested
Yours

Yes you are right, a PR is welcome.


fix some assets

Does this fix #84?

Looks great, but I'll undo the changes to the Dualshock face buttons in the bedrock resource pack, as with your changes they don't look like the Bedrock Edition equivalents anymore


Is XTAE (Tel Aviv) start time wrong?

Is XTAE (Tel Aviv) start time wrong? Simple fix but I wanted to allow discussion first.
~Official start time~ Official start time is randomly between 9:59 and 10:00 ; end time randomly between 17:14 and 17.15. The last change to trading times acknowledges this, but decision process for which times are chosen not consistent. I'd expect either 9:59->17:15 or 10->17.14 to be chosen (ideally the wider range), but instead a hybrid is used: 10->17:15
Any reason why I shouldn't change the start time to 9:59?

Haven't come across an exchange that does this before.
Thinking in terms of trading minutes, if during regular trading a trade can be placed between 09:59 and 10.00 then this minute should be represented, same for 17:14 to 17.15.
So I agree with @ValueRaider, 09:59 -> 17.15.

Yep - agreed here, thanks for catching that.

Fixed in #247.


Add network-health-max-send-fail-rate flag.

Closing in favor of https://github.com/ava-labs/avash/pull/141


opae: cherry pick release 1.3.2 changes to master

-Doc changes
-Metrics changes for Max10
-KW issues

Coverage decreased (-0.2%) to 80.993% when pulling 0b1a389f0254a1cd9cb8a7f7d90a5393009ba0bd on aravuri/cp_release_1.3.2 into 9146738f3fb72c7d797ae154ec2c35c63a54e928 on master.


agsGetCrossfireGPUCount() return incorrect result when running in Window Mode

Hi,
I'm trying to use agsGetCrossfireGPUCount() to examine the application if Crossfire is currently Enabled. In Windows mode, I cannot see AMD Crossfire Logo, which indicated that Crossfire Rendering Mode is OFF, however, agsGetCrossfireGPUCount() still return num_gpu > 1;
Actually, agsGetCrossfireGPUCount() return the same result regardless of running in Windows or Fullscreen, but Crossfire rendering seem to work only in Fullscreen.
Could you please advise? Are there any other functions I can use to examine Crossfire Rendering?
Thanks,
Wittawat K

Hi,
Crossfire is only active in exclusive fullscreen mode.  So if you are in a window, then the driver will not be doing AFR.
Something to also consider is that, by default, agsGetCrossfireGPUCount returns the number of Crossfire GPUs in your machine.  After calling agsDriverExtensionsDX11_Init, if the Crossfire API is active (check for the AGS_DX11_EXTENSION_CROSSFIRE_API flag) then the GPU count will be 2 if your app profile allows Crossfire, otherwise it will return 1.
For AGS v5.2, I'll be removing agsGetCrossfireGPUCount and returning you the Crossfire GPU count in the DX11 device creation call so that you don't get caught out by the order of the function calls.
cheers,
Gareth.

Now in 5.2


Does not run when scheduled?

Hi,
do you have an idea why the updater does not run when scheduled:
https://github.com/Squidex/squidex/actions/workflows/check-updates.yml
Seems that only manual runs actually work.

The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.

Reference:

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#scheduled-events
https://github.com/orgs/community/discussions/27130

There is a chance that the scheduled jobs may also be dropped if the load is high. I just tested this in one of my repositories. The first time it did not run the action at all and the second time it ran the action 5 minutes after the scheduled time.

I am closing this issue as this is not directly related to this GitHub Action. :)


Add a weapon system and use #equip to arm a weapon. Add a list of preset weapons.

automatically add to inventory if it's not present. Add to the list of weapons if it isn't there already. Use a setup dialog to determine the damage


fix llama3 tokenizer glitch

Fix llama3 tokenizer glitch  which leads to incorrect prompt truncation and answer extraction.
See Issue https://github.com/NVIDIA/RULER/issues/54#issuecomment-2543812514 for details

Thanks for finding this issue!


v0.2.5

None check in set_search_properties

Codecov Report

Merging #30 (43adcc0) into main (2d3bd84) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #30   +/-   ##
=======================================
  Coverage   70.40%   70.41%
=======================================
  Files          19       19
  Lines        3142     3143    +1
  Branches      611      611
=======================================
+ Hits         2212     2213    +1
- Misses        750      751    +1
+ Partials      180      179    -1

Flag
Coverage Δ

unittests
70.41% <100.00%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

flaml/searcher/blendsearch.py
85.34% <100.00%> (+0.92%)
:arrow_up:

flaml/version.py
100.00% <100.00%> (ø)

flaml/searcher/flow2.py
77.80% <0.00%> (-0.83%)
:arrow_down:

flaml/automl.py
79.50% <0.00%> (-0.15%)
:arrow_down:

flaml/model.py
84.10% <0.00%> (+0.57%)
:arrow_up:

Continue to review full report at Codecov.

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


ubuntu 22.04 otel-collector can't read /var/log

test read permissions for syslog:
sudo -u openobserve-agent test -r /var/log/syslog; echo $?
shove this into install.sh somewhere:
setfacl -R -m u:openobserve-agent:rx /var/log/
shove this into uninstall.sh somewhere:
setfacl -R -x u:openobserve-agent /var/log/
double check:
getfacl /var/log

Sorry, i didn't get what your mean?


Refactor ": nil" in ternary operators

This PR refactors some ": nil" in ternary operators according to #11955.

Actually it seems that there's no occurrence of this issue anymore, hehe. Closing this.


Replace precondition if with guard in NSNumber.encode.

Previously NSNumber.encode would call NSUnimplemented when you try to
do a keyed coding. Whilst it is true that this wasn't implemented it was
due to not being possible rather than not yet implemented.
With this patch we call preconditionFailure which is more consistent
with the rest of the project. We also use a guard so can remove a level of
indentation.

@swift-ci please test

LGTM. What do you think @ianpartridge @phausler ?

Yes I think this is fine. Thanks @oc243

@swift-ci please test and merge

Looks like an unrelated segfault:
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux/swift/utils/build-script-impl: line 261:  9831 Segmentation fault      (core dumped) "$@"
@swift-ci please test and merge


Extended methods for getting shared link of a file

Hey,
this is my first fork and pull request ever, I hope I am doing this right. I extended the DropBoxService for a method to create a share link (or get the link if it already exist) from DropBox. It can be used to publish files.
Usage could be e.g.:
def jsonResponse = dropBoxService.shares('pizza.jpg', dropBoxAccessToken)
def slurper = new JsonSlurper()
def result = slurper.parseText(jsonResponse)
def url = result.url
But this only gets the shurt_url. But I need to get the long url so that I can receive the raw image by adding "&raw=1" to the shared link. Is there a way I can add params to your methods? See https://www.dropbox.com/developers-v1/core/docs#shares for "short_url".
Thanks

Maybe instead of handing over only the access_token it would be nice to use a parameter map:
String shares(String path, Map params) {
return get("/shares/auto/${path}", params)
}
and
protected String get(String uri, Map params) {
    return new URL("${URL_ROOT}${uri}${encodeParams(params)}").text
}

then we could use it like that:
def jsonResponse = dropBoxService.shares('pizza.jpg', [access_token: dropBoxAccessToken, short_url: 'false'])
With every wanted param. And in encodeParams we should set the String delimiter = '?' then. But it is used in many lines yet. So I did not made the changes in git yet.
What do you think about it?

@mexx91 Yes you are right. We should hand over the params map instead of just an access_token. But my intention back then at time of creating DropBox plugin is to provide an elegant and easy solution to use all Dropbox APIs right into Grails.
That's why i didn't wanted user to handle the params map and things. But if things wants us to use params map instead of just access token to be returned then we'll do so as well.
Let me know your view about it i.e. what should be better etc.
Thanks, Hiten

@hitenpratap Thanks for merging. :) Yes I think it would be very nice to give the user the opportunity for params. I will do some changes and create a pull request again later on to do so. But I have not much time, so I will only extend some methods to handle params. But I will adapt the other ones, so that they keep working by putting the accesToken String into a Map: encodeParams([access_token: accessToken]) instead of the toQueryString() part.
Then you could review the code and decide what parts to take or what we need to optimize.
PS: At the moment I am only using this plugin in a prototype grails app, so I can not invest to much time by now.


Specification v1.0.0 - Requirement for Caching unclear

In the README description for NDLP, it is mentioned that the data which is provided as response by the individual services is not required to be real-time.
"The following performance criteria shall be kept:
- No real-time data required (Information to be taken from MWDI)
- Retrieval of the data at least once a day
- ...
"
In the diagrams, there is no mention of a local cache like for example an elastic-search instance.
Could you clarify if there is a requirement for local caching of MWDI data?

There is no local caching required in the NDLP.
It is passing the requests from NDL to MWDI and the responses vice versa.


Feature/delete host directive

I have written a simple directive to answer this GitHub issue.

I've ran into this behaviour many times. Nice solution.
Does this break other host directives applied to a component or directive?
And if so, there should probably be a big warning in the docs.


Add support for Promise

I wanted to add to publish.js so that if the included files dir will be mirrored into the output directory.
but that is a bit out of the scope of this PR
Example of output
./src/index.js
./src/Chat/index.js
./src/Api/index.js

Should come out as
./<dest dir>/index.d.ts
./<dest dir>/Chat/index.d.ts
./<dest dir>/Api/index.d.ts

I think that is a good change to make, though it would be nice to be in a separate PR. Currently it exports everything to a single *.d.ts so there may be other work related to tracking references that would need to happen for multi-file support.
Looking at the newest updates you put in now.

I already made it output multiple files. I just need to add the directory structure logic

JSDoc already calls the publish file multiple times for each js file. Just how you had the naming set up, it was just appending to the single types.d.ts file because there was no need to generate a new file. It was defaulting to types and because one existed it added to the end. I fixed where it gets the file name from, it will create a new file with the proper name, on every call jsdoc makes to the template.


Return value from writeRef and modifyRef

Preempted by purescript/purescript-st#4:
modifySTRef :: forall a h r. STRef h a -> (a -> a) -> Eff (st :: ST h | r) a
modifyRef   :: forall s   r.   Ref   s -> (s -> s) -> Eff (ref :: REF | r) Unit

In particular the current behavior of modifyRef' strangely returns an arbitrary value not what's stored.

strangely returns an arbitrary value not what's stored

Why is this strange?

Because the value returned doesn't necessarily correlate to the value passed? Can't that be accomplished with map instead of an extra argument? I assumed it wasn't implemented in ST for that reason?

But you've lost the ability to have the return value depend on the original value too.

I don't understand why that'd be desirable. I still have the value passed in. If I want it inside the Monad that sounds like liftEff or just extract the new value, combine it with the original, and pure. If there were a practical use case it wouldn't need FFI and should be added to ST.

Is there an example I can try? Its the shape of the function that looks out of place and could be achieved with combinations of functions.

How can you accomplish the equivalent of
increment <- modifyRef' ref \old -> { state: new, value: new - old }

main = do
  ref <- newRef 10
  diff <- dec' ref 100
  logShow diff -- 100 - 10 = 90
  diff <- dec ref 1000
  logShow diff -- 1000 - 100 = 900

dec ref new = do
  old <- readRef ref
  writeRef ref new
  pure (new - old)

dec' ref new = modifyRef' ref \old ->
  { state: new
  , value: new - old
  }

Is there a common problem that needs read/write in a single call? Could it at least be named better? I struggled through the example remembering what state and value mean. Should it not be added to ST?

Right, but you've basically implemented modifyRef' there. It's just a question of which one you consider more basic. Since they can both be implemented in terms of one another, I don't think there's a good reason to prefer one or the other. The current way is compatible with the Haskell IORef library.

Since the FFI is simpler the other way around could I switch which implements it and add it to ST?

atomicModifyIORef is an atomic operation in the sense of atomic updates.
I suspect this way round is faster, so I'd like to measure both before changing. What's the reason for changing?

Because I'm working on ST and it was different.

Discussed offline with the following conclusions:

modifyRef' should remain named as is and added to ST.
The record returned should have the shape { newValue, returnValue } for clarity.
Since either can be implemented in terms of the other let's give the more common use case less indirection.

I'm pasting my implementation of modifyRef' and generated code (with ES6 arrows for legibility) for discussion:
main = do
  ref <- newRef "Hello"
  let newValue = "World"
  greeting <- modifyRef' ref (\val -> { newValue, returnValue: val <> " " <> newValue })
  log greeting

modifyRef' ref f = do
  value <- readRef ref
  let t = f value
  writeRef ref t.newValue
  pure t.returnValue

var main = () => {
  var v = Control_Monad_Eff_Ref.newRef("Hello")();
  var v1 = modifyRef$prime(v)(val => ({
    newValue: "World",
    returnValue: val + (" " + "World")
  }))();
  return Control_Monad_Eff_Console.log(v1)();
};

var modifyRef$prime = ref => f => () => {
  var v = Control_Monad_Eff_Ref.readRef(ref)(); -- calls FFI
  var t = f(v);
  Control_Monad_Eff_Ref.writeRef(ref)(t.newValue)(); -- calls FFI
  return t.returnValue;
};

Hmm my implementation incurs a dependency on bind and pure. Switching back.


don't know how to install the news update

don't know if I'm dumb but I don't know how to install the news update

See the README.


VRchat Lag Spikes

Face tracking template uses _Do_Nothing state to be placeholder for write defaults to reset the animation to default. This works in Unity but will cause lag spikes in game causing people crash. This because there is tons of layers using this same _Do_Nothing animation which causing the animator failure.
Solution is to remove _Do_Nothing animation and use zero state animations for all face tracking states.

This has been fixed by v3.1.4 and higher. Zero states have to be used.


val data = 1 to 10000 renders Notebook unresponsive

Naively typing in the very first command from the "itas workshop"
(http://stanford.edu/~rezab/sparkclass/slides/itas_workshop.pdf)
val data = 1 to 10000
leads to unresponsive script:

Testing the same with 1 to 100, 1 to 1000, 1 to 2000 leads to increasingly longer wait times.
If possible, I suggest that we do not only "show" the ellipsis (...) using CSS,  but also cut-off the number of data points sent in the html to some reasonable default max (e.g. 1,000 would have worked here).

indeed, that's something we're planning to do, that is only call the plots when it asked for.
The thing here is that it will create 4 plots with all points in them (the points are there in json to allow oflline showcases).
So for now, you can do
val data = 1 to 10000
()

In the next version (probably 0.7.0.), it won't be required, but to plot we'll need to call xxx
val data = 1 to 10000
xxx(data, maxPoints=100)

for instance

there wasn't an entry on this plot thingy, not there is #280


specifying "Boilerplate: abstract no" still generates the header for the abstract

Specifying in the metadata block:

Boilerplate: abstract no

still generates a header for the Abstract, it just doesn't put the body of the abstract in.
(I actually wanted to use this because I wanted an abstract with a markdown-generated nested list, but couldn't figure out how to get bikeshed not to strip the indentation that would allow the list markup to be accepted, so I tried this to generate the abstract manually.  I gave up and wrote the abstract in HTML instead of markdown instead.)

Hmm, I'm not sure why I didn't just put the Abstract header in the abstract.include.  Makes sense to reshuffle that, remove the Abstract header from the header.include.

Done.