Check run error, invalid field: annotations

Bug Report
Current Behavior
I'm creating a check run and I'm passing an array of annotations but I get this error
ERROR probot: {"message":"Validation Failed","errors":[{"resource":"CheckRun","code":"invalid","field":"annotations"}],"documentation_url":"https://developer.github.com/v3/checks/runs/#create-a-check-run"}
function checkFailure(context, { head_branch, head_sha }, annotations) {
  return context.github.checks.create(context.repo({
    name: 'Check',
    head_branch,
    head_sha,
    status: 'completed',
    conclusion: 'failure',
    completed_at: new Date(),
    output: {
      title: 'Check',
      summary: 'The check failed',
      annotations: [{
        path: 'src/check.js',
        start_line: 15,
        end_line: 15,
        annotation_level: 'failure',
        message: 'Parsing error: Unexpected token ... on line 15, column 78',
        title: 'Parsing error: Unexpected token ...',
        start_column: 78
      }]
    },
  }))
}

Expected behavior/code
I expect annotations to appear on the changed files
Environment

Probot version(s): v7.2.0
Node/npm version: Node v10.14.2/npm 6.4.1
OS: OSX 10.14.2

Also running into this, will update if I figure it out myself...

@nickcolley ah cool, will try your solution to this

resolved: https://github.com/octokit/rest.js/issues/1170#issuecomment-450545193


Allow to run with pod security 'restricted'

Addition to pull request #17.
Allows the pod to run with restritcted PodSecurity enabled (https://kubernetes.io/docs/concepts/security/pod-security-admission/).
Error creating: pods ... is forbidden:
violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "cert-manager-webhook-hetzner" must set securityContext.allowPrivilegeEscalation=false),
unrestricted capabilities (container "cert-manager-webhook-hetzner" must set securityContext.capabilities.drop=["ALL"]),
runAsNonRoot != true (pod or container "cert-manager-webhook-hetzner" must set securityContext.runAsNonRoot=true),
seccompProfile (pod or container "cert-manager-webhook-hetzner" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

Thanks for the great project!

Looks good.


KDF Function

Do you think that adding a KDF function into the mix the overall security against brute forcing will improve?
Do you think there is a way to add more entropy, like adding an email as the salt or somthing like that?

It already uses pbkdf2 and the salt is randomly generated which should be way more secure than user input.
https://github.com/anderson-arlen/cryptoseed/blob/master/src/containers/Application.jsx#L48

I see, good!
Im adding cryptoseed to my version bitkey.io (livecd), maybe it will get pulled in.

Sweet. Glad you found it useful. :+1:


⚠ SolarOscp has degraded performance

In e9cd80c, SolarOscp ($SOLAROSCP_URL) experienced degraded performance:

HTTP code: 200
Response time: 292 ms

Resolved: SolarOscp performance has improved in 4892889.


Clean up formatting: PEP8 and .format()

Is this a welcome PR @dtarnowski16 to make the code more readable and consistent with PEP8?

Codecov Report

Merging #25 into master will not change coverage.
The diff coverage is 38.46%.

@@          Coverage Diff           @@
##           master     #25   +/-   ##
======================================
  Coverage    28.8%   28.8%
======================================
  Files           6       6
  Lines         184     184
======================================
  Hits           53      53
  Misses        131     131

Impacted Files
Coverage Δ

labcalc/gibson.py
34.37% <38.46%> (ø)
:white_check_mark:

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 b3d8249...4ff214b. Read the comment docs.


Improve default component icons in the model registry

Currently, the default component icon is served via the CRXDE, which may not be available in standalone Sling deployments. Provide a custom component icon instead.

Done!


Error when installing botframework

Is it an issue related to Adaptive Cards?
No
Is this an accessibility issue?
No
What version of Web Chat are you using?
Latest production
Which distribution are you using Web Chat from?
NPM
Which hosting environment does this issue primarily affect?
WebView on React Native
Which browsers and platforms do the issue happened?
No response
Which area does this issue affect?
Others or unrelated
What is the public URL for the website?
No response
Please describe the bug
When running npm i botframework-webchat
version ˆ4.16.0
throws Module not found: Error: Can't resolve 'p-defer-es5'
Do you see any errors in console log?
Module not found: Error: Can't resolve 'p-defer-es5' in ...

How to reproduce the issue?

Navigate to ...
Click on ...
Type "..." in the send box

What do you expect?
installation of this package
What actually happened?
broke down the process of installation
Do you have any screenshots or recordings to repro the issue?
No response
Adaptive Card JSON
No response
Additional context
No response

@matejvagic - thank you for reporting this. I am going to attempt a repro of the issue and will let you know what I find.

@matejvagic - Can you tell me which version of Node and npm you are running?
Also, can you try running these commands in the below order and see how far you get? You may also want to try deleting the node_modules folder if the first attempt generates any sort of error. These come from the BUILD-SCRIPTS.md file in the Docs folder.

npm ci
npm i
npm run bootstrap
npm build
npm start

Unfortunately, I wasn't able to repro your issue. If you didn't initially follow the above steps, can you try and let me know how far you get?

Closing due to inactivity.


Convert initSkipLink.js to TypeScript & add unit tests

Is your proposal related to a problem?
initSkipLink has been in the codebase for some time and it would be good to convert this to TypeScript
So that we can have a basic confidence that code changes will not lead to widget regressions, and in prep for some widgets migrating to Stimulus it would be good to have a basic test coverage of this component util.
It would be good to also include some basic JSDOC for each function in that file, and conversion to TypeScript gives us more confidence that the code will be used in a reliable way.
Describe the solution you'd like
The file https://github.com/wagtail/wagtail/blob/main/client/src/includes/initSkipLink.js should be converted to TypeScript (.ts) and any required types be added.
Along with this we should add some basic unit tests to cover the init functions' basic behaviour in a new file client/src/includes/initSkipLink.test.js (note: .js for tests)
Additionally, there should be a basic JSDOC entry describing the purpose and behaviour of each of the functions in the file - if not already included. For example the 'inspired by' label should be in the JSDOC section.
Requirements

[ ] Convert the file to TypeScript
[ ] Add a JSDOC description to the function
[ ] Add a basic set unit test in newly created test file, it should check that the main element gains focus in the test and it should check that the tabindex gets correctly added & then removed on blur

Additional context

This has been created as part of the Outreachy program to help new contributors that are interested in the Stimulus project.
Look at client/src/includes/breadcrumbs.test.js for an example of mocking some HTML to then trigger some behaviour on that HTML.
Look at some future proposed code for an example of unit testing this (note: this is not the same source but should give you a good idea for some starting points) https://github.com/lb-/wagtail/blob/rfcs/stimulus-ui/client/src/controllers/SkipLinkController.test.js

hi, @lb- I'd like to work on this issue.

I am working on this

@Julietadeboye as per Slack - yes please can you pick this up.
Sorry for the confusion @Deepanshu039


[Improvement] Use bottom sheets for KP

Hi everyone,
On a product page, when we click on a knowledge panel, we open a new screen with the details.
By doing that, we lose the context of the product:

A simple enhancement would be to use some bottom sheets, which may look like this (sorry for this really bad mock-up):

What would you think of this?
(In terms of code, the impact is relatively small)

My 2 cents:

looks better your way
why not?
should we make it a general rule in the app?

always use "bottom sheets", never dialog?
always use "bottom sheets" for read-only content?
no general rule, each case is different?

you are lucky with your mock-up because

the size of your content is small enough to fit in half-screen - would that look that good with a much taller content? much smaller content?
there's only one button that goes outside the app - with an "edit" button like "add categories", would that still be a smooth UX when going back from "add categories", e.g. with refreshed data?

Beyond that I would say: that looks good, please try!
If possible make it agnostic from the product page, with a (new) "openKP" method that in the current version would open a page, in your version would open a bottom sheet, and perhaps one day would open a dialog. Once you create the "openKP" method, we have no impact on the product page, that just uses "openKP".


I need a Receipt

Colleagues,
I have the bank record
07.07.2015	09.07.2015	Card ***7159 JS BIN JS BIN PRO +4412735577	12.99 GBP
I paid it in July for Pro account. I can't see the recieipt that I need to supply to my accountant.
Probably that's because my account not in Pro status now.
Could you please send me the receipt on my Email<EMAIL_ADDRESS>?

That should have been sent now directly from Stripe.


add badges on README.md

I would suggest they be added to readme.md as well. I know many times when I look at projects, I'm browsing on GH, and the readme.md is the first thing I read, and I rarely go to the associated webpage. That's personal experience/opinion though.

I would suggest they be added to readme.md as well. I know many times when I look at projects, I'm browsing on GH, and the readme.md is the first thing I read, and I rarely go to the associated webpage.

Same here


Logos update

Hi @ozorku, thanks a lot for submitting this PR, can you compress these logos with TinyPNG and update the PR?

Also, can you edit/find a squared version of these logos to fit with the others

Hi @ozorku, thanks a lot for submitting this PR, can you compress these logos with TinyPNG and update the PR?

Also, can you edit/find a squared version of these logos to fit with the others

Sure thing

I've also updated some previous logos to be squared e.g Kuda Bank, UBA, Asosavings


sources/path: if PathSource::list_files fails while using a git repo, retry without it

Sometimes discover_git_repo() can succeed even though the git repo
isn't complete. This resulted in us failing to build in some cases (I
noted the case where HEAD is valid but other objects are missing due to
alternates not being accessible, and we trigger use of list_files() by
having a build script). Resolve this by always retrying without a git
repo if we fail to list files while using one.
Fixes #10311.
Note: this may cause retries in list_files that are unrelated to git issues. I think these should be minor (if they ever occur). It is possible to structure things as a loop rather than a separate function and only trigger retries on git issues, but the separate function seemed cleaner. (It's also possible one of the other alternates solutions in #10311 might be a better choice because of some downside I'm not aware of. Let me know if that's the case).
Also, right now this code will never indicate if there was an issue examining the git repo (and silently fall back to the non-git-repo file listing). This makes sense given the issue I reported in #10311, but seems like it might allow us to unknowingly break handling of the git files list (given it will silently fallback). Thoughts here would be useful.

r? @alexcrichton
(rust-highfive has picked a reviewer for you, use r? to override)

Thanks for the PR! I am wary of the retry mechanism. PathSource::list_files are used in three places at this moment:

Determine fingerprint of rustdoc or package with a build script.
cargo package
cargo vendor

Since the file-listing logic in list_files_git and list_files_walk are totally different, I am afraid that some unexpected/sensitive files might be included without notice.

It's important to note that in many cases, an invalid git repo already causes us to use the list_files_walk mechanism: for example, if one is using git worktree for their git directories (and makes the source inaccessible) or if one uses git clone --reference but without a valid HEAD (ie: no extra commit) we already fall back to using list_files_walk instead of list_files_git.
It's my believe that we're using list_files_git for better accuracy if include is not specified, but it's not a requirement, just an optimization to better match user expectations wrt what files are included. In other words: it's not great if we have a less accurate mechanism (like list_files_git is less accurate than using include in metadata), but it doesn't seem like this would block us from using a fallback.

@joshtriplett what's you're thought on the boundary between "fallback" and "detecting a valid git directory" here? In some ways, we're already falling back to not using git in many cases.
More generally, I think it's useful to consider the mental model here: It's (from my perspective as a user) somewhat surprising that cargo itself is trying to treat the location where my crate is located as a git repository. It's nice that it does (when it's not broken, like this bug), but it's somewhat questionable when it causes build failures.
One option we have is to adopt the mental model that if treating the directory as a git repository fails, then clearly the directory was not actually a git repository. This is essentially the model of this PR.
Another option though is for us to reduce our reliance on a fully formed git repository. The cargo documentation for include/exclude (which also documents it's use of git to some extent), only indicates that the .gitignore files are being used if the crate lives in a git repo (https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields). This particular bug in cargo occurs because that documentation isn't entirely accurate: while the gitignore system is used, cargo is also using the git index combined with the gitignore system to determine appropriate files to list. If cargo instead just did what was claimed by the documentation, this error would not occur (because git here is failing while trying to examine the index).
A related option to the last one is to continue examining the index (with a documentation update), but make the index not being usable result in us just using the gitignore system.

@jmesmon My thinking here is primarily about consequences: I'm concerned about falling back from git to not-git causing cargo publish or cargo package to include a file that the user doesn't want included (e.g. because we don't pay attention to .gitignore and similar in the non-git case). That's an especially terrible failure, which may result in harm to a user through publishing information they didn't want. (It could also result in less awful but still annoying failure modes, as well as issues of publishing too little and ending up with a non-functional crate.)
One way to reduce potential harms would be to warn but continue in less consequential situations, such as cargo build, but hard-error in more consequential situations, such as cargo publish or cargo package. That seems much safer.
Another orthogonal improvement would be trying to be more consistent about what information we process, such as always processing .gitignore files even if we're not in a git repository. (We could do that with the ignore crate, for instance.) We'd have to take care about backwards compatibility, but doing what we can to improve consistency between these cases seems like an improvement.
I'd prioritize reducing potential harms in the publish/package/etc case, though.

Sure, it sounds like you're proposing that rather than this fix, we do something more complicated. To do the more complicated thing (if we do decide to go that way), we do need to more definitively define what "inside a git repo" means, as that's part of the reason that this bug occurred in the first place. Don't see any one proposing/clarifying what that might mean (other than myself). It would be very useful to have direct discussion of this point.
Some breakdown of conditions as they currently exist vs how this PR would change things:

condition
"in git repo" in current cargo
"in git repo" in this PR

HEAD exists and all it's file/tree objects exist, but parent commits may not
✔
✔

HEAD exists, but file/tree objects it refers to may not
✔
✖

.git (and subdirs) exist, but HEAD object does not
✖
✖

.git exists, but has no content
✖
✖

It will be difficult to make changes to this code without us establishing what this boundary is supposed to be. Is it simply "does git_discover_repo work" (as it is currently defined in cargo) or some other definition better for us here, given the concern folks have with having list_files returning too many files (because we don't handle ignores if not "in a git repo"), it seems like it might make sense for it to decide we're in a git repo more often than git_discover_repo (even though this PR makes us decide we're in a git repo less often to fix the current build failure).

Oh, also: we're already using the ignore crate for gitignores here. We just inseperably (at the moment) mix it in with using the libgit2 index as well (hence the bug).

@jmesmon At the moment, I think I'd be satisfied if we just turn the warning into a hard error if we're in cargo publish or cargo package. That would address all my concerns about including too many files by mistake.

r? @joshtriplett

Ping @jmesmon. Just checking in to see if you are still interested in working on this. The comment here telling one of the expected solution. Let us know if you can continue in that way, or have any question. Thank you!

:umbrella: The latest upstream changes (presumably #12159) made this pull request unmergeable. Please resolve the merge conflicts.

I'm going to close due to inactivity. We are still interested in some solutions here, specifically https://github.com/rust-lang/cargo/pull/10313#issuecomment-1024593534. Feel free to reopen if you have a chance to work on it again. Thank you.


Building pull requests

This PR changes the GH Actions flow so that also pull requests are built. Could be useful perhaps?
// CC @richardstartin

@gunnarmorling I think if you rebase to pick up the fix this should pass.

Rebased and applied. This needs explicit approval by a maintainer given it's my first contribution to this repo.


Allow meltano upgrade to complete without an active project

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/3409
Originally created by @aaronsteers on 2022-04-18 04:58:00

Most meltano commands require an active project.
meltano upgrade does have some project-specific elements (at least in theory).
When run outside a project, meltano upgrade should at least in theory still be able to run, analogous to pipx update meltano.

View 2 previous comments from the original issue on GitLab


feat(azure): increase terminationGracePeriodSeconds to 300s for azure provider

What this PR does / why we need it:
Add your description
Which issue(s) this PR is related to (optional, link to 3rd issue(s)):
Fixes #
Reference to #

Special notes for your reviewer:
/cc @your-reviewer

Release note:

NONE

/lgtm


NaN metric is not reported

Not A Number (NaN) is a supported metric according to EXPOSITION FORMATS

value is a float represented as required by Go's ParseFloat() function. In addition to standard numerical values, Nan, +Inf, and -Inf are valid values representing not a number, positive infinity, and negative infinity, respectively.

However, this is not tracked when doing the following:
var nanGauge = Prometheus.Client.Metrics.CreateGauge("nan", "metric with nan value");
nanGauge.Set(double.NaN);

Expected Outcome
# HELP nan metric with nan value
# TYPE nan gauge
Nan

Actual Outcome
# HELP nan metric with nan value
# TYPE nan gauge

Repro
Pull https://github.com/tomkerkhove/prometheus-nan-repro and consume /repro endpoint.

Hi @tomkerkhove
Thank you for reporting the problem, but could you please provide some more details about you use-case? We suppress NaN value in Gauge for the reason: it's hard to define predictable behavior for the Gauge in such scenario. What if value was set to NaN and then try to Inc? Should we consider NaN as 0 and result to current value be 1? But NaN + 1 results to NaN in .net. Or should we work with NaN according to .net rules? Than gauge will "not accept" any changes unless user's code explicitly set it to some other value.
We should define behavior before make any changes to the library. Let's discuss your use-case and create some proposal.
Thanks

If you are doing this deliberately I think an exception would'be been better rather than supressing as this is a bit strange.
My use case is simple - I have a metric and sometimes I need to report NaN 🤷♂ I only use Set, never use Inc/Dec.

Ok, so here is my suggestion:

gauge should be changed to throw on NaN value to provide better experience
untyped metric, which is suppress NaN for the moment should accept it

So you can use Untyped instead of gauge for your needs. I can create PR tonight if the suggestion works for you.

Well, in theory, is it still a gauge 🤔
Can we have 2 gauges? Or be able to define a baseline for NaN so you can inc/dec?
What are you doing today when somebody passes NaN and then calls Inc? You store the previous value then or?

Where I'm going is that there should maybe be 2 gauges - One which only has set and supports NaN, and one which has Inc/Dec?

What if the Gauge creation allows me to say that it's acceptable to pass NaN and it's up to me to only use Set?
Example:
var nanGauge = Prometheus.Client.Metrics.CreateGauge("nan", "metric with nan value", suppressNaN: false);
nanGauge.Set(double.NaN);

It's not a gauge, but untyped which is exported as untyped metric.
The main difference that there is Set only, no Inc or Dec methods.

In our case, we need a gauge - https://prometheus.io/docs/concepts/metric_types/#gauge.
Based on this our scenario is still valid as far as I see:
We have a metric that can either go up or down. If we don't have a value, and 0 is not representable, then we should use NaN
https://prometheus.io/docs/practices/instrumentation/#avoid-missing-metrics

Gauges can be set, go up, and go down. They are useful for snapshots of state, such as in-progress requests, free/total memory, or temperature. You should never take a rate() of a gauge.

Gauges can be set, go up, and go down. They are useful for snapshots of state, such as in-progress requests, free/total memory, or temperature. You should never take a rate() of a gauge.

Example:
var nanGauge = Prometheus.Client.Metrics.CreateGauge("nan", "metric with nan value", suppressNaN: false);
nanGauge.Set(double.NaN);

I think this is the best approach, personally. It tracks as a Gauge & allows me to use NaN when I don't have a decent metric.

The problem with NaN for gauge that if you set it's value to NaN, and then use Inc... the current value will be NaN... it might be unexpected and hard to predict behavior.
Why can't you use untyped instead? Currently Prometheus server ignores type information at all:

The Prometheus client libraries offer four core metric types. These are currently only differentiated in the client libraries (to enable APIs tailored to the usage of the specific types) and in the wire protocol. The Prometheus server does not yet make use of the type information and flattens all data into untyped time series.

Untyped metric has no such logical problem in work with NaN as Gauge has, because there are no methods except Set.

Or after all you can implement and register into the CollectorsRegistry you own metric, which will work as you want and reports itself as a Gauge (It's easy after the V3 release by using IMetricWriter). I can create an example for you if you prefer this way.

The reason for a gauge is that human consumers know what to expect but I get your point, although I'm still not convinced (sorry 😅)
Feel free to post a sample, maybe that's a good alternative!

Ok, so do you need labels support for the metric or just a single unlabeled value?

We are using labels indeed! But take your time, it's not urgent.

Hi @tomkerkhove !
Here is example code for custom metric which uses stub as a datasource. All you are need - just register instance of RaceMetric class in your collectors registry (Metrics.DefaultCollectorRegistry if you are using the default one).
Custom collector should implement ICollector interface, where:

Configuration property, should have all configuration data needed to create instance of your collector, useful if you use ICollectorRegistry.GetOrAdd for registration
MetricNames property, should return all metric names produced by the collector
Collect method, which is called on each scrape to produce actual output via the IMetricsWriter

using System.Collections.Generic;
using System;

using Prometheus.Client;
using Prometheus.Client.Collectors;
using Prometheus.Client.Collectors.Abstractions;
using Prometheus.Client.MetricsWriter;
using Prometheus.Client.MetricsWriter.Abstractions;

namespace CoreConsoleMetricServer
{
    public class RaceMetric : ICollector
    {
        private readonly IEnumerator<(string Car, double Speed)[]> src = new RaceDataSource().Get();

        private const string MetricName = "race_car_speed";

        public ICollectorConfiguration Configuration { get; } = new CollectorConfiguration("my_custom_race_metric");

        public IReadOnlyList<string> MetricNames { get; } = new[] { MetricName };

        public void Collect(IMetricsWriter writer)
        {
            src.MoveNext();

            writer.WriteMetricHeader(MetricName, MetricType.Gauge);
            foreach (var item in src.Current)
            {
                writer.WriteSample(item.Speed, string.Empty, new[] { new KeyValuePair<string, string>("car", item.Car) });
            }
        }
    }

    public class RaceDataSource
    {
        public IEnumerator<(string Car, double Speed)[]> Get()
        {
            yield return new[] { ("red", 0d), ("green", 0d), ("blue", 0d) };

            yield return new[] { ("red", 10d), ("green", 12d), ("blue", 20d) };

            yield return new[] { ("red", 30d), ("green", 24d), ("blue", 50d) };

            yield return new[] { ("red", 50d), ("green", 45d), ("blue", 80d) };

            yield return new[] { ("red", 100d), ("green", 90d), ("blue", 120d) };

            yield return new[] { ("red", 50d), ("green", 75d), ("blue", double.NaN) };

            yield return new[] { ("red", 75d), ("green", double.NaN), ("blue", double.NaN) };

            while (true)
            {
                yield return new[] { ("red", double.NaN), ("green", double.NaN), ("blue", double.NaN) };
            }
        }
    }
}

Please let me know if this helps.

@tomkerkhove Could you please let us know if the suggestion above helps?
Thanks

Thanks for the sample, I'll have a look at soon.

Hi @tomkerkhove
Is this still actual or we can close the issue?
Thanks

I still need to give it a spin but will close for now. Thanks!

I've had a look at the sample and makes it a lot more complex for consumers, just to track a NaN on a Gauge. I still believe that, if it's opt-in, and I call Inc/Dec on a NaN it's up to me to fix it or just use Set.
I tried to extend the current gauge but the factory method makes it a bit more cumbersome.
However, if you really think it's best not to remove the check then that's ok for me. Will go with an untyped metric then unfortunately

I'll reopen the issue so we can discuss the changes.
Here is new suggestion:
We can allow NaN as a valid value for Gauge via method Set, but throw when user's code try to use Inc or Dec if current value is NaN. This approach allow us to support NaN and still have predictable behavior.
@tomkerkhove and @phnx47  does such suggestion works/makes sense?
Thanks

That would be prefect for me! Thanks for considering!

We are holding off https://github.com/tomkerkhove/promitor v1.0 until this is sorted out.
Feel free to let me know what you think of this and if you have the bandwidth. If not, I might be able to contribute this if you want.

Wow! Sounds like we have to change our plans a little to make this live ASAP. I think it will take day or two to get development build so you can check everything on your side. And then we can cut the production build.
I'll keep you informed on the progress.

Thanks and don't rush it, if we have to wait then that's it - I don't expect you to drop everything and implement this :)

Here is new suggestion:
We can allow NaN as a valid value for Gauge via method Set, but throw when user's code try to use Inc or Dec if current value is NaN. This approach allow us to support NaN and still have predictable behavior.

In terms of your suggestion, don't feel obliged to roll this out for everybody perse, if you want to use a supressNaN which is true by default, then that's ok for me!

Pulled in the MyGet package and it works:
# HELP demo_servicebusqueue_queue_size Amount of active messages of the 'myqueue' queue (determined with ServiceBusQueue provider)
# TYPE demo_servicebusqueue_queue_size gauge
demo_servicebusqueue_queue_size{resource_group="promitor",subscription_id="0f9d7fea-99e8-4768-8672-06a28514f77e",resource_uri="subscriptions/0f9d7fea-99e8-4768-8672-06a28514f77e/resourceGroups/promitor/providers/Microsoft.ServiceBus/namespaces/promitor-messaging",instance_name="promitor-messaging",entity_name="orders"} NaN<PHONE_NUMBER>042

Thank you!

@tomkerkhove,  sounds good!
Do we need to create a prod package ASAP or you OK for now and it can wait week or two (for other issues in scope of 3.1 to be sorted)?

I won't ship v1.0 on the preview package but it's ok to wait a week or two, no worries!

OK. I'll close the issue and let's plan it to be included into upcoming 3.1 release. If you need the functionality to be available earlier - just let us know and we will cut the build.
Thanks.

Just out of curiosity - When are you planning to ship 3.1?

Sure that's fine - Thanks!


Please provide more documentation on SvgDataResolver

I'm a bit confused as to the use case for this class.

Why do we need it to enable svgs on native?
Why is the height parameter always 0 in the examples you provided?
Why are you passing 64 for width in one sample even though svg width is 30?
How should we allocate ImageView dimensions before loading the svg?

https://github.com/luberda-molinet/FFImageLoading/wiki/SVG-support

Why do we need it to enable svgs on native?

It's because SVG support has a SkiaSharp dependency and it's included as a separate nuget package.

Why is the height parameter always 0 in the examples you provided

FFImageLoading automatically maintains correct aspect, so if you set width - height will be auto-calculated, if you set height - width will be auto-calculated.

Why are you passing 64 for width in one sample even though svg width is 30?

SVG is scalable, so widths / heights would be scaled to 64

How should we allocate ImageView dimensions before loading the svg?

Could you elaborate?
BTW: Feel free to update WIKI - it's editable. Cheers :)


is vf_row_sky correct?

https://github.com/pvlib/pvlib-python/blob/7e88d212c786d0ad334dce6fcafaf29339ff60ab/pvlib/bifacial/infinite_sheds.py#L146
I think this should be:
$$\frac{1 + \cos \left( \text{surface tilt} + \psi_{t}\ \text{shaded} \right)}{2}$$
because in the reference frame of the module surface the angle pointing along the slant height to the sky is actually zero, $cos(0) = 1$, and the angle above the slant height to a horizontal line would be the surface_tilt itself, then the angle from the horizontal to the top of the next row is psi_t_shaded so finally this angle from the slant height all the way up to the top of the next row is surface_tilt + psi_t_shaded:

For example, this is why if psi_t_shaded is zero, then the view factor should collapse to the isotropic view factor $(1+\cos(\beta))/2$ as given on the PVPMC website modeling reference for POA sky diffuse.
The actual value difference between the two formulas can be quite small when psi_t_shaded is close to zero (eg less than 5°), but it's significant when as the masking angle is larger (eg greater than 5°).

ditto:
https://github.com/pvlib/pvlib-python/blob/7e88d212c786d0ad334dce6fcafaf29339ff60ab/pvlib/bifacial/infinite_sheds.py#L153
and
https://github.com/pvlib/pvlib-python/blob/7e88d212c786d0ad334dce6fcafaf29339ff60ab/pvlib/bifacial/infinite_sheds.py#L251

FYI: these formulas are sort of referenced in doi: 10.1109/PVSC40753.2019.8980572 in eqn's (10) & (11), except that they are multipliers meant to undo the VF the previous transposition step.

I disagree and believe that line of code and its description are correct.
The implementation of the infinite_sheds doesn't use the multiplier approach indicated by the paper. The function _vf_row_sky_integ first calculates the view factor to the visible from each point x along the slant length of the module, which is given by 1/2 (cos(psi_t) + cos(tilt)), where psi_t is the angle from x to the top of the facing row of modules. Then the view factors are integrated over x to return an "average" view factor value.

I've been chewing on this for a while and am not quite sure where the flaw is in Mark's math.  I suspect it has something to do with unwittingly adding or deleting a segment from the sky dome, making it not a hemisphere anymore and causing the view factor to be taken as a fraction of the wrong thing, but I don't have any math to back that up.  I'd be interested to see a better explanation if anyone has one.
Anyway, regarding the calculation in the code: start with the usual $(1 + \cos(\beta))/2$ view factor for an isolated row and subtract off the portion of the sky blocked by the facing row.  That second VF is the sky VF of an upside-down row tilted at psi_t, so it can be calculated with $(1 + \cos(180-\psi_t))/2 = (1 - \cos(\psi_t))/2$.  Subtracting the latter from the former yields $(\cos(\beta) + \cos(\psi_t))/2$.

I suspect it has something to do with unwittingly adding or deleting a segment from the sky dome, making it not a hemisphere anymore and causing the view factor to be taken as a fraction of the wrong thing

Yes, I think this was my mistake. In my analogy, isotropic like seems to be coming from below the horizon. BTW: I wasn't proposing the "multiplier" approach - but it does make me think that the equations in the reference are incorrect because the sky dome isn't entirely visible if the reference frame is rotated to the slant height reference frame of the module surface. Thanks for the insight!

Although I don't see an issue that needs correcting, I think it is worth documenting how that line of code is derived. In the attached diagram, we want the view factor for the angle of view corresponding to the red arc. Measuring angles from the horizontal (positive to the right), the view factor is 1/2 (cos(tilt) - cos(180 - psi)) = 1/2(cos(tilt) + cos(psi)).  The second angle (180-psi) results because pvlib uses psi = shading.masking_angle which always returns a positive value, i.e., psi measured clockwise as indicated in this diagram.

However, if angles are measured from slanted line (positive upwards from the ground), I get the formula above: view factor = 1/2(cos(0) - cos(180 - (psi + tilt))) = 1/2 (1 + cos(psi + tilt)). I think the bridging the gap between these two equations must lie in the direction (sign) of the various angles, and some clever way to separate the '1' into cosine terms.

angles are measured from slanted line (positive upwards from the ground)

That was my mistake I think, but now I think that the way the angles are measured should not be arbitrary. Measuring the angles the way I did (from the slanted line) requires rotating the reference frame from horizontal, which I believe is equivalent to a module surface tilted further away from the isotropic sky dome by psi_t.
If I just rely on Marion as the reference then we have:
vf = 0.5 * (cos(beta) - cos(180-psi_t)) = 0.5 * (cos(beta) + cos(psi_t))
according to trig identities.
Also the existing formulation (cos(psi_t) + cos(beta))/2 differs but is numerically closer to the Passias shade factor:
# for backside beta = 160-deg:
(1-pvl.shading.sky_diffuse_passias(np.arange(10)))*(1 + np.cos(tilt))/2
# array([0.03015369, 0.03015139, 0.03014451, 0.03013303, 0.03011696,
#        0.03009632, 0.0300711 , 0.03004131, 0.03000696, 0.02996807])

I think it's important to realize that these two formulas do not evaluate the same:

Hi @cwhanse dis you mean to reopen this?

Yes. I think we need to better understand these two different calculations of view factors before we consider this question resolved.

ok, I think this is essentially B-71 from Siegel's and Howell's "Thermal Radiation" 7th edition which is the fraction of radiation from:

[a] Differential element of any length to surface generated by a line of infinite length parallel to the plane of the element, and moved parallel to itself. Plane of element does not intersect surface.

Then using trig identities and reciprocity, this becomes the same as Marion's reference:
F2->d1 = 0.5 * (cos(phi2) - cos(phi1)) * dA1/A2
Then to get the radiation incident on dA1 from A2, let's call the flux leaving it I2 which is already in units of power per unit of area of A2 you get:
Ed1 = (radiationleaving A2) * (fraction of radiation leaving A2 incident on dA1)
    = (I2*A2) * F2->d1  # radiation from A2 incident on dA1
    = (I2*A2) * (0.5 * (cos(phi2) - cos(phi1)) * dA1/A2)
    = I2 * 0.5 * (cos(phi2) - cos(phi1)) * dA1  # A2 cancels out

The area A2 cancels out and we're left with just the flux of radiation from A2 incident on dA1:
Id1 = Ed1/dA1 = I2 * 0.5 * (cos(phi2) - cos(phi1))

By the way, this problem can be solved using A-10 by integrating from zero to Y_psi = sin(phi+psi)/sin(psi) but the integral is nasty. It also looks like superposition could be used if there were view factor from dA1 to the part of A2 starting where psi intersects it. I'll try to add a figure or use SymPy maybe. My calculus is very rusty.

Testing both formulas against integrating A-10 in this gist, I find better agreement with the formulation in the PR and the original reference doi: 10.1109/PVSC40753.2019.8980572 in eqn's (10) & (11) than the existing formulation which I think is only valid for the ground's view of the sky as in the Marion reference.

@cwhanse I think the reason the existing formulation doesn't work is because the normal of the differential surface dA1 is pointing upward instead of normal to the panel surface and that affects the angle from the normal to a line connecting the two surfaces:

@kanderso-nrel I think the reason that superposition, Fd1->a = Fd1->2 - Fd1*->b

as you suggested, doesn't work because they are not the same differential dA1 as you can tell by the normal from each surface, which is different for the differential rotated by psi than for the differential rotated by phi. The orientation of each differential matters.
I think we should consider merging the PR. I think we can use Siegel & Howell as a reference.

Also I should’ve clarified that I did not derive the numerator expression. I took it from work done by Jeff Newmiller as explained in the wiki bifacial notes. I remember it took me awhile to understand it, as I also originally thought it should be a difference of two cosines, vs a cosine of a difference. Evidentially it didn’t stick because I forgot. That was pre-pandemic

I believe the current pvlib formulation would only be valid for the ground's view of the sky

Yes. Herein lies the conceptual mistake I made in the implementation. B-71 in Siegel and Howell is the correct formula, but the angles must be relative to the plane containing the receiver, not to a reference plane such as the ground surface. I concur that #1666 is the valid correction to that line of code.

Thanks @cwhanse for running this to ground. I will copy some of this into the wiki bifacial notes for reference. Just for clarification I think:

B-71 is correct for the ground -> sky
B-1 is correct for module -> sky with no obstructions
A-10 integrated from zero to Y_psi is correct for module -> sky with obstruction above the horizon which approaches B-1 as Y_psi -> inf where Y_psi = sin(psi+phi)/sin(psi)

B-71 is correct for module -> sky. We typically measure angles relative to the module's plane rather than it's normal. I wouldn't point to B-1 since that assumes the radiating surface is a flat plane, as opposed to a surface formed by moving a parallel line to form an arbitrary surface. I suppose there's an equivalency between B-71 and B-1, but that's one more conceptual step. B-71 and B-1 yield the same formula when the angles are determined from the module's plane.

The orientation of each differential matters.

D'oh!  Of course, thanks :)

icymi: @jdnewmil


How to zoom the content when use pinch gesture?

There is no built-in feature to zoom by pinch gesture. You can add yourself. Probably add pinch gesture recognizer, then change number of column and row in the handler.

@kishikawakatsumi Can you please explain a little more?

@genaks Hi
You can add pinch gesture recognizer and add it to spreadSheetView
then you can scale spreadSheadView like below:
@objc func zoom(sender:UIPinchGestureRecognizer) {
if sender.state == .began || sender.state == .changed {
self.spreadSheetView.transform = CGAffineTransform(scaleX: sender.scale, y: sender.scale)
} else {
if sender.scale < 1.0 {
self.spreadSheetView.transform = CGAffineTransform.identity
}
}
}

@Cemoo Hi
I followed your codes and had an issue. I couldn't scroll to top or bottom after zooming.
Can you take a look?

Works fine for me. Can I somehow have a look at your code?

@IBAction func pinchRecognized(_ sender: UIPinchGestureRecognizer) {
if sender.state == .began || sender.state == .changed {
if sender.scale <= MAX_ZOOM_SCALE {
self.transform = CGAffineTransform(scaleX: sender.scale, y: sender.scale)
}
} else {
if sender.scale < 1.0 {
self.transform = CGAffineTransform.identity
}
}
}
My problem is couldn't scroll to the end of the spreadSheetView. My solution is putting the spreadSheetView into an UIScrollView then scaling the scrollview. Plz take a look. Thanks.


As a user I want to be able to work with Pseudomonas putida

Done criteria:

[ ] User can create project that supports physiology and genotype data from P. putida


Default Dashboard: Google Ads Clicks over Time

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/1734
Originally created by @dmor on 2020-02-13 20:58:17

Definition of "Clicks":

The number of clicks on your ads.

Important: For this dashboard we want the overall clicks. There are probably other click metrics in the API, but we want this one.
For the MVC, we should just show this at the account level (no special selector for specific campaigns).
https://developers.google.com/adwords/api/docs/appendix/reports/ad-performance-report#clicks

View 5 previous comments from the original issue on GitLab


Update to latest version of Docker in Salt

@brittainhard - can you test this when you get a chance?  Just a warning but you will probably need to start with a fresh vagrant box.

Actually, hold on.  I think there's a Docker configuration file that needs to be set on Ubuntu.

Just a warning but I need to merge this PR very soon for TAD integration, so if it goes unreviewed I'll merge it myself at end of day today.
This upgrades to the latest version of Docker.  Should make things much easier since the new version of Docker has nice commands for debugging and interacting with containers.

Yeah give me about 25 minutes to get the box up and running.

I tested this out and had no obvious issues.

Thanks!  I need to review yours but feel free to merge both now.
On Thursday, July 16, 2015, Brittain Hard<EMAIL_ADDRESS>wrote:

I tested this out and had no obvious issues.
—
Reply to this email directly or view it on GitHub
https://github.com/memex-explorer/memex-explorer/pull/614#issuecomment-121980759
.


Testing on macos-latest fails with Java 8

The failure commented on in https://github.com/xspec/xspec/pull/1918#issuecomment-2078454284 looks like https://github.com/actions/setup-java/issues/625 .
Based on links from that issue 625 to other GitHub issues/PRs, I see two resolutions that different repos are using (at least temporarily):
A) Using zulu distribution instead of temurin for macOS
B) Requesting macos-13 instead of macos-latest

@cmarchand : Do you have any thoughts on the best solution for this repo?
For reference: List of distributions supported by setup-java

You asked:

Where is the script source for this build ?

This is the configuration file for the test workflow:
https://github.com/xspec/xspec/blob/master/.github/workflows/test.yml

There no JDK 8 available for MacOs ARM : https://adoptium.net/temurin/releases/?version=8&os=mac&arch=arm&package=jdk
I don't know if it's new or not. Probably not.
And I'm not able to find if macos-latest runner is a Intel or an Arm.
We probably should add a uname -a in the build process, before installing Java, to check this. Maybe GitHub has changed its default infra recently...

Ok, it's now on M1, Arm. So yes, it's the same problem than actions/setup-java#625.
I'm reluctant to use an old MacOs OS version.
I'd prefer using either :

Bell Liberica

it's coherent with this

Azul Zulu

Your idea of sticking to macos-latest while picking a different distribution, with Bell Liberica as the first choice, sounds good to me. I can try that in the coming week (probably imitating the syntax in https://github.com/apache/logging-parent/pull/169/files except with liberica instead of zulu), but if you want to pursue this yourself, feel free.


wrong number of line reported

Duplicates

[X] I have searched the existing issues

Current behavior 😯
on https://github.com/nkh/ftl, the tool report 500 lines of code, maybe detecting bash code lines needs to looked at
Expected behavior 🤔
report a more accurate number of lines
Steps to reproduce 🕹
clone https://github.com/nkh/ftl
run the tool
Additional context/Screenshots 🔦
No response
Possible Solution 💡
No response

report a more accurate number of lines

Thanks for the report! Can you provide some more information? Why does the number of lines look inaccurate to you? What number were you expecting?

Hi, the problem arrises from the fact that the code is Bash and that notoriously difficult to count, sometimes "# vim: set filetype=bash :" is added at the end of the files and can be used at a hint.
I guess it's at least ten times more code than reported. (506 reported)

Oh, I see what you mean. For example, this is a bash file, but won't be detected.
Right now, these are the hints used to detect a file's type:

extension (e.g. .bash)
shebang (e.g. #!/bin/bash)

Right now this project still uses tokei, which does not check for things like modelines.


Update autorest.csharp to 3.0.0-beta.20220113.5

PR consists of several commits, one project per commit

/check-enforcer reset


[CT-489] Convert  tests to new adapter framework

Pick an adapter test from this list to convert:
https://www.notion.so/dbtlabs/Converting-older-Test-framework-to-pytest-b19ab90b19b941ecb141b4adc890c1a7#aa26483b738b4f0fba9d76e62a4d35bd

Done! https://github.com/dbt-labs/dbt-bigquery/issues/164


DEBUG and ENV: should only be activated for Source §3,4

The environment model is needed for understanding this, so we should limit the use to Source §3 or later.
One "easy" way may be to allow for gutter click only when Source §3 or §4 are active.

However, I feel like a debugger is useful regardless of where you are in the module. Perhaps we could enable the environment visualiser with 3 and 4 but leave the inspector as it is?

The current INSPECT tool also uses the environment model. We are working on an inspector that operates on the substitution model. Yee Jian is working on it. We hope it can be ready in time.
The idea is to use the same entry point: A break point in the gutter of the Ace editor. If the user chooses Source §1 or §2, the substitution model inspector is used, and if the user chooses Source §3 or §4, the environment model inspector is used.
If a student is curious about the environment model before the recess, he can switch to Source §3 and play. There is nothing wrong with that. However, it's clear that its not covered in class yet.
So yea, I differ from your view. I feel that the way to activate the INSPECT debugger is to choose Source §3 (or §4). Users who choose Source §1 or §2 should not see the debugger. (If Yee Jian succeeds, the user will see the SUBST inspector, and if he does not succeed, we will not have an inspector for Source §1 and §2.)

Fixed by #661


Tokenize Regex as Parameter

This PR adds support for a tokenizer parameter which gives the user more control over what constitutes a "token". If the tokenizer parameter is not set then the default regex is used.

What's the use case here?

The default regex is /(\s+|[()[\]{}'"]|\b)/ and the one I am using is /(\s+|[()[\]{}'"_]|\b)/.
It's been a while since I worked on this, but it looks like I wanted to add _ as a tokenizing character. I could also see a use-case here for using , for diff-ing CSV data or maybe . for diff-ing file names.

I second this functionality. I have a use case for diffing two html strings and this would enable me to adjust the tokenizer to meet my needs.

Worth thinking about before I merge this - for Chinese and Japanese support, we might need tokenization logic too complicated to be encompassed in a regex, either built in to jsdiff or as something you can plug in yourself: https://github.com/kpdecker/jsdiff/pull/328#issuecomment-1860452680. I want to carefully think through what I ultimately want the API to look like before merging this PR and make sure it's not gonna commit us to an API that's fundamentally incompatible with supporting Chinese and Japanese.


min do not work

in your first example, like this:

The props "min" is 1, but when I input 0, and blur, the input still show 0.
The "currentValue" has been updated to 1, but the view do not update.
why?

When this.$emit("change"), newValue = 1 and oldValue = 1...
newValue equals oldValue, is this reason to make the BUG?


"Error: certificate has expired Result:  undefined" - Freezes after Ask button click

Once you hit the Ask button, the gif pops up and freezes there.

Same for me

Same for me. I hit ask button and wheel just spins....

Hey Chris
Any fixes for our problem above?
Cheers


PNG Issue in Dark Mode

A PNG on this page have transparent backgrounds but are items on the diagram are coloured assuming a white background.
https://docs.microsoft.com/en-us/azure/postgresql/media/concepts-aad-authentication/authentication-flow.png has a dashed border that doesn't seem to come up in dark mode but does in light mode.
Issue similar to https://github.com/MicrosoftDocs/microsoft-365-docs/issues/3699

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

ID: ab3066d3-1ac8-3367-2b76-7b3d124cc327
Version Independent ID: cb862d42-6f01-f034-d4ee-e4695ca97409
Content: Active Directory authentication - Azure Database for PostgreSQL - Single Server
Content Source: articles/postgresql/concepts-aad-authentication.md
Service: postgresql
GitHub Login: @lfittl
Microsoft Alias: lufittl

@tlourey Thank you for the feedback. This is being assigned to the content author to evaluate and update as appropriate.

@tlourey Thank you for the feedback. This is being assigned to the content author to evaluate and update as appropriate.

We sincerely apologize for the delayed response to this issue. I collaborate with the owners of the GitHub Issues related to PostgreSQL to help either get them resolved or determine how to update our documentation.
Due to the age of this issue, we will continue to close this issue.
Please visit https://docs.microsoft.com/en-us/answers/support/ for more information on asking questions about the product or service.
Thank you.

#please-close


Transition SimpleSkillsTable component from vue-table-2 table to use bootstrap-vue table

Component is used by Badges, Global Badges and Skill Dependencies pages

PR: #291

PR: #291


Release v1.22.0

Release summary
Version number: v1.22.0
Release details
AEA:

Updates the cert request serialisation process to maintain consistency across different operating systems
Updates the get_or_create_cli_config method to return default config instead of creating one
Introduces the copy_class utility function for testing different setup configurations
Updates the overridable policies for the configuration classes

Packages:

Removes the unwanted autonomy dependency from the ledger connection

Tests:

Updates the cli config fixture to retain user config
Fixes outbox check test
Adds test coverage for

aea/cli
aea/configurations
aea/helpers
aea/test_tools
aea/manager

Docs:

Adds documentation on the usage of component overrides

Chores:

Adds a script to automatically generate a package table for the docs
Introduces the usage of tomte to maintain third party dependency version consistency
Updates the script to check the broken links to use parallelization

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[x] I am making a pull request against the main branch (left side), from develop
[x] Lint and unit tests pass locally and in CI
[x] I have checked the fingerprint hashes are correct by running (aea hash all and aea packages lock --check)
[x] I have regenerated the latest API docs
[x] I built the documentation and updated it with the latest changes
[x] I have added an item in HISTORY.md for this release
[x] I bumped the version number in the aea/__version__.py file.
[ ] I bumped the version number in every Docker image of the repo and published it. Also, I built and published them with tag latest
(check the READMEs of aea-develop
and aea-user)
[ ] I have pushed the latest packages to the registry.
[ ] I have uploaded the latest aea to PyPI.
[ ] I have uploaded the latest plugins to PyPI.

Codecov Report
Base: 97.23% // Head: 97.23% // No change to project coverage :thumbsup:

Coverage data is based on head (f6a741c) compared to base (0f1d4cd).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #419   +/-   ##
=======================================
  Coverage   97.23%   97.23%
=======================================
  Files         204      204
  Lines       18667    18667
=======================================
  Hits        18151    18151
  Misses        516      516

Flag
Coverage Δ

unittests
97.23% <100.00%> (ø)

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

Impacted Files
Coverage Δ

aea/__version__.py
100.00% <100.00%> (ø)

aea/cli/fetch.py
90.99% <100.00%> (ø)

aea/configurations/base.py
100.00% <100.00%> (ø)

aea/decision_maker/base.py
100.00% <100.00%> (ø)

aea/test_tools/generic.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


config: global tx support timeout priority choose

What would you like to be added:
global tx support timeout priority choose
priority:

code config
global config
default config

Why is this needed:

pls assign to me

I have implement it in #262


Vagrant on Windows 10 cannot find ubuntu/trusty boxes

http://stackoverflow.com/questions/35519389/vagrant-cannot-find-box
Looks like the solution is to downgrade Vagrant

This appears to be fixed in Vagrant 1.8.5, need to confirm


Disabling a specific file type in imports/exports

Thanks for this great django extension, it's been really useful for me.
Is it possible to disable specific file types like json or tsv in import/export forms?

Quickly looking at the code, you could subclass ImportMixin and ExportMixin and override formats, which gets its default value from  DEFAULT_FORMATS. Or you could override get_import_formats() and get_export_formats().

Yeah I found that, forgot to update this github issue. Thanks anyways.


ng-bind is working fine but {{}} doesn't

in my code , {{}} doesn't display the value ,but ng-bind works ,even it does't occur every time,any idea help?

This sounds like a general support question. Please, use one of the appropriate support channels for these types of questions.
GitHub issues are reserved for bug reports and feature requests.
Thx!


Support create and update source with package name

Master Issue: #8676
Motivation
We have a new package management service that can manage all
the source packages. We can use that in the Pulsar Source to manage
source packages.
Modifications

Support create and update the source with package name
Add test for this

/pulsarbot run-failure-checks

@codelipenghui @wolfstudy @sijie @jiazhai   Please take a look when you have time. Thanks.


cannot complete installing any linux distribution, installation progran repeats "Enter new UNIX username:".

Microsoft Windows [版本 10.0.19559.1000]
every time I install any linux distibution, I cannot finish enter username, see the picture. I didn't do any thing strange. btw, wsl2.

There is a newer Windows 10 insider build 19564.1000. Please update the insider build and try again.

Also, where are you installing them? I have seen people getting permissions errors after installing other than C:\ drive and if you can't create a new user it might be a permissions issue.

It seems there is some problem with input on chinese Windows console.
User needs to be added manually like in https://github.com/microsoft/WSL/issues/5245#issuecomment-632067047

Duping for forward to #5245 which has the work-around. Thanks onomatopellan.


Update Documentation

Hi there! Here I come, 2 years after my first deployment of quetz.
TL;DR: Add all the authentication plugins to the authentication doc page and explain the use of the environment variables in the configuration page.
Long Version: my company was acquired by another one, and we are moving from google workspace to microsoft 365.
I need to switch quetz authentication, and I headed to the documentation to see if there were some updates in these two years.
Having found nothing, I updated my fork to start implementing a micrisoft oidc plugin, and then I found that the azuread plugin was already there.
Also, looking at the configuration page, I see that there a few environment variables declared, but searching through the issues and looking at the code it's clear that every config done in the toml file is now possible via environment variables.
This has to be clarified in the documentation!
There might be more things to update/fix, but I needed these pieces of information only.

Thanks for the note. Indeed, we do support azure login. Do you have time to update the docs?

I could give it a try, but honestly I don't know what's changed in these 2 years, so I'm the last qualified person to do that.
I opened this issue exactly because of that, and because I feel that new user would hugely benefit of updated documentation!


Component: Create utility (official) header (informs DS)

Create CA official top header component that would include ca.gov logo, and languages links.
Figma link:
https://www.figma.com/file/9FTGOPO5HlsLfYuNrtL9IM/cannabis.ca.gov-screens?node-id=381%3A3318
CA.gov Logo needs to be SVG code.
Next to it needs to be text "Official website of the State of California"
Languages links are: English, Espańol, 中文 and More (drop down button with arrow down icon). They should go on the left side of the component.

Mobile layout:

Where will this live?
design-system/components/utility-header/template.html
design-system/components/utility-header/index.css

Created manual WP styles for utility header: https://github.com/cagov/cannabis.ca.gov/blob/main/src/css/manual-caweb.v1.0.1.css


feat: Summary of group permissions in the Project settings page

Thanks for submitting a PR! Please check the boxes below:

[x] I have run pre-commit to check linting
[x] I have added information to docs/ if required so people know about the feature!
[x] I have filled in the "Changes" section below?
[x] I have filled in the "How did you test this code" section below?
[x] I have used a Conventional Commit title for this Pull Request

Changes
In the list of groups, the permissions that this one has were added to the row.

How did you test this code?

Create a group
Go to project setting page -> permissions
Select Groups
Add Permission
Refresh the page

Thanks so much! Will review!

Thank you very much @fabricanva
I edited the PR a little bit by componentising the permission summary, making them chips / tooltiping the remaining permissions. I'd like to use this in other areas!


UTf-8 encoding problems w urllib3 response

I can't remember the error from before now, something like 'response must be string, not bytes'. I don't know why this is an issue on my machine and not on OP/JevinJ's. But here is how I fixed it:
in 'fasttick.py' in the 'heartbeat()' function, I deleted use of urllib3 and replaced with:
from urllib.request import urlopen
def heartbeat():
response = urlopen('https://bittrex.com/api/v2.0/pub/Markets/GetMarketSummaries').read().decode('utf8')
data = json.loads(response)
This brought me to the next error, pickle's attempt to write to a directory 'fast_history' that doesnt exist.
mkdir fast_history
fixed that. I got one screen update that showed three or four markets, but since then, the screen is blank after each 15 second loop. The fast_history folder is filling up with .pickle files though.

Here we go. I'm still relatively new to github, but I made a fork with described changes here:
https://github.com/JevinJ/Bittrex-Notify/compare/master...rocket-pig:master

@rocket-pig Good work, this is something I've encountered but usually goes away when I restart. You can submit a pull request if you like.
The screen being blank may be normal if the market is slow at the time, you can test this by changing line 67 of the current version(if average_rate >= MIN_RATE:) to (if True:) and it should fill up completely.


r7: follow default on actionmailer timeouts

I rule and have completed some work on Case Manager that's ready for review!
ActionMailer is getting some timeouts by default, this change follows that standard.
This pull request makes the following changes:

turn on actionmailer timeouts by default

no view changes
It relates to the following issue #s:

Bumps #2462

For reviewer:

Adjust the title to explain what it does for the notification email to the listserv.
Tag this PR:

feature if it contains a feature, fix, or similar. This is anything that contains a user-facing fix in some way, such as frontend changes, alterations to backend behavior, or bug fixes.
dependencies if it contains library upgrades or similar. This is anything that upgrades any dependency, such as a Gemfile update or npm package upgrade.

If it contains neither, no need to tag this PR.

Whoops, brain on autopilot.


: error GD6C8354B: 'JsonKey' is imported from both 'package:drift/src/dsl/dsl.dart' and 'package:json_annotation/src/json_key.dart'.

Describe the bug
I am getting this error message when I do the flutter run command.

[+10559 ms] [+10435 ms] lib/modules/login/bloc/login_bloc.freezed.dart(150,4): error GD6C8354B: 'JsonKey' is imported from both
'package:drift/src/dsl/dsl.dart' and 'package:json_annotation/src/json_key.dart'.
[C:\bitecope\salesman\build\windows\flutter\flutter_assemble.vcxproj]

I am using
  drift: ^1.6.0
  freezed_annotation: ^2.0.3
  json_annotation: ^4.5.0 as main dependency.
because I get this issue when I run the flutter command flutter run that means I am can't make any further progress till this issue is fixed :(
any help would be highly appreciated. I have also raised this same issue in Freezed so, far got no help :(
https://github.com/rrousselGit/freezed/issues/488

When you import drift into the file for which freezed generates, can you instead import 'package:drift/drift.dart' hide JsonKey? That should resolve this issue.

import 'package:freezed_annotation/freezed_annotation.dart' hide JsonKey;

Thank you so much this solved the issue :)


Specifying email address for web-based Git operations

What article on docs.github.com is affected?

Setting your commit email address
What part(s) of the article would you like to see updated?

"Setting your commit email address on GitHub" indicates that the primary email address will be used for web-based Git operations, but this statement does not appear to be correct. At least, web-based Git operations are not being associated with my primary email address. Moreover, the associated text no longer mentions web-based Git operations as shown in the screenshot in the documentation and instead indicates the email "will be used for account-related notifications and can be used for password resets".
Additional information

👋 Thanks for opening an issue @joel-coffman! You're right, that screenshot is out of date. We'll work on tracking down some more information about what the best fix for this article might be.

👋 @joel-coffman I've spoken to a few different teams and agree that these docs need updating! We need to do some additional digging to figure out the best changes to make, so I'm going to close this issue and open one internally for the team to take a look at. Thanks so much for bringing this to our attention!


[SDL 0165] Remote Control – Lights – More Names and Status Values

Proposal: Remote Control – Lights – More Names and Status Values

The light status signal in the vehicle can provide more values than just ON / OFF for certain lights. Some vehicles can provide the status of more lights than currently defined light names. This proposal adds some new light status values and some new light names to allow an application to get the status of additional lights.

Review: smartdevicelink/sdl_evolution#479
Steering Committee Decision:

The Steering Committee voted to accept this proposal with the revisions.  The revisions will include the error and documentation as described in this comment and this comment, respectively.

The proposal .md was updated on May 4, 2018 to include the agreed upon revisions.

Included with #712


npm run build:aot is not working on Linux

Note: for support questions, please use one of these channels: Chat: AngularClass.slack or Twitter: @AngularClass

I'm submitting a ...
[ X ] bug report
[ ] feature request
[ ] question about the decisions made in the repository

What is the current behavior?

I'm trying to compile the original project (without modifications) in using "npm run build:aot:prod", but receiving an error.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via
https://plnkr.co or similar (you can use this template as a starting point: http://plnkr.co/edit/tpl:AvJOMERrnz94ekVua0u5).

Clone the original project.
Execute the following command:
cross-env BUILD_AOT=1 npm run webpack -- --config config/webpack.prod.js  --progress --profile --bail

-The error just happens when I set "cross-env BUILD_AOT=1".
-The command above is a sub command of "npm run build:aot:prod" (check package.json), that also trigger the error, I separated the exactly point of error to make easier to track.
-This error only happens in Linux (ubuntu) for me, on Windows all is working fine.

What is the expected behavior?

npm run build:aot:prod successfully.

What is the motivation / use case for changing the behavior?
I didn't change anything, just clone and compile.

Please tell us about your environment:
-Linux Ubuntu (on Windows this works fine)

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Details about the error I received:
Starting compilation using the angular compiler.
Angular compilation done, starting webpack bundling.
Error: undefined, resolving symbol ɵf in<EMAIL_ADDRESS>at Error (native)
at syntaxError (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/bundles/compiler.umd.js:1550:34)
at simplifyInContext (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/@angular/compiler.es5.js:23865:17)
at StaticReflector.simplify (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/@angular/compiler.es5.js:23877:7)
at StaticReflector.annotations (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/@angular/compiler.es5.js:23326:38)
at NgModuleResolver.resolve (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/@angular/compiler.es5.js:13878:34)
at CompileMetadataResolver.getNgModuleMetadata (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/@angular/compiler.es5.js:14468:58)
at addNgModule (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/bundles/compiler.umd.js:23050:58)
at /home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/bundles/compiler.umd.js:23061:14
at Array.forEach (native)
at _createNgModules (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/@angular/compiler.es5.js:23055:8)
at analyzeNgModules (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/bundles/compiler.umd.js:22935:14)
at analyzeAndValidateNgModules (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/@angular/compiler.es5.js:22940:19)
at AotCompiler.compileAll (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/@angular/compiler/@angular/compiler.es5.js:22716:13)
at CodeGenerator.codegen (/home/helmut/Workspaces/Javascript/angular-starter-master/packages/compiler-cli/src/codegen.ts:41:10)
at /home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/src/main.ts:20:84
at Object.main (/home/helmut/Workspaces/Javascript/tools/@angular/tsc-wrapped/src/main.ts:116:12)
at Object.runInternal (/home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/src/main.ts:25:10)
at /home/helmut/Workspaces/Javascript/angular-starter-master/node_modules/src/plugin.ts:64:21
at process._tickCallback (node.js:368:9)
at Function.Module.runMain (module.js:444:11)
at startup (node.js:136:18)
at node.js:966:3

I tried again after reinstall everything, and worked fine...
Sorry


Added the search button hover style

What is the change?
Modified the search button style css by adding color to the hovering state.
Related issue?
close: #576
How was it tested?
I have tested by running the localhost:3000 and inspecting through the google developer tool in my device.
Checklist:
Before you create this PR, confirm all the requirements listed below by checking the checkboxes [x]:

[x] Have you followed the Contribution Guidelines while contributing.
[x] Have you checked there aren't other open Pull Requests for the same update/change?
[x] Have you made corresponding changes to the documentation?
[x] Your submission doesn't break any existing feature.
[x] Have you tested the code before submission?

Screenshots or Video:
Add a screenshot or demo video if appropriate.
https://user-images.githubusercontent.com/72553479/113506919-35b19c80-9565-11eb-8da0-87ca25d86958.mp4

Please review my pull request.

comment again to reopen PR..


Add Redox OS support, via platform checks!

This took me a very long time to get working. If there's anything that looks weird, feel free to point it out, but there's probably a reason it's there.

I'm also planning to delete the RustPython/redox and RustPython/redox-cookbook in favor of the installer scripts, as I realized that it's a much bigger pain to maintain a fork of a huge project like Redox than it is to just insert the 2/3 lines of code into the needed files.


add warning of multiple package instances in shared scope

This PR adds a new feature that warns consumer applications if they have multiple npm packages loaded into the browser due to version mismatch. This is yet very simple without any useful instructions. Once, I find a more useful use case, I will add them in the near future.  I think we would need to add some feature flags as well, but I am not yet able to introduce a flag in the best way.

We are in the middle of additional open shift SDK integration so it will take a week or so until we can get a new version released and added to chrome.


Change display username ?

Hello,
Who have a custom .coffee to change the display username ???
Thanks

just addResponseHandler to GetPlayer and set data.player_data.username = 'maestrococ'


feat: support graphql.object_type.name for overriding type names

Pull Request Test Coverage Report for Build 540062525

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 95.208%

Totals

Change from base Build 538951439:
0.02%

Covered Lines:
817

Relevant Lines:
844

💛  - Coveralls


Problem with Discovery project

Hi pals, I am going to run the discovery project. The service (fortuneService) gets registered in the Eureka, but when running the UI project, it cannot find the Random method in FortunesController ("http://fortuneService/api/fortunes/random").
I have also checked the "http://fortuneService/api/fortunes/random" in Postman and it does not find the endpoint either!
Could you please help me with the problem?

Which sample are you using?
In our samples, the back-end service registers itself in a Eureka server with the name fortuneService, and the front-end (UI) apps use Eureka to resolve that service name to instance information (like host and port). Postman doesn't know how to ask Eureka how to find instances of that services.

Dear TimHess,
I am running the .Net Core sample code presented in https://github.com/SteeltoeOSS/Samples/tree/master/Discovery. First, I run the service project and it gets registered in the Eureka. When running the UI project, no response is returned from the service. I receive Bad Request from the following method:
public async Task<string> RandomFortuneAsync()         {             try             {                 var result = await _httpClient.GetStringAsync(RANDOM_FORTUNE_URL);                 _logger.LogInformation("RandomFortuneAsync: {0}", result);                 return result;             }             catch (Exception ex)             {                 Console.WriteLine(ex);                 throw;             }         }
Could you please tell me the way I can solve the issue?

I just tried running that sample, both in the dev(default) branch and master (the one you linked) -- the samples appear to be working as expected, it is likely there is something unexpected happening on your workstation. A bad request
You should be able to browse to the eureka dashboard on your machine to see how fortuneService registered itself. Clicking the link that is displayed with your service instance should result in a 404 as there is nothing listening at /info in that service, but if you change the path from /info to /api/fortunes/random, you should be able to see whether or not the service is in fact up and running at the location it has registered itself with eureka. On my machine, the service registered with http://desktop-kml5ih5:5000 and I am able to get fortunes from http://desktop-kml5ih5:5000/api/fortunes/random.
I'd also recommend trying to run both apps from the command line. Sometimes the color coding in the console output is easier to read. You should see log entries for Steeltoe attempting to resolve the hostname. Here's a success:
dbug: Steeltoe.Common.Discovery.DiscoveryHttpClientHandler[0]
      LookupService(http://fortuneservice/api/fortunes/random)
dbug: Steeltoe.Discovery.Eureka.DiscoveryClient[0]
      GetInstances returning: Instance[InstanceId=DESKTOP-KML5IH5:fortuneService:5000,HostName=DESKTOP-KML5IH5,IpAddr=<IP_ADDRESS>,Status=UP,IsUnsecurePortEnabled=True,Port=5000,IsSecurePortEnabled=False,SecurePort=443,VipAddress=fortuneService,SecureVipAddress=fortuneService,ActionType=ADDED]
dbug: Steeltoe.Common.Discovery.DiscoveryHttpClientHandler[0]
      Resolved fortuneservice to desktop-kml5ih5
dbug: Steeltoe.Common.Discovery.DiscoveryHttpClientHandler[0]
      LookupService() returning http://desktop-kml5ih5:5000/api/fortunes/random

and here's a failure
dbug: Steeltoe.Common.Discovery.DiscoveryHttpClientHandler[0]
      LookupService(http://fortuneservice/api/fortunes/random)
warn: Steeltoe.Common.Discovery.DiscoveryHttpClientHandler[0]
      Attempted to resolve service for fortuneservice but found 0 instances
dbug: Steeltoe.Common.Discovery.DiscoveryHttpClientHandler[0]
      LookupService() returning http://fortuneservice/api/fortunes/random

If that doesn't help you resolve, please provide the following:

Your operating system
.NET SDK version
How you are running Eureka

I'm assuming you were able to get this running, feel to re-open if you still need help


CDS-74421 added stage status

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ x] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

https://harness.atlassian.net/browse/CDS-74421

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app


Feature/wishlist

This PR adds the GraphQL's API for customers' wishlists.

[ ] ~Privileged views and APIs are guarded by proper permission checks.~ views use only logged-in users data.
[ ] ~All visible strings are translated with proper context.~
[ ] ~All data-formatting is locale-aware (dates, numbers, and so on).~
[x] Database queries are optimized and the number of queries is constant.
[x] Database migration files are up to date.
[x] The changes are tested.
[x] GraphQL schema and type definitions are up to date.
[x] Changes are mentioned in the changelog.

Here is the report for 4a683adddd1e405ebf91efbc4ce8f53e971dd4f2 (derenio/saleor @ feature/wishlist)
Base comparison is 5f1437b91400f033ef23782fa919487c44f79093.
No differences were found. (click me)

# api.benchmark checkout
  test name                                  	left count 	right count	duplicate count
  -------------------------------------------	-----------	-----------	---------------
  add billing address to checkout            	         34	         34	             20
  add shipping to checkout                   	          7	          7	              0
  checkout payment charge                    	         10	         10	              0
  complete checkout                          	          8	          8	              0
  create checkout                            	         50	         50	             24

# api.benchmark homepage
  test name                                  	left count 	right count	duplicate count
  -------------------------------------------	-----------	-----------	---------------
  retrieve main menu                         	          5	          5	              0
  retrieve product list                      	          4	          4	              0
  retrieve secondary menu                    	          5	          5	              0
  retrieve shop                              	          2	          2	              0

# api.benchmark product
  test name                                  	left count 	right count	duplicate count
  -------------------------------------------	-----------	-----------	---------------
  product details                            	         15	         15	              3
  retrieve product attributes                	          9	          9	              0

# api.benchmark variant
  test name                                  	left count 	right count	duplicate count
  -------------------------------------------	-----------	-----------	---------------
  product variant bulk create                	         51	         51	              3
  retrieve variant list                      	         15	         15	              6

# api product sorting attributes
  test name                                  	left count 	right count	duplicate count
  -------------------------------------------	-----------	-----------	---------------
  sort product not having attribute data     	         21	         21	              0

@derenio Proposition: create unique together on wishlist item fields: (token, variant) This way we will avoid duplicates and handling logic for those. WDYT?

Mr. @krzysztofwolski Can you review it again?

@derenio let's solve conflicts and we should be ready to finish it today
@maarcingebala Do you have any suggestions?


Feature/getrecordsbyid

Implements the getRecordsById API method (we should use this one instead of searchRecords since we store the IDs already)
Returns the Account ID as part of the convertLead API method
Implements custom module mapping (for code clarity)
Removes a real e-mail address from the system.

Coverage decreased (-1.91%) to 98.09% when pulling bf9defb49d07816e29bdacf2490eaad454e3e73d on feature/getRecordsByid into a231f7322481cfd8f90b8ddfabe9957dec7ccb69 on master.

Coverage remained the same at 100.0% when pulling 9bb2be74a0610e2843d0fcea1be0239b9ed03a57 on feature/getRecordsByid into a231f7322481cfd8f90b8ddfabe9957dec7ccb69 on master.

Coverage remained the same at 100.0% when pulling d21151fa922b23763cf031291eb15224a2ad82d5 on feature/getRecordsByid into a231f7322481cfd8f90b8ddfabe9957dec7ccb69 on master.

Coverage remained the same at 100.0% when pulling 7feae175b924dcbf8cbaa2451338d863988afb7e on feature/getRecordsByid into a231f7322481cfd8f90b8ddfabe9957dec7ccb69 on master.


optimization (proof checking)

if have-steps the terms and types sent to handle-definition are already checked
for correction, hence there should be no further check (should save a lot of CPU !).

this is fixed in commit 6028806e46326b4d6b6d2ecb698071a424115bc2


Updated README.md to use full URLs

Links inside of README.md are relative and do NOT work when the file is synced out to Docker Hub. This PR updates those links to use absolute URLs.

I think we should close this @bradfordcp

I think we should close this @bradfordcp


Add void in empty brackets

Super simple PR.
I was getting warnings for the lack of parameters inside of empty brackets.
I added them in, and these remove the warnings while making this project a little more portable.

Thanks for the fix.


deprecate ready setting

companion to https://github.com/OpenVoiceOS/ovos-config/pull/166
NOTES:

to check if a service is ready, this should be used https://github.com/OpenVoiceOS/ovos-utils/blob/dev/ovos_utils/process_utils.py#L124
now that skills are not necessarily managed by core,  mycroft.ready message was emitted almost randomly and was not dependendable on
mycroft.ready is redefined by this PR as "core is ready to register intents", vs "everything finished loading"
external skills / anything registering intents should still use mycroft.ready in combination with ProcessUtils linked above to determine when to load

Summary by CodeRabbit

New Features

Enhanced skill management processes for improved efficiency.
Refined handling of skills requiring network or internet connections.

Bug Fixes

Improved synchronization checks during skill loading.
Deprecation of outdated methods to streamline skill management.

Tests

Expanded test coverage for blacklisted skill loading.
Adjustments made to the validation of event handlers in tests.

Why deprecate this? It is used in many skills and integrations to determine when core services are ready for normal usage

discussion here https://matrix.to/#/!EOygeDJPfJQOfNacqH:matrix.org/$cN3qQ_K_CdrMSYXUx3rDRUGs60gwX3Q_QlK3vzeEkIo?via=matrix.org&via=tchncs.de&via=mozilla.org

Why deprecate this? It is used in many skills and integrations to determine when core services are ready for normal usage

edited original post to include some extra info about this

discussion here https://matrix.to/#/!EOygeDJPfJQOfNacqH:matrix.org/$cN3qQ_K_CdrMSYXUx3rDRUGs60gwX3Q_QlK3vzeEkIo?via=matrix.org&via=tchncs.de&via=mozilla.org

I have used it in Neon without changes for probably more than a year now; changes to default configuration could be an alternative solution compared to removing configuration support completely.
If the meaning of "mycroft.ready" is changing here, I would ask that this emit something less ambiguous (maybe "mycroft.intent_service.ready", or implement ProcessStatus directly for consistency with other modules that report state. mycroft.ready emit should be configurable (possibly with a deprecation warning) since the meaning of the event has changed; this would allow anyone wanting to restore backwards-compat. to emit that message with a plugin (i.e. the React GUI might want to wait for the GUI core service to start).

moved message to skill https://github.com/OpenVoiceOS/skill-ovos-boot-finished/pull/15


Reenable integration tests

I used the nativeWindowOpen option available in electron 1.7
I set the menu for each window. Before, when a window was created, the menu was added again and in every window.
On macOS the menu is shared, so win.setMenu does nothing. So I used Menu.setApplicationMenu which seemed to work ok(ish).
To merge it needs:

[ ] verify macOS
[ ] merge https://github.com/brackets-userland/brackets-electron/pull/97
[ ] rebase to master

I had some issues with shortcuts on multiple windows, but otherwise seemed to work fine.
But I don't think I'll be back to this anytime soon.


Add support for List annotated model fields

For instance, a field annotated as typing.List[str] will be mapped to pl.List(pl.Utf8).

Codecov Report

Merging #50 (ed39280) into main (b36f559) will decrease coverage by 87.36%.
The diff coverage is 2.04%.

@@             Coverage Diff              @@
##              main      #50       +/-   ##
============================================
- Coverage   100.00%   12.63%   -87.37%
============================================
  Files            7        6        -1
  Lines          926      554      -372
  Branches       216      141       -75
============================================
- Hits           926       70      -856
- Misses           0      484      +484

Impacted Files
Coverage Δ

src/patito/pydantic.py
3.35% <0.00%> (-96.65%)
:arrow_down:

src/patito/validators.py
2.46% <6.66%> (-97.54%)
:arrow_down:

src/patito/__init__.py
31.25% <0.00%> (-68.75%)
:arrow_down:

src/patito/polars.py
33.33% <0.00%> (-66.67%)
:arrow_down:

src/patito/sql.py
43.75% <0.00%> (-56.25%)
:arrow_down:

src/patito/duckdb.py

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Need to update docs for entities and rigidentities

Just wrote up some rough documentation for these

Fixed in #47


Populate array buffer with data in  attrib_t directly?

Hi
I found that in order to populate array buffer, all examples make a copy of every position, normal, etc to  create a new vertex.
I was wondering if there is a way to avoid it,  so we can populate array buffer directly from attrib_t? Current attrib_t contains all information for all the shapes, i have no luck in finding the boundary between shapes.
By the way, I'm new to opengl and tinyobjloader and .obj file.

tinyobjloader is not designed for OpenGL.
You can use callback API to load .obj data fit into your data structure

Callback should work.
Thanks for the help.

Callback API is the best solution for you, but there would be another solution: https://github.com/syoyo/tinyobjloader/blob/master/experimental/tinyobj_loader_opt.h
This is much more OpenGL friendly. Although I haven't tested yet, you may send attrib_t data to VertexBuffer directly, then pass shape_t::face_offset and shape_t::length to glDrawArrays(Assume you read .obj data with triangulation) to render each shape.


[Bug] Conversion from u64::MAX into RedisValue fails

Fred version - 9.0.3
Describe the bug
Attempt to set a key to u64::MAX fails:
conn.set("key", u64::MAX, None, None, false).await?;
// returns error `Redis Error - kind: Unknown, details: Unsigned integer too large`

Can be worked around by explicitly converting to string. But getting u64::MAX integer works fine:
// Using `to_string` works for setting.
conn.set("key", u64::MAX.to_string(), None, None, false).await?;

let v: u64 = conn.get("key").await?;
assert_eq!(v, u64::MAX); // passes

Yeah, I'm not sure there's a great solution here. The representation for numbers in redis and on the wire is a signed 64-bit integer, so I intentionally made anything >2^63 fail the automatic type conversion to avoid this kind of thing:
redis-main:6379> set foo<PHONE_NUMBER>3709551616
OK
redis-main:6379> decr foo
(error) ERR value is not an integer or out of range

If you're only operating on the value as a number in app code then I can see why this would be annoying, but the alternative approach of hiding a to_string, and thereby changing the allowed operations on the server, seemed worse in my opinion. The intention here was to make it explicit to the user that the underlying value must be stored and operated on as a string on the server.

Closing for now, but let me know you want to reopen or propose any changes for this.