Stockoverview - Filter by location not selectable

On the demo site on the stockoverview page the dropdown "Filter by location" has no function. It is empty. Tested with several different browsers.

Sorry, I only tested with Firefox 61 (current stable), can verify this with for example Firefox 62 (current Developer Edition) - will fix this shortly...

Should now be fixed in v1.12.1...

Thank you that you could solve it so quickly.


Improve branch naming

@charlierudolph @allewun @ricmatsui
Follows the more common branch naming scheme by using dashes instead of underscores in branch names.

looks ok to me, relying on tests to catch any bad renames

:ship:


Minor typo on wpf hosting walkthrough page

itto is a typo.  It should probably say it to

The Form1_Load event handler creates an instance of UserControl1 and adds itto the ElementHost control's ...

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

ID: 04fff519-3d2a-4756-1fc7-41ba0cc98621
Version Independent ID: e26e8075-7880-39b9-9c87-8f0b871c03dc
Content: Host 3D WPF Composite Control in Windows Forms
Content Source: dotnet-desktop-guide/framework/wpf/advanced/walkthrough-hosting-a-3-d-wpf-composite-control-in-windows-forms.md
Product: dotnet-framework
Technology: dotnet-wpf
GitHub Login: @adegeo
Microsoft Alias: adegeo

Thank you for reporting. I've made the fix.


Use without Sapper or SvelteKit

From reading the documentation it's not clear if/ how this can be used within a bare Svelte app.
If this is possible, how would one use Houdini without using Sapper (i.e. only having a simple Svelte app). If this is currently not possible, why not (and how could that be changed, e.g. if I wanted to submit a PR)?

At the moment, houdini doesn't work in a bare svelte app because query does not actually fire a network request. It assumes that the pre-processor has hoisted the query into a load function (preload in sapper) and that the component using query will be passed the data as a prop from the load function. Also, query and the other document functions have internal APIs that are not very ergonomic so there would have to be some work done to make the user's life smoother. For a better understanding of what I mean, you can look at the fragment tests. The top of that is what the user writes, the block underneath is what the pre-processor turns it into and shows the actual API for the fragment function when its invoked.
Supporting this would probably be best done by building versions of query, mutation, subscription, and fragment that don't make these assumptions. You could still use the artifacts that the compiler generates and the caching mechanism would still work which is what powers the actual APIs (ie things like mutation updates would "just work"). It's definitely doable but not something I have time to prioritize at the moment. If you do want to try to add support for a raw svelte app, I can provide any guidance you need

Interesting, so queries are actually all run server side before the components are send to the browser, or am I miss understanding the process? 😅

yes that's correct! At least for the first request that is rendered by the server. From then on, queries fire from the client directly to the API (both Sapper and SvelteKit take care of these details when you define the appropriate loader).
With that understanding, hopefully I can explain why the API isn't setup like relay's (I also use relay in my react projects). In order to get access to the page variables (so users can do something like pull a filter value from the url) the actual logic for computing the variable needs to exist in the module script where the actual network request happens. If the variables were just a static value, this wouldn't be a problem - the preprocessor could just copy the value up to the right script. Unfortunately that's too big of a limitation since a user could put all sorts of madness in that function. That means that the preprocessor would be forced to hoist up any necessary logic to perform the computation. By forcing the user to define their variable function in the module context, we can guarantee that anything that the user used to compute their variables is also accessible without any complicated hoisting logic.
Re the return value - I think a promise is a reasonable response from the various document functions in a bare svelte app as long as it resolves to a store so the user can subscribe to updates.

After poking around with possibilities, I think we can support bare this with the current API. At the very least querys inside of non page/layout components have the same constraints as a bare component so the two  should have very similar solutions.
related: #72

I think one solution could be to split the query API into lazyLoadedQuery and preloadedQuery (or just query), where the later one is the default to use in page components, defers the arguments into the preload-function, while the lazy loaded version fires on the client side, when the component is rendered (and takes the arguments directly). (iirc that's roughly the story with Relay's API as well)

I'd like to avoid doing that if possible. I think the only thing that's missing from the query api to support client-only requests is to add a loading field to track the state of the response. I agree that a promise would be a more native solution but I'd like to keep the api surface as small as possible. Also, having two different functions that are constrained by file location means that refactoring components from a page/layout into a common component is not as simple as just moving the file - the user would also have to go update all of the querys to clientQuery or whatever we call it.

What do you think of mirroring relays approach more closely and having a preloaded query that is passed the pre-load value explicitly; and then having a loader that can load a given query from within the sapper/ kit (pre)loader side of things (or potentially another function in the frontend); and potentially having a convenience wrapper that lazy loads things by doing something like query(…, await preloadQuery(…))
That would break compatibility with the current api but be more flexible in terms of where the loading can happen.

In some sense that's how query works now. The actual function exported from the runtime expects an object that is created by the preprocessor.
If we wanted to bring the idea of preloading a query into the core API, I think the best way is to leave query the way it is and instead add two new functions to the runtime that do the preloading and and subsequent loading. Even if query is just a very thin wrapper over loadPreloadedQuery (or whatever we call it), having two functions with distinct names lets the preprocessor handle the details for query and keeps the API simple in the most common cases. I want to avoid complicating the API to support "advanced" use cases wherever possible.
I think ideally, the logic for preloading a query should be hidden from the user and the framework should just do the "right thing" whenever possible. I think given that houdini is currently only maintained by a single person, the best way to get to that dream is to lean heavily into kit to handle the router integration. I do understand that supporting this is important to integrate with other routes but advanced users are more likely to be okay with a less-than-perfect API that might be heavily caveated.

@dyedgreen I think I have a working update to support query in a non-kit or sapper environment. Mind giving #95 a shot and see if it works for you?

Going to reopen this, @pixelmund had a very good point, a lot of the generated code still assumes things like $app and sessions. We'll need to generate a bare svelte adapter that avoid this


Guild Wars 2 has lower fps with d9vk than normal wine

The game seems to work pretty good for some users.
For me the game is working below wine staging.
The DXVK_LOG_LEVEL=none seems to have no effect on fps.
The details for the game are set at best appearance without depth blur and my fps is about 30-35 in normal (not reach in details) maps.
on a world boss  kill when lots of players are in the same place i had about 5-7 fps.
I've tried the game both on arch (kernet 5.0.11) and on linuxmint (kernel 4.15.0-48). both has the same low fps.
System information

GPU: 970 GTX
Driver: 418.56 (i also tried beta drivers)
Wine version: 4.7 staging
D9VK version: ab57adc

Log files
Gw2-64_d3d9.log.zip

Can you please try using a TKG wine build and see if that improves performance?

using lutris is the best way to test that out

with a new TKG prefix (lutris) I get about 10 fps more than wine (TKG) in that HoT map.
So the stats are like this wine staging with d9vk (no TKG) = 15fp < wine (TKG) no d9vk = 25 fps < wine (TKG) with d9vk=35fps
on another map i have 65-70 fps with tkg and d9vk compared to 45-48 with just TKG
definitely better than wine.
well im far from 140 fps as ReaperOfSouls1909 but at least im getting ~70 fps in the same place as that screenshot.

Please try 430.09 drivers. They do improve performance in Guild Wars 2.

@michalszajnecki same performance with 430.09.
Well, even though i dont have such a huge fps in same place i'm still getting better performance than i'd get without d9vk.
seems that i TKG wine is needed.

After installing to a new prefix with DXVK_LOG_LEVEL=none and installing the latest git master I finally started to get decent FPS. Before I was getting around 20 - 25 FPS and now I'm getting between 55 - 85 which is much more playable. Still not getting 100+ like others, but this is a big improvement.

i've made a few tests windows 10 vs wine with d9vk with 18c78ce
some maps has about same fps and some has 20 lower fps than w10. at least on my setup
seems that PoF and HoT maps are slower on wine than windows.
here are some screenshots

question: what should be the settings in lutris for DX/9VK?
i don't know what else to put in there other then DXVK_HUD=whatever you like  DXVK_LOG_LEVEL=none and STAGING_SHARED_MEMORY=1 (i have no clue what it does but sound interesting :) ).


Hyperfine benchmarks

Closes #129
I started putting together a Dockerfile that gets all the clients and benches them with hyperfine. I decided to do it all in Docker, because I would not want to have all the clients on my system and to make it accessible for third parties to easily verify the results that our benchmarks produce.
At the time of writing, only tealdeer and the C client are compared, but I will add more clients.
Eventually, we could think about running benchmarks in CI, but this is not the focus of this PR.

I noticed that when using fast-tldr (or tldr-hs), the output still has the {{ and }} which is not intended by the client specification. I am not sure how to compensate these differences fairly. After all, fast-tldr runs considerably faster than tealdeer in hyperfine.

Just so I'm up to date: @niklasmohrin this is still WIP, right? (I'll wait with another review until you think it's ready.)

@dbrgn Yeah I am a bit out of the loop myself, I will have to come back to this with the zig build some time soon. I will just request the review once it's ready.
About the results: I think it would be fairest if we included some evaluation with the results, for example that fast-tldr doesn't really parse the files and just outputs variables as they are read, otherwise we really are just breaking our own legs here
We have some performance PRs on the way, I am excited about #187. Is there any news on #108 or a way to get rid of docopt otherwise?

Yeah, I agree, clients that simply stream a file to stdout aren't really fair comparison.

I'm working on #108 right now. It would be kind of nice to have benchmarks before and after, but that can also be done after the PR was merged.

Oh, before and after seems like a nice thing to have too, well then I can't rest on that argument anymore :laughing:

Yeah, but as I mentioned, we can simply backport the hyperfine docker script to an old version of the repository. That's no problem 🙂

@dbrgn I think I am satisfied with the current state of Dockerfile. I found a way to drop the disk caches from within the container, so that we can test with cold caches (which is closer to the actual use case).
Unless you have something else to add, the only thing left is getting outfieldr to build, don't know when dev will respond (only messaged earlier).
With #187 merged, we are also standing pretty strong against fast-tldr again, only falling 5-10% behind. I am wondering if we can reproduce the 30x speedup that outfieldr claim on their README.
Nevertheless, I think having all the results in a table that outlines the tradeoffs is fair to everyone

From this perspective, having node and python in the list makes sense, yeah. I didn't want to run the node app 500 times, but I have two ideas for how to present that:

We list node in the table, but with an asterisk to note that the mean is only from 50 runs or
There are actually two columns, one for a benchmark with 500 runs and one with a benchmark with only 50 runs. Node just wouldn't appear in the 500 column.

I think I'd prefer the first option, because it's less (redundant) numbers on the screen and still presents the main point that node is an order of magnitude slower. What do you think?

Having this code in a separate repo means it is its own thing, whereas here it's just documentation for how numbers in a readme were generated. I would like to keep the impression of the latter for as long as possible. I was wondering if we should set up a gh action to run the benchmarks (I think you can run privileged docker containers inside of the vm), but the ci runners are afaik quite the opposite of a cold machine, so I'm not sure (it's more work too ofc). It would add credibility though, since the numbers don't just come from a single person

50 runs are perfectly fine. Btw, why don't we simply omit the --runs 400 argument? Hyperfine will try to determine on its own how many runs are required to achieve statistical significance. The number of runs is not really relevant to the user, as long as the numbers are repeatable.

Without this, it would do too few runs leading to too much variance. I also used --min-runs but that would just mean that everyone ran about that number of times and then I came to the conclusion that I could just fix the number of runs :man_shrugging: I'll see how reliable 50 runs are for me and check back in with you

Doesn't hyperfine take the variance into account? I assumed so, but maybe I'm wrong...

I am not sure, maybe it does to a degree, but with the small number of runs it was still somewhat unstable when I tested

Ok, then let's not hold up this PR any more, we can do additional improvements later. Feel free to merge!

(I gotta add python first though)

@dbrgn I think everything is ready

Can you build the Dockerfile? On my machine, tldr-hs fails every time (even with --no-cache).
Step 10/39 : RUN git clone https://github.com/psibi/tldr-hs.git         && cd tldr-hs         && stack build --install-ghc
 ---> Running in ea506c72af75
Cloning into 'tldr-hs'...
Downloading lts-18.0 build plan ...
RedownloadInvalidResponse Request {
  host                 = "raw.githubusercontent.com"
  port                 = 443
  secure               = True
  requestHeaders       = []
  path                 = "/fpco/lts-haskell/master//lts-18.0.yaml"
  queryString          = ""
  method               = "GET"
  proxy                = Nothing
  rawBody              = False
  redirectCount        = 10
  responseTimeout      = ResponseTimeoutDefault
  requestVersion       = HTTP/1.1
}
 "/root/.stack/build-plan/lts-18.0.yaml" (Response {responseStatus = Status {statusCode = 404, statusMessage = "Not Found"}, responseVersion = HTTP/1.1, responseHeaders = [("Connection","keep-alive"),("Content-Length","14"),("Content-Security-Policy","default-src 'none'; style-src 'unsafe-inline'; sandbox"),("Strict-Transport-Security","max-age=31536000"),("X-Content-Type-Options","nosniff"),("X-Frame-Options","deny"),("X-XSS-Protection","1; mode=block"),("Content-Type","text/plain; charset=utf-8"),("X-GitHub-Request-Id","C986:10058:47268:7522A:6103AE47"),("Accept-Ranges","bytes"),("Date","Fri, 30 Jul 2021 07:46:15 GMT"),("Via","1.1 varnish"),("X-Served-By","cache-fra19120-FRA"),("X-Cache","MISS"),("X-Cache-Hits","0"),("X-Timer","S1627631175.106098,VS0,VE149"),("Vary","Authorization,Accept-Encoding"),("Access-Control-Allow-Origin","*"),("X-Fastly-Request-ID","0468e71bfb3d2f26e693cecec5a72f9a0374bb0b"),("Expires","Fri, 30 Jul 2021 07:51:15 GMT"),("Source-Age","0")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose})
The command '/bin/sh -c git clone https://github.com/psibi/tldr-hs.git         && cd tldr-hs         && stack build --install-ghc' returned a non-zero code: 1

Ah, I think it's the haskell:8.6, I reverted too far after trying to avoid building half the haskell ecosystem... I tested a no-cache rebuild (when I still had just haskell) and it worked there, I am gonna build again now before pushing :D

That works, although I'd pin the version to haskell:9.0 instead. Building works for me with that version.

It's interesting how big the effect of the disk cache is! After running sync; echo 3 | tee /proc/sys/vm/drop_caches, a tealdeer run takes around 14 ms. For subsequent calls, it's only 2-4 ms.
Here are my numbers:

That works, although I'd pin the version to haskell:9.0 instead. Building works for me with that version.

Prior to today, I had it pinned to 8.6, but the build would fail. I think that --install-ghc always figures out the needed version, which is why I just had it be the latest
I think running on a cold cache is most realistic, what do you think?

which is why I just had it be the latest

Ok, I don't know about that, you might be right. (I personally prefer to pin versions to avoid unexpected incompatibilities when a newer version of the image is pushed.)

I think running on a cold cache is most realistic, what do you think?

Yes, I agree!

whoops, apparently --autosquash does nothing without --interactive :thinking:
I think I would separate the docker and readme changes, because we may want to trace the table in the readme separately from the benchmark setup

whoops, apparently --autosquash does nothing without --interactive :thinking:

Yep, that's the case.

I think I would separate the docker and readme changes, because we may want to trace the table in the readme separately from the benchmark setup

Yeah, that makes sense. I was referring to the fixup commit 🙂 Feel free to merge now.


feat: add util(srt to md)

:sparkles: add util(srt to md)
:sparkles: sort srt contents before cutting
:art: format code

我的我的，改漏了
---Original---
From: "Mu @.>
Date: Fri, Nov 11, 2022 12:13 PM
To: @.>;
Cc: "Qianhe<EMAIL_ADDRESS>Subject: Re: [mli/autocut] feat: add util(srt to md) (PR #18)
@mli approved this pull request.
resolve conflict 和 update readme.md 里的 -g 就ok了
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


Disconnect automatic after using Firefox

I use Firefox at view minute and then,vnc got disconnect automatic.how can i fix that,so i can use Firefox on many time :)

Sory for my bad English :(


we need to change the label of the stepper

We have a requirement for tripapp-product-hotels to change the displayed value within the stepper from just a number to a number and  a label, "4 Adults" for example.

Make it an option for the middle of the stepper to be a dropdown?
https://github.com/holidayextras/tripapp-product-parking/issues/10

Not fixing as iterating on existing tech

when this one needs doing sounds like it will be done by the trips pod


Savina Benchmarks?

Not really an issue just a question, have you guys seen the Savina benchmarks at https://github.com/shamsmahmood/savina? Wonder what you think of them and whether they would be a worthwhile benchmark set for comparisons with other actor languages.

As a pony user (not a maintainer) - I think this would be interesting to participate with.  If I read the source right, looks like only JVM-based systems are present so far?  Has there been any attempt to describe the requirements of each benchmark in a formal way that is not coupled to the Java/Scala source code I see in the repository?  I briefly looked through the paper linked to in the README, but it seemed to mostly be an overview of the objective and results so far.  It would be helpful to have a description of each benchmark so that implementations in non-JVM-based languages could be written by those who don't read Java/Scala.

I am not aware of such a description, no.
I saw that some fellow researchers actually picked it up and usually implemented a few of the benchmarks in their systems. But, nothing more than that.
A more precise description would indeed be useful, especially since I am working with an event-loop actor language that's different enough from the process-based/Erlang like actor frameworks used in Savina to raise certain questions of what a fair port is.

Hmh this is very interesting. I am not aware of such a description either, but looking into this is worthwhile.

We have indeed looked at Savina. I think it's interesting, but I haven't had time to decipher their implementations. As @jemc points out, everything is JVM based at this point.
Hey @jupvfranco , you've looked at Savina I believe. What are your thoughts?

If you are brave, and read Smalltalk syntax, my (partial) port is here: https://github.com/smarr/SOMns-corelib/blob/master/Benchmarks/Savina.som
It's not without problems porting it, because they cheat in multiple places, are very much tied to Java, and rely heavily on technical details of the actor frameworks. And, not all of the benchmarks do self-verification, which is quite a bit of an issue for porting.

Thanks @smarr , that's extremely helpful. Personally, I find the Smalltalk more comprehensible than the Java :)


go-controller - ovnkube node-init fails when -init-gateways true

When running ovnkube --init-node with `-init-gateways is true (full --init-node command below)
./ovnkube --init-node bsteciuk-worker-linux -ca-cert "/etc/kubernetes/pki/ca.crt" \
 -token "${TOKEN}" -apiserver "https://<IP_ADDRESS>:6443" \
 -ovn-north-db "tcp://<IP_ADDRESS>:6641" -ovn-south-db "tcp://<IP_ADDRESS>:6642" \
 -init-gateways true -gateway-interface ens4 -nodeport true

ovnkube fails with the following:
INFO[0000] Node bsteciuk-worker-linux ready for ovn initialization with subnet <IP_ADDRESS>/24
Feb 13 16:29:40 bsteciuk-worker-linux systemd[1]: Started LSB: Open vSwitch switch.
Feb 13 16:29:40 bsteciuk-worker-linux ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl set Open_vSwitch . "external_ids:ovn-nb=\"tcp:<IP_ADDRESS>:6641\"" "external_ids:ovn-remote=\"tcp:<IP_ADDRESS>:6642\"" external_ids:ovn-encap-ip=<IP_ADDRESS> "external_ids:ovn-encap-type=\"geneve\"" "external_ids:k8s-api-server=\"https://<IP_ADDRESS>:6443\"" "external_ids:k8s-api-token=\"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJvdm4tY29udHJvbGxlci10b2tlbi10aDQ2cyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJvdm4tY29udHJvbGxlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjZmOTY5NzdiLTEwY2UtMTFlOC1hNDM1LTQyMDEwYThlMDAwYSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlLXN5c3RlbTpvdm4tY29udHJvbGxlciJ9.YRYutvUR1uBSAVA227r1ThgJ8GrwGwMdR9o8cIgRdpqQc_ScFn9dKaji-rAMhcxyqDOXeYUi1UZBY_CHIhoIimZiHC3TN-9evsyKvlRmFR9OG_kvQ9zVhwy3gq-VqA2uDbzEQxH-mGDmytyFdQc4zTxVeHAzWl375GHhf3KmHY0ZyobG4aG4MHbOvbgQpsqrlwbEUFB8XUdcr81EBklNcotzhP8YoGO1Ryo0ObMx4UMGNzXBNO9cAYFmBUMwW57ZR_qYFcZ243FSv51TsaV3qjebVKs0I89m3K7nZtaDRFdbTTXSAG7WU8nNZ6czaDHozf4JUYzAGGkO5Ednamf_2w\""
Feb 13 16:29:40 bsteciuk-worker-linux systemd[1]: Stopping LSB: OVN host components...
Feb 13 16:29:40 bsteciuk-worker-linux ovn-host[7357]:  * Exiting ovn-controller (3818)
Feb 13 16:29:40 bsteciuk-worker-linux kernel: [ 4624.020155] device genev_sys_6081 left promiscuous mode
Feb 13 16:29:40 bsteciuk-worker-linux systemd[1]: Stopped LSB: OVN host components.
Feb 13 16:29:40 bsteciuk-worker-linux systemd[1]: Starting LSB: OVN host components...
Feb 13 16:29:40 bsteciuk-worker-linux ovn-host[7385]:  * Starting ovn-controller
INFO[0000] Open configuration file /etc/openvswitch/ovn_k8s.conf error: open /etc/openvswitch/ovn_k8s.conf: no such file or directory, use default values
Feb 13 16:29:40 bsteciuk-worker-linux systemd[1]: Started LSB: OVN host components.
Feb 13 16:29:40 bsteciuk-worker-linux ovn-nbctl: ovs|00001|nbctl|INFO|Called as /usr/bin/ovn-nbctl --db=tcp:<IP_ADDRESS>:6641 --timeout=5 -- --may-exist ls-add bsteciuk-worker-linux -- set logical_switch bsteciuk-worker-linux other-config:subnet=<IP_ADDRESS>/24 external-ids:gateway_ip=<IP_ADDRESS>/24
Feb 13 16:29:40 bsteciuk-worker-linux kernel: [ 4624.168322] device genev_sys_6081 entered promiscuous mode
Feb 13 16:29:40 bsteciuk-worker-linux ovn-nbctl: ovs|00001|nbctl|INFO|Called as /usr/bin/ovn-nbctl --db=tcp:<IP_ADDRESS>:6641 --timeout=5 -- --may-exist lsp-add bsteciuk-worker-linux stor-bsteciuk-worker-linux -- set logical_switch_port stor-bsteciuk-worker-linux type=router options:router-port=rtos-bsteciuk-worker-linux "addresses=\"00:00:00:3E:0F:34\""
Feb 13 16:29:40 bsteciuk-worker-linux systemd-udevd[7429]: Could not generate persistent MAC address for genev_sys_6081: No such file or directory
Feb 13 16:29:40 bsteciuk-worker-linux ovs-vsctl: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=5 -- --may-exist add-br br-int
Feb 13 16:29:40 bsteciuk-worker-linux ovs-vsctl: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=5 -- --may-exist add-port br-int k8s-bsteciuk-wo -- set interface k8s-bsteciuk-wo type=internal mtu_request=1400 external-ids:iface-id=k8s-bsteciuk-worker-linux
Feb 13 16:29:40 bsteciuk-worker-linux ovn-nbctl: ovs|00001|nbctl|INFO|Called as /usr/bin/ovn-nbctl --db=tcp:<IP_ADDRESS>:6641 --timeout=5 -- --may-exist lsp-add bsteciuk-worker-linux k8s-bsteciuk-worker-linux -- lsp-set-addresses k8s-bsteciuk-worker-linux "e2:4d:21:c3:f6:15 <IP_ADDRESS>"
Feb 13 16:29:41 bsteciuk-worker-linux ovn-nbctl: ovs|00001|nbctl|INFO|Called as /usr/bin/ovn-nbctl --db=tcp:<IP_ADDRESS>:6641 --timeout=5 set logical_switch bsteciuk-worker-linux load_balancer=cf9f654e-aa26-4b42-ba7b-69499507fa34
Feb 13 16:29:41 bsteciuk-worker-linux ovn-nbctl: ovs|00001|nbctl|INFO|Called as /usr/bin/ovn-nbctl --db=tcp:<IP_ADDRESS>:6641 --timeout=5 add logical_switch bsteciuk-worker-linux load_balancer 418b52f5-6d19-4611-a991-65b8f0b0d8b2
Feb 13 16:29:41 bsteciuk-worker-linux ovs-vsctl: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=5 -- --may-exist add-br brens4 -- br-set-external-id brens4 bridge-id brens4 -- set bridge brens4 fail-mode=standalone other_config:hwaddr=42:01:0a:8e:00:0b -- --may-exist add-port brens4 ens4
INFO[0000] Successfully created OVS bridge "brens4"
INFO[0000] Successfully saved addr "<IP_ADDRESS>/32 brens4" to bridge "brens4"
Feb 13 16:29:41 bsteciuk-worker-linux kernel: [ 4624.246838] device brens4 entered promiscuous mode
Feb 13 16:29:41 bsteciuk-worker-linux kernel: [ 4624.247086] device ens4 entered promiscuous mode
ERRO[0000] Add route to bridge "brens4" failed: network is unreachable
ERRO[0000] Failed to convert nic ens4 to OVS bridge (network is unreachable)
panic: Failed to convert nic ens4 to OVS bridge (network is unreachable)

goroutine 1 [running]:
main.main()
	/home/bsteciuk/go/src/github.com/ovn-kubernetes/go-controller/_output/go/src/github.com/openvswitch/ovn-kubernetes/go-controller/cmd/ovnkube/ovnkube.go:177 +0x181c

It looks like the failure is occurring in nicstobridge.go:51 with network is unreachable while trying to add route to the ovs bridge.  I don't see this failure when -init-gateways true is not set.
Worth noting, that this leaves the node in a state where it can no longer be access via network, nor can it make connections out.  This was on a cluster running in GCE.

@bsteciuk
3 questions/comments

How many interfaces do you have in your box?

If you have more than one interface, is ens4 your primary interface? i.e one with default gateway configured?

If you have more than one interface, and ens4 is not your primary interface, you should likely have to provide the default gateway for ens4 as part of the -node-init command.

For e.g:
https://github.com/openvswitch/ovn-kubernetes/blob/master/vagrant/provisioning/setup-k8s-minion.sh#L86

@shettyg  it's just the one interface ens4

Okay. It is possible that, because GCE has the /32 interface, the code to convert interface from nic to bridge is buggy. It may be missing an additional step. Let me look into it.

@bsteciuk
I do not have a GCE machine handy. My local simulation with a /32 interface seems to work with the above referenced patch.


An assembled ship will lose texture if I look up at it.

If I run the game without the Optfine mod, or with that mod but setting the shader option as "OFF" (instead of "Internal"), the texture of the assembled ship's blocks will all be rendered as solid color (mostly light blue) if I look up (at an angle above 45 degrees, more or less?) at the ship, this texture issue could occur both inside and outside the assembled ship.
Running the game with the Optfine mod and choosing the "internal" shader option would indeed avoid the problem, although some other mods will have glitch (e.g. Flan's mod) or stop working (e.g. Colored Lights mod). Since the Optfine mod is an additional mod after all, I wonder if this problem should be deemed as a bug or an incompatible issue.
In addition, when I run the game with the Optfine mod and the shader setting as "OFF", if I dive into the sea (or any other water that deep enough and outside the assembled ship, I guess?), look up at the assembled ship, then get out of the sea, the texture issue will be somehow alleviated (texture will be faded, but not solid color anymore, which is much more tolerable).
I'm using the latest update 1.0 for 1.12.2.

You need to set shaders up before entering a world to avoid this issue. I am using seus renewed shaders on my side and there is no compatibility issue.

And there could be some additional compatibility issues with other mods instead of optifine. Or could be some optifine settings you need to turn off, like fast math for example. I suggest you tweak around with optifine settings first and see if the problems still exist. But remember you may need to quit and re enter the world every time you change optifine settings. I have been played vs on both client and server for a long time, never had such issues with optifine.

And there could be some additional compatibility issues with other mods instead of optifine. Or could be some optifine settings you need to turn off, like fast math for example. I suggest you tweak around with optifine settings first and see if the problems still exist. But remember you may need to quit and re enter the world every time you change optifine settings. I have been played vs on both client and server for a long time, never had such issues with optifine.

Thanks for replying. Although in my case, the issue aforementioned occurs WITHOUT the Optifine mod, thus I thought it might be a bug that need to report.

This should not be a vs problem, what other mods did you have?

You are right, it turns out that the Albedo mod is the one causing the problem. Sorry for all the trouble caused by my negligence.


Vulkan: Don't warn about invalid pipelines cache if missing or outdated

This is just noisy, it warns when opening a new project because no cache
pre-exists, and it warns when opening a project after having done any
kind of rendering adjacent edit, since the cache will need to change.
See https://github.com/godotengine/godot/issues/81150#issuecomment-1978698527
Also include the rendering method in the cache filename, as it differs
between Forward+ and Mobile for a same GPU.
Full set of pipelines caches on my laptop with integrated AMD and discrete AMD GPUs, editing both Forward+ and Mobile versions of a blank Vulkan project.
$ ls -l ~/.local/share/godot/app_userdata/TestVulkan/vulkan/
total 1800
-rw-rw-rw-. 1 akien akien 722500 Mar  5 14:23 'pipelines.forward_plus.amd_radeon_graphics_(radv_gfx1103_r1).editor.cache'
-rw-rw-rw-. 1 akien akien 722500 Mar  5 14:24 'pipelines.forward_plus.amd_radeon_rx_7600m_xt_(radv_navi33).editor.cache'
-rw-rw-rw-. 1 akien akien 195624 Mar  5 14:21 'pipelines.mobile.amd_radeon_graphics_(radv_gfx1103_r1).editor.cache'
-rw-rw-rw-. 1 akien akien 195624 Mar  5 14:21 'pipelines.mobile.amd_radeon_rx_7600m_xt_(radv_navi33).editor.cache'

$ md5sum ~/.local/share/godot/app_userdata/TestVulkan/vulkan/*
2ecc1c142a674127d8417136d43162d4  /home/akien/.local/share/godot/app_userdata/TestVulkan/vulkan/pipelines.forward_plus.amd_radeon_graphics_(radv_gfx1103_r1).editor.cache
19fb5379fb8254e22f4f04144970e82a  /home/akien/.local/share/godot/app_userdata/TestVulkan/vulkan/pipelines.forward_plus.amd_radeon_rx_7600m_xt_(radv_navi33).editor.cache
690d563e72ef52973ac18370e5ff5183  /home/akien/.local/share/godot/app_userdata/TestVulkan/vulkan/pipelines.mobile.amd_radeon_graphics_(radv_gfx1103_r1).editor.cache
088f86d4dc5dfc06a04de1b9b87b2bc1  /home/akien/.local/share/godot/app_userdata/TestVulkan/vulkan/pipelines.mobile.amd_radeon_rx_7600m_xt_(radv_navi33).editor.cache

and it warns when opening a project after having done any kind of rendering adjacent edit, since the cache will need to change.

In theory it should not do that. There seems to be an unrelated error as to why it thinks the pipeline cache is corrupted every time it starts. The only kind of change that should lead to invalidating it is a driver version change or some source-level change in Godot itself that invalidates everything by changing the version number.
That said the pipeline cache is a bit of a discussion point and I'm not sure I've seen much benefit of using it myself. I think the current belief is that Mobile might rely more on it, as on desktop it's pretty much guaranteed the driver will handle it as well.

See https://github.com/godotengine/godot/pull/80232 which makes the messages more descriptive instead.


Deploy your Docker image to Kubernetes

As a [role]
I need [function]
So that [benefit]
Details and Assumptions
* [document what you know]

Acceptance Criteria
gherkin
Given [some context]
When [certain action is taken]
Then [the outcome of action is observed]

Title: Deploy your Docker image to Kubernetes
As a service provider
I need my service to run on Kubernetes
So that I can easily scale and manage the service
Assumptions

Kubernetes manifests will be created in yaml format
These manifests could be useful to create a CD pipeline
The actual deployment will be to OpenShift

Acceptance Criteria
Given the Kubernetes manifests have been created
When I use the oc command to apply the manifests
Then the service should be deployed and run in Kubernetes


Move fft

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

130 of 136 (95.59%)  changed or added relevant lines in 2 files are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.2%) to 87.169%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/engine/piano.rs
81
83
97.59%

src/rpc.rs
49
53
92.45%

Files with Coverage Reduction
New Missed Lines
%

src/engine/piano.rs
1
95.59%

src/rpc.rs
2
88.5%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
2106

Relevant Lines:
2416

💛  - Coveralls


Phaser.GameObjects.Group.destroy() seems to be failing

Possible bug in the API (Phaser 3.0.0)
this.balloonsArray = [];
...

generateBalloon() : void{
   let balloonGroup = this.add.group();
   balloonGroup.create(700, 100, 'misc', 'balloon';
   this.balloonsArray.push(balloonGroup);
}

update() : void{
    for(let x = 0; this.balloonsArray[x]; x++){
        let balloonGroup = this.balloonsArray[x];
        Phaser.Actions.IncX(balloonGroup.getChildren(), 1);
        if(balloonGroup.getChildren()[0].x > 750){
            balloonGroup.destroy();
            this.balloonsArray.splice(x, 1);
        }
    }
}

I would expect ballonGroup to be destroyed by balloonGroup.destroy(); but it remains on screen.
So I wonder if the Phaser.GameObjects.Group.destroy() method is failing.
Thank you!

From what I've seen on the source code, Group.destroy() only cleans up the group, clearing its Set of children gameobjects without calling .destroy() on them.
Maybe there can be added a destroyChildren=false parameter that if true also calls something like this on the children (or a new Actions.Destroy)?
Phaser.Actions.Call(this.children.entries, function(child) {child.destroy()});

AFAIK, this is by design. Phaser 3 avoids the parenting mess, and groups are merely ways to organize sprites together, so that you can run Actions on them, etc. Sprites are always children of the scene, so deleting a group should not delete the children.
I do agree with @agilul though, it would be nice if you could specify a boolean to force the removal of the group's children as well.
For now, one easy way is just to baloonsGroup.getChildren().map(child => child.destroy()), or similar.
I have also noticed a bug in your code: The for loop you use walks through the indices of balloonsArray, but as soon as you splice it, the indices change. If you are using ES6, a more elegant solution would be to use Array.reduce().

As @Ziao said this is indeed by design, as unlike v2 Groups in v3 are not exclusive parents. A Sprite can exist in multiple Groups at the same time.
We could look at adding a destroyChildren argument, but in order for that to work, we'll have to change it so that Game Objects always emit a destroyed event, so that other Groups can listen for it and act accordingly. Which is probably a good idea anyway, as if you currently destroy a child of a Group, the Group doesn't know this has happened and will still include it in getChildren calls.

Thank you all very much.  Greatly appreciated.  I'll play some more with this.
So with regards parent > child relationships, would we just set the origin of all objects to the same co-ordinate and apply transforms to each object rather than have a parent child relationship and just transform the parent?

That's one way to do it. I did make a little something for people who can't
let go of the old parenting system. Sometimes it just makes more sense to
have groups behave the way they did in Phaser 2. Feel free to have a look.
https://github.com/Ziao/phaser3-interim-containers
On 20 Feb 2018 08:28, "Dougi"<EMAIL_ADDRESS>wrote:

Thank you all very much. Greatly appreciated. I'll play some more with
this.
So with regards parent > child relationships, would we just set the origin
of all objects to the same co-ordinate and apply transforms to each object
rather than have a parent child relationship and just transform the parent?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/photonstorm/phaser/issues/3246#issuecomment-366888906,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABiZL-1PyJB16X0yNUZjdw52QduVMQSmks5tWnQtgaJpZM4SJOhS
.

Thanks very much :)

Thank you for submitting this feature request. We have implemented this and the feature has been pushed to the master branch. It will be part of the next release. If you get time to build and test it for yourself we would appreciate that.

baloonsGroup.getChildren().map(child => child.destroy())
This does not remove all children. removes only few and remaining are still live.
Please help


grpc-web: need to create a seperate client from clientFactory.

The way secretjs structured is different from how a client is created in telescope, we have secrets client which defined in https://github.com/scrtlabs/secret.js/blob/830165acac47dab1cafce4e0d2741aa924aa738a/src/secret_network_client.ts and our client is originally created using extern.ts (https://github.com/osmosis-labs/telescope/blob/main/fixtures/v-next/outputv2/extern.ts).

[x] make a working JS template using grpc-web client generate from telescope.
[x] update the telescope ast and generators using modified client.

https://github.com/hoangdv2429/grpc-web-js working grpc-web template


Metrics data not reporting after installing Gatsby Plugin Quickstart

After setting up a test Gatsby site on a branch of OSS we found that the metric data wasn't reporting to the dashboards setup using the gatsby build quickstart.
steps to reproduce
visit this dashboard and view the metrics tab
expected
metric data is reporting for this test gatsby site.

@rudouglas 👋

Looking into this @jpvajda looks like an integration error, seeing the following:
One or more metrics rejected because attribute value exceeded maximum length. For more info visit https://docs.newrelic.com/docs/troubleshoot-nrintegrationerror-events'

@rudouglas ok, but I just installed a quickstart and followed our plugin instructions to set it up, so what would a user do in this case? Are you saying they'd need to follow the doc to troubleshoot? I guess I thought the point of a quickstart was to have it work out of the box?

Oh @jpvajda i forgot there was a separate ticket for this, this was what I resolved in the PR, you shouldn't see this issue anymore


Revert "Revert "Roll engine to 7d17da76d""

Reverts flutter/flutter#19792
The failing test is flaky (marked as such in #19824)

Reusing the LGTM of the original roll, I'm landing this as we think the failure was a flake.


[release-1.12] bump base images for release-1.12

prompted by https://github.com/cert-manager/cert-manager/issues/4033
/kind cleanup
NONE

/lgtm


Removed the link to the Asciicast of the Hello World example

I removed the link of the Asciicast of the Hello World example as per this comment from @fcrozetta: https://github.com/fcrozetta/tui-netcore/issues/13#issuecomment-711231863

All the images should be included in one PR


Make Selector fully private

Currently, Selector is only public in order to support the Evented trait which exposes the type as part of it's API. It should be possible to fix this.

Just to make sure - do you plan to have outside types able to implement Evented? I've implemented Evented for a few types in other crates, but I could also work around it if it became impossible.

It should be plausible to make it private and let you implement Evented as long as you can proxy the call to some other Evented type that you own.

The implementation (all methods) can be private, but the type itself has to be exposed if it's part of the method signatures on Evented.

Related see #319.

The strategy here will be to have Evented take an EventLoop reference vs. a Selector reference. Internal to Mio implementations of Evented will be able to access the selector via EventLoop, implementations external to Mio can proxy to other Evented types.

Fixed on master


Fix race condition when rendering the UI

~This fix depends on a fix in ign-rendering module, because it
depends on the new Camera::SwapFromThread function
Without it, compilation will fail~
~The PR for ign-rendering can be found at https://github.com/ignitionrobotics/ign-rendering/pull/307~
Forget about that PR for now
🦟 Bug fix
Fixes ignitionrobotics/ign-rendering#304
Checklist

[x] Signed all commits for DCO

Ooofff!
This was quite the Pandora's box. Fix a bug, 3 new race conditions appear. I hope I got them all (or at least the major ones).
I think some random crashes on shutdown are explained by a race condition I fixed.
It's ready for review. It does not depend on anything, but may require additional testing.
If everything goes fine, I think this fix can be (back-)ported to pretty much all branches!
Btw: What's the deal with ign-gui? @iche033 said the goal was to merge these two files; but I don't know when/where is ign-gui's Scene3D.cc file is used.
Considering they're almost identical, I suspect these patches have to be ported there too, but I don't know how to test it because I how to trigger ign-gui's version

What's the deal with ign-gui? @iche033 said the goal was to merge these two files

Yup, here's the issue for that: https://github.com/ignitionrobotics/ign-gui/issues/137. We're currently studying the possibility of doing it as part of https://github.com/ignitionrobotics/ign-gazebo/issues/556.

I don't know when/where is ign-gui's Scene3D.cc file is used.

ign gui -c <path to ign-gui>/examples/config/scene3d.config instantiates ign-gui's Scene3D, for example. It's not a very interesting scene though.
The ign_rviz project makes a more interesting use of that Scene3D.

Moving the camera when no Qt GUI elements are being updated. For example, when the simulation is paused, the Real Time Factor (RTF) % number on the bottom right of the screen is static - in this case sometimes camera movement locks up

How do I repro that? Just keyboard movement? (I can't see the UI right now because it's compiling...)

How do I repro that? Just keyboard movement? (I can't see the UI right now because it's compiling...)

Here are the steps I did:

Run ign gazebo as usual (paused)
ign gazebo -v 4 shapes.sdf`

Press with left mouse and drag to pan the camera -> sometimes camera movement works sometimes it does not for me

Press Play button and repeat camera movement -> camera movement always works for me

Here's a gif showing the issue. The first time I tried to move the camera when simulation is paused, it does not work. After hitting play, I did not have problem. I then paused the simulation again - this time the first mouse movement worked but subsequent mouse drags didn't.

Ooof!!! Finally.
It was our own fault after all (i.e. not the alleged glibc bug).
The problem is that rendering changed between Qt versions and newer versions offload some work to a worker thread that was previously in the main thread. This causes potential deadlock scenarios that would not happen (or extremely rarely) in older Qt versions.
I've redone the synchronization code. It seems to work fine in both machines environments now.
It should be ready for review and hopefully merge.

OK all outstanding issues fixed. Should be (hopefully) ready for merge.

@osrf-jenkins run tests please

test failures look unrelated. latest changes look good to me. Merging.


Add better examples in the documentation

Is your feature request related to a problem? Please describe.
Following the examples in the README returns empty responses.
Describe the solution you'd like
If a user follows the instructions in the README, then more useful responses should be default.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

We can additionally add some examples from the DocDB workshop capsule?

Sounds good


iree_tf_compiler/TF can be replaced with TensorFlow functionality

TensorFlow now has code that lowers savedmodels to stablehlo + ml_program (pass pipeline). This aims to be equivalent to (and is, in fact, heavily inspired by) the IREE code under iree_tf_compiler/TF.
At the very least, several pass implementations can likely be deleted (e.g. LowerGlobalTensors and StripMetadata), but possibly the entire iree-import-tf binary can be replaced with something that instead calls the TensorFlow binaries, in the following way:
tf-mlir-translate --savedmodel-objectgraph-to-mlir /path/to/saved_model/ > savedmodel.mlir
tf-opt -tf-lower-to-mlprogram-and-hlo savedmodel.mlir

Thanks for the update! I was just about to ask earlier today, glad to be beaten to the punch :) OOC do those tools make it to any of the pip packages?

OOC do those tools make it to any of the pip packages?

I don't see them in the tensorflow pip package. Which probably makes sense, they're not used much outside of unit tests.
I think you can access the passes / pipelines from Python, though?

We can also (maybe, if the maintainers let us) add ml_program+stablehlo output capability to savedmodel_cli. The latter does get shipped with tensorflow pip.

Yes couple of options, was just prefetching some ideas. It'll unfortunately be a bit of time before we get to integrating here... Well I want to try, but should decrease stack first before adding on :-)

This is great progress - thank you Matthias!
 It would be great to have proper python apis, but if we got equivalent functionality into savedmodel_cli, that would allow for an immediate transition to use that behind iree's python apis, and I expect we could then kill the importer completely. Even if transitional, that could be a good way to go...

(adding Natasha to track & help with switch post Python APIs/savedmodel_cli usability)

Once the tensorflow pip package is recent, looks like we can just do
from tensorflow.python import pywrap_mlir

saved_model = pywrap_mlir.experimental_convert_saved_model_to_mlir(
    "/path/to/saved/model", [], show_debug_info=False)
result = pywrap_mlir.experimental_run_pass_pipeline(
    saved_model, "tf-lower-to-mlprogram-and-hlo", show_debug_info=False)

(There's some string serialization happening here, but it doesn't seem like there's a way around that given that tensorflow statically links against its own MLIR.)
Will update this thread once this is good to go.

Update: With tf-nightly, the code given in the previous comment works now. However, I've seen it trigger a bug (segfault) in TF's pattern matcher, for some models. Will post an update once that issue is resolved.

Thank you Matthias!

This should be good to go now (using tf-nightly).

Seems to be textual/debugging format still rather than bytecode but using StableHLO (conversion to StableHLO at end of pipeline from MHLO, so should be input here).

And we'd need to encode as bytecode TF side/part of nightly release.

This is a really interesting feature that I'm sure non-IREE users (like myself) would be interested in as well. I was looking at forking just iree_tf_compiler as a way of getting a tool to get HLO just from a saved model.
I created this test that shows a more complete example. It reuses some of the code from the TF SaveModel tutorial, but also exports the backprop program. I added conversion back to HLO for kicks.
""" Example showing how to turn a SavedModel into an MLIR module that contains
only StableHlo/HLO dialect + upstream MLIR dialects.
"""
import tensorflow as tf
from tensorflow.python import pywrap_mlir
from pathlib import Path

saved_model_path = "./test_model"

# ---------------------------------------------------------------
# Create a simple test model
# ---------------------------------------------------------------

class CustomModule(tf.Module):
  def __init__(self):
    super(CustomModule, self).__init__()
    self.v = tf.Variable(1.5)

  @tf.function
  def __call__(self, x):
    print("tracing with", x)
    return x * self.v

  @tf.function
  def train_step(self, input):
    with tf.GradientTape() as tape:
      loss = (10. - self(input)) ** 2
    variables = tape.watched_variables()
    grads = tape.gradient(loss, variables)
    print(grads)
    return list(grads) + [loss]

module = CustomModule()
infer_call = module.__call__.get_concrete_function(
  tf.TensorSpec((None, 10, 10, 10), tf.float32))
train_call = module.train_step.get_concrete_function(
  tf.TensorSpec((None, 10, 10, 10), tf.float32))
tf.saved_model.save(module, "./test_model",
                    signatures={"infer": infer_call, "train": train_call})

# ---------------------------------------------------------------
# Convert saved model to Stablehlo + upstream MLIR ops
# ---------------------------------------------------------------

def convert_to_hlo(model_path: str, use_stablehlo=True):
  result = pywrap_mlir.experimental_convert_saved_model_to_mlir(
      saved_model_path, "", show_debug_info=False)
  pipeline = ["tf-lower-to-mlprogram-and-hlo"]
  if not use_stablehlo:
    pipeline.append("stablehlo-legalize-to-hlo")
  result = pywrap_mlir.experimental_run_pass_pipeline(
      result, ",".join(pipeline), show_debug_info=False)
  return result

Path("test_model.stablehlo.mlir").write_text(
  convert_to_hlo("./test_model", True))
Path("test_model.hlo.mlir").write_text(convert_to_hlo("./test_model", False))

I currently have signature of shape to be dynamic in the first dimension. In this case, the backprop function will still contain some tf ops including things like tf.Sum. It seems  to be do to presence of tf.BroadcastGradientArgs.
When shapes are static all TF opeations are gone.
It would be awesome to be able to pass MLIR printer args as well like mlir-elide-elementsattrs-if-larger=32 and mlir-print-local-scope

When shapes are static all TF opeations are gone.

Yeah this may be the same gap mentioned above (dynamic shape support paths diverged a bit), so this is great example.

It would be awesome to be able to pass MLIR printer args as well like mlir-elide-elementsattrs-if-larger=32 and mlir-print-local-scope

Agreed, I think we could do it with wrapper (we are parsing strings quite a bit here ... but I think for export path this may be OK starting point).

Sent out bytecode writing for review TF side.
@matthiaskramm could you follow up on missing legalization in this example with bridge team?

Thanks for sending out the bytecode change, Jacques! Beat me to the punch. :)
The dynamic shape issue is known, and being worked on. Not sure about timelines, though. For now, trying to make shapes static whenever possible is a good idea.

I propose that it is now time to disable TF dynamic shape tests. We have the coverage through other channels, and I believe we need to re-evaluate requirements and design for the TF side in light of strong work on the Jax/PyTorch/TFLite side and the actual needs of a compiler at this level.

@christopherbate did you do anything special to get the tf-lower-to-mlprogram-and-hlo pipeline pass registered? I'm getting the following error when I try to run your code:
tensorflow.python.framework.errors_impl.InvalidArgumentError: Invalid pass_pipeline: MLIR Textual PassPipeline Parser:1:1: error: 'tf-lower-to-mlprogram-and-hlo' does not refer to a registered pass or pass pipeline
tf-lower-to-mlprogram-and-hlo

It looks like the pipeline name is correct; I'm not sure how to get this code to run though (assuming it isn't).

@dellis23 the TF 2.11 release does not register the pass  tensorflow::RegisterMlProgramPasses(). You can use the nightlies however.

I have a rudimentary version working, but the exposed public names using the tensorflow API are not consistent with what we're producing now.
As an example, consider the following model:
class MyModel(tf.Module):

  @tf.function
  def train(self, x):
    #...

Using the current iree-import-tf tool, I get back MLIR with a public train function and a private __inference_train_250 function; I'm able to run train using iree-run-module just fine.
Using experimental_convert_saved_model_to_mlir, the returned MLIR has the nice train name stripped entirely, leaving only __inference_train_250. I'm able to run that with IREE, but I think this is pretty obviously a non-starter from a usability and regression perspective.
(As a side note, I've dug through saved model internals for years and the contradiction in the name __inference_train_250 is somehow still humorous to me.)

Filed https://github.com/tensorflow/tensorflow/issues/59685

When this is solved do you think that we could modify this section of the image in the Readme?

When this is solved do you think that we could modify this section of the image in the Readme?

I think it can be updated but for other reasons. There is still an input and preprocessing to useful state for IREE/OpenXLA that happens there. This moved some of what was in the TF specific import upstream (but the same is true for JAX, TOSA and PyTorch independent of this), but there is still some massaging required before it is in desired input format. It can be made more explicit where some of these importers live now.

Mhh... so what is the relationship between the Importers block and the API in https://github.com/openxla/openxla-pjrt-plugin?
Isn't the plugin ingesting directly StableHLO program?

Plugin and IREE are different things. While there is a plugin whose interfaces are implemented (and we are promoting that as/evolving it for framework integration), that is not the only way to use IREE. StableHLO is a supported opset but not an exclusive input one (that's true for the plugin too though).

Plugin and IREE are different things. While there is a plugin whose interfaces are implemented (and we are promoting that as/evolving it for framework integration), that is not the only way to use IREE. StableHLO is a supported opset but not an exclusive input one (that's true for the plugin too though).

Thank you for the clarification, I've supposed that StableHLO was the only unified entry-point in the roadmap.
Does it makes sense to upgrade the welcome image at least if it isn't generically represented only by IREE importers blocks?
e.g. is StableHLO  an IREE importer? Is the standard plugin API an IREE importer?

I'm not quite sure of the distinction you're trying to make. IREE often requires or handles additional preprocessing on top of whatever the input format is - that code generally lives in IREE, and is an "IREE importer for a particular input representation" - see https://github.com/openxla/iree/tree/main/compiler/src/iree/compiler/InputConversion.

Ok I suppose that this means that also for StableHLO we will have just another preprocessor/importer.

Ideally we'd replace the MHLO path with StableHLO when it's ready.

Closed via https://github.com/openxla/iree/pull/12758

https://github.com/openxla/iree/pull/12972

@dellis23 Is this closed?

I'm not sure of the current state of this.  I'm no longer working on it, but I forgot to change the assignee field.

I'm pretty sure this issue as filed is fixed now, though there are some related threads in the discussion here. How about we file new issues/discussions if there are still areas to work on?


Client and server don't have same version

I keep getting the following error even though I just updated everything today (both brew and dinghy upgrade):

Error response from daemon: client and server don't have same version (client : 1.19, server: 1.18)

Is there something wrong with my setup? Should I wait for a new release of Dinghy?

Sounds like your VM is still running docker version 1.7.0. Does /usr/local/var/dinghy/vagrant/Vagrantfile show config.vm.box_version = "1.7.1" ?
dinghy upgrade essentially just does cd /usr/local/var/dinghy/vagrant and then runs vagrant box update && vagrant destroy, creating a new VM using the latest image.

Nope it contains config.vm.box_version = "1.6.0"
I'm not sure I understood what you meant, how should I upgrade?

Woops nevermind I just realized that there are special instructions to upgrade Dinghy (https://github.com/codekitchen/dinghy#upgrading), I was expecting it to be handled by brew ;) my mistake
Will try that! Thanks


Fine tuning on 24 Hours of Tamil Dataset

Checks

[X] This template is only for question, not feature requests or bug reports.
[X] I have thoroughly reviewed the project documentation and read the related paper(s).
[X] I have searched for existing issues, including closed ones, no similar questions.
[X] I confirm that I am using English to submit this report in order to facilitate communication.

Question details
I have attempted test training on Tamil dataset with some own patches with 24gb VRAM, 8192 Cuda Cores.
And yes. it worked good with small amount of training and testing.
But my question and doubt is ,

is it ok that a dataset can contain multiple speakers (voices) in dataset ?
bcos getting a single speaker voice data set of 20+ hours is bit tough on my case.
Tamil script has 247 characters, 12 vowels, 18 consonants,1 special character. So can i add custom vocabs manually ?
Please help. TIA.

I think you'd better keep one speaker in small dataset
if you train from scratch in tamil, you can build your vocab. But if you want to finetune the F5 Base version, it will mismatch in vocab size

I think you'd better keep one speaker in small dataset

if you train from scratch in tamil, you can build your vocab. But if you want to finetune the F5 Base version, it will mismatch in vocab size

How to train from scratch? Can u please guide ?

I think you'd better keep one speaker in small dataset
if you train from scratch in tamil, you can build your vocab. But if you want to finetune the F5 Base version, it will mismatch in vocab size

How to train from scratch? Can u please guide ?

https://github.com/SWivid/F5-TTS/tree/main/src/f5_tts/train

I think you'd better keep one speaker in small dataset

if you train from scratch in tamil, you can build your vocab. But if you want to finetune the F5 Base version, it will mismatch in vocab size

How to train from scratch? Can u please guide ?

https://github.com/SWivid/F5-TTS/tree/main/src/f5_tts/train

Thanks.

will close this issue and you can reopen this issue if you have question : )


[AIRFLOW-2450] update supported k8s versions to 1.9 and 1.10

Make sure you have checked all steps below.
JIRA

[x] My PR addresses the following Airflow JIRA issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-2450
In case you are fixing a typo in the documentation you can prepend your commit with [AIRFLOW-XXX], code changes always need a JIRA issue.

Description

[x] Here are some details about my PR, including screenshots of any UI changes:

Upgrades supported k8s versions to 1.9 and 1.10.
Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Doesn't need any new unit tests since it only modifies existing unit tests.
Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[x] In case of new functionality, my PR adds documentation that describes how to use it.

When adding new operators/hooks/sensors, the autoclass documentation generation needs to be added.

Code Quality

[x] Passes git diff upstream/master -u -- "*.py" | flake8 --diff

@bolkedebruin @Fokko Small one but important :).

Codecov Report

Merging #3345 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3345   +/-   ##
=======================================
  Coverage   76.24%   76.24%
=======================================
  Files         198      198
  Lines       14778    14778
=======================================
  Hits        11267    11267
  Misses       3511     3511

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 7ca45b2...b1bd69a. Read the comment docs.


More restrictions in abstract methods

According to the spec: “When instantiating an extern type that has abstract methods users have to supply implementations for all such methods. This is done using object initializers”, which include function declarations and instantiations. First of all, this seems to imply that the compiler should check if users have defined implementations only for the abstract method declarations and also all such declarations are defined, but I think it is worthwhile to explicitly state that in the spec.
According to the spec, an object initializer can be an instantiation, but some types of instantiations can lead to unwanted behavior and should probably be prohibited. For example, if a control is instantiated in the initializers of an extern, which is instantiated in a parser, the parser can essentially call that control instance, which is forbidden by the manual in Appendix F. An additional column should be added to the “can be instantiated in this place” table to clarify that.
Litmus Test 1
control compute(inout bit<32> x) {
    apply { x = x + 1; }
}
parser parse {
    Virtual() vtl = {
	compute ci;
        @synchronous(f)
        bit<32> f(in bit<32> ix) {
            ci.apply(ix);
		 return ix;
        }
    };
    state start {
       h.ip.sip = vtl.f(h.ip.sip);
    }
}

This example is equivalent to calling the control instance ci in the parser state start, which is explicitly not allowed by the spec.
The spec says that “the abstract methods can only use the supplied arguments or refer to values that are in the top-level scope.” This restriction should probably be extended to also include the arguments to instantiations. Otherwise, given an instance instantiated with non-top-level variables as arguments, calling it in an abstract method implementation intrinsically breaks the bounds, making it possible to access/change the prohibited entities in the method implementation.
Litmus Test 2
control compute(inout bit<16> x) {
    Register<bit<32>,bit<16>>(32w65536, 0) reg;
    Virtual() vtl = {
        RegisterAction<bit<32>, bit<16>, bit<32>>(reg) regact = {
   	      void apply(inout bit<32> value, out bit<32> rv) {
                rv = value;
            }
        }
        @synchronous(f)
        bit<16> f(in bit<16> ix) {
            regact.execute(ix);
        }
    apply {
        vtl.f(x);
    }
};

This example is equivalent to accessing the non-top-level variable reg in the implementation of f, which is not allowed by the spec.
One last thing that is worth thinking about when formalizing the abstract methods is the nested initializer blocks, i.e. instantiation of an extern object A with an initializer block inside another instantiation of an extern object B with an initializer block. From the current scope restrictions in the spec, the inner initializer block should not access the instances in the outside initializer block, and the outside initializer block should not access the instances in the inner initializer block. The only allowed interaction is for synchronous abstract method implementation in A to call methods of the B.
Litmus Test 3
Register<bit<32>,bit<16>>(32w65536, 0) reg;
Virtual() vtl = {
    State(1024) state1;
    RegisterAction<bit<32>, bit<16>, bit<32>>(reg) regact = {
       State(1024) state2;
   	  void apply(inout bit<32> value, out bit<32> rv) {
            rv = value;
        }
    }
    @synchronous(f)
    bit<16> f(in bit<16> ix) {
        regact.execute(ix);
    }
};

Assuming that the restriction of the top-level scope extends to the entire initializer block, no entities in vtl can access state2, and no entities in regact can access state1. Only regact, after the complete instantiation, can be accessed by the synchronous function declarations of vtl. I think it is worth clarifying the scoping issues in nested initializers.

At the 2/7/22 LDWG, we agreed (as with #973) that adding further clarifying text to Appendix F would be good.
See the notes for an extended discussion of scope, restrictions on variables, etc.

In the interest of tidying up the set of active issues on the P4 specification repository, I'm marking this as "stalled" and closing it. Of course, we can always re-open it in the future if there is interest in resurrecting it.
Note link to #973.


Refactor and fix substituting, unify it with overrides

I'm almost sure that this works fine, but please review before merging.

It seems this fixes my issue, thanks!

LGTM, feel free to merge

:+1:


Have indicator for path normal that can be toggled

Closed path can have a meaningful polarity depending on whether they are defined clockwise or anti-clockwise. A similar notion can apply to open paths depending on the direction they are drawn.
This information can be important and it would be useful to have an indicator (typically an arrow) to indicate the 'direction' of the path. Such a visual indicator is something you would probably want to toggle as necessary.

Not saying we should do this since it will cause issues with using a Polygon as a primary data structure, but for reference I thought i'd explain how the XMS/CMB type suites works.

Polygons are made of Arcs (i.e. Polylines).
Arcs have direction and the direction can be reversed. Hence the Polygon might have Arcs with opposing direction. This doesn't fit the standard used for polygons in shapely/geojson etc.
Each Arc starts and ends at a 'Feature Vertex'.
Vertices along arcs can also be redistributed keeping the Feature Vertices unchanged.
Vertices can be promoted/demoted from being a Feature Vertex.

This gives very fine grained control, that allows things like grid generation and setting boundary conditions for models. Unfortunately, it doesn't quite fit into GIS paradigms for representing objects.

Still a priority for this phase.


WIP dark theme

I have found this guide how to create a dark theme: http://www.hidroh.com/2015/02/25/support-multiple-themes-android-app-part-2/
The "xml color" part was easy, but now I'm stuck in the java code part.
Since there is no settings menu I'm not sure to add one or not.
Can you help me?

For the Light / Dark theme - a simple toggle-menu item would be fine. You can achieve this with a simple menu entry (where the about item is for example) and storing the boolean in the shared preferences space, updating the menu-item's label when the state changes (and onResume()).

Since you do not recommend the app for daily usage, I close this PR


refactor docker-compose to make it easier

the docker-compose example is a learning tool, but people seem to be more interested in simply deploying an overlay quickly and easily and not so much for complex learning. relegate the current docker-compose to a learning tool by flipping the simplified-docker-compose.yml with the existing docker-compose.yml. Then, refactor the doc to focus on the new, easier, experience.
Also, refacotor the compose file to incorporate ALPN and radically simplify the .env file down to the most basic pieces. Example .env and compose files are located at https://github.com/dovholuknf/ozconfigs/tree/main/extrasimple for inspriation. .env file is much simpler and basically requires changing adding/changing/providing these values:
ZITI_FULLY_QUALIFIED_DOMAIN_NAME=cdaws.clint.demo.openziti.org
ZITI_CTRL_PORT=8441
ZITI_ROUTER_PORT=8440
ZITI_USER=admin
ZITI_PWD=

https://github.com/openziti/ziti/pull/2310

https://github.com/openziti/ziti-console/pull/449


Laravel 10.x Compatibility

This is an automated pull request from Shift to update your package code and dependencies to be compatible with Laravel 9.x.
Before merging, you need to:

Checkout the l10-compatibility branch
Review all comments for additional changes
Thoroughly test your package

If you do find an issue, please report it by commenting on this PR to help improve future automation.

:warning: Shift detected GitHub Actions which run jobs using a version matrix. Shift attempted to update your configuration for Laravel 10. However, you should review these changes to ensure the desired combination of versions are built for your package.

:alembic: Using this package? If you would like to help test these changes or believe them to be compatible, you may update your project to reference this branch.
To do so, temporarily add Shift's fork to the repositories property of your composer.json:
{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/laravel-shift/laravel-queued-db-cleanup.git"
        }
    ]
}

Then update your dependency constraint to reference this branch:
{
    "require": {
        "spatie/laravel-queued-db-cleanup": "dev-l10-compatibility",
    }
}

Finally, run: composer update


gc: allow disabling secret gc with a flag

Related to #45, for those of us who just don't want to delete at all.

Am not entirely happy with this change, I'd prefer a single gc flag that lets us set the timer to either no, or a time.Duration, and would default to 7d

Changed to be a duration, good call.

A few more slight things:

Let's have any zero or negative duration disable the GC (Should just be a matter of removing the if on startup I think ?)
The documentation needs to be updated

Will check this in detail in the next day or two

Have given this a good read, and I don't think this will behave as people expect it to, a secret can still get deleted within a day if the GC happens to trigger the day after.
As #45 suggests, we should probably record the time a secret goes unused and use that as the threshold, and meanwhile also leave the option in to disable GC entirely.
Is this a change you'd want to work on ? The current flag is useful regardless, so I'm ok with it if you aren't.

My initial pr to disable GC was with the intent of later coming back and doing #45. I'm happy to do it properly instead, it'll just take longer for me to find the spare cycles.

Thank you!


Update to 1.40

Update to SGDK 1.40.
Fix example to compile with this version.
Update Dockerfile to use Ubuntu 18.04.
Update deb package dependencies to add JRE 8 and make.
Update README.

I'm trying to see why you are getting errors in Travis.  It looks like missing texinfo, not sure why ..

Hi,
thanks.
I don't understand what's happen. Texinfo is in addons apt.

I'm working on switching to CircleCI from Travis, I think this will give more reliable builds.  However, I'm showing both locally and in Circle that the SGDK samples no longer build on 1.4.

I have rebase with your recent changes.
Samples compile but I have got warning:
~/3d_example$ make-gen
mkdir -p src/boot
mkdir -p out
mkdir -p out/src
mkdir -p out/res
cp /opt/gendev/sgdk/src/boot/sega.s src/boot/sega.s
cp /opt/gendev/sgdk/src/boot/rom_head.c src/boot/rom_head.c
/opt/gendev/bin/m68k-elf-gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -I/opt/gendev/sgdk/inc -I/opt/gendev/sgdk/res -B/opt/gendev/sgdk/bin -c src/boot/rom_head.c -o out/rom_head.o
/opt/gendev/bin/m68k-elf-ld -T /opt/gendev/sgdk/md.ld -nostdlib --oformat binary -o out/rom_head.bin out/rom_head.o
/opt/gendev/bin/m68k-elf-gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -I/opt/gendev/sgdk/inc -I/opt/gendev/sgdk/res -B/opt/gendev/sgdk/bin -c src/boot/sega.s -o out/sega.o
/opt/gendev/bin/m68k-elf-gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -I/opt/gendev/sgdk/inc -I/opt/gendev/sgdk/res -B/opt/gendev/sgdk/bin -O3 -fuse-linker-plugin -fno-web -fno-gcse -fno-unit-at-a-time -fomit-frame-pointer -flto -c main.c -o out/main.o
In file included from main.c:3:0:
meshs.h:125:5: warning: braces around scalar initializer
     {FIX16(0)},
     ^
meshs.h:125:5: note: (near initialization for 'cube1_p.distance')
main.c: In function 'render':
main.c:115:32: warning: passing argument 2 of 'M3D_project_s16' from incompatible pointer type [-Wincompatible-pointer-types]
     M3D_project_s16(stars_t3D, stars_t2D, NUM_STARS);
                                ^~~~~~~~~
In file included from /opt/gendev/sgdk/inc/genesis.h:20:0,
                 from main.c:1:
/opt/gendev/sgdk/inc/maths3D.h:276:6: note: expected 'V2s16 * {aka struct <anonymous> *}' but argument is of type 'Vect2D_u16 * {aka struct <anonymous> *}'
 void M3D_project_s16(const V3f16* src, V2s16* dest, u16 numv);
      ^~~~~~~~~~~~~~~
main.c: In function 'drawPoints':
main.c:297:13: warning: value computed is not used [-Wunused-value]
             *pt_dst--;
             ^~~~~~~~~
main.c:270:14: warning: unused variable 'str' [-Wunused-variable]
         char str[10];
              ^~~
echo "out/main.o" > out/cmd_
/opt/gendev/bin/m68k-elf-gcc -B/opt/gendev/sgdk/bin -n -T /opt/gendev/sgdk/md.ld -nostdlib out/sega.o @out/cmd_ /opt/gendev/sgdk/lib/libmd.a /opt/gendev/sgdk/lib/libgcc.a -o out/rom.out
rm -f out/cmd_
/opt/gendev/bin/m68k-elf-objcopy -O binary out/rom.out out/rom.bin
/opt/gendev/bin/sizebnd out/rom.bin -sizealign 131072

Oh gotcha, yeah the 3d examples I wrote now work (thanks!) but the SGDK provided samples don't.  Try make sgdk_samples

Hi,
if you spoke about this:
src/main.c: In function 'main':
src/main.c:288:5: error: too many arguments to function 'SPR_initEx'
     SPR_initEx(20, 80, 64);
     ^~~~~~~~~~
In file included from /opt/gendev/sgdk/inc/genesis.h:33:0,
                 from src/main.c:1:
/opt/gendev/sgdk/inc/sprite_eng.h:396:6: note: declared here
 void SPR_initEx(u16 vramSize, u16 unpackBufferSize);
      ^~~~~~~~~~
/opt/gendev/sgdk/mkfiles/makefile.gen:148: recipe for target 'out/src/main.o' failed
make[2]: *** [out/src/main.o] Error 1
rm res/music.s res/gfx.s
make[2]: Leaving directory '/tmp/gendev/sgdk/SGDK/sample/xgmplayer'
Makefile:73: recipe for target '/tmp/gendev/sgdk/SGDK/sample/xgmplayer/out/rom.bin' failed
make[1]: *** [/tmp/gendev/sgdk/SGDK/sample/xgmplayer/out/rom.bin] Error 2
make[1]: Leaving directory '/tmp/gendev/sgdk'
Makefile:48: recipe for target 'sgdk_samples' failed
make: *** [sgdk_samples] Error 2

but it's SGDK issue.
If you take SGDK release v1.40 on Windows, you have same issue.

Cool, good to know.  I've got your fork pulled into a branch and am tweaking a few things.  Thanks for getting this going!

Your welcome

Closing this PR since these changes have now been pulled in.


BsonReader and BsonWriter are interfaces

In driver 3.8 these are interfaces

Thanks for the PR @arunkjn


Update snippets to dotnet8

Summary
Fixes #40684
Updated projects from .NET 6 & .NET 7 to .NET 8. Keeping in draft mode to review myself, but will leave a few questions.

[x] Clean up unnecessary <LangVersion> tags
[ ] Unsure what to do with this project and its dockerfile

/samples folder is excluded from the versionsweeper.json, but I think it's a good idea to update samples there as well (unless it's a specific sample for older .NET version). Maybe a new task for that?

Internal previews

📄 File
🔗 Preview link

docs/standard/security/cryptographic-signatures.md
Cryptographic Signatures

docs/standard/security/cryptography-model.md
".NET cryptography model"

docs/standard/security/decrypting-data.md
Decrypting data

docs/standard/security/encrypting-data.md
Encrypting data

docs/standard/security/replacing-a-principal-object.md
"Replacing a Principal Object"

Hey @IEvangelist, I have some more work to do on this and review if I hadn't updated something by mistake, but I need some guidance with the snippets build task; namely

PassingStructVsClass got its Program.cs removed
type-forwarders got its 'after' projects removed

I suppose they were removed as they were not referenced anywhere. Should I backtrack and re-add them?

Hey @IEvangelist, I have some more work to do on this and review if I hadn't updated something by mistake, but I need some guidance with the snippets build task; namely

PassingStructVsClass got its Program.cs removed
type-forwarders got its 'after' projects removed

I suppose they were removed as they were not referenced anywhere. Should I backtrack and re-add them?

I wouldn't re-add them, no. Perhaps remove their projects, if those aren't referenced anymore either. Thanks for doing this, looks great thus far! I viewed EVERY SINGLE change 🤣.

I tried to remediate some Snippets 5000 issues in this commit which seems to have fixed the errors I had in the prior runs. Then I encountered a new boss: the schrödinger's solutions - they don't exist at the target location, yet they throw an error. Now I am in awe, have doubts about said commit and question my life choices.
Jokes aside, I am unsure how to proceed and am open to suggestions.

I'll investigate the snippets tool to see where that bug is. It seems it does flip out because of the deleted SLN, and not on anything actually valid.
One thing to do though, the security snippets were moved around but their current folder structure doesn't follow our guidelines. You have:
security\snippets\csharp\decrypting-data
security\snippets\vb\decrypting-data

Which is ...\snippets\language\article-name\code but the structure should be ...\snippets\article-name\language\code

Looking...

Ahh OK, so I think those two solution files (readded via the revert) were added before we had perfected some of our detection. There should be 0 or 1 solution files in that folder. You can put all projects in the same solution and see if that works, but in the past I've seen it complain when the projects are named the same and only the language is different. Hopefully .NET/Visual Studio has solved that problem lol.
I would suggest deleting the solution files.

Snippets are clean!
Can you see the details of the OpenPublishing.Build action?

That worked, thank you!
I deleted some files after this run - was throwing errors after some unused snippets being removed here.
I can re-add all the necessary files to make it build, but if detecting unused snippets is automated it would delete files again in this specific case (type forwarding).
Alternatively, I could inline the code referred in the after regions of type forwarding.
What would be the preferred approach?

Considering how small those files are, and the code doesn't really demonstrate much, I would be fine with copying that code directly into the article.

Thanks for your help with this folks!


api v1 deprecated

shows error message:
"Deprecated, use /v2/countries"

Yes, just upgarde to latest version 1.2.4 and also change the method names as per this
npm i novelcovid --save


Implement power operator (to be open)

Motivation

This PR on the subject

Modifications

Write power() in Jpql, Expressions
Create a JpqlPowerSerializer
Write the respective test code

Commit Convention Rule

Please commit your modification based by conventional commit:

Commit type
Description

feat
New Feature

fix
Fix bug

docs
Documentation only changed

ci
Change CI configuration

refactor
Not a bug fix or add feature, just refactoring code

test
Add Test case or fix wrong test case

style
Only change the code style(ex. white-space, formatting)

chore
It refers to minor tasks such as library version upgrade, typo correction, etc.

If you want to add some more commit type please describe it on the Pull Request

Result

Now supports POWER.

Closes

#647

We see that there is missing test code.
I'll fill it in and post it.

um...
I don't know why that one line of missed code is there.

Because as you can see, when I run the test for that class, it definitely captures the debugger.
I guess I'll have to find out what the magic is...

um...
I don't know why that one line of missed code is there.

Because as you can see, when I run the test for that class, it definitely captures the debugger.
I guess I'll have to find out what the magic is...

You don't need to worry about this missing test code issue.

Thank you so much to everyone who reviewed my code! (I'm touched)
However, due to my work, I won't be able to implement them right away.
I've read everything you said, and I'll apply what I can to the PR after committing!
Thank you everyone! (especially waah)


Unable to use ChefDK as Your Primary Development Environment

Hi,
I'm using chefdk version 0.3.5, Installed from OS X dmg file. It worked before for previous version. I don't know why it is not now.
➜  cat .chefrc
eval "$(chef shell-init zsh)"
➜ source .chefrc
➜  knife ec2 server list
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/bundler-1.7.5/lib/bundler/rubygems_integration.rb:266:in block in replace_gem': can't activate chef-zero (= 2.2.1), already activated chef-zero-3.2. Make sure all dependencies are added to Gemfile. (Gem::LoadError)         from /opt/chefdk/bin/knife:4:in '
Please help. Thanks

Allow me to update more.
$ knife cookbook search --help
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/bundler-1.7.5/lib/bundler/rubygems_integration.rb:256:in block in replace_gem': chef-zero is not part of the bundle. Add it to Gemfile. (Gem::LoadError)         from /opt/chefdk/bin/knife:4:in '

Do you have something in your environment that could be invoking bundler automatically, like direnv or some shell alias? When I try to detect bundler integration, I don't see anything:
knife exec -E 'raise Exception' -VV
-E Argument:in `run': Exception (Exception)
	from /opt/chefdk/embedded/apps/chef/lib/chef/knife/exec.rb:51:in `instance_eval'
	from /opt/chefdk/embedded/apps/chef/lib/chef/knife/exec.rb:51:in `run'
	from /opt/chefdk/embedded/apps/chef/lib/chef/knife.rb:493:in `run_with_pretty_exceptions'
	from /opt/chefdk/embedded/apps/chef/lib/chef/knife.rb:174:in `run'
	from /opt/chefdk/embedded/apps/chef/lib/chef/application/knife.rb:139:in `run'
	from /opt/chefdk/embedded/apps/chef/bin/knife:25:in `<top (required)>'
	from /opt/chefdk/bin/knife:33:in `load'
	from /opt/chefdk/bin/knife:33:in `<main>'

I tried running with OS X dtruss (to be fair, dtruss hasn't worked well in the past but it seems to work better on Yosemite) and didn't see any exec happening, nor did I see any evidence of bundler getting invoked (I ran sudo -E dtruss -f knife exec -E 'raise Exception' -VV 2>&1 |less FWIW).

I tried to switch to bash instead of zsh.
Everything looks the same as yours. Thanks for your suggestions
There is sth wrong between ChefDK and zsh when I evaluating zsh, eval "$(chef shell-init zsh)"
With zsh, I always have to wrap the knife commands inside chef exec

I've been using zsh myself and not seeing this issues. Maybe you can try temporarily moving your ~/.zshrc (or maybe even system-wide invocation files, see man zsh for the list) out of the way and launching a new shell with the default config? If that changes the behavior, you probably need to audit your zsh config for anything that might be changing your environment. You can also run which knife, which ruby, etc. to see if these are implemented as shell aliases.

Yes, your suggestion is right. I moved out my zshrc. knife command works well.
I'm using oh-my-zsh plugins. I will investigate it. Thanks a ton.

Hi,
I suspected that 'bundler' plugin of oh-my-zsh was causing the problem. I haven't enough time to find out the root cause.
However, I found a remedy, added UNBUNDLED_COMMANDS=(kitchen knife). Knife and Kitchen should work normally :)


catalog-info: add links

Couple of links related to Backstage :grin:

Tugboat has finished building the preview for this pull request!
Link:

https://pr4497-buwun5yzaxvyci5me45hdaryn3ip7kcn.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/6025616bfcb22d512f531ee3


[lz4] Update to 1.10.0, use official CMake build system

Based on #40021, with ~a tentative~ an accepted change for https://github.com/lz4/lz4/issues/1179:
Keeping the lz4::lz4 target for CMake config package lz4, i.e. consistent capitalization.

lz4
All features are tested successfully in the following triplet:
x86-windows
x64-windows
x64-windows-static

Thanks @teo-tsirpanis and @dg0yt for the update!


why MultiTenantDbContext requires ITenantInfo not just current TenantId ?

could you please explain to me why does MultiTenantDbContext requires ITenantInfo when a string tenantId parameter or
interface ICurrentTenant
{
    string TenantId { get; set; }
}

seems to be enough?

Hi, two main reasons.

dependency injection: it needs to work with DI and injecting a string type wasn’t feasible until keyed services very recently
users may want to use more of the properties in their db context e.g. connection string

I actually will be changing it so they accept IMultiTenantContextAccesor (in addition to the current). You can of course make your own constructor that takes a string, creates a tenant info instance, and passes it to the base constructor for convenience. I will probably add that soon a convenience.

cheers. thank you buddy for this great tool. we started using MultiTenant recently and it sure saved us a lot of work. Now I am sure I am ignorant on many of the use cases others have, but imo requiring ITenantInfo as MultiTenantDbContext constructor argument invites confusion, and abuse.
For example the guys working on fullstackhero template have this snippet in their db context

when I think about it, this cannmot be correct, DbContextOptions should be enough to connect to the correct database. relying on the ITenantInfo.ConnectionString tells me there is either a misunderstanding on their side, or it's a work around of some sort. I couldn't figure that out yet.
Again I assume I am not seeing the full picture, and perhaps it's misunderstanding on my side. your thoughts are much appreciated.

Hi again,
DbContextOptions and their builder don't really follow the normal options pattern and when used with AddDbContext it isn't obvious how/if per-tenant options can be applied -- so in this case they wait and use the tenant details on OnConfiguring.
Also you forgot one possibility: I didn't design well and plan ahead when I started building this thing!

the possibilities are many. let's put them aside.
In my understanding (within web app context) services.AddMultiTenant<Tenant>().WithClaimsStrategy("tenant_claim_key") will somehow resolve the correct ITenantInfo for the tenant Id extracted from the user's tenant claim, and add it as scoped to the dependency container (given the user has a valid tenant id claim). we don't care how at the moment.
then, (again I am drawing the picture in my mind), we should use GetRequiredService<ITenantInfo>() in AddDbContext() in order to build the correct DbContextOptions that is used to build the tenant's DbContext.
do you agree, that this is the valid straight forward approach utilizing your library? I can image not all cases are straight forward.

You are correct but I have a PR coming soon that changes this.
Soon only IMultiTenantContextAccessor will be available straight from DI. I’m doing this to more closely match how HttpContext works. You’ll notice that is never injected because it is not a service, just like ITenantInfo isn’t.
I’ll have some convenience methods to get it but not straight via DI. Another problem it has with DI is that sometimes there is no current tenant so it is null which doesn’t play well with DI. The accessor is never null.
For db context specifically I’ll probably keep the current constructor but also add ones for just tenantId and an accessor. I am also planning to add factory method support which will work better in Blazor and some use cases when you need a dbcontext for a given tenant that might not be the current tenant.

I agree with yo that it is a best practice. There are some use cases where some entities make sense to not be multi tenant but part of the overall model. Right now a db context just throws exceptions on null tenant id. I want to add some smarter handling. Maybe it returns no results or maybe there is an option to have it return no results OR throw an exception during construction.

Also it’s on my list to look at using interceptors for the functionality or maybe events. Neither were an option back when I started.  That would make it easier to not have to inherit the Finbuckle context which is something not everyone can do.

Wait. To have multi-tenancy support in a DbContext inheriting from MultiTenantDbContext is not the only option? I need to revisit that part on the docs.

Yep, here is the section:
https://www.finbuckle.com/MultiTenant/Docs/v6.13.1/EFCore#adding-multitenant-functionality-to-an-existing-dbcontext


package_version doesn't install the specified version

Cookbook version
6.0.0
Chef-client version
12.18.31
Platform Details
ubuntu 14 & 16
Scenario:
Trying to install a specific version in Ubuntu
Steps to Reproduce:

create a dummy cookbook and only use ubuntu 16 as the platform
create a attribute file and add the line default['git']['package_version'] = '2.11.0'
add git cookbook as a dependency and add include_recipe 'git' in the default recipe
converge in vagrant
login and run git --version

Expected Result:
2.11.0
Actual Result:
2.7.4
Comment
I've skimmed through the code and package_version is defined in the resource but it's never been passed a value. Is this the intended behaviour or is this just some outdated feature from 2 years ago?
https://github.com/chef-cookbooks/git/blame/master/README.md#L92

The attributenode['git']['package_version'] = '2.11.0' isn't used by the default recipe - if you want to choose a version that isn't latest, use the resource directly as below
git_client 'default' do
  package_version '2.11.0'
  action :install
end

well, that won't work and here's what i get if i try that.

the default version in the Ubuntu repository is always a little old and almost never seems to be updated until the next major OS release.
in order to get the latest version of git, either you have to build it from source and install from a ppa.


Integration test

Following completion of both the partner and super admin flows, write a Cypress test that encompasses both flows.
Might need to consider a separate Cypress job to run this test in order to turn the environment variable on.

QA Notes
There is no QA needed from product/design here, it can be closed after merge.


Replace config.execution.fmriprep_dir uses in BIDSURI calls with output_dir parameter

What would you like to see added in fMRIPrep?
All of the workflows in fMRIPrep that currently use BIDSURI to track sources currently rely on config.execution.fmriprep_dir for the output directory, and yet all of those functions have an output_dir parameter.
It would be easier for other preps that use fMRIPrep as a dependency (i.e., ASLPrep) if we used output_dir instead of the config object's package-specific fmriprep_dir field.
Do you have any interest in helping implement the feature?
Yes
Additional information / screenshots
I think I completely overlooked the output_dir parameter when I started implementing BIDSURI-based source tracking (#3255, #3262, #3263, #3297) because I originally wanted to reference the config object directly within the BIDSURI interface, which ended up not working.

Sounds good to me.


Performance issue / holding reference to binaries

Hi,
A Phoenix app I am working on is experiencing binaries related memory leak.
It is related to Quantum triggered jobs, but after some investigation found that it is actually open telemetry related process that holds on to those binaries. Not sure if this is a Quantum or Telemetry issue though (or our usage!).
Binaries memory leak with quantum and (open)telemetry contains all the details.
Any ideas on what might be the cause?

@elvanja Hm. I would say that this is an unexpected behavior of telemetry / telemetry-related libraries.
Could you open an issue there and link back to this?

Yep, already done that. See https://github.com/open-telemetry/opentelemetry-erlang/issues/459. Likely it is entirely at telemetry side of things. Apologies for not adding a note sooner 😄

@elvanja No worries, thank you :)
I'll leave this issue open for other people until it has been resolved.

Update: this seems to be resolved by switching protocol to :http_protobuf. The :grpc flow still has issues, but at least there is a workaround. And, it definitely is related to open telemetry, not quantum.