Gtags support (maybe?)

Gtags (https://www.gnu.org/software/global/) are a enhanced version of ctags that provides search references and incremental ctags db updates. It can use universal ctags as a backend, so all languages supported by universal ctags are supported.
Also, with search references support, features like rename symbol should be easy to implement

Seems like a good suggestion. Does gtags for Windows exist?

Seems like a good suggestion. Does gtags for Windows exist?

There is not an official package for windows but its posix compliant, so it is possible to compile from source using mingw/cygwin for example

I don't see the benefits supporting gtags would bring. The only feature of universal-ctags that's being used is parsing the project and passing the resulting JSON on to the language server. Everything else is done by the server itself.
gtags offers no improvement to this workflow, and I don't think it supports JSON output at all.


Solution for 9 - Palindrome Number in TypeScript

Solution for 9 - Palindrome Number in TypeScript

Thank you, @Sinha1994!


Crash when clicking 'Options'

Occurs on version 1.4.8, on Minecraft 1.19.2.
Does not occur on version 1.4.7.
Log here.
https://hastebin.com/ariligegot.yaml

Thank you for the bug report, I have released a version that fixes this issue.


Fix undefined controller error in tooltip plugin

Issue that has been made clear in https://github.com/chartjs/Chart.js/pull/11596#issuecomment-1899486148
Issue also applies to a project of mine where the data is loaded twice, (Once from local storage and once from a result from a request), which might cause the issue.

@etimberg we dissalowed optional chaining because it was not stable yet and not all platforms supported it. It seems it is stable now and every major browser supports it, except for IE 11 but we do not support that ourselfs.
I think we can use it now, what is your oppnion on it?
https://caniuse.com/?search=optional chaining

@LeeLenaleee I'm ok to use it now that it's stable

I have this exact issue currently and will wait for this fix to be merged.
Our scenario happens when swopping between the graph on the dashboard and the page load from the graph click event multiple times, and only when this is done quickly.

Just confirming that I also have this issue in my current codebase - in my case, it seems to be related to multiple graphs being loaded at the same time under a stress test. It's four graphs in total with four sets of data (~600 points) being drawn each.
I've already staggered the loading because it wouldn't go smoothly otherwise (I first init the graphjs instance and then load in the data a short timeout later) and the missing controller happens seemingly at random - skipping over the error, all tooltips work just fine a moment later, navigating away and back to the page, I cannot reproduce the error consistently.
Another weird thing is that when I add a breakpoint to where the error occurs, I can print out the content of controller just fine (it's not null), but then the error happens anyhow.
The fix in this MR resolves the issue for me.
Seems like only a linter error is preventing this from being merged, so would be great to see it in the next release!


Simplify generated C reproducers

Work in progress.

Work in progress.

Do you want me to look at it now?

No, not yet.

PTAL

PTAL

PTAL

All done, PTAL

LGTM


Mirroring in China

HI
I want to build a flutter image in China. Is there any relevant documentation?
With the default address, it is really very slow, maybe this is a problem with the Chinese network.

Did you check https://github.com/flutter/flutter/wiki/Using-Flutter-in-China
What is

the default address

?

The default address I mentioned above is the address without setting the environment variable. I tried to give<EMAIL_ADDRESS>but the mailbox address didn't seem to exist. Google returned my mail.

I want to build a mirror in China. Can you help me?

A mirror for what exactly?
The Flutter install files, or pub.dartlang.org, ...

Try https://groups.google.com/forum/#!forum/flutter-dev instead of<EMAIL_ADDRESS>

Sorry, my description is not clear enough.
I want to build two mirrors, one is
PUB_HOSTED_URL
FLUTTER_STORAGE_BASE_URL
Please forgive me for my carelessness.

Can you please try if you can access the flutter-dev Google group using the web interface (with above link). If you can, please state the issue with the email there as well

<EMAIL_ADDRESS>but the mailbox address didn't seem to exist. Google returned my mail.


Task2

issue :#3
added a python program in Task.py to print "Hello, World!"

Hey @sanjitha006
Thanks for opening this PR 🚀. Mentor will review your pull request soon and till then, keep contributing and stay calm.
Thanks for contributing in OpenCode'24 ✨✨!

Hey @sanjitha006
Your PR has been merged 🥳🥳 and you have earned 10 points.
Thanks for contributing in OpenCode'24 ✨✨


sails-mongo: "contains" operator doesn't work for multiline texts.

Waterline version: 0.13.0-rc11
Node version: 8.4.0
NPM version: 5.3.0
Operating system: All
Sails-mongo version: 1.0.0-9

Raw query in Model.find():
{
    "content": {
        "contains": "some_text"
    }
}

The query built in build-mongo-where-clause.js:
...
{
    content: {
        '$regex': /^.*some_text.*$/
    }
}

But this doesn't work for multiline texts. Obviously we need some way to specify regex flags (e.g. /^.*some_text.*$/m).

Cleanup added


Change how we delete the analysis cache tables in the user deletion

We have been deleting the analysis cache tables using the reference
is stored in the cab_analysis_catalog table but for some reason
sometimes we have the table but not the reference in the table.
So in order to avoid this kind of mismatch due to bugs and because
we're not worried about the integrity of this table when we're deleting
the user, we're going to retrieve the analysis tables using pg_tables
and cleaning the metadata table all in the same transaction
The main reason behind this is that if we don't clean all the tables
we end up having owners blocked when they try to delete users

@juanignaciosl new review?

For future reference, here's a matching error trace.


Relative path instead of absolute

VSCode Version: 1.33.1
OS Version: macOS 10.14.3

Steps to Reproduce:

Create blank c++ project.
Open problems tab.
Click on any message and go to the problem.
But VSCode will not find path, because problem message contains absolute path, and VSCode will try to open it like relative path.
You can see VSCode notification:
Unable to open 'main.cpp': File not found (file:///absolute/path/main.cpp).
Click "Create File" and update file tree. You can see "./absolute/path/main.cpp" inside your project folder.

Please file it against c++ extension as it generates these problems with these URIs.


Install command

Todo before merging:

[x] Fix tests
[x] Take checksum from opam into account when installing packages
[x] Decide if we should bundle opam-installer-bin and subst as part of the esy (let's not do that)
[x] Make sure we depend on concrete commits of submodules
[x] Handle bzipped archives from opam
[x] ...

Another huge PR with various improvements but mainly:

esy install command which is based on pnpm installer
conversion from OPAM to package.json
Better error reporting
realpath command

OPAM conversion
opam-packages-converions dir contains a fork of opam-npm by @yunxing which transforms opam files into package.json files.
Such package.json contains "esy" key with Esy specific config and also "opam" key with "url" (optional) and "patch" (optional) keys.
Those generated package.json are meant to be distributed along with Esy and are commited into the repo. I think that's a good idea while we have semi-manual way of mapping OPAM to npm.
esy install command when encounters @opam/* packages consults opam-packages directory for the corresponding package.json files and resolves packages/versions from there.
Trying out
For testing I published Esy on npm under @andreypopp/esy so you can try it on ReLayout for example:
% npm install -g @andreypopp/esy
% git clone https://github.com/andreypopp/ReLayout.git
% cd ReLayout
% esy install
% esy build

Wow, I'll review this more thoroughly soon.
Curious, why was the ocaml compiler moved to a dev dependency?
https://github.com/andreypopp/ReLayout/commit/9c47935903079a0c632a6dcf60c5afaf46a41e97#diff-b9cfc7f2cdf78a7f4b91a753d10865a2R22
Dev dependencies are only installed for the top level npm package, but it's required to build ReLayout even if you depend on ReLayout transitively.

Curious, why was the ocaml compiler moved to a dev dependency?

It was moved both to peer and dev dependencies so that the top level package could decide which ocaml package to use. That's needed before we get dep overrides in sandbox config.

It was moved both to peer and dev dependencies so that the top level package could decide which ocaml package to use. That's needed before we get dep overrides in sandbox config.

But will every overridable package have to be anticipated as such and be listed as a dev dependency? It seems hard to predict which will require overriding, and I think by default, even if a package is not overridden - it should work.
We can make it so that the overrider is the one that has to install the second version explicitly as a dependency, and then esy could make sure to compile the right version. The only downside is that you might end up downloading two versions of the package - but that's tiny amount of time spent compared to compilation.

But will every overridable package have to be anticipated as such and be listed as a dev dependency?

Right now — yes, unless we implement package overrides as part of sandbox config (we should do it!). I left ocaml that way just because I was experimenting with different branches.

esy install command when encounters @opam/* packages consults opam-packages directory for the corresponding package.json files and resolves packages/versions from there.

I think this is a clever/fast way to move forward with barely any maintenance cost. (Until we get on the fly package resolving).
Just to confirm, this will still work well with the purely offline workflow where we do:
git clone someProject
cd someProject
esy install
scp to server
#... then on server
cd someProject
esy build

Just to confirm, this will still work well with the purely offline workflow

Yes, esy build should keep working offline. We actually should add a test for ejection workflow.

Right now — yes, unless we implement package overrides as part of sandbox config (we should do it!). I left ocaml that way just because I was experimenting with different branches.

I'm not even sure how this would work. If ReLayout declares ocaml as a dev dependency, then ocamlopt shouldn't be in the PATH when building ReLayout, unless ReLayout is the top level package right? I think it works right now because ReLayout is the top level package, but it might cease to work when ReLayout is a dependency of another app, right?

Does this current workflow require that we have only one version of package.json committed for each converted opam package?

Does this current workflow require that we have only one version of package.json committed for each converted opam package?

Yes, but a package.json insn't an actual package.json you see in node package usually — it has the form {"versions": [list of package.json files per version]} similar to how npm stores it in the registry. So yes, we can have multiple versions of the same package if that's what are you asking.

Curious, why use a forked pnpm instead of a forked yarn etc? That might make it easier to end up getting some of this merged into Yarn, I imagine. Also, I understand that you might have good reasons to start with pnpm. I do wish that we could simply have esy install generate an npm-shrinkwrap.json or Yarn lockfile so that it's kind of agnostic, and then also would share the download cache with npm or yarn.

I'm not even sure how this would work. If ReLayout declares ocaml as a dev dependency, then ocamlopt shouldn't be in the PATH when building ReLayout, unless ReLayout is the top level package right? I think it works right now because ReLayout is the top level package, but it might cease to work when ReLayout is a dependency of another app, right?

Note that ReLayout has ocaml both in peer and dev dependencies — peer deps ensure that OCaml is in env and dev deps ensure a packager installs the ocaml when ReLayout is the top level package.

Curious, why use a forked pnpm instead of a forked yarn etc? That might make it easier to end up getting some of this merged into Yarn, I imagine. Also, I understand that you might have good reasons to start with pnpm. I do wish that we could simply have esy install generate an npm-shrinkwrap.json or Yarn lockfile so that it's kind of agnostic, and then also would share the download cache with npm or yarn.

The most important reason is that I have the knowledge of pnpm codebase. Also pnpm was working better for me — less bugs, more space efficiency, faster installs.
I like the idea of generating shrinkwrap/lockfile to be installer agnostic.

Note that ReLayout has ocaml both in peer and dev dependencies — peer deps ensure that OCaml is in env and dev deps ensure a packager installs the ocaml when ReLayout is the top level package.

Oh, I see.

The most important reason is that I have the knowledge of pnpm codebase.

That is also a valuable reason.

Also pnpm was working better for me — less bugs, more space efficiency, faster installs.

Supposedly yarn is really fast though - I wonder if using git urls was the culprit?

Another thought. Depending on how pnpm resolves dependencies, it might be more difficult to add a constraint solver on top of it. The same may also be true of yarn. I believe that many constraint solving libraries we can use to resolve versions would require the package metadata to be available. That's one reason why opam often has you opam update to update the client's knowledge - however, I really like the npm style workflow. Thoughts?

Depending on how pnpm resolves dependencies, it might be more difficult to add a constraint solver on top of it. The same may also be true of yarn. I believe that many constraint solving libraries we can use to resolve versions would require the package metadata to be available for nearly the entire universe.

Yes, the algo should be modified to fetch all metadata for all versions of packages recursively to construct "universe".  Fortunately npm registry returns meta for all versions for a single package on a single API call. For git repos though you'd need git ls-remote to list all tags and then fetch package.json files for each tag.

For git repos though you'd need git ls-remote to list all tags and then fetch package.json files for each tag.

Assuming we wanted to add support for constraint solving on top of tags, right? Which would be quite amazing really. A fully decentralized package manager.

Assuming we wanted to add support for constraint solving on top of tags, right? Which would be quite amazing really. A fully decentralized package manager.

Yes, actually I have a patch for pnpm which does that (w/o constraint solver though).

I decided not to commit generated package.json (that was silly). Will try to do a proper rebase so we don't see them in history too.

I addressed all TODO issues I believe. @jordwalke is there anything else should be done before we pull this in?

This PR is amazing. Let's ship it, and fix the wget next?

Rebased to remove generated package.json files from history. Waiting for CI to confirm and will merge.


Initial docs

Initial pass at creating governance docs for SimPEG. This includes standard docs to be included in each of the SimPEG repositories

licensing guidelines
code of conduct
contributor guide

as well as a sketch of ideas on how new projects enter the SimPEG ecosystem. Some of these docs make reference to a steering council - this is something to discuss and is noted in #2. Most of these docs are largely inspired by the Jupyter governance docs: https://github.com/jupyter/governance

I am going to close this in favour of starting from the SimPEG docs


Config factory typo in docs

Looks like there is a quick typo in /doc/book/usage-examples.md where the config globbing examples are.  The example uses \Zend\Config\Config::fromFiles() but it appears that method is actually in the factory class - \Zend\Config\Factory::fromFiles().  Cheers!

Oops! Care to create a pull request?

Sure, just sent the request.


Add Jaimin25

@ArslanYM The PR is fixed, please review now

@ArslanYM The PR is fixed, please review now

The noise still exists. I would recommend doing git reset --hard on your branch and then making your change again. Just make sure you are changing only one line instead of adding noise.


kube-aws: truncate configPath (cluster.yaml) on open

If the cluster.yaml file exists and is longer than the new version being
written, the resulting cluster.yaml will contain portions of the previous
version.

@zuercher the desired behavior here is kube-aws init failing if cluster.yaml exists already. I think that check is simply missing.

OK. I'll close this one and submit another one that fails the open instead.

Thanks @zuercher.


actors returned from Proxy.conflicts() don't match original actors

I've tried to efforts - one that creates two independent documents from the same model, and another that clones an initial model. In both cases, conflicting changes are made, the two documents merged, and that's all (correctly) consistent.
However, the actors returned from the rootProxy.conflicts() don't match either of the original actors. The returned ActorId look like they're prepended with additional information, which the Swift API allows (related issue: https://github.com/automerge/automerge-swift/issues/45), but ultimately you can't really match the actors - which you should be able to do.
PR #48 illustrates the scenario that's failing as additional unit tests.

While looking at Documenting some of the other elements of the API, I ran into ObjectId, which includes a method to parse what looks like an ObjectId that's in the form of  {counterValue}@{ActorId}. Is that what the conflicts API is returning? An ObjectID, not an Actor?
And if so, should the type of the key returned from a call to conflicts by ObjectId instead of Actor?


Linux Crash

As far as I know this isn't an issue with extraterm but I'm posting this anyway since it might help someone else. Upon launching extraterm it crashed because of a limit on the number of inotify watches.
Doing the following made the error go away which allowed extraterm to launch:
TypeError: Unable to watch path
If you get following error with a big traceback right after Atom starts:
TypeError: Unable to watch path
you have to increase number of watched files by inotify. For testing if this is the reason for this error you can issue
 sudo sysctl fs.inotify.max_user_watches=32768
and restart Atom. If Atom now works fine, you can make this setting permanent:
echo 32768 | sudo tee -a /proc/sys/fs/inotify/max_user_watches
See also #2082.
Source: https://github.com/atom/atom/blob/master/docs/build-instructions/linux.md#typeerror-unable-to-watch-path

Thanks for the info. Extraterm uses inotify watches to monitor its theme files to do live updates which is very handy if you're working on a theme. It is not vital to the function of Extraterm for 95%+ of users. It should thus handle this error condition and not blow up. Or I could make it an option somewhere for those who need live theme loading. It is a bug in other words.

I've removed the code which watched the file system. This problem can't happen now.


Check for Deno. APIs in Deno provider

Check if any Deno. APIs are being used in the Deno provider.

I'm not sure if we should have this change. Just using regex to check for Deno.* usage can easily go wrong (variable named Deno in normal Node). Alternative is to actually parse all the source code and look for top level usage of the Deno variable. But I'm not sure that is something that Nixpacks should be doing. Is it common to be just using Deno, in an app that should be built and deployed, but is not also using a Deno import or has a deno.json file?


More ones/zeros than specified, BitArray

This test fails:
#[test]
    fn bitarray() {
        let x = bitarr!(1; 361);
        dbg!(x.iter_ones().filter(|&x| x > 361 ).collect::<Vec<_>>());
        assert_eq!(x.count_ones(), 361);
        assert!(!x.iter_ones().any(|x| x > 361))
    }

Why it's unexpected ?
I initialize an array of bits of length 361 with 1. The count is superior to the number of ones specified.
Left:  384
Right: 361

I don't know if it's a feature, feel free to close it, if it is.

The current implementation of const generics does not allow me to create an array of 361 bits. This will eventually change but until the language advances, I can't do anything about this.
The implementation of the bitarr![BIT; COUNT] value constructor repeats BIT for its entire memory content: bitarr![1; 2] produces BitArray<_, _> { _ord: PhantomData, data: [!0; 1] }. And, because BitArray always rounds up, you wind up with more bits than were requested.
For this reason, BitArrays that don't semantically fill their entire buffer will need to be wrapped in code that correctly subslices down to what you asked for. This can only be done with borrowed views at the time, so &your_array[.. 361] will produce a &BitSlice with 361 bits instead of 384.
Changing this behavior would currently require storing an additional usize length counter in-line with the bit-array, which renders it representationally incompatible with its storage buffer and therefore cannot implement the standard-library's array API. I elected to preserve representation compatibility at the cost of always rounding up the length, with a note that this will eventually change but must currently be handled manually by users.

From the linked API docs:

Exact bit lengths cannot be encoded into the BitArray type until the const-generics system in the compiler can allow type-level computation on type integers.

Sorry to hijack this (closed) issue, but would it be possible elaborate on this a smidge?  It's not immediately obvious why "type-level computation on type integers" is necessary; even if it, perhaps the typenum crate can provide an intermediate solution?

I had a play with typenum, and got fixed-size BitArrays working in a WIP branch.  Given that type-level computation on const generics probably won't land for some time, would such a typenum-based solution be of any interest in this crate?  Perhaps an interim v2 before the ultimate const generic solution eventually gets us to v3?
Tagging @myrrlyn just in case you don't otherwise see notifications on closed issues.


Token naming suggestions

How about if we change current naming that:

ERC721.sol (interface) -> ERC721Interface.sol or ERC721Standard.sol and ERC721implementation.sol -> ERC721.sol;
Alternatively we move interfaces in tokens/interfaces and name both ERC721.sol (interface and implementation).

If the plan is that our implementation gets reused then we need to have simpler names. ERC721implementation is way too long and verbose. Thoughts?

Interfaces could be prefixed by the I but it's strange when you have names like ERC721.sol.

/tokens/ERC721.sol (interface)
/tokens/NFToken.sol


Attribute doesn't parse correctly with dash in the value

The Attributes parser seems to eagerly match the first dash and breaks it up into description and value.
+ Attributes
    + blog_url: https://www.trunkclub.com/blog/is-the-hoodie-the-new-power-suit (string, required) - Blog url

Expected:

Name
Type
Required
Description
Value

blog_url
string
required
Blog url
https://www.trunkclub.com/blog/is-the-hoodie-the-new-power-suit

Actual:

Name
Type
Required
Description
Value

blog_url

optional
the-hoodie-the-new-power-suit (string, required) - Blog url
https://www.trunkclub.com/blog/is

@tigerpenguin please use back tick to escape values with reserved characters:
+ Attributes
    + blog_url: `https://www.trunkclub.com/blog/is-the-hoodie-the-new-power-suit` (string, required) - Blog url

See MSON reserved characters

Thanks! @zdne


ZIndex for overlapping elements

The following expression should use "higher" instead of "lower", or "back" instead of "front"
"An element that has a lower ZIndex value appears in front when elements overlap."

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

ID: 3bfd1636-a149-bcf7-823f-d2ecf0a0120f
Version Independent ID: c65af203-fb57-0609-7f12-902bfb497fdd
Content: Working with elements in XAML Designer - Visual Studio
Content Source: docs/designers/working-with-elements-in-xaml-designer.md
Service: visual-studio-dev15
GitHub Login: @gewarren
Microsoft Alias: gewarren

@yilmazdurmaz Thanks for this feedback; I'll fix it in the next sprint. Also in case you didn't know about it, we do allow the public to edit the docs too, if you want to give that a go. There's an Edit button near the top right corner.


PRODUCT  SECTION UPDATED

#550 issue solved
By adding this feature Product section looks more attractive .
It's a Responsive animation and effect .
Before

AFTER
DESKTOP MODE
https://github.com/Anushkabh/krishiconnect/assets/162671639/1088316b-0184-400b-8389-b5ccafb9a7f3
MOBILE MODE
https://github.com/Anushkabh/krishiconnect/assets/162671639/513a2cc9-163c-4b1d-82e3-f79a39d65ffb

@himanshu-03  please review my PR and merge it

product.css and product.js  should be in the desired directory under assets
You can look on the below link and see how your changes are looking on the website: Link

Ok sir , I will arrange it

Also, try to keep this card a little small its covering the whole page.
We dont need such big fonts, you can shorten the font size on the homepage as well as on the product card.

There are conflicting merges and also, sync your repo with our latest changes most of the files are movied in specific directories.

There are conflicting merges and also, sync your repo with our latest changes most of the files are movied in specific directories.

I will submit another PR for this issue
So i clossed this PR


[Question] Solving POMDP in TDMPC2

First of all, thank you for open-sourcing this algorithm.
I am trying to train a quadruped robot locomotion policy with multimodal input, including egocentric depth vision, on complex terrain. However, I have noticed that TDMPC does not apply to POMDP. Setting observation history as input is possible, but the planning step might be able to benefit from past latent dynamics. Have you conducted any experiments on such ideas?

TDMPC does not apply to POMDP

TD-MPC is an off-policy algorithm (same family as DQN, DDPG, SAC, etc.) and can be applied to the same settings as other algorithms in this family. When the environment is a POMDP (such as in our visual RL experiments) a Markovian state can be approximated using frame stacking or a memory mechanism (e.g. RNN); we use frame stacking in our experiments. I have tried RNNs, Transformers, S4 models previously but did not find any benefit in doing so, presumably because our visual RL tasks do not require much history.

Closing this issue due to inactivity. Feel free to reopen!


[KOGITO-3623] - Align Smallrye Messaging version with Quarkus

Signed-off-by: Ricardo Zanini<EMAIL_ADDRESS>@evacchi I believe we missed this during the BUMP.
Many thanks for submitting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors guide
[x] Pull Request title is properly formatted: KOGITO-XYZ Subject
[x] Pull Request title contains the target branch if not targeting master: [0.9.x] KOGITO-XYZ Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains link to any dependent or related Pull Request
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket

jenkins please retest this


Consensus below Header height

Note that this can be a symptom of #2698. This is because validation fails on a block due to missing coin information, which causes the rest of the chain to stop getting validated and consensus stops.

Duplicate of #2698


[FLINK-3579] Improve String concatenation

I think this time I got the PR correctly. Last time I did not select the right branch while creating the PR but the code was created with tableOnCalcite branch. Sorry about that.
As said in JIRA I have some doubts with that 'cast' operator change becasue the parser itself was written with '.cast(BYTE)' etc. where the . operator was explicit.

I could see some failure in the log console
JobManagerSubmittedJobGraphsRecoveryITCase.  But not related to the patch. Is there a place where we could see the failed test cases alone as how the Jenkins build shows us?

Anyone merged this PR as part of commit to Flink ASF Git repo?
I wonder why asfgit close this PR

@hsaputra
I am waiting for @tillrohrmann  reviews. Why did this get closed am not sure. Any way to open it back?

grasping at straws here: when was the tableOnCalcite branch deleted?

tableOnCalcite was deleted on Friday, but it seems that this PR was closed yesterday, so I'm not sure if that's why.
Sorry for the inconvenience @ramkrish86!


Handle non-JSON responses

Fix for #53

One note regarding this PR: this will still fail responses that aren't UTF8-encodable strings, ie. binary data like that returned from read CA will still fail. It will work with the /pem variant though, which is still a non-JSON response, but it is valid UTF-8. I'm not sure if Ansible supports returning arbitrary binary blobs.

Thanks for the fix @andor44!


Add a sample app

@jakecraige I've pushed a sample app to the sampleapp branch. I'm going to get it code reviewed before merging into master, but you can go check it out if you want.

#9 merged into master


Need to implement exponential backoff for polling nextUri

In the library exponential needs to implemented for checking the nextUri
Is there going be a performance impact if we directly check the nextUri without polling or doing exponential backoff?

In case you want to implement this in userspace, you could look at @watchable/nevermore that I wrote for this purpose.
Its generator API could work especially well with the AsyncIterator returned by trino.query(...)


config/perf: use prefix matchers instead of regexes

Commit Message: Converting regex matches to prefix matches as the former are way more costly. This is supposed to help with Envoy Mobile initialization times. The changes increase the number of stats that are enabled with default configuration of Envoy Mobile from 317 to 461. The profiling did not show any significant performance impact of this change but in theory reducing the number of places where we use regex should help.
Additional Description: related PR https://github.com/envoyproxy/envoy/pull/24521
Risk Level: Low
Testing: Manual
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]
Signed-off-by: Rafal Augustyniak<EMAIL_ADDRESS>

@jmarantz I was able to convert all but one matcher to prefix. The last one is tricky - I could try to convert is using suffix instead but I wanted to confirm whether using suffix has the same performance benefits as using prefix?

It's always better to use suffix-matching than a regex, but it doesn't have the same special-case code currently as "prefix: foo." (the trailing dot triggers the optimization). It would not be hard to add an optimization for `"suffix .foo" (leading dot would trigger).
The cases like cluster.base.upstream_cx_ are better than using regex but will still be expensive, as the elaborated string representation of the stat names will need to be created, and the rejected names remembered in a map.

This new simplification looks great -- it errs on the side of disabling a wider subset of stats; assuming that's OK.
I think this could motivate someone -- perhaps in E-M , to optimize for the remaining safe-regex by only applying elaborating the string for stats whose StatName starts with the "vhost" token. That will greatly reduce the amount of string elaboration required.
But it would make sense to take some more flame-graphs with this PR in place first; this might be enough.

Another option is to punt on that vhost exclusion and just let that stat live :)

Another option is to punt on that vhost exclusion and just let that stat live :)

I definitely thought about doing this but in our case - Lyft - we have quite a few of virtual clusters and enabling all vhost.* stats leads to a significant increase in the total number of stats that need to be created (we are talking about thousands of stats in here). In general, we should make this inclusion list configurable (https://github.com/envoyproxy/envoy/issues/24459) so that each company can tweak it as needed and decide what trade-offs work best for them.

This new simplification looks great -- it errs on the side of disabling a wider subset of stats; assuming that's OK.

The PR increase the number of stats enabled by default in EM from 317 to 462 but I think that that increase is fine given the fact that we use regexes in only one place now.

/retest

The existence of any rejection expression that is not of the form prefix: foo. causes all stats to be name-elaborated so they can run through the string-matcher API.
How many more stats are added if you drop the vhost regex?

How many more stats are added if you drop the vhost regex?

For the Envoy Mobile configuration that I am interested in the numbers look as follows:
regex vhost matcher: 2336 stats
prefix vhost matcher: 6067 stats

@jmarantz if you do not mind, I would like to merge this PR without further changes to vhost and collect some prod data to see whether the changes that I made in here helped or not. That being said I am a curious what you think about the vhost stats after learning about the increase in the number of stats I observed in https://github.com/envoyproxy/envoy/pull/24733#issuecomment-1370170222.
Merging this PR today as opposed to tmrw will speed up the process of collecting the data by a week since we are doing a beta/release cut later today.

Checking this in now and iterating makes sense to me. This is a great improvement.
checkAndRememberRejection would drop out of this flame-graph if our rejections were just based on prefix tokens w/o regexes, but it's probably a lot smaller than it used to be due to this change.


build for the cli

@NicolasMahe I might need some help a bit on this one, the build is fine on local but fails on the ci...

Ok I'm checking it

could be usefull to upload release to github: https://github.com/tcnksm/ghr

another multi system build: https://github.com/mitchellh/gox

Fixed with model: https://github.com/ncw/rclone/blob/master/.circleci/config.yml


emulators: firebase-tools no longer supports Java version before 11.

Whenever running npm run emulators, I get the error:
⬢  emulators: firebase-tools no longer supports Java version before 11. Please upgrade to Java version 11 or above to continue using the emulators.
i  emulators: Shutting down emulators.

Error: firebase-tools no longer supports Java version before 11. Please upgrade to Java version 11 or above to continue using the emulators.

On a MacOS, I solved the issue running the following commands:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

brew install openjdk@11

Add the following lines to your shell configuration file (~/.zshrc, ~/.bashrc, or ~/.bash_profile, depending on your shell):
export JAVA_HOME=$(/usr/libexec/java_home -v 11)
export PATH=$JAVA_HOME/bin:$PATH

Then, apply the changes:
source ~/.zshrc  # or ~/.bashrc, ~/.bash_profile

Check:
java -version

java version "11.0.x"
Java(TM) SE Runtime Environment (build 11.0.x)
Java HotSpot(TM) 64-Bit Server VM (build 11.0.x, mixed mode)


Hardcode broker class that the broker operates on

closes #466
Changes

:wastebasket: Do not  expose the broker class that the controller operates on as an environment variable.

/kind removal
Release Note

Do not  expose the broker class that the controller operates on as an environment variable.

/lgtm
/approve


Fix forum rank doesn't exist

Closes #202.
Do not raise an exception when forum rank doesn't exist

@alexdashkov I still don't think this resolves the problem. The issue is that "Copper Member" is not an acceptable rank, and so a failure is displayed about not being able to find the user, when the real error is that a) the user could be found, but b) could not parse the rank.

@shawnlauzon the issue is being diplayed that user's rank doesn't exist in the venue DB. Including all the context (user, profile, etc.. ) so you (or someone else) can decide to add or not this rank to the database.

There should be a migration that populates the database with content. That
migration should contain a new item "Copper Member"
On Sat., Aug. 25, 2018, 5:00 p.m. Oleksandr<EMAIL_ADDRESS>wrote:

@shawnlauzon https://github.com/shawnlauzon the issue is being diplayed
that user's rank doesn't exist in the venue DB. Including all the context
(user, profile, etc.. ) so you (or someone else) can decide to add or not
this rank to the database.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Volentix/venue-server/pull/203#issuecomment-415996223,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAlUyWIVrotWGGF8UX4L6F9BEd-vfYQJks5uUbrfgaJpZM4WGVZp
.

Do you mind if I use the fixture instead? This data should not be in migrations. Read more

Fixture sounds better, thank you.
On Sun., Aug. 26, 2018, 11:56 a.m. Oleksandr<EMAIL_ADDRESS>wrote:

Do you mind if I use the fixture instead? This data should not be in
migrations. Read more
https://docs.djangoproject.com/en/2.1/howto/initial-data/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Volentix/venue-server/pull/203#issuecomment-416048886,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAlUyQtA1KIm3kvdAc-rBmKLHzNd8GSoks5uUsU_gaJpZM4WGVZp
.

@shawnlauzon I've added this rank to the django fixtures and call of this fixture to the entrypoint.sh.
Do you execute this file during the deployment?

@alexdashkov truthfully, I'm not sure. Will merge it and see what happens :)


No write permission for user created with PFFacebookUtils.logInInBackgroundWithReadPermissions

Issue Description
When a PFUser is created on Parse Server with PFFacebookUtils.logInInBackgroundWithReadPermissions it has no write permission to existing objects with ACL (Public: Read, User: Write). It can however create new objects with that ACL.
The object's ACL is set as:
let acl = PFACL()
acl.setWriteAccess(true, forUser: currentUser)
acl.publicReadAccess = true
aObject.ACL = acl

which results in permissions:
{
    "_id": "Asd1tk4FeW",
    "_rperm": [
        "*"
    ],
    "_wperm": [
        "xdY082YDF0"
    ],
    "_acl": {
        "*": {
            "r": true
        },
        "xdY082YDF0": {
            "w": true
        }
    }
}

Steps to reproduce

Create new user with PFFacebookUtils.logInInBackgroundWithReadPermissions
Create object with ACL: Public read, user write.
Try updating a field of the object, e.g. with PFObject.saveInBackgroundWithBlock.

Expected Results
Updating the object should succeed.
Actual Outcome
Updating the object fails with error, user has no write permissions:

[Error]: Object not found. (Code: 101, Version: 1.13.0)
(Error Domain=Parse Code=101 "Object not found." UserInfo={code=101, temporary=0, error=Object not found., NSLocalizedDescription=Object not found.})

The solution is to log-out and re-log-in the user, then the update and all following updates succeed.
The update also succeeded without re-login when Public: write is enabled in the object's ACL in Parse Dashboard.
This issue does not occur when creating a user with PFUser.signUpInBackgroundWithBlock.
Environment Setup

Server

parse-server version: 2.2.11
Operating System:     -
Hardware:             -
Localhost or remote server?: Heroku

Database

MongoDB version: 3.0.9.
Storage engine:  -
Hardware:        -
Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): mLab

Logs/Trace

Having the same issue. Figure anything out?

Ahhh... Probably not the best practice but I logged in with the access token after calling PFFacebookUtils.logInInBackgroundWithReadPermissions and that seemed to work!
PFFacebookUtils.logInInBackgroundWithAccessToken(FBSDKAccessToken.currentAccessToken())

Did you update to the latest parse-server version (2.2.18) and let us know if the issue persist? We have a serverSide mechanism that prevents the user lock himself out.

I can confirm that this issue is solved in Parse Server 2.2.18.


feat: allow optional fields

Closes https://github.com/gr2m/github-project/issues/18
Follows { name: string; } pattern for custom fields as suggested in https://github.com/gr2m/github-project/issues/8,
  const project = new GitHubProject({
    fields: {
      createdDate: { name: "Created Date", optional: true },
    },

Backward compatible with custom fields that pass a string instead of an object,
  const project = new GitHubProject({
    fields: {
      createdDate: "Created Date",
    },

It's my first time in this project, so all critiques are very welcome

@all-contributors please add @Ebonsignori for code, test and documentation. Please add @tmelliottjr for review


Use Updated .obj's

This PR Updates the Demo to use the .obj's from:
https://github.com/MyoHub/myo_sim/blob/obj_meshes/scene/myosuite_scene.xml

@Vittorio-Caggiano @vikashplus

LGTM! Thanks!


web todo: Show type error messages in a helpful way

What it says on the tin.
I think this is largely a styling thing.

We don't have an endpoint to run GHCI, so this is blocked until that.


Add one paper into the collection

Hi,
Thanks for releasing the great collections of paper on llm planning and reasoning.
Would you please kindly add our previous research paper into the collection:
Title: Are Large Language Models Really Good Logical Reasoners? A Comprehensive Evaluation and Beyond
It focuses on the limitations of LLMs in the logical reasoning domains, which provide interesting findings and insights.
Thanks for your effort !

Sure, thank you for your suggestion! We will include this paper in the collection. We’re also in the process of adding a few more papers, and we’ll update the repository with all of them within a couple of days.
Thanks again for your contribution!


Wrangling data flow availability

When and where will wrangling data flow be available? I currently can not add in my region and in other regions it does not show up.

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

ID: 8fd84209-19f9-3fa0-f3af-6ebf12cac777
Version Independent ID: 43ae3347-2644-48a5-be2a-e0f57a6ebb97
Content: Getting started with wrangling data flow in Azure Data Factory - Azure Data Factory
Content Source: articles/data-factory/wrangling-data-flow-tutorial.md
Service: data-factory
GitHub Login: @djpmsft
Microsoft Alias: daperlov

Thanks for the question , we will review the same and get back to you .

@sampruett As mentioned in the document there are two ways to create a wrangling data flow (Preview) in Azure Data Factory. One way is to click the plus icon and select Data Flow in the factory resources pane.

The other method is in the activities pane of the pipeline canvas. Open the Move and Transform accordion and drag the Data flow activity onto the canvas.

In both methods, in the side pane that opens, select Create new data flow and choose Wrangling data flow. Click OK.
Could you please share below details to better assist on your query.

What is your subscription type - free trial subscription or Pay-as-you-go?
Also what is the your region of your Azure Data Factory?

@sampruett Please refer to this doc to know more about Wrangling data flows region availability.
https://docs.microsoft.com/en-us/azure/data-factory/frequently-asked-questions#wrangling-data-flows
Wrangling data flow is currently supported in data factories created in following regions:

Australia East
Canada Central
Central India
Central US
East US
East US 2
Japan East
North Europe
Southeast Asia
South Central US
UK South
West Central US
West Europe
West US
West US 2

@sampruett We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply and reopen the issue. We will gladly continue the discussion.


Discrepancy between values in online and print views

Original report via customer contact centre:

I did a search on the above for: average price Detached Houses, May 2009 to March 2010 with a comparison of UK and Nottinghamshire. With data on screen the UK figures were higher than Notts., but when I printed it out the data changed columns.

Fix confirmed by Mal and deployed to production.


EHN: Make the console program importable by other program

Dear OpenH264 community,
I am currently working on video compression development.
The console program is very helpful, which is able to read configuration file.
However, it is not possible to import the console program into other program.
So, i refactored the code, separate the main function part from the code.
Hope this minor change could be adopted.
Or if you have better solution, i would be more glad to know.
Best Regards,
Longquan

the console program only is a sample test program. You can do this change according to your application on your side. Don't suggest to merge into master branch.


Drive Redirection Not Working in Newer Versions

Describe the bug
Since a recent update to FreeRDP, Drive Redirection is no longer working for me.
When I compile and use the version I pulled from GitHub on 2023-10-11, Drive Redirection works.
When I compile and use the version I pulled today, Drive Redirection does not work. (I do not get any error messages, it just does not map to the server.)
Application details

FreeRDP version (xfreerdp /version)
This is FreeRDP version 2.11.2 (2.11.2)

Command line used
xfreerdp 5-CCS-RDS3-User.rdp /bpp:24 -menu-anims -wallpaper +clipboard /sound /drive:Remote,/tmp +auto-reconnect /p:

Output of xfreerdp /buildconfig
This is FreeRDP version 2.11.2 (2.11.2)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_BACKTRACE=1 HAVE_EXECINFO_BACKTRACE_SYMBOLS=1 HAVE_EXECINFO_BACKTRACE_SYMBOLS_FD=1 HAVE_EXECINFO_H=ON HAVE_EXECINFO_HEADER=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=1 HAVE_GETPWUID_R=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL=1 HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CAIRO=OFF WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_GDI=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_ORDERS=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=OFF WITH_FUSE=OFF WITH_GFX_H264=OFF WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_1_0=ON WITH_ICU=OFF WITH_INTERNAL_MD4=OFF WITH_INTERNAL_MD5=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PCSC=OFF WITH_PROFILER=OFF WITH_PULSE=ON WITH_PULSEAUDIO=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_VERBOSE_WINPR_ASSERT=ON WITH_WAYLAND=OFF WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          Debug
CFLAGS:               -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g -fno-omit-frame-pointer -DWINPR_DLL
Compiler:            GNU, 13.2.1
Target architecture: x64

OS version connecting to (server side)
Windows Server 2019 (but I have tried several other server versions)

Environment (please complete the following information):

OS: [e.g. Linux/Windows/Android/..]
openSUSE Tumbleweed
and
openSUSE Leap 15.5

duplicate https://github.com/FreeRDP/FreeRDP/issues/9517

This was marked as a duplicate of #9517, which is marked as fixed. However, I am still having this problem. How can we proceed with investigating / fixing this issue?

@KenHolloway did you test with the latest stable-2.0 ?
we did not tag it yet.

ok, have to apologize, there seems to have been a glitch with the latest backport reintroducing this bug.

This issue is resolved for me.
As always, thank you for all of your wonderful work on this!


Documentation references firmware/ directory that doesn't exist

Documentation in docs/first_project.md references a firmware/ directory that doesn't exist in the project template.

We also added a firmware and mech folder to store 3D designs or firmware associated with your project.

Thanks! Updated


[Issue-193] Don't show blocktime although perform transaction in wallet #193

Related issue(s)

#193

Is your feature request related to a problem(s)? Please describe.

Add re-scan BTC transaction have no block_time

Describe the solution you'd like

Add re-scan BTC transaction have no block_time

Describe alternatives you've considered

No

Additional context

No

🚀 Deployed on https://pr-195--papaya-melba-f5c160.netlify.app