Add fusion installation

Add small description to install the plugin with Fusion

Thanks for this, will look at reviewing and getting it in soon.  I definitely agree installation instructions for Fusion are needed.

Hi @Gil-1
Will be there at next release!
Cheers
Cedric

Great news :)
Thanks !

Hi all!
The README of 1.2.0.b6 now holds a 3 step explanation on how to install cryptomatte!
Cheers
Cedric

Thanks !


jsdoc

Describe the feature
Please tell me how to configure it so that jsdoc can be retained during packaging.
Additional information

[ ] Would you be willing to help implement this feature?

config
export default defineBuildConfig({
entries: [
'src/index',
'src/cli/index',
],
declaration: true,
clean: true,
rollup: {
emitCJS: true,
},
})

@coderbaozi because unbuild uses esbuild for bundling, I don't think there a global way to retain JSDoc comments.
What you can do, is to add the @preserve tag to those comment blocks you want to keep. For example:
/**
 * A log Function
 * @param  {...any} args Arguments to log
 * @returns {void}
 * @preserve
 */
export const log = (...args) => {
  console.log(...args);
};


Svg sources

Would be awesome to open source the vector sources (.svg, .ai) as well !

there are simply no vector sources. They are derivatives of the official marker present in leaflet with some color shifting.

Could you maybe explain, how you did the change? I'd like to have a marker with a special RGB color and would like to know how to reproduce this. Thanks :-)


NO-TICK: remove channel override from drone

same as https://github.com/CasperLabs/website/pull/65

bors r+


RuntimeError: CUDA error: no kernel image is available for execution on the device

Hi, I have cuda 11.7 on my system and I am trying to install functorch, since the stable version of pytorch for cuda 11.7 is not available here, I just run pip install functorch which also installs the compatible version of pytorch.
But when I run my code that uses the GPU, I get the following error :
RuntimeError: CUDA error: no kernel image is available for execution on the device
Is it possible to use functorch in my case?

I followed this recommendation, I used the supported binary with CUDA 11.3  by runing this command : pip install --pre torch -f https://download.pytorch.org/whl/nightly/cu113/torch_nightly.html --upgrade

Ah I see. My hypothesis is that your functorch version and pytorch version are incompatible. If you installed PyTorch via pip install --pre torch -f https://download.pytorch.org/whl/nightly/cu113/torch_nightly.html --upgrade, then you have a nightly version of PyTorch.
To install functorch with a nightly version of PyTorch you'd want to install functorch from source:
pip install ninja  # Makes the build go faster
pip install --user "git+https://github.com/pytorch/functorch.git"

That's exactly what I did

Can you please print out the following:
import torch
import functorch
print(torch.__version__)
print(torch.version.cuda)
print(functorch.__version__)

? Also, are you getting RuntimeError: CUDA error: no kernel image is available for execution on the device when you use only PyTorch and no functorch?
For some more context: functorch is CUDA agnostic (it doesn't have any CUDA-specific code), so it's most likely PyTorch that has problems with your CUDA setup.

That's what I did the first time, I've installed functorch on a venv from source as described on your Readme, by doing :
pip install --pre torch -f https://download.pytorch.org/whl/nightly/cu113/torch_nightly.html --upgrade pip install ninja  # Makes the build go faster pip install --user "git+https://github.com/pytorch/functorch.git"
I got a wheel building error as you can see on this picture :

After that, I started a new venv and directly installed functorch with pip install functorch but it seems that the torch version installed by default is incompatible with cuda 11.7.Here is by order, the output of prints :
1.12.1+cu102
10.2
0.2.1

pip install functorch installs functorch 0.2.1 which is going to pull in PyTorch 1.12.1 with cu102 support. What you really want is to install PyTorch 1.12.1 with cu113 support. Could you please try the following?
pip install torch --extra-index-url https://download.pytorch.org/whl/cu113
pip install functorch

It worked, thanks for your help

Glad to hear. We're working on making installing both pytorch and functorch easier. Please let us know if you have any other feedback.


Updating retrier function runtime from v14 to v18.

Updating retrier function runtime from v14 to v18.
I received the following email from AWS regarding the end-of-support for v14.

We are contacting you as we have identified that your AWS Account currently has one or more Lambda functions using the Node.js 14 runtime.

We are ending support for Node.js 14 in AWS Lambda. This follows Node.js 14 End-Of-Life (EOL) reached on April 30, 2023 [1].

As described in the Lambda runtime support policy [2], end of support for language runtimes in Lambda happens in two stages. Starting November 27, 2023, Lambda will no longer apply security patches and other updates to the Node.js 14 runtime used by Lambda functions, and functions using Node.js 14 will no longer be eligible for technical support. In addition, you will no longer be able to create new Lambda functions using the Node.js 14 runtime. Starting January 25, 2024, you will no longer be able to update existing functions using the Node.js 14 runtime.

We recommend that you upgrade your existing Node.js 14 functions to Node.js 18 before November 27, 2023.

End of support does not impact function execution. Your functions will continue to run. However, they will be running on an unsupported runtime which is no longer maintained or patched by the AWS Lambda team.

Closed in favour of https://github.com/sst/sst/pull/3266


Allow charts in other directories

Right now, if you have you chart in a directory other than charts/, you cannot use Draft.

What would you like for the behavior to be? Can you give an example of your use case?

For example, the OSBA project has the chart under contrib/k8s/charts/open-service-broker-azure.
The first use case would be to specify in draft.toml the relative path that doesn't necessarily have to be under charts/.
(The other use case, which is a separate issue, would be to add in  draft.toml a remote chart - however that is tracked in #732 )

gotchya yea that makes sense to me!


Analytic not starting

I migrate to the newest version v1.219.0 and suddenly its not working anymore if i call supabase start.
Screenshots
If applicable, add screenshots to help explain your problem.
System information
Rerun the failing command with --create-ticket flag.

Ticket ID:  a6c49671d4a9479891ce80100b09f932

Version of OS: Windows 11

Version of Docker: where to check=

Versions of services:
SERVICE IMAGE      │      LOCAL       │   LINKED

supabase/postgres      │ <IP_ADDRESS>       │ <IP_ADDRESS>
supabase/gotrue        │ v2.163.2         │ v2.163.2
postgrest/postgrest    │ v12.2.3          │ v12.2.3
supabase/realtime      │ v2.30.34         │ -
supabase/storage-api   │ v1.11.14         │ v1.11.14
supabase/edge-runtime  │ v1.61.0          │ -
supabase/studio        │ 20241106-f29003e │ -
supabase/postgres-meta │ v0.84.2          │ -
supabase/logflare      │ 1.4.0            │ -
supabase/supavisor     │ 1.1.56           │ -

can i reset it?
tried docker system prune -a but error remains

ok duplicate https://github.com/supabase/cli/issues/2737
is just fixed it with supabase stop --no-backup


Fix install.sh/upgrade.sh for tput-less systems

@fcrozat's original fix assumes which not to output anything to STDOUT
in case the command is not found. That is not necessarily true on all
systems. A better solution is to check the return value instead.
Fixes #4376.
Supersedes #4496.

Good job @WhyEee, merging as per https://github.com/robbyrussell/oh-my-zsh/pull/4496#issuecomment-148749806. Works well :+1:


56 style errors when building project in Flutter 2.5.1

Description
There are 56 style errors when building in latest Flutter
Screenshots
Upload the current working screenshots here.

Steps to Reproduce
Please provide detailed steps for reproducing the issue.

Update Flutter
Check errors

Additional data
I would like to update the app and submit a PR

@CarltonBranch , it's the duplicate of #99


Advanced test environment

This is PR for this issue: https://github.com/Supercolony-net/openbrush-contracts/pull/136#issuecomment-1167236655
that was started in https://github.com/Supercolony-net/ink/pull/4

[x] Add support of call_flags
[x] Error & revert handling

While calling fallable from Fallback Contract I got Contract trapped during execution. Why MainContract::inc: NotCallable' isn't callable.

@123oli did you deploy the main contract? Is the account you are calling indeed the main contract's account id?

@123oli did you deploy the main contract? Is the account you are calling indeed the main contract's account id?

Yes, I have deployed main contract as well and while deploying fallable contract I indeed choose main contract's account id.

@123oli but actually you can't just set the callee as AccountId for fallback contract, because as you can see, inside of contract it's type is MainContractRef, anyway that's a good point to change the way it works, so everybody could test it on-chain

@123oli but it is still AccountId, you can see the type of variable in UI. Also, I've changed the way contracts are deployed and added README, so you can use guide from there. But if you try to just call fallback as you described previously, it won't work, because reentrancy will occur in fallback contract, which is not allowed, so you can try to just call main contract first, and then you will be able to call fallback method directly.


update experiments.py: plenty of docs.

Types of changes

[x] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue
Docs are now visible on the dashboard, so more doc ==> more cool.
How Has This Been Tested (if it applies)

Checklist

[x] The documentation is up-to-date with the changes I made.
[x] I have read the CONTRIBUTING document and completed the CLA (see CLA).
[x] All tests passed, and additional code has been covered with new tests.

@jrapin  I modified; ok under this form ?


Command failed error appears when running ansible-lint (This is a specification)

Description
If there are syntax errors  problems, you will get a very unimpressive error message. I was surprised to see a bright red error screen. :(
It would be nice if the language server side, could handle it properly... :(
coc-ansible

Same for "VSCode" (vscode-ansible)

I think if you can get ansible-language-server's ansibleLint.ts to handle it properly without using window.showErrorMessage, this problem will be solved.
https://github.com/ansible/ansible-language-server/blob/main/src/services/ansibleLint.ts#L133-L135
// ...snip
      } catch (error) {
        if (error instanceof Error) {
          const execError = error as ExecException & {
            // according to the docs, these are always available
            stdout: string;
            stderr: string;
          };
          if (execError.code === 2) {
            diagnostics = this.processReport(
              execError.stdout,
              await ansibleLintConfigPromise,
              workingDirectory
            );
          } else {
            // Here
            this.connection.window.showErrorMessage(execError.message); // <-- Here
          }

          if (execError.stderr) {
            this.connection.console.info(`[ansible-lint] ${execError.stderr}`);
          }
        } else {
          this.connection.console.error(
            `Exception in AnsibleLint service: ${JSON.stringify(error)}`
          );
        }
      }
// ...snip

I reported an issue (feature request) to ansible-language-server

It is likely to be adjusted in the future.

https://github.com/ansible/ansible-language-server/issues/21


[feature request] Run shellcheck (or equivalent linter) on individual steps

Is your feature request related to a problem? Please describe.
There are lots of subtle issues related to executing bash. However, because Github Actions uses YAML you lose useful shell linting options.
Today, I ran into a set of issues with bash environment variables. Here is a script with some nonintuitive (for me at least) behavior:
export env=prod
echo "${env}"              # => prod
env="uat" echo "${env}"    # => prod
env="uat" && echo "${env}" # => uat

The Shellcheck VS Code extension actually catches this issue, but you can't use it from Github Actions because the shell is embedded in the YAML.
Here are the linting warnings provided by Shellcheck's VS Code extension for shell files:

Describe the solution you'd like
I would like to see the linting warnings from Shellcheck appear in the Github Actions steps.

Please let me know if additional clarification is required.
Additional context

Shellcheck - Homepage
Shellcheck - VS Code Extension

Hey, this seems like a very interesting feature idea, but upon first reading, I think there are complexities that make it more challenging to implement than it seems at first sight

Do we need to require that anyone who installs the actions linter also installs shellcheck?
Do we need to provide configuration to allow users to add a shell linter instead?
How do we know if the command is running in a bash vs zsh vs some other form of shell in the yaml, e.g. if someone is using a windows runner?
What are limitations present in workflow runs that aren't in traditional shells? Do we need to lint those too to avoid unexpected behaviors?

I don't think its unachievable but I do think its the type of thing that requires careful thought and design, and is probably out of scope for where this project is right now. That said if someone submitted a PR that did this, I'd certainly review it.

Those are great points! I hadn't considered Windows runners and I wasn't aware that you could change the shell type in other OSes. It does seem the linter would need to be context sensitive and rely on environment information, but I don't know how the extension is architected so that may be infeasible.
I'm pretty swamped right now so I don't think this is the sort of thing I could reasonably contribute to. Maybe in the future.
Thanks for the response!

So if it's something you might visit in the future, or would welcome a PR for, why would you close the issue suggesting it?  Leaving the issue open indicates that it's something that could be considered for development.
What if somebody who wants to contribute to this project comes along looking for issues that need some time put into them?  They certainly won't find this one as it's closed.
So again, why close this issue?

For anyone else coming across this issue, there is a more generic request for any appropriate linter to be used on a run: script, based on the default shell for the platform and/or defaults.run.shell is in #114.  It was also closed as "complicated" and related to this issue.  While #114 is a more comprehensive implementation and doesn't just work when the shell is the borne [again] shell, this one has a nice description of the general idea.

So if it's something you might visit in the future, or would welcome a PR for, why would you close the issue suggesting it? Leaving the issue open indicates that it's something that could be considered for development.
What if somebody who wants to contribute to this project comes along looking for issues that need some time put into them? They certainly won't find this one as it's closed.
So again, why close this issue?

In general, we try to keep open issues for work we're actively tracking or that we intend to do. Even if someone opened a PR for this there's no guarantee we'd merge it in because there's a lot of complexity involved in both maintenance burden and generally figuring out usability and dependencies. I don't want to leave it open and have someone pour their effort into a PR without a guarantee we'd actually merge it.
So yeah, sorry, I know that's disappointing to hear, it's really not a ding on the idea. If we had unlimited time and engineers I'm sure its something we'd want to explore.

Looks like the only workaround here is to put shell script into separate .sh file and reference it.

Looks like the only workaround here is to put shell script into separate .sh file and reference it.

Indeed.  Buy that gets very messy very quickly as it means that in the case of duplicating workflows across projects (or even better, using reusable workflows) you now have to duplicate (and maintain!!!!!) all of the separate script files across all of the repos that you are duplicating (or using reusable) workflows across.
It would sure be helpful if such external scripts could be maintained alongside resuable workflows so that those workflows and their scripts were all maintained in a single place, but the only way to really do that is to break out every step you refer to a script in into an action that you can run with uses: in the reusable workflow.  Something else that gets very messy very quickly.


use #with_channel rather than maintaining a persistent channel and exchange

https://github.com/jondot/sneakers/issues/192

Ow, looks like a lot of the tests didn't behave too well. The change itself looks good to me. Anyone else?

Using with_channel isn't critically important. I don't really object to it either.
What worries me is how many tests use mocks. Bunny uses no mocks.

Previously the Bunny::Session instance was only used in #ensure_connection! which in most examples was mocked out of the execution path (mock(p).ensure_connection! {}).  So now the extra mocking of Bunny is required due to the usage of @bunny.with_channel in the #publish method.  We're unit testing Sneakers here, not Bunny, so IMO these mocks are required.

@veetow question - do you somehow pool/cache your publisher? I'm wondering if you are still happy with a cached publisher that uses a single persistent connection. One that closes/opens one per message sounds a bit strange, I'm not sure what's the effect of this on RabbitMQ...

@jondot, I was not keeping a persistent publisher because I assumed that configuring a persisted Bunny::Session was good enough.  I've made some improvements to my code since, but I still think that using #with_channel here is more flexible and fool proof.  There's really no advantage to a long-lived channel.

Thanks @veetow, I am still wondering if opening/closing the connection for high rate of publishing repeatedly is thrashing RMQ. @michaelklishin is there any such effect that you know of by a chance ?

You mean by opening and closing the channel (not the connection)? Nope, as channels are multiplexed across the single connection.  Via Sneakers.configure I am passing in an existing Bunny::Session so there is no connection tear-down/set-up.

This goes against how most messaging protocols are supposed to be used, and AMQP 0-9-1 in particular. I understand what kind of improvement this offers but opening a new channel per message will severely drop throughput (as it is a network roundtrip before you can do anything, in fact, in this case it is two because the new channel instance won't have the exchange cached!).


Remove the legacy routeagent code

Since we are now using the updated routeagent code that uses
the event interface framework, this PR removes the previous
implementation which is no longer used.
Related to: https://github.com/submariner-io/submariner/issues/858
Signed-Off-by: Sridhar Gaddam<EMAIL_ADDRESS>

@SteveMattar FYI


[Bug] support deleteMany for serverless option

Is this a new bug?

[X] I believe this is a new bug
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
I am trying to test the serverless option as we are using a bunch of indexes in our organization. For us is mandatory to delete or at least locate vectorIds by metadata. Are these limitations permanent?
https://docs.pinecone.io/docs/limits#serverless-index-limitations
During ingestion we associate document information that then need to locate all chunks from there during a delete operation.  Now we are using a filter like
...
  const filter = {
    id: identifier
  };
...
await namespace.deleteMany(filter);

Expected Behavior
Followed the comments from here but still cannot locate the vectors I need to delete.
https://docs.pinecone.io/docs/manage-rag-documents#fetch-all-records-for-a-parent-document
Steps To Reproduce
create a serverless index, try to delete some vectors by some metadata
...
  const filter = {
    id: identifier
  };
...
await namespace.deleteMany(filter);

Relevant log output
No response
Environment
- **OS**: windows 10
- **Language version**: nodejs 18
- **Pinecone client version**: 2.0.0

Additional Context
Would like to know the timeframe for this support as without this option is not possible to evaluate the new serverless option.
Besides would be nice to have a method on the namespace to be able to list documents, otherwise extrametadata is needed to do a POST as detailed here, we do not have the metadata to fully locate the index location
https://docs.pinecone.io/docs/manage-rag-documents#fetch-all-records-for-a-parent-document
In short for the library it would be grat to

support the same options as non serverless for delete operations
otherwise provide an option to get ids from metadata to then do the deletion manually. That again, could be wrapped in the library.

standing by, thanks in advance

any comment on this issue? a little concerned to know this is on the roadmap on the serverless indexes.

I'm getting this error when calling deleteMany with a metadata filter on a serverless index:
PineconeBadRequestError: Filters in this operation are not supported by the current index type 'Starter'.

I am getting the same issue on the Standard Plan using serverless. I believe this was working last week however when I originally switched.

I suspect the error is just misleading - just means that filters are not supported in deleteMany operation, regardless of your plan

I have not followed this case, is there any advance to be able to delete vectors by metadata for serverless? Is it no the roadmap?
Your feedback is important for us to analize options. thanks in advance

This is currently a limitation of serverless, though it's on our roadmap to address. We'll circle back once this has been completed. Thanks!


Fix annoying run-time warning

Automated message from Dropbox CLA bot
@borisyankov, it looks like you've already signed the Dropbox CLA. Thanks!


PuppeteerSharp.ResponseData Read-Only

It appears that PuppeteerSharp.ResponseData properties are read only.  I am trying to return a response in the request interception but it is not allowed to set the Status and Body properties.
await e.Request.RespondAsync(new PuppeteerSharp.ResponseData
{
Status = HttpStatusCode.OK,
Body = intermediateHtml.ToString()
});

@vbisbest take a look at this test https://github.com/kblok/puppeteer-sharp/blob/d432f026d78c1dede71b3c2f401feb81d30c334f/lib/PuppeteerSharp.Tests/NetworkTests/RequestRespondTests.cs#L23

Sorry, was on older version of puppeteerSharp.  Thanks!


Automated cherry pick of #11320 upstream release 1.0

cc/ @thockin @robertbailey @zmerlynn

Will re-do this.


az storage account list - Parameter 'resource_group_name' must have length less than 90.

This is autogenerated. Please review and update as needed.
Describe the bug
When you run the command with the subscription parameter and  without the resource-group parameter it results in an error. The same error occurs if you run the command without any parameters.
Command Name
az storage account list
Errors:
ValidationError: Parameter 'resource_group_name' must have length less than 90.

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az storage account list --subscription {}

Expected Behavior
List all storage accounts in a subscription.
Environment Summary
Windows-10-10.0.18362-SP0
Python 3.6.8
Installer: MSI

azure-cli 2.17.1 *

Extensions:
interactive 0.4.4

Additional Context

storage

storage

Hi @dmraymond, have you ever configure group with az configure or local context?
Could you also add --debug in your command and share debug info?

Just prior to running the command I do run "az account set --subscription {}" but I do not set the resource group or set any persistent parameters. I ran the command again today and it is not throwing an error. I am attaching the debug log just in case.
debug.log

Thanks for your feedback. There is no special issue in your log. But if you still get the issue, you could create a new issue with debug log.


And ruby 2.5, update others, in travis config

I also removed ruby 2.0.0 from the build matrix - it has been failing on rails 4.2 for a while now and has been unsupported for 2 years.
Is it time to update the gemspec to only support ruby 2.2 going forward, or what will be the cutoff for that?

@lostapathy I think it would be good to set minimum required version in the gemspec when dropping 2.0.
And I think it makes sense to drop unsupported rubies when they stop working or cause too much maintenance burden, which is not the case for 2.1 yet, right? Also I think formtastic should be supporting the same rruby versions as supported versions of rails.

@mikz Ruby 2.1 support ended almost a year ago, and 2.2 is slated to end next month, see https://www.ruby-lang.org/en/news/2017/04/01/support-of-ruby-2-1-has-ended/
I really like restricting gemspecs to match what we're willing to keep working on Travis, and I see little reason to keep support for unsupported rubies (or other dependencies) except in pretty extreme circumstances.  Gem developers should spend their precious time looking forward, not supporting software it's own maintainer has walked away from.
I'll update this PR to remove ruby-2.1 and update the gemspec to match.  I'll save it for another PR, but perhaps it's also time to restrict the other dependencies (mainly rails stuff) to only supported versions of rails as well?

@lostapathy if ruby 2.1 works with supported rails versions then formtastic should support it too. And formtastic 4.x is going to support  Rails >= 4.1, so we definitely are not dropping Ruby 2.1 anytime soon. It would make sense only if it breaks and it would take too much time to fix.
Ruby >= 2.1 sounds good to me. And >= 2.2 when we drop Rails 4.2 support. But could be done faster if it breaks sooner.
We can reconsider when supporting old versions actually causes some maintenance, but right now it really doesn't so I'd try to not break things if possible.

Thanks @mikz - I have updated this as suggested.

@lostapathy thank you very much!


Corrected Windows Alternative Babel Build Process

In the readme documentation there is a sub-process detailed for Windows users when it comes to the Babel build process as seen here:

This is currently broken on Windows. On Windows please run the following commands separately instead: bower install, babel -w scripts -s --retain-lines -d lib and firebase serve.

However with the project directory structure, this will fail if followed directly as stated with an error stating:
C:\..\friendlypix-web>babel -w scripts -s --retain-lines -d lib scripts doesn't exist
I would like to suggest updated steps to read:
bower install, cd public, babel -w scripts -s --retain-lines -d lib and firebase serve.
This addition of the cd public command will resolve this issue as seen above

Nice one Tom , much appreciated

I updated the instructions :)


Tests: adjust the expectations for Windows

Windows spells paths with \ as the path arc separator rather than /. Adjust the expectations to account for this.

@swift-ci please smoke test

@swift-ci please test Windows platform

@swift-ci please clean test Windows platform


[buildmgr] IAR compile flag issue for preinclude file

Describe the bug
In IAR, for preinclude file, the compile flag is --preinclude <preinclude.h>. In the generated compile_commands.json, it uses '-include' which is for ARMCLANG, like
.
This error generation will result in build error like

To Reproduce
Steps to reproduce the behavior:
Use csolution to generate IAR build target with Pre_Include_Global element in related packs.
Expected behavior
A clear and concise description of what you expected to happen.
Environment (please complete the following information):

[tool or library] csolution/cbuild
Version [e.g. v0.0.3] 1.6 for csolution; 1.6.1 for cbuild
OS: [e.g. windows/linux/darwin] Windows

Additional context
Add any other context about the problem here.

Hello @tcsunhao,
you are right:
there was this PR https://github.com/Open-CMSIS-Pack/devtools/pull/734 to fix the command line
however it seems this PR https://github.com/Open-CMSIS-Pack/devtools/pull/798 did revert it again.
@JonatanAntoni and @jlonnberg could you please investigate what happened here?

@jkrech I have an pending update for the IAR toolchain file in the near future, I'll include this for that!

This slipped through the review, I guess. Unfortunately, we don't have CI for IAR Compiler integrated. @jlonnberg, any updates about running IAR Compiler within GitHub Actions? Would it be possible to provide IAR Compiler via vcpkg similar to Arm Tools?

@JonatanAntoni Our PM for licenses are working on this atm, but I haven't heard anything concrete yet. I'll keep you notified.
Moreover, I'm running continuous integration tests each night based on the main branch but I have yet to include a test that tests this. I'll most likely add one when fixing the problem.


Documentation for SelfTargetExecutor

Summary
@yahoo/ychaos-dev
Adding SelfTargetExecutor docs
Fixes: #12

Checklist
Checklist (Developer)
Prerequisites

[x] I have read the contribution guidelines

Code Analysis

[ ] Covered by Unittests
[ ] Security warnings ignored (Why?!)

Project related

[ ] Schema changed and is backward compatible.
[ ] Introduces a new sub-command for ychaos CLI

Autogenerated Files

[ ] Auto generated schema

Pre-Merge Checklist

[ ] All the build jobs are passing

Checklist (Reviewer 1)

[ ] Reviewed Source Code
[ ] Reviewed Tests (If applicable)
[ ] Reviewed Documentation (If applicable)

Checklist (Reviewer 2)

[ ] Reviewed Source Code
[ ] Reviewed Tests (If applicable)
[ ] Reviewed Documentation (If applicable)

@AlfinST Please add example usage as well to the documentation


Exception Errors in Chapter 3: Could be newbie error as well

I'm going through this book and running the code as I go. I am running into the following issue:
ALL DONE Exception ignored in: <function RolloutWorker.__del__ at 0x7fb2260368c0> Traceback (most recent call last):   File "/home/rustykettle/.local/lib/python3.10/site-packages/ray/util/tracing/tracing_helper.py", line 461, in _resume_span TypeError: 'NoneType' object is not callable
The ALL DONE is my print:
ray.init()
gymEnv = GymEnvironment()
trainer = DQNTrainer(env=GymEnvironment, config={"num_workers": 4})  # <1>
config = trainer.get_config()  # <2>
#print(pretty_print(config))

for i in range(10):
    result = trainer.train()  # <3>

ray.shutdown()
print(pretty_print(result))  # <4>
print("ALL DONE")

It is to show that the exception is something to do with Ray, but it also might have something to do with my configuration. I followed the book very closely, but I'm not discounting a user-error on my part.
output.log
I'm also getting depreciation warnings that don't appear in the log. I'm imagining that this happens because it is happening on a different thread.

Another quick observation. This doesn't happen when running via the cmd_line using the yml method, so it further points to something acting up in my script.

More observations. It still happens with the multiagent example, and when updating to Ray 2,0.

hey @RustyKettle, by now we've rewritten a substantial part of this chapter due to lots of API changes. I ran the examples locally and on colab and so far don't see any problems. Closing this issue for now, but please feel free to reopen if your problems persist!


Gatsby example does not load

I was firing up your Gatsby Example in the repo and it does not load. See below for error output

[x] This is a v1.x issue (v0.x is no longer maintained).
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior
NPM run develop should boot a server with gatsby. It does not.

Current Behavior

Compile fails, reports:
  Error: Module build failed: ReferenceError: Unknown plugin "@babel/plugin-transform-object-assign" specified in "(...)/material-ui/.babelrc" at 0, attempted to resolve relative   to "(...)/material-ui"

  - option-manager.js:180
    [gatsby]/[babel-core]/lib/transformation/file/options/option-manager.js:180:17

  - Array.map

  - option-manager.js:158 Function.normalisePlugins
    [gatsby]/[babel-core]/lib/transformation/file/options/option-manager.js:158:20

  - option-manager.js:234 OptionManager.mergeOptions
    [gatsby]/[babel-core]/lib/transformation/file/options/option-manager.js:234:36

  - option-manager.js:368 OptionManager.init
    [gatsby]/[babel-core]/lib/transformation/file/options/option-manager.js:368:12

  - index.js:212 File.initOptions
    [gatsby]/[babel-core]/lib/transformation/file/index.js:212:65

  - index.js:135 new File
    [gatsby]/[babel-core]/lib/transformation/file/index.js:135:24

  - pipeline.js:46 Pipeline.transform
    [gatsby]/[babel-core]/lib/transformation/pipeline.js:46:16

  - index.js:46 transpile
    [gatsby]/[babel-loader]/lib/index.js:46:20

  - fs-cache.js:79
    [gatsby]/[babel-loader]/lib/fs-cache.js:79:18

  - fs-cache.js:15 ReadFileContext.callback
    [gatsby]/[babel-loader]/lib/fs-cache.js:15:14

Steps to Reproduce (for bugs)

Clone this repo
cd to gatsby example
npm i
npm run develop

Context

I'm trying to fix the flicker of unstyled on my gatsby site. I'd like an example to work from
Your Environment

MacOS 10.13.5
Node 8.11.1
NPM 6.1.0

@mbuttler Thanks for reporting the issue!


je ne peux plus ouvrir de consoles

<!---   *** BEFORE SUBMITTING: PASTE CLIPBOARD HERE TO COMPLETE YOUR REPORT ***   ---!>

Hey @anoukandre, thanks for reporting. It seems you're using a very old Spyder version (probably five years old or more). So, please install a more recent version by following the instructions in our documentation.


[DEV-1096] Fix pipelines

Task linked: DEV-1096 Create release candidate branches for April On Chain Upgrade + document processes


CFE_SB_Default_Qos exposed globally, with internal defaults, passing structure by value

Is your feature request related to a problem? Please describe.
CFE_SB_Default_Qos is extern from cfe_sb.h (so any code including cfe_sb.h could change it's value!):
https://github.com/nasa/cFE/blob/c7363c8d0bfbc0ce8d404799c64defe3cb171616/fsw/cfe-core/src/inc/cfe_sb.h#L175-L185
But the defines are "internal" to SB:
https://github.com/nasa/cFE/blob/c7363c8d0bfbc0ce8d404799c64defe3cb171616/fsw/cfe-core/src/sb/cfe_sb_priv.h#L86-L87
Also structure passed by value:
https://github.com/nasa/cFE/blob/c7363c8d0bfbc0ce8d404799c64defe3cb171616/fsw/cfe-core/src/inc/cfe_sb.h#L381
There is no underlying implementation, so currently just a placeholder in the API.
Describe the solution you'd like
Possibly convert to bits in a uint32/16 or similar (structure is overkill), provide default and the other values publicly as defines, don't expose as a global variable.
Describe alternatives you've considered
None
Additional context
Found when working #1036, it's out of family since it's not at task global scope.
Requester Info
Jacob Hageman

@ejtimmon Note CFE_SB_Default_Qos is referenced by ds and hs (and in sch test utils)

@ejtimmon Note CFE_SB_Default_Qos is referenced by ds and hs (and in sch test utils)

Passing by value is generally OK so long as the structure is small (i.e. 32 bits or less) in case the calling convention in use relies on register(s) to pass argument/return values.  However if it grows larger it can become inefficient to pass by value.
IIRC the one I was worried about before was CFE_TIME_SysTime_t - this is passed by value and it is 64 bits in size, therefore could be inefficient on 32-bit machines depending on the calling convention and particularly the return value.
But this one is only 16 bits so its probably fine.  But it would be a good idea to note in the structure/declaration comments that it is passed by value and therefore needs to be kept small for this reason - so fields shouldn't be added without careful consideration.

Passing by value is generally OK so long as the structure is small (i.e. 32 bits or less) in case the calling convention in use relies on register(s) to pass argument/return values.  However if it grows larger it can become inefficient to pass by value.
IIRC the one I was worried about before was CFE_TIME_SysTime_t - this is passed by value and it is 64 bits in size, therefore could be inefficient on 32-bit machines depending on the calling convention and particularly the return value.
But this one is only 16 bits so its probably fine.  But it would be a good idea to note in the structure/declaration comments that it is passed by value and therefore needs to be kept small for this reason - so fields shouldn't be added without careful consideration.

I understand it's OK in this case since it's small, but the extra caution/complexity and currently implementation really doesn't seem justifiable based on a lack of implementation.  I'd think a generic uint and setting bits is a more flexible, future proof implementation that needs no special note.  Could easily add implementations as modules and assign more bits (or have reserved/user defined bits), etc without having to redefine the elements in the structure (until bits run out).

I understand it's OK in this case since it's small, but the extra caution/complexity and currently implementation really doesn't seem justifiable based on a lack of implementation.  I'd think a generic uint and setting bits is a more flexible, future proof implementation that needs no special note.  Could easily add implementations as modules and assign more bits (or have reserved/user defined bits), etc without having to redefine the elements in the structure (until bits run out).

Sure, bit fields in an integer could work too - but then you lose the advantage of type safety protection from having it as a struct.  That is, one has to declare their local variable as a CFE_SB_Qos_t or else they get a type mismatch when they try to pass it to the API.  If it is uint32 then any uint32 will be accepted - regardless of whether it is actually a match or not.
I definitely agree with moving the constants out of the "private" file and into a public header file - but I would hesitate to actually change the API at this time.

Sure, bit fields in an integer could work too - but then you lose the advantage of type safety protection from having it as a struct.  That is, one has to declare their local variable as a CFE_SB_Qos_t or else they get a type mismatch when they try to pass it to the API.  If it is uint32 then any uint32 will be accepted - regardless of whether it is actually a match or not.
I definitely agree with moving the constants out of the "private" file and into a public header file - but I would hesitate to actually change the API at this time.


Create unit-test ci.yml

Created a CI script for running Unit test

Closes issue #53
Automates the process of running unit tests

How I Tested

Repo can't be tested until it is approved by @mikaelacaron

@am2089 Do you want to make this a PR to my repo?

yes, sorry this is my first time doing this, so im learning along the way.

All good! When you create the PR, you'll see drop downs at the top, you need to make a PR to my repo, as opposed to yours

ohhh ok, so should i delete the branch and do it over again?

no need, as long as the branch still exists, which it looks like it does, click the "new pull request" button, and make sure to select my repo in the drop downs
Also look at some GitHub tutorials too, that will help

see here

so do I just change the head repo to your repo?

No it should look like this image
base is where you wanting to merge the code, the head is yours (notice the direction of the arrow)

ok, I did it. Thanks for the help!


[Important] The current website is about to enter maintenance mode to aid with v3 launch

TL;DR; At the end of Jan 2021, all tracks will enter v3 staging mode. Updates will no longer sync with the current live website, but instead sync with the staging website. The ClojureScript section of the v3 repo will be extracted and PR'd into this track (if appropriate). Further issues and information will follow over the coming weeks to prepare ClojureScript for the launch of v3.
Over the last 12 months, we've all been hard at work developing Exercism v3. Up until this point, all v3 tracks have been under development in a single repository - the v3 repository. As we get close to launch, it is time for us to explode that monorepo back into the normal track repos. Therefore, at the end of this month (January 2021), we will copy the v3 tracks contents from the v3 repository back to the corresponding track repositories.
As v3 tracks are structured differently than v2 tracks, the current (v2) website cannot work with v3 tracks. To prevent the v2 website from breaking, we'll disable syncing between track repositories and the website. This will effectively put v2 in maintenance mode, where any changes in the track repos won't show up on the website. This will then allow tracks to work on preparing for the Exercism v3 launch.
Where possible, we will script the changes needed to prepare tracks for v3. For any manual changes that need to be happening, we will create issues on the corresponding track repositories. We will be providing lots of extra information about this in the coming weeks.
We're really excited to enter the next phase of building Exercism v3, and to finally get it launched! 🙂

As of today, the website has entered maintenance mode.

As of today, the website has entered maintenance mode.

With Exercism v3 just being released, tracks are no longer in maintenance mode and are active again.
This means that changes made to this track will once again show on the website.
Thanks for being patient with us and enjoy Exercism v3!


[BUG] Completion-requests to Ollama are not cancelled, resulting in an unusable delay

helix-editor version
helix 23.10 (f6021dd0)
helix-gpt version
0.31
Describe the bug
Ollama supports canceling requests, https://github.com/ollama/ollama/issues/2876#issuecomment-1989771389. However, from my testing of using Ollama from helix-gpt, code-completion requests are not cancelled. That means every few times a character is typed a new request is queued. The latest request will never finish in a reasonable time.

@justinlovinger can you test this branch https://github.com/leona/helix-gpt/compare/master...sigmaSd:helix-gpt:perf
if that works , I can open a pr

@justinlovinger can you test this branch master...sigmaSd:helix-gpt:perf
if that works , I can open a pr

Your change appears to work. Ollama is more responsive, and I was able to get completions.
 I got completions less often than I expected to. However, that may have been caused by the model I was using.
Also, Helix would frequently show "The operation was aborted." as an error, but that is a nitpick.

Also, Helix would frequently show "The operation was aborted." as an error, but that is a nitpick.

try adding this line if (error.name === "AbortError") reject({ message: "" }); here https://github.com/sigmaSd/helix-gpt/blob/34f9a7b615d278eba7fc37352a2536b01357476e/src/models/api.ts#L45 (before the other reject) to hide that error

Also, Helix would frequently show "The operation was aborted." as an error, but that is a nitpick.

try adding this line if (error.name === "AbortError") reject({ message: "" }); here https://github.com/sigmaSd/helix-gpt/blob/34f9a7b615d278eba7fc37352a2536b01357476e/src/models/api.ts#L45 (before the other reject) to hide that error

That appears to work.
P.S. I think I figured out why completion felt off, and I opened a separate issue about it, https://github.com/leona/helix-gpt/issues/56.

Another minor issue, requests are not cancelled when timed out.

I added canceling request on timeout here https://github.com/leona/helix-gpt/compare/master...sigmaSd:helix-gpt:perf

I added canceling request on timeout here master...sigmaSd:helix-gpt:perf

It worked for me, 👍.


When using Starscream via Carthage, projects must also include zlib folder

When including Starscream with Carthage, project can compile properly, as long as Starscream/zlib resides in Carthage/Checkouts. This should not be the case. So projects that includes Starscream should copy the zlib folder to the project dir, and add it to "Swift compiler - Search Path" in Build Settings.
I think the readme should reflect that?

I think #461 should address this issue. If you could try it out of master and see if works, that would great!

@acmacalister Doesn't look like it worked for me 😕

@acmacalister @codeOfRobin I just deleted the Carthage/Checkouts/Starscream/zlib folder and I'm not sure it's all working yet (sorry, new to Swift and Xcode xD) but at least it builds.

I detailed what worked for my project here :
After every carthage update we delete the SSCZLib and SSCommonCrypto modulemap entries in
./Carthage/Checkouts/SwiftPhoenixClient/Example/Pods/Starscream/zlib.
Also we added $(SRCROOT)/Carthage/Checkouts/Starscream/zlib/ under Swift Compiler - Search Paths -> Import Paths in the Project Build Settings.

@Bersaelor  Thanks, the hack made my code run again, after blocked by this bug for several months.
One question though, what purpose does the last step serve, can it be skipped? I run the code under Xcode 9.3 without the last step, it seems to be fine so far.
Thanks again.

Please check with 3.0.6 version.


[BUG] adc/plugins/module_utils/citrix_adc.py - fails to populate nitro_* parameters

Tested towards a Netscaler 13.1 33.49
While trying to run for instance citrix_adc_nsip to add an IP address it will fail due to the part where nsip_exists() will check if the IP address is already present. The errorcode 258 is included in the API response, but not placed correctly in the nitro_errorcode by module_utils/citrix_adc.py:
This seems to be a duplicate of the unassigned bug issue #232
"calculated configured nsip {'ipaddress': '<IP_ADDRESS>', 'netmask': '<IP_ADDRESS>', 'type': 'SNIP', 'arp': 'ENABLED', 'icmp': 'ENABLED', 'telnet': 'DISABLED', 'ftp': 'DISABLED', 'gui': 'DISABLED', 'ssh': 'DISABLED', 'snmp': 'DISABLED', 'mgmtaccess': 'DISABLED'}",
"ModuleExecutor.update_or_create()",
"ModuleExecutor.nsip_exists()",
"get result {'http_response_body': '', 'http_response_data': {'url': 'https://<IP_ADDRESS>/nitro/v1/config/nsip?args=ipaddress:<IP_ADDRESS>', 'status': 404, 'date': 'Thu, 17 Nov 2022 11:58:46 GMT', 'server': 'Apache', 'x-frame-options': 'SAMEORIGIN', 'expires': 'Thu, 19 Nov 1981 08:52:00 GMT', 'cache-control': 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0', 'pragma': 'no-cache', 'vary': 'Accept-Encoding', 'feature-policy': "camera 'none'; microphone 'none'; geolocation 'none'", 'referrer-policy': 'no-referrer', 'x-xss-protection': '1; mode=block', 'x-content-type-options': 'nosniff', 'content-length': '103', 'content-type': 'application/json; charset=utf-8', 'connection': 'close', 'msg': 'HTTP Error 404: Not Found', 'body': b'{ "errorcode": 258, "message": "No such resource [(IPAddress, , <IP_ADDRESS>]", "severity": "ERROR" }'}, 'nitro_errorcode': None, 'nitro_message': None, 'nitro_severity': None}"
],
"msg": "nitro exception errorcode=None, message=None, severity=None"

@HS1542 looks like ansible version is mismatching.
Please install the relevant ansible (https://github.com/citrix/citrix-adc-ansible-modules#pre-requisites)
As of today, citrix_adc_* modules are tested for ansible version 2.12 or below.
Let here know your findings.

Ansible 2.9.6 installed from the universe repository of Ubuntu 20.04, so it should be within the pre-requisites ?

Yes, @HS1542. We have not tested our modules for ansible versions beyond what is mentioned in prerequisites.
Installing ansible beyond the version mentioned in the prerequisites may break our modules.
We are planning to update our modules to make it compatible to the latest version of ansible possible.
However, PRs are welcome.
Please let here know if this solves your issue for now.

Hello,
I do not follow you here, 2.9.6 is less than 2.12, so in regards to the documentation, the version of ansible should be no problem here? Perhaps there has been some changes in the Nitro API on v13.1 or some other part? It should be quite easy to reproduce.
However, I see that I have been using pip packages, so the version is as you correct stated updated: ansible-core 2.13.5 and ansible 6.5.0.
This solves my issue for now, thank you!
However, could you share some thoughts on how Citrix will proceed with the support of ansible modules? There seems to be much more development and resources going into a full Terraform provider, which as far as I can see works as expected in most cases. What about Ansible? Can we expect some further development on the ansible modules, or should we focus on plain nitro requests?


Make the Header Banner Having Contrast

The Current Header Banner is of color Grey , Make it to Black to look better Contrasted.

hello @kumarankit999
I have solved your issue you can refer to my pull request:-
link 1:- gh pr checkout 23
link 2:- https://github.com/mmacneil/devfolio/pull/23
One more thing if you like my changes then please follow me😅😇😇.
Thanks
@Arshdeep-13


Fix for UTF-8 in hostname

This patch replaces using strtolower() on hostnames as this cant handle utf-8 characters, I have opted to do this with a regex to prevent adding mbstring as a dependancy

If I understand this patch correctly it will only run strtolower on A-Z characters? How is that different from running it on the entire string? If you have a mixed string of ASCII and larger Unicode, strtolower will already only convert the ASCII.
Example code comparing the new filterHost proposed here with just strtolower:
$mixedString = 'MÅi';

function filterHost($host): string
{
    return \preg_replace_callback(
        '/([A-Z])/',
        static function ($cap) {
            return \strtolower($cap[0]);
        },
        $host
    );
}

var_dump(
    filterHost($mixedString),
    \strtolower($mixedString),
    filterHost($mixedString) === \strtolower($mixedString)
);

string(4) "mÅi"
string(4) "mÅi"
bool(true)

I think the test you added will pass with or without the proposed patch. Could you write a test case illustrating a case that fails without applying your proposed patch? Maybe I am missing something. I may very well be missing something crucial, some fluke of PHP’s Unicode handling, and would love it if you could point it out!

I am sure that this test was failing before I replaced strtolower, but i cant seem to reproduce that now....
function testUtf8Host()
{
    $uri = new Uri('http://ουτοπία.δπθ.gr/');
    $this->assertSame('ουτοπία.δπθ.gr', $uri->getHost());
    $new = $uri->withHost('程式设计.com');
    $this->assertSame('程式设计.com', $new->getHost());
}

On futher investigation, it does seem to be a windows specific thing:
Output from your example code on windows:
"C:\Program Files\php-7.3\php.exe" C:\Users\chris\www\psr7\try.php
C:\Users\chris\www\psr7\try.php:21:
string(4) "mÅi"
C:\Users\chris\www\psr7\try.php:21:
string(4) "m�i"
C:\Users\chris\www\psr7\try.php:21:
bool(false)

Process finished with exit code 0

This is so weird. I am assuming try.php is saved as UTF-8? What do you get when you add the following to it?
echo setlocale(\LC_ALL, 0) . \PHP_EOL . ini_get('mbstring.func_overload');

Wondering if strtolower is somehow affected by some other setting, in which case the real solution would be to accommodate for that rather than trying to only find ASCII characters.

I get the following:
LC_COLLATE=C;LC_CTYPE=English_Australia.1252;LC_MONETARY=C;LC_NUMERIC=C;LC_TIME=C
0

So maybe because windows has the default codepage set to 1252?

Thanks for sticking with me @cseufert!
I have now been able to replicate the issue. I do not have the exact locale you mention on my macOS setup, but I was able to use the following (extra name variations to cover all bases) to reproduce the problem:
setlocale(\LC_CTYPE, ['English_Australia.1252', 'en_AU.1252', 'en.1252', 'English_Australia.UTF-8', 'en_AU.UTF-8', 'en.UTF-8']);

I think it may be an idea to modify the test case so it sets a locale we know will fail. That way we actually know the PHPUnit test works.
Locally my PHP is set to use the C locale. So rather than using a regular expression and running strtolower() a lot of times on the domain, I wonder if it instead would be better to declare a safeStrtolower() method that sets the locale as follows:
$originalLocale = setlocale(\LC_CTYPE, ['C', 'POSIX']);

And then resets it after running strtolower().
I will try to put the code together during the day (if you do not beat me to it) and hope you will be able to test it on Windows as well.

I can confirm that setting the locale like this
setlocale(\LC_CTYPE, ['C', 'POSIX']);
does, in fact, solve the problem on windows of strtolower() not working with UTF-8 characters.
However, there are some pretty serious warnings about changing the locale, on shared hosting (mod_apache) on the setlocale man page.

Warning
The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server API like IIS, HHVM or Apache on Windows, you may experience sudden changes in locale settings while a script is running, though the script itself never called setlocale(). This happens due to other scripts running in different threads of the same process at the same time, changing the process-wide locale using setlocale().

https://www.php.net/manual/en/function.setlocale.php
So changing it is probably not a great solution for some users.

Hmm, clearly I somehow missed that when working on my own solution in #133.
I am not sure this is a problem in practice, where we would only need to temporarily change the locale for ~3 lines of code before changing it back to what it used to be. But definitely something to keep in mind.
I am a little surprised that I haven’t encountered this issue in other projects before.

Unicode hostnames are still experimental, and I only encountered them through forged referrer headers, but it still caused some weirdness, so yes, I'm not sure if it is a problem for legit activity.

Would it be dumb to just use mb_strtolower() ?

@drupol  The only issue it then makes this library require that users PHP environment has the mbstring extension loaded. This is not part of a default PHP installation
(see: https://www.php.net/manual/en/mbstring.installation.php)

Thank you for this PR.
I merge the solution in #143. I did however include this test (with your commit).
Thank you again.


Question: local v. remote builds

There are two broad use-cases for builds:

local when developers want to see if their code changes build + test it prior to making a GIT PR
strictly remote builds when PRs are validated prior to approval and merge

According to build buddy the native Bazel remote-cache option among other things:

Determine if any inputs to the action need to be uploaded
Then execute the action remotely
If the action completes successfully, download the action's outputs from the CAS

So any missing inputs (headers, .c, .cpp etc) are rcp'd to the build farm. This is important because for local builds:

Developers clone normally on their local machine where edits occur for local work, but outputs are cached
IF those outputs can be reused by PR validation, they are already cached

So what does bazel-remote do beyond this? I gather bazel-remote implement's Bazel's remote execution like:

Buildbarn
Buildfarm
BuildGrid
Scoot

as referenced here. bazel-remote also reference by Google on a different page.
In particular, what's the thinking process to do builds (before CI validation) prior to PR submission vs. build PR candidates? Building PR candidates is usually mediated through Jenkins etc., but for this question the key point is they always run on a build-farm.
Finally, how does bazel-remote scale to multiple boxes? For 10 available remote build boxes, should I run one copy of bazel-remote per macine and, when building jobs, consistently choose one of the 10 boxes for a given job?

withdrawing until I better understand remote execution with or without remote-caching. My questions mixes both I think in a confusing way

A short summary of remote caching and remote execution:
Remote caching can be used without remote execution. In this setup clients read build results from and write then to the cache directly as needed. This can improve the best-case build times (assuming that the cache overhead is low enough, and the cache hit rate is high enough).
Remote execution requires a remote cache. In this setup, clients download cached build results if available, and if not upload actions (basically a description of a command to run) as well as all the inputs to the command, and then ask the remote execution service to run the action and populate the remote cache with the results. This can improve the worst-case build times (assuming that the actions are faster to upload to the cache, be run by the remote execution service, and downloaded when compared to waiting for a local CPU core to be available).
Bazel-remote only implements remote caching (but it can be used as the cache server with other remote execution implementations). It mostly scales with network and filesystem throughput/latency. It should be able to handle 10s of clients fairly easily, with suitable network and SSD-like storage (though it depends entirely on the kind of actions you want to cache). When experimenting, I think you should start with a single cache and see how far it scales before you need more advanced setups.


Model.update_forward_refs() is Deprecated

The Pydantic BaseModel.update_forward_refs() function is deprecated. This should be replaced with the function call that replaces it.

Resolved by #213.


Issue: prefix Use  being added to agent action causing InvalidTool to be invoked again and again

Issue you'd like to raise.
I have added the tools named A_tool, default_tool  to a ZeroShotAgent.
The output from one of the execution looks like:
Thought: We need to use the A_tool.
Action: Use A_tool
Observation: Use A_tool is not a valid tool, try another one.
Thought:We need to use the default_tool since A_tool is not a valid tool.

Action: Use default_tool
Action Input: None
Observation: Use default_tool is not a valid tool, try another one.

I am not sure why the prefix Use  is getting added to Action.....ideally action should be just the name of the tool [A_tool, default_tool]
This is causing InvalidTool to be invoked again and again.
What can i do to fix this issue?
Suggestion:
No response

https://stackoverflow.com/questions/76785286/prefix-use-being-added-to-agent-action-causing-invalidtool-to-be-invoked-agai

Anything wrong with https://github.com/langchain-ai/langchain/issues/1559#issuecomment-1483791903 ?

@mrvaruntandon Did you get a workaround this problem?

What I found for my usecase was the name of the tool is as important as the description of the tool.
I removed _tool from my tool names and made it more meaningful. I would suggest using a noun for tool name.
Also, I observed that altering the FORMAT_INSTRUCTION while creating an agent also helps.
I changed Action: the action to take, should be one of [{tool_names}] to Action: the action to take, should be only one of the values from [{tool_names}] list

Anything wrong with #1559 (comment) ?

I have not tried with chat-zero-shot-react-description for my usecase.


ci: test luminous

Luminous is out so let's test it instead of Kraken.
Signed-off-by: Sébastien Han<EMAIL_ADDRESS>

I think it's fine to update the default value here, but we were never testing kraken because each ceph version factor sets CEPH_STABLE_RELEASE itself.  See: https://github.com/ceph/ceph-ansible/blob/master/tox.ini#L126

@andrewschoen it's weird, all the iscsi tasks were being skipped here: https://github.com/ceph/ceph-ansible/pull/1747
Looking at the logs, kraken was showing up as a release, cherry picking this commit into that PR now make the role being played...

@leseb, it looks like you're using the wrong group name.
https://github.com/ceph/ceph-ansible/pull/1747/commits/b4ac5b3b449d65bd037842a79d47344746fde249#diff-b0b857e9bebef348b0c2b15e96769ab6R21
https://github.com/ceph/ceph-ansible/pull/1747/commits/b4ac5b3b449d65bd037842a79d47344746fde249#diff-657cf23ae65985b42e777b5c9208ec72R54
iscsi-gw and iscsi_gws are both used

jenkins test this please


colors not displayed with TERM=xterm

I notice that keyb does not use any colors with TERM=xterm, but it does work with TERM=xterm-color.
I usually just use TERM=xterm, can I force keyb to use colors without changing my $TERM?
(Note: This used to work with v0.3, I just upgraded to v0.7 and lost colors)

Hi, thanks for opening an issue. Could you share the following information:

OS
Terminal Emulator
With tmux?
Environment variables:

TERM
COLORTERM
TERM_PROGRAM
CI
CLICOLOR
NO_COLOR

This is most likely an issue with the underlying color libraries termenv or lipgloss as these were updated since v0.3.

Thanks, I'm using Ubuntu 22.04.4 LTS and XTerm 393, without tmux/screen.

Environment:

TERM=xterm
COLORTERM unset
TERM_PROGRAM unset
CI unset
CLICOLOR unset
NO_COLOR unset

The other features all seem to work!

Hmm, CLICOLOR_FORCE=1 keyb does work as a workaround, I guess that's okay... although I think most xterm users just use the default XTerm $TERM name, so won't realize there are colors!

I managed to replicate this with xterm and the examples in termenv.

With default TERM=xterm xterm, termenv's hello-world example returns no colors as the color profile is ASCII.
With CLICOLOR_FORCE=1 TERM=xterm xterm, there are colors as the color profile switches to ANSI256.
With TERM=xterm xterm +cm, the color profile is ANSI256 as the +cm flag enables support for ANSI escape sequences.

However, you mentioned that colors were working before in v0.3.0, but I didn't manage to replicate that - colors were still not working for me with the default TERM=xterm xterm and the rest of the behaviour was exactly the same as above.
For the fix, I could add the following:
if termenv.EnvColorProfile() == termenv.Ascii {
    lipgloss.SetColorProfile(termenv.ANSI256)
}

but I don't feel comfortable messing with the user's terminal configuration. Instead, I'll probably just add a note with the 2 workarounds above for xterm users or any other users that lack colors.


Insanely outdated packages

I tried cli-extra and xcde, and I used apt-get update and apt-get install nodejs, and it installed version 6 of node. They're on 12 now. It did something similar with npm.
I don't know if these distros are being maintained any more, but if not, are there some that are and update their package managers?

So, unity is the best package for anyone else who can't get this to work. It takes up about 7GB though

unity, xfce, cli-extra are targets. They don't have any influence on package versions released with a distro. A distro release has influence on that, for example ubuntu releases precise, trusty etc and debian releases wheezy, jessie etc You probably used in a previous install release precise and now with unity release trusty.


Does inversion work in CogVideoX?

Hi,
I am trying to invert a video using Cogvideo, how should I go about this?
Thanks!

This model cannot play videos in reverse, however. You can create forward-playing videos based on prompt words and use tools like ffmpeg to achieve reverse playback.


Will beast add support for swagger like golang?

Are you able to describe what support you are hoping to see?

like this https://github.com/swaggo/swag

func main() {
	r := gin.Default()

	c := controller.NewController()

	v1 := r.Group("/api/v1")
	{
		accounts := v1.Group("/accounts")
		{
			accounts.GET(":id", c.ShowAccount)
			accounts.GET("", c.ListAccounts)
			accounts.POST("", c.AddAccount)
			accounts.DELETE(":id", c.DeleteAccount)
			accounts.PATCH(":id", c.UpdateAccount)
			accounts.POST(":id/images", c.UploadAccountImage)
		}
    //...
	}
	r.GET("/swagger/*any", ginSwagger.WrapHandler(swaggerFiles.Handler))
	r.Run(":8080")
}

This looks like a higher level concern that beast.
There is nothing stopping someone writing a library like this that uses beast for the HTTP encoding and decoding.


HTTP Endpoint Inbuild Loadbalance

Use case:
Just like JDBCtemplate provide in build load balance. It would be more powerful if crate has inbuild rest endpoint fail-over.
Feature description:
Postgressql provide inbuilt capability for multiple node fail-over. The same way crate should have gateway which can handle the http endpoint request which can redirect based on round-robin (as default) algo.
so is there any plan for this ? or its already available ? Or its recommended to used LB server ?

Ok. Something like In-build Load balancer for crate-client. I have read the documentation where crate has mention one particular URL like http://crate01:4300/_sql?.
Now lets say i have 5 node running.
Now the issue is if suppose the crate01 down for some reason then what happen ? I have to bring nginx or haproxy for this to manage. so instead of talking LB server into the picture is it possible to have in build load balancer which is contain getaway(virtual IP) which handle  the http endpoint request which can be redirect based on round-robin (as default) algo.

Which client are you referring to? As I said, this is not something that can be done on the server side and most of our maintained clients include some form of fail over already.


inconsistent variable value in cells

Describe the bug
I have not managed to reproduce this yet, I have been playing with the auto_reload functionality (have not managed to get it to work yet, will report separately). But the bottom line, I ended up having two cells showing a different value for a variable, this is not supposed to happen I presume? Here is a screenshot (load_times variable)

The source is probably not helpful, since it is exactly not enough to produce (you would need the history), and I don't remember it, I'm trying to reproduce and will share as soon as I can.
import marimo

__generated_with = "0.4.1"
app = marimo.App()

@app.cell
def __():
    import marimo as mo
    from datetime import datetime, timedelta
    import os
    return datetime, mo, os, timedelta

@app.cell
def __():
    load_times = []
    return load_times,

@app.cell
def __(load_times):
    load_times
    return

@app.cell
def __(mo):
    refresh = mo
    return refresh,

@app.cell
def __(datetime, load_times):
    from mymodule import somefunc
    load_times.append(datetime.now())
    return somefunc,

@app.cell
def __(load_times):
    load_times
    return

@app.cell
def __(os):
    os.getcwd()
    return

@app.cell
def __():
    from pathlib import Path
    return Path,

@app.cell
def __(Path):
    Path('mymodule.py').write_text('''
    def somefunc():
        return 99
    def func2():
        return 42
    ''')
    return

@app.cell
def __():
    return

if __name__ == "__main__":
    app.run()

Environment
{
  "marimo": "0.4.1",
  "OS": "Linux",
  "OS Version": "6.7.9-200.fc39.x86_64",
  "Processor": "",
  "Python Version": "3.12.2",
  "Binaries": {
    "Browser": "--",
    "Node": "--"
  },
  "Requirements": {
    "click": "8.1.3",
    "importlib-resources": "missing",
    "jedi": "0.19.0",
    "markdown": "3.6",
    "pymdown-extensions": "10.8",
    "pygments": "2.15.1",
    "tomlkit": "0.12.4",
    "uvicorn": "0.29.0",
    "starlette": "0.37.2",
    "websocket": "missing",
    "typing-extensions": "4.8.0",
    "black": "24.1.1"
  }
}

Code to reproduce
not yet, see notebook above.

You can try mo.state for advanced usages (one way to bring mutations back in the reactive world)


BeamX DAO. Investor allocation section (mobile view)

Add Investor allocation section (available only for investors). The section should be foldable
https://zpl.io/V0Nq0LO
In Current height section, if number of days in brackets are less than 1, show "Current height (vesting starts today)"
If vesting already started, show "Current height (vesting started date)"

Checked


Failed to import -

Failing module
import "https://esm.sh/@heroicons/react@2.0.17/20/solid?alias=react:preact/compat,react-dom:preact/compat,@types/react:preact/compat&external=preact/compat"

Error message
520 Origin Error
cloudflare-nginx
Additional info

esm.sh version: 128

Thanks, I will look into it

closed in 2d6a0968ee8a58bb4f843cdab1d523b329ceb1e6

check https://esm.sh/@heroicons/react@2.0.17/20/solid?alias=react:preact/compat,react-dom:preact/compat,@types/react:preact/compat&external=preact/compat

The index file seem to work now, but I get 404 for the imports.
Example:
https://esm.sh/@heroicons/react@2.0.18/24/outline?alias=react:preact/compat
imports
https://esm.sh/v128/<EMAIL_ADDRESS>

@marcushultman  i found this exports in the package.json of heroicons, esm.sh can not handle this correctly (randomly use one of the exports bc golang non-stable map itermap), i will fix later! thanks for reporting!

   "./24/outline/*": {
      "types": "./24/outline/*.d.ts",
      "import": "./24/outline/esm/*.js",
      "require": "./24/outline/*.js"
    },
    "./24/outline/*.js": {
      "types": "./24/outline/*.d.ts",
      "import": "./24/outline/esm/*.js",
      "require": "./24/outline/*.js"
    },
    "./24/outline/esm/*": {
      "types": "./24/outline/*.d.ts",
      "import": "./24/outline/esm/*.js"
    },
    "./24/outline/esm/*.js": {
      "types": "./24/outline/*.d.ts",
      "import": "./24/outline/esm/*.js"
    },


global Promises overwritten by es6-promises

The version of es6-promise you are using has an issue where it overwrites global.Promise (see issue : https://github.com/stefanpenner/es6-promise/issues/140).
It is fixed in version 4.x.x (https://github.com/stefanpenner/es6-promise/pull/230).
Dropbox version : 2.5.7 ( & es6-promise : 3.3.1)
global.Promise = require('bluebird');
const Dropbox = require('dropbox');

let client = new Dropbox({accessToken: ''});
console.log(global.Promise.version); // 3.5.0  => it's bluebird
client.filesUpload({});
console.log(global.Promise.version); // undefined  => now it's es6-promise

Would it be possible to update the es6-promise dependency to a newer version to avoid this behaviour please ?
Thanks !

Thanks!
On Aug 23, 2017 6:41 AM, "Beckett"<EMAIL_ADDRESS>wrote:

The version of es6-promise you are using has an issue where it overwrites
global.Promise (see issue : stefanpenner/es6-promise#140
https://github.com/stefanpenner/es6-promise/issues/140).
It is fixed in version 4.x.x (stefanpenner/es6-promise#230
https://github.com/stefanpenner/es6-promise/pull/230).
Dropbox version : 2.5.7 ( & es6-promise : 3.3.1)
global.Promise = require('bluebird');const Dropbox = require('dropbox');
let client = new Dropbox({accessToken: ''});console.log(global.Promise.version); // 3.5.0  => it's bluebirdclient.filesUpload({});console.log(global.Promise.version); // undefined  => now it's es6-promise
Would it be possible to update the es6-promise dependency to a newer
version to avoid this behaviour please ?
Thanks !
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dropbox/dropbox-sdk-js/issues/152, or mute the thread
https://github.com/notifications/unsubscribe-auth/AE2ScAeeIIYK-WRo3eA09D4dj1KMeg1Vks5sbCwYgaJpZM4PACDf
.

If needed, I would be happy to work on a PR for this.

Merged #153 .


Merge infinite loop and short circuit waitgroup

#200 resolves an infinite loop due to requesting a new iterator for each loop, and break causing a short circuit of the wait group resulting in the Merge observable never terminating.

Solved in https://github.com/ReactiveX/RxGo/pull/215


[SPARK-14672][SQL] Move HiveContext analyze logic to AnalyzeTable

What changes were proposed in this pull request?
Just moving code around. Note that this patch removes a public method, but that's OK since HiveContext is totally going away before Spark 2.0 anyway.
How was this patch tested?
No change in functionality.

@yhuai

Test build #55965 has started for PR 12429 at commit bc7873a.

Test build #55965 has finished for PR 12429 at commit bc7873a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/55965/
Test PASSed.

Test build #55981 has started for PR 12429 at commit fa80269.

Test build #55981 has finished for PR 12429 at commit fa80269.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/55981/
Test FAILed.

Merged build finished. Test FAILed.


Macro error with Rust 1.70.0

I've recently rebuilt some code with latest stable rust and encountered this error:
error: impl method assumes more implied bounds than the corresponding trait method
 --> src/library/rpc.rs:8:1
  |
8 | #[rtc::remote]
  | ^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #105572 <https://github.com/rust-lang/rust/issues/105572>
  = note: `#[deny(implied_bounds_entailment)]` on by default
  = note: this error originates in the attribute macro `rtc::remote` (in Nightly builds, run with -Z macro-backtrace for more info)

Some errors have detailed explanations: E0412, E0432.
For more information about an error, try `rustc --explain E0412`.

The problem was actually in my code, but the error was quite cryptic/unexpected.

It's quite difficult to provide good error messages in proc macros.
The best advise is actually  what the compiler is giving you:
  = note: this error originates in the attribute macro rtc::remote (in Nightly builds, run with -Z macro-backtrace for more info)

Yup. Unluckily the nightly build wasn't really more explicit about the cause. In this case, IMHO, the problem is not the macro or remoc at all, but rustc compiler, because this linter-turned-error misrepresents the real error in the specific case I encountered, even on non-macro situations. I'll comment on appropriate issue on rust-lang asap.

BTW if you're having trouble with Send + Sync bounds on the RTC server, you could try version 0.11.


Fix line separation in concepts/architecture/nodes

https://github.com/kubernetes/website/pull/27261

/lgtm
/assign @fabriziopandini


Draft: log.Entry reusability

Please read the entirety of this PR comment before proceeding.
Note this is a draft PR, some local tests were made but not committed to avoid loss of time if these changes are not desired relative to the wanted outcome. It is to spur discussion, not to be merged as is, yet.
Changes

Allows users of zerolog/logrus drivers to set a behavior of the log.Entry interface type that has always made it clear that the top level interface does not enforce or define a behavior if called multiple times. This change uses a log.Option in each respective package instead of a log.Config change in order to avoid changing the higher level log package, but to also leave it as an option for drivers, rather than a requirement.
Keeps backwards compatibility with existing interfaces, no v2 of package needed.
logrus driver, if set to not reuse entries, becomes a noop if already sent, rather than panicing if misused.

Tradeoffs

Introducing a new type, regardless of similarities with log.Entry would result in a breaking change to the higher level log package and interface, therefore requiring a v2. Unless the new type was only exported via an optional interface, but then this becomes more verbose to use.
Code duplication in zerolog version (of the existing *entry type), check ztype_go118 for details. The TLDR though is that pre1.18 interfaces were not good enough to interchange between Entries and Contexts from zerolog, there was a TODO about this some time ago but was removed before this code/repo was moved to github and before generics were accepted into Go.
It was always documented that a log.Entry was the type for individual entries to spur canonical log lines, and generally discourage log spam. If new code is now written that expects an entry to be reusable but is given one that isn't, it will "not behave as expected". An assertable interface such as the one below could be added and a helper in the log package so code can check this behavior without knowledge of the underlying driver or settings. This would still be backwards compatible from an interface signature standpoint.

// Or Reuser/Reuse, Reuser/Reusable to make it more idiomatic
type Reusable interface {
	Reusable() bool
}

Or, to keep log.Entry as "single"/individual entries we add a new type, which would cause the breaking changes mentioned above but might be clearer to users. The amount of code would change little, given the need for generics to cut down on much of what is already here.

My take on this approach:

I like the use of options to change default behavior, and no breaking changes.
I don't think we want to introduce a system for implementing an anti-pattern, which this does. I'd rather we have the alternate functionality be to panic with a clear message.

As a response to #6 and #7, I think the OP had a basic misconception that lead to misusing the library: that logger.WithField returns a logger.Logger, not a logger.Entry. Coming from a library where this is how the interface worked (Zerolog), I don't blame OP for making this assumption without fully ingesting the docs here, esp. since these docs misleadingly claim it's a "drop-in" replacement. However, I think the solution for #6 and #7 is in fact a breaking change to the interface that makes logger -> entry -> field clearer. This is probably not the place to hash out what that change looks like, but at a minimum it would mean removing the Logger.WithField method.

My take on this approach:
1. I like the use of options to change default behavior, and no breaking changes.

2. I don't think we want to introduce a system for implementing an anti-pattern, which this does. I'd rather we have the alternate functionality be to panic with a clear message (`type ReusePanicker interface { ReusePanicker() bool }`).

As a response to #6 and #7, I think the OP had a basic misconception that lead to misusing the library: that logger.WithField returns a logger.Logger, not a logger.Entry. Coming from a library where this is how the interface worked (Zerolog), I don't blame OP for making this assumption without fully ingesting the docs here, esp. since these docs misleadingly claim it's a "drop-in" replacement. However, I think the solution for #6 and #7 is in fact a breaking change to the interface that makes logger -> entry -> field clearer. This is probably not the place to hash out what that change looks like, but at a minimum it would mean removing the Logger.WithField method.

For your second point, I actually received the direct opposite feedback, that it shouldn't panic. But I tend to agree with you that I'd like to know something were wrong.
Hmm this is the first I've heard about the WithX methods on the logger causing confusion, but I can understand it. Are there other breaking/v2 style changes you'd recommend or have encountered?

For your second point, I actually received the direct opposite feedback, that it shouldn't panic. But I tend to agree with you that I'd like to know something were wrong.

Yes, I think I am in the minority. However, it's also because I think I have come around to see the design choices for this interface and so understand the trade-offs better than people approaching it with the mindset of a more standard logger. I would say panic only bc generating an error could cause logging a bunch of errors because of an issue logging an error ad nauseam.

Hmm this is the first I've heard about the WithX methods on the logger causing confusion, but I can understand it. Are there other breaking/v2 style changes you'd recommend or have encountered?

Yeah, there are a few ones all related to this. I think really hammering the logging "model" this interface recommends, how to think about writing logs, that is, should be a major part of the docs, and ensuring that this model is clearer / more orthogonal, with fewer shortcuts, would be helpful. I also think adding a few extra methods that don't force one to conform to the model (like an easy mode: logger.Printf, etc) so you can ramp up and do some basic stuff would be nice for adoption. But that's all a separate issue I haven't had time to follow up on.

I also think adding a few extra methods that don't force one to conform to the model (like an easy mode: logger.Printf, etc) so you can ramp up and do some basic stuff would be nice for adoption. But that's all a separate issue I haven't had time to follow up on.

I've always gone back and forth on methods like 'Print(f)' and 'Log(f)' similar to the std lib logger. Though I think most of that comes from what loggers do have those often don't have levels at all (or they're more "difficult" to use, like it becomes a param).
That seems to be what you're going after in your current v2 proposal though. I think it's something to consider; just like adding more interface types (and their methods) are.

I don't know if the BasicLogging part should be included or not. I've heard that this would be nice, but I tend to think that just having clearer docs would obviate needing these.
I am much more interested in:
type Logger interface {
	// Renaming these to make it clear they return entries:
	TraceEntry() Entry
	DebugEntry() Entry
	InfoEntry() Entry
	WarnEntry() Entry
	ErrorEntry() Entry
	PanicEntry() Entry
	FatalEntry() Entry

	// Removing these to remove confusion about "currying" fields on a Logger:
	// // WithField(key string, value interface{}) Entry
	// // WithFields(fields map[string]interface{}) Entry
	// // WithError(err error) Entry

	// Adding these to allow for the desired "currying" behavior.
	// Note that they do not return a value (use a chainable interface)
	// to make it clear they are mutating the state of the current logger.
	DefaultFields() map[string]interface{}
	AddDefaultField(key string, value interface{})
	SetDefaultFields(fields map[string]interface{})
}

// Adding these to allow for the desired "currying" behavior.
// Note that they do not return a value (use a chainable interface)
// to make it clear they are mutating the state of the current logger.
DefaultFields() map[string]interface{}
AddDefaultField(key string, value interface{})
SetDefaultFields(fields map[string]interface{})

How would you make a "new" logger then with prior default values + new ones? Or how would this version work if the logger is being shared and multiple goroutines are calling these methods?

How would you make a "new" logger then with prior default values + new ones?

This makes no provision for the use case of copying the current logger. We could "clone" loggers if we want, but I don't see why that would be useful.

Or how would this version work if the logger is being shared and multiple goroutines are calling these methods?

The above implementation is to handle the use case of someone wanting to add some values to every entry generated from a logger (app name, for example). In this case it does not matter that the logger is shared between goroutines: all log entries are meant to include this data.
If a user wants to build up an entry and then re-log it multiple times with small changes: that seems to me to be an anti-pattern, but also "entry" cloning is something else we could do if necessary. I think it'd make more sense to create an entry per goroutine and add fields to it and log one time.

How would you make a "new" logger then with prior default values + new ones?

This makes no provision for the use case of copying the current logger. We could "clone" loggers if we want, but I don't see why that would be useful.

As far as I've been told, this is exactly what people want to do... :confused:

Or how would this version work if the logger is being shared and multiple goroutines are calling these methods?

The above implementation is to handle the use case of someone wanting to add some values to every entry generated from a logger (app name, for example). In this case it does not matter that the logger is shared between goroutines: all log entries are meant to include this data.
If a user wants to build up an entry and then re-log it multiple times with small changes: that seems to me to be an anti-pattern, but also "entry" cloning is something else we could do if necessary. I think it'd make more sense to create an entry per goroutine and add fields to it and log one time.

That means it wouldn't be concurrency safe because if two goroutines are adding "defaults" then those values show up in logs created by both of them. I don't think that would be desired behavior, again from what I understand of how others what this to work.

That means it wouldn't be concurrency safe because if two goroutines are adding "defaults" then those values show up in logs created by both of them. I don't think that would be desired behavior, again from what I understand of how others what this to work.

Yeah in my mind this is a one-time setup at the beginning of a logger, maybe something better handled by configuration.
I am also a NOFIX (unless I am convinced otherwise) on making entries that generate entries and loggers that generate loggers. People embedding toooooooooooo much logic and state in a logger. The logger should just log (see, I can also aver to what a logger "should do"). :)


fixChange column statistics table varchar length to 1024.

Change column statistics table varchar length to 1024. Including db name, table name, column name and partition name. Because the maximum length of the names above is 256 characters. (For 256 Chinese character, we need varchar 1024 to store it)

run buildall


feat: new website hero

Please describe the changes this PR makes and why it should be merged:
New hero! (inspired by https://astro.build)

Status

[x] Code changes have been tested against prettier, or there are no code changes
[x] I know how to update typings and have done so, or typings don't need updating

Semantic versioning classification:

[ ] This PR changes the codebase

[ ] This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
[ ] This PR changes the internal workings with no modifications to the external API (bug fixes, performance improvements)

[x] This PR only includes non-code changes, like changes to documentation, README, etc.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

6 of 25 (24.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 60.211%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/react/hooks.ts
6
25
24.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
1395

Relevant Lines:
2410

💛  - Coveralls


Perm checking consistency

Issue Summary
page_listing_more_buttons hook uses both page and page_perms to check for permissions. To keep it consistent I suggest only page_perms.page_is_root should be used.
Technical details

Python version: 3.6.6.
Django version: 1.11.
Wagtail version: 1.13.1.
Browser version: Firefox 58.

Fixed in #4326


Alpha doesn't work with depth setting in isosurface rendering

🐛 Bug
As @kevinyamauchi knows, I absolutely love his work in #3181. However, it has also ruined my workflow. :joy:
Specifically, the way it currently works, nothing behind an object is currently rendered, even if that object is transparent. Here is code to reproduce the example:
import napari
import numpy as np
from skimage import data, filters, morphology, segmentation
from scipy import ndimage as ndi

cells3d = data.cells3d()

viewer = napari.view_image(
    cells3d, channel_axis=1, name=['membranes', 'nuclei'], ndisplay=3
)
membrane, nuclei = cells3d.transpose((1, 0, 2, 3)) / np.max(cells3d)
edges = filters.scharr(nuclei)
denoised = ndi.median_filter(nuclei, size=3)
thresholded = denoised > filters.threshold_li(denoised)
cleaned = morphology.remove_small_objects(
    morphology.remove_small_holes(thresholded, 20**3),
    20**3,
)
maxima = ndi.label(morphology.local_maxima(filters.gaussian(nuclei, sigma=10)))[0]
markers_big = morphology.dilation(maxima, morphology.ball(5))

segmented = segmentation.watershed(
    edges,
    markers_big,
    mask=cleaned,
)

labels_layer = viewer.add_labels(segmented)
points_layer = viewer.add_points(np.transpose(np.nonzero(maxima)), size=2)

napari.run()

This results in the following display now, even on low opacity for the labels layer:

The points are actually there, but can only be seen if the Labels layer is made invisible:

Whereas it used to look like this:

It was always weird that the points would be "on top" of any previous layers, and messed with our perspective, but unfortunately I think the current behaviour is worse, in that transparency gives the impression that there is nothing "behind" a surface when in fact there is.
In the worst case, we can have a switch for setting depth or not during rendering.

Ah, sorry about that @jni . This makes sense. I think the best fix is probably to have a switch to turn the depth checking on/off. Doing transparency + depth will be a lot more tricky.
I think we can use set_gl_state(depth_test=False) on the visual, but I am not sure if that will cause other issues. Do we want to tie it to the opacity value (i.e., turn of depth test for opacity < 1).

Do we want to tie it to the opacity value (i.e., turn of depth test for opacity < 1).

I kinda like this but it seems like a recipe for some other unforeseen problem. :joy:

I kinda like this but it seems like a recipe for some other unforeseen problem. 😂

For sure. This was my thought as well.

I've thought about this a bit more and I am not sure that adding a depth_test flag is the right approach here. I made a small PR showing this approach (#3395). The issue with a depth_test flag is that we set depth_test when we set blending modes, so they can "fight" eachother.
I now think the best approach is to add another blending mode that is  the same astranslucent with the exception that depth_test=False. For some context, here are the blending modes:
https://github.com/vispy/vispy/blob/585266c07a5d0f954523651ba20604bb49793b08/vispy/gloo/wrappers.py#L37-L52

@kevinyamauchi I must say I'm rather agnostic here, but yes, I do have a slight preference to your second approach.

@kevinyamauchi I must say I'm rather agnostic here, but yes, I do have a slight preference to your second approach.

Sounds good. I'll make a PR with the second approach today and close #3395.

Relevant discussions on vispy:

vispy/vispy#2039
vispy/vispy#2208

I think that the OIT PR is what we need to solve a lot of our problems (including how ugly antialiased borders are currently), but I tried my hand at it and it's really hard stuff. We need someone with more experience than me to pick it up, or asnt to find the time to work on it :)


[Core] editor framework setup

Pull Request Template
Description
Summary:

Rewrite everything related to EditorWidget. Big refactoring.

Issue(s) Addressed:

...

Changes
Type of Changes: new feature / breaking change

Change 1: Describe in detail what was changed or added.
Change 2: Elaborate on the reasons and any associated logic/decisions.
...

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Reviewers Checklist:

[ ] Code follows project guidelines and clean code principles
[ ] Tested on various resolutions and browsers
[ ] Unit tests have been updated or added, if necessary
[ ] Documentation has been updated

The above commit now is able to create a simple functional empty CKEditor when clicking a file✔ But it is just for testing purposes. The code will be refactored soon.


Ensure INSTALLED_APPS and MIDDLEWARE as tuples still work

Currently if MIDDLEWARE is a tuple and not a list Django crashes on startup.

This should work already: https://github.com/simonw/djp/blob/099378e10d024fddf859d37d4149774d19c12110/djp/init.py#L48-L49
This is breaking:
https://github.com/simonw/djp/blob/099378e10d024fddf859d37d4149774d19c12110/djp/__init__.py#L66


Vue 3 support

Hi,
Vue 3 is out for several weeks now, is there a plan to support it ?

Any progress here?

Any progress here?

+1

+1

has anyone managed to use it with the composition api

has anyone managed to use it with the composition api

I worked on this a bit today: https://github.com/nVitius/vue-infinite-loading/tree/next
I haven't tested everything but the core functionality at least is working.
I didn't try running the tests, but I'm pretty sure they aren't valid anymore.
I switched webpack out for rollup and used this project to configure the build process.
Until this is merged, you should be able to install it with npm like this:
npm i --save github:nvitius/vue-infinite-loading#next
Usage is the same as before.

+1

You can use this inside a Vue 3 app via https://github.com/privatenumber/vue-2-3
Here's a working example https://codesandbox.io/s/vue3-infinite-loading-63rqj
https://github.com/wobsoriano/vue3-infinite-loading

https://github.com/PeachScript/vue-infinite-loading/issues/313#issuecomment-871106685


not supported in the pynq board from xilinx

@vishwas1234567, Is this still an issue

@vishwas1234567, Closing since it is resolved. Please feel free to open if still issue persists. Thanks


Feature/cbl c/cbl 1783

This is the motivation of the change. Currently, we add listener as follows,
ChangeListener listener = addChangeListener(callback), where the callback gets called when the change takes place, and then we can get the change from "listener," as listener.result(). One place to handle the change is inside the callback. However, before "addChangeListener" is returned, listener is incomplete. This actually caused crashing due to the race condition, whereby the callback is something like "callback = { listener.results();}"
Whereas this use itself is bug, which can be fixed by, inside the callback, waiting for the add function to return. However, we want to improve the API to be less liable to that kind of error. After discussing with Pasin, we derived this solution of this PR. We provide the object, Change, as an argument of the callback. With this object, the author of the callback may safely get the results. Of course, the original function listener is not removed. Users may still call listener.results() in the same thread as the one that runs addChangeListener(). We just removed little awkwardness to get the change results from inside the callback.

Could you also add some description about the problem / solution in the PR description?

You only changed the unofficial C++ wrapper API. You need to change the C API, include/cbl/Query.h.

Please don't make it a habit of naming PRs like this.  We should be able to tell what the PR is for from the PR summary page (i.e. the title should give enough information to describe without any outside resource).


[Feature](add bitmap udaf) add the bitmap intersection and difference set for mixed calculation of udaf

Problem summary
Add the bitmap set for  mixed calculation of udaf
Calculate the bitmap intersection, union and difference set of expressions to calculate the count function.
Checklist(Required)

Does it affect the original behavior:

[No]

Has unit tests been added:

[No]

Has document been added or modified:

[Yes]

Does it need to update dependencies:

[No ]

Are there any changes that cannot be rolled back:

[ No]

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...


golangci-lint | Disable default exclusions in cfg

Add explicit config settings to disable default exclusions
fixes GH-28

CI failed due to linting errors encountered. That's expected (and a good thing). Will loop back to this once the detected linting errors are resolved.


CanFulfillIntentRequest Type error

Hello i am trying to use the CanFulfillIntent.
I am getting a type error
System.ArgumentOutOfRangeException : Unknown request type: CanFulfillIntentRequest. (Parameter 'Type')
any advice?
please note i also posted an issue on alexa.net.
I am feel the change needs to be made to the Type in alexa.net.
https://github.com/timheuer/alexa-skills-dotnet/issues/261

I think this may be my issue https://github.com/timheuer/alexa-skills-dotnet/issues/121
how would i call this in a startup in dot net 6 i don't have a startup script anymore?
CanFulfillIntentRequestConverter.AddToRequestConverter();

Hiya - apologies for the delay I've been travelling for a client site.
The code needs to be run somewhere statically - so you should be able to put it in your program.cs file


Add unary ops to TTNN

Is your feature request related to a problem? Please describe.
We need a new operation to perform unary operations similar to what was implemented in torch.
ex. clone , gelu
Following are the ops needed
abs, cbrt, clone, deg2rad, digamma, erf, erfc, erfinv, exp, exp2, expm1, gelu, hardsigmoid
Describe the solution you'd like
This will perform unary operation to the given input tensor and return one output tensor.
Describe alternatives you've considered
It's possible that ttnn tensor could be converted to a pytorch and then do unary operations with pytorch.  Then the result would be returned by using a ttnn.from_torch operation.
Additional context
The reference implementation in this case is:
import torch

tensor = torch.tensor([1, 2, 3])

result_tensor = torch.nn.functional.gelu(tensor)
print(result_tensor)

Merged to main
https://github.com/tenstorrent-metal/tt-metal/pull/5279