Worn items bank menu incorrect weights

Describe the bug
When viewing worn items within the bank, all the item weights are +0.453 if you have the show weight setting enabled in item stats
Expected behavior
Should show proper item weights.
Environment

OS: Windows 10
RuneLite version: <IP_ADDRESS>
Launcher version: 2.1.0

Created pull request #11327


People are confused by adapter-static

Describe the problem
I've lost count of the number of times people have asked "why is my adapter-static build output missing index.html" (and other similar questions) in Discord. It's always fixed by either adding config.kit.adapter.fallback = 'foo.html' or config.kit.prerender.default = true. To be clear, this is in the documentation, and not having one of these settings does produce a yellow (?) warning during build, but I've found that people tend to lose the yellow warning in the output from build.
Describe the proposed solution
When trying to run svelte-kit dev or svelte-kit build, throw a full-on, red, crash-the-process error stating:
It looks like you're using adapter-static, but `config.kit.prerender.default` is `false` and `config.kit.adapter.fallback` is missing. Either set `config.kit.prerender.default` to true (to statically generate your entire site) or set `config.kit.adapter.fallback` to your desired fallback page (to operate in SPA mode). For more information, check out <link to FAQ in adapter-static docs about this issue>

Maybe I'm missing some context here, but I don't think there's any case where adapter-static should be run without one of those options set, and the fact that it "works" in dev confuses a lot of people.
Alternatives considered
No response
Importance
would make my life easier
Additional Information
Happy to work on this one if it's a feature we'd actually like to add.

There are use cases when you want to use adapter-static without prerendering or fallback, anyway it's good to warn about this... not throw error.

There are use cases when you want to use adapter-static without prerendering or fallback, anyway it's good to warn about this... not throw error.

There are use cases when you want to use adapter-static without prerendering or fallback

When?

I can second that this has been causing confusion for me. In earlier versions of Adapter Static, it was clear that you can render as a SPA by including config.kit.adapter.fallback, or pre-render all routes by including config.kit.prerender.enabled, but now I get messages suggesting that I need to use "hooks" to render as a SPA, but there isn't any documentation on how to do this.

Judging by the emoji reactions, this is something we should do. I also can't think of a situation where you'd want to use adapter-static without either prerendering by default or having a fallback.

@Rich-Harris Consider it done


dibs: I will implement all-your-base

dibs: I will implement all-your-base

PS: We will need to deprecate binary, trinary, octal and hexadecimal exercises after we merge this in. ref: https://github.com/exercism/x-common/issues/279 Not sure of the exact method of deprecating though.

@tejasbubane right about that.  @rchavarria the only thing about that process that still seems unclear to me is how to create an association between the old deprecated exercises and this new one.  It's not clear that there's any way to do that at this point, and I think it requires a change to the CLI globally.  We would also need to change this track's config.json file afterward.
Does it make sense to merge this exercise now, or do we need to wait until we have a way to deprecate the old ones?

Does it make sense to merge this exercise now, or do we need to wait until we have a way to deprecate the old ones?

There would be absolutely no harm in merging. This would be served as just another exercise.
In terms of deprecating, I think just adding the exercises to deprecated in config.json should do the job as per this document. I am not sure though.

I agree with @tejasbubane: it'll make no harm to add a new exercise.
What to do with binary and friends? According to https://github.com/exercism/x-common/issues/279 there is still some work to do, but there are some tracks that have already deprecated them (https://github.com/exercism/x-common/issues/279#issuecomment-264938769).
I would move binary and friends to deprecated in config.json, and I'd keep exercise implementations, as suggested in https://github.com/exercism/x-common/issues/279#issuecomment-265214041

Well that sounds good to me.
@javaeeeee would you like to move binary, trinary, and hexadecimal to deprecated?  If not I can do it as part of another PR.

Done!
On Sat, Dec 17, 2016 at 9:56 AM, Matthew Morgan<EMAIL_ADDRESS>wrote:

Well that sounds good to me.
@javaeeeee https://github.com/javaeeeee would you like to move binary,
trinary, and hexadecimal to deprecated? If not I can do it as part of
another PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/exercism/xecmascript/pull/250#issuecomment-267766955,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIezh_fX63Ktz-DDVgHjcvFD77LPRrAXks5rI_gagaJpZM4LHy4L
.

Looks like you forgot to remove the octal exercise @javaeeeee

Thank you @tejasbubane, OKAY

Fantastic! Just one little detail. The PR consist of multiple commits. Do you mind squashing them into a single one?

Done
On Mon, Dec 19, 2016 at 4:51 PM, Rubén Chavarría<EMAIL_ADDRESS>wrote:

Fantastic! Just one little detail. The PR consist of multiple commits. Do
you mind squashing them into a single one?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/exercism/xecmascript/pull/250#issuecomment-268089144,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIezh1dUFifT00s0RfXH4srwR-85DM3wks5rJvxdgaJpZM4LHy4L
.

Hmmm, I think there are more commits now. But don't worry, I'll merge them into a single commit into branch.
It seems to me you struggled with git and branches during the squash process. The other day, I talked to another contributor about how to squash commits (see https://github.com/exercism/xjavascript/pull/309#issuecomment-264655066). Let me know if you find the link and the commands useful.

Thank you, I'll take a look
On Tue, Dec 20, 2016 at 4:39 PM, Rubén Chavarría<EMAIL_ADDRESS>wrote:

Hmmm, I think there are more commits now. But don't worry, I'll merge them
into a single commit into branch.
It seems to me you struggled with git and branches during the squash
process. The other day, I talked to another contributor about how to squash
commits (see exercism/xjavascript#309 (comment)
https://github.com/exercism/xjavascript/pull/309#issuecomment-264655066).
Let me know if you find the link and the commands useful.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/exercism/xecmascript/pull/250#issuecomment-268366925,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIezh2N9q1sQKMKZMdkvZMmHnZ96-cjMks5rKEsZgaJpZM4LHy4L
.


Document how service account credentials work.

The documentation of our classes should describe how they work and/or reference existing documentation that does (maybe an introduction to Oauth2?)

@coryan
We documented use of Credential classes here
Should we include this information on landing page or Bigtable?

I think we are done with this.  The various classes in google/cloud/storage/oauth2 reference the right documentation, and the documentation of google::cloud::storage::Client links to those classes.
I am closing this, if you think something is missing please reopen.


use ClusterDeployment's CA data when validating vsphere credentials

When a vSphere ClusterDeployment defines the CA certificates Secret, use the CA certificate data when validating vSphere credentials.
The high-level client library doesn't allow providing a CA certificate early enough, so we need to implement a lot of the lower-level connection setup so that we can slip in the custom CA data when needed.

I put this together while the investigation into #1235 was fresh in my head.
This needs to be tested/verified against both a vSphere environment that doesn't need CA Secret data (ie properly signed and trusted certificates) and a vSphere environment using untrusted certificates.

/test e2e

/assign @abutcher
/cc @suhanime

/cc @akhil-rane
In case this is relevant for your current work.

/cc @akhil-rane
In case this is relevant for your current work.

ACM team is hoping this can be reviewed and merged ASAP so we can get a new hive build published.

ACM team is hoping this can be reviewed and merged ASAP so we can get a new hive build published.


Fixing opening draft and creating component

It's fixing the problem with opening the file - now it's loading the draft version if exists.
Fixing margins.
Fix the way a new file is created.

I wasn't able to reproduce the previous bugs, however I found two new issues:

When no component is present and I create a new component with a given name, this name is not assigned to the component. Instead a Draft-1 name is displayed.
I can't create more than two components - I have Draft-1 and Draft-0 files and when I click "Create a new component", nothing happens.

Fixed.

Thanks you @calebjacob

the main problem was with Draft-X files - I removed this mechanism and added Untitled-X and it’s working differently from the implementation point of view
change Creating New File flow - now you are not able to provide the name but you are able to rename it immediately - so it’s similar to how most of the ide’s a working
splash page
fixing drafts mechanism

LGTM 👍🏾 🚀


How can i get total active number of messages from service bus subscription of topic.

You can use the getSubscriptionRuntimeProperties() method on the ServiceBusAdministrationClient. Here is a sample that shows how to create this client and use some of the methods on them: https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/servicebus/service-bus/samples/v7/javascript/advanced/administrationClient.js


Singleton not thread safe

The singleton pattern is prone to synchronization errors and is not thread-safe. If multiple thread mutate the state of Push Raven, it will lead to an inconsistent state. The library is really great and I would like to contribute in it after some discussion over design patterns are done
I think we can achieve simpler syntax with production level design with minimal impact on current API

I am open to any suggestions, in fact the singleton implementation came about after issue #2

Sure. I will add the proposed changes here soon


Mark moment as invalid if bad string weekday repr is parsed, fixes #2423

Well, we were just not checking if the weekday was invalid.
I also found other issues related to the week-year, week, week-day parsing -- we don't do any overflow checks there, I'll submit it as another issue.

:+1: LGTM

Merged in 8620c53e41a11151be1ed008175130acc717799e


[PL-50559] Adding note for OIDC connector

PL-50559
This doc change is in reference to the request made on PL-49120
Note added:
:::info note
OIDC authentication support is not available for any connectors in Legacy Delegates.
The support for OIDC is made available and tested from Delegate versions 24.03.82600 and higher.
:::
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

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

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

Handled under separate PR. You can close this.

I have removed this from all irrelevant locations as suggested by April and Brian. Please review and let me know if there are any other places where this could be added. Currently, out of a total of 7 files containing OIDC references, I have removed it from 6, leaving it present only in the GCP connector document. We also need to include a mention of this where the AWS Connector is referenced for OIDC authentication.
@brian-f-harness

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

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

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

@saifeemustafaqharness This PR can be closed. Doc was added here - https://github.com/harness/developer-hub/pull/6526


documentation issue in /migrate-from/google-dialogflow-to-rasa

Rasa version: 2.4.0
Rasa SDK version (if used & relevant):
Rasa X version (if used & relevant):
Python version:
Operating system (windows, osx, ...):
Issue: The documentation in Step 5 to send a request to the server using the Dialogflow emulation mode does not mention when starting the server, the --enable-api tag is needed. If you attempt to send the request to the server without the tag, /model/parse can't be found.
Error (including full traceback):

Command or request that led to error:
curl 'localhost:5005/model/parse?emulation_mode=dialogflow' -d '{"text": "hello"}'

Content of configuration file (config.yml) (if relevant):

Content of domain file (domain.yml) (if relevant):

I'll submit the fix to the documentation.


Following behavior of COSMAC VIP for BNNN and not for LD [I], VX

Firstly, I must thank you for your test rom. It helps me confident with my implementation.
Although, I have something to ask:
I ran your test rom (https://github.com/Skosulor/c8int/blob/master/test/c8_test.c8) through my own interpreter.
While your rom checks for behavior of BNNN instead of BXNN - just like COSMAC VIP chip-8 interpreter -
it doesn't increase I after LD [I], Vx or LD Vx, [I] instruction.
So the test rom reports that my implementation is wrong for BNNN (14 number displayed).
Is this behavior of your test rom expected?
It mismatches behavior of old COSMAC VIP for BNNN and not for LD [I], VX.

Hello, glad it helps!
I have not heard about the COSMAC VIP chip-8 interpreter and I'm not sure what you mean by that it doesn't increase I after LD [I].
The test is quite simple, it sets v0 to 4 and then calls a BNNN to jump forward 4 steps (NNN which is equal to current PC + V0).
If the jump would be shorter or just a step forward then the ROM will stop error checking and display number 14.
Have you tried stepping through the code as see what happens? In line 16 at https://github.com/Skosulor/c8int/blob/master/test/chip8_test.txt you can see the test for BNNN

Hi, you could find info about behavior of LD [I] in this excellent guide https://tobiasvl.github.io/blog/write-a-chip-8-emulator/#fx55-and-fx65-store-and-load-memory, also in in Note (d section in wiki page: https://en.wikipedia.org/wiki/CHIP-8#Notes

The test is quite simple, it sets v0 to 4 and then calls a BNNN to jump forward 4 steps (NNN which is equal to current PC + V0).
If the jump would be shorter or just a step forward then the ROM will stop error checking and display number 14.

Oh i see what you mean now. The test rom was made for the modern take on chip8 interpreter so its not strange that it fails. It shouldn't display 14 though but the test rom can be wrong depending on how an instruction is implemented.
I don't think i will spend any time on fixing this but i will pin this issue for anyone else making an interpreter based on the one for the COSMAC and happens to stumble across my test rom.

The test rom was made for the modern take on chip8 interpreter so its not strange that it fails

Maybe my words were not clear. BNNN is a standard behaviour of COSMAC VIP chip-8. BXNN is newer behavior on superchip and chip-48 interpreters.

I don't think i will spend any time on fixing this but i will pin this issue for anyone else making an interpreter based on the one for the COSMAC and happens to stumble across my test rom.

That's understandable. Have a nice day!

I added a license in the root of the repository as well.


🐛 Weird animation in NavigationView

One of the animations is not disappearing.
https://user-images.githubusercontent.com/351125/191164804-9f1e4c49-3fe5-416a-b6f0-a662b3bde66f.mov

I'm not sure to understand the problem ? Is the sticky animation the problem ? Seems ok to me.

The animation should disappear, not "jump" when disappearing. On windows it doesn't jump.

Can you try on the official WinUI 3 Gallery app? To my eyes, the animation is similar

Here it goes in slow motion:
https://user-images.githubusercontent.com/351125/192128401-51073f5e-56b1-4adf-bf5a-00ac8a8ba7a0.mp4

I believe that the WinUI 3 Gallery app has a bug :/ because the animation looks different everywhere else

The animation appear for me too, in a test app I'm building. The line transition between items is slow

Can you try on the official WinUI 3 Gallery app? To my eyes, the animation is similar

I believe it's fixed in the newer version of WinUI 3 Gallery (one with updated icon).
https://user-images.githubusercontent.com/98909696/230472692-198cbe4b-a1ba-48c2-b655-0ca004f240c5.mp4
If fixed in fluent_ui package, it'd really seem very sleek, and elegant looking.

TWinUI 3 Gallery (<IP_ADDRESS>) shows two different animations when switching between items in a NavigationView. One for items that have the same "logical" level:

And another one for items that have different levels:

To make it even more confusing, ListView uses an entirely different animation:

Personally, I think either one is just fine and I don't see a benefit in having different animations for these slightly different scenarios. Actually I'm wondering if this was even done on purpose...

I think the two different animations make sense. The ListView does not lead to or suggest any up/down movement in the ui and emphasizes selection more.

What do you mean by "up/down movement in the ui"?

The navigation view changing the main body page content. Like the current windows settings page. The pages slide in upwards.

I see.
Just for argument's sake: To me this explanation feels a little far fetched, as I think I remember seeing the page also "zoom in" on changing. But I might misremember this.
Also, the page always slides in upwards, whereas the animation's direction depends on whether you move your selection upwards or downwards. But maybe you're right and that was the intention behind the different designs.
Still: More of a hassle when recreating these widgets. ; )

It is true.. All these design guidelines change so much as well

Probably the listView one is when you don't know if the last one is up/down, since the list might be infinite. The other one is very limited, so it is easy to cache it came from up/down.


Avalonia quickstart

New Contributors:
please review CONTRIBUTING.md
Purpose:
Describe what this pull request accomplishes. If it addresses an issue, link to it here.
#574
New Functionality:
Describe what this pull request does using code and/or images.
The new quickstart is here: https://github.com/Benny121221/ScottPlot/blob/avalonia-quickstart/dev/website/quickstart.md
The only thing is that the picture looks a little weird, but I can't put my finger on why. If you think you can make a better screenshot by all means go ahead. I just ran the ScottPlot.Demo.Avalonia project so you shouldn't have to edit any code.

Hi @Benny121221, thank you for this! Looking at your quickstart I'm surprised how simple it is. I don't know what I was expecting... I thought preparing the Avalonia project would be harder for some reason (due to my Avalonia inexperience). In hindsight I probably could have figured this one out myself, but thank you for putting this together and I really appreciate all the effort you've been putting into the Avalonia control!


bad token hangs

If you enter a bad token for a cluster and attempt to add the UI hangs with spinning circle.  This occurred several times when installing/re-installing CAM on a cluster and forgetting to update the token for the cluster and using an outdated token.

CAM version 1.1.1


spec: consider well-known URIs for discovery

At FOSDEM someone suggested that a more well-specified/standardised means for serving discovery metadata would be to use well-known URIs instead of HTML meta tags - RFC5785.
The basic idea is that there is a centralised (IETF) registry of well-known URI names which are then exposed at $URLROOT/.well_known/$NAME. So in our case it would probably be .well_known/ac-discovery or so - and this endpoint could serve a simple JSON file or so with the URL templates. Presumably initially we would just do this "unofficially" and then at some point we could actually try to register it through the process described in 5.1
Arguably this is less intrusive than meta tags as it does not requite the HTML of the page(s) (whether root or leaves) to be modified.
I am not convinced it is necessarily appropriate ("well-known URIs are not intended for general information retrieval or establishment of large URI namespaces on the Web"), or a marked improvement  over meta tags, but throwing this up for discussion.

I think in any moderately large organization any form of discovery using the organization's bare domain is unlikely to fly for various reasons both political and technical.
The Marketing group that runs the example.com webserver probably won't understand or be capable of hosting this sort of metadata.  Your Security group probably won't be willing to take the risk that this data leaks to the public, mingled as it is with the company's public website.
So I think most folks are either going to end up with some container metadata specific hostname (e.g. ac.example.com/reduce-worker), or they're going to go the DNS record route being discussed in #3.
Presuming folks use a form of HTTP discovery, then the question in my mind is what is the easiest to build automation around?  People are going to want to run something like the Docker registry where users can push images and immediately deploy them.
The meta tag discovery mechanism requires statically or dynamically generating HTML pages with the requisite tags.  That's technically simple, but doesn't feel very clean.
This .well_known URI scheme doesn't feel very nice either.
Ignoring the "prefix-match" portion of the current meta tags (which seems unnecessary to me) how about using HTTP Link headers?  http://www.w3.org/wiki/LinkHeader  Then you don't have to return an HTTP body at all.

@jheiss I would say that an HTTP header raises the bar quite a bit higher than serving up HTML. For example most cloud object stores make you jump through a lot of hoops to add a custom header.
The prefix-match portion is necessary so that you can host different projects at different hosting providers. For example example.com/open-source-project might be hosted as a simple github.com container but example.com/enterprise-edition might be a super sophisticated geo-replicated thing with auth.
Also, returning a full body isn't necessary, you can just return a body with just meta tags if you have a "smart" registry that checks the ?ac-discovery=1 GET parameter.
I agree that alot of orgs won't want to use their official corporate domain but for a lot of the public projects that you can imagine being in containers like databases, webservers, programming languages, etc I don't think it is a huge stretch of the imagination.

On the main point I have never really seen this well-known scheme used in practice: http://www.iana.org/assignments/well-known-uris/well-known-uris.xml
The notable exception being keybase: https://keybase.io/docs/keybase_well_known

I just started to read the spec and my first impulse was to fill the same issue. Please don't make up your own stuff for things that already have RFCs!

Like others, I just came to this issue after trying to understand the discovery process.
While using html meta tags for the discovery have some advantages, it requires a dedicated html page for each image (with a dedicated url that can conflicts with your website content).
So, having site wide meta information will probably be more scalable and easier to put in place.
In that perspective, .well-known url and DNS entries are existing mechanisms to give website-wide meta information.
For reference, caldav and carddav defines a service discovery mechanism based on DNS entries with a fallback to .well-known uri; for reference, see rfc6764. With some adaptations, this mechanism can be used for appc.
Some other uses of .well-known uri includes:

Let's Encrypt with the acme protocol
Open ID connect; see also google's implementation

Just my 2 cents on this issue.

We discussed well-known to a large degree in the past. I am not opposed to
adding it to the spec if someone wants to do the work.
The two reasons we didn't end up using the well-known in the past:

We were inspired by the Go spec on this which is very similar with meta
tags

The number of well-known users at the time we started appc was small and
didn't seem to be growing. Notice that only 1 was added in 2014 and now
nearly half were added in the last 3 months of 2015!
https://www.iana.org/assignments/well-known-uris/well-known-uris.xml

On Fri, Jan 22, 2016 at 2:25 AM Olivier Samyn<EMAIL_ADDRESS>wrote:

Like others, I just came to this issue after trying to understand the
discovery process.
While using html meta tags for the discovery have some advantages, it
requires a dedicated html page for each image (with a dedicated url that
can conflicts with your website content).
So, having site wide meta information will probably be more scalable and
easier to put in place.
In that perspective, .well-known url and DNS entries are existing
mechanisms to give website-wide meta information.
For reference, caldav and carddav defines a service discovery mechanism
based on DNS entries with a fallback to .well-known uri; for reference, see
rfc6764 http://tools.ietf.org/html/rfc6764. With some adaptations, this
mechanism can be used for appc.
Some other uses of .well-known uri includes:

Let's Encrypt https://letsencrypt.org/ with the acme protocol
https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md
Open ID connect
http://openid.net/specs/openid-connect-discovery-1_0.html; see also google's
implementation
https://developers.google.com/identity/protocols/OpenIDConnect

Just my 2 cents on this issue.
—
Reply to this email directly or view it on GitHub
https://github.com/appc/spec/issues/160#issuecomment-173871741.

Following up on this I think a combination of SRV record which can specify the location of the server from which a GET /.well-know/ac-discovery call would work should be a sufficient combination which follows relevant RFCs, is extensible enough to be used by a large number of operators, and would support failover nicely.  I would foresee a record of the form:
_acdiscovery._tcp.example.com.   300  IN SRV 10 10  8080 int-ac-discovery.example.com.


ImageWriter : When writing images that don't support separate dataWindow geometries, what should be written?

If you have an image stream where the data window is a different size from the display window, and you write out to an image format that doesn't support a separate data window size (I'm not sure which formats other than EXR support this), then it will write the Data Window as the image rather than the DisplayWindow (and pad with black)
This is something that is default in OpenImageIO, although there is an option to go the other way.
To replicate this, try this script:
import Gaffer
import GafferImage
import IECore

__children = {}

__children["Constant"] = GafferImage.Constant( "Constant" )
parent.addChild( __children["Constant"] )
__children["Constant"]["color"].setValue( IECore.Color4f( 1, 0, 0, 1 ) )
__children["Constant"].addChild( Gaffer.V2fPlug( "__uiPosition", defaultValue = IECore.V2f( 0, 0 ), flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic, ) )
__children["Constant"]["__uiPosition"].setValue( IECore.V2f( 42.2617569, -6.26819324 ) )
__children["Constant"].addChild( Gaffer.V2fPlug( "__uiPosition1", defaultValue = IECore.V2f( 0, 0 ), flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic, ) )
__children["ImageTransform"] = GafferImage.ImageTransform( "ImageTransform" )
parent.addChild( __children["ImageTransform"] )
__children["ImageTransform"]["transform"]["scale"].setValue( IECore.V2f( 1, 0.5 ) )
__children["ImageTransform"]["transform"]["pivot"].setValue( IECore.V2f( 0, 540 ) )
__children["ImageTransform"].addChild( Gaffer.V2fPlug( "__uiPosition", defaultValue = IECore.V2f( 0, 0 ), flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic, ) )
__children["ImageTransform"]["__uiPosition"].setValue( IECore.V2f( 42.2626305, -15.4322557 ) )
__children["ImageTransform"].addChild( Gaffer.V2fPlug( "__uiPosition1", defaultValue = IECore.V2f( 0, 0 ), flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic, ) )
__children["ImageWriter"] = GafferImage.ImageWriter( "ImageWriter" )
parent.addChild( __children["ImageWriter"] )
__children["ImageWriter"]["fileName"].setValue( 'test.exr' )
__children["ImageWriter"].addChild( Gaffer.V2fPlug( "__uiPosition", defaultValue = IECore.V2f( 0, 0 ), flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic, ) )
__children["ImageWriter"]["__uiPosition"].setValue( IECore.V2f( 31.4692802, -24.5963173 ) )
__children["ImageWriter"].addChild( Gaffer.V2fPlug( "__uiPosition1", defaultValue = IECore.V2f( 0, 0 ), flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic, ) )
__children["ImageWriter1"] = GafferImage.ImageWriter( "ImageWriter1" )
parent.addChild( __children["ImageWriter1"] )
__children["ImageWriter1"]["fileName"].setValue( 'test.png' )
__children["ImageWriter1"].addChild( Gaffer.V2fPlug( "__uiPosition", defaultValue = IECore.V2f( 0, 0 ), flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic, ) )
__children["ImageWriter1"]["__uiPosition"].setValue( IECore.V2f( 50.6353607, -25.2374325 ) )
__children["ImageWriter1"].addChild( Gaffer.V2fPlug( "__uiPosition1", defaultValue = IECore.V2f( 0, 0 ), flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic, ) )
__children["ImageWriter1"].addChild( Gaffer.V2fPlug( "__uiPosition2", defaultValue = IECore.V2f( 0, 0 ), flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic, ) )
__children["ImageTransform"]["out"].setInput( __children["ImageTransform"]["__implementation"]["out"] )
__children["ImageTransform"]["in"].setInput( __children["Constant"]["out"] )
__children["ImageWriter"]["in"].setInput( __children["ImageTransform"]["out"] )
__children["ImageWriter1"]["in"].setInput( __children["ImageTransform"]["out"] )

del __children

I would have expected both the resulting images to be 1920x1080, with the PNG having black bars top and bottom (as in the viewer in Gaffer), but that one actually comes out as 1920x540
In any compositing sense, the display window is the important part for the size of the image, with the data window being there for either overscan or for efficiency in only having part of the image needing to have pixel values defined.
There was a big discussion about this concept on the OIIO mailing list a few years ago, which I managed to instigate, and a lot of people on there felt that the data window should be considered the "image" when converting.
oiiotool now has a "--noautocrop" command-line flag to ensure that the full display window is written out to any image format that doesn't support separate data and display windows.

I would vote for "pad with black", as in I see the display window as being the image size and the datawindow as mostly being an optimisation (ignoring overscan). Do you know the right incantations to make OIIO do that Hugh? If so, fancy making a pull request?

Not off the top of my head, but yeah, I know where to look. I need to get my own branch of gaffer properly building/working (I've been using the binaries so far) and I'll find the fix and put it in as a pull request.
I'm thinking that it would default to pad, but there would be an option on the ImageWriter node to "only write data window"

My intention with Gaffer is to keep each node doing one thing (and one thing only) well, and to limit the proliferation of lots of little "do it a bit differently" toggles. The power of node-based applications comes from having lots of well-designed nodes which are each relatively simple but interoperate well to build all sorts of more complex permutations. So I'd argue for no "only write data window" toggle, and a Crop node (or some such) which can be placed in front of the writer if and when desired.
We're putting a lot of work into the Box node, UIEditor and API to allow people to easily build their own nodes via the UI or scripting, so I think the default position for stuff built into Gaffer should be "keep it simple", followed by "if you want it complex/customised, we encourage you to build in-house solutions from our building blocks".

I am absolutely fine with doing that - personally it's what I would want as default behaviour, I just wanted to cater for all types! If there isn't already a node to crop to data window, I may look at doing that one too.

Interesting point John, which makes me wonder how you'd feel about the other plugs I've realized we need on the ImageWriter (for processing EXRs at IE)... we need control over bitdepth (per-channel?) and compression mode. We'll probably eventually want other plugs for control over other file formats as well. To me, those all seem tightly tied to the writer, though maybe you could argue bitdepth should be affecting the in-app data representation instead? I think at some point we decided that'd be a pain in the butt and the in-app data should always be float, right?
I was also planning to add an ImageDescription plug, since the writer seemed the most logical place for a user to say "this is what my image is about", but it could be argued that belongs on a StandardMetadata node or some such instead...

Yeah, I think lots of extra plugs for exr/tiff/etc options is probably unavoidable. But I don't see that as contradicting what I was saying above - those settings are fundamental to writing images usefully, and couldn't usefully belong on another node (unless we got into a metadata-affects-processing mindset, which we decided we don't want).
I suggest we parent all the exr options under a top-level "exr" plug, and all the tiff ones under a top-level "tiff" one, and so on. That way it's very clear what is used when, and we can also hide/show them easily as a group via activators based on the filename. I'm tempted to say the current tiled/scanline setting should actually move under these format-specific sections, since it's only relevant for a small subset of them.
For the description I think I would prefer that to be on a StandardMetadata node. I can imagine wanting to make a custom node or box which not only processes an image but also adds to the description to say what it has done, and possibly even have a series of these that all collaborate to make a compound description. So doing it beforehand via metadata would be more powerful.

Just so you know, because you're writing straight to an ImageOutput object, rather than via an ImageBuf, the built-in OIIO method for doing this isn't available. I think it would be cleaner to keep it working this way, and add the functionality to pad with black (or crop off data outside the displayWindow) manually into ImageWriter::execute(). Unless of course you think it'd be better to change execute() to write to an ImageBuf and then use OIIO to crop/pad it and then pass this straight to an ImageOutput.

I think it depends on whether or not we think it's a good idea to generate the image in one big buffer before writing or not, since both our current approach and the ImageBuf approach do that. It seems that it might be better to do the whole thing progressively so we can deal with huge images without memory spikes.

Well, I've already done the scanline version (it needs more testing, but at a glance, it appears to work), and I need to implement it for tiles too. I'm just doing it straight in the ImageWriter code, passing 0s through when there isn't the image data for it.

Closing this, as was merged in #1419


chore: bdd-spring-1586845631 to 0.0.1

chore: Promote bdd-spring-1586845631 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


[Feature Request] Make concurrency field accepts multiple values

Hi. I think it would be great if runn accepts multiple values in the concurrency: field.
Current behavior
Only one string can be specified to the concurrency: field. Runbooks with the same key are assured of a single run at the same time.
Expected behavior
One string or multiple strings (list) can be specified to the concurrency: field. Runbooks with any of the same keys are assured of a single run at the same time.

Looks good to me!


rdkafka memory issue

First wonderful project, i've watching from the sidelines and really excited about pushing for first class python tools in the kafka ecosystem.
I have started testing the new rdkafka support in 2.1.0 and i do see a throughput improvement (yeah!), but there appears to be a memory leak. My attempts to implement memory profiling have come up with very little because the tooling around C extensions is limited and my knowledge is even less.
I'm going to dig deeper next week but wanted to put a note here to see if anyone else run into this.
I am deploying these workers as docker containers, so i am not ruling out some issue with my container setup, but below is a chart of memory.rss for the same container. The flat lines are configured use_rdkafka=False, the ominous slanted line only difference is use_rdkafka=True. These are configured from envvars so the underlying images are the same.

Sorry for the vagueness of this, i work on getting some better threads to pull on next week.
My setup:
pykafka 2.1.0
rdkafka 0.8.6

@jofusa thanks for reporting this! Are you seeing this with a producer or consumer? And can you give me an idea of what kind of message volume you're moving over the time of that plot? (I made some last-minute updates to how producer delivery-reporting works just before we released 2.1.0, and so I wonder if your graph is showing that that somehow leaks protocol.Message references...)
Thanks!

This worker is using both a consumer and a producer. I can tun off the producer to help isolate the issue.
The message rates aren't crazy ~500/s per a worker.
Also here is the obligatory crash:

Removing the producer did not stop the issue. Still creeping memory like before

Thanks @jofusa I think I found the problem: pretty ugly double-definition that slipped in last month! It should be fixed by #381. As you said, the tooling is a bit lacking - I'm not sure how to write a straightforward test case that would detect this, eg I can't get gc.collect() to warn me about this one.

Thanks for fixing! thats a nasty one. who said C extensions were hard...
I tried this with no luck. https://pythonhosted.org/Pympler/muppy.html
At some point, aggregate cpu hours are what is needed. Which means RCs and a willing community.

@emmett9001, this would be the reason for the crazy memory usage earlier.

That'll do it. I'll be making a new release before EOD tomorrow.


Add an option to let go remote signer respond directly through webhooks.

#89  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @zhenlu and the rest of your teammates on  Graphite


Improve handling of errors when parsing pathConf commands

Currently, if arguments or options are wrong, only the usage of pathConf will be displayed.
This PR makes sub-commands' help messages available when argument or option parsing fails.
A new integration test is added to enforce the new behavior.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3452/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3453/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3454/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3457/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3458/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3468/
Test PASSed.

alluxio-bot, merge this please


Use pull_request_target instead for auto notify bot

Follow-up for #5538
https://github.com/peter-evans/create-or-update-comment

Note: In public repositories this action does not work in pull_request workflows when triggered by forks. Any attempt will be met with the error, Resource not accessible by integration. This is due to token restrictions put in place by GitHub Actions. Private repositories can be configured to enable workflows from forks to run without restriction. See here for further explanation. Alternatively, use the pull_request_target event to comment on pull requests.

@kmaehashi Failed to backport automatically.

Git command failed with code 1
Command: ['git', '-C', '/tmp/bp-f045du7d/work', 'push', 'https://github.com/chainer-ci/cupy', 'HEAD']

@kmaehashi Failed to backport automatically.

Git command failed with code 1
Command: ['git', '-C', '/tmp/bp-lardv04z/work', 'push', 'https://github.com/chainer-ci/cupy', 'HEAD']

Ignore errors above.


Containers fail to start due to "(409 Client Error: Conflict ("Conflict. The name "" is already in use by container . You have to remove (or rename) that container to be able to reuse that name."))"

Server version - Build from master
Lot of container deployment failures are seen when trying to upgrade/rollback a service , reconcile a service.
This  causes the service to be stuck in "Upgrading" /"Rolling-Back"/"Degraded" state for a very long time. Sometimes they are stuck forever.
Following error is seen when container deployment fails:
(409 Client Error: Conflict ("Conflict. The name "r-hello_hello123_1" is already in use by container b5e406b5dffb. You have to remove (or rename) that container to be able to reuse that name."))

Tested with v0.55.0-rc3:
This issue is not seen anymore where services are stuck in "Upgrading" /"Rolling-Back"/"Degraded" when upgrading/rollbacking/reconciling services.

Rancher Release - v0.59.1
This issue appeared again. Even if the service and its containers are deleted, unless you restart the agent on that specific host when the container is starting it gives you:
Containers fail to start due to "(409 Client Error: Conflict ("Conflict. The name "" is already in use by container . You have to remove (or rename) that container to be able to reuse that name."))".
I can confirm that the container shown in the error did not exist on the host.
Unfortunately I cannot give you more information on how to reproduce this bug.

@manei I am unable to reproduce.
If you are launching services, it doesn't matter what host the containers are on. It's a matter of whether the same service with the same name exists in a particular stack.  That's the only check that Rancher performs when adding services.
If you are adding containers to a specific host, there is no name restriction for standalone containers in Rancher.

I ended up looking in Docker and it looks like you might be hitting one of their open issues.
https://github.com/docker/docker/issues/15311
What version of Docker are you using?

@deniseschannon thanks for the quick response
I'm using docker version 1.10.0 and it seems is actually a docker issue. It was really weird that rancher complained about not being able to deploy a container because the name it wanted to assign to it was already used by another container with an id which did not exist in docker engine.

I'm getting same error, for Prometheus stack, config container didn't start after healthcheck fail:
2017-02-01 06:13:31,228 ERROR [:] [] [] [] [cutorService-28] [.e.s.i.ProcessInstanceDispatcherImpl] Expected state running but got stopped: Error response from daemon: Conflict. The container name "/r-Prometheus-prometheus-prom-conf-1-f3b4308f" is already in use by container c62ca816958c4705c4c8e0a2470c0ebc6406fbc5fba044b9715cd4cf2a4c4b46. You have to remove (or rename) that container to be able to reuse that name.

agent restart didn't help, only deleting.
Docker version 1.13.0, build 49bf474
Rancher version v1.3.3

Still having this issue randomly on rancher 1.6.10 and docker 17.04.0-ce

Still having this issue randomly docker 18.03.1-ce

This issue is almost 2.5 years old and can't be used to indicate issues with current releases. Please file a new issue with versions used and steps to reproduce so we can investigate.

facing the same issue in Rancher V1.6

Any resolution , please provide me..

Docker -> preferences -> bug icon (top right) -> clean / purge data


SIRF VM: Error msg in reconstruct_measured_data.ipynb (PET)

In the notebook 'reconstruct_measured_data.ipynb' (PET notebooks) I get the error:
error: ??? "'Error opening file template.hs\n' exception caught at line 303 of /home/sirfuser/devel/buildVM/sources/SIRF/src/xSTIR/cSTIR/cstir.cpp; the reconstruction engine output may provide more information
after: lm2sino.set_up()
All the other notebooks went through without any problem.
Executed within VirtualBox 6.1.18 with the new .ova: SIRF_2.2.0_Python3.

This was fixed


Bump main for CI

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Help me With this plugin

Where is the autoevent.dll  cus I can't find this dll in file

Sorry, we have not compiled the plugin dll (yet). We will do so in a foreseeable future.


slurm-api version 1.0

Copying in from previous issue tracking - the next step is to break out this source into something more formal and usable including but not necessarily limited to:

[ ] - sapi libraries broken out from slurm-api program
[ ] - scontrol/slurm man page friendly fields in accordance with direction described at https://groups.google.com/forum/#!topic/pyslurm/lEGdCF-3iFA
[ ] - Swagger/Connexion
[ ] - Job submission directly using pyslurm sbatch integration instead of callouts
[ ] - Full build and configuration instructions based on el7

The timing on this may or may not fully line up with SLURM 19 compatibility, that will depend on when pyslurm with 19 compatibility is out.

Can't quite do all the above until pyslurm is further developed, but did best we could and covered quite a bit from above - released in 1.0


Interceptors

https://github.com/Lokeh/hx/commit/f8b755ecf21d954a675a7296a0d52b9f2abf6ad6 adds the API for registering interceptors. The default is currently to compile top-level hiccup, and to transform $ to calls to (compile-hiccup ...). Several people have commented on the use of $ so I'm considering switching that off by default.
There are currently two outstanding issues with the interceptor API:

How should lib consumers register interceptors?

Interceptors must be registered via CLJ code at macroexpansion time, but apps that use this library are primarily CLJS.

Modifying the interceptor stack as it's processed


[19.09] nexus: 3.18.1-01 -> 3.22.0-02 (backport)

Update for security.
CVEs: CVE-2020-10199, CVE-2020-10203, CVE-2020-10204
Motivation for this change
Backport of #83988
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@ironpinguin
@aespinosa
@Ma27

cc @grahamc could you take a look, ofborg seems to have problems here :)

@ofborg eval
"Thank you, GitHub, very cool!" (Sorry about this.)

@zaninime thanks for taking care of this!
@cole-h @grahamc thanks for taking a look at the ofborg issues!


Add user ID to full profile modal

We should show the user ID just above the role in the full user profile modal. This way, even if someone doesn't have access to the user's email address, they can verify the identity via the full profile UI.

@zulipbot claim

@zulipbot claim

Hello @zulipbot, yes I am still working on it. It should be done very soon!

@zulipbot claim


Supervisors attempt to restart the same actor if terminated before restart completes

In the scenario of an actor terminating repeatedly, the supervisor may handle the exit event while the previous exit event is still being handled.
There is no easy way to guard against this, but we should not crash the supervisor.
Repro

This is probably the one thing in Celluloid that causes me problems most often. If I understand @tarcieri:s comment on #233 correctly, this is not really considered problematic behavior? Or is there a difference between what @halorgium describes here and #233?
It seems a similar problem occurs when finalize crashes: the supervisor end up crashing too and my app dies (I can link a repro if needed). This means I have to be really careful what I put in initialize and finalize. More specifically, setting up connections of any kind in initialize is out of the question unless I want to rescue any possible exception that could arise, which seems to go against the "let it crash" principle. You can argue I should not do such things in initialize anyway and I'd agree, but with finalize it's different: here is my last chance of cleaning up and if any unforeseen exception is raised (for example due to trying to close a connection that was already closed, which caused the actor to terminate in the first place) the supervisor will go down.
Since, as I said, this is one of the trickier parts of using Celluloid for me, I'd like to ask about the status of this issue.
Is this not considered a problem? And if so, what are the recommended best practices?
If it is considered a problem, is there any consensus on or clear plan for how to handle it? And if so, what can I do to help?

After some more thought I wonder if the "best practice" might be to have one more level of supervisor. My current top-level supervisor directly supervises several pools and actors. If one of them raises an exception in initialize or finalize, there goes my entire app. If I had one more supervisor above my current top-level supervisor that wouldn't be the case. The rule of thumb then would be: "The top-level supervisor is only allowed to supervise other supervisors:" Opinions on this?

On Thursday, February 12, 2015, Felix Holmgren<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:

After some more thought I wonder if the "best practice" might be to have
one more level of supervisor.
Yes. You're describing the idea of a supervision tree, which is supported
by Celluloid and used heavily by both Erlang and Akka.

My current top-level supervisor directly supervises several pools and
actors. If one of them raises an exception in initialize or finalize,
there goes my entire app. If I had one more supervisor above my current
top-level supervisor that wouldn't be the case. The rule of thumb then
would be: "The top-level supervisor is only allowed to supervise other
supervisors:" Opinions on this?

A supervision tree is definitely the way to go.
--
Tony Arcieri

Moved to: celluloid/celluloid-supervision#5


Potential issue in DE when using a Posterior that does not include entire dataset

It's hard for me to tell if this is a bug. If I make a Posterior object on some subset of cells, shouldn't the following lines be in reference to the indices I already am using in the Posterior?
https://github.com/YosefLab/scVI/blob/6c9f43e3332e728831b174c1c1f0c9127b77cba0/scvi/inference/posterior.py#L379-L385

it looks like this is by default collecting all cells from the dataset then
? That sounds like an ill-behavior. By default this should return only
normalized values for the already selected cells ?
Romain
Romain Lopez
PhD candidate, EECS
UC Berkeley
<EMAIL_ADDRESS>+1<PHONE_NUMBER>
On Sat, Jan 11, 2020 at 12:34 PM Adam Gayoso<EMAIL_ADDRESS>wrote:

It's hard for me to tell if this is a bug. If I make a Posterior object on
some subset of cells, shouldn't the following lines be in reference to the
indices I already am using in the Posterior?
https://github.com/YosefLab/scVI/blob/6c9f43e3332e728831b174c1c1f0c9127b77cba0/scvi/inference/posterior.py#L379-L385
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/YosefLab/scVI/issues/557?email_source=notifications&email_token=AFCDZDZMLDZHJN526NRJ2DTQ5H7LBA5CNFSM4KFTC4AKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IFQZTYQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFCDZD6ZAJPX53IMSPHYZ33Q5H7LBANCNFSM4KFTC4AA
.


bug: compiles but errors around sending data to clients

I'm putting together a PR (https://github.com/malcolmstill/foxwhale/pull/51) to update to 0.8.0 and add some GitHub actions.
Whilst I've made sufficient changes to get foxwhale to compile, and I can (briefly) render weston-terminal (for example) I'm crashing when attempting to send data back. Clearly I can send some data but something is upsetting it.

Fixed by #51


Avian Wallet v3.1.0 - 17 weeks behind

I just downloaded the Avian wallet and extracted it. When I open it shows 17 weeks behind. I waited it for half an hour and it's still shows 17 weeks behind. Is it normal to be syncing that much time?
My network speed is 100Mbps and I'm located in Bulgaria (EU).
Machine specs:

OS: Windows 11
CPU: Intel Core i5-7300HQ
RAM: 8GB
Disk size: 500 GB (SSD) + 1TB HDD
Disk Type (HD/SDD): Both but the program is installed on the HDD with data also on HDD

Sorry didn't read enough info. Everything is okay now.


Match on events & XSelectInput mask

Hello !
First of all, thank you for those bindings, great work !
This is more some questions than issues :

How do you check for the received event with that lib ??

I tried this :
loop {
         let ev: *mut xlib::XEvent;
         unsafe {
             xlib::XNextEvent(dpy, ev);
         }

         match ev {
             xlib::XExposeEvent => println!("Ok"),
             _ => println!("Nothing"),
         }
     };

But it does not compile ( unresolved enum variant, struct or const XExposeEvent ) I'm new to rust, and I'm doing this little project with xlib & rust to learn both ^^ So my question should be stupid...

Secondly, is there anything to applying masks (like ExposeMask) to XSelectInput ? Or not for the moment ?

Thank you
Regards,
Peekmo

I don't know if anybody has written Rust code to process events using rust-xlib yet. It certainly doesn't look like it will work well right now, since XEvent isn't actually defined to take up any space. If you look at what the glutin library does, you can get a better sense of how this should be used - https://github.com/tomaka/glutin/blob/master/src/x11/ffi.rs#L1241

Similarly, https://github.com/tomaka/glutin/blob/master/src/x11/window/mod.rs#L455 should what your code should end up looking like.

In fact, it's more like the C code.
Thank you for your answer and for the link to Glutin :+1:

Is this not a valid bug in this xlib library though? Shouldn't this issue be kept open until actually resolved?


Raise a more verbose error message if vacuum type is not supported

As mentioned on #22:

Unfortunately my vacuum (Kogan G50) isn't supported, as the following result object is returned from the /v1.0/users/sweepers/file/{{device_id}}/realtime-map endpoint (also tested using postman):

{
    "result": [],
    "success": true,
    "t":<PHONE_NUMBER>473,
    "tid": "96969c6fb66a11eeb846e2ba4cc47aff"
}

Looks like my Robot Vac returns an empty result (but no error code), so it doesn't seem to be available.

This PR adds a slightly more verbose error message if a vacuum is not supported because there are no vacuum map results form the Tuya API.

Looks good! Thank you for your support!
Hopfully your vacuum will be supported if i get local communications up and running.


Fix ReferenceCountManagedChannel#incrementAndGetCount return type

What is the purpose of the change
Fix ReferenceCountManagedChannel#incrementAndGetCount return type
see more detail in #7794

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #7795 (63ed897) into master (1a7ca1e) will decrease coverage by 0.24%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master    #7795      +/-   ##
============================================
- Coverage     59.47%   59.22%   -0.25%
+ Complexity      556      554       -2
============================================
  Files          1083     1083
  Lines         43755    43754       -1
  Branches       6380     6362      -18
============================================
- Hits          26022    25913     -109
- Misses        14876    14975      +99
- Partials       2857     2866       +9

Impacted Files
Coverage Δ
Complexity Δ

...pc/protocol/grpc/ReferenceCountManagedChannel.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...ng/transport/dispatcher/all/AllChannelHandler.java
62.06% <0.00%> (-27.59%)
0.00% <0.00%> (ø%)

...ntext/event/AwaitingNonWebApplicationListener.java
48.48% <0.00%> (-24.25%)
0.00% <0.00%> (ø%)

...dubbo/common/status/support/LoadStatusChecker.java
46.15% <0.00%> (-15.39%)
0.00% <0.00%> (ø%)

...rg/apache/dubbo/remoting/utils/PayloadDropper.java
76.92% <0.00%> (-15.39%)
0.00% <0.00%> (ø%)

...ng/transport/dispatcher/WrappedChannelHandler.java
47.82% <0.00%> (-15.22%)
0.00% <0.00%> (ø%)

...bo/config/event/listener/LoggingEventListener.java
50.00% <0.00%> (-12.50%)
0.00% <0.00%> (ø%)

...in/java/org/apache/dubbo/common/utils/JVMUtil.java
81.13% <0.00%> (-11.33%)
0.00% <0.00%> (ø%)

...che/dubbo/remoting/transport/mina/MinaChannel.java
35.52% <0.00%> (-10.53%)
14.00% <0.00%> (-1.00%)

...o/remoting/transport/ChannelHandlerDispatcher.java
60.00% <0.00%> (-10.00%)
0.00% <0.00%> (ø%)

... and 26 more

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 1a7ca1e...63ed897. Read the comment docs.


Textures rescaling relative to UV maps

Description
The problem that I am experiencing is that when applying a new texture to a model, the texture seems to be applied using the same pixel scaling as the original image on the model.  So when applying the same image that is already there, it works perfectly but if you apply a differently sized image, it will appear on only part of the model.  Usually the width and height of UVs are 1 and 1 so that any size or aspect ratio of texture works with UVs and they will always be the same relatively, but it is not working properly now.  I did an experiment in Blender by playing around with the texture and found something which, to me, seems to be proof of exactly what is happening.
This issue appeared after a couple months of not making any changes, so the problem is definitely model-viewer.
Console, along with UV issue.

Blender experiment

Expected Result, which was working on model-viewer up until a while ago

Live Demo

https://01000001khan.github.io/AR-Speakers/founder.html?
switch the material using the drop down to Non Existent testing material to see the bug.

Version

model-viewer: vX.X.X
Not sure which version, just using https://unpkg.com/@google/model-viewer for the script src

Browser Affected

[x] Chrome, version: 97.0.4692.99 (Official Build) (64-bit)
[ ] Edge
[ ] Firefox
[ ] IE
[x] Safari

OS

[ ] Android
[x] iOS
[ ] Linux
[x] MacOS
[x] Windows

I just noticed that you're selecting multiple elements with the same id. ids can only be used once, and it appears you are trying to select all of the ids. Try using classes instead of id's if you are selecting multiple elements.


[HPO] Optional ray lightning and backup implementation

Issue #, if available:
Description of changes:

Change ray lightning to be optional because the support level of it remains unclear. Current strategy is to let user install ray lightning and the corresponding pytorch lightning themselves. We can consider adding ray lightning back in our setup.py after they support pytorch lightning 1.6, which is mandatory for 0.5 release.
Without ray lightning, we can still run trials in parallel but each individual trial won't be able to utilize multiple gpus.
Updated ray version for protobuf and hyperopt fix.
Extracted common logic of each adapter to abstract adapter.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Job PR-1828-3 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-1828/3/index.html

Job PR-1828-4 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-1828/4/index.html

Job PR-1828-5 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-1828/5/index.html


Error with Expo SDK 46

Hi! I got an error using useSWRNative after upgrading EXPO SDK to v 46.
com.facebook.react.bridge.ReadableNativeMap cannot be cast to java.lang.string
Anyone has bumped into this?

seems unrelated to swr, no?

Hi @nandorojo tks for your reply! I have found the issue, reading some of the official doc.
I was using it like this
const {data, error} = useSWRNative(
    [url_Endpoint + currentUser.docNumber, currentUser.access_token],
    fetcherToken, {revalidateOnFocus: true}
 )

And I changed it to:
const {data, error} = useSWRNative(
    [url_Endpoint + currentUser.docNumber, currentUser.access_token],
    ([url, token]) => fetcherToken(url, token), {revalidateOnFocus: true}
 )

I don´t fully understand why this was working before upgrading and then it wasn´t, but I'm glad if this could help someone with the same issue.


Using {unicode: true}

First of all, thanks for this project @leeoniya!
I am having an issue with {unicode: true}, I think. If I use { alpha: "a-zæøå" }, I can search for æøå without issue. From reading the docs, it seems to me that {unicode: true} is a slower but more general version of this, but I am not getting any results with {unicode: true}, instead I am getting a null which crashes the rest of my code:
{ alpha: "a-zæøå" }

{unicode: true}.

unicode: true by itself is not enough, you have to set the other options with it, as shown in the docs.

Thanks @leeoniya - seems you have to do
// Unicode / universal (50%-75% slower)
let opts = {
  unicode: true,
  interSplit: "[^\\p{L}\\d']+",
  intraSplit: "\\p{Ll}\\p{Lu}",
  intraBound: "\\p{L}\\d|\\d\\p{L}|\\p{Ll}\\p{Lu}",
  intraChars: "[\\p{L}\\d']",
  intraContr: "'\\p{L}{1,2}\\b",
};


Chat Continuation

Chat continuation does not appear to be working.
For instance if i type "/r This is a really long sentence that exceeds the amount of words accepted by minecraft to send to another player and or to the server because the default chat is terrible and Tabby Chat is the only thing that makes it better which is why I am so glad it is being developed for 1.8."  It would break up the sentence and send it as 2 or 3 different entries.
Right now all that gets sent is "/r This is a really long sentence that exceeds the amount of words accepted by minecra" and that is it even though i can type in the entire thing.  I believe what it used to do was take the command line and re-enter it after each break. but i could be wrong.
Hope these issues help and thanks for taking the time to update the plugin.

This is not implemented yet.


Test latest runtime upgrade

On devnet:
2023-05-25 07:38:24 🔔 Starting Smart Contract pallet storage cleaning
2023-05-25 07:38:24 🧼 Cleaning Smart Contract pallet storage [0/10]
2023-05-25 07:38:24 successfully billed contract with id 14776
2023-05-25 07:38:24 successfully billed contract with id 16781
2023-05-25 07:38:24 successfully billed contract with id 24927
2023-05-25 07:38:24 ✨ Imported #5953480 (0x5e10…36e2)
2023-05-25 07:38:24 [20922, 21052, 21224, 21859, 22713, 23192, 18082, 25680, 26404] contracts to bill at block 5953480
2023-05-25 07:38:24 offchain worker done.
2023-05-25 07:38:27 💤 Idle (11 peers), best: #5953480 (0x5e10…36e2), finalized #5953478 (0xf002…5ca0), ⬇ 40.4kiB/s ⬆ 29.1kiB/s
2023-05-25 07:38:30 🙌 Starting consensus session on top of parent 0x5e10cd3f9f7668672b92a514c83469cc1a6ac22232e7c6b5d34b78bdf03936e2
2023-05-25 07:38:30 🧼 Cleaning Smart Contract pallet storage [1/10]
2023-05-25 07:38:31 successfully billed contract with id 18082
2023-05-25 07:38:31 successfully billed contract with id 26404
2023-05-25 07:38:31 🎁 Prepared block for proposing at 5953481 (6 ms) [hash: 0xb1566ff0efe5985fd8625586ed0d30705e23c7f087c9a91f8351075849634b3d; parent_hash: 0x5e10…36e2; extrinsics (11): [0x3365…9c46, 0x1339…419a, 0xeb31…97c2, 0x72bc…c77c, 0x8753…bf2a, 0xe059…e2df, 0x17ec…40af, 0xf70b…6146, 0xc64d…419f, 0x80b1…91b3, 0x7085…9c4b]]
2023-05-25 07:38:31 🔖 Pre-sealed block for proposal at 5953481. Hash now 0xeb4189a7807658ecd66b0a0559d152c2dded78123757821d4ea3f179846757a7, previously 0xb1566ff0efe5985fd8625586ed0d30705e23c7f087c9a91f8351075849634b3d.
2023-05-25 07:38:31 ✨ Imported #5953481 (0xeb41…57a7)
2023-05-25 07:38:31 [21617, 21999, 23040, 23274, 18131, 23802, 25681, 26406] contracts to bill at block 5953481
2023-05-25 07:38:31 offchain worker done.
2023-05-25 07:38:32 💤 Idle (11 peers), best: #5953481 (0xeb41…57a7), finalized #5953478 (0xf002…5ca0), ⬇ 12.0kiB/s ⬆ 15.6kiB/s
2023-05-25 07:38:36 🧼 Cleaning Smart Contract pallet storage [2/10]
2023-05-25 07:38:37 successfully billed contract with id 18131
2023-05-25 07:38:37 ✨ Imported #5953482 (0xe73e…b9cd)
2023-05-25 07:38:37 No contracts to bill at block 5953482, index: 282
2023-05-25 07:38:37 offchain worker done.
2023-05-25 07:38:37 💤 Idle (11 peers), best: #5953482 (0xe73e…b9cd), finalized #5953479 (0x95ea…0bca), ⬇ 15.2kiB/s ⬆ 12.0kiB/s
2023-05-25 07:38:42 🧼 Cleaning Smart Contract pallet storage [3/10]
2023-05-25 07:38:42 ✨ Imported #5953483 (0x6368…870a)
2023-05-25 07:38:42 No contracts to bill at block 5953483, index: 283
2023-05-25 07:38:42 offchain worker done.
2023-05-25 07:38:42 💤 Idle (11 peers), best: #5953483 (0x6368…870a), finalized #5953480 (0x5e10…36e2), ⬇ 11.1kiB/s ⬆ 12.5kiB/s
2023-05-25 07:38:47 💤 Idle (11 peers), best: #5953483 (0x6368…870a), finalized #5953481 (0xeb41…57a7), ⬇ 10.8kiB/s ⬆ 12.0kiB/s
2023-05-25 07:38:48 🧼 Cleaning Smart Contract pallet storage [4/10]
2023-05-25 07:38:48 ✨ Imported #5953484 (0x304a…2608)
2023-05-25 07:38:48 No contracts to bill at block 5953484, index: 284
2023-05-25 07:38:48 offchain worker done.
2023-05-25 07:38:52 💤 Idle (11 peers), best: #5953484 (0x304a…2608), finalized #5953482 (0xe73e…b9cd), ⬇ 13.4kiB/s ⬆ 11.1kiB/s
2023-05-25 07:38:54 🧼 Cleaning Smart Contract pallet storage [5/10]
2023-05-25 07:38:54 ✨ Imported #5953485 (0xa865…714f)
2023-05-25 07:38:54 No contracts to bill at block 5953485, index: 285
2023-05-25 07:38:54 offchain worker done.
2023-05-25 07:38:57 💤 Idle (11 peers), best: #5953485 (0xa865…714f), finalized #5953483 (0x6368…870a), ⬇ 11.4kiB/s ⬆ 9.9kiB/s
2023-05-25 07:39:00 🙌 Starting consensus session on top of parent 0xa8659c8c447efcdd4fb4c4b05a8754f6c223b7d29b7d5013215933cb1e7c714f
2023-05-25 07:39:00 🧼 Cleaning Smart Contract pallet storage [6/10]
2023-05-25 07:39:00 🎁 Prepared block for proposing at 5953486 (1 ms) [hash: 0x9781a4937f60ed40ea7696094d791ca2fd65a6ee799eabd2d01ec75fe995d511; parent_hash: 0xa865…714f; extrinsics (1): [0x7584…fd5a]]
2023-05-25 07:39:00 🔖 Pre-sealed block for proposal at 5953486. Hash now 0x53cc7c8c7c3d3df6cc9d13d61a19ea9fe1bf7346de4261c3d07f3adcf3e53e19, previously 0x9781a4937f60ed40ea7696094d791ca2fd65a6ee799eabd2d01ec75fe995d511.
2023-05-25 07:39:00 ✨ Imported #5953486 (0x53cc…3e19)
2023-05-25 07:39:00 No contracts to bill at block 5953486, index: 286
2023-05-25 07:39:00 offchain worker done.
2023-05-25 07:39:02 💤 Idle (11 peers), best: #5953486 (0x53cc…3e19), finalized #5953484 (0x304a…2608), ⬇ 11.7kiB/s ⬆ 12.5kiB/s
2023-05-25 07:39:06 🧼 Cleaning Smart Contract pallet storage [7/10]
2023-05-25 07:39:06 ✨ Imported #5953487 (0xb351…d643)
2023-05-25 07:39:06 No contracts to bill at block 5953487, index: 287
2023-05-25 07:39:06 offchain worker done.
2023-05-25 07:39:07 💤 Idle (11 peers), best: #5953487 (0xb351…d643), finalized #5953485 (0xa865…714f), ⬇ 10.9kiB/s ⬆ 11.4kiB/s
2023-05-25 07:39:12 🧼 Cleaning Smart Contract pallet storage [8/10]
2023-05-25 07:39:12 ✨ Imported #5953488 (0x56d7…c94b)
2023-05-25 07:39:12 No contracts to bill at block 5953488, index: 288
2023-05-25 07:39:12 offchain worker done.
2023-05-25 07:39:12 💤 Idle (11 peers), best: #5953488 (0x56d7…c94b), finalized #5953485 (0xa865…714f), ⬇ 11.5kiB/s ⬆ 10.7kiB/s
2023-05-25 07:39:17 💤 Idle (11 peers), best: #5953488 (0x56d7…c94b), finalized #5953486 (0x53cc…3e19), ⬇ 10.3kiB/s ⬆ 9.0kiB/s
2023-05-25 07:39:18 🧼 Cleaning Smart Contract pallet storage [9/10]
2023-05-25 07:39:19 price 12
2023-05-25 07:39:19 storing average now
2023-05-25 07:39:19 average price 12
2023-05-25 07:39:19 ✨ Imported #5953489 (0x51aa…b25a)
2023-05-25 07:39:19 No contracts to bill at block 5953489, index: 289
2023-05-25 07:39:19 offchain worker done.
2023-05-25 07:39:22 💤 Idle (11 peers), best: #5953489 (0x51aa…b25a), finalized #5953487 (0xb351…d643), ⬇ 14.6kiB/s ⬆ 12.1kiB/s
2023-05-25 07:39:24 🧼 Cleaning Smart Contract pallet storage [10/10]
2023-05-25 07:39:24 🔔 Ending Smart Contract pallet storage cleaning
2023-05-25 07:39:24 ✨ Imported #5953490 (0x8043…3397)

Let's see how this behaves after being executed.


Progress Steps Indicator - bug fix #1409

Q
A

Bug fix?
[X ]

New feature?
[ ]

New sample?
[ ]

Related issues?
#1409

What's in this Pull Request?
added missing image

@joaojmendes thanks!


Add a .nojeykll file to ensure Github Pages includes TypeDoc module files

Change-type: patch

@imrehg Good catch, I'd put it in the wrong place. :)

Was this missing a connects-to: ?

It was indeed.
Connects-To: #121


Support ImGui viewports (multiple windows)

https://github.com/ocornut/imgui/wiki/Multi-Viewports
https://docs.godotengine.org/en/latest/classes/class_window.html

Here's a fun example:
GDScript, but may prove useful as Impl reference.
https://www.reddit.com/r/godot/comments/xr8yxn/learning_a_godot_40_window_node/
https://github.com/gongpha/godot4-window-test


Strong mode implicit generic instantiations should be limited to known targets

[Update: 2018.06.05]  The new CFE implements this correctly, analyzer handles all but the generic function typed variable case correctly.
Per language team decision, we will not support implicit instantiation (via inference) of arbitrary function expressions, but instead only for statically resolvable tearoffs. That is, a reference to a generic function declaration or a closurization of a generic method can be simultaneously instantiated at the tearoff point, but a general function expression cannot be.
Examples:
void take(int f(int x)) {}

T foo<T>(T x) {}

class A {
  T bar<T>(T x) {}
}

T Function<T>(T x) returnFoo() => foo;

void test() {
  T baz<T>(T x) {};
  take(foo); // instantiated to int
  take((foo)); // instantiated to int
  take(new A().bar); // instantiated to int
  take (baz); // instantiated to int
  take(<T>(T x) => x); // Error, not instantiated
  var g = foo;
  take(g); // Error, not instantiated
  take(returnFoo()); // Error not instantiated
}

[Updated 2017.06.02 with bug fix]

@leafpetersen is this critical for 1.22?

No, doesn't need to be 1.22 at all.  Very small change in inference, no impact on non strong mode code.

This feature has been reversed.


"x509: failed to load system roots and no roots provided" when using grafana slack alerts

maybe root CA certificates are missing from the docker image?

They most likely are missing from the Docker image, which I (personally) see as best practice, as root CAs might be revoked or updated, meaning your image will eventually become incompatible with newer certs (or, conversely, a certificate that should no longer be trusted may be trusted)
I think best practice here is to pass through /etc/ssl/certs from your host machine. Alternatively, an init container with a shared emptyDir at /etc/ssl/certs can be used to populate the directory.

Thanks @munnerz, I used volumeMount

I tried this, and it didn't work (error persists)
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: monitoring-grafana
  namespace: kube-system
spec:
  replicas: 1
  revisionHistoryLimit: 0
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: grafana
    spec:
      containers:
      - name: grafana
        image: gcr.io/google_containers/heapster-grafana-amd64:v4.0.2
        ports:
        - containerPort: 3000
          protocol: TCP
        volumeMounts:
        - mountPath: /var
          name: grafana-storage
        - mountPath: /etc/ssl/certs
          name: ca-certificates
        env:
        - name: INFLUXDB_HOST
          value: monitoring-influxdb
        - name: GRAFANA_PORT
          value: "3000"
      volumes:
      - name: grafana-storage
        emptyDir: {}
      - name: ca-certificates
        emptyDir: {}
      - name: grafana-config
        configMap:
          name: grafana-config-ini
          items:
            - key: grafana.config.ini
              path: grafana.ini

---
apiVersion: v1
kind: Service
metadata:
  labels:
    # For use as a Cluster add-on (https://github.com/kubernetes/kubernetes/tree/master/cluster/addons)
    # If you are NOT using this as an addon, you should comment out this line.
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: monitoring-grafana
  name: monitoring-grafana
  namespace: kube-system
spec:
  # In a production setup, we recommend accessing Grafana through an external Loadbalancer
  # or through a public IP.
  type: LoadBalancer
  # You could also use NodePort to expose the service at a randomly-generated port
  # type: NodePort
  ports:
  - port: 80
    targetPort: 3000
  selector:
    k8s-app: grafana

I had to change my volumes def from emptyDir to
      - name: ca-certificates
        hostPath:
          path: /etc/ssl/certs

@NullVoxPopuli even above solution doesn't work for me.

@NullVoxPopuli even above solution doesn't work for me.


Use a Stream's composite type in a function

As I understand when creating a Stream it also creates a corresponding composite type. I'd like to use this type as an argument in a function.
Example:
CREATE STREAM mystream (
    id int,
    name varchar(255)
);

CREATE OR REPLACE FUNCTION myfunc(item mystream)
RETURNS BOOL AS
$$
    BEGIN
        RETURN FALSE;
    END;
$$
LANGUAGE plpgsql;

I get the following error:
ERROR:  relation "mystream" is not a table
CONTEXT:  compilation of PL/pgSQL function "myfunc" near line 1
I think this is because PL/pgSQL checks to see if the relation type is one of a few different types.
pipelinedb/src/pl/plpgsql/src/pl_comp.c :: build_row_from_class
I plan on using this function in a Continuous Transform and I'd like to pass the entire stream record to the function.
Version
PipelineDB 0.9.3

Fixed via 28097cb06e7c8e085977f71c4a87cf8976f2032b


Building out Unit 3 of web

@nmadd @rors Check it out!

IMMA MERGE THIS GUY! We can always do more iterations on this unit, but i'm happy with this first pass


skeleton for ghost-actor proc macro

PR summary
There's no code changes here, just some moving around and creation of skeleton for the new proc-macro ghost actor work.
Review checklist

[ ] The story has unit or integration tests
[ ] No new bugs, and any tech-debt is identified and justified
[ ] There is enough API documentation (how to use)
[ ] There is enough code documentation (how the code works)

why did this fail windows CI?

why did this fail windows CI?

sim_chat got in without the zombie reference update


documentation metacharacters are confusing

It's confusing for the documentation to use (...) and [...] instead of the Unix-conventional [...] and <...> (or all-caps instead of <...>).  I don't remember seeing that convention elsewhere.

That is interesting, I've never really noticed the convention. If I am
understanding correctly, [...] is used for mandatorys  and <...> is used
for optionals?

--
Gregory M. Kurtzer
High Performance Computing Services (HPCS)
University of California
Lawrence Berkeley National Laboratory
One Cyclotron Road, Berkeley, CA 94720

It's the other way round.  For instance
USAGE: singularity (options) help [command name]

in Unix man conventions might be
USAGE: singularity [options...] help <command name>

or, better, commandname -- see man(1).  Some man pages (and GNU Info format) might use COMMAND-NAME for replacements.  I'd expect any of those to be widely recognized.

This motivated me not only to fix the metacharacters as you pointed out, but also refactor the help outputs which I have been meaning to do. Please check [master 39ff286].
Thanks!


Remove HTML use of relatedLink property

The property relatedLink is not needed in the RepositoryObject hasFile example, and the use of inline HTML for http://schema.org/relatedLink is not matching upstream spec, which expects URL.

In call 2020-09-24 @ptsefton agreed to merge - however the fact that this HTML "just worked" in Calcyte needs to be revisited as it can be a potential exploit factor.


Remove incorrect permitted next node from check-uk-visa

The outcome_visit_waiver is not a valid return value for the next_node block for this question.
I came across this while double-checking that the mechanism for automatic detection of permitted next nodes was working correctly. The fact that this had managed to get out of sync highlights the duplication inherent in the current implementation and encourages me that the automatic detection mechanism will be an improvement.
Expected changes
None

Good catch @floehopper. I think our Rubocop config wants trailing commas, which would reduce the diff by a line, otherwise looks good

@erikse: Thanks. Rubocop wasn't failing, but I've added the trailing comma anyway in this fixup commit.

I'm about to rebase this against master and force-push in preparation for merging.


JS SDK 0.2.1 release

Merged on behalf of Devrel since it was EOD for them, and they told me it would be okay to merge 😄 🎉


Adding scopes to measures, filters and dimensions

Firstly, thanks for all your work on an excellent project!
I need to add scopes (class methods) to the relations defined as measures, filters and dimensions such as .for_organization(current_organization). I'm struggling to add scopes at all, let alone accessing helper methods such as current_user or current_organization that would normally be available to controller contexts. The filter initializer context doesn't have access to those methods either.
Any thoughts?

This can be done using a Context Record. Here's an example using current_user:
class User < ApplicationRecord
  has_many :posts
end

= render_report 'my_posts', context_params: { foo: 'bar' }

measure: post
dimensions:
- is_published

# config/initializers/reports_kit.rb

ReportsKit.configure do |config|
  config.context_record_method = lambda do |controller|
    context_params = controller.params[:context_params]
    # You could use any other context_params-related conditional here, or even omit this line if all of your reports are scoped to `current_user`
    return nil unless context_params && context_params[:foo] == 'bar'
    current_user
  end
end

If context_record_method returns nil, then the query that's run is effectively Post.group(:is_published).count.
If context_record_method returns a User instance (via current_user), then the query that's run is effectively current_user.posts.group(:is_published).count.
Does this solve your use case?

Other Thoughts
This Context Record-based solution (described above) isn't as intuitive as I'd like.
One approach that I've been considering is having a "contextual_filter" (there may be a better name for this) that works like so:
measure: post
contextual_filter: my_contextual_filter
dimensions:
- is_published

class User < ApplicationRecord
  has_many :posts

  include ReportsKit::Model
  reports_kit do
    contextual_filter :my_contextual_filter, ->(relation, controller) { relation.where(user_id: controller.current_user.id) }
  end
end

This would 1) be fairly flexible and applicable to many use cases, and 2) move the filtering out of config/initializers/reports_kit.rb and into the report YAML and model, where the other filtering is done. If we used this, we would likely deprecate the Context Record approach.
Would this solution be more intuitive to you, and would it solve your use case?
Are there other solutions that would be better than this?

Thanks for the detailed response! After thinking about this for a few days, my sense is the contextual filter solution would be far more intuitive and flexible. I tend to not lean on chained relationships (current_user.posts) and instead opt to write class methods that yield more clarity around the final object to be returned (Post.for_user(current_user)). The first method you propose would require a good amount of refactoring for me, and while I'm happy to do that for the opportunity to use your project, I suspect others will find the current context record implementation a bit confusing as I did.
I'll try out the currently available solution now and circle back if I run into any roadblocks.
Thanks!

Great, thanks for giving this some thought. This feedback is very helpful, and everything you mentioned is very much in line with my perspective, too. This improvement will (hopefully) not only reduce confusion, but also allow us to remove the Context Record-related code, which would simplify ReportsKit's implementation significantly.
To see what this new solution would look like, I've done a very rough implementation of it, and it looks relatively straightforward. It's already working well to replace Context Records in a large app that makes somewhat heavy use of Context Records.
If you or anyone else wants to keep up with it, I have an initial implementation of it in this branch, but it's very much a work in progress without documentation yet. When it's in a more stable state, I'll mention it here again, and if you want to, you could try it out then to see if it meets your needs. (Or if you prefer, you can just wait til it's in a stable release :) ).

Thanks! I'll check out the branch and let you know if I see any issues with the new direction.

There has been a decent amount of confusion about context records, and ReportsKit is nascent enough that it's still possible to iterate quickly on it without impacting too many users, so I've gone ahead and added contextual filters in 0.4.0. They're additive, so no existing functionality will break, but newcomers will more easily know that they exist and be able to try them out.
Contextual filters are documented here. I've deprecated context records in both this library and in the documentation.
They've been working well in a Rails app that has historically made fairly heavy use of ReportsKit and context records, so they seem to fit at least that use case, but additional feedback would definitely still be helpful.

This is working well for appending scopes to measures, thanks! Next question is filters. If I've got a filter key for user I'm still getting all users in the filter select as User.all but I need to append User.for_organization(current_organization). I'm not seeing how to add any context to the filter since the custom filter is meant to only be a relation scope on the measure object. Is there any way to append that context to a filter?

Just to clarify, do you mean that you have a multi-autocomplete filter for a user association, and you're seeing that the results in that autocomplete are all users (User.all)?
If so, then the current way to scope the results to the organization is to use the autocomplete_results_method to modify the autocomplete's results. Your implementation might look something like this:
# config/initializers/reports_kit.rb

ReportsKit.configure do |config|
  config.autocomplete_results_method = lambda do |params:, context_record:, relation:|
    query = params[:q]
    relation = relation.for_organization(params[:context_params][:organization_id])
    results = relation.where('name ILIKE ?', "%#{query}%").order('name').limit(30)
    results.map do |result|
      {
        id: result.id,
        text: "#{result.last_name}, #{result.first_name}" }
      }
    end
  end
end

As described in the context filter documentation, if you need to validate the params[:context_params] value, you can do so like this.

However, this is not an obvious nor easily-used solution. As you mentioned, it would probably make sense to configure this in the filter's configuration in the YAML. Would something like the following make sense to you? Or perhaps there's a better solution?
measure: post
filters:
- key: user
  contextual_filters:
  - for_organization
dimensions:
- is_published

filters:
- key: user
  contextual_filters:
  - for_organization

Is exactly what I was hoping for, that would make it consistent with the measure contextual filter implementation. Thanks again for all your effort here!

The use of contextual_filters within filters is now supported in 0.5.0. The documentation that more thoroughly explains this is here.
I've also added documentation about Multi-Autocomplete Results Filtering that describes the two methods for achieving this.
I believe that the needs described in this issue should be supported now, so I'll close the issue. If there are other aspects to this, it might be best to open a new issue so that we can specifically focus on them. Thanks for surfacing these needs; I hope these are helpful additions!


Init optimizer with class type

Add the option to pass a torch.optim.Optimizer class type in traininig params to initiate an optimizer object through the build_optimizer.
This way a custom / not supported optimizer class can be passed, while still make use of the utils functions initialize_param_groups and zero_weight_decay_on_bias_and_bn

Im closing this PR down as our optimisers factory already supports external classes (see tests/unit_tests/factories_test.py
as an example)


Extra progress bar being displayed

Sample code:
from dask.array import ones
from dask.diagnostics import ProgressBar

data = ones((8,79,200,401),dtype='f4',chunks=(1,1,200,401))
with ProgressBar():
  s = data.sum().compute()

print s

Result (version 0.18.1):
[########################################] | 100% Completed |  0.4s
[########################################] | 100% Completed |  0.1s
50686400.0

Result (version 0.17.5):
[########################################] | 100% Completed |  0.4s
50686400.0

Version information
(from xarray.show_versions)
commit: None
python: 2.7.6.final.0
python-bits: 64
OS: Linux
OS-release: 3.10.0-514.el7.x86_64
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: None.None
xarray: 0.10.7
pandas: 0.23.1
numpy: 1.14.5
scipy: 0.13.3
netCDF4: 1.4.0
h5netcdf: None
h5py: 2.2.1
Nio: None
zarr: None
bottleneck: None
cyordereddict: None
dask: 0.18.1
distributed: None
matplotlib: 1.3.1
cartopy: None
seaborn: None
setuptools: 39.2.0
pip: 1.5.4
conda: None
pytest: None
IPython: 1.2.1
sphinx: 1.2.2

Thank you for the excellent minimal example @neishm .  Hopefully someone comes by soon who has the time to resolve this.  Alternatively, if you're interested in diving in here your efforts would be most welcome.

Traced it to the following change in dask.base.repack():
Version 0.17.5:
https://github.com/dask/dask/blob/b2bed5eb145b39641181140b8f64a9b4427b53ba/dask/base.py#L279
Version 0.18.1:
https://github.com/dask/dask/blob/d7755492c81b7b11788a314e008edd11663ff150/dask/base.py#L283
local.get_sync() triggers a second progress bar, whereas simple_get() does not.  I confirmed this by checking out 0.18.1, and changing that line of`dask.base.repack to:
from .core import get as simple_get
return simple_get(dsk, out)

With this I get a single progress bar again.  Don't know what the proper fix is, though.

Hrm, indeed.  Nice find.  Git blame shows that I made this change.  I
suspect that I thought I was just cleaning up.  My guess is that it is safe
to revert this line.  It would also be good to ensure that this doesn't
happen again by having a test that ensures that we only output a single
line.  I think that the capsys pytest fixture can help us with this.
Do you have any interest in submitting a PR with this fix?  The tests to
look at are probably in dask/diagnostics/tests/test_progress.py.
On Mon, Jun 25, 2018 at 1:51 PM, Mike Neish<EMAIL_ADDRESS>wrote:

Traced it to the following change in dask.base.repack():
Version 0.17.5:
https://github.com/dask/dask/blob/b2bed5eb145b39641181140b8f64a9
b4427b53ba/dask/base.py#L279
Version 0.18.1:
https://github.com/dask/dask/blob/d7755492c81b7b11788a314e008edd
11663ff150/dask/base.py#L283
local.get_sync() triggers a second progress bar, whereas simple_get()
does not. I confirmed this by checking out 0.18.1, and changing that
line of`dask.base.repack to:
from .core import get as simple_getreturn simple_get(dsk, out)
With this I get a single progress bar again. Don't know what the proper
fix is, though.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/3668#issuecomment-400038538, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AASszEqlglSnRAbJ3MqRgXq3n2tjryaoks5uASMigaJpZM4U2c3Y
.

@neishm Great work! Thanks for fixing my problem as well!


Push Source Code or Build Steps

I'd be interested in this module, but it looks weird that there's no source code at all for it. 🤔

Sine the original @vue/compiler-sfc is highly coupled to vue itself, I tried to separate it but failed, so I chose to modify it directly based on the dist.
Although this is not feasible in the long run, given that vue@2 itself has stopped maintenance, I think it is acceptable to a certain extent.

Thanks then 😄
Might still try it out.


Cant find materialized set for a simple var in a group query

The following query produces Cant find materialized set. This is the simplest grouping mat-set error I've been able to produce this far.
with
dur := <optional str>$duration,
cutoff := (
  datetime_current() - <cal::relative_duration>dur
  if exists dur
  else to_datetime(0)
),

group (
  select Anything
  filter .createdAt > cutoff
)
by .something

EdgeDB Version: 5.0-beta.2 + 4.6 + 4.7
EdgeDB CLI Version: 4.3.0
OS Version: multiple

Steps to Reproduce:

Derive a with var from another var with a param
Use that in a group query

Schema:
module default {
  type Anything {
    something: bool;

    required createdAt: datetime {
      default := datetime_current();
    }
  }
}

Follow-up, wrapping the group in a new select makes it work!
with
dur := <optional str>$duration,
cutoff := (
  datetime_current() - <cal::relative_duration>dur
  if exists dur
  else to_datetime(0)
),

select (
group (
  select Anything
  filter .createdAt > cutoff
)
by .something
) { key, elements }


Hotfix IE search when submitting via enter

Force the knockout value to update in IE when using enter to submit a search, fixes https://github.com/CenterForOpenScience/osf.io/issues/1448
Cause
IE doesn't update the value of the search field unless the focus is lost
Fix
Blur and then focus the field before submitting the search
Notes
I don't have access to an IE browser to test this but running the commands in saucelab's VM seemed to work.

I have a windows VM for testing, however would I be able to run this on my host machine and access the server on the VM?

Yes

:+1: I'll test that then

So I just tested this and it still isn't working... It's a minor issue, but just wanted to let you know!

@kmjungersen When you have a chance could I take a look on your vm?

certainly!