Accept definedBy action arguments in bundle file

I would like to be able to specify the use of versioned IRIs in the definedBy action. I don't want to leave it to chance - I.e., someone remembering or not remembering to use it on the commandline - but would like to specify it as an argument in the bundle file. Same consideration applies to retain-definedBy, though I am not planning to use it.

My mistake again, this is exactly how it does work: add versionedDefinedBy: true to the definedBy action in the bundle config.


feature request: shell in a tab

I want to run a test script and see the results in the console.
essentially, this could just be a shell expression.
but it is not a long lived process like an eval client,
and it probably produces stack traces in stdout that can be linked to lines of code in the editor.
for my purposes binding a key to a command that runs in the directory of the currently open file would work well. I may also want to configure this per directory/workspace?
or maybe just a way to run a shell command and see output in the console...

nope, we REALLY need a tab with a shell in it. closing this issue and the referencing #1687 and closing that one referencing this one, well...
+1 for a shell tab

+1

+1

+1

+1

+1
Pretty please make this a standard feature.

I have found LT-Opener and will give it a try now.

@muhuk Please create a new issue in the repo for the LT-Opener plugin. I suspect its not working because its behaviors file isn't in the new flat syntax.
Or, before creating an issue, first try converting it to the new format manually. Here's the corresponding commit for converting the behaviors file for the default HTML plugin.
I created an issue in the LT-Opener plugin repo about the behaviors file format.

@muhuk Seems like you messed up with settings. open(1) is a standard utility on OS X, but not on linux. Anyway, js console in dev tools should give you enough information.

@muhuk My bad – it's definitely not the behaviors file. The latest version continues to support the old format of those files.

open(1) is a standard utility on OS X, but not on linux.

OSX is based on Linux.
$ which open
/bin/open
$ open --help
Usage: open [OPTIONS] -- command

This utility help you to start a program on a new virtual terminal (VT).

Options:
-c, --console=NUM   use the given VT number;
-e, --exec          execute the command, without forking;
-f, --force         force opening a VT without checking;
-l, --login         make the command a login shell;
-u, --user          figure out the owner of the current VT;
-s, --switch        switch to the new VT;
-w, --wait          wait for command to complete;
-v, --verbose       print a message for each action;
-V, --version       print program version and exit;
-h, --help          output a brief help message.

@muhuk the open(1) command you refer to is a completely different thing. It has nothing to do with open(1) we have on OS X. Try to make sure that your command works as expected when entered directly, before attempting to configure the plugin.

For anyone familiar with Butterfly – can't it be used as-is by accessing it from a browser tab in LT?

@kenny-evitt I  made a butterfly plugin a while back,  I can open up a branch.  There some bugs but I can't remember what they were

@justintaft What does your plugin do? Start Butterfly and open a browser tab in LT?

+1 for shell in a tab!

So I confirmed that you can in fact just use Butterfly as-is – start it, open a browser tab in LT, and change the address of the browser tab to point to the Butterfly server. I'm not sure what value a plugin would add.

So I confirmed that you can in fact just use Butterfly as-is – start it, open a browser tab in LT, and change the address of the browser tab to point to the Butterfly server. I'm not sure what value a plugin would add.

@kenny-evitt it would reduce work from:

start it
open a browser tab in LT
and change the address of the browser tab to point to the Butterfly server

to:

open a shell tab in LT (with a bonus of recognizing project dir or file dir)

@muhuk Yeah; I can see the value in that. And it can do other cools things too – see the help info. Something in particular that might be really handy:
{title}Butterfly programs:{reset}
  {strong}b         : {reset}Alias for {strong}butterfly{reset} executable. Takes a comand in parameter or launch a butterfly server for one shot use (if outside butterfly).
...

One thing I noticed about Butterfly, tho I didn't spend any real amount of time investigating it, is that the browser tab in LT pointing at Butterfly seemed to refresh automatically and lose my history. I'm not sure if there's a quick-fix for that or that's part of why the shell-in-a-tab feature needs to be more tightly bound to LT.

Hello, I've invested some time to create a really simple wrapper around butterfly.
See here for details https://github.com/alun/terminal/blob/master/README.md
There of course some more work to do to make it more pleasant to use.

I'm closing this as @alekseilunacharskii has implemented a plugin to provide this and any future work related to this can best be directed towards improving that plugin.
Thanks @alekseilunacharskii ! 🎉 👍 Sorry for not congratulating you back in February!


Fix maximum call stack error when parsing very long arc arrays

This fixes a bug caused when concatenating arc segments using push.apply() for arcs that are very large (100,000-200,000 points), see eg: https://stackoverflow.com/questions/61740599/rangeerror-maximum-call-stack-size-exceeded-with-array-push
See #12842 for more details.
I have only tested that the fix works by copying the relevant functions to a separate js script, not within the context of the entire OpenLayers library.

Any takers to help merge this? This would help out a great deal for those working with TopoJSON. Much appreciated!

A regular for loop is more efficient than for ... of in most browsers https://jsfiddle.net/qwofaujr/

Thanks for pointing this out @mike-000. Would be glad to merge your suggestions @ahocevar, but see you already created a new PR and merged the fix for this into main in https://github.com/openlayers/openlayers/pull/13165. Thanks for your quick response both, my app will be much happier come next release :)


Diff Rummager and Content Store mainstream browse content

We recently switched from using Rummager to using the Content Store to populate mainstream browse pages.
This has caused some old pages to start resurfacing because of some mainstream content having not been untagged in content store, and just removed from search.
This rake task searches for all mainstream browse pages, and then finds any mainstream content reported by the Content Store, and not by Rummager (and vice versa).
Trello
https://trello.com/c/TcWCXN1B/457-fix-bug-with-old-content-reappearing-on-topic-browse-pages

@tijmenb I've added the topic checks. Results on int:
mainstream_browse_pages: https://deploy.integration.publishing.service.gov.uk/job/run-rake-task/1277/console
specialist_sectors: https://deploy.integration.publishing.service.gov.uk/job/run-rake-task/1278/console
It looks like there's a lot of missing pages for topics. Should we revert?
cc @suzannehamilton

@tijmenb @suzannehamilton I've run the Rake task on int and come up with the following results:
mainstream_browse_pages: 152 paths in Content Store, not found in Rummager; 1 path found in Rummager, not found in Content Store
specialist_sectors: 754 paths in Content Store, not found in Rummager

Good stuff. We've reverted https://github.com/alphagov/collections/pull/274 so that we can look at these issues later.


Show all .bin files in dir as options, including names?

Currently, the tool just shows two selections, "Flash MicroPython" and "Flash Kano Code", where each is tied to hardcoded filenames.
If I understand it right, flashing a newer version of MicroPython would require either overwriting the existing pixel32-v0.1.0.bin file (which is confusing since then the filename's version number doesn't reflect the actual version), or editing the source to change the filename.
Instead, could you change the tool to just scan the firmware directory, and offer all the .bin files in it as individual items in a selector? Or alternatively, use a "Browse" button with which the user can select the file to flash.
That way, when there's a new MicroPython release for the Pixel Kit, users can just download it from the project release page and drop it in the firmware directory (or browse to it in the flash tool). I think that would be more flexible and intuitive, and also reduce the work needed for publishing new releases - there's no need to change the flash tool each time that way.

He, @klausw !
Regarding the confusion about version numbers, I believe you just found a serious bug due to my manual build process... Excellent argument for prioritising setting up automated builds 👍 !
I believe the best solution will be checking and downloading the latest firmware as part of the "flash MicroPython" process. This way we don't need to add a step to select which firmware to install as this might scary the people this tool is initially designed for.
I believe I will need to keep updating the tool with the latest firmware as it's released in case someone downloads it but plan to use on an offline environment (this is an important scenario to cover, probably one of the most important, actually). But I'm sold on the idea that it must happen automatically.

If you are looking at a more complete, flexible yet still friendly way to flash your Pixel Kit I can't recommend this project enough. If you are not afraid of command line, perhaps even the esptool itself?
Would that solve your use case?
All you will need to do is to find/build a suitable firmware of MicroPython (or LUA, javascript, BASIC, etc) and flash it to your Pixel Kit!
I do want to improve the flasher tool but I also think I'd like to keep it as simple as possible in terms of UI (2 or 3 obvious clicks) and 100% offline.


wip: update(build): fix build with system libs

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug
Any specific area of the project related to this PR?
/area build
What this PR does / why we need it:
Together with https://github.com/falcosecurity/libs/pull/142, it allows to build falco using system libraries.
gRPC cmake module needed to be fixed in libs, while in falco we needed to properly link GRPC_LIBRARIES and CURL_LIBRARIES.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

update(build): libs updated to...? TDDO

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: FedeDP
To complete the pull request process, please assign leogr after the PR has been reviewed.
You can assign the PR to them by writing /assign @leogr in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

Closing the PR: wrong solution proposed.


Windows - rescan make to loose the logo in the progress screen.

happen in a couple of screens... when you change to another wallet...


Remove hibernate validator to make sure that JVM can optimize the code to acquire the extreme performance

hibernate validator is very helpful, but we need to remove it gradually to acquire the extreme performance.

Note:
Don't use the following assertion code style because it will copy the reference of "myvar" and degrade performance:
public Mono<Long> anything(@NotNull myvar)
        return Mono.defer(() -> {
                Assert.notNull(myvar);
                ...run the business logic
        });


Display number of not imported lines

It would be useful, if the status bar would show the number of lines in the log
file, which are ignored because they could not be parsed with the logimporter.
With this you could easily check, if you took the wrong importer or if someone
logs with wrong format to the logfile.

Even more comfortable would be, if the unparseable lines would show up in the
table (message column) or an additional tab sheet.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 16 Jan 2012 at 11:23

If log line is not parsed it will be merged with previous log event (as message)


[Bug]: npm package JS missing sources and over-transpiled?

Bug expectation
I needed to debug some behavior between DevTools frontend, the lighthouse panel, the Puppeteer connectionservice and then CDP connection mgmt within pptr. (Again.. we're in the devtools frontend)
Bug 1: I expected sourcemaps to work for stepping through pptr code. It didn't. The NPM package does have sourcemaps, but not original sources (either as files or sourcesContent). So.. instead you just see an awkward 404 page in Sources tab.
I can repro the same problem just debugging w/ node via Chrome DevTools.

FWIW if I just put the .ts sources files from the repo in the correct file location (my devtools out/ at least), this worked. So I suspect the fix for the NPM package is easy enough as including them in the publish.
"Bug" 2: I then turn off sourcemaps in devtools. I can see the JS sources now.. but they're overtranspiled IMO. In particular, all the private fields have __classPrivateFieldGet invocations.. Those make it so messy its very hard to read the code enough to follow it.

I attempted to fix this by playing with the typescript configuration but failed. I don't know your node support policy but private class fields are pretty green at this point. (They're definitely solid in browsers)
Bug behavior

[ ] Flaky
[ ] PDF

Minimal, reproducible example
const puppeteer = require('puppeteer');
console.log(puppeteer); throw new Error('😩');

Error string
😩
But actually.. a repro:
For the sourcemaps issue...
create a new folder. npm init -y. Copy examples/search.js into there. node --inspect-brk search.js  set a breakpoint on the .launch() line. Step in there.

Puppeteer configuration
No response
Puppeteer version
20.7.2
Node version
19.6.0
Package manager
npm
Package manager version
9.4.0
Operating system
macOS

"over-transpiled" sounds like https://github.com/puppeteer/puppeteer/issues/10170 ? (e.g., https://github.com/puppeteer/puppeteer/issues/10170#issuecomment-1547519545)


Text size is missing a 6th size for parity with existing tile/toast notifications

Tiles/toasts have six sizes... right now the schema has only 5. It's missing a largest "Huge" size
Small = caption
Normal = base
Medium = subtitle
Large = title
ExtraLarge = subheader
?????????? = header

Call it display - the Bootstrap does this:
The version of headers dedicated to stand out from display:
https://v4-alpha.getbootstrap.com/content/typography/


grafanaImage change breaks when repository on custom port

What happened?
Change introduced in PR breaks when parsing image repositories which are using custom ports.
Images of the form dockerrepo.example.com:5000/grafana/grafana:8.1.1 are incorrectly parsed and result in a deployment manifest with image: dockerrepo.example.com:8.1.1
The change is splitting on all ':' characters (line 46) and selecting the first field. Correct parsing would split on the right-most ':' and then select the first field.
Did you expect to see some different?
A properly parsed image value would result in a deployment with image: dockerrepo.example.com:5000/grafana/grafana:8.1.1
How to reproduce it (as minimally and precisely as possible):
local kp =
  (import 'kube-prometheus/main.libsonnet') +
  {
    values+:: {
      common+: {
        images+:: {
          grafana: 'dockerrepo.example.com:5000/grafana/grafana:8.1.1',
        },
      },
    },
  }

kp.grafana['deployment']

Environment

Prometheus Operator version:
release-0.9

Kubernetes version information:
v0.49.0

Kubernetes cluster kind:
insert how you created your cluster: kops, bootkube, tectonic-installer, etc.

Manifests:

local kp =
  (import 'kube-prometheus/main.libsonnet') +
  {
    values+:: {
      common+: {
        images+:: {
          grafana: 'dockerrepo.example.com/grafana/grafana:8.1.1',
        },
      },
    },
  };

kp.grafana["deployment"]

Prometheus Operator Logs:

N/A

Prometheus Logs:

N/A
Anything else we need to know?:

An inelegant but functional fix:
      imageRepos+:: {
        grafana: std.join(":", (std.reverse(std.reverse(std.split(g._config.image, ':'))[1:]))),
      },

Closing since #1450 has merged


Change font of text on arrows inside "edge" object

From discussion here:
https://groups.google.com/forum/#!topic/wavedrom/THreH-zNU7A

I have just started using Wavedrom. Its really good..
I want to increase the font size of the text inside the "edge" option. Is that possible..?
I tried to use something like  'd->q ['tspan', {class:'h6'}, 'sometext ']',

I kinda have the need for font size request for the edge text as well. Sometimes they are just too small.

bumping issue

There is an acceptable solution. "Export SVG..." then change the svg file, add "font-size" to the tspan label.
before:  <tspan>5ns</tspan>

after: <tspan style="font-size:13px" dy="1.4">5ns</tspan>


Add trace id to logs

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


[Request] Set font

Hi,
would be nice if we can use a sort of draw_set_font, maybe, scribble_set_font function.
At the moment the only way to change the font is inside the text but when you pass from a language to another maybe is much more easy to use a function than add in all text the selected font.
Thanks

You can use the global.__scribble_default_font variable to set the default font when creating a new scribble, or if you prefer, write a script that does it for you. Changes will only apply to newly created scribbles, though. Alternatively you can write a script to automatically append the [font] tags to the beginning and end of the string, which would cause the default font to appear to change on-the-fly.

Thanks for your feature request!
Dragonite raises a couple good points. Writing a custom script that wraps around scribble_draw() and prefixes the desired font is what I'd expect most people would do; however, this does mean that [] won't neessarily reset the font as you'd expect.
It certainly is possible to set global.__scribble_default_font, though I wouldn't necessarily expect people to work that out for themselves. Doing this has the advantage that the dev can then use [] and it'll reset the font to the default.
I prefer this second solution so I propose making a function that handles the variable swapping for the user. When it comes to handling caching, it's just a case of adding the current default font to the cache string.
Funnily enough, I did originally have a function to set the default font, but I ended up stripping it out for the sake of simplicity!

In 6.0.2.pre


(iOS) Undesired scroll bounds/limits when keyboard is up (ionic-exclusive?)

When I have a long page with text input fields (long enough to scroll a decent amount)

If I select an input near the bottom of the page I am unable to scroll all the way up.  (Or vice-versa.)

After being denied scrolling all the way up (or down) once, it then lets me scroll the full length of the page.

Environment
iOS 12.2 (iPhone X emulated), 13.3.1 (iPhone 6s real), 12.4.5 (iPad mini 2 real)
slightly modified ionic tutorial project
cordova-plugin-ionic-webview 4.x
Investigation

When using cordova-plugin-ionic-webview 4.x on a pure Cordova project it is fine.

Maybe (quite possibly) I just don't know what I am doing with ionic and missed a configuration option or something

When I install cordova-plugin-ionic-keyboard this issue disappears

NO cordova-plugin-ionic-keyboard
See how the app apparently thinks I've reached the top on the first attempt at scrolling
The Bug Video
WITH cordova-plugin-ionic-keyboard
See how the app lets me scroll all the way on the first try
The not-so-bug Video
Thoughts
Is cordova-plugin-ionic-keyboard maybe just covering up the issue?

I say this because when cordova-plugin-ionic-keyboard is included, the keyboard pops up, but the content does not shift up, (and unfortunately the keyboard covers the selected input).

Maybe the content shifting up a bit throws off the scroll bound limits somehow

Maybe this is related to the shmorgishborg of issues surrounding this issue?  Though this focuses on keyboard dismissal issues... not keyboard pop-up issues

The shmorgishborg has been slightly documented in PR #533

Not sure why it only happens on an ionic project and not a cordova one.  :/

Is this just me? (If so don't worry about this issue, because I have no intention of actually using ionic. :p)  (Just curious because I was working on related stuff)
Any ideas?

i have the same problem


support registering custom type mappings

It seems like in order to allow seamless consumption of elements written in JavaScript, there needs to be a way to register unknown JavaScript types so that they are converted to Dart objects.   There's probably a relationship here to custom-element-apigen too.

cc @jacob314

Similar to how @CustomElementProxy works but that is just for elements, I assume what you want here is a general purpose thing for any JS Object?

Correct.  If users can register type mappings for any JsObject, then on the Dart side, anything that can comes out of Polymer can be converted to a Dart object instead of JsObject.  If this is done when someone wraps a JavaScript element in custom-element-apigen, then no-one who uses that element should have to know it's a not natively Dart.  I think :)

Also, I'm not sure, but the new js interop may remove the need for this.

Here's an example of what this case should look like like with the new JS interop.
There is no proxying or wrapping. Essentially you define JavaScript interfaces specifying the shape of the JavaScript API you want to access from Dart and then you can access that interface on any JavaScript object passed to Dart where DOM objects are considered JavaScript objects.
import 'package:js/js.dart';

@Js
class AwesomeCustomElement {
  // all methods must be external.
  external someAwesomeMethod(foo);
  external String get someAwesomeGetter;
}

void main() {
  AwesomeCustomElement element = querySelector(#yourElementId");
  element.someAwesomeMethod("hello");
}


Added a new api

Added creepernation skin api

just out of curiosity, what makes it better then the existing tydium api?

just out of curiosity, what makes it better then the existing tydium api?

I’m not going to say better because every api has its own thing but we are going to have feature never seen before this api is not the same I’d suggest you talk to blue @bluetree242

Our up time is doing well incase your wondering  https://hetrixtools.com/r/d1539367bbd131746b9d387c118e0f5b/ tracked since 21 september (excluding geyser api)

If you’re going to propose a new API, it’s not upstreams job to chase someone else on what it does that the existing one doesn’t already do.

Both APIs existed for a while, it's not new

It’s new to the project

And unless you had permission from both GeyserMC and Tydium, I really wouldn’t recommend setting up uptime monitors for their endpoints.

It’s new to the project

No not really it was private for awhile I mainly used it for my server

If you’re going to propose a new API, it’s not upstreams job to chase someone else on what it does that the existing one doesn’t already do.

tydiumcrafts api does it’s own thing my api has its own set of features to make it different from the others

If you’re going to propose a new API, it’s not upstreams job to chase someone else on what it does that the existing one doesn’t already do.

tydiumcrafts api does it’s own thing my api has its own set of features to make it different from the others

And they are?

If you’re going to propose a new API, it’s not upstreams job to chase someone else on what it does that the existing one doesn’t already do.

tydiumcrafts api does it’s own thing my api has its own set of features to make it different from the others

And they are?

I’ve said it in the repo but we have more private features we aren’t finished coding but one of them will be Catcha another will hopefully solve an issue that fixed it so the apis not only for geyser I can’t revealed anything more

I’ve got to go for now but I’ll be back

And unless you had permission from both GeyserMC and Tydium, I really wouldn’t recommend setting up uptime monitors for their endpoints.

Yeah I never really even gave permission for that lol…

With this I'll lock the conversation. project leads will review this and merge it upon approval.


Fix missing quantity & settlement price for handleLoanDebtTransferred1024

Retrieve quantity from onchain storage.
Calculate settlement price based on transaction amount divided by quantity.


Table: toggleTreeExpansion

Please make sure these boxes are checked before submitting your PR, thank you!

[x] Make sure you follow Element's contributing guide (中文 | English | Español | Français).
[x] Make sure you are merging your commits to dev branch.
[x] Add some descriptions and refer relative issues for you PR.
Closes #16301

@yyjjqq94 解决一下冲突。

@yyjjqq94 解决一下冲突。
ok


Clarify interactions with GraphsOptim.jl

Hi there, and congrats on the new package!
I'm one of the JuliaGraphs maintainers, and we've recently started to regroup all graph algorithms that require heavy dependencies (such as ILP solvers) inside a package called GraphsOptim.jl. It is dormant until I have some more time, but you might want to check out our discussion about it in this issue. It may be useful to you if you want to avoid duplicating code. Of course, we would also be interested in contributions :)

Hey, thanks! And thank you for bringing up GraphsOptim.jl. I was unaware there was anything in development like that. Does something like GraphInvariants.jl look like it would fit into your vision for GraphsOptim.jl?
A lot of the invariants we’re implementing are using ILPs, but long-term I was thinking about including as many different solution methods as possible, since a lot of the ILPs aren’t viable on large graphs.
I’m happy to contribute and would love to get more involved in the Graphs.jl ecosystem.

Basically, the idea was to put all lightweight (combinatorial) algorithms in Graphs.jl, and all the LP-based ones in GraphsOptim.jl. This is on standby for now, but from what you tell me, it looks like GraphInvariants.jl could be split between both packages?

Our goal is to provide an interface that’s as simple as possible for students and researchers to calculate graph invariants, so to that end I’m a bit unsure about splitting things up. At the same time, I’d like do what’s best for the Graphs.jl ecosystem.
I think for now it makes sense to continue working on GraphInvariants.jl as planned, if only to have a repository that catalogues several different algorithms, and especially since we’re planning to have our initial goals completed in the next few weeks. But I’m keen on keeping the dialogue open so that we can figure out the best way to move forward with Graphs.jl and GraphsOptim.jl
I’d be thrilled to see this work eventually end up in the more official packages! I’ll keep this issue open for now, and if there are any other conversations that would be beneficial to be a part of, please let me know.

Deal!


Database/firestore

fixes #17 and fixes #16

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


In Progress: Refactor for Registration page

In progress: LNBits iframe not copying invoice address to clipboard.
Requires LNBits API Key
https://plebdev-website-git-registration-amsalmeron.vercel.app/Indiv

@amsalmeron maybe I did not communicate this correctly, but the BOLT 11 can be done on the following page after they click on Submit, if the modal is giving you problems. having an embed might not show up too well on the page. I haven't dived into the code, but this just my observation from the vercel deploy

Also be sure to consider mobile usage and how it displays on mobile.

MVP is created.
Lightning invoice is created on load of form, and user is routed to sats pay invoice link upon submit. Let me how y'all feel about the workflow. Should be able to include the invoice directly on page / modal, and make get request on invoice to ensure payment is complete.
https://plebdev-website-e67x62ndb-amsalmeron.vercel.app/

@amsalmeron Link works, although you can just submit the form without any validation e.g. * Fields should be validated
Otherwise, link works. Either BOLT11 on page embedded, similar to https://plebnet.dev/donate page or on modal should be fine, as long as it looks good on mobile.

@bliotti if you get a chance - please see this

@amsalmeron we took a look, I'm having @bliotti rework this PR so that we can move to production asap.

@amsalmeron @bliotti How's this PR coming along?


How to deal with java.net.SocketTimeoutException

when i use the library to make to request,but the server cause java.net.SocketTimeoutException,if I want to deal with it by myself , but  which method where be called?
can not connect terminal net  onFailure
java.net.SocketTimeoutException
can not connect terminal net  onFailure
org.apache.http.conn.ConnectTimeoutException: Connect to *** timed out

when i use my company's wifi i got the same problem

i think u can set the var DEFAULT_SOCKET_TIMEOUT to a bigger number in class AsyncHttpClient

thanks

SocketTimeoutException will be handled by library and callback will be received in onFailure method


perlPackages.SQLTranslator: fix some scripts issues

Motivation for this change

perlPackages.SQLTranslator: shorten long shebang
The long shebang was causing troubles for running the Perl scripts on
both Darwin and Linux. This seems to solve the issue on Perl 5.32,
but the scripts remain broken on Perl 5.34.

perlPackages.SQLTranslator: add missing dep
This adds a missing dependency for the sqlt-graph script provided in
the SQLTranslator package.

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"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 131414 at 60d8c34c run on aarch64-linux 1

6 packages built successfully:

perl532Packages.DBICxTestDatabase
perl532Packages.DBIxClassDynamicDefault
perl532Packages.SQLTranslator
perl534Packages.DBICxTestDatabase
perl534Packages.DBIxClassDynamicDefault
perl534Packages.SQLTranslator

The shebangs in the scripts are set to #!/nix/store/.....coreutils-x.xx/bin/env perl this might be the reason why they appear to fail on perl 5.34.
Adding patchShebangs might resolve the problem you're seeing.
    postPatch = ''
      patchShebangs bin
    '';

PS: Try it without shortenPerlshebang, it might only be needed on Darwin.

On Linux, with only patchShebangs, without shortenPerlShebang:
❯ nix build .#perl534Packages.SQLTranslator
❯ ./result/bin/sqlt-diagram --help
/nix/store/nvlnl2swxmk50x25mzn71rhc0gzpylfr-coreutils-8.32/bin/env: ‘perl -I/nix/store/y29hhfh2gjmiagdanzywabjbd2y4g79c-perl-5.34.0/lib/perl5/site_perl -I/nix/store/03af9jbrywvrkd1vcjv6hcna4qlx4aw3-perl5.34.0-File-ShareDir-Install-0.13/lib/perl5/site_perl’: No such file or directory
/nix/store/nvlnl2swxmk50x25mzn71rhc0gzpylfr-coreutils-8.32/bin/env: use -[v]S to pass options in shebang lines

On Linux, with both patchShebangs and shortenPerlShebang:
❯ nix build .#perl534Packages.SQLTranslator
❯ ./result/bin/sqlt-diagram --help
Can't locate SQL/Translator.pm in @INC (you may need to install the SQL::Translator module) (@INC contains: /nix/store/y29hhfh2gjmiagdanzywabjbd2y4g79c-perl-5.34.0/lib/perl5/site_perl /nix/store/03af9jbrywvrkd1vcjv6hcna4qlx4aw3-perl5.34.0-File-ShareDir-Install-0.13/lib/perl5/site_perl /nix/store/pssx0kzw5cfvf8ph9fbwsywx6jwda2cr-perl5.34.0-JSON-MaybeXS-1.004003/lib/perl5/site_perl /nix/store/ixbhwbwfwkhja1705mdy44pbq2z24wg2-perl5.34.0-Test-Differences-0.67/lib/perl5/site_perl /nix/store/mzix90bpyscj2mp5y5wwi2klysw0a4yp-perl5.34.0-Capture-Tiny-0.48/lib/perl5/site_perl /nix/store/n0lkl84czhgqc7b44ib33szkyh9slgcb-perl5.34.0-Text-Diff-1.45/lib/perl5/site_perl /nix/store/9xx0i68ipw55byjy1d57s6fyx16cyp02-perl5.34.0-Algorithm-Diff-1.1903/lib/perl5/site_perl /nix/store/9ndic1b2v9104f4hxxp72mh37cmkqk31-perl5.34.0-Test-Exception-0.43/lib/perl5/site_perl /nix/store/giii2g0n31s5q7ji046jxxxfzg7f3v0l-perl5.34.0-Sub-Uplevel-0.2800/lib/perl5/site_perl /nix/store/mspl4xlznw7mz7m66xkxrk1y67if696f-perl5.34.0-XML-Writer-0.900/lib/perl5/site_perl /nix/store/fppqx5am25qfc730q91iw0qyzbnf0v05-perl5.34.0-YAML-1.30/lib/perl5/site_perl /nix/store/2x9m86yfm2k15byn7lg3f2q8ii8h8mi3-perl5.34.0-Carp-Clan-6.08/lib/perl5/site_perl /nix/store/y9r3zcgsl108xn5m8dd4fmg48pv0ymkh-perl5.34.0-DBI-1.643/lib/perl5/site_perl /nix/store/dkn0xhk61vbn6hpaqcs7p10h5y3ky707-perl5.34.0-File-ShareDir-1.118/lib/perl5/site_perl /nix/store/7hb7n294k4fwsjmf2vrqac0zsdcy9haz-perl5.34.0-Class-Inspector-1.36/lib/perl5/site_perl /nix/store/67g6lxisvx13rzz860yaikl79iplf1f8-perl5.34.0-Moo-2.004004/lib/perl5/site_perl /nix/store/2lmclwbwrz68x6d6dzrw4i3qjqvliprn-perl5.34.0-Class-Method-Modifiers-2.13/lib/perl5/site_perl /nix/store/2y3q96wcg2n6zcx9imvmapzp94qz41kb-perl5.34.0-Module-Runtime-0.016/lib/perl5/site_perl /nix/store/kp1104m3lcgnln3r1rz52akm0pf1vw9i-perl5.34.0-Role-Tiny-2.001004/lib/perl5/site_perl /nix/store/7azh3vjcmkdi6v52l88hh0hifz2myfkg-perl5.34.0-Sub-Quote-2.006006/lib/perl5/site_perl /nix/store/8ia7kyw5cfbbg814idya82r53pdlia5v-perl5.34.0-Package-Variant-1.003002/lib/perl5/site_perl /nix/store/fl84lfrvgsdrzm5xwbvh186y2bgy4r7d-perl5.34.0-Import-Into-1.002005/lib/perl5/site_perl /nix/store/8hwhaw5hsna4zmnq2vga2yfkm8hyzc6l-perl5.34.0-strictures-2.000006/lib/perl5/site_perl /nix/store/yajrawq7xxaxkpl8m8h3pzwkal9lmlx4-perl5.34.0-Parse-RecDescent-1.967015/lib/perl5/site_perl /nix/store/qjiynfaib7r941bap6jy93vbgampwwcs-perl5.34.0-Try-Tiny-0.30/lib/perl5/site_perl /nix/store/359i4xgm74hvl5rwhh4brp4356h91lqn-perl5.34.0-GraphViz-2.24/lib/perl5/site_perl /nix/store/j5dd7pifpqjxf812cm462j5gna9x8b5f-perl5.34.0-File-Which-1.23/lib/perl5/site_perl /nix/store/b325k3cw8kig2wvnpw4zk234zb6fska1-perl5.34.0-IPC-Run-20200505.0/lib/perl5/site_perl /nix/store/9b3ghpfwh38aqf042a0l04n3vdf9vazx-perl5.34.0-IO-Tty-1.15/lib/perl5/site_perl /nix/store/p6ajchakms9rm4j62g4yfb3aqh3zqssq-perl5.34.0-XML-Twig-3.52/lib/perl5/site_perl /nix/store/9nr4drhi9110a544ag6xbijbz6w9bby6-perl5.34.0-XML-Parser-2.46/lib/perl5/site_perl /nix/store/rk7q85mryrwv0qcyx10qvy2qx0s76xyx-perl5.34.0-libwww-perl-6.49/lib/perl5/site_perl /nix/store/m292qqzzzaj9hrmpidl6972zsaavqbqi-perl5.34.0-File-Listing-6.14/lib/perl5/site_perl /nix/store/37njap8i5mmflzyp4msgkmqwb6rlj1sq-perl5.34.0-HTTP-Date-6.05/lib/perl5/site_perl /nix/store/hrh82rg7fpxa85dlp9l3llm71pzay0dj-perl5.34.0-TimeDate-2.33/lib/perl5/site_perl /nix/store/rq5xzi0rsp3q8v6kqdw806pb0gzfr35f-perl5.34.0-HTML-Parser-3.75/lib/perl5/site_perl /nix/store/14nx9wmizvsl024v65r2zw3fsv8a5aga-perl5.34.0-HTML-Tagset-3.20/lib/perl5/site_perl /nix/store/h28y7ainrfg5nlxnwj96g3amnbmiy610-perl5.34.0-HTTP-Message-6.26/lib/perl5/site_perl /nix/store/80yqyx7vnxa3par83lvrw0njw4dx3d36-perl5.34.0-Encode-Locale-1.05/lib/perl5/site_perl /nix/store/y7fahdp1kbh7s0bk7vcmyhjrvlv1bk0x-perl5.34.0-IO-HTML-1.004/lib/perl5/site_perl /nix/store/3nwb37n7ffjvw8bcv3z63alz7xfggn28-perl5.34.0-LWP-MediaTypes-6.04/lib/perl5/site_perl /nix/store/w0a7vcg03ihgv3cxclp3qjij59ixwy57-perl5.34.0-URI-5.05/lib/perl5/site_perl /nix/store/jgjvdnswg8k6xbq3illk8m38103jlb6w-perl5.34.0-HTTP-Cookies-6.09/lib/perl5/site_perl /nix/store/qixgmaa7kfrdgdap5m8mqgplisy43w08-perl5.34.0-HTTP-Daemon-6.01/lib/perl5/site_perl /nix/store/8s0b48rpwvaidn52x0vp2vpfqr2qj5s1-perl5.34.0-HTTP-Negotiate-6.01/lib/perl5/site_perl /nix/store/5834z3dbsbmjcr9crfk8z64rpxp0svp3-perl5.34.0-Net-HTTP-6.19/lib/perl5/site_perl /nix/store/bb2hkalggi4v5ckcammf44751msvn2vj-perl5.34.0-WWW-RobotRules-6.02/lib/perl5/site_perl /nix/store/jpnj50b18cs5hmbgffmdyjpg4al0xfv4-perl5.34.0-XML-XPath-1.44/lib/perl5/site_perl /nix/store/vcyz8c5cmplasy1hl5wj12n9ks5h8hx8-perl5.34.0-GD-2.73/lib/perl5/site_perl /nix/store/hb9pi1awa49spy6nj3r1wnmyv2yymcll-perl5.34.0-SQL-Translator-1.62/lib/perl5/site_perl /nix/store/n7hbdyp3bsmdxy2lcxivaxnq4nv8ndv3-perl-5.32.1/lib/perl5/site_perl/5.32.1/x86_64-linux-thread-multi /nix/store/n7hbdyp3bsmdxy2lcxivaxnq4nv8ndv3-perl-5.32.1/lib/perl5/site_perl/5.32.1 /nix/store/n7hbdyp3bsmdxy2lcxivaxnq4nv8ndv3-perl-5.32.1/lib/perl5/5.32.1/x86_64-linux-thread-multi /nix/store/n7hbdyp3bsmdxy2lcxivaxnq4nv8ndv3-perl-5.32.1/lib/perl5/5.32.1) at ./result/bin/sqlt-diagram line 78.
BEGIN failed--compilation aborted at ./result/bin/sqlt-diagram line 78.

@GrahamcOfBorg build perl532Packages.SQLTranslator perl534Packages.SQLTranslator


Add information about cask install

I've found that the developer setup in unusable without doing cask install first and adding all the dependencies to load-path (which can be done automatically with cask exec emacs).
I think you have all of the dependencies (e.g. dash) installed in your profile and haven't any difficulties because of this.
Maybe I'm doing something wrong and we need to discuss that a bit.

Hm...  I didn't even think about it, because of having the dependencies installed, yes. Thank you very much! Let me review the changes...

Everything else looks ok for me. Thanks!

Ok, looks good. Thank you very much mr @ForNeVeR.


feat: contains and containsItems [DHIS2-16211]

This PR adds two expression functions:
contains(expr, ...) returns true if the first expr contains each of the following expressions as a substring.
containsItems(expr, ...) returns true if the first expr is split into tokens separated by commas, and each of the following expressions exactly matches one of the tokens.
See DHIS2-16211 for more details and examples.
@jbee Note that in ExpressionGrammar.kt the grammar is defined as:
        fn(NamedFunction.contains, expr, expr, expr.plus()),
        fn(NamedFunction.containsItems, expr, expr, expr.plus()),

I wanted to require two expression arguments and then have optional additional expressions. But this seemed to result in no expressions required, essentially the equivalent of:
        fn(NamedFunction.contains, expr.plus()),
        fn(NamedFunction.containsItems, expr.plus()),

As a result, these functions can be called with no arguments. Then when ExpressionFunctions contains(values: List<String?>) and containsItems(values: List<String?>) refer to values[0] they generate an IndexOutOfBoundsException, as is tested for in ContainsTest and ContainsItemsTest. I did not try to fix this because I didn't know how you would want to address the problem.

@jimgrace @jbee I have changed the base branch to beta just to trigger a beta build instead of a production build (there is no production release yet for the mulitplatform library).

Closing if favor of #51 (I did not find how to make a PR to your PR without needing write access to your fork so I made a new PR)


Standardize validation error text across target languages?

Spin-off from https://github.com/smithy-lang/smithy-dafny/pull/582#discussion_r1773676073
Polymorph generally evaluates constraints "on the client side", i.e. in the target language rather than the source language. That means unlike with a real microservice, the exact error messages can be different.
On the one hand, we've seen any variation can be cause for alarm when trying to assert that a polymorphed library behaves identically to the original: https://github.com/smithy-lang/smithy-dafny/issues/362
On the other hand, having the validation in each target language means the error text can be slightly more tuned to that language, which is better UX: "The full_name field must be set - call .set_full_name(...) on the builder" (using e.g. Rust terms and concrete symbols) as opposed to "The FullName member must be present" (generic validation on the server side, has to use generic Smithy terms)

Relevant: Smithy now includes a built-in error shape for validation exceptions, smithy.framework#ValidationException. See https://smithy.io/2.0/tutorials/full-stack-tutorial.html#generating-the-server-sdk


PUD-541:  Add dossierCreatedByUserId to Recall

The purpose of using an Auth token is to identify/authenticate the user making the request so passing a user ID doesn't make much sense to me ; especially since you can pass anything you want (there's no validation). I can see all kinds of issues popping up because of this...

Yes 100% agree.  However at the moment the auth token does not contain the UUID we want to use, so we decided for now to just pass through from the UI as it already has access to the UUID to keep things simple.   Definitely not the long term solution, hopefully the dps_tech_team will add the UUID to the token soon (ticket has been raised) and we can review these stories, and also hopefully put some proper auditing of user actions in place

The purpose of using an Auth token is to identify/authenticate the user making the request so passing a user ID doesn't make much sense to me ; especially since you can pass anything you want (there's no validation). I can see all kinds of issues popping up because of this...

Yes 100% agree. However at the moment the auth token does not contain the UUID we want to use, so we decided for now to just pass through from the UI as it already has access to the UUID to keep things simple. Definitely not the long term solution, hopefully the dps_tech_team will add the UUID to the token soon (ticket has been raised) and we can review these stories, and also hopefully put some proper auditing of user actions in place

I think it would have been simpler and safer to make a request to the Auth service to get the user ID rather than introduce new fields which means changing the contract + passing on changes the clients. Also it's introducing a dependency on another team (which we said we wouldn't do) ; we aren't even sure how much effort it is to include the user ID to the access token.


Windows syscall adapters

Set up some code organization to pave the way for @compnerd's awesome Windows support work.

@compnerd I can add you as a reviewer now. I'll let you decide if you want to merge this, or take the code into your own PR. Either way is fine with me.

@milseman - lets just merge this since its ready; I'm sure that I'll end up with more changes in the future :)


Update Java and Libcamera Packages

Update the naming of libcamera-apps-lite to rpicamera-apps-lite.
Update to openjdk 17

Can you instead make a PR to both the arm64 and gloworm-arm64 branches? We use those to build normal pi and LL images. Also rebase both the branches against upstream


could I use this package for inline on-the-fly keboard?

hi.
I want to show data to user by some inline keyboard like this
does this repo support it?

Yes. Just pass the appropriate array according to the bot api docs into your desired method, e.g. sendMessage. I think something like this will work:
$api->sendMessage([
    'chat_id' => ...,
    'text' => '...',
    'reply_markup' => json_encode(['inline_keyboard' => [
        [['text' => '...', 'url' => '...'], ['text' => '...', 'callback_data' => '...']],//first row
        [...],//second row
    ]),
]);


use cases for value_of/values_of

Sorry to keep opening issues, and this may indeed be more of a question because I've missed something, but what are the intended use cases of value_of/values_of? In particular, I notice that this is part of its contract:

This method will panic! if the value contains invalid UTF-8 code points.

(Pedant: I think this should say "invalid UTF-8." There is no such thing as a "UTF-8 codepoint.")
Since the value is typed by the user, this means that the user can cause your program to panic if you use value_of/values_of when the user gives a value that isn't valid UTF-8. In my view, if an end user sees a panic, then it ought to be considered a bug. If my interpretation is right, then that means I should never use value_of/values_of, right?
I do see one possible use case: if a caller disables the AllowInvalidUtf8 setting, then I believe clap will return a nice error if it detects invalid UTF-8, and therefore, value_of/values_of will never panic. However, according to the docs, AllowInvalidUtf8 is enabled by default, so this seems like a potential footgun.
(This is a good instance of the pot calling the kettle black because docopt.rs, for example, can't handle invalid UTF-8 at all! :-) So clap is already leagues better in this regard.)

No worries, so far all the issues you've written have been superb and are pushing great things! Keep them coming!
I think you're absolutely correct in that reasoning, and I actually agree the StrictUtf8 should be the default, where the users actually opt-in to allowing invalid UTF-8, at which point they're also conscious that they should be using the value[s]_of_os instead.
I can't remember exactly, but I believe my reasoning behind making invalid UTF-8 allowed by default was....whelp no I can't remember. I know I had a reason though! Maybe it was prior to adding the value[s]_of_os? Oh well...
Changing that default is technically a breaking change, although like Rust I do believe some breaking changes should be allowed if they fix [logic] bugs, prevent security holes, or otherwise correct other unsound behavior. It should be simple to at least find github users who have used the value[s]_of_os and know to what extent this change would cause. I know that's not the whole sample, but should at least give an idea.
Thoughts?
Changing the docs is a quick fix too :wink:

Ok, so on Github there are actually more than I thought using the value[s]_of_os methods. Probably more than I'd feel comfortable switching the default. It's roughly ~30 uses, which is totally possible to contact all of them and warn them of the change. What scares me is that there's ~30 on github, but I have no idea how many in all the other places with no way to warn them. This may just have to wait for 3.x :cry:

I think it's perfectly fine to wait for 3.x FWIW. It does feel like a bit of a sneaky breaking change to try to sneak it in into a minor bump. I also think making StrictUtf8 the default is a good solution given the current API too.

One thing to consider though is this fact: if I'm writing a CLI tool on Unix and my tool accepts file paths as arguments, then I probably always want to allow invalid UTF-8 because I'm otherwise preventing my tool from working on all file paths. This is kind of a bigger picture question to answer that's probably out-of-scope for a small footgun, because it means putting UTF-8 handling front and center, which obviously sacrifices a bit of ergonomics. It's a hard line to walk.

Exactly, I wouldn't make a change like that unless I could reasonably sure it either breaks no code or I was able to contact the majority (if not all) users of said feature to get their approval first. And in this case I don't think that's reasonable.
I have been thinking of a 3.x for a while now, so hopefully the wait won't be too long! :)

I've tried to fix panics in Cargo (w/clap 2.x), but Cargo frequently uses such pattern (and its match equivalent):
if args.value_of("arg") == Some("value")

Changing it to value_of_os/value_of_lossy requires mapping/unwrapping and makes it longer and less readable.
Perhaps it could be fixed at the source, by changing definition of arguments? Currently app.arg() doesn't define the data type it expects.
How about having app.arg_os() or app.arg_path() that would force use of value_of_os/value_of_pathbuf? And app.arg() (or app.arg_str()?) would reject non-UTF-8 arg.

It does seem like the vast majority of non-utf8 offenders in CLI args are filesystem paths, and otherwise there's little sense to be on guard against invalid utf-8, correct? Maybe introducing some sort of path-specific getter (as described in #1723 for instance) is the way to mitigating the issue?

How about having app.arg_os() or app.arg_path() that would define the arg is/isn't a path, and force use of value_of_os/value_of_pathbuf? And app.arg() (or app.arg_str()?) would reject non-UTF-8 arg.

That might not be a bad idea, but it's not really feasible implementation-wise. That's just very far image from how the current implementation works; we'd have to rewrite a good part of clap for it. Maybe in next major version 🤷

Info: https://stackoverflow.com/questions/5408730/what-is-the-encoding-of-argv . And on Windows, Rust args should always be UTF-16 since it's using GetCommandLineW.
Opinion: Using value_of do introduces possiblility of panic, but the current api designed is the same as std::env::args() and std::env::args_os. So removing value_of() is unneeded. And I don't think adding new convenient functions is good for api surface's cleaness.

clap_derive is using value_of behind the scenes.  We should either switch away from value_of for the derive or fix this because this is a case where the user has no idea this is happening and don't have a choice to move away from it.

Is it planned to fix this for clap 3? It looks like the current API as of clap 3 beta 2 still panics on invalid UTF-8: https://docs.rs/clap/3.0.0-beta.2/clap/struct.ArgMatches.html#method.value_of

I assume so since its tagged with the 3.0 milestone.  At minimum, I'd like to see hidden callers use a non-panicing API (derive, value_of_t, etc), whether that involves fixing this or changing the call sites.
Options

StrictUtf8 being the default

Downside: This can't discriminate on how the arg will be used, so breaking all uses of accepting PathBuf / OsString.  Enabling support for that would then re-enable the panic

ArgSettings for invalid/strict like the similar AppSettings

Looks like we look at StrictUtf8 after we know which are we are processing, so this looks feasible
clap_derive can auto-set this
We can make this the default with a comment on value_of_os that they should unset the flag.
The question is how to have this interact with the AppSetting, if we keep it.

If someone sets StrictUtf8 at the App level, there isn't a way to opt-out at the Arg level.  We'd need a tri-state (yes, no, default).
We could keep both StrictUtf8 and AllowInvalidUtf8 to mimic the tri-state.  What to do if someone sets both on an Arg or on the App?  Unsetting a default would be different from all other settings (instead of unset, you set something different)
Its also used for external subcommands, so we'd need something for that.
This is similar to the "How about having app.arg_os() or app.arg_path()" idea before mentioned but is tying into the way clap is currently doing things

Change value_ofs signature to return an error

This ties into #2505 for whether not-present should be an error, or whether we should use Option<Result<_, _>> or Result<Option<_>, _>

I lean towards

ArgSetting::StrictUtf8 being added and being the default

value_of_os would document this
clap_derive would "do the right thing"

AppSetting::StrictUtf8 would be changed to AppSetting::StrictUtf8ExternalSubcommand and would be on by default just to keep the documentation simple

value_of_os would document this
clap_derive would "do the right thing"

There's a little bit of holistic clean up that needs to be done regarding these API methods and how they are used in derive. This is related to a few others issues too. Definitely need to be done before 3.0

@pksunkara how does my proposal sound for a path to move forward?

Based on another thread (https://github.com/clap-rs/clap/discussions/2627), By making StrictUtf8 the default, we'd need to invert its name again back to AllowInvalidUtf8

Yup. So, we basically need to change the StrictUtf8 setting in favor of AllowInvalidUtf8.

@pksunkara just want to make sure you read what my comment was associated with; its not just inverting it but also moving it from an app setting to an arg setting

Missed that, but still sounds good. This change might be a bit big for @hosseind88 though in #2623


[Feature Request] Minimized Exceptions in Terminal, Verbose Exceptions in Log File

no doubt this is a re-issue, but just wanted to show you what fills my monitor when i enable beartype. the signal to noise ratio is too low, just an infinite wall of tracebacks, sadly gonna have to turn it off
if there is a problem hidden somewhere in a class, ok, great, show us the problem, not the full traceback of bear internals please.

that's patronizing BS, because there are plenty of reasons to want less verbose beartype besides "SKILL ISSUE", like not having to scroll through pages and pages of beartype exception details to find the name of the class with a problem hidden inside (not helpful)
Is it possible to customize these exceptions so they don't show users beartype internal traceback, only the user code locations in violation of whatever? That's a dealbreaker for me, tbh, it's just too much useless details about how you're making the errors, fills my whole terminal history, I want to like beartype, any workarounds?

here's what i tried:
# ....................{ BIG BEAR                        }....................
# Warn about type hint violations in *OTHER* packages outside your control;
# only raise exceptions from violations in your package under your control.
# Again, at the very top of your "{your_package}.__init__" submodule:
from beartype import BeartypeConf  # <-- this isn't your fault
from beartype import BeartypeViolationVerbosity
from beartype.claw import (
    # beartype_all,
    beartype_this_package,
)  # <-- you didn't sign up for this

beartype_conf = BeartypeConf(
    violation_verbosity=BeartypeViolationVerbosity.MINIMAL,
)
beartype_this_package(conf=beartype_conf)  # <-- raise exceptions in your code
# beartype_all(
#     conf=BeartypeConf(violation_type=UserWarning)
# )  # <-- emit warnings from other code

...heh. Anger, huh? I was wondering when I was going to start receiving anger-filled invective. Anything that receives attention eventually receives anger-filled invective. It's a law of the Internet probably called McMurdo's Law of Anger Attraction. With @beartype on the cusp of garnering widespread attention beyond the cozy confines of the ML (machine learning) community, it was sorta inevitable that this day would dawn. And... here it is. The angry day dawned.  I pretty much lost my 30's – an entire decade – to anger-filled invective. Sadly, I was anger personified in the flesh. It was a disastrous look, a debacle of a decade, and a time I now reflect on with an upwelling sense of loss and sadness. I'm all too familiar with the emotion. As a full-blown autist with alexithymia, anger was pretty much the only human emotion I ever genuinely felt. All of which is to say...
@beartype: It Prolly Ain't for You
Like, seriously. @beartype behaviour and documentation upsets you. You're not necessarily wrong, of course. @beartype is a flawed vessel, because I am a flawed human. @beartype is human stuff. No amount of issue resolutions on my part can possibly change, rectify, or mollify the negative emotions on display here. Anger tends to be resilient to change. Anger is fixed in place.
It kinda just sounds like @beartype isn't for you. @beartype isn't here to generate anger, enhance frustration, or make the world an even worse place than the world already is. If this is happening when you use @beartype, then @beartype has failed your use case. The best (and really only) remedy is to drop @beartype from your app stack. That's what I'd do, anyway.
I have zero tolerance for software that upsets me. There's just not enough time in a single lifetime to squander on upsetting things. You're probably not too different in that respect, right? This world is upsetting enough already. It might be time for you to just "pump and dump" @beartype. That said...
@beartype: It Isn't Entirely to Blame Here
The traceback you exhibited above is a sterling example. Anger and confusion have intersected here to obfuscate the underlying issue. A good third of that traceback derives from pytest itself. Another 10% or so derives from standard importlib machinery. Neither of those things are @beartype. Right? @beartype can't do anything about either pytest or standard importlib machinery. Those things do themselves outside @beartype's purview. They're beyond us. Which is probably a good thing. You wouldn't trust @beartype to start mucking around with pytest or standard importlib machinery, would you? I wouldn't. I wouldn't trust @beartype to monkey-patch anything. And I wrote this shambolic monster.
As for the remaining 60% or so your traceback that does derive from @beartype, that's actually a good thing. Wait! Hear me out, please. I am about to say something crazy. Thankfully, crazy people are interesting. Everybody likes a show. Because...
I need tracebacks to debug @beartype. Without tracebacks, resolving issues is infeasible. That would be far worse than users confronting upsetting tracebacks – which should never happen, anyway. We're talking extreme outlier events here. Why? Because...
@beartype: It Blew Up, but You Didn't Know It
Something blew up deep inside @beartype here. Clearly, you hit something resembling a @beartype bug here.
@beartype only raises a traceback when something goes catastrophically unexpected. Because @beartype raised a traceback, something (...wait for it) went catastrophically unexpected. Unfortunately, you omitted the exception message. I can't say with any confidence what exactly went wrong here. But I surmise it has something to do with a class annotated by a type hint unsupported by @beartype. But @beartype supports pretty much all type hints. So... I'm confused and can't do very much to assist you. It is sad. Weep, sobbing emoji face! :sob:
@beartype intentionally omits tracebacks when type-checking violations occur. That covers 99.99% of the exceptions raised by @beartype. This means that 99.99% of @beartype users never see any tracebacks containing @beartype internals: e.g.,
>>> from beartype import beartype
>>> @beartype
... def fun_func(bad_arg: str) -> None: pass
>>> fun_func(b'Suck eggs, fun func!')
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    fun_func(b'Suck eggs, fun func!')
    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<@beartype(__main__.fun_func) at 0x7f453a42ad40>", line 29, in fun_func
beartype.roar.BeartypeCallHintParamViolation: Function __main__.fun_func() parameter
bad_arg=b'Suck eggs, fun func!' violates type hint <class 'str'>, as bytes
b'Suck eggs, fun func!' not instance of str.

See? No @beartype internals, right? That's intentional. Nobody wants @beartype internals in type-checking violations. So @beartype works surprisingly hard to omit @beartype internals from type-checking violations. Technically, it would be possible to also omit @beartype internals from decoration-time exceptions like the kind of exception you hit above. Pragmatically, doing so would be disastrous. If I omitted @beartype internals from decoration-time exceptions, then I'd have no means of resolving any issues whatsoever. That would be like Godzilla on Mothra all over again.
Nobody is supposed to see exceptions like the exception you are seeing. Whenever you see an exception like that from any package, your thought process should usually go something like this:

"Something blew up. This is bad. Oh, Gods. I heard shattering glass. And... was that gun shots? And I'm pretty sure I heard a small baby screaming. I don't feel angry. I feel sad and scared! Explosions are scary! I'd better report what I saw to the authorities. Oddly, that happens to be this autistic guy @leycec in this case. Whatever! The explosions, the shattering glass, the gun shots, and the small baby screaming is all that guy's problem now. I feel better. That's what matters."

In other words, @beartype users are supposed to:

(A) Be surprised by super-long tracebacks like the one you hit and...
(B) Submit them as issues to this issue tracker.

Everything's actually working as intended from @beartype's perspective. @beartype wasn't trying to make you feel wrathful anger and a desire to bludgeon @beartype into oblivion. By presenting you with an uncomfortably long traceback dredged up like a Balrog from the mines of Moria, @beartype was trying to convince you that the sky is now falling, that the five riders of the QA Apocalypse are now cavorting through your codebase, and that you should probably tell somebody about that as soon as possible so that they can fix that for you and stave off the QA Apocalypse. Right? QA Apocalypse == bad.
But you had the opposite reaction. You didn't quite grok the enormity of @beartype was trying to tell you. It probably would have helped if @beartype could have screamed. In code, only the AI can hear @beartype scream.  This assumption then led you to anger.
But the assumption itself was false.  Ergo, the anger itself was predicate on a false assumption. In other words...
Anger: What Is Good For?
Absolutely nuthin'. Anger isn't a tool. North American culture got that tragically wrong. Anger is the small death that feeds every greater demise. This is the lesson eternal:
Dev bros don't let dev bros anger.
Not even once.
       – some bald autistic guy on GitHub, probably

Observation: There is a long comment with what seems like an assumption this issue was created in anger.

Need: I, like many developers, value being able to provide honest negative feedback about developer experience without this being assumed to be angry or hostile.
Request: If this kind of experience ought to yield a structured bug report, then could it be possible for beartype to output the verbose tracebacks to an error log file and provide guidance about the best way to upload that error log file to a github issue? I'd be glad to share the logs but they literally took up my entire terminal history, impossible to copy them all here, not to mention it's a private repo, how do we balance these objectives productively?
I sincerely apologize if I made you feel like I don't appreciate your work on your project. It just didn't work the way I tried to work with it. That doesn't mean it's a bad project or is broken, just means, maybe it's a sign to guide folks more gradually into the land of beartype (like instead of guidance to enable beartype broadly for whole projects, docs could guide us to enable for one single tdd red/green/refactor cycle), and proactively minimize crash errors into an artifact to be conveyed to this issue tracker.
For a nugget of technical detail, I was trying to use the python 3.12 type to alias parametric generics and access the methods at runtime through the alias, which could explain why it crashed .. python type alias types are not Deref like every other type system I've worked with, so they don't resolve methods of the aliased type. I wound up needing to make a lot of changes, so you're right, it was a sign I was doing something wrong, I just got overwhelmed by the huge wall of tracebacks, that's all.
For every person like me who experiences this and posts here, there are almost surely others who are use it and get discouraged and stop using it without raising any issue at all. So I hope you'll realize that I was putting myself out there to help improve your project with honest feedback, and not aiming to put you down, though I admit I could have been more tactful and diplomatic.
Keep up your work, type level python is crucial for correctness of many of the most critical pieces of software around.
 It is what it is. I call a spade a spade. I know anger. I'm sadly familiar.  There's no shame in anger, either. It's a stock human emotion. It's natural to feel anger. This is anger:

that's patronizing BS

This is anger, too:

"SKILL ISSUE"

This is anger as well:

not helpful

This is anger yet again:

dealbreaker

This is anger all over:

useless details

And that was just your first comment. I'm not even touching that third comment. Casually throwing around slurs like "patronizing BS" to Internet strangers volunteering free work for you is textbook anger, toxic abusiveness, and injudicious in the extreme. I don't do that to Internet strangers. I'd appreciate the same consideration in kind.
If you'd rather not acknowledge the self-obvious, well... that's cool, I guess. You're in your own meat suit, of course. You know your emotions best. I'm certainly not here to belabour the subjective point. Neither are you, right?
So let's get down to brass tacks. I'm more than happy to ignore the anger, the passive-aggressiveness, and whatever else is going on here. Personality conflict, maybe? Seems plausible. Autism sure ain't for everybody. Ultimately, I'm just here to fix bugs. QA is @beartype's bread and butter. However, to belabour the only point that matters...
I Need an Example to Fix Bugs
That's it. That's all I need here. That's all any package maintainer needs. Please feed me a minimal reproducible example (MRE). Something reasonably short and to the point that exhibits the issue you're seeing. Given that, I'll gratefully resolve whatever issue this is for you and everybody else.
A traceback would also be useful – a full unredacted traceback complete with exception message. Screenshots are cool, I guess, but not nearly as useful as a working example and a full traceback.
Sound good? Sounds good. It's a good deal. Everybody wins. Winning is good. Let's win. :muscle: big muscles mean winning is happening
Exception Tracebacks are Good – Not Bad
Until then, there's not much meaningful I can do with this. Aside from whatever bug is happening here, @beartype is otherwise working as intended.
As suggested above, I need tracebacks to resolve bugs. Without tracebacks, bugs cannot be resolved. "Minimizing" tracebacks away is a non-starter. No one should want to do that ever for any open-source Python package – including @beartype. No one should even see tracebacks with @beartype internals in them in the first place. If you see a traceback with @beartype internals, that's a bug that I need reported to me.
So, this feature request doesn't particularly make sense. With apologies, let's quietly close this for sanity. I hate closing issues unresolved.  Since both of those things are now happening, neither of us had a good time with this one.
My emoji face sighs in spent exhaustion. :face_exhaling:

I see you're labeling my emotions.
That makes me feel you're not attending to my attempt to be more diplomatic. To be clear, in the first message, I was just in disbelief that an infinite wall of tracebacks is an acceptable dev experience. It was more of a diss / insult, than being angry. Need me to calmly read the text on youtube or something so you can catch my tonality?
To provide a complete traceback, I need to be able to select it, but I can't because it fills the whole terminal history buffer.
Could it be possible pipe the entire verbose tracebacks into a text file to upload, and then print the user code to the terminal? Issue persists because developers will read the docs, enable beartype broadly, hit a wall of tracebacks, and disable beartype. Thank you for your understanding.

anyway, my first message was mean out of line so i don't blame you for not wanting to help,
helpful book for folks in our situation, if i'd written my first message according to this book, then it would not have been mean https://www.nonviolentcommunication.com/learn-nonviolent-communication/4-part-nvc/


Jurik JMA indicator

Jurik indicator - JMA

Hello @mihakralj,
Cool! 😎 Thanks for contributing! I will merge it in as soon as I can and let you know when it's testable on the development branch.
Kind Regards,
KJ

My pleasure! 😊
Please wait for an updatebof this PR, I found an embarrassing bug in a math of Volty calculation...

Hello @mihakralj,
I pushed it to the development branch if you want to check it out before it's pushed to main.
$ pip install -U git+https://github.com/twopirllc/pandas-ta.git@development

Thanks for the contribution. 😎
KJ

modifications changed the math and the updated jma is no longer as smooth as the submitted code. I can chase what broke, but let me show you the graphics from the control data. On the screenshots below, blue is the input, yellow is my (original) jma, white is  what I called from pandas_ta:

Here is the code that I used above; the control file (JMA-test.csv) is available on my github here
import pandas as pd
import pandas_ta as ta
import numpy as np
import plotly.graph_objects as go

dfin = pd.read_csv (r"JMA-test.csv")
df=pd.DataFrame()
tests=['Spike', 'Impulse', 'Triangle', 'Sawtooth', 'Sine', 'Chirp', 'White', 'Gauss', 'B', 'HF', 'Impulse+HF', 'Sawtooth+HF', 'Sine+G', 'Chirp+G', 'Market', 'Complex']
for test in tests:
    df['input']=dfin[test]
    df['control']=dfin[test+'-JMA']
    df['ta_jma']=ta.jma(df['input'], length=10, phase=0)
    df['jma']=jma(df['input'], length=10, phase=0)

    fig = go.Figure(data=go.Scatter(y=df['input'], name='input'))
    #fig.add_scatter(y=df['control'], name='control', marker_color='yellow')
    fig.add_scatter(y=df['ta_jma'], name='ta_jma', marker_color='white')
    fig.add_scatter(y=df['jma'], name='jma', marker_color='yellow')
    fig.update_layout(xaxis_rangeslider_visible=False, margin=dict(l=0, r=10, t=0, b=0), showlegend=False, title={'text':test, 'y':0.9})
    fig.layout.template = 'plotly_dark'
    fig.show()

I think I found it;
line 37 ( beta = 0.45 * (length - 1) / (0.45 * (length - 1) + 2.0) ) should be:
beta = 0.45 * (_length - 1) / (0.45 * (_length - 1) + 2.0)
After this change, the control and the submitted code create identical result.

@mihakralj,
Thanks for checking the code promptly and finding the error! I apologize for the resultant mistake upon the variable renaming and will update it asap.
Thanks,
KJ

@mihakralj,
Ok. It's the development branch is updated. Give it another shot please.
Thanks,
KJ

Checked. All ok! 👍

@mihakralj
Awesome! Thank you!
KJ


Escape RegExp specials in _createSpecialLineExp

Fixes #11097.
Before this, the current character was only escaped in subExps, but not in prevChars.

Changes look good and it fixes the issue. Merging.


Use labels to enhance records filtering in FA e2e tests

In this pull request, we:

Set a label to Perftest Pods before initiating traffic in each subtest to filter records in both the IPFIX collector Pod and the ClickHouse.
Remove the --since-time flag used during log retrieval from the IPFIX collector Pod in the e2e test.
Cease reliance on timestamps for record filtering due to potential time discrepancies between the testbed and Kubernetes nodes, which might hinder the retrieval of desired logs.

resolve #5730

/test-e2e


operator!= DRY

What's in this pull request?

Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci Please smoke test

The build fails.  Please try building the code before submitting patches.

@tkremenek It build fine over here. On OS X I see the error is just a (spurious?) timeout, and on Linux I can't say I understand the error, but it doesn't seem to be related to my minor change.

@swift-ci please test

@danra hmmm, maybe master was broken for other reasons?  Re-running CI.


Add service method to clearWatch

Currently, there's no way to stop watching a users location. This is done by calling navigator.geolocation.clearWatch(id) (https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/clearWatch). However, the watchPosition id is not currently being stored, so there is no id to use for clearing it.
The watchPosition id is returned from the navigator.geolocation.watchPosition method (https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/watchPosition), so the return value could be stored on the service (https://github.com/igorpreston/ember-cli-geo/blob/c68a1d54ea6d96e2e5262f68613ed91e63a6df3b/addon/services/geolocation.js#L22).
It would then be convenient to round out the API with a public method to stopping tracking the location. The method would just need to call clearWatch with the stored watchPosition id.

https://github.com/igorpreston/ember-cli-geo/pull/7 this takes care of it

I'll push an update to the docs and then this can be closed.


Did not apply self.norm in PreNorm module's forward fn

https://github.com/drv-agwl/ViViT-pytorch/blob/a08baa06490d45e796eb0e438fcd43a64da88607/models.py#L14
should be
return self.fn(self.norm(x), **kwargs)

Thanks!
I have updated the code.


Add disclaimer text for claimed facility details

Overview
Add disclaimer text from #643 for claimed facility details
Connects #643
Demo

Testing Instructions

serve this branch, turn on claim a facility, then claim a facility and approve the claim
visit the details page for the facility you've claimed and verify that you see the disclaimer text

Checklist

[ ] fixup! commits have been squashed
[ ] CI passes after rebase
[ ] CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines

Thanks!


Fuzzy file search for example events

Resolves https://github.com/srijs/rust-aws-lambda/issues/34
The strategy I used is that I build a fuzzy file listing (where underscores and hyphens are removed) and then match against that.

Oh cool, that's a good strategy and much better than I was thinking of! 🎉

Thanks again for the patch!


[opencolorio] build with Python 3 support

Is your feature request related to a problem? Please describe.
Python 2 will be EOL'ed soon.
Proposed solution
It would be great to have OpenColorIO built with Python 3 support
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered if applicable.
Additional context
Add any other context or screenshots about the feature request here.

Thanks for posting this issue. This issue has been fixed. So I am closing this issue for now.


Localized 'configure-java-microservice' to Hindi

Fixed #46404

@anushatomar13  Thanks you for your contribution.
Could you please sign the CLA before the PR can be reviewed.
You can follow the steps documented here: https://git.k8s.io/community/CLA.md

@anushatomar13  Try to localize the sentences in simple hindi language only which can easily be understood. Dont use full machine language.  Before  making changes try to get Easycla signed then do the needful changes.

/easycla

Hi @niranjandarshann ,
I have made all the required changes now. Also, signed the CLA. Let me know if it looks fine to you.

@anushatomar13  Thank you for your contribution  What we wants in lacalization is the simple sentence that we use in our daily life which is understandable in simple hindi sentences. Without changing the meaning of the paragraph and sentences. I have found Some of the words like secrets in english have some meaning but in k8s its itself is a topic. which doesnt need translation of the word.
So Try not to simply use the machine generated translation. Try to validate with its meaning.

@anushatomar13  You are doing great work try to see the entire page and resolve them.
Continue contributing the good work.

Thank you so much for the suggestions and guidance @niranjandarshann
I have proof-read the content now, making sure that the words are easy-to-understand rather than machine-generated. Let me know if it's fine now

@niranjandarshann , @divya-mohan0209 I have made all the suggested changes. Please let me know if it looks fine now. If there are more suggestions, please let me know!

@anushatomar13  Please squash the commits in one commit.

You can get information about squashing the commits are https://kubernetes.io/docs/contribute/new-content/open-a-pr/#squashing-commits

@anushatomar13  its showing the two changed file whereas this PR only related with one file.Please do the needful.

@niranjandarshann Yes, I'm on it. Just facing some issues. Will resolve this asap.