update httpclient version to 4.5.13 because of doris connection reset

Purpose of this pull request
update httpclient version to 4.5.13 because of doris connection reset.
refer doc: https://doris.apache.org/zh-CN/administrator-guide/load-data/stream-load-manual.html#常见问题
The FAQ3 is account for the pr.

Check list

[x] Code changed are covered with tests, or it does not need tests for reason:
[x] If any new Jar binary package adding in you PR, please add License Notice according
New License Guide
[x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

hi,please refer this :https://github.com/apache/incubator-seatunnel/blob/dev/docs/en/developement/NewLicenseGuide.md
resolve license error.

commons-codec-1.11.jar

Thanks


Company POC

Is your feature request related to a problem? Please describe.
Depends on
https://github.com/atsign-foundation/at_libraries/issues/367
https://github.com/atsign-foundation/at_client_sdk/issues/1077
https://github.com/atsign-foundation/at_client_sdk/issues/1078
write a POC code to validate the sequence diagram

Describe the solution you'd like
Flexxon use case

Consumer device in user’s home.
Not exposed directly to the internet but has a http server which may be accessed on the home network by the user’s browser
Device setup flow:
a process to assign a unique ID (which will actually be the atSign) to the consumer device
Device checks atSign uniqueness by talking to the Flexxon API which in turns talks to the Registrar API
Device talks to Flexxon API which talks to the Registrar API to register and activate the atSign
Device does the initial CRAM authentication and onboarding
and stores its atKeys file
App setup flow (app can run anywhere and will communicate with the device on the user’s home network via atProtocol)
User is instructed to go to some page served up by the http server on the device
In the app, the user enters the device ID (which will be displayed by the device for convenience)
User clicks a ‘Pair your app’ button on the device web page
Device issues the otp:generate:ttl:60 request, gets the PIN back, shows the PIN on the web page
User enters the PIN into the app
App sends the enroll request
Device approves the enroll request if the PIN matches the PIN it just displayed
App stores its atKeys file with the new APKAM pair
Key thing to note about this use case is that it is the device which is central, so it is the device which must do the initial onboarding.

Describe alternatives you've considered
No response
Additional context
No response

@murali-shris rather than links to private GDocs things can you please put the diagrams etc. into this ticket.

Sure. Done @cpswan

moving to private repo


async vs multithreading

Hello,
In the book section «Sending messages», you write:

if Alice sends bob: foo , and Charley sends bob: bar , Bob might actually receive fobaor . Sending a message over a socket might require several syscalls, so two concurrent .write_all 's might interfere with each other!

As a rule of thumb, only a single task should write to each TcpStream.

Then you resort to an Arc to share access to the TcpStream, and to a mpsc channel to have only one task writing to the socket.
I get confused: why in an async environment should we need to use thread-specific constructs? Doesn't it completely defeat the purpose of async programming? Why should data races occur in an async framework? Isn't the event loop supposed to treat one action after the other?
Thanks for your help!

Thank you for your answer. I still have questions:

Would there be the same problem on a single-theaded event loop like Node.js? If so, what solution would be relevant on Node.js?
In Rust, if we split the TcpStream into reader and writer, is it possible to have only message passing and no sharing at all (no Arc)? (listener -> mspc -> broker -> writer)
Wouldn't it be simpler to implement this chat using good old threads and mutexes?

I think node js's implementation of async/await might not have this issue (but don't quote me on that). Rather than using polling on tasks to make progress, Node JS uses a callback style approach to handle operations.

I think that should be possible. If the same task is doing both the reading and the writing, you don't need to put it in an Arc. If you do end up splitting the read task and write task, you'll still need an Arc because it's possible that the reader & writer would live on different "real" threads.

It might be! You could try an async mutex approach as well with futures' mutex. That said, you'd likely get better performance out of an async version, since you're not spawning threads & context switching for each connection.

I think maybe:

No. event-loop call callback one by one. There won't be two callbacks being called at the same time.

async's advantage over threads is to have a thread pool to avoid having too much threads. If you are using thread pool, you may achieve similar result.

Still one question: why do you spend so much effort building an async framework rather than green threads? It seems to me that they would bring both simplicity and performance, as the Go language shows it.

Still one question: why do you spend so much effort building an async framework rather than green threads? It seems to me that they would bring both simplicity and performance, as the Go language shows it.

I found this talk by Steve which talks about whether to implement  green thread or not.
I believe it's chosen because rust wants to stay at the system language level where user have access to tweak about the underlying mechanism while providing zero cost abstraction.

@thomas-hugel As it turns out, synchronization problems do show up in node.js and web browsers, and will arise in any language with asynchronous features. They're introduced, not by threads, but by callbacks and awaits.
JavaScript only runs one event handler at a time. But consider an event handler like this:
function handle_click(event) {
  fetch('http://example.com/movies.json')
    .then(response => response.json())
    .then(data => console.log(data));
}

Depending on how long the promise that fetch returns takes to resolve, any number of other event handlers could run between the time this function is called and the time that we log the result to the console. This example is simple, but if the event handler wanted to actually have an effect on the page's state (as one usually does), it must be carefully written to tolerate other event handlers' effects on the page jumping in while it is waiting for promises to resolve. Perhaps all its effects must be put off until the very last callback. Perhaps other events will need to wait for this operation to finish before they can proceed. But these problems are very similar to those that threaded synchronization primitives like channels and mutexes are designed to solve: ensuring that things happen in an acceptable order.
It's true that you can assume you won't be interrupted in the middle of ordinary JavaScript control flow - it's only await expressions and callbacks that make it possible for other code to interrupt. But you must carefully restrict which functions you use within your "critical sections", to ensure that nobody starts an asynchronous operation. Most complex interactive JavaScript applications introduce some sort of rules or constructs for dealing with this.
One of your broader assumptions seems to be that 'the purpose of async programming' is to be a programming model that avoids the complexities of multi-threaded programming. It's true that asynchronous features play this role in JavaScript: they bring a certain kind of pleasant concurrency to the language without having to go fully threaded, which would be extremely difficult not just for developers but also for implementers of the language.
But this doesn't apply in Rust, for two reasons:

Multi-threaded programming is not worth avoiding in Rust. It is not at all like multi-threaded programming in any other production language. Once your program compiles, it is free of data races. You can use threads in Rust whenever they make sense, just as you would decide to use a for loop. Channels and mutexes and arcs are not hard to get used to, and the language will catch whatever mistakes you make in the learning process.

The value of asynchronous programming in Rust is its performance in certain cases. Operating system threads have certain kinds of overhead that make them unsuitable for certain sorts of work. On Linux, an operating system thread takes 15µs to start, and uses around 20KiB at minimum. Rust can start an asynchronous task fifty times faster than that, and it will use only as much memory as it needs to suspend itself at its await points. So if your program is bound by the speed of task creation and per-task memory consumption (not all are!), then you can go much farther on a given piece of hardware with asynchronous code.

So in fact, asynchronous programming in Rust has been designed from the start to be used together with threads: you'll usually see a pool of threads all running asynchronous tasks. So an async task might migrate from one thread to another over the course of its execution, and will certainly run concurrently with other tasks. This is why crates like async-std and tokio include full suites of synchronization tools like channels and mutexes.

I recommend Steve's talk, too. Rust had green threads originally, but then took them out because they have certain kinds of overhead that we can't ameliorate the way Go does.

Many thanks for your answers.
I have watched the talk by Steve Klabnik and I understand why the Rust language doesn't offer green threads.
But, I still cannot understand why green threads should not be available as an extra library for the people who can afford a little extra runtime. Wouldn't their performance be comparable to what async libraries achieve? Why not?
As for the art of programming, Bob Nystrom emphasizes that async inevitably brings a kind of apartheid between sync and async functions (red and blue functions). Every function shall have two versions, just like async-std has to mimic all functions from std.
Here is his article : https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

I did a simple benchmark, scanning 500 TCP ports on a remote host. Here are my results:

sequential : 247 s;
parallel iterators from rayon : 68 s;
async-std : 42 s;
tokio : 42 s;
1 native thread / port : 42 s;
a pool of 30 threads from rayon : 10 s.

Those results are not surprising. Threads are very efficient, and are fine for almost all applications.  Your benchmark doesn't meet either of those criteria, so threads should have the advantage.
There are a number of green thread crates: https://lib.rs/keywords/green
Why not give them a try?
I think it's unhelpful to bring emotionally charged words like 'apartheid' or (in the US at least) 'red and blue' into a technical discussion, because it invites us to view technical opinions as reflections of individual character, instead of problems that can be analyzed and understood.
That said, yes, I think it's unfortunate that async-std and tokio need to reimplement std's functionality. The fact that it's been done twice is even more unfortunate. But remember that basing your language on green threads doesn't change this: it just picks a winner, making the async library the default. Rust picked sync as the winner. As far as I can see, async has a much smaller (but still important!) niche, so I think Rust made the right choice.

@thomas-hugel This RFC may help to understand: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md

Thanks for your answers.


Catalog: Fix entity orphaning

Hey, I just made a Pull Request!
Fixes a bug in the catalog where entities were not being marked as orphaned.
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

fixes #7563


Exception when linking accts with hidden email addresses

Many Github accts choose to hide their email address in settings (this is different than simply marking the email private, which can still be requested by the connecting app). When these users connect an app using this plugin, an exception will be thrown from GithubOAuth2Service.createSpringAuthToken. Since the username is still available though, it a better approach might be to add username to the GithubOauth2SpringToken. and proceed with token creation, since User creation can may be able to use that as the unique username instead.

This is going to be a requirement for us for a number of projects.


.cxx, .h files

Need to include these in languages

closed via https://github.com/sedouard/gittrack/pull/103


URL based one-liner to run debloater GUI

iex ((New-Object System.Net.WebClient).DownloadString('https://git.io/debloat'))

Just thought this might be nice to add to the README as it is how I always run the debloater GUI now. The git.io link was just a link that I made using the free git.io URL shortener. You could, of course, instead use a raw GitHub link if that would be more secure in your opinion.
I find this much simpler tho, and on older computers, it is quite laggy to copy & paste the debloater script into Powershell. This is almost instant, assuming a fast enough internet :)

You got it :D

Added it to the ReadMe.


[Bug]: Unable to disable AllowRegister on FirstInstance with Helm deployment

Preflight Checklist

[X] I could not find a solution in the documentation, the existing issues or discussions
[ ] I have joined the ZITADEL chat

Environment
Self-hosted
Describe the bug
We are deploying via the Helm chart, and as part of the configmapConfig value, we try to disable registration. This doesn't work - registration is enabled on the instance and organization.
To reproduce

Deploy Zitadel using Helm. Inside the values, specify the instance as described below.
Open up the console UI.
Observe that the Register button is available. Alternatively, log in with the admin user, and observe that inside the instance settings, "Allow register" is checked.

Screenshots
No response
Expected behavior
I would have expected FirstInstance.LoginPolicy.AllowRegister to affect the ability to register.
Version
v2.15.0
Operating System
Zitadel Helm chart: v4.1.3
Kubernetes: v1.25.4
Relevant Configuration
zitadel:
  configmapConfig:
    FirstInstance:
      InstanceName: Foo
      LoginPolicy:
        AllowRegister: false
      Org:
        Name: Foo Org
        Human:
          # ...

Additional Context
The default value for AllowRegister is documented here:
https://github.com/zitadel/zitadel/blob/5651f98600ba17dfc8294f6ae1df34748167cb9a/cmd/defaults.yaml#L422

Hi @meyfa
It looks like you have a miss configuration.
Can you try DefaultInstance instead of FirstInstance?

That worked, thanks! Still, I was under the impression that DefaultInstance would supply standard values for all instances, while FirstInstance can choose to override some of them. Is that not the correct way to think about these two sections? The docs don't seem to make a clear distinction IMHO.

For reference, I found a simpler way of reproducing the issue (based on the self-hosting guide), that I used to try out your solution just now.
This snippet doesn't work:
helm repo add cockroachdb https://charts.cockroachdb.com/
helm repo add zitadel https://charts.zitadel.com
helm install crdb cockroachdb/cockroachdb \
  --set fullnameOverride=crdb \
  --set single-node=true \
  --set statefulset.replicas=1
helm install my-zitadel zitadel/zitadel \
  --set zitadel.masterkey="MasterkeyNeedsToHave32Characters" \
  --set zitadel.configmapConfig.ExternalSecure=false \
  --set zitadel.configmapConfig.TLS.Enabled=false \
  --set zitadel.secretConfig.Database.cockroach.User.Password="a-zitadel-db-user-password" \
  --set replicaCount=1 \
  --set cockroachdb.single-node=true \
  --set cockroachdb.statefulset.replicas=1 \
  --set zitadel.configmapConfig.FirstInstance.LoginPolicy.AllowRegister=false

It works if we substitute DefaultInstance for FirstInstance in the final line, as you recommended.

That worked, thanks! Still, I was under the impression that DefaultInstance would supply standard values for all instances, while FirstInstance can choose to override some of them.

This explanation is on point :slightly_smiling_face: whereas the LoginPolicy doesn't belong to these values that can be overwritten by FirstInstance. @hifabienne, @livio-a is there a reason why not all DefaultInstance properties can be overwritten by FirstInstance?

I think we just started somewhere and did not have a look at it later on if we should allow some more possibilities.
I close the issue for now as the problem could be solved.


add a non blocking function to set compare channel

In continuous mode the provided set compare channel function implements a delay to guarantee the correct adc value.
In microcontroller tasks with multiple simultaneous tasks this delay is a problem because it blocks other tasks. So I added an additional non blocking function to set compare channel. This is only for advanced users because the user has to take care to wait an appropriate time until the adc value is valid.
Nevertheless I hope you could accept this pull request.
Thank you.

Hi @generationmake, thanks for this contribution. Happy to include it. Makes sense for advanced users.


Add duplicate_with for RSpec Example

This is the last of the new APIs as discussed in #2094

I love how simple this is!

Contributing to rspec-core has been a great experience. Thanks for the timely feedback and code reviews.


Syntax highlighting incorrectly applied to characters wrapped in backticks

Incorrect syntax highlighting is being added to variable names that are enclosed in backticks (see screenshot below)

(wasn't sure where to post this so please let me know if it needs to go to the language server extension repo instead)

Yes, you are right. All syntax highlighting is provided by vscode-R.

Already fixed via #859.


新增镜像地址

http://kr-se-cncn-1.ofalias.net:59862/

暂时先别过，等待进行重构。

怎么重构
获取Outlook for Androidhttps://aka.ms/AAb9ysg

From: 冬烟mio @.>
Sent: Sunday, July 7, 2024 10:23:53 PM
To: Mxmilu666/bangbang93HUB @.>
Cc: Rubedo332 @.>; Author @.>
Subject: Re: [Mxmilu666/bangbang93HUB] 新增镜像地址 (PR #124)
暂时先别过，等待进行重构。
―
Reply to this email directly, view it on GitHubhttps://github.com/Mxmilu666/bangbang93HUB/pull/124#issuecomment-2212468010, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5RVDCVVZXV6OPFKNXPSBR3ZLFFPTAVCNFSM6AAAAABKPHRNMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJSGQ3DQMBRGA.
You are receiving this because you authored the thread.Message ID: @.***>

你至少搞个 https 吧...

那我寻思着内网穿透我SSL也搞不好啊
况且workers反代会提示503
获取Outlook for Androidhttps://aka.ms/AAb9ysg

From: Mxmilu @.>
Sent: Monday, July 8, 2024 11:26:31 PM
To: Mxmilu666/bangbang93HUB @.>
Cc: Rubedo332 @.>; Author @.>
Subject: Re: [Mxmilu666/bangbang93HUB] 新增镜像地址 (PR #124)
你至少搞个 https 吧...
―
Reply to this email directly, view it on GitHubhttps://github.com/Mxmilu666/bangbang93HUB/pull/124#issuecomment-2214440853, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5RVDCU63GMFTNAXDRZNDX3ZLKVSPAVCNFSM6AAAAABKPHRNMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJUGQ2DAOBVGM.
You are receiving this because you authored the thread.Message ID: @.***>

获取Outlook for Androidhttps://aka.ms/AAb9ysg

From: Mxmilu @.>
Sent: Monday, July 8, 2024 11:31:30 PM
To: Mxmilu666/bangbang93HUB @.>
Cc: Rubedo332 @.>; Author @.>
Subject: Re: [Mxmilu666/bangbang93HUB] 新增镜像地址 (PR #124)
那我寻思着内网穿透我SSL也搞不好啊
况且workers反代会提示503
获取Outlook for Androidhttps://aka.ms/AAb9ysg

From: Mxmilu @.>
Sent: Monday, July 8, 2024 11:26:31 PM
To: Mxmilu666/bangbang93HUB @.>
Cc: Rubedo332 @.>; Author @.>
Subject: Re: [Mxmilu666/bangbang93HUB] 新增镜像地址 (PR #124https://github.com/Mxmilu666/bangbang93HUB/pull/124)
你至少搞个 https 吧...
D
Reply to this email directly, view it on GitHub#124 (comment)https://github.com/Mxmilu666/bangbang93HUB/pull/124#issuecomment-2214440853, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5RVDCU63GMFTNAXDRZNDX3ZLKVSPAVCNFSM6AAAAABKPHRNMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJUGQ2DAOBVGM.
You are receiving this because you authored the thread.Message ID: @.***>
你不能在 node 里面开 https 吗
况且你内网穿透稳定性怎么样
―
Reply to this email directly, view it on GitHubhttps://github.com/Mxmilu666/bangbang93HUB/pull/124#issuecomment-2214451431, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5RVDCUCUWHFXQDUF4ZZKJ3ZLKWFFAVCNFSM6AAAAABKPHRNMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJUGQ2TCNBTGE.
You are receiving this because you authored the thread.Message ID: @.***>

稳定性能好
并且上面那个因为卡所以多发了一个
获取Outlook for Androidhttps://aka.ms/AAb9ysg

From: Whirity 404 @.>
Sent: Tuesday, July 9, 2024 6:31:59 AM
To: Mxmilu666/bangbang93HUB @.>; Mxmilu666/bangbang93HUB @.>
Cc: Author @.>
Subject: Re: [Mxmilu666/bangbang93HUB] 新增镜像地址 (PR #124)
获取Outlook for Androidhttps://aka.ms/AAb9ysg

From: Mxmilu @.>
Sent: Monday, July 8, 2024 11:31:30 PM
To: Mxmilu666/bangbang93HUB @.>
Cc: Rubedo332 @.>; Author @.>
Subject: Re: [Mxmilu666/bangbang93HUB] 新增镜像地址 (PR #124)
那我寻思着内网穿透我SSL也搞不好啊
况且workers反代会提示503
获取Outlook for Androidhttps://aka.ms/AAb9ysg

From: Mxmilu @.>
Sent: Monday, July 8, 2024 11:26:31 PM
To: Mxmilu666/bangbang93HUB @.>
Cc: Rubedo332 @.>; Author @.>
Subject: Re: [Mxmilu666/bangbang93HUB] 新增镜像地址 (PR #124https://github.com/Mxmilu666/bangbang93HUB/pull/124)
你至少搞个 https 吧...
D
Reply to this email directly, view it on GitHub#124 (comment)https://github.com/Mxmilu666/bangbang93HUB/pull/124#issuecomment-2214440853, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5RVDCU63GMFTNAXDRZNDX3ZLKVSPAVCNFSM6AAAAABKPHRNMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJUGQ2DAOBVGM.
You are receiving this because you authored the thread.Message ID: @.***>
你不能在 node 里面开 https 吗
况且你内网穿透稳定性怎么样
―
Reply to this email directly, view it on GitHubhttps://github.com/Mxmilu666/bangbang93HUB/pull/124#issuecomment-2214451431, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5RVDCUCUWHFXQDUF4ZZKJ3ZLKWFFAVCNFSM6AAAAABKPHRNMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJUGQ2TCNBTGE.
You are receiving this because you authored the thread.Message ID: @.***>


Vue Watch not working upon redirect route

"inertiajs/inertia-laravel": "^0.6.8"
"laravel/framework": "^10.10"
"laravel/jetstream": "^4.0"
"vue": "^3.2.31"
Problem
Watch in Vue 3 not working when:
return redirect()->route()->with('message', $Message);
Works Perfectly with:
return back()->with('message', $Message);
HandleInertiaRequest.php
return [
            ...parent::share($request),
            'ziggy' => fn () => [
                ...(new Ziggy)->toArray(),
                'location' => $request->url(),
            ],
            'flash' => [
                'message' => fn () => $request->session()->get('message')
            ],
        ];

Layout.vue
<script setup>
  import { Head, Link, router, usePage } from '@inertiajs/vue3';

  const page = usePage();

  const flash = computed(() => page.props.flash);
  const message = computed(() => page.props.flash.message);

  const showSuccess = ref(false);

  watch(flash, async (newFlash, oldFlash) => {
    console.log('hit');
    if(message.value != null){
      showSuccess.value = true;
    }
  });

</script>

This works absolutely fine when i redirect back but not when redirecting to route (with all the methods via the docs) too.
If i update flash.message via a function in the child of Layout.vue this does not trigger the watch either.
If i change the watch to the below and update the message via the child component function then it also triggers the watch:
 watch(message, async (newFlash, oldFlash) => {
    console.log('hit');
    if(message.value != null){
      showSuccess.value = true;
    }
  });

I can get it to work how i want in a hacky way via the below:
router.on('success', (event) => {
    if(message.value != null){
        showSuccess.value = true;
    }
});

I've confirmed in vue devtools that the prop is also being updated as expected.  It almost feels as though the old value matches the new value on redirect.
But would like to understand why the watch is not working and if there is any fix or better way or whether it is in fact a bug?

Sorry for reopen this thread but I have the exactly same problem


Bug: Spigot spawns areas of chunks at once, rather than keeping up with the player.

Spigot 1.16.5 appears to spawn some 30x30 chunks at a time, making it appear very slow when exploring.

Fixed by Josh for 0.0.15.


Output token usage being misreported as 1 when using streaming

In the final Message object that the Python SDK constructs when streaming completes (stream.get_final_message()). usage.output_tokens is always reported as 1 regardless of actual output length.
I believe this object is supposed to be comparable to the Message object you would work with in non-streaming, so I would expect this to report the total output tokens.

Thanks for reporting, we'll take a look!

Let me if you can't repo. I can provide more steps if needed!

This is the same issue as https://github.com/anthropics/anthropic-sdk-python/issues/424

Thanks, closing as a duplicate.


Features: Gene: Internal Server Error (500)

Go to Features tab on civicdb.
Click on any gene.
The summary page opens without any data and the console shows as internal server error.

Hi @sumirp, thanks so much for the report!
It looks like this was an issue with our MyGene.info integration. Their API is returning a 500 error and we weren't properly catching the issue.
The error is properly handled now and the page should load for you, however the MyGene.info box will not show until the errors on their end are resolved.
Thanks again,
Adam

Thank you @acoffman for this information.


Replace JSCS with ESLint (or Prettier?)

this should be addressed by some version of #4475
it's important that

code is readable & maintainable by new and old developers
code can be automatically fixed when possible (low-effort for developers)
automated tools are still being used (i.e., let's get off jscs!)

I like the ESLint approach, but I'm not that familiar to Prettier or JSLint or the others. Would love to open a chat to see what people are using nowadays :)

ESLint is a great tool, but deciding on a configuration can be tedious as there's a long list of rules. That's why most people adopt popular styleguides and configurations like Standard JS or Airbnb. Standard can be used either as an ESLint config, or as a stand-alone tool.
Prettier is another great tool, but only for code formatting. Contrary to ESLint or Standard, it is not concerned with sources of bugs and errors in your code. In a way, you could end up with a beautifully formatted document full of bogus javascript.
My suggestion is to choose one of the following:

Use Prettier for formatting and ESLint with the eslint:recommended config to find common sources of problems.
Use Standard

Would you be interested in using clean-slate to do that, by any chance? 🙂https://github.com/Tom-Bonnike/clean-slate.
Or would you rather roll your own config? In any case, I strongly recommend you setup a git hook to run ESLint and Prettier on all staged files before every commit, automatically. husky and lint-staged are great for that. :)
My suggestion would be that you use ESLint-Standard + Prettier while using https://github.com/prettier/eslint-config-prettier to disable all ESLint formatting rules that could conflict with Prettier. That way, only Prettier is responsible of the formatting itself. This is what clean-slate does.

I'm super partial to prettier. FB uses it for all their OSS product so it's battle tested and, importantly, makes reasonable choices for you to eliminate debates over the right style. +1 to eslint:recommended or airbnb eslint and prettier with either.

fixed in https://github.com/moment/moment/pull/5462


GEODE-3126: Adding a query command to the experimental driver

Adding a QueryService and query operations to the experimental client.

This travis build is failing because this PR also requires #1497 to build, but that hasn't been merged yet.


ChannelOption for FIRE_EXCEPTION_ON_FAILURE?

I want to be able to react to any outbound channel failure.
I can add a handler to the tail of my pipeline that will call promise.addListener(ChannelFutureListener.FIRE_EXCEPTION_ON_FAILURE) for every outbound event, but this is not sufficient.
Specifically, in the case of a MessageToMessageEncoder that outputs more than one object, new promises are created for all but the last object:
https://github.com/netty/netty/blob/00afb19d7a37de21b35ce4f6cb3fa7f74809f2ab/codec/src/main/java/io/netty/handler/codec/MessageToMessageEncoder.java#L112-L127
If one of those objects then triggers a failure on a subsequent outbound handler, the exception is suppressed.  There might be other scenarios where this can happen as well.
How can I react to these failures when I don't have the opportunity to inject a ChannelFutureListener.FIRE_EXCEPTION_ON_FAILURE?
Would it be reasonable to have a ChannelOption for FIRE_EXCEPTION_ON_FAILURE?
Netty version
4.1.30.Final

@Bennett-Lynch that's a good question.. I like the idea of the ChannelOption but I would need to investigate if this is easily doable without breaking any API (I suspect it should be doable).

@Bennett-Lynch https://github.com/netty/netty/pull/8448 PTAL


[of topic] how to manage GH issue labels

just aa quick question, do you  manage the issue Labels manually or is this driven by a tool using the GH API. Have seen the same structure in the k8s project.

Manually and very painfully.

@ibuildthecloud I expected that and feel your pain...

Not that @ibuildthecloud is the one doing the managing :-P
But yes, basically manually.. There are keyboard shortcuts for label/assigned/milestone so you don't need a mouse, which helps.  There's also some tools like waffle.io that we've tried but had some issue with.  And https://github.com/9-volt/bug-life is cool for visualizing them.

I mess around with huboard a bit. Not so bad, at least a start

Closing this issue so I don't have to label it. ;)


platform bug

hey
Thank you for the excellent library
There is a problem
You used html and js packages and this causes problems in running the application on other platforms
For example, I tried to run the example on Windows and it got many errors

hi @androidwoman, this package is intended only to be used for web. I think I made it very clear on Readme and on the packages pub.dev page.

hi @androidwoman,
I’m truly sorry for my previous response. I realize now that I didn’t fully grasp the issue you were experiencing and that my reply was not helpful. I regret any frustration this may have caused.
I’ve revisited the problem and believe I’ve found a solution that addresses the issue more accurately. I hope this resolves the problem you were facing.


You misspelled features on README.md

You wrote featrues instead of features

Ugh, I wish there was spell check in the README box. Anyways thanks for finding this.

np


[Test] Make model tests run again and remove --forked from pytest

This PR makes model_tests work by

Right now, some tests fail because fork is called after cuda context is initialized. This is due to the usage of --forked https://github.com/vllm-project/vllm/issues/3557. The reason why --forked is required is to clean up resources by simply killling processes. This PR removes the usage of --forked from pytest and instead doing clean up using fixtures.
Fixed the issue where del hf_model or del vllm_model doesn't actually clean up GPU usage.
When running a large model in small GPUs (like the one used in CI) vllm fails to initialize because the machine doesn't have kv cache to match model_len. It uses the smaller model_len by default (1024) to avoid this issue. Note that none of tests require more than 128 tokens to generate.
Separate out big models (7B) to different test suites.
Skip failed model tests. Also remove soft_fail: true from model tests

The following models fail to succeed.

allenai/OLMo-1B: TypeError: forward() got an unexpected keyword argument 'cache_position'
mistralai/Mistral-7B-v0.1: correctness issue (generate doesn't generate any token) + RuntimeError: expected scalar type BFloat16 but found Half (only in CI)
Deci/DeciLM-7b: correctness issue (output is different)
tiiuae/falcon-7b: correctness issue (output is different)

Closes https://github.com/vllm-project/vllm/issues/3557
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

@simon-mo addressed all comments!


Errors

Erros should be sent to the Failure relationship, see issue #27
But when sending errors we will close Context.
This is why we need a
Failure struct {
Err error
Processor string
Payload Payload
}

Fixed by having a rather nice solution which is Highly customizable
Workflow now has a
failureHandler func(f Failure) that can be changed by users or devs.
That handler is ment to take care of the failure anyway wanted,
Workflow now also has a functionHandler cancler context and a FailurePipe that is inherited by the processors..
Should failureHandler be placed inside each Processor instead? That would be cool since each processor could do its own error fixing, .... Probably In the Future


Manage gossip identities and broadcast to ROUTER connected peers

This adds an identity registration mechanism to gossip and broadcasts out to connected identities on the router socket.

@boydjohnson yeah, this is in advance of the peering work. I like your suggestion of a peer class which abstracts the two types.


Where can I find this plugin in the chrome store?

At least put the link to the add-on, I'm interested in installing it in chrome.
Thank you

i have the same question, i come from the firefox addon, but in chrome where is it?


need session_id

Added in this release:
https://github.com/adswerve/google_analytics_flattener_ga4/releases/tag/v1.3.0


⚠ Bofrost.com has degraded performance

In df9dd8b, Bofrost.com (https://www.bofrost.com) experienced degraded performance:

HTTP code: 200
Response time: 6511 ms

Resolved: Bofrost.com performance has improved in c59e049 after 6 minutes.


Reorganization of cardinalities to be <, =, or <= (and fix the beth numbers)

I don't have time to write this issue up now, but I'm posting this placeholder to remind me to get back to this.

As brought up in #96 there are some issues related to how cardinality is represented on the pi-base. Here are how they appear now:

https://topology.pi-base.org/properties/P000125 "has distinct points", >= 2
https://topology.pi-base.org/properties/P000078 "finite", < omega
https://topology.pi-base.org/properties/P000057 "countable", <= omega
https://topology.pi-base.org/properties/P000058 < 2^omega
https://topology.pi-base.org/properties/P000065 2^omega
https://topology.pi-base.org/properties/P000059 <= 2^(2^omega)

These were either chosen based on Counterexamples to match the reference chart, or added over time. I propose we reorganize as follows.

Keep >=2 (while this is not consistent with how I've organized the rest of the proposal, this is how the property is most frequently used and based on recent discussion #14 we should keep it this way)
All other carnality properties moving forward should be equivalent to <kappa for some cardinal kappa. Since this is a ZFC database, we will carefully use aleph and beth numbers. Note that our canonical name doesn't be exactly <kappa ("finite" is better than "<beth0") but the property should be equivalent to <kappa.

finite is equivalent to <beth0=aleph0
countable is equivalent to <aleph1
<2^omega is equivalent to <beth1
2^omega is equivalent to <beth2 and not <beth1
<=2^(2^omega) is equivalent to <beth3

So most of what I propose is some possible renaming or modification of descriptions, except for handling P65 (=beth1). We should certainly add a <beth2 property, and theorems connecting it to P65 and P58 (<beth1). Whether we need to dig through the entire database to purge P65 is up for discussion: we have redundancies elsewhere (e.g. listing T_3 for regular+T_0), and I think keeping this one =beth1 property is possibly useful for historical reasons.

I think we should also mention that P59's current name is (<= 2^omega), and that does not match (<= 2^(2^omega)).

I think keeping P65 (beth1) is kind of useful because it can be asserted for many examples that have an obvious cardinality of the continuum, and from that we can automatically derive the fact that many other cardinality properties are true or false.  It simplifies the management of the data in many cases, I think.

One comment about that last two bullets in your list. "2^omega is equivalent to <beth2 and not <beth1" and "<=2^(2^omega) is equivalent to <beth3".  That would be the case if GCH holds, but otherwise there could be many cardinals strictly between two consecutive beths, so they don't seem to be equivalent.  It does not seem to be the case that one can express cases of equality or <= in terms of < of beth numbers.  I guess one can always say: <= beth3 is the same as <(beth3)+, where the + indicates the successor cardinal, and =beth1 is the same as [not(<beth1) and <(beth1)+ ], but that does not seem too useful.

Oh yeah, that was a silly oversight from me. Yes, beth_(n+1)=(beth_n)+ fails in many models of ZFC, so some of my beth_(n+1)s should be (beth_n)+ (but really it's easier to just say <=beth_n than <(beth_n), which is what we should do).

Hi @StevenClontz .  Would it be possible for you to fix just the title for https://topology.pi-base.org/properties/P000059 ("smaller or same as the continuum", but seemingly meant to be something else)?
After that, there are many many examples that have the cardinality of the continuum by construction.  That's why I really think we should keep P65.  It allows to claim the correct cardinality in an obvious fashion for these spaces, and then the other cardinality properties can be deduced appropriately.  That will allow to remove a lot of redundant traits files, which is what I had started doing in PR #96. I can work on that, independently of any further tweaking of cardinality properties that you have in mind.  Would you be ok with that approach?

I opened a PR for @lyengulalp or @ccaruvana to approve to make the necessary fix to the title of P59; will review the rest of this comment when I can.

Hi.  Quoting below from my Nov 6 comment.  Would you be ok with this for now?

After that, there are many many examples that have the cardinality of the continuum by construction. That's why I really think we should keep P65. It allows to claim the correct cardinality in an obvious fashion for these spaces, and then the other cardinality properties can be deduced appropriately. That will allow to remove a lot of redundant traits files, which is what I had started doing in PR #96. I can work on that, independently of any further tweaking of cardinality properties that you have in mind. Would you be ok with that approach?

Responding to this is way-overdue, but I think I want this refactor done programmatically rather than by hand. So unless it's blocking something critical, let's keep this on the back-burner.

In today's meeting we decided it was reasonable to fix cardinality >=3 and >=4 to be <=2 and <=3 and flip the booleans.
We decided to make the exception for "has multiple points (cardinality >=2)"

One thing that came up in the review for #561.
We have a "convenience property" P65 (card = c), which could be expressed as (card <= c and not < c) but is really convenient for data entry in particular.  Similarly, to express that a space is countably infinite, we currently must say (countable + not finite).  But I think it would be really convenient to add a property (card = $\aleph_0$).

I hate to throw a monkey wrench into something we already decided on in the meeting, but it has dawned on me that for finite cardinalities, it is probably literally always going to be the case that a theorem requires cardinality at least $n$, rather than at most $n$.  There is really little point in making theorems about all spaces of cardinality at most $n$, since there are only finitely many of them, and I doubt the premises of any of our theorems will ever include $|X|\leq n$.
So we might reconsider that change, and have instead a convention that finite cardinal properties all have the form $|X|\geq n$ (we could even flip the bits on "Empty" to "Nonempty" to conform to this, which would make a lot of sense in my view, as there are never theorems that require "empty" as a hypothesis.)
So our rule could be:

finite cardinal properties always equate to $|X|\geq n$.
infinite cardinals have the form $|X| <\kappa$ (which includes $|X|\leq \kappa$ as has been pointed out).  Note the finite rule is just a negation of this rule, so we still have some governing logical principle here.
As @prabau suggests, convenience properties for equality of extremely common infinite cardinalities, probably just $|X|=\mathfrak c$ and $|X|=\aleph_0$, though I think we currently have $|X|=\aleph_1$, so maybe that stays if we feel generous enough.

In practice, I think this just means leaving everything the way it is except for

changing P137 from empty to nonempty and flipping the bits on asserted traits and theorems.
adding $|X|=\aleph_0$.
possibly removing P114 ($|X|=\aleph_1$), and adding $|X|\leq \aleph_1$, or alternatively leaving the convenience property and just adding $|X|\leq \aleph_1$.  Or doing nothing at the moment since we may not have a use for $|X|\leq \aleph_1$, in which case we simply add it if we ever need it.

I am ok with most of what you are proposing.  Except maybe for the elimination of $|X|\leq \kappa$ with infinite cardinals.  We have various theorems with a conclusion of that form, which seems more "convenient" than $|X|\lt\kappa^+$ in my opinion (what is $\mathfrak c^+$ or $(2^{\mathfrak c})^+$ anyway, it's neither well determined in the aleph scale nor on the beth scale for example).  We should give this some thought.

I am ok with most of what you are proposing. Except for the elimination of the convenience |X|=ℵ1 and of |X|≤κ for infinite cardinals. We have various theorems with a conclusion of that form, which seems more "convenient" than |X|<κ+ in my opinion (what is c+ or (2c)+ anyway, it's neither well determined in the aleph scale nor on the beth scale for example). We should give this some thought.

I maybe mis-explained.  $|X|\leq \kappa$ would not be eliminated - it is equivalent to $|X|<\kappa^+$.  As @StevenClontz  mentioned earlier the actual name isn't important as long as it is equivalent to $|X|<\kappa$ for a cardinal $\kappa$.
As for $\mathfrak c^+$ (or even $\mathfrak c$ itself) not being well-determined on $\aleph$ scale, I don't think that's a problem.  We need only include those ZFC theorems that relate it to other cardinals in the database.  Which is what we currently do.
I mostly agree with keeping the convenient $\aleph_1$, was just keeping its elimination as a possibility in case others thought that we should limit the number of "convenience cardinals."

I have slight unhappiness with "not nonempty" being the phrasing for "empty" on pi-Base. I wouldn't block a PR from someone who really wants that to happen, but I'm going to skip that suggestion for now.
Otherwise I'm cool with having contrary conventions for finite vs infinite cardinals.


Fedora28 CI significantly slower than other Linux CI legs

For example, for https://github.com/dotnet/source-build/pull/638 (chose a non-code PR to look at):

22 min CentOS https://ci.dot.net/job/dotnet_source-build/job/master/job/CentOS7.1_Release_prtest/62/
21 min Debian https://ci.dot.net/job/dotnet_source-build/job/master/job/Debian8.4_Release_prtest/53/
1 hr 14 min Fedora28 https://ci.dot.net/job/dotnet_source-build/job/master/job/Fedora28_Release_prtest/8/

The Fedora28 leg seems to have more warnings in the native compilation steps than CentOS, nothing else stands out, though.
@dseefeld do you know if this is expected with https://github.com/dotnet/source-build/pull/603? (Changing to running on Helix?)

@dagood Certainly not expected.  I looked at the vm configuration, and I don't see anything different than others.

@MattGal took a look at the queues and saw the machines are different: the faster legs are running on D3_v2s (4-core), and Fedora 28 runs on D2_v3s (2-core). It's possible to move Fedora up to D4_v3 (closest to D3_v2) if the perf is worth it.
I don't think Fedora28 speed is affecting dev flow enough to justify it. The tarball legs won't get under 1h14m, and the number of Fedora28 agents should keep up to PR demand.
We also can't be completely sure that upgrading will fix this completely. There might be something about Fedora28 that makes our PR builds slow.
(Recently I noticed there was only one Fedora28 agent up, causing a backlog, but Matt fixed that with https://github.com/dotnet/core-eng/issues/3991.)


OTEL collector performance metrics

With both logging and metrics switching to otel collector we should check whether there are any metrics provided by the application that we want to collect

FYI @dbason when otel metrics is enabled, by default it collects the collector metrics

I've had to disable that because of an issue with process namespace so we probably need to revisit this.

Is that a known issue with the open telemetry collector, or is this specific to our setup?

I didn't see any open issues, but from my investigating it seems to be a race condition that only occurs when the kubernetes processNamespace sharing is enabled (a prerequisite for reloading)


Remove git config --global requirements from forge

Component
Forge
Describe the feature you would like
Being able to run forge init on a system that does not have global git settings configured.
Requested behaviour

Test git settings

git config --list | grep 'user.'       // Outputs nothing

Forge init

forge init hello_foundry             // Creates the project

Current behaviour

Test git settings

git config --list | grep 'user.'       // Outputs nothing

Forge init

forge init hello_foundry

Output:
Initializing /home/USER/foundry/hello_foundry...
Error:
Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email<EMAIL_ADDRESS>  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect e-mail address (got 'USER')

Additional context
Background
Most of my crypto work is anon, so I don't globally set my git credentials. I set them up per repo using scripts.
This is the reason why I'm running the above command in an empty folder.
Setting up a foundry project within a pre-initialised repo also doesn't work. More on that here: https://github.com/foundry-rs/foundry/issues/4214

I'm assuming this error occurs when we try to commit, and since there are no local or global credentials the commit command fails. Can you please retry with --no-commit

A. forge init {PROJECT_NAME} --no-commit was a pass for me.
For reference I created the project in an projects directory on a system with no global git configs.
1, Check git config
git config --list | grep 'user.'           // Outputs nothing

Location folder

ls                                                  // Outputs folders within the, ie. not an empty folder

Forge init

forge init hello_foundry --no-commit  // Creates the project as expected

Check the project creation

ls                                                       // contains `hello_foundry` folder

=======
B. forge init --template {TEMPLATE} {PROJECT_NAME} --no-commit was a fail
I also wanted to test project creation from a template. Feels like most users would want to use this scaffolding.
Got the following error
error: the argument '--template <TEMPLATE>' cannot be used with '--no-commit'

Usage: forge init --template <TEMPLATE> <ROOT>

For more information, try '--help'.

=======
C. Comments
When purely looking at forge-init as a project scaffolding tool, the committing of the scaffold seems odd.
I'm comparing it to other large scaffolding tools: create-react-app (98.7k stars on Github)
For example create-react-app doesn't init the repo for the user:
0.1 Pre-requisites

Requires node to be installed on the system, best installed via nvm

Run the create-react-app

npx create-react-app test-react

List the created folder

ls test-react                                       // Outputs project files

Check the project repo

cd test-react && git status

Outputs:
fatal: not a git repository (or any of the parent directories): .git

``

=======

D. Thank you

Thanks a lot @DaniPopes I can move forward with the `--no-commit` workaround.

A. great, I guess we could make the error clearer for future users
B. that's definitely a bug, easy fix for anyone to implement: just remove the "conflicts" in the clap args and put the template commit under an if block
C. It really depends on the framework as well. Rust projects initialized with Cargo also start with a vcs (like git). But also this is nice for Foundry since we are still using git submodules as dependencies

For future reference:
forge init --template https://github.com/foundry-rs/forge-template --no-commit does not respect the --no-commit flag


Possible to export the props for given components for typescript

https://github.com/mui-org/material-ui-pickers/blob/2323a4b3e4e8479909ad5a9de4a671320506360f/lib/src/DateRangePicker/DateRangePicker.tsx#L30
Would it be possible to export the prop interfaces so that I can use them in typescript.
Reason:
I am writing a wrapper for the DateRangePicker. I'm just wrapping things that I need on top of it but the component is having a hard time dealing with props that are just transfered.
import {DateRangePicker} from '@material-ui/pickers'

type MyDate = {
  foo: string
  bar: string
}

const DateInput = (props) => {
  const {foo, bar, ...other} = props

  // something something foo / bar

  return <DateRangePicker {...other} />
}

I get a very ugly (and long) typescript error.
Type '{}' is missing the following properties from type 'Pick<DateRangePickerProps &
BasePickerProps<RangeInput, DateRange> & Pick<DateInputProps<RangeInput, DateRange>,
"color" | ... 292 more ... | "ignoreInvalidInputs"> & WithDateAdapterProps & DateValidationProps &
Pick<...>, "color" | ... 349 more ... | "disableAutoMonthSwitching">': onChange, focused, valuets(2739)

I believe if the interface was exported then I could import the props and use that to extend my type.
import {DateRangePicker, DateRangePickerProps} from '@material-ui/pickers'

type MyDate = DateRangePickerProps & {
  foo: string
  bar: string
}
...

For obvious reasons you would also have to extend those interfaces for the DesktopDateRangePicker and MobileDateRangePicker. Not including other components that may want to also export the types.
I ask because this is how @material-ui/core exports the types for each of the components.

Ok, I found out that I can get rid of the typescript error by adding three apparently required fields.

value
onChange
focused (not sure why)

So the error is no longer a problem.
It would still be handy to have the props be exported for extending.

@JeffBaumgardt This issue seems to resonate with #1631.

@JeffBaumgardt please provide your case. I cannot reproduce an error with focused prop

I'm not sure why the focued was required. I tried several times yesterday and it was erroring out if I was missing, value, onChange and focused. Today, however focused is no longer needed. I'm unsure why. Oh well.
Thanks for the types on the export. That will help 👍


Update the Target Description web page

Update the Rust target document parts regarding to #276

Could someone pull this PR to check builds and deploy this change?

No automatic CI check?

What do the curly brackets do?

I intended to leave the parts as backups but just dropped them for clarification.

Rust target description validation

Example and method used
: Run the binary of CounterProgram.lf after applying the target property and compiling with lfc (version: 0.9.0)

Target Property
Supported (Web)
Supported (Actual)
Compilation & Execution
Review Comment

auth, build, compiler, docker, files, no-runtime-validation, protobufs, runtime-version, scheduler
X
X
N/A
None

buildtype
O
O
O
None  (Binary size: Debug=40,671,312bytes  Release=4,450,760bytes  RelWithDebInfo=27,350,408bytes  MinSizeRel=4,179,936bytes)

cargo-dependencies, fast, no-compile, single-file-project, single-threaded, timeout, workers, Command-Line Arguments
O
O
O
None

cargo-features
O
O
O
It would be good to add usage examples later.

external-runtime-path
O
O
X
Not able to know how to use

export-dependency-graph
O
O
O
1) This option works only when cargo-features is set to cli and the command line option --export-graph is given.

logging
X
O
O
Check later

rust-include
O
O
O
The link Linking support files doesn't work.

@lhstrh Would the above table be enough for the versioned documents? Or could you let me share a guide for the documents?

I'm not sure what you mean, @chanijjani, but what I'm asking for is to simply replicate the changes you made in this PR across the files in the versioned_docs directory. At a minimum, v0.9.0 should reflect these changes. If we don't do this, the changes will only appear in the "nightly" docs, and I expect most people will be looking at the versioned docs.

@lhstrh Oh, I understand. Let me do that immediately.

@lhstrh Could you review this PR again?


Update: Survey and Observation Branch

Holistic update of Survey Type, Survey Method, Observation Type, and Observation Method to update via request #193
If this is approved will need to tag (at)Greenwoodmatthew and (at)CantRoger in the above pull request 193

@DavidCrosswellGSQ
When you are able can you please run a quick technical check on this request in Nick's absence? This will merge into the observations branch and pull request where the content can be reviewed.


Command to finalize pairing process

One more thing to add about pairing :)
Actually we need to run 2 commands in order to finish pairing process (at least on HERO4).
First is
https://<IP_ADDRESS>/gpPair?c=start&pin=XXXX&mode=0
And right after that finish pairing:
https://<IP_ADDRESS>/gpPair?c=finish&pin=XXXX&mode=0
For me PIN is always 4 digits (seen on Hero4).
####Problem:
####Details:

GoPro Camera(s): HERO4
Firmware Version: 4.0.0
Steps to reproduce:
Happens every time? [Y/N]: Y

Thanks, added in f35c448254de23ea315059fcadc341e585a780d3


use rustls native certs in reqwest

this allows for standards such as TLS 1.3 to be supported consistently across all platforms, while still using the system's certificate store to recieve important security updates - regardless of what we do upstream

this can also be ported over to geode-sdk/server. i can do it if you want :3

oops


krypton suite install licence

Dear Sir/Madam
After one month working with your great components, now every time I open my project  it ask for licence key.
Please help me solve this problem.
Best Regards

Hi mkarfaa,
Did you solve that problem? It's asking me for a license key too.
Regards.

Please use the 2013 branch or my fork (https://github.com/Cocotteseb/Krypton)
Once you use the correct source, delete your krypton .licx files in your projects.

Thanks a lot!
I used the fork of Cocotteseb,
then I added the DLLs from "bin/publisherSigned" and the message about licensekey did not show up any longer.
BUT: After I added the controls to the toolbox and dragged one of them to my form,
I get "LC.exe exited with code -1"
Yep, I deleted the "License.licx", which DID contain an entry for the "krypton"-comtrols.
(and I'm not using any repositry).
so I resetted my toolbox, delete any references in my project, but still get the same error and cannot compile my project since then.
Can anyone help please?

I have listed a nuget package at https://www.nuget.org/packages/KryptonWinFormControls/4.4.1
It has batch file KryptonWinFormControls.<IP_ADDRESS>\lib\net40\install krypton.bat
Update gacutil path in install.bat
and run batch file in administrator mode.
Please let me know if you still face the issue.

You can now directly clone the repo, the pull request removing all restrictions has been merged.

I just downloaded this but when i tried to drag and drop a control to my form a license screen appeared, and it's asking for a serial key. Any ideas?

I've just tested this in a fresh VM and did get no license screen. How did you install the assemblies? Did you take the ones directly in the BIN directory in this repo (not the publisher signed ones)?

I took the ones in "Bin\PublisherSigned". But it's not that important now, i dismissed that screen and conitinued without license just to try the dlls but i couldn't get them to work. Is there any documentation? i don't know how to open the "Help3.mshc" file.
El Sábado, 24 de septiembre, 2016 9:45:51, Matthias Gliwka<EMAIL_ADDRESS>escribió:

I've just tested this in a fresh VM and did get no license screen. How did you install the assemblies? Did you take the ones directly in the BIN directory in this repo (not the publisher signed ones)?—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

2016-oct-23 today i after downloaded krypton master and add krypton workspace into my form,
asked Regsitration key  .... what is Registration key ?... i deleted license.lcx !! ... project failed ..

Just add the unsigned Binaries (those in Bin, NOT in Bin\PublisherSigned). They work fine and don't Show the license screen.


[Feature Request] Ability for --delete-existing-rows and --skip-schema-files flags when using restore-dump

Currently, when making use of the restore-dump sub-command there is not an easy way for the *-schema.sql files to be skipped entirely, which would be separate from the recent --overwrite-tables flag that was recently added in, which primarily allows for existing tables to be dropped and then created again, which does not work if the branch is a production one.
A database dump generated by pscale database dump ... will generally include several files ending in -schema.sql so making use of the proposed new --skip-schema-files flag would simply add in a file filter excluding those files from being processed when making use of restore-dump.
To test a similar effect, you can simply manually remove any files ending in -schema.sql from your database dump folder and this would allow only the files containing the rows to insert to be processed.
Separately, the proposed --delete-existing-rows flag would go hand in hand with this option since it would help automate the loop for users where a DELETE query must be repeated with a LIMIT clause until the table is empty that we have as an alternative to using TRUNCATE when working with production branches. Additionally, this flag could possibly be made aware of whether a branch is a development or production one and use TRUNCATE or the DELETE loop with LIMIT clause depending on what's more appropriate.
Both of the requests above used together would help enable users to use restore-dump against a production branch and make it easier to restore a database dump from a primary production branch into a secondary staging / development branch that happens to also be a production one.
Example usage:
pscale database restore-dump <DATABASE_NAME> <BRANCH_NAME> --dir="/path/to/database/dump" --delete-existing-rows --skip-schema-files --org=<ORGANIZATION_NAME>

There is some risk with exposing flags like the ones proposed here for users, but used appropriately and with care, it should provide useful functionality simplifying the work users may have to go through in order to restore data from a database dump into a production branch if they were available.

Partially addressed by https://github.com/planetscale/cli/pull/910 once that is able to get merged in via the new --data-only flag which would allow for schema files to be skipped.
The --delete-existing-rows idea is not covered by that PR but is still mostly covered by the already existing --overwrite-tables option.


Clarify section about device env vars and bandwidth usage

Change-type: patch

@balena-ci rebase

@balena-ci I self-certify!


chore: enable tracing of function timing for debug subcommands

e.g. #[tracing::instrument] will now print the time a function spent busy and idle without having to add a timer crate or manually capture Instants
Split off from #5357
Doesn't affect any production code

Closing, I ended up using logging_timer to do this a different way, in #5375


Hide some buttons

Hi,
can we hide next,previous and other buttons?

Hi @prashanthd,
there are no buttons in this lib. You can find buttons only on the dribble shot.
Build, install and run sample app to see how it looks like or check #28, there you can find a screenshot.
Close this issue if this answer helps you.


Error installing Django from Ansible - Page 28

Hi.
In page 28 "Configure groups of servers, or individual servers" there is an Ansible code to install Django:
####################################################
ansible` app -b -m yum -a "name=MySQL-python state=present"
ansible app -b -m yum -a "name=python-setuptools state=present"
ansible app -b -m easy_install -a "name=django state=present"
###################################################
The 3th line throw the following error:
################################################################
<IP_ADDRESS> | FAILED! => {
"changed": false,
"msg": "\n==========================\nUnsupported Python version\n==========================\n\nThis version of Django requires Python 3.4, but you're trying to\ninstall it on Python 2.7.\n\nThis may be because you are using a version of pip that doesn't\nunderstand the python_requires classifier. Make sure you\nhave pip >= 9.0 and setuptools >= 24.2, then try again:\n\n    $ python -m pip install --upgrade pip setuptools\n    $ python -m pip install django\n\nThis will install the latest version of Django which works on your\nversion of Python. If you can't upgrade your pip (or Python), request\nan older version of Django:\n\n    $ python -m pip install "django<2"\nerror: Setup script exited with 1\n"
}
<IP_ADDRESS> | FAILED! => {
"changed": false,
"msg": "\n==========================\nUnsupported Python version\n==========================\n\nThis version of Django requires Python 3.4, but you're trying to\ninstall it on Python 2.7.\n\nThis may be because you are using a version of pip that doesn't\nunderstand the python_requires classifier. Make sure you\nhave pip >= 9.0 and setuptools >= 24.2, then try again:\n\n    $ python -m pip install --upgrade pip setuptools\n    $ python -m pip install django\n\nThis will install the latest version of Django which works on your\nversion of Python. If you can't upgrade your pip (or Python), request\nan older version of Django:\n\n    $ python -m pip install "django<2"\nerror: Setup script exited with 1\n"
}
#################################################################
I've tryed upgrade pip, do a symlink from pip to pip3.6, etc, with no results.

What is the full version of the OS of your servers?
On Tue, Jul 10, 2018, 06:54 dr7tbien<EMAIL_ADDRESS>wrote:

Hi.
In page 28 "Configure groups of servers, or individual servers" there is
an Ansible code to install Django:
####################################################
ansible` app -b -m yum -a "name=MySQL-python state=present"
ansible app -b -m yum -a "name=python-setuptools state=present"
ansible app -b -m easy_install -a "name=django state=present"
###################################################
The 3th line throw the following error:
################################################################
<IP_ADDRESS> | FAILED! => {
"changed": false,
"msg": "\n==========================\nUnsupported Python
version\n==========================\n\nThis version of Django requires
Python 3.4, but you're trying to\ninstall it on Python 2.7.\n\nThis may be
because you are using a version of pip that doesn't\nunderstand the
python_requires classifier. Make sure you\nhave pip >= 9.0 and setuptools

= 24.2, then try again:\n\n $ python -m pip install --upgrade pip
setuptools\n $ python -m pip install django\n\nThis will install the latest
version of Django which works on your\nversion of Python. If you can't
upgrade your pip (or Python), request\nan older version of Django:\n\n $
python -m pip install "django<2"\nerror: Setup script exited with 1\n"
}
<IP_ADDRESS> | FAILED! => {
"changed": false,
"msg": "\n==========================\nUnsupported Python
version\n==========================\n\nThis version of Django requires
Python 3.4, but you're trying to\ninstall it on Python 2.7.\n\nThis may be
because you are using a version of pip that doesn't\nunderstand the
python_requires classifier. Make sure you\nhave pip >= 9.0 and setuptools
= 24.2, then try again:\n\n $ python -m pip install --upgrade pip
setuptools\n $ python -m pip install django\n\nThis will install the latest
version of Django which works on your\nversion of Python. If you can't
upgrade your pip (or Python), request\nan older version of Django:\n\n $
python -m pip install "django<2"\nerror: Setup script exited with 1\n"
}
#################################################################

I've tryed upgrade pip, do a symlink from pip to pip3.6, etc, with no
results.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/geerlingguy/ansible-for-devops/issues/100, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABEoE3-Ar8T6fF1tfsBvkzPZ1Pvl21jDks5uFJYTgaJpZM4VJQ9a
.

(To @dglinder - The example in the book uses three Vagrant VMs running CentOS 7.)
@dr7tbien - The problem is the latest versions of Django require Python 3 (or 3.4 or later apparently)... but CentOS 7 ships with 2.7.x, and getting 3 can be burdensome ;)
So, to avoid that pain, the book was recently updated to use the following command to install Django (< version 2):
ansible app -b -m easy_install -a "name=django<2 state=present"

I'd recommend for the purposes of testing to use this command instead of installing the latest Django, mostly because it's easier on any OS that doesn't ship with the latest Python by default (most of them).
In the future, the example will be updated for some later OS version or maybe Ubuntu 18 or so, and this will be a moot point, but for now, use the less than operator to make it work.

See related: https://github.com/geerlingguy/ansible-for-devops/issues/81


ROX-11070: Add ID to group proto.

Description
A detailed explanation of the changes in your PR.
Feel free to remove this section if it is overkill for your PR, and the title of your PR is sufficiently descriptive.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

Current dependencies on/for this PR:

master

PR #2062   👈

PR #2063

This comment was auto-generated by Graphite.

/retest-required


Adding Megatron-Style input data pipelines

What does this PR do?
The current version of Nanotron's input pipelines is based on Hugging Face Datasets and relies on clm_preprocess, which tokenises and preprocesses the entire dataset at the beginning of the training (linked to the sequence_length, making it even more difficult to reuse the result across different experiments).
I have developed new data input pipelines based on those included in Megatron. Since I didn't want Nanotron to lose its essence, I removed many functionalities that we don't need (such as those related to BERT models pretraining). What I mainly modified is the torch.utils.data.Dataset, and we continue to work with the same Sampler*, Collator* and DataLoader (* I had to modify them slightly), so it doesn't alter the behavior of other modules like the PipelineEngine at all. It also allows us to continue using the previous pipeline based on Hugging Face Datasets, since I added the script run_train_nanoset.py to launch the training with the new pipeline.
Relevant details:

The new input pipelines work with the same files as Megatron. In this PR, I include references to this project to carry out the data preprocessing, although we could include them here as well. The scripts could be simplified, and necessary dependencies could be added.
I included a new configuration in the .yaml file called NanosetDatasetsArgs, which can replace `PretrainDatasetsArgs. You only need to specify the path to the dataset (generated by Megatron's preprocess_data.py, without the extension as they specify) and the distribution of the dataset samples for each of the splits (train, valid, and test) so that it sums up to 1.
The Nanoset will be the new dataset format. It is a lighter version of GPTDataset and MegatronDataset from Megatron.
To build the datasets, we will use the NanosetBuilder, which, based on a NanosetConfig (Contains NanosetDatasetsArgs + other details), will build a Nanoset for each split. In this first version, we only support one dataset file, but I will include the possibility of using multiple files (BlendedNanoset), hence preserving the NanosetBuilder.
Each Nanoset contains an MMapIndexedDataset. This object is found in indexed_dataset.py and comes from fairseq. Megatron also includes it as such.
I have added a page to the documentation with more details about the preprocessing to create the datasets and the internal functioning similar to what is included in Megatron.

I think maybe we should centralize the input data pipelines and perhaps move the dataloader.py file to another location. I also propose moving several functions from this file with the comments # Question:.
To use the Nanoset datasets, you need to specify the data_path and split fields in config.data.dataset in the .yaml file and use the script run_train_nanoset.py in the same way as run_train.py.
data:
  dataset:
    data_path: /mloscratch/homes/solergib/s-ai/nanotron/datasets/llama2/europarl-gpt-llama2_text_document
    split: 949,50,1
  num_loading_workers: 0
  seed: 1234

I've published the wandb logs of the different tests I have carried out, comparing the HF Datasets and the new Nanoset datasets with 1 and 4 GPUs and resuming training from a checkpoint.
This is a first version, I am open to all suggestions you can think of!
Toni

already integrated upstream and resolved with the most recent sync.


WindowsAppSDK1.3 : DependencyProperty::RegisterAttached is not working in WinUI3 unpackaged application

Describe the bug
When trying to registers an attached dependency property with the specified property name using the method the Microsoft::UI::Xaml::DependencyProperty::RegisterAttached() the application crashes at startup and throwing the following exception.
Exception thrown at 0x00007FF968B2CF19 (KernelBase.dll) in SampleApp.exe: WinRT originate error - 0x80040154 : 'Class not registered'. 'SampleApp.exe' (Win32): Loaded 'C:\Windows\System32\bcrypt.dll'.  Exception thrown at 0x00007FF968B2CF19 in SampleApp.exe: Microsoft C++ exception: winrt::hresult_class_not_registered at memory location 0x000000C961BCFBF0. Unhandled exception at 0x00007FF968B2CF19 in SampleApp.exe: Microsoft C++ exception: winrt::hresult_class_not_registered at memory location 0x000000C961BCFBF0.
Steps to reproduce the bug

Create a C++ WinUI3 project using "Blank App, Packaged (WinUI 3 in Desktop)" template.
Make it as unpackaged application using the steps described in the following link.
https://learn.microsoft.com/en-us/windows/apps/winui/winui3/create-your-first-winui3-app#unpackaged-create-a-new-project-for-an-unpackaged-c-or-c-winui-3-desktop-app
Registers an attached dependency property with the specified property name, property type, owner type, and property metadata for the property in MainWindow class.
Build the application.
Start the application.

Expected behavior
The application would run without crashing or throwing an error.
Screenshots
No response
NuGet package version
Windows App SDK 1.3.1: 1.3.230502000
Packaging type
Unpackaged
Windows version
Windows 10 version 22H2 (19045, 2022 Update)
IDE
Visual Studio 2022
Additional context
A sample application with the above-mentioned issue is attached.
SampleApp.zip
Any help would be greatly appreciated.

This, interestingly enough, isn't a Windows App SDK problem.
What you are seeing is the C++ static initialisation order fiasco at work. The dependency property is a static class member being initialised at global scope. The Windows App SDK bootstrap is also done as a static global variable that is in the MddBootstrapAutoInitializer.cpp file which is compiled and linked to your application when you set the WindowsPackageType project setting to none.
So when this kind of situation happens, you tend to have little control over the order that global variables initialise, this is something that is completely implementation defined. Your best option is to delay the initialisation of the dependency properties until you get to the App constructor at the very least. The other option is to take control of when the Windows App SDK bootstrapper is run and make sure that your dependency properties initialise after the bootstrapper runs.

This, interestingly enough, isn't a Windows App SDK problem. What you are seeing is the C++ static initialisation order fiasco at work. The dependency property is a static class member being initialised at global scope. The Windows App SDK bootstrap is also done as a static global variable that is in the MddBootstrapAutoInitializer.cpp file which is compiled and linked to your application when you set the WindowsPackageType project setting to none. So when this kind of situation happens, you tend to have little control over the order that global variables initialise, this is something that is completely implementation defined. Your best option is to delay the initialisation of the dependency properties until you get to the App constructor at the very least. The other option is to take control of when the Windows App SDK bootstrapper is run and make sure that your dependency properties initialise after the bootstrapper runs.

Thank you so much for your help.
The issue is fixed by initialising the static class member after the InitializeComponent() call.

This, interestingly enough, isn't a Windows App SDK problem. What you are seeing is the C++ static initialisation order fiasco at work. The dependency property is a static class member being initialised at global scope. The Windows App SDK bootstrap is also done as a static global variable that is in the MddBootstrapAutoInitializer.cpp file which is compiled and linked to your application when you set the WindowsPackageType project setting to none. So when this kind of situation happens, you tend to have little control over the order that global variables initialise, this is something that is completely implementation defined. Your best option is to delay the initialisation of the dependency properties until you get to the App constructor at the very least. The other option is to take control of when the Windows App SDK bootstrapper is run and make sure that your dependency properties initialise after the bootstrapper runs.

Thank you so much for your help.
The issue is fixed by initialising the static class member after the InitializeComponent() call.


custom render of grid checkbox  bug

It seems that custom render doen't work in w2ui 2.0 grid
More here:
https://jsfiddle.net/Lz657j3g/

If you use editable: {type: "check"}, then the grid will always create an <input type="checkbox"> field for you in getCellHTML().
This is done after the renderer has been called.
The result of your renderer will then be used as truthy-value for checking that input field or not.
That's why in your case both boxes where checked.
If you want to custom render that column, just remove the editable attribute - or override getCellHTML

Modified version without  editable: {type: "check"}, shows  context corrtetly but howto
emulate checkbox funtionality?
https://jsfiddle.net/gmut0qc7/

Well, to emulate checkbox functionality, you have to emulate checkbox functionality, that means render your column however you want and then add a delegated click event handler and toggle/flip some value and to tell the grid that the cell value has changed.
https://jsfiddle.net/an6xok90/
https://github.com/vitmalina/w2ui/assets/10152404/f3d49d3f-d306-4727-b4b1-46a830c27f06
The example is based on https://w2ui.com/web/demos/#/grid/21 (Grid Inline Editing Demo)
data-changeind and data-colInd are needed to identify the cell, just as a checkbox in w2grid does.
The relevant parts are the custom renderer:
            render( record, extra ) {
                return '' + ( extra.value ? '★' : '☆' ) + '';
            },

and the click event handler, that also updates the content of the cell:
query( grid.box ).find( '.w2ui-grid-body' ) // gridBody
    .on( 'click.body-global', { delegate : '.w2ui-editable-star' }, ( event ) => {
        const dt = query( event.delegate ).data();
        // read and toggle data-checked
        const flipped = 1 - parseInt( dt.checked, 10 );
        // update data-checked
        query( event.delegate ).data( 'checked', flipped );
        // update the star
        query( event.delegate ).html( flipped ? '★' : '☆' );
        // create INPUT field
        const input   = document.createElement( 'input' );
        input.type    = 'checkbox';
        input.checked = flipped;
        input.style   = 'display: none;';
        // grid.editChange.call( grid, event.delegate, dt.changeind, dt.colind, event );
        grid.editChange.call( grid, input, dt.changeind, dt.colind, event );
        grid.updateToolbar();
    } );

@vitmalina Feel free to add this to the demos

Nice example, thnak you a lot.


Make official process for doing point releases

Branch procedure
Make sure CI runs on branch
Make sure when branch is tagged, docker images, etc. get pushed.

I think there are some good ideas we could steal from some other projects.
For example:

Istio :: https://github.com/istio/istio/blob/master/release/create_github_release.sh
Kubernetes :: https://github.com/kubernetes/kubernetes/tree/master/build
Etcd :: https://github.com/coreos/etcd/tree/master/scripts
Jaeger :: https://github.com/jaegertracing/jaeger/tree/master/scripts/travis

I think istio's release process seems to be the closest match.

Can someone help me understand why the v1.7.1 tag didn't make it to Dockerhub? I don't see any code for skipping the publish if its a point release, AFAIK Circle gets the tag event and we run docker_tag.sh

@bndw this seems like something we should fix, given 1.7.1 was a security release. I'm going to next hop route to @ggreenway who is Envoy maintainer on-call this week, if this ends up being non-trivial one of the maintainers will pick it up.

@mattklein123 did you do anything different when creating the v1.7.1 release that would have caused it to not be picked up by CircleCI?

There was no v1.7.1 container built because the current process relies on a master build to have already created the container. We need to fix the tagging process to also do the build so it will work off a branch.

OK now this makes sense. v1.7.1 was never brought into master but rather lives in stable/v1.7.1 and the current Docker publishing code only cares about master.
If we enable Docker image publishing for branches other than master, here are a couple considerations

We must have process in place to prevent history rewriting, squash and merging, etc, else we'll have orphaned Docker image tags in Dockerhub
We should consider if we want to push images for all branches or some. e.g. should we only publish master and stable/* branches?
We should consider if including the branch name into the Docker tag is a good idea

@bndw I don't have a strong opinion here. Do you want to make a proposal based on what you think the community would most expect?

I just posted this to #envoy-users in Envoy slack. Please let me know if anyone has any feedback.
Hi Envoy users: I'm trying to finally fix our story around both 1) doing point releases and 2) making the official release docker images easier to find given poor searching on docker hub. This is related to https://github.com/envoyproxy/envoy/issues/4052. In the context of (2), I'm considering making 2 new hub repos here: https://cloud.docker.com/u/envoyproxy/repository/list, "envoy-tagged" and "envoy-alpine-tagged". We would switch our scripts to drop our tagged releases in these repos, as opposed to being mixed in with the master builds we do now. Any thoughts on this? I'm trying to break as few people as possible but make the tagged releases more discoverable. Thank you for your feedback!

A similar approach with two dockerhub repos, inspired by (2), could be as follows:
envoyproxy/envoy
Images tagged for official Envoy releases. The latest tag points to the latest Envoy release.
Examples:

envoyproxy/envoy:v1.9
envoyproxy/envoy:latest -> envoyproxy/envoy:v1.9

envoyproxy/envoy-dev
Images tagged with the GITSHA for every commit in master. The latest tag points to the HEAD of master
Examples:

envoyproxy/envoy:36f39c746eb7d03b762099b206403935b11972d8
envoyproxy/envoy:latest -> envoyproxy/envoy:c24e26fda60096a68baccc6255c2ee083095b5a4

I believe this approach would solve the main issue of too many tagged images in dockerhub and we can't find anything, while maintaining an intuitive Docker experience.

I hashed out ^ with @bndw in slack and this makes sense to me unless there are community objections. I will start working on this in parallel.


Fix bindAll usage

_.bindAll is mutable function and doesn't return any value. Variable obj is mutated and must be returned after _.bindAll call.

Thank you!

@joshkatz this fixed the issue. Can you please merge this in?

Does not seem to be merged, i dislike hardcoding this kind on thing in node_modules, what should we do?

You can get module directly from my GitHub by writing in your 'package.json':
"dependencies": {
"r-script"<EMAIL_ADDRESS>}

Thanks for your quick response, this approach is a bit more elegant, i would preffer a better solution through npm but i cannot as too much. I hope you do not delete the repository.

@joshkatz I would also like to see this patch published through NPM


Slot.onCrafted/onStackChanged are wrong

onCrafted is only called in onStackChanged, which is called from classes like BeaconScreenHandler that have nothing to do with crafting
onStackChanged is not called for most stack changes, so it has another meaning. I'm not exactly sure what it does, but it's got something to do with stack counts changing. The method gets two item stacks as parameters, and the only vanilla implementation (the default implementation in Slot itself) takes the difference of the counts and passes it to onCrafted.

I've got no idea what onStackChanged should be called, but onCrafted could be onCountChanged.

I think either onSizeChanged or onItemCountChanged would be better. It's the stack size, or item count, being changed, not the stack count (number of stacks).

is this still applicable after mojang's recent revamp on screen handlers in like 21w11a?

Okay, the original analysis might not be 100% correct. Current behaviour:

Slot.onStackChanged is still not a general stack change handler.

It's called from transferSlot implementations for output slots of various crafting blocks, but also for brewing stand inputs.
The parameters are seemingly newStack, originalStack (swapped from how they're mapped currently).
What it does is checks if there have been items taken out of the slot and if so, calls onCrafted(ItemStack, int) with the originalStack (called newItem in current mappings) and the difference between the stack sizes.
I think this is more of a "on output slot item count changed".

Slot.onCrafted(ItemStack, int) is only called by onStackChanged.

Default impl: no-op
In CraftingResultSlot, FurnaceOutputSlot and TradeOutputSlot the implementation is always the same: it increments a private amount field by the int parameter, then calls onCrafted(ItemStack) with the item stack parameter.

Slot.onCrafted(ItemStack) is only called by onCrafted(ItemStack, int) and onTakeItem implementations in those three classes.

Default impl: no-op
Implementations in those three classes: resets the private amount field to 0 and runs finalising tasks (furnace dropping XP etc)

Conclusion (needs to be confirmed with a debugger or a closer look):

All these methods relate to the player taking items out of output slots (crafting or trading).
onStackChanged is called when the item count changes in the output slot, and onCrafted(ItemStack, int) when that count decreases (= items are taken out).
onCrafted(ItemStack) finalises the output process when there's either a partial decrease (onStackChanged) or a full stack taken out (onTakeItem).
These methods still need renames.

Conclusion (needs to be confirmed with a debugger or a closer look):

All these methods relate to the player taking items out of output slots (crafting or trading).
onStackChanged is called when the item count changes in the output slot, and onCrafted(ItemStack, int) when that count decreases (= items are taken out).

The method that calls them, transferSlot, is only used for quick transfer a.k.a. shift clicking.  So, onQuickTransfer seems the most accurate to me. Parameter names were indeed switched.

This still applies to onCrafted, so reopening.


Allow list to be shown on focus, allow keyboard navigation, allow all results to be displayed

Allow the dropdown list of options to be displayed before the user starts typing values

This PR pulls in #45, #29 and an initial one by ourselves.
It adds two options to the component:
showOnFocus - Show all data properties that are tied to a list on focus
showAllResults - After typing or selecting a result still show all other options.
It also adds keyboard support.
I've not pulled across the tests from PR #29 so if somebody could do that that would be great!

I merged this into my fork of this project and published it to npm rebranded as vue-typeahead-bootstrap (to avoid collisions). https://www.npmjs.com/package/vue-typeahead-bootstrap. I hope this helps other to continue to use this tool. Thanks for the PR!


DAG - On error abandon currently running tasks

Summary
It would be extremely useful if a DAG could give up if argo already knows the end result will be failure. Currently the failFast option will stop scheduling dependencies if there has been a failure but if there are concurrently running tasks and one of them fails the others will be left to finish running before the workflow will finish.
Use Cases
I have a DAG workflow which uses RabbitMQ to pass work items between tasks. This works well with the large number of items I need to process. However if the message consumer part dies or is evicted (for example due to an OOM event) then the workflow will stall and will never finish without manual intervention.
While it would be possible to invent a way to detect this kind of failure in my message consumers and have them give up, perhaps involving a a regular heartbeat message between the message producer and consumer, Argo already knows all hope is lost so it would be much cleaner if it could just kill everything off and call it a day.
I discussed this with @sarabala1979 on one of your office hours zoom calls a couple of weeks ago.
Example workflow:
This is an extremely simple and contrived example of the kind of hang I'm hoping to avoid. The message producer pretends to have been evicted due to an out of memory event but it equally well might have crashed due to a bug. The end result is that the message consumer ends up hanging around forever waiting for messages which will never arrive.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hang-
spec:
  entrypoint: hang
  templates:
  - name: rabbitmq
    daemon: true
    container:
      image: rabbitmq:3
      startupProbe:
        exec:
          command: ['su', 'rabbitmq', '-c', '/opt/rabbitmq/sbin/rabbitmq-diagnostics status']

  - name: generate-messages
    inputs:
      parameters:
      - name: amqp-url
    script:
      image: ubuntu:20.04
      command: [bash]
      source: |
        echo Preparing to publish some messages
        apt-get update
        apt-get install -y amqp-tools
        amqp-declare-queue --url={{inputs.parameters.amqp-url}} -q workitems -d
        for i in $(seq 1 10); do amqp-publish --url={{inputs.parameters.amqp-url}} -r workitems -p -b "Work item: $i"; done
        # --== Pretend we got evicted ==--
        echo Oh no! We caused an OOM
        exit 137
        # --==          End           ==--
        amqp-publish --url={{inputs.parameters.amqp-url}} -r workitems -p -b "FINISHED"

  - name: consume-messages
    inputs:
      parameters:
      - name: amqp-url
    script:
      image: ubuntu:20.04
      command: [bash]
      source: |
        echo Preparing to consume some messages
        apt-get update
        apt-get install -y amqp-tools
        amqp-declare-queue --url={{inputs.parameters.amqp-url}} -q workitems -d
        echo Foo
        echo Bar
        while : ; do
          msg="$(amqp-consume --url={{inputs.parameters.amqp-url}} -q workitems -c 1 cat)"
          [ "$msg" == "FINISHED" ] && break
          echo "Pretending to work on: $msg"
          sleep 1
        done
        echo FINISHED!

  - name: hang
    dag:
      tasks:
      - name: mq
        template: rabbitmq
      - name: message-producer
        dependencies: [mq]
        arguments:
          parameters:
          - name: "amqp-url"
            value: "amqp://guest:guest@{{tasks.mq.ip}}:5672"
        template: generate-messages
      - name: message-consumer
        dependencies: [mq]
        arguments:
          parameters:
          - name: "amqp-url"
            value: "amqp://guest:guest@{{tasks.mq.ip}}:5672"
        template: consume-messages

What I'd like to see happen in this case is for Argo to kill the message consumer task once it's detected the failure of the message producer task. ie, once Argo knows that the dag has failed, give up. I doubt everyone wants this behaviour so perhaps it can be requested via an extension to the failFast flag.
If there are steps which have a retryStrategy set, then obviously things should keep running until the retry limit has been reached.

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

This is a good idea. We would need to terminate the running pods:
https://github.com/argoproj/argo-workflows/blob/master/workflow/controller/operator.go#L1222
I'm not sure how you'd configure it on? Perhaps spec.failFastStrategy: TerminateContainers.

Would you like to submit a PR?

I don't think I can work on it right now but if this ticket stays dormant I'll try to have a look in a few weeks time. I'm a Python person mostly so it would take me a while I suspect :)


[New Internship/Hackathon]:Devfolio Hackathon On BlockChain

Is there an existing issue for this?

[X] I have searched the existing issues

Description
I want to list the new hackathon under Devfolio which is a hackathon under Blockchain category.
The title is Onchain Summer Buildathon.
Thank You.
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

Please assign this issue to me under gssoc'24. Also add the gssoc and level labels


Update to more recent LLVM

We can ignore the status checks here. They shouldn't be triggering on this PR at all. I just tweaked the  BuildKite pipeline in a way that hopefully it should stop doing that. The GitHub actions workflow is already deleted on the main branch. Really having this in a separate branch of the same repo is a hack, so not quite sure how to get it to behave.

I ran bazel build --config=generic_clang @llvm-project//llvm:NVPTXCodeGen (since that was the target failing in TF).
Running bazel build --config=generic_clang @llvm-project//... fails on my end
ERROR: /usr/local/google/home/mihaimaruseac/.cache/bazel/_bazel_mihaimaruseac/72d11c4dfc9b1a3c3ec48afbb7d953e7/external/llvm-project/llvm/BUILD:3395:1: in binary_alias rule @llvm-project//llvm:llvm-addr2line:
Traceback (most recent call last):
        File "/usr/local/google/home/mihaimaruseac/.cache/bazel/_bazel_mihaimaruseac/72d11c4dfc9b1a3c3ec48afbb7d953e7/external/llvm-project/llvm/BUILD", line 3395
                binary_alias(name = 'llvm-addr2line')
        File "/usr/local/google/home/mihaimaruseac/.cache/bazel/_bazel_mihaimaruseac/72d11c4dfc9b1a3c3ec48afbb7d953e7/external/llvm-project/llvm/binary_alias.bzl", line 14, in _binary_alias_impl
                ctx.actions.symlink(<3 more arguments>)
symlink() got unexpected keyword argument 'target_file'
INFO: Repository remote_coverage_tools instantiated at:
  no stack (--record_rule_instantiation_callstack not enabled)
Repository rule http_archive defined at:
  /usr/local/google/home/mihaimaruseac/.cache/bazel/_bazel_mihaimaruseac/72d11c4dfc9b1a3c3ec48afbb7d953e7/external/bazel_tools/tools/build_defs/repo/http.bzl:336:16: in <toplevel>
ERROR: Analysis of target '@llvm-project//llvm:llvm-addr2line' failed; build aborted: Analysis of target '@llvm-project//llvm:llvm-addr2line' failed
INFO: Elapsed time: 5.433s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (26 packages loaded, 9322 targets configured)

Are you running with an old version of Bazel? Looks like the API was finalized in 3.2
https://docs.bazel.build/versions/3.1.0/skylark/lib/actions.html#symlink
vs
https://docs.bazel.build/versions/3.2.0/skylark/lib/actions.html#symlink
If you're running the demo, the .bazelversion should ensure that it's 3.3.1

Oh, I'm using TF's Bazel, 3.1.
Let me upgrade.

With Bazel 3.7 it is building
INFO: Elapsed time: 1246.247s, Critical Path: 171.34s
INFO: 10641 processes: 2157 internal, 8484 linux-sandbox.
INFO: Build completed successfully, 10641 total actions

Thanks!


⚠ Bofrost.de has degraded performance

In bddabfa, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1201 ms

Resolved: Bofrost.de performance has improved in 6eb752b after 6 minutes.