SVG Display issue on IOS

TO REPRODUCE THE ISSUE, FOLLOW THESE STEPS:
I am serving SVG files from a node server. We are linking these svg files in the scene file by creating textures then applying the texture to a style and then applying the style to a layer. Example below:
"textures": {
"f3f58b56-e562-46c4-96d1-bda0531a20f5": {
"url": "http://localhost:3000/markers/8dd593/circle-11.svg",
"filtering": "linear"
}, ...
"styles": {
"f3f58b56-e562-46c4-96d1-bda0531a20f5": {
"base": "points",
"texture": "f3f58b56-e562-46c4-96d1-bda0531a20f5"
},...
"layers": {
"f3f58b56-e562-46c4-96d1-bda0531a20f5": {
"data": {
"source": "location_source",
"layer": "locations"
},
"visible": true,
"draw": {
"points": {
"style": "f3f58b56-e562-46c4-96d1-bda0531a20f5",
"interactive": true,
"collide": false
}
}
},...
The svg file accessed at the url is as follows:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 15 15" height="15" width="15"><title>circle-11.svg</title><rect fill="none" x="0" y="0" width="15" height="15"></rect><path fill="#000" transform="translate(2 2)" d="M10,5.5C10,7.9853,7.9853,10,5.5,10S1,7.9853,1,5.5S3.0147,1,5.5,1S10,3.0147,10,5.5z"></path></svg>
We are using the svg icon set available here. https://www.mapbox.com/maki-icons/
RESULT:
The svg shows as expected as the map point symbol within our tangram map on the latest Chrome web browser (Version 55.0.2883.95 (64-bit)) on desktop devices. Unfortunately, when accessing the map on an IOS device iPhone or IPad using IOS safari (latest) the point style only shows as a black square.
EXPECTED RESULT:
Since the point symbol is being properly rendered on the desktop map we believe that our configuration is correct. We would expect that the display on IOS Safari would be the same.
ENVIRONMENT:
We are using tangram js v0.11.7.
OTHER:
I wanted to say that this is a great library and we really appreciate your making it available to the community.
If there is any guidance you can provide to help us understand how to resolve this issue or if there are any thoughts about how tangram is consuming the. svg and displaying it that would allow us to continue our research on a solution it would be greatly appreciated.

Hi, thanks for the details. Tangram simply treats SVGs as any other image file, which is to say the URL is set on an internal Image object/element, which is then fed to WebGL as a texture. So the responsibility for any SVG parsing is the browser's. That said, I've occasionally seen oddities in this image -> texture loading process across browsers.
I made a quick test that does appear to work for me both on desktop Chrome and iOS mobile  Safari. Can you give it a try and let me know if it works for you too (you should see red star icons):
http://bit.ly/2jSPBp5
This may help to narrow whether it is an environment or resource-related issue.

Thank you for the example. It is producing the desired result and we can see the svg symbol on IOS. This helps us understand that it is most likely an issue within our environment.

The issue is in the SVG. The fill property on "none" reverts the svg to black which is its initial value.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 15 15" height="15" width="15"><title>circle-11.svg</title><rect fill="none" x="0" y="0" width="15" height="15"></rect><path fill="#000" transform="translate(2 2)" d="M10,5.5C10,7.9853,7.9853,10,5.5,10S1,7.9853,1,5.5S3.0147,1,5.5,1S10,3.0147,10,5.5z"></path></svg>
When the fill property is set to transparent it works as expected.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 15 15" height="15" width="15"><title>circle-11.svg</title><rect fill="transparent" x="0" y="0" width="15" height="15"></rect><path fill="#000" transform="translate(2 2)" d="M10,5.5C10,7.9853,7.9853,10,5.5,10S1,7.9853,1,5.5S3.0147,1,5.5,1S10,3.0147,10,5.5z"></path></svg>
Curious as the the svg fill property of "none" is per the specifications  and when using the same svg outside of the map it renders correctly on the IOS devices (below).
<span class="map-marker" data-marker-name="circle-11">
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 15 15" height="15" width="15"><title>circle-11.svg</title><rect fill="none" x="0" y="0" width="15" height="15"></rect><path fill="#000" transform="translate(2 2)" d="M10,5.5C10,7.9853,7.9853,10,5.5,10S1,7.9853,1,5.5S3.0147,1,5.5,1S10,3.0147,10,5.5z"></path></svg>
</span>

Interesting, although I haven't yet been able to reproduce this issue in Tangram. Here's an example I made using the original SVG (with fill="none") you provided above. It's working for me on both desktop and iOS. Can you give it a try?
https://mapzen.com/tangram/view/?scene=https%3A%2F%2Fmapzen.com%2Fapi%2Fscenes%2F4%2F140%2Fresources%2Fscene.yaml#12.9175/40.6750/-73.9953
Side note, the SVG here is actually inlined in the Tangram scene file using a data URL:
texture: data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 15 15" height="15" width="15"><title>circle-11.svg</title><rect fill="none" x="0" y="0" width="15" height="15"></rect><path fill="#000" transform="translate(2 2)" d="M10,5.5C10,7.9853,7.9853,10,5.5,10S1,7.9853,1,5.5S3.0147,1,5.5,1S10,3.0147,10,5.5z"></path></svg>
If you're curious, the whole scene is here.

I like this approach and did not realize it is available. I will test it out and let you know what we find.

Yeah it's not obvious at first, but as long as it's a valid URL that an <img> tag will render, it should work :)

All is good with this approach. Thanks for the assistance!

Great! Still not clear what caused your original issue, let us know if it happens again.


Inconsistent extraction of Prims.int (should extract to bigint)

The tutorial mentions that we have "A well-founded partial order on all terms". What exactly is this order on integers? I'm completely sick of our equivocation about the nature of integers. This is just wrong and undermines the credibility of what we're doing!

We now have lib/int32.fst and examples/unit-tests/testint32.fst. The Int32 library soundly models integer overflow semantics. The Prims.int type is for mathematical integers. We will eventually compile programs using it to use bigint.

We also ran into this problem in contrib/Platform/fst/Bytes.fst and when compiling examples/crypto/rpc.fst. See also https://github.com/FStarLang/FStar/issues/314 .
The following function in Bytes.fst demonstrates the problem nicely:
val repr_bytes : nat -> Tot nat
 let repr_bytes n =
     if n < 256 then 1
     else if n < 65536 then 2
-    else if n < 16777216 then 3
+    (*else if n < 16777216 then 3
     else if n <<PHONE_NUMBER> then 4
     else if n <<PHONE_NUMBER>776 then 5
     else if n <<PHONE_NUMBER>10656 then 6
-    else if n <<PHONE_NUMBER>7927936 then 7
+    else if n <<PHONE_NUMBER>7927936 then 7    *)
     else 8

Should it have a refinement that restricts it to nat's representable as 8 bytes?
We need 64 bit integers to verify sequence numbers in the TLS record layer
Extraction of RPC currently works only if constants are small. the + patch/hack.

Just to document that we rolled back to an assumed repr_bytes, with a partial specification for integers up to 2^64-1.
I'm curious about what's a good solution for writing a logical function that uses literals that overflow OCaml integers, so that it is erased during extraction and doesn't break code generation.

Such functions would be either GTot functions or produce an erased result.
Both should be erased at extraction. If you are only using the function in specifications, GTot is nice because it is transparent, you do not have to handle hide and reveal everywhere.

What I meant is that a definition like let f: unit -> GTot int = fun () -><PHONE_NUMBER> will get extracted and fail (on Windows) because the literal is too large, while let f: unit -> GTot int = fun () -><PHONE_NUMBER> would extract fine.

We've had several proposals for addressing this, but we haven't really converged on a solution.
The simplest approach, I think, is to just translate int to BigInt/System.Numerics.BigInteger for OCaml/F#.
This means that if you're using int, you should be aware that you'll be paying the cost of bigints.

That sounds very reasonable. I think that's the expectation because int is translated to Z3 as the type of mathematical integers.

Regarding functions with GTot effect, like let f: unit -> GTot int = fun () -><PHONE_NUMBER> above, I expected them to be erased during extraction anyways. Why are they extracted at all?

Just to recap, so we should implement int using BigInt/System.Numerics.BigInteger for OCaml/F#.
What about not extracting GTot functions?

Fixed using ZARITH


[Visual Editor] SetProperties does not correctly display object types

What's our expected appearance of an object?
To show its full value or just tell user it's an Object [Object]?

@sangwoohaan do you have guidance here? It's possible for users to add values that are objects with any types in them and arrays with any types in them.
ex:
{
  "user": { "address": { "city": "Bellevue" } },
  "places": [{ "name": "Office" }, { "name": "Home" }]
}

If values are objects or arrays they should display the actual values, but truncate if it doesn't fit in one line.

Something like this

addressed in #2335


Upgrade org.codehaus.mojo:tidy-maven-plugin 1.1.0 -> 1.2.0

This PR contains the following updates:

Package
Type
Update
Change

org.codehaus.mojo:tidy-maven-plugin (source)
build
minor
1.1.0 -> 1.2.0

[ ] If you want to rebase/retry this PR, check this box

Suggested commit message:
Upgrade tidy-maven-plugin 1.1.0 -> 1.2.0

See:
- https://github.com/mojohaus/tidy-maven-plugin/releases/tag/tidy-maven-plugin-1.2.0
- https://github.com/mojohaus/tidy-maven-plugin/compare/tidy-maven-plugin-1.1.0...tidy-maven-plugin-1.2.0

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.


Support for XLSR-53

Hi, thanks for the nice work!
I am just wondering if there's any plan on supporting XLSR-53, the multilingual pre-trained wav2vec 2.0 model?
Thank you!

Hi,
Thanks!
Yes this will be supported soon, hopefully one or two days later.

Hi, sorry for the late.
I am adding this now.

Hi,
You can now use -u wav2vec2_xlsr` to use the multilingual version.
Thanks for your patient!


spawning crystal process leads to out of memory

hello.
Running crystal code spawns a lot of crystal processes which looks like fork bomb and within few second I'm out of RAM. I didn't have time to try to troubleshoot nor analyze crystalruby code.
spawned more than 40 processes (ps -ax | grep crystal):
crystal build --single-module --link-flags -shared -o <local path>/crystalruby/crystalruby/lib/crystalruby_2740b21ad0d3ecda509d3b50bda329dc <local path>/crystalruby/crystalruby/src/crystalruby.cr

after exiting ruby process and killing crystal processes ruby stack:
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/compilation.rb:17:in `compile!'
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/library.rb:157:in `block in build!'
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/library.rb:150:in `synchronize'
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/library.rb:150:in `build!'
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/function.rb:34:in `block (2 levels) in define_crystalized_methods!'
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/function.rb:35:in `block (2 levels) in define_crystalized_methods!'
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/function.rb:35:in `block (2 levels) in define_crystalized_methods!'
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/function.rb:35:in `block (2 levels) in define_crystalized_methods!'
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/function.rb:35:in `block (2 levels) in define_crystalized_methods!'
        from /home/olek/.rvm/gems/ruby-3.1.2/gems/crystalruby-0.2.0/lib/crystalruby/function.rb:35:in `block (2 levels) in define_crystalized_methods!'
...

sample code which leads to error:
require 'crystalruby'

module MyTestModule
  # The below method will be replaced by a compiled Crystal version
  # linked using FFI.
  crystalize [a: :int, b: :int] => :int
  def add(a, b)
    a + b
  end
end

# This method is run in Crystal, not Ruby!
MyTestModule.add(1, 2) # => 3

Used on ruby 3.3 and 3.1.2, crystal 1.12.1 on gnu/debian.

Thank you for your report @akwiatkowski, I was able to reproduce the behaviour on a system running Debian 12, and have pushed version 0.2.3 which appears to address the issue (seems mishandling of compilation process output was causing the Ruby code to progress prematurely before the compiled assets were ready, causing infinite recursion).
https://github.com/wouterken/crystalruby/releases/tag/0.2.3
Please feel free to report back with more information if the issue still persists for you.


Setting "Critical Damage Maximize Dice" maximizes crit dice instead of base dice

Causes issues with Brutal critical, since the additional dice are always maximized.

It seems to be only multiplying the base dice for me:

This is what it looks like for me.
With these options on:

And if you disable whatever rolling module you are using, does it work as expected. It looks like that might be a module issue not a 5e issue.


Using two Hue bridges error

Describe the bug
My first hue bridge was completely full so I tried to add a second one (both v2) to shift some load to it. After installing the bridge via Hue App and adding some lights and scenes to it I added it to Huemagic without a problem. When I try to discover lights or scenes via light or scene node i get the error "Something went wrong. Please retry" (see error log). Using the bridge directly with Home Assistant or official Hue App works fine.
If I remove the new bridge, then everything works again without any problems.
Error Log:
...
24 Jan 22:42:16 - [red] Uncaught Exception:
24 Jan 22:42:16 - [error] TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'TLSSocket'
    |     property '_httpMessage' -> object with constructor 'ClientRequest'
    --- property 'socket' closes the circle
    at JSON.stringify (<anonymous>)
    at /config/node-red/node_modules/node-red-contrib-huemagic/huemagic/hue-bridge-config.js:807:31
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
2022/01/24 22:42:16 [error] 544#544: *1213 upstream prematurely closed connection while reading response header from upstream, client: <IP_ADDRESS>, server: a0d7b954-nodered, request: "GET /hue/resources?bridge=<IP_ADDRESS>&key=[myApiKeyWasHere]&type=scene HTTP/1.1", upstream: "http://<IP_ADDRESS>:46836/hue/resources?bridge=<IP_ADDRESS>&key=[myApiKeyWasHere]&type=scene", host: "<IP_ADDRESS>:1880", referrer: "http://<IP_ADDRESS>:1880/"
...

Please complete the following information:

Node-RED version: 10.3.4
NodeJS version: 16.13.2-r0
Device running Node-RED: Home Assistant / hassio
Hue Bridge(BSB002): 1.49.1949107040

I have not changed anything but since yesterday works.

I like those kind of issues 😄


Lighthouse Audit fails for PWA if start_url contains any url parameters

Version
3.0.0-rc.3
Reproduction link
https://github.com/vesper8/vue-cli-3-pwa-failed-service-worker
Steps to reproduce
*1-create a brand new app from vue-cli RC3
*2-npm run build
*3-serve the dist folder with web server
*4-visit the Lighthouse Audit from chrome debugger
*5-notice the manifest's Start URL is /index.html
*6-run audit (PWA section only)
*7-see perfect 100 score
then
edit the manifest.json, change start_url from /index.html to /index.html?utm_source=landing&launcher=true repeats steps 2-6 above notice the score is now 91 and there's a failure from the service worker to serve the start_url
bonus: visit the start url from the manifest.json and notice that it loads just fine with the url parameters
What is expected?
you should be able to use url parameters as part of the start_url, specially since a lot of tutorials recommend doing just that for analytics purposes
What is actually happening?
service-worker fails to serve start_url which means that the "Add to homescreen" won't appear as a result

This has nothing to do with Vue CLI.


Problem on installing integrations in zsh

Hello,
I had a problem when running any variant of pip install integrations with zsh:
pip install imgui[pygame]
zsh: no matches found: imgui[pygame]

With good old bash is working fine. For zsh, you need to escape the brackets:
pip install imgui\[pygame\]

Was a bit tricky to find this, so I tough about sharing.

This issue is not related to this project but to interaction between pip and zsh. Note you can also use quoting in place of escaping:
pip install "imgui[pygame]"


NTR: ciliary vesicle

@JohnvanDam @krchristie
(John is away at the moment, but I’ll open this ticket now anyway as I’m looking at this term.)
John suggested to add the following CC term (initial communication was done by email on 27/7/16, so copying here):
+[Term]
+id: ID:0000012
+name: ciliary vesicle
+namespace: cellular_component
+def: "A Golgi derived vesicle to which the ciliary basal body docks via its transitional fibers. The membrane composition is distinct and will become the ciliary membrane once it is fused to the plasma membrane. The ciliary vesicle is thought to be formed by multiple smaller vesicles that attach to the transitional fibers and then fuse to form a larger vesicle." []
+synonym: "primary vesicle" EXACT []
+xref: PMID:13978319
+xref: PMID:25805133
+is_a: GO:0097708 ! intracellular vesicle
+created_by: jvandam
+creation_date: 2016-07-18T11:51:26Z
The formation/assembly term will then be added for this CC. This is all relevant for the cilium assembly BP branch.
I agree, and suggest to add the CC term as follows (i.e. with a few changes in definition, synonyms and parentage):
+name: ciliary vesicle
+namespace: cellular_component
+def: "A Golgi-derived vesicle to which the ciliary basal body docks via its transitional fibers. Its membrane is compositionally distinct from Golgi membranes, and will become the ciliary membrane once the ciliary vesicle is fused to the plasma membrane. The ciliary vesicle is thought to be formed by multiple smaller vesicles that attach to the transitional fibers and then fuse to form a larger vesicle." [GOC:cilia, PMID:13978319, PMID:25686250]
+synonym: “CV” RELATED [PMID:2568625]
+synonym: "primary ciliary vesicle" EXACT [PMID:20427320]
+is_a: GO:0031410 ! cytoplasmic vesicle
(Note for self: NOT is_a GO:0016023 ! cytoplasmic, membrane-bounded vesicle because... see https://github.com/geneontology/go-ontology/issues/11504, my comment from March 29)
John, Karen, please double-check for correctness. Also, a question for you: PMID:20427320 suggests that ‘ciliary vesicle’ should be related to the existing term GO:0020016 ‘ciliary pocket’ (“Invagination of the plasma membrane from which a cilium (also called flagellum) protrudes.”). Is this correct and if yes, how should we accomplish this?
Note for self:
When working on the ‘cilium assembly’ branch, consider adding the link ‘cilium assembly’ starts_with ‘ciliary vesicle formation/assembly’? (See e.g. PMID:25686250 “Membrane association with mother centriole (M-centriole) distal appendages is critical for ciliogenesis initiation”.)

In terms of taxon constraints for 'ciliary vesicle' and associated BP terms, John also wrote:
"I've also added one more CC term "ciliary vesicle" because while reading I found out that, even though it is often neglected in literature, basal body docking is preceded by docking to a specialized vesicle, which will then fuse to the plasma membrane. The vesicle functions as a pre-made ciliary membrane. (...) it is pretty difficult to find out how common this process is in other organisms. I've been able to track some components back to the jawed vertebrates, but I do not know how or if this process occurs in lower animals as well, or non-animals for that matter. I am pretty sure it does not occur in Chlamydomonas and Giardia species, but I could not find any references that actually say so."
In the absence of references, I'd lean towards not applying taxon restrictions. We can always revise if/when published evidences can be provided.

I've come across the "ciliary vesicle" in mouse literature, but I haven't focused on it and don't have anything to add to this discussion at the moment. Your current proposal sounds fine to me.
-Karen

Thanks @krchristie !

The term as you defined it looks excellent Paola. On the relationship with the ciliary pocket, the Sorokin paper has some very nice EM pictures showing all the stages of vesicle-BB docking and subsequent merging with the plasma membrane (1). The ciliary pocket is formed by first extending the axoneme into the vesicle forming some sort of "vesicle cap". This is then followed by the membrane fusion event, and so creating the ciliary pocket. So, indeed, the CV and pocket are related to each other as some of the membrane that lines the ciliary pocket initially is derived from the vesicle. Though I suspect that the pocket membrane composition will rapidly change due to mixing with plasma membrane. I do not know how to capture this in GO other than via the definition of both terms in CC or via biological processes.

Check figures 11 through 17 in the Sorokin paper at http://jcb.rupress.org/content/15/2/363.long page 369

Hi Paola,
Excellent! I wonder to which extent (or if) we should limit the biological process taxonomically (is that a word?). I've only found references to vesicle docking and ciliary pockets in mammalian systems. I am not sure if it occurs in Chlamy and protists for instance.

Hi @JohnvanDam,
I think the best course of action would be

[ ] Once the revised GO ‘cilium assembly’ branch is in place, we should ask Karen to check with her colleague from the Chlamydomonas community to please take a look and let us know if we should restrict any terms beneath ‘cilium assembly’ to specific taxonomic groups. Currently, ‘cilium assembly’ is labelled as occurring only in eukaryotes but never in Ascomycetes; we could certainly add more constraints if needed, to it and/or to any of its children. I’ll move this note to the appropriate GH ticket too.

Added
[Term]
+id: GO:0097721
+name: ciliary vesicle
+namespace: cellular_component
+def: "A Golgi-derived vesicle to which the ciliary basal body docks via its transitional fibers. Its membrane is compositionally distinct from Golgi membranes, and will become the ciliary membrane once the ciliary vesicle is fused to the plasma membrane. The ciliary vesicle is thought to be formed by multiple smaller vesicles that attach to the transitional fibers and then fuse to form a larger vesicle." [GOC:cilia, PMID:13978319, PMID:25686250]
+synonym: "CV" RELATED [PMID:2568625]
+synonym: "primary ciliary vesicle" EXACT [PMID:20427320]
+is_a: GO:0031410 ! cytoplasmic vesicle


Please add me to the Kivy Garden

Hi, I wrote this new widget which I think might be a good candidate for the kivy garden :)
https://github.com/antocuni/garden.xcamera

@antocuni, thanks a lot for your work, please transfer the repo to me and i'll pass it to garden.

It was moved to https://github.com/kivy-garden/garden.xcamera and you should have write access to it. :dancer:


Replacing hiveadmission daemonset to deployment

--> Replaces the hiveadmission daemonset with a deployment (replication = 2)
--> Removes the daemonset from the clusters that might already have it. Needs to be removed once it is run in opshive

/lgtm
/ok-to-test

/test e2e

/lgtm


Kong with Bitnami OIDC

I want an images with bitnami/kong:3.3.0 comibine with oidc?? could you help me??

You can try forking this repo, replacing the imagine in Dockerfile with the one from bitnami, docker build and run it to see what happens :)


What are the plans for Hubot?

Hi. I was just wondering if there are any plans for continuing Hubot or not?

My guess is "no", can any Hubot dev confirm? @mistydemeo

I emailed this to<EMAIL_ADDRESS>the contact email displayed at https://github.com/hubotio, May 6 2021. I will update if I hear back - I should have linked to this issue.
Hi there
A commonly used Hubot package (hubot-redis-brain) has recently started
failing npm audit checks due to a dependency that needs updating.
There hasn't been any update from the Hubot team in a long time, and I
believe Github's focus is now on the Probot / Botkit interfaces. There
is still a community of Hubot usage though, and I'm interested if you
have any plans you can share for how this community might proceed?
Would Github consider handing the reins over? I don't want ownership
myself, but I do want to see Github support a process to move towards
community ownership if that's plausible.
Thanks
Chris
cc @technicalpickles @mistydemeo - are you able to give any guidance / contact which would support some kind of community organisation here?

I'm afraid I no longer work at GitHub, so while I'm still a Hubot maintainer I'm not able to drive the conversation from that perspective.

Thanks for the reply! It might be fine to have any active maintainer, if there are ways we can support you in the issue queue etc. Is the project still on your radar sufficiently that this would be helpful? How could some kind of community support work best for you (and/or other @hubotio maintainers)?

Is there another possibility then forking this repo in order to keep this alive?
I e.g. see lots of hello world issues by users already deleted and PRs to bump versions etc. I guess if some of the users could get the permissions to at least triage issues this could get a few updates. Or is there a predecessor which should be used instead of hubot?

@dominik-ba I'm interested in ensuring Hubot gets at least the maintenance to continue operation. Simply unblocking version bump PRs would be a step in the right direction. Like you I'd prefer to avoid forking the project if there's some way to build on what exists.

Howdy folks! It's really cool to see so much community interest still in Hubot. I used to use Hubot a lot as well, and I worked on the docs site a bit many years ago, and I still think of Hubot as one of the simplest ways to spin up a basic bot for chatops.
Also FWIW, as a former GitHub staffer I'm assuming that it is not likely for GitHub to release maintainership of Hubot anytime in the immediate future, if for no other reason then because there are still probably a number of apps and deployment processes running at GH on this repo (speculating a bit here, so I could be wrong about this).
So it may be worth seriously considering the fork option if you'd like to drive Hubot into the future (could even call it hubot-future or hubot-next. 😉 ).
The other option, of course, is to get on Twitter and get lots of folks to ask new(ish) GitHub CEO Thomas Dohmke to release this project to the community! (That used to work pretty well with Nat Friedman, I hear 😄). Again, my hunch is this approach is probably a long shot, but still might be worth a try.

There: I tweeted with a request for a response. Feel free to add your comments to the thread, or tweet Thomas in your own thread!

I think you're right, and it's fine for Github not to pass on stewardship of Hubot - that's a big ask tbh.
Feels like there's room for a community fork here, a nice thing about which is a fork doesn't borrow from some parts (PRs) and not others (what's with all the hello-world issues?). & in hubotio/evolution the project even comes with a (school-age, free to ignore) roadmap, which is a rare feature in unmaintained projects 😆
My brain parses hubot-future (hubot-dash-thing) as "a Hubot plugin that provides Future functionality" which is going to get confusing. nubot? yubot? Are we picking a name here?

Forking sounds like the right next step. I'm new here, so a bit clueless on how to create a fork (not git clone, but the social aspect of it) of an open sourced project and bring the community along. Any recommendations?

I love Hubot and have been using it since the Hipchat days. Later when the world moved to Slack I brought the Hubots along.  Slack has written a kind of tutorial to migrate Hubot apps to Bolt, but it seems nobody's published a complete example of a Slack bot running Bolt for JavaScript with clear examples.
Since Hubot seems to have been abandoned...anyone have a good standalone example of a basic Bolt app that has all the main features of Hubot?

Just to clarify, I'm still using Hubot. I forked it and have been updating it.

@joeyguerra i'm Just Some Guy, so take my suggestions with several grains of salt, but I'd say next steps would be:

rename your fork so that
a. it's obvious that development has moved elsewhere
b. you can create a new organization for it and not have the name conflict with this org
reach out to all the people listed as devs on this repo and invite them to contribute to your new fork
reach out to anyone who as committed to their own fork in the last ...18 months? and invite them to submit PRs to your fork
announce the fork on various platforms (eg HN, maybe some Reddit communities)

I'm on board to help out with this kind of administrative work (i have next to 0 modern JS experience, so that's all I can contribute)

@joh6nn this plan is actually quite helpful. Thank you.

@joeyguerra if you're keen to take it forward - I'd be much more confident if the changes on your fork had clear intent, eg by taking the changes as they are and reworking them into MRs for each feature or bug fix applied.
If it's time to create a new org, we can do that by lifting and reviewing the changes into that new location. You've clearly done lots of work, and this process would document that.
I realize this is extra labor which you don't owe anyone, but it might really help viability of the fork going forward, which I'm enthusiastic about. Are you up for that?

Yes. I think that’s the right approach as well. To clarify:

new org
Fresh fork into new org
MRs for to collaborate on changes

Any ideas on the new org name? Naming is hard.

Btw, #hubot on the fediverse.

Let's just call the new org "hubot-new" or something, and make an issue for naming over there. Github organisations can be renamed (right?), so we can defer that and deal with it later IMO.
That also gives us something for the new roadmap.

Ok. I intend to create an org called hubot-new, add you to it, and fork the repo today.

Here's the new org/repo https://github.com/hubot-new/hubot-b

@levenleven since you recently merged to this project after a long period of no updates or response from Github, I am pinging you into this discussion to make sure you're aware of plans to explore continuing Hubot support in the new organisation linked above.
I think Hubot users would love to see Github's engagement, and we're also prepared to put some work in ourselves. If Github has plans, now is a great time to clarify them :)

Update: In touch with @technicalpickles to review, merge #1581, and create a new release.

@joeyguerra reached out over email, and we've been discussing what to do there w/ @xurizaemon and @joh6nn
They have been working over in https://github.com/hubot-new/hubot to merge PRs, update dependencies and etc. After reviewing, I didn't see any reason to not just add them as maintainers, and get that work merged here before it diverges.
Since then, @joeyguerra started https://github.com/hubotio/hubot/pull/1581 with all the changes, and we've tested, and I just merged it earlier today. I (manually) cut a release of v3.4.0 (because Travis wasn't working, and not all the commits followed semantic-release).
I've also added those 3 as maintainers. There is some followup to do post merging that, but I can make issues for tracking them.
While there isn't a plan per se, there is work being done. Is that enough to close this? Perhaps.

I think so. I was also thinking that we could continue "the future of Hubot" discussion in a new issue or in a PR with a ROADMAP.md file. Or continue discussions in the evolution repo.

I intend to the close this issue. I'll wait a few minutes :)


MLPerf - Inference Reference Implementations

When will the reference implementations for the inference of the model be added?

Okay Thanks

please check the lates code under v0.5 dir.


error in Java grammar

public enum Problem {
	A_IS_FOR_AARDVARKS, //
	B_IS_FOR_BANANAS, //
	C_IS_FOR_CEPHALOPDS, //
	D_IS_FOR_DOCTORS, //
	;

}

(See JLS-8.9.1 and
JLS-14.20.3)

fixed by<PHONE_NUMBER>a8795ac0b4c017c0388841c823d6db


Using GLES2, the theme cannot be changed.

Using GLES2 I can't add a theme, the editor can't be displayed, in general I can't modify the default theme.... godot closes spontaneously when I try to enter the theme editor.

Same problem, when you want to add a new theme or simply want to edit the default theme, Godot stops working.


Swagger API

Is there a way to have angular-formly generate forms using swagger.  It generates a JSON with detailed descriptions of a REST API.
For example here is swagger-ui interfacing with the swagger JSON file:
http://petstore.swagger.io/
Here is the exact JSON that is used to display the above interface:
http://petstore.swagger.io/v2/swagger.json
As you can see the JSON is very well defined and contains the information to generate forms.
Please consider adding the feature to angular-formly.
Thanks

Hi @delaman, we actually use swagger at @alianza-dev as well. It's way cool. However, we don't generate forms based on it.
I don't think that this belongs in angular-formly core. This would go very nicely as a formly-js library though. All that you would need is a function that converts the JSON from swagger into properly formatted fields. You could look at this example of how I did this to help upgrade people from 2.0.0 to 3.0.0 or modify the code of this tool to make it work and turn it into a library. It should hopefully be fairly trivial.
However, as I said, this is not something that belongs in angular-formly core. If you're interested, I could create a repo in the formly-js organization and give you commit access so you could build and open source such a tool. Let me know.

@kentcdodds Looks like angular-formly uses ES6 via babel in parts of the library.  If I can use babel so that I can use ES6 stuff i'll do angular-formly swagger library.
Thanks

You're right, but you don't have to use ES6 if you don't want to. However
you want to code. Formly supports ES5.

Kent C. Dodds

(Sent from my mobile device, please forgive typos or brevity)
On Feb 28, 2015 11:48 AM, "Pedro de la Cruz Jr."<EMAIL_ADDRESS>wrote:

@kentcdodds https://github.com/kentcdodds Looks like angular-formly
uses ES6 via babel in parts of the library. If I can use babel so that I
can use ES6 stuff i'll do angular-formly swagger library.
Thanks
—
Reply to this email directly or view it on GitHub
https://github.com/formly-js/angular-formly/issues/190#issuecomment-76539581
.

@delaman, I don't think this is something that I'm going to work on. Are you planning on doing anything with it? If so, I'll leave it open. Otherwise I think I'll close it.

No activity for almost two weeks, so I'll go ahead and close this. Please reopen it if you have further needs.


NSH portiability warnings

Quite recently, building NSH provides me with the following warnings:
nshlib/nsh_proccmds.c: In function ‘ps_callback’:
nshlib/nsh_proccmds.c:357:1: warning: embedding a directive within macro arguments is not portable
  357 | #ifdef CONFIG_SMP
      | ^
nshlib/nsh_proccmds.c:359:1: warning: embedding a directive within macro arguments is not portable
  359 | #endif
      | ^
nshlib/nsh_proccmds.c:363:1: warning: embedding a directive within macro arguments is not portable
  363 | #ifdef CONFIG_SMP
      | ^
nshlib/nsh_proccmds.c:365:1: warning: embedding a directive within macro arguments is not portable
  365 | #endif
      | ^
nshlib/nsh_proccmds.c:532:1: warning: embedding a directive within macro arguments is not portable
  532 | #ifdef PS_SHOW_HEAPSIZE
      | ^
nshlib/nsh_proccmds.c:534:1: warning: embedding a directive within macro arguments is not portable
  534 | #endif
      | ^
nshlib/nsh_proccmds.c:535:1: warning: embedding a directive within macro arguments is not portable
  535 | #ifdef PS_SHOW_STACKSIZE
      | ^
nshlib/nsh_proccmds.c:537:1: warning: embedding a directive within macro arguments is not portable
  537 | #endif
      | ^
nshlib/nsh_proccmds.c:538:1: warning: embedding a directive within macro arguments is not portable
  538 | #ifdef PS_SHOW_STACKUSAGE
      | ^
nshlib/nsh_proccmds.c:541:1: warning: embedding a directive within macro arguments is not portable
  541 | #endif
      | ^
nshlib/nsh_proccmds.c:542:1: warning: embedding a directive within macro arguments is not portable
  542 | #ifdef NSH_HAVE_CPULOAD
      | ^
nshlib/nsh_proccmds.c:544:1: warning: embedding a directive within macro arguments is not portable
  544 | #endif
      | ^
nshlib/nsh_proccmds.c:545:1: warning: embedding a directive within macro arguments is not portable
  545 | #if CONFIG_MM_BACKTRACE >= 0 && !defined(CONFIG_NSH_DISABLE_PSHEAPUSAGE)
      | ^
nshlib/nsh_proccmds.c:547:1: warning: embedding a directive within macro arguments is not portable
  547 | #endif
      | ^
nshlib/nsh_proccmds.c:548:1: warning: embedding a directive within macro arguments is not portable
  548 | #if !defined(CONFIG_NSH_DISABLE_PSSTACKUSAGE)
      | ^
nshlib/nsh_proccmds.c:550:1: warning: embedding a directive within macro arguments is not portable
  550 | #endif
      | ^
nshlib/nsh_proccmds.c:551:1: warning: embedding a directive within macro arguments is not portable
  551 | #ifdef PS_SHOW_STACKUSAGE
      | ^
nshlib/nsh_proccmds.c:556:1: warning: embedding a directive within macro arguments is not portable
  556 | #endif
      | ^
nshlib/nsh_proccmds.c:557:1: warning: embedding a directive within macro arguments is not portable
  557 | #ifdef NSH_HAVE_CPULOAD
      | ^
nshlib/nsh_proccmds.c:559:1: warning: embedding a directive within macro arguments is not portable
  559 | #endif
      | ^
nshlib/nsh_proccmds.c: In function ‘cmd_ps’:
nshlib/nsh_proccmds.c:626:1: warning: embedding a directive within macro arguments is not portable
  626 | #ifdef CONFIG_SMP
      | ^
nshlib/nsh_proccmds.c:628:1: warning: embedding a directive within macro arguments is not portable
  628 | #endif
      | ^
nshlib/nsh_proccmds.c:631:1: warning: embedding a directive within macro arguments is not portable
  631 | #if CONFIG_MM_BACKTRACE >= 0 && !defined(CONFIG_NSH_DISABLE_PSHEAPUSAGE)
      | ^
nshlib/nsh_proccmds.c:633:1: warning: embedding a directive within macro arguments is not portable
  633 | #endif
      | ^
nshlib/nsh_proccmds.c:634:1: warning: embedding a directive within macro arguments is not portable
  634 | #if !defined(CONFIG_NSH_DISABLE_PSSTACKUSAGE)
      | ^
nshlib/nsh_proccmds.c:636:1: warning: embedding a directive within macro arguments is not portable
  636 | #ifdef CONFIG_STACK_COLORATION
      | ^
nshlib/nsh_proccmds.c:639:1: warning: embedding a directive within macro arguments is not portable
  639 | #endif
      | ^
nshlib/nsh_proccmds.c:640:1: warning: embedding a directive within macro arguments is not portable
  640 | #endif
      | ^
nshlib/nsh_proccmds.c:641:1: warning: embedding a directive within macro arguments is not portable
  641 | #ifdef NSH_HAVE_CPULOAD
      | ^
nshlib/nsh_proccmds.c:643:1: warning: embedding a directive within macro arguments is not portable
  643 | #endif
      | ^
nshlib/nsh_proccmds.c:646:1: warning: embedding a directive within macro arguments is not portable
  646 | #ifdef CONFIG_SMP
      | ^
nshlib/nsh_proccmds.c:648:1: warning: embedding a directive within macro arguments is not portable
  648 | #endif
      | ^
nshlib/nsh_proccmds.c:651:1: warning: embedding a directive within macro arguments is not portable
  651 | #if CONFIG_MM_BACKTRACE >= 0 && !defined(CONFIG_NSH_DISABLE_PSHEAPUSAGE)
      | ^
nshlib/nsh_proccmds.c:653:1: warning: embedding a directive within macro arguments is not portable
  653 | #endif
      | ^
nshlib/nsh_proccmds.c:654:1: warning: embedding a directive within macro arguments is not portable
  654 | #if !defined(CONFIG_NSH_DISABLE_PSSTACKUSAGE)
      | ^
nshlib/nsh_proccmds.c:656:1: warning: embedding a directive within macro arguments is not portable
  656 | #ifdef CONFIG_STACK_COLORATION
      | ^
nshlib/nsh_proccmds.c:659:1: warning: embedding a directive within macro arguments is not portable
  659 | #endif
      | ^
nshlib/nsh_proccmds.c:660:1: warning: embedding a directive within macro arguments is not portable
  660 | #endif
      | ^
nshlib/nsh_proccmds.c:661:1: warning: embedding a directive within macro arguments is not portable
  661 | #ifdef NSH_HAVE_CPULOAD
      | ^
nshlib/nsh_proccmds.c:663:1: warning: embedding a directive within macro arguments is not portable
  663 | #endif
      | ^

I think it would be wise to fix these.

Oops, this seems already fixed on the latest revisions.
Closing...


Fix a deprecation warning

BEGINRELEASENOTES

Use the new templated getters, fixes compiler warnings

ENDRELEASENOTES
The non-templated getters were deprecated in https://github.com/AIDASoft/podio/pull/262

Thanks! This introduces a new dependency version constraint as it needs podio v00-14-02 or newer. This is not currently available in the lcg releases, so you'd need to remove LCG_102rc1 here: https://github.com/key4hep/k4FWCore/blob/master/.github/workflows/test.yml#L12
I think we can keep the dev3 workflow even though it is currently broken, seems like a temporary publication failure only, in principle it should work.
Ideally you could also update the podio dependency in the recipe of our build tool to reflect this change: https://github.com/key4hep/key4hep-spack/blob/release/packages/k4fwcore/package.py#L26

There are no more gcc10 dev3/dev4 builds we have to move to gcc11 for that.


How to add parameters to an event ? (that are present in the JSON)

In the JSON there are parameters for begin, end, URL etc...
If I try to add a parameter, say for example, 'supplementaryinfo' in the JSON I am not able to retrieve it in the template files <%= event.supplementaryinfo %>
How may this be done?
thank you all for your help ;)

So it seems that simply adding them to the JSON is sufficient to retrieve them in template -_-
pretty simple


Babylon repo is moving

Changing the link so the docs reference goes directly to the relevant documentation.
Looks like the 2 repos are in sync however, so the change is mainly to go directly to a useful readme.

@Jackbennett
Nice catch, thanks.


Configure LLVM external projects explicitly instead of as part of LLVM build.

This is a necessary pre-requisite for #12231.
There are quite a few ways that this can be improved, but severing the nesting within the LLVM build system is necessary to maneuver anything else.
This includes a couple of other fixes:

Allows usage of iree-dialects-opt without being installed into the common LLVM tools dir (it is now under ./llvm-external-projects/mlir-iree-dialects/tools/iree-dialects-opt/iree-dialects-opt, which lines up the trees).
There was a latent ODR issue with the TransformDialectInterpreterBase in IREE having the same name/namespace as the upstream version. Due to some vagary of linking order, this patch uncovered the duplicate symbols on my machine. I namespaced the forked version to account for this but am not thrilled with the overall layering of this piece.

Closing in favor of the full stack PR.


Make Function and AdditiveModel cloneable

Currently AdditiveModel support multiscale sampling and does so by assigning each partition one scale to train model on. Each partition receives the (mutable) model spec/weights via broadcasted variable, which each JVM has one and only one copy. This becomes a problem when each executor has multi-cores and tasks on the same executor work on different partitions/scales. This create a race-condition between executors and leads to ArrayIndexOutOfBound exception.
Even when multiscaling is off, task runner on the same executor will still overwrite each other's weight update and race condition simply gets masked.
We work around this issue by making Function and AdditiveModel cloneable such that a deep copy is made for each partition. In the long run, we should revisit the liberal use of mutable data structure in Aerosolve and possibly adopt a different weights updating scheme.
@jq @deerzq @yolken @timyitong
p.s. Never done Java cloneable before. Please let me know if you have a better idea. (I considered copy constructor and builder pattern but couldn't come up a way to make inheritance work.)

nice catch! LGTM

What's the benefit of using deepCopy instead of clone? The clone is protected scoped by default and is not accessible unless we override. Is it just to clarify the fact we are deep copying vs. shallow copying?

@saurfang it is just clarify the fact we are deep copying, I am ok with check this in and refactor later, since the ideal solution is ModelTrainer can be shared. and this deep copy is part of Model operation


e-mail application type

it would be useful to add "e-mail" as a password type so that you can also archive your e-mail passwords

I think that the "Web" type is perfect for this. I have my mails with this type (url, user and password).


Format sats in create invoice screen

Fixes #803.

This is how it looks with the PR

I think my dart might be of a different version which is why this formatting is different to locally?

I think the lnd-dlc-node-tests failure is irrelevant since I didn't change anything Rust-side here.

I think the lnd-dlc-node-tests failure is irrelevant since I didn't change anything Rust-side here.

Yes, we have unfortunately somewhat flaky tests at the moment. see also #774 and #775.


Refactor/#506 - Rename scheduler to orchestrator

https://github.com/Avaiga/taipy-core/issues/506

Since the _scheduler (_orchestrator now) is only used internally, do we need to add a section to the release note?


Named routes

Implement optionally named routes within Router and/or Route so that their URIs can be generated (reverse-routed).

Solved by f2e338f3 and its preceding commits. This is v0.4.0-dev.


Missing dependencies and package names

Hi all.
Thanks for open sourcing the rf_interactions and line of sight code.
I have been unsuccessful in getting rf_interaction evaluations (e.g. running rf_values_from_pdb_and_sdf.py) to work.
I think there are some leftover naming and organization from internal Roche repo which makes this challenging.

ccdc_roche package is referenced everywhere but is not a package.

recommend creating a new package "rfinteractions" under root dir, adding init.py and moving python and atom_types subfolders under the new "rfinteractions" folder.  Then search replace all ccdc_roche package names with rfinteractions.

lookup_files is referenced but is not available

See python/rf_structure_analysis.py
ImportError: cannot import name 'lookup_files' from 'ccdc_roche' (note this is not just a ccdc_roche naming issue. I can't find "lookup_files")

global_ligand_xxxx files seem to be missing too.

Recommended changes

Having gold docking  required for parsing gold docking files make it required to have even more CCDC licenses (expensive).  We just want rf_interactions for pdb and sdf files for the time being.

Hi,
Thanks for this. If I get some time in the next few weeks I will tkae a look. The roche package is a historical thing and I'm sure it could be factored out.

Thanks for listening and your feedback.
On Tue, May 9, 2023 at 2:46 AM Jason Christopher Cole <
@.***> wrote:

Hi,
Thanks for this. If I get some time in the next few weeks I will tkae a
look. The roche package is a historical thing and I'm sure it could be
factored out.
—
Reply to this email directly, view it on GitHub
https://github.com/jasonccole/relative-interaction-frequencies/issues/2#issuecomment-1539684694,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEOJMVGNDDDXVBCDKVVT5RTXFIG7NANCNFSM6AAAAAAXTSEFTA
.
You are receiving this because you authored the thread.Message ID:
@.***
com>


Expose database/schema metadata through Connection

Feature Request
Expose detailed metadata about the database through Connection interface, similar to how a JDBC Connection exposes DatabaseMetaData.
Is your feature request related to a problem? Please describe
Not really. This feature is an enhancement. Metadata about the underlying database should make dealing with DDL queries easier. A DatabaseMetaData in JDBC for example contains information such as names of all tables in the database, list of types supported by the DBMS, etc.
Not having this additional API wouldn't be much of a problem when you have to deal with only one type of DBMS, but it could be helpful when you're dealing with more than one. Especially when you're writing a library (e.g. an ORM) that uses R2DBC drivers to deal with arbitrary DBMS's. As in this case for example: https://github.com/JetBrains/Exposed/issues/456#issuecomment-678535178
Describe the solution you'd like
R2DBC Connection interface should include a method which exposes detailed metadata about the database obtained from the Connection.
Describe alternatives you've considered
We could decide not to add complexities to the SPI, keeping it minimal. Applications/Libraries can still generate DDL, only with some difficulties.

R2DBC aims to expose only driver- and server-specific metadata (driver name, database version). Adding schema capabilities basically would add only a dialect abstraction on top of drivers and we wanted to avoid that. The actual question is: How much is such a feature required to justify demand vs. effort. Having 50% of all SPI users that want such a feature is a different story from having 1% of all users asking for the feature.

+1


 Is there any plan for mxnet to support similar lib @piiswrong @tqchen

We are working on merging in minpy

wonderful job, looking forward it


Add blueprint to make the installation easier

See README as a reference of the manual steps needed today.

Install ember-devtools not required once we do #1
Add template for app/resolver (similar to what ember-cli-bundle-loader does).
Add config/environment with 'ember-devtools' section not required once we do #1
Patch livereload.js (maybe it's too hard/hacky) or update reference to use a forked version of livereload.js and send a PR. not needed after fixing #3

Fixed by https://github.com/toranb/ember-cli-hot-loader/pull/9 the other points will be addressed by PR#2 and the corresponding issues.


Marking all feedbacks as done when you delete code fails

Steps to reproduce:

Resume an exercise that has 1 feedback
Delete some code with feedback
Wait a couple of seconds until the exercise is saved
Press the "Mark feedback as done" button in the modal
Try and send the exercise

What should happen: you should be able to send the exercise
What actually happens: the client-side code still sees the feedback as incomplete thus doesn't let you send it

Done!


Inspect sent messages

As not understood by https://t.me/grammyjs/116786

Do we, the Ukrainian translation, have to join this PR or is it enough for us to simply synchronize the changes without marking them here?

Latter

Do we, the Ukrainian translation, have to join this PR or is it enough for us to simply synchronize the changes without marking them here?

Latter

@deptyped @LWJerri this may be interesting to you, too


[CI] Support code-snippet extraction and docs-updating

What's this PR about?

Contributes to #1635 by setting up the tooling and providing a simple example of use.
This PR illustrates the use of code-excerpt extraction from source code, and the syncing of code excerpts in doc pages.
I've used Go's Getting started code as an example, annotating three code blocks for auto-syncing.
Notes: I only marked three code blocks for syncing. Of these:

The tooling found a single line mismatch (a deleted comment)
No changes were required of the Go source code for these particular code blocks to sync.

I've illustrated the most basic code synching functionality. If maintainers agree to move forward with this approach, I'll progressively illustrate the capabilities of the tooling as I set up the syncing of more code blocks.

How it works

Just add <?code-excerpt ...?> directives before code blocks to have the code snippet synced. That's it, the tools do the rest once configured.
Code excerpts get extracted from the Go code repo, which is included as a submodule.

How can I try this myself? (For maintainers/approvers only)

As indicated in tools/README.md: install the Dart SDK if you don't have it already.
Run: npm run code-excerpts
This does some preprocessing of the code excerpts and then syncs the docs -- both substeps are independent. Once primed, that full prep and sync takes less than 6 seconds on my machine, and that's mostly tooling overhead. The tools scale very nicely in the number of code excerpts and pages processed.

PR details

Sets up tooling in support of code-excerpt extraction from sources, and syncing of code excerpts in doc pages.
Adds two new directories. For details, see their respective README files.

examples
tools

Adds NPM scripts: code-excerpts, code-excerpts:get, and code-excerpts:update-docs
Adds opentelemetry-go as a submodule source to have access to example/dice code

⚠ Important: Consider this feature in beta, and for repo maintainers/approvers only.
For later

This PR do not hook up code-excerpt update into CI yet.
Prettier doesn't play nice with the SGML directive, so I've temporarily added Prettier ignore directives. I plan on eliminating that requirement soon.
Symlinks are used to centralize directories used by the code-excerpt tooling. (That won't be a problem for Linux and macOS environments. It may not play nice under Windows. I could get around this issue, but would rather not have to invest time in that atm.)

@chalin FYI related: https://github.com/open-telemetry/opentelemetry.io/pull/3949

The issue with this approach is we're going to now have 11+ additional sources of contributors messing up submodules. In practice I think most contributions are in the text and not code snippets, but the introduction of that many submodules means we're probably going to have commit to cleaning up peoples' branches for them. Submodules are difficult to work with and easy to screw up.

... Submodules are difficult to work with and easy to screw up.

Contributors can now simply run npm run sync to sync the submodules in their PR branches. For details, see the thread starting at https://github.com/open-telemetry/opentelemetry.io/issues/3149#issuecomment-1919630531.
As @svrnm pointed out during the last Comms meeting, the issue isn't how many submodules we have, it's whether we have submodules at all. Since we're pretty much stuck with submodules, having a few more won't be an extra burden; and besides, IMHO npm run sync will go a long way towards alleviating the pains of submodule syncing.
As maintainers the question we need to ask is whether we want #1635 solved in the repo or not. If we do, then this PR offers one of the best solutions I know of.
/cc @theletterf

Big fan of that, thank you for tackling this @chalin!

... Submodules are difficult to work with and easy to screw up.

Contributors can now simply run npm run sync to sync the submodules in their PR branches. For details, see the thread starting at #3149 (comment).
As @svrnm pointed out during the last Comms meeting, the issue isn't how many submodules we have, it's whether we have submodules at all. Since we're pretty much stuck with submodules, having a few more won't be an extra burden; and besides, IMHO npm run sync will go a long way towards alleviating the pains of submodule syncing.

First: +1 for npm run sync fixing 80% of that, I used it the other day and it does a perfect job, maybe we can turn this into a /fix:sync as well?
Yeah, in my experience it's not one submodule that contributors screw up, it's "all or nothing". Although I agree that adding another 11+ submodules may come with additional challenges, e.g. how much is this slowing down the build process, etc. But this is an issue to worry about later, since we start with one repo now...
Also, I am wondering, how much do contributors need to interact with that? So, if I fix some typos or words in the docs, do I even need to install&use that tooling? Or, even better, could we package all of that in a github workflow that regularly fetches the code repos, executes that code and then raises the appropriate PR?

As maintainers the question we need to ask is whether we want #1635 solved in the repo or not. If we do, then this PR offers one of the best solutions I know of.

I want this to be solved: we are software developers creating software for software developers to make it easier for them to fix problems in their code. So there are rightfully some high expectations for our stuff (including the docs) to work. Also, with our docs still growing quicker than we onboard new docs contributors we need every tooling we can have to keep us afloat.
One organizational note:
One key element for this to be successful is that we setup a proper "contract" between us and the code-owning SIGs. We need some guarantees that this code will live at a certain place in their repository and that it does certain things consistently across languages (e.g. for the getting started the roll the dice app should always run on port 8080, have /rolldice as endpoint, ...). So while trying this out with Go, we might consider establishing some documentation & practices on that (I am wondering if it may help to have @ docs-approvers/maintainers as CODEOWNERS for those files)

For this:

the issue isn't how many submodules we have, it's whether we have submodules at all.

I'd say the more submodules, the more ways things can get out of date, so it's also a matter of how many. I'm happy that we have npm run sync, but I'm hoping we can help a little more with automations. Layering on this, the refcache, and the oodles of checks we now have there's a lot of ways for a "simple contribution" to turn into a whole ordeal of unhapiness.

@svrnm wrote:

turn this into a /fix:sync as well?

Great idea! Let's track that via:

#3950

Also, I am wondering, how much do contributors need to interact with that?

Initially, no interaction at all.

So, if I fix some typos or words in the docs, do I even need to install&use that tooling?

No.

Or, even better, could we package all of that in a github workflow that regularly fetches the code repos, executes that code and then raises the appropriate PR?

Yes.

One key element for this to be successful is that we setup a proper "contract" between us and the code-owning SIGs.

Right.
We're trying to solve an inherently challenging problem. I propose that we approach this incrementally. First, let's agree on the base tooling (even if it changes later) so that we can start with something concrete. Then find a SIG willing to have us sync their code. Then incrementally bring in the automation, adjusting as we go along.
My proposal is that contributors not have to interact with this at all in the beginning. We maintainers/approvers would manually run the code-excerpt script when needed -- e.g., to handle situations like #3949 -- and commit changes.
Eventually we'll need to educate contributors that code changes need to happen at the source. There are ways to mitigate this (that I can share at our next Comms meeting), but IMHO we should stay focus on first steps.
@cartermp wrote:

I'd say the more submodules, the more ways things can get out of date, so it's also a matter of how many.

You're right, of course: the number of submodules does have an incremental impact.

I'm happy that we have npm run sync, but I'm hoping we can help a little more with automations.

That's the plan.

Layering on this, the refcache, and the oodles of checks we now have there's a lot of ways for a "simple contribution" to turn into a whole ordeal of unhappiness.

Yup, and we've been trying to do our best to keep all stakeholders as happy as possible (#2448, #3149). There are inherent complexities in the problem we're trying to manage (supporting the build, checking and deployment of a non-trivial tech-docs website with parts spread across repos) beyond "just writing docs". E.g., submodules can be a pain to deal, but most of the time IMHO, they help cleanly solve the problem of keeping content across repos in sync.

<?code-excerpt "otel.go" from="package main"?>

For the sake of consistency, can we wrap this in a short code that is only there to replace those <? with {{%:
{{% code-excerpt "otel.go" from="package main" %}}

We're trying to solve an inherently challenging problem. I propose that we approach this incrementally. First, let's agree on the base tooling (even if it changes later) so that we can start with something concrete. Then find a SIG willing to have us sync their code. Then incrementally bring in the automation, adjusting as we go along.
My proposal is that contributors not have to interact with this at all in the beginning. We maintainers/approvers would manually run the code-excerpt script when needed -- e.g., to handle situations like #3949 -- and commit changes.
Eventually we'll need to educate contributors that code changes need to happen at the source. There are ways to mitigate this (that I can share at our next Comms meeting), but IMHO we should stay focus on first steps.

+1 for this approach, in the worst case(!) we can pull back and revert that tooling. We should gain some experience with it and see if it adds more value vs more issues and then make a judgement. Maybe we need to onboard 2 to 3 SIGs to make a final decision if we want to go all in or not. Let's assume we take 1-2 months to add one more SIG we might be able to go from "beta" to rolling this out in ~3-4 months. WDYT?

@cartermp wrote:

I'd say the more submodules, the more ways things can get out of date, so it's also a matter of how many.

You're right, of course: the number of submodules does have an incremental impact.

I'm happy that we have npm run sync, but I'm hoping we can help a little more with automations.

That's the plan.

Layering on this, the refcache, and the oodles of checks we now have there's a lot of ways for a "simple contribution" to turn into a whole ordeal of unhappiness.

Yup, and we've been trying to do our best to keep all stakeholders as happy as possible (#2448, #3149). There are inherent complexities in the problem we're trying to manage (supporting the build, checking and deployment of a non-trivial tech-docs website with parts spread across repos) beyond "just writing docs". E.g., submodules can be a pain to deal, but most of the time IMHO, they help cleanly solve the problem of keeping content across repos in sync.

If we wrap all that code-updating into a workflow or into something only maintainers touch, I wonder if we should pick some "conditional" submodules, i.e. they are not part of .gitmodules by default and a maintainer (or a bot) needs to run a script first to add and load them, do the script updates, run a script to unload them and send the PR. It adds some extra burden on us / the workflow but it removes the necessity for regular contributors to interact with even more submodules

@svrnm wrote:

For the sake of consistency, can we wrap this in a short code that is only there to replace those <? with {{%:

Eventually, but for now I'd like to focus on using the tools rather than customizing them. I have further improvements in mind, but again, I'd rather we gain experience with existing tooling for starters.

+1 for this approach, in the worst case(!) we can pull back and revert that tooling. We should gain some experience with it and see if it adds more value vs more issues and then make a judgement. Maybe we need to onboard 2 to 3 SIGs to make a final decision if we want to go all in or not. Let's assume we take 1-2 months to add one more SIG we might be able to go from "beta" to rolling this out in ~3-4 months. WDYT?

👍🏻

If we wrap all that code-updating into a workflow or into something only maintainers touch, I wonder if we should pick some "conditional" submodules, i.e. they are not part of .gitmodules by default and a maintainer (or a bot) needs to run a script first to add and load them, do the script updates, run a script to unload them and send the PR. It adds some extra burden on us / the workflow but it removes the necessity for regular contributors to interact with even more submodules

Sure, but with the magic and ease of npm run sync, I'd say that there's no extra burden on regular contributors. So I'd avoid the extra cost (for now) of conditional / secondary submodules.
WDYT?

@svrnm wrote:

For the sake of consistency, can we wrap this in a short code that is only there to replace those <? with {{%:

Eventually, but for now I'd like to focus on using the tools rather than customizing them. I have further improvements in mind, but again, I'd rather we gain experience with existing tooling for starters.

+1

If we wrap all that code-updating into a workflow or into something only maintainers touch, I wonder if we should pick some "conditional" submodules, i.e. they are not part of .gitmodules by default and a maintainer (or a bot) needs to run a script first to add and load them, do the script updates, run a script to unload them and send the PR. It adds some extra burden on us / the workflow but it removes the necessity for regular contributors to interact with even more submodules

Sure, but with the magic and ease of npm run sync, I'd say that there's no extra burden on regular contributors. So I'd avoid the extra cost (for now) of conditional / secondary submodules.

If we start with one repo (=> go), I have no concern with adding this one more sub-module for now. Let's make it work with go, and then keep it going for a few weeks and see how many things break.
@pellared , @cartermp: wdyt?

So one thing that this has caused me to think about is adding an action for a "please fix all my shit". So it fixes formatting, the refcache, runs npm sync, etc. Maybe if we not only have the actions in place, but also a single place to mostly fix most things, then that could be enough to ease my unease around the contributor experience.

So one thing that this has caused me to think about is adding an action for a "please fix all my shit". So it fixes formatting, the refcache, runs npm sync, etc. Maybe if we not only have the actions in place, but also a single place to mostly fix most things, then that could be enough to ease my unease around the contributor experience.

Like a fix all?
--> https://github.com/open-telemetry/opentelemetry.io/blob/main/.github/workflows/pr-actions.yml#L82
It does not have all the fixes yet, but updating that workflow file has become much easier now. So that should hopefully help a lot.
Another thing we could do is adding a workflow that checks CI results and let's people know that they can trigger those actions, or that they should not worry about them too much and that we can fix that for them before merging.

@chalin update and merge this PR whenever you are ready

awesome, thanks @chalin! Now let's see how this works in the future.

@svrnm - I'm OOO next week, but will dive into using this again (probably for the demo) when I'm back (FYI)


How much data a Scan() call can return

Your Question
Wanted to check how much data a single Scan() call could return.
Assuming there are 0.1 million matching rows in DB, all rows would be returned or there is some default limit (number of rows returned or on size of data returned)? Or will return any error?

The document you expected this should be explained

Expected answer
A Scan() call would return, for example max 10k rows or 10MB data out of 0.1 million rows, etc.

gorm has no restrictions on this.


yarn install报错：gifsicle pre-build test failed

有没有人遇到以下这个问题？
vben-2.6.1版本
在运行yarn install的时候一直报错，clean:lib，clean:cache都没用，删除-lock文件也没用，卡了好久了
`
warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>[5/6] Building fresh packages...
[8/13] ⠈ optipng-bin
[6/13] ⠈ jpegtran-bin
[9/13] ⠈ pngquant-bin
[7/13] ⠈ mozjpeg
error D:\workspace\xxx\xxx\node_modules\vite-plugin-imagemin\node_modules\gifsicle:
Command failed.
Exit code: 1
Command: node lib/install.js
Arguments:
Directory: D:\workspace\xxx\xxx\node_modules\vite-plugin-imagemin\node_modules\gifsi
cle
Output:
Response code 404 (Not Found)
gifsicle pre-build test failed
compiling from source
Error: Command failed: C:\WINDOWS\system32\cmd.exe /s /c "autoreconf -ivf"
'autoreconf' �����ڲ����ⲿ���Ҳ���ǿ����еĳ���
���������ļ���
at D:\workspace\xxx\xxx\node_modules\bin-build\node_modules\execa\index.js:231:1

1

我也是，
win11
node:v16.13.1
yarn:1.22.10
Output:
Response code 404 (Not Found)
gifsicle pre-build test failed
compiling from source
Error: Command failed: C:\WINDOWS\system32\cmd.exe /s /c "autoreconf -ivf"
'autoreconf' �����ڲ����ⲿ���Ҳ���ǿ����еĳ���
���������ļ���

我也是， win11 node:v16.13.1 yarn:1.22.10
Output:
Response code 404 (Not Found)
gifsicle pre-build test failed
compiling from source
Error: Command failed: C:\WINDOWS\system32\cmd.exe /s /c "autoreconf -ivf"
'autoreconf' �����ڲ����ⲿ���Ҳ���ǿ����еĳ���
���������ļ���

我找到原因了，还原这个文件就可以了yarn.lock。这个文件不能删除。

我换成pnpm，把官方的pnpm-lock.yaml放进项目里，好了

TL;DR: Change the resolutions section in package.json as below:
  "resolutions": {
    "bin-wrapper"<EMAIL_ADDRESS>    "gifsicle": "5.2.0",
    "rollup": "^2.56.3"
  },

This fix also applies to anncwb/vben-admin-thin-next
The package bin-wrapper-china has the gifsicle-bin download issue by applying mirrors in binary-mirror-config, but the windows executable for v5.3.0 is missing in npmmirror.com (i.e. GET https://npmmirror.com/mirrors/gifsicle-bin/v5.3.0/vendor/win/x64/gifsicle.exe 404). Since both v5.2.0 and v6.1.0 exist and similar fixes (anncwb/vue-vben-admin#1497, anncwb/vue-vben-admin@2aabbc788ab05d06f4dcc2a01b25585ecf8f690b) uses v5.2.0, this fix chose that version as the resolution.
The @0.1.0 suffix is required in Yarn 2 protocal schemas (see https://yarnpkg.com/features/protocols). This fix is tested to successfully installed with Yarn v1.22.11 /v3.1.1 and Node v16.13.1 . Supposely this fix and those applied at anncwb/vue-vben-admin can fix anncwb/vue-vben-admin#345 and anncwb/vue-vben-admin#1438
Note for Yarn proxy settings:

For Yarn 1, use yarn config set proxy http://host:port and yarn config set https-proxy http://host:port in terminal, or you can edit ~/.yarnrc directly.
For Yarn 2 and up, use yarn config set httpProxy http://host:port and yarn config set httpsProxy http://host:port in terminal, or you can edit ~/.yarnrc.yml directly. Note that ~/.yarnrc will not work with Yarn 2.


[FLINK-5021] Makes the ContinuousFileReaderOperator rescalable.

This is the last PR that completes the refactoring of the ContinuousFileReaderOperator so that it can be rescalable. With this, the reader can restart from a savepoint with a different parallelism without compromising the provided exactly-once guarantees.
The whole PR contains 3 commits.
The first removes the EOS special split which was used to signal that no new splits are to be processed. This was useful in the PROCESS_ONCE mode. Now the reader closes by setting a flag and waiting for all the pending splits to be fully processed.
The second puts an additional check in the ContinuousFileMonitoringFunction that guarantees that in the case of the PROCESS_ONCE, the source will not reprocess the directory after recovering from a failure.
Finally, the third integrates the new rescalable state abstractions with the reader so that the reader can restart from a savepoint with different parallelism and still guarantee exactly-once semantics.
R: @aljoscha

I merged this, thanks for your work! 👍
Could you please close this PR and the Jira issue?


Add important information to README

This pull request adds to the README file some important information:

an alternative way to install VOC via pip (as discussed in issue #2 )
Python 3.x is required to run VOC (otherwise some lambda functions raise errors, due to print being a statement in Python 2.x)

Thanks of the report - I tweaked the text, but should have all the same details.

Thanks... also for having fixed the issue about pip installation !
Actually, it seems there is another small imprecision in the Quickstart section: the relative path to the file example.class when running the java command.
Instead of just example it should be org.pybee.example
That is, the complete command should be:
$ java -XX:-UseSplitVerifier -classpath python.jar:. org.pybee.example
It's such a small correction that I'm not sure if open an issue, create a pull request or simply notify you about it with this comment =)

Thanks - I've just corrected that extra problem. I swear that sometimes, I actually read the instructions that I write... :-)


Introduce longhorn version env variable in webpack

What's change in this PR?
From this PR comment, we need to let user link to correct version docs following to LH UI version.
Introduce env variable in webpack to know longhorn-ui version at build time.(npm run dev & npm run build)
Issue
https://github.com/longhorn/longhorn/issues/8071
Test Result
Development mode

v1.6.3 (by update version file)

v1.7.0

Production mode

Done rebase, mark ready to review


confusion about the paper's formulas

Hi @takashiishida Thank you very much for your reply. If I didn't understand it wrong, you mean
.
But i can only get
Another question is, when I replace the formula in the codelogistic = -1. * negative_logistic(-1. * model(inputs)) loss = torch.sum(-model(inputs)+ logistic * 1. / confidence) with the formula in the paperloss = torch.sum(negative_logistic(model(inputs)) + negative_logistic(-model(inputs))*(1.-confidence)/confidence), the results are different. What is the reason?Why the results obtained by directly optimizing the formulas in the paper are poor？

I'm sorry but there was a typo in my post in Issue #2 so the correct proof would be:
\ell_L(g) - \ell_L(-g)
= \log \frac{1+exp(-g)}{1+exp(g)}
= \log \frac{1+e^{-g}}{1+e^{g}}
= \log e^{-g}
= -g
Mathematically the two equations are equivalent and should give similar experimental results.  I haven't tried the experiments with the latter implementation, so I will need to investigate to see if there are some numerical issues.

Thank you very much for your patience👍


TAL38 One button to delete all current drafts

https://user-images.githubusercontent.com/51877144/103631855-1a3ef180-4f76-11eb-93f2-e8d613bddf49.mp4

https://user-images.githubusercontent.com/51877144/103631855-1a3ef180-4f76-11eb-93f2-e8d613bddf49.mp4


Add alerts for pods that are being "heavily" throttled

Our new monitoring stack provides far better insight into the our system metrics than any of the other tools available for the platform.  Specifically, we now have in depth insight in to the throttling metrics of our pods.
Please setup alerts to trigger notifications when pods are throttled >25% for more than 5 minutes.
This should be done after the review of the related Throttling Tickets.

Alerts have been created in Grafana with notifications being sent to RocketChat.


Update roles.rst

https://github.com/aspnet/Mvc/blob/51d47c7be18ff55a1d9acca63f1a381f144f0d13/src/Microsoft.AspNet.Mvc.Core/Filters/AuthorizeAttribute.cs#L38
Input is not being trimmed (remove spaces), so if you follow the documentation, the second role will never be able to access the method.

Hi @Sebas-, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

@blowdart Please review. Is this a product bug?

No it's a doc bug :) We don't trim on purpose.

Thank you! 6b71a8ab5495069939406665fe6ce370b2cf0065


page.body wraps JSON responses in HTML

When requesting a page in json format from a rails 3 application via cucumber-rails 1.0 with capybara 1.0, I get the following response:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">

[]

This had worked with capybara 0.4.x and cucumber-rails 0.5.x. I'm not entirely certain as to which gem introduced the error though.

+1.  Just hit this when updating cap here.

+1


Missing plugin in @guardian/eslint-config-typescript

Describe the bug
When trying to use @guardian/eslint-config-typescript v9.0.3 within Editions, we get the following error
ESLint couldn't find the config "plugin:@typescript-eslint/recommended-type-checked" to extend from. Please check that the name of the config is correct.

This is because the eslint plugin is not part of the package.json
To Reproduce
Install the package on a clean project, run it and see the error
Environment (please complete the following information):

Version 9.0.3 of the package.

Thanks for raising this @jimhunty.
I'm afraid I'm unable to recreate it.
@guardian/eslint-config-typescript has a dependency on @typescript-eslint/eslint-plugin and that provides recommended-type-checked, so it should be present.
Are you still having issues with it?

unable to reproduce


How can we give styling to the dot ?

How can we give style to the dot to display like below?

able to resolve it by using renderDotContent() property.


[A11y] Links of workbench.parts.banner have role="button"

Type: Bug
Hi folks,
I've found that <a> nodes which work like links have role="button" at workbench.parts.banner. That happens because there is a line which explicitly set it for every Link instance:
https://github.com/microsoft/vscode/blob/650e4b5e68d22d111ed22e571c274ddf48faa96a/src/vs/platform/opener/browser/link.ts#L93
Do you know if there is a reason to override the role value? Shall there be a way to explicitly change the role for some specific actions?
Role descriptions:

button
link

VS Code version: Code - Insiders 1.70.0-insider (92fd228156aafeb326b23f6604028d342152313b, 2022-07-19T13:01:49.834Z)
OS version: Darwin x64 21.5.0
Modes: Restricted

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz (16 x 2300)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
64.00GB (21.49GB free)

Process Argv
--crash-reporter-id dae9747d-a608-49fb-967b-b0bdd43dcc8f

Screen Reader
no

VM
0%

Extensions: none
A/B Experiments
vsliv695:30137379
vsins829:30139715
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vslsvsres303:30308271
pythonvspyl392:30422396
pythontb:30258533
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805:30301674
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30404738
wslgetstarted:30449409
vscscmwlcmt:30465136
cppdebug:30492333
pylanb8912:30522163
vsclangdf:30492506

//cc @isidorn, @joaomoreno

@mbelsky thanks for opening this issue. I believe this was recommended to us some time ago by members of our accessibility community. Unfortunately I do not remember more details. If you want you can try to remove that line, and create a PR and test it out. And let us know what is the exact difference you see when using this with a screen reader. I think we are open for a change here if you have a good reason.

@sbatten, what would be a good feature label for this issue? Thanks!

@lszomoru do you mean feature area label? if so, we don't have workbench-banner but we should probably add it.

based on the feedback from @isidorn , I've added info-needed since our current behavior is based on previous guidance.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Revert "Introduce privateApiElements variant"

Reverts gradle/gradle#27980
We had issues integrating this new variant when trying to wire tests.
The problems arise when you try to resolve two dependencies on the same component, one which selects the public API and one which selects the private API during compile-time. For example, resolving the compileClasspath of a java library that targets some producer library with test fixtures, like so, leads to a capability conflict:
plugins {
    id("java-library")
}

dependencies {
    implementation(testFixtures(project(":producer")))
    implementation(project(":producer")) {
        attributes {
            attribute(ApiType.TYPE_ATTRIBUTE, objects.named(ApiType, ApiType.PRIVATE))
            attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named(LibraryElements, LibraryElements.CLASSES_AND_RESOURCES))
        }
    }
}

task resolve {
    def files = configurations.compileClasspath
    doLast {
        files.each {
            println(it)
        }
    }
}

The issue here is that these two dependencies select two different variants, and there is no mechanism to resolve that conflict. We have discussed two solutions:

Enhance the dependency resolution engine to automatically handle conflicts like this. When multiple nodes in a graph are selected and they conflict with each other where one variant is compatible with the other, automatically disambiguate them by retargeting the edges targeting one node to the other. This approach is risky in that it touches complex resolution infrastructure, but is likely the more effective solution and leads to a better use experience. Currently, the engine does not track node conflicts during resolution, and only checks conflicts between nodes during graph validation, after the graph has been built. See: validateGraph
Migrate to using constraints on project dependencies. This would allow tests to declare that all dependencies on the production code should use the private API. Even transitive ones. This can run into issues if a transitive dependency also declares a constraint on the same component, but we discussed a potential solution of intelligently merging constraint attributes using an attribute schema and compatibility rules. Furthermore, this solution makes it so users need to declare both a project dependency and constraint, which complicates the user experience. These constraints may not be simple, as we would also want to introduce capability-scoped constraints that apply attributes only to nodes with certain capabilities. For example, we do not want the private API constraint to also affect the test fixtures jar, which lives in the same component. Furthermore, if we go with this approach, we will likely have some DSL in-between the user and the actual dependency declarations, which means we would want to revisit option 2 in the original spec

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

The merge queue build has started. Click here to see all failures if any.


[FEATURE REQUEST] Add ARM build to the releases

I wanna use linux-arm64

@xiaohao0416 Thanks for the FR. It's totally not a problem to build a golang binary with ARM/ARM64 support, but I have to test RR on that platform to make sure, that everything goes fine.

Done, now you can use docker container with the linux/arm64

(Internal ticket) INFR-1869 "Create a VM with AArch64/ARM64 image" for auto-tests has been added to the scope.


Some optimize

Replace internal API;
Enable and disable plug-ins without restarting;
Compatible with 2023.*

Hello @meiMingle , thanks for the PR.
BTW, if I understand correct, we can remove require-restart="true" in the plugin.xml, isn't it?

Hello @meiMingle , thanks for the PR. BTW, if I understand correct, we can remove require-restart="true" in the plugin.xml, isn't it?

Yeah I just forgot to remove it, I just fixed it

@meiMingle Thanks again! Merged.

Will release 1.1.4 soon.

@meiMingle Thanks again! Merged.

I'm also grateful to you. I created another plug-in that supports viewing JPEGXL format files based on my study of your code. JPEGXL Support


How to create a custom Gradle task mytest that can include/exclude matching test classes

For #350 , I edited the base/build.gradle and inserted the following lines:
test {
    filter {
        includeTestsMatching("*reduce.MaterialProductGroup_BuilderTest")
        includeTestsMatching("*reduce.MaterialProductGroup_issue87Test")
    }
}

This worked fine.
Buit I wanted to create a custom task mytest which does the same above while leaving the original test task as origingal. So I modified
task mytest(type:Test) {
    filter {
        includeTestsMatching("*reduce.MaterialProductGroup_BuilderTest")
        includeTestsMatching("*reduce.MaterialProductGroup_issue87Test")
    }
}

This does not work.
$ gradle mytest
> Task :base:mytest FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':base:mytest'.
> No tests found for given includes: [*reduce.MaterialProductGroup_issue87Test, *reduce.MaterialProductGroup_BuilderTest](filter.includeTestsMatching)

How should I write the mytest task?

With the build.gradle file having
test {
    filter {
        includeTestsMatching("*reduce.MaterialProductGroup_BuilderTest")
        includeTestsMatching("*reduce.MaterialProductGroup_issue87Test")
    }
}

I did clean and test --- it failed.
$ gradle clean test

> Task :base:test

MaterialProductGroup_issue87Test > test_getQueryOnMetadataList() FAILED
    org.opentest4j.AssertionFailedError at MaterialProductGroup_issue87Test.java:111

8 tests completed, 1 failed

> Task :base:test FAILED

Soon after this, I tried test without clean --- i passed.
:~/github/materialstore/base (Issue350 *)
$ gradle test

BUILD SUCCESSFUL in 5s
10 actionable tasks: 2 executed, 8 up-to-date

Then I tried clean and test again --- it failed.
:~/github/materialstore/base (Issue350 *)
$ gradle clean test

> Task :base:test

MaterialProductGroup_issue87Test > test_getQueryOnMetadataList() FAILED
    org.opentest4j.AssertionFailedError at MaterialProductGroup_issue87Test.java:111

8 tests completed, 1 failed

> Task :base:test FAILED

I tried this sequence repeatedly. I could reproduce this result.
There must be a clue here.

I changed the issue87Test so that it draws the diagram of the MaterialProductGroup object:
    @Test
    public void test_getQueryOnMetadataList() throws MaterialstoreException {

        List<QueryOnMetadata> queryList = mpg.getQueryOnMetadataList();

        System.out.println("[test_getQueryOnMetadataList]");
        for (int i = 0; i < queryList.size(); i++) {
            System.out.println(String.format("queryList.get(%d): %s", i, queryList.get(i).toString()));
        }

        // https://github.com/kazurayam/materialstore/issues/351
        // generate a diagram of the MaterialProductGroup object
        // save the image into a new folder
        String dot = DotGenerator.generateDot(mpg);
        BufferedImage bi = DotGenerator.toImage(dot);
        store.write(jobName, JobTimestamp.now(), FileType.PNG, Metadata.builder().build(), bi);

        // Assert
        Assertions.assertEquals(8, queryList.size());

When it passed, it produced the following image:

The following worked:
task testFiltered(type:Test) {
    useJUnitPlatform()
    filter {
        includeTestsMatching("*reduce.MaterialProductGroup_BuilderTest")
        includeTestsMatching("*reduce.MaterialProductGroup_issue87Test")
    }
}


[AMBARI-23227] Pass service_group_name and service_name while creatin…

…g Host Components.
What changes were proposed in this pull request?
service name and service_group_name are fetched from selectedServices
How was this patch tested?
20408 passing (23s)
46 pending

RETEST


Speed up detection of new virtual environments in workspace

For #656

[x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR)
[x] Title summarizes what is changing
[no] Has a news entry file (remember to thank yourself!)
[x] Unit tests & system/integration tests are added/updated
[no] package-lock.json has been regenerated by running npm install (if dependencies have changed)

New changes:

When extension is refreshing the list of interpreters, we'll display a progress message Refreshing Python Interpreters
Add a progress label for this.


MAISTRA-2475 Fix initialization and update of Kiali.spec.deployment.accessible_namespaces

This ensures that the .spec.deployment.accessible_namespaces field is initialized when the Kiali resource is first deployed (by the smcp controller), but is then updated only by the smmr controller. The smcp controller should never overwrite the value, as this would cause the issue described in MAISTRA-1956. Previously, we simply removed the field from the Helm chart, which resulted in the smcp controller never updating the field (it was thus only ever updated by the smmr controller), but this resulted in a different issue, where Kiali starts logging errors, because it thinks it has access to all namespaces.

Forced push to fix the commit message (should be smmr, not smm controller)


Fix transfer project to organization

Restrict transfer project choices to active orgs
Avoid double <hr> when organizations are disabled

A couple fixes for the project "Settings" page — not related to any active issue.


glibc: 2.31 -> 2.32 [20.09]

cherry-picked (30286ebcc178aec1fb3797ba3ec88cf75feb282b)
commit 30286ebcc178aec1fb3797ba3ec88cf75feb282b
Author: Maximilian Bosch<EMAIL_ADDRESS>Date:   Mon Aug 10 11:25:08 2020 +0200

    glibc: 2.31 -> 2.32

    ChangeLog: https://sourceware.org/pipermail/libc-announce/2020/000029.html

    Patches removed:

    * `rpcgen-path.patch` is obsolete as the support for SunOS RPC has been
      removed in 2.32[1].

    * The vulnerabilities CVE-2020-1752[2] & CVE-2020-10029[3] are fixed in
      `glibc-2.32`[4][5], thus applying those manually isn't necessary anymore.

    I also added myself as second maintainer as I'm quite regularly doing
    `glibc`-related stuff in `nixpkgs`, so let's make this situation
    official.

    [1] https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=5500cdba4018ddbda7909bc7f4f9718610b43cf0
    [2] https://nvd.nist.gov/vuln/detail/CVE-2020-1752
    [3] https://nvd.nist.gov/vuln/detail/CVE-2020-10029
    [4] Commit<PHONE_NUMBER>cde1d5cca518badf79533a24114b6f (CVE-2020-1752)
    [5] Commit ddc650e9b3dc916eab417ce9f79e67337b05035c (CVE-2020-10029)

Motivation for this change
See above:  #93992
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

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

There may be packages that this breaks and have additional changes to cherry-pick.
Not sure if they should be cherry-picked into this PR or not -- seeking advice.

https://github.com/NixOS/nixpkgs/issues/100799

Yeah, in fact I had to fix ~40 packages during the update to 2.32 (and there were a few more broken). Also I think it's a bad idea to replace such a core component of the OS in a stable release (that is known to have breaking changes in minor releases like the removal of sunrpc support in 2.32 btw), instead we usually applied the relevant patches in the past IIRC.
cc @vcunat

I'm fairly confident that we don't want to upgrade glibc on a stable release.  I think the best alternative is to use recent 2.31 branch from upstream.  They surely are better at backporting than any of us.

Ah, here's how one can do such a thing: https://github.com/NixOS/nixpkgs/pull/100813

Sounds good @vcunat - I can take a stab at it but honestly I'm probably not the best person to do it.

Sounds good @vcunat - I can take a stab at it but honestly I'm probably not the best person to do it.

Okay - so I'm the one doing it :-)
Marking as WIP and firing up my hydra instance

Putting it in a new branch/pr so I don't confuse my simple brain.
Will reference this PR in the other to cross-reference for history.


[Question] for node array in order content. Is it valid that  add two nodes with the same nodeId but different nodePositions.

for node array in order content. Is it valid that  add two nodes with the same nodeId but different nodePositions.
for example ：
"nodes": [
{ "nodeId":"1", "nodePosition":{"x“: 1000, "y": 1000 } },
{ "nodeId":"1", "nodePosition":{"x“: 1500, "y": 1000 } }
]

it is possible as log the nodes have driffrent sequenceId.
But then your edges get crazy because the startNodeId is identical to  endNodeId.
then it get vehicle dependet what will happen.
but if there are some nodes in between it is less problematik.

thank you for the reply so quickly.
if two node has same nodeId  and sequenceId is invalid, I can increment the second node's  sequceceId, its simple.
in our system, nodeId，startNodeId and endNodeId is not needed. AMR only care the base command position and the line style（straight line or cruve）,velocity ...
so for simple just I want is set the nodeId always be a constant ,for example  be 1, and let amr always update the base command to the second node.  amr need to ommit "the startNodeId is identical to endNodeId"
for example  in our system:
amr position (1000mm, 1000mm, 0)
T1: send  (1500mm,  1000mm, 0) straight line
T2: send  (1555mm, 1000mm, 0) amr will update base command to (1555mm, 1000mm, 0)
follow VDA ptotocal
T1: orderId: 0,
{ "nodeId":"1", "nodePosition":{"x“: 1000mm, "y": 1000mm } },
{ "nodeId":"1", "nodePosition":{"x“: 1500mm, "y": 1000mm } }
need amr  ommit "the startNodeId is identical to endNodeId"
T2：orderId: 1,
{ "nodeId":"1", "nodePosition":{"x“: 1500mm, "y": 1000mm } },
{ "nodeId":"1", "nodePosition":{"x“: 1555mm, "y": 1000mm } }
also need amr  ommit "the startNodeId is identical to endNodeId"
also in VDA ptotocal
if we have two point
{ "nodeId":"1", "nodePosition":{"x“: 0mm, "y": 1000mm } },
{ "nodeId":"2", "nodePosition":{"x“: 100000mm, "y": 1000mm } }
if amr posinion is (50000mm, 1000mm) i want amr  go to  (50020mm, 1000mm)，there is not a node which position is  (50000mm, 1000mm,) and also no nodeId whitch  (50020mm, 1000mm).  how VDA solve this case, use random nodeId ?

it is possible as log the nodes have driffrent sequenceId.
But then your edges get crazy because the startNodeId is identical to endNodeId.
then it get vehicle dependet what will happen.
but if there are some nodes in between it is less problematik.

thank you for the reply so quickly.
if two node has same nodeId and sequenceId is invalid, I can increment the second node's sequceceId, its simple.
in our system, nodeId，startNodeId and endNodeId is not needed. AMR only care the base command position and the line style（straight line or cruve）,velocity ...
so for simple just I want is set the nodeId always be a constant ,for example be 1, and let amr always update the base command to the second node. amr need to ommit "the startNodeId is identical to endNodeId"
for example in our system:
amr position (1000mm, 1000mm, 0)
T1: send (1500mm, 1000mm, 0) straight line
T2: send (1555mm, 1000mm, 0) amr will update base command to (1555mm, 1000mm, 0)
follow VDA ptotocal
T1: orderId: 0,
{ "nodeId":"1", "nodePosition":{"x“: 1000mm, "y": 1000mm } },
{ "nodeId":"1", "nodePosition":{"x“: 1500mm, "y": 1000mm } }
need amr ommit "the startNodeId is identical to endNodeId"
T2：orderId: 1,
{ "nodeId":"1", "nodePosition":{"x“: 1500mm, "y": 1000mm } },
{ "nodeId":"1", "nodePosition":{"x“: 1555mm, "y": 1000mm } }
also need amr ommit "the startNodeId is identical to endNodeId"
also in VDA ptotocal
if we have two point
{ "nodeId":"1", "nodePosition":{"x“: 0mm, "y": 1000mm } },
{ "nodeId":"2", "nodePosition":{"x“: 100000mm, "y": 1000mm } }
if amr position is (50000mm, 1000mm) i want amr go to (50020mm, 1000mm)，there is not a node which position is (50000mm, 1000mm,) and also no nodeId whitch (50020mm, 1000mm). how VDA sugget to solve this case, use random nodeId ?


Color matching brackets for Clojure

Is it possible in Clojure mode, to color each matching brackets in a different color in a similar way as the rainbow brackets extension for IntelliJ?

You could write an addon that does that, but the existing Clojure mode doesn't (and I consider it outside of the scope of modes to do this).


Add submission date to PR search results and update default sor field

Is the title meant to say "sort" field?

Is the title meant to say "sort" field?

Yes! Typo, my bad


Remove excess l10n related markups

There are excess l10n markups which produce meaningless msgid/msgstr pairs in message catalogue.

https://github.com/bluesky-social/social-app/blob/9cbd3c0937d22e8dccbd9c086d3a3a24dbd27b3a/src/Navigation.tsx#L147
It looks like this can be removed as well.