feat(forge): Better deployment

Add the ability for forge to use a solidity file to create a contract on mainnet and arbitrary deploy scripts by adding a cheatcode. You could do something like:
contract t {
    function deployMyContract() {
        uint256 input1 = dep.someFunc();
        vm.mainnetDeploy();
        MyContract t = new MyContract(input1);
    }
}

Would vm.mainnetDeploy() broadcast the next call as a transaction? So it'd require having instantiated a signer and an RPC connection? Maybe it could be configured in a 2-step process, one which generates the transactions, and another one which fires them all? (brainstorming)

Along with vm.mainnetDeploy(), we could specify FOUNDRY_* env vars in the foundry.toml and then these scripts would implicitly use the FOUNDRY_RPC_URL and FOUNDRY_PRIVATE_KEY or MNEMONIC + PATH env vars to setup RPC connection and signers.

I would rename it to vm.deploy(); and select network like:
forge deploy --network rinkeby

env variables for keys and .toml for paths, rpcs, and some configurations.
What I like about hardhat deploy plugin, is that you can deploy and run additional commands, like initial calls for setups or stuff like that.

we should be able to just deduce where you want to deploy to based on the RPC you provide

we should be able to just deduce where you want to deploy to based on the RPC you provide

Usually we reuse deploy scripts for different networks

Usually we reuse deploy scripts for different networks

Thats my point - when someone does forge create ./deploy/* --rpc-url <xxxxx>, we leverage the rpc url to deploy. if there is a config file and no rpc provided, we can force them to specify the network

Would you be able to reuse the deployment contract as a test fixture if it contains calls to vm.mainnetDeploy?

Usually we reuse deploy scripts for different networks

Thats my point - when someone does forge create ./deploy/* --rpc-url <xxxxx>, we leverage the rpc url to deploy. if there is a config file and no rpc provided, we can force them to specify the network

Sounds good, but might me confusing doing forge create ./deploy/* --rpc-url <rinkeby.xxx> and in the contract vm.deployMainnet();

We can just call it vm.deploy() to avoid the confusion I think?

What do people think about broadcast as the cheatcode? it makes it agnostic to create/call style transactions, as well as what network youre sending to.

Good point^
So maybe

vm.startBroadcast()
Foo foo = new Foo();
foo.set(5);
vm.stopBroadcast()

Would produce 2 ethers-rs TypedTransaction which then we could either serialize, or immediately broadcast?

we also need to simulate it and make sure it doesnt fail - also would be good to give the gas costs

Wonder how we'd handle idempotency, e.g. if for whatever reason it fails at the first call, how does it know to resume from the second one? @moodysalem any thoughts here (cf the v3 deployer from some time ago)

one option is that when we send a tx, we record it in a cache file - with deployed addresses and what not. I think hardhat does something similar. and if we have a cache, we pickup where we left off unless they pass a flag to restart the deployment (we would need to include the chain it was deployed to tho for multichain deployments, like local node vs mainnet)

Yeah I think this is a great idea and would definitely use it.
A couple of ideas (echoing some that are above but wanted to have a comprehensive list):

"Dry-run" deployments on mainnet forks
Gas cost summaries of deployments
Some sort of artifact that gets generated with all deployed addresses (and tx hashes maybe)
Being able to ensure auto-verification of all deployed contracts (single file verification)
Being able to run assertions against newly deployed contracts to ensure complete deployment

I like all the ideas on @lucas-manuel's list, and would like to add two more:

A way to specify expected deployer account and nonce, or alternatively perhaps a way to specify expected contract address
Ensure deploy scripts are easily reusable as setUp() logic, to easily run tests against deployed state

Putting this here: https://github.com/EthWorks/Mars
Mars has dry-runs, gas cost summaries, automatic deployment of only parts of your code that changed etc. We could probably borrow some ideas from there

Copied from chat:
I wonder how well this would work for necessariliy moduralized deployments of larger projects and/or maintaining an idempotent deployment over a longer time span with different parts of the project having different lifespans & different solidity versions.
I already ran into a similar problem in my integration tests where one of the core contracts (persistent contract in an otherwise upgradable protocol) is on solidity 0.6.12 so I can't directly use it, and inlining and bumping it to 0.8.11 just for the sake of the test would be weird. Sure, a fork test would work fine but comes with its own downsides (mainly performance).
Anyways ...
I'd imagine that problems of a similar nature might arise for long-lived, upgradable protocols that wish to deploy & configure their contracts in an idempotent IAC fashion.
It feels like a layered approach could work well where deployment artifacts shared between these layers/steps in sequence could also be used as a starting point for integration tests (by etching the deployed bytecode as recorded in the deployment artifacts of the previous layers), thus not needing a fork.
This could also be a fine approach for Acceptance Tests prior to a protocol upgrade.
... And a nice way to share deployment artifacts between repositories (just like lib) possibly including state.

Imho, this is related because integration testing on top of the actual deployment can be quite useful: https://github.com/gakonst/foundry/issues/326
I might be overthinking this, but here's a possible solution that could work also for types of projects as described in my previous comments without sacrificing DX/UX:
We might be able to structure this with "modularized" deployment files that define their I/O interface using shared structs that live in an "interface" contract in a separate .sol file without a version constraint. Thus, these interfaces could be shared between different deployment modules (and tests) with different solidity versions. This interface contract would feature serialization & deserialization (SerDe) a.k.a encode/decode functions for the I/O structs of the corresponding deployment contract.
A cheatcode could be used to then utilize these interfaces, both to share I/O between deployment modules and to enable integration tests to use a deployment (and its output) e.g. in setUp without juggling abi encode/decode manually.
When running actual production deployments, these structs could be serialized into artifacts and written to disk.
Does this make any sense at all? Is it worth a shot?

I am just attacking this based on intuition first. I have started development of this but thought id outline current plan.
Basic plan is to:

support contracts that have “IS_DEPLOY” - similar to “IS_TEST”,
run functions that have deploy in the name, with support for numbers, i.e. deploy1, deploy2, etc.
Support broadcast, startBroadcast and stopBroadcast, which has similar semantics to prank
we will execute in the vm and craft the needed TransactionRequest based on the broadcast cheatcode state
by default, forge deploy dry runs (i.e. doesn’t actually send transactions). you specifically pass a flag to actually broadcast
we will print out a report of the deployments (and actually broadcast them). more details on what this entails likely to arise later
we will cache results, and maybe full txs even, via json based on deploy function number
you will be able to pass in a selection of deployment stages like 1 3 6 which would run deploy1, deploy3 and deploy6

i already have the cheatcodes written and tx crafting done. now it’s the hard part of actually building the interaction with the VM
addressing comments:

I wonder how well this would work for necessariliy moduralized deployments of larger projects and/or maintaining an idempotent deployment over a longer time span with different parts of the project having different lifespans & different solidity versions.

having multiple deploy1 deploy2, etc, as well as separate deploy contracts should make this trivial to upgrade and manage larger repos & varying lifetimes & versionings because you can simply have a contract that is UpgradeA that has a new pragma 0.8.11 for example, which would import UpgradedA that also used that version. So the compiler pipeline would just take care of the versioning for you.

Imho, this is related because integration testing on top of the actual deployment can be quite useful: #326
Agree, stdlib will have a helper function for getting code that isnt compatible with a particular version that leverages the getCode cheatcode.

awesome. Thoughts on renaming IS_DEPLOY to something like IS_LIVE_REQUESTS to indicate that this could also be used for making live txs and not just deploys?

ye good thought - we should make all naming agnostic to deploy vs normal txs

support contracts that have IS_DEPLOY - similar to IS_TEST

afaik we don't actually use IS_TEST, and just use the test prefix to identify test functions—just mentioning since it'd be nice to have consistent behavior between how the special prefixes behave, especially since we'll likely have more prefixes in the future too, like invariant and prove
also, how would it work with reusing the deploy() methods so you can run tests against post-deploy state? would you just call the deploy methods within setUp() and have deploy assign the deployed contracts to your test contract state variables?

Hi, just found about this discussion after @onbjerg mentioned it to me here: https://github.com/gakonst/foundry/discussions/634 where I basically mention the lack of mechanism to replicate deployment procedure in tests and allude to a potential mechanism to solve it.
I see that here you are discussing an approach where you start from the solidity test and imagine thus a mechanism where such test solidity code would perform the deployment themselves, making these deployment setup available in test as a matter of fact.
I have been thinking of a different approach, where the deployment procedure would be free to use whatever programming language suits them.
This has several benefit compared to a solidity approach:

full flexibility, reading file, managing proxy upgrade and check like storage layout changes, etc...
no bottleneck on the availability of specific cheatcode (with the approach discussed here, I can easily imagine request for specific cheatcode not thought of initially)
no need to learn a new DSL (cheatcode)
can reuse existing library to deal with all the intricacies of deployments, including L2 like zksync that require different transaction mechanism.

The way I see that alternative approach is as follow :
forge would let the user setup the EVM state before running the tests by invoking some scripts.
Basically such script would be given a RPC endpoint (FOUNDRY_RPC_URL) and can perform any action on it, including but not limited to contract deployment. The only requirement for these scripts would be to save the contract data in a specific location / format so that the solidity tests can reuse them.
Thinking of something like:
forge test --before "deploy.py" or forge test --before "node deploy.js" or whatever
where forge would execute whatever command is passed to it, here "deploy.py" or "node deploy.js", but this can be anything.
That execution would have a specific environment variable set to be the RPC endpoint to talk to (FOUNDRY_RPC_URL) and maybe other env variavkes too. Here, since we are dealing with the test command, the rpc endpoint would simply be the in-memory EVM against which the tests are run.
deploy.py or deploy.js would then do whatever it want to with that rpc end point (Deploying new contracts, making calls, constructing merkle trees, making proxy upgrades, including checking storage layout conflict, etcc...). the only thing it needs to do is to save the result of the deployment in specific location / format.
Once the script finishes, forge can then execute the tests and provide cheatcode for the tests to access the deployment data (like addresses, argument used or more). forge should also snapshot the state of the EVM before the tests are executed so that it reset to it before every test, (instead of having to re-execute the deployments). (evm_snapsnot)
Then when it is time to deploy on a network, the script would not even need forge, but forge could have a command to facilitate the setting of the environment variable described above. something like :
forge deploy --network rinkeby "deploy.py" or a more generic term might be forge execute --network rinkeby "node deploy.js" (because after all these does not need to be about deployments of new contracts)
a js script could look like this
...
const provider = new JsonRPCProvider(process.env.FOUNDRY_RPC_URL);
...
async main() {
  ...
  const factory = new ContractFactory(abi, bytecode, signer);
  const contract = await factory.deploy();
  fs.writeFileSync(`${process.env.FOUNDRY_DATA_FOLDER}/MyDeployedContract.json`, {address: contract.address, abi, bytecode, ...});
}

As for the solidity test, these would look something like the following:
...
  function setUp() {
    MyDeployedContract myContract = MyDeployedContract(vm.getData("MyDeployedContract01").address);
  }
...

What do you think ?

@wighawag I think that in this discussion we've already reached consensus that deployments should absolutely be available to tests. It's clear that we need to be able to verify the integrity of a deployment. Handling deployment artifacts & I/O of some kind is definitely necessary too.
full flexibility, reading file, managing proxy upgrade and check like storage layout changes, etc...
This can be achieved with cheatcodes (handling deployment artifact / config I/O, etc.) too and particularly storage layout changes, etc. are more easily tested directly in solidiity rather than through the JSON RPC indirection.
no bottleneck on the availability of specific cheatcode (with the approach discussed here, I can easily imagine request for specific cheatcode not thought of initially)
Cheatcodes are great and are simply the equivalent of e.g. hardhat_impersonateAccount or other custom JSON RPC methods. Missing cheatcodes can be worked around with iif or  by possibly making cheatcodes pluggable through other means in the future. Not sure if this has been discussed yet.
no need to learn a new DSL (cheatcode)
What's the difference between learning cheatcodes vs. custom rpc calls & other stubbing / mocking / artifact loading etc. utils in a less native environment. Personally, I think the benefit of using solidity code for deploying contracts is much more intuitive than going via multiple layers of indirection & abstraction in a foreign language.
can reuse existing library to deal with all the intricacies of deployments, including L2 like zksync that require different transaction mechanism.
There are definitely certain (arguably less common) use-cases that might not be covered initially. I think that's fine. Personally, I am absolutely positive that solidity-native deployments are going to offer a far superior developer experience for the majority of cases. Let's not discard this attempt just because it might not cover all cases right off the bat.
All that said, nothing is stopping you from building a deployment framework around JSON RPC & the build artifacts produced by the compiler. You could load the deployment artifacts into a fork test (e.g. with a custom cheatcode or iif) and proceed to verify the deployment there.

@fubhy thanks for the reply
Looking forward to see such solidity-based deployment implemented :)

All that said, nothing is stopping you from building a deployment framework around JSON RPC & the build artifacts produced by the compiler. You could load the deployment artifacts into a fork test (e.g. with a custom cheatcode or iif) and proceed to verify the deployment there.

One benefit of the approach I mentioned, is that I would actually have to do nothing and could reuse existing framework.
from what you said here, it seems I can already do it. Where could I learn more ?

Cureent plan is for @brockelmore to handle the cheatcode / TX creator, and I'll write the "driver" code which executes each migration to completion idempotently, with gas escalation/rebroadcast for reliable inclusion etc. We'll update you all - thx for all the feedback

Just making a note: this is a feature most people will not really leverage in the sense that they do not typically have overly complicated deployments.
I have used this before
https://github.com/icetan/abi-to-dhall
It generates a bash script for deploying, it cam handle doing the entire DSS. I think the autogenerated deployment scripts should be a feature especially in large deployments: who wants to waste time doing that.
As for persistence of compiled and deployed output , we need it for verification and for downstream distribution. We could solve both at once and provision a service that offers that, I had explored this idea a few months ago with https://abi.storage
Cheers

just to clarify the benefit of having persistence handled together with deployment is now you could provide a URL to consumers of your application/etc, like unpkg. esm.sh, etc

Definitely!
To add to that, another very useful feature (present in hardhat-deploy) is the ability to share the deployment procedure itself. Very useful to integrate whatever protocol in your integration tests / app.
For example, if you use hardhat-deploy and you need to test your protocol against uniswap, just import hardhat-deploy-uniswap-v2 (ideally provided by the project itsself) from npm and you can do deployments.fixture('UniswapV2Router') and get access to a fully deployed uniswap, in your test but also when you develop your app.

+1
something like hardhat-deploy would definitively be useful like. For example:

deployment files as solidity, that can be used to deploy in tests but also when starting a local node. This way you can test your website locally with your new contracts.
deploy them, using the same deployment procedure you used for your tests.
record the deployment inside deployment files so it's easy to verify them.

I guess the deployment solidity files would need to use functions that uses special cheatcode so that they can work for both testing/localnode and live deployment ?
I think that's the missing key for Foundry "mass-adoption".

Ability to Use a defined artifact packaging schema, eg eth-pm, dpack, pojson, etc

also, websockets.

I'm new to this so this may be both off topic and wrong, but I'm wondering if y'all considered using a proxy pattern coupled with deploy contracts.
Based on my reading from ds-proxy couldn't we have forge deploy a proxy for each account, and then forge build into a cast send?

I'm new to this so this may be both off topic and wrong, but I'm wondering if y'all considered using a proxy pattern coupled with deploy contracts. Feels like it would simplify a lot of the semantics
Based on my reading from ds-proxy couldn't we have forge deploy a proxy for each account, and then forge build into a cast send?

We don't want to force users into a particular setup. We want this to feel like a better version of writing a script in javascript. Adding a proxy and what not forces users into a particular style. Given the work in #1208, I think we will stick with this

See https://github.com/foundry-rs/foundry/discussions/1840


build a CI/CD pipeline with GitHub Actions

I created cmake.yml from templates provided by GitHub.

Since there has been no significant activity on this repository for years, I don't think there's any need in updating CI.


[SMALLFIX]Change mSeekBuffer to final mSeekBuffer

Improve core/client/fs/src/main/java/alluxio/client/file/FileInStream.java as mSeekBuffer can be marked as final.
Change
private byte[] mSeekBuffer;
to
private final byte[] mSeekBuffer;

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/17210/
Test PASSed.

Merged build finished. Test PASSed.


Lag issues stutters

Every second, it keeps dropping by 10 fps, and it's so annoying. It keeps stuttering, and every time I aim, it drops to 40 fps. Turning off notifications helped, and the random aim-part mode is causing the stutters and lag.

I will check it later. Thanks a lot for reporting

Notifications cause this lag as @Dafuuh says.
When i disable the notifications my fps goes up to 200 normally.
When its enabled i have spike lags.

The reason is starting threads (spawning tasks) in RenderStepped, that notifications create. Probably, the only one way to resolve this issue is remove notifications calls from Aimbot Loop.

Issue resolved. Thanks for patience


feat: add forall audit

Add a built-in audit that allows arbitrary expressions that must hold for all rows in a model.

@plaflamme thank you so much for this pr. it's very well done. i'm super impressed!


Continuous Integration with Constant Checks when Manim CE Updates

https://stackoverflow.com/questions/58465057/trigger-a-github-action-when-another-repository-creates-a-new-release


wrapper.js

new cmd where !wrapper player ChiefChippy2 would imitate a call to the api, like getPlayer("ChiefChippy2")
inb4 very unstable.

TypeError: Found non-callable @@iterator

TypeError: Found non-callable @@iterator

args.args

args.args

If -raw flag

If -raw flag


include ANTS

Per https://github.com/cedadev/jasmin_scivm/issues/189

Also Helpscout ticket 24521

Migrated.


pkg/config(ticdc): enable pull based sink

What problem does this PR solve?

Issue Number: close TBD
What is changed and how it works?
enable pull-based sink.
Check List
Tests

Unit test

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
None

Codecov Report

:exclamation: No coverage uploaded for pull request base (release-6.5@1ce0a34). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head c37982d differs from pull request most recent head 05fa2bc. Consider uploading reports for the commit 05fa2bc to get more accurate results

Additional details and impacted files

Flag
Coverage Δ

cdc
63.8425% <0.0000%> (?)

dm
53.2485% <0.0000%> (?)

engine
66.6129% <0.0000%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
@@               Coverage Diff                @@
##             release-6.5      #8220   +/-   ##
================================================
  Coverage               ?   59.8290%
================================================
  Files                  ?        813
  Lines                  ?      93936
  Branches               ?          0
================================================
  Hits                   ?      56201
  Misses                 ?      33046
  Partials               ?       4689

/run-all-tests


Flex: detect empty/broken media repositories

Problem 1

@terencode and @obstriegel had the issue when installing inexor that the media folders where there  but not correct git repos and empty.
We should detect that.

Problem 2
(copied from #434)

Right now when a media repository is not properly initialized the whole thing will blow up with:

Jun 20 19:52:04 @inexor-game/flex/server[28817] INFO:  Cannot read property 'substr' of undefined
  err: TypeError: Cannot read property 'substr' of undefined
      at GitRepositoryManager.mergeBranches (./node_modules/@inexor-game/media/Repository.js:513:29)
      at ./node_modules/@inexor-game/media/Repository.js:459:23
      at tryCallOne (./node_modules/nodegit-promise/lib/core.js:37:12)
      at ./node_modules/nodegit-promise/lib/core.js:103:15
      at flush (./node_modules/asap/raw.js:50:29)
      at _combinedTickCallback (internal/process/next_tick.js:73:7)
      at process._tickCallback (internal/process/next_tick.js:104:9)

It would be good to also spawn the git cloning in a dedicated process, so it will not be killed when flex is killed.

Tasks

[x] detect empty/broken media repositories
[x] detect failed clone/update
[x] check integrity of a media repository
[x] restart (or continue) clone/update

Probably because the cloning the repository has started but not completed. The folder may have been created but is empty.
A solution would be to check if repository.json or repository.toml exists.

It will probably be useful to implement a pipeline library (small) to do the following tasks for us

download media repositories
download core releases

the pipeline should preferably spawn a dedicated, new process (shell/bash/dos) and launch the download there, so in any case the download operation is continued.
For the validity part, the following can be used

https://git-scm.com/docs/git-fsck for git repos
the checksums of the zip files for the core zip files

Prevent crashes

A first effective and simple solution is already done: In https://github.com/inexorgame/inexor-flex/commit/51dc8081177529800ce13ce3a441db943e8c035e we prevent Flex from exiting cause of unhandled exceptions. This way the stability has been improved a lot. The remaining unwanted exits are segfaults in native nodejs extension (for example in grpc).

Prevent exit during updates or other transactional tasks

An additional task is to block Flex from exiting if there are transactional tasks (like git clone/git pull) still running. We could add a service for this.

Better use an integrated API instead of external programs

There's a little problem with Node.js and external tasks: In order to get any response from the external task you have to connect to it's stdout. But with stdout connected and Flex exits or crashs the external child process is also terminated. Without stdout connected there's a black box running but at least the external process won't be terminated.
Also you run into more problems:

git as end user dependency. Now we are using Nodegit which uses or bundles the native libgit2 library.
We can't profit anymore from the tight integration of the API provided by nodegit: http://www.nodegit.org/api/.
I really don't want to parse the console output of git commands.  Also, the console output of git commands changes with new versions.

Since this is implemented in Inexor Flex but not tested by others than myself, please give me feedback.

Delete your media repository
Start Flex with the dev profile to get verbose logging
Kill Flex while cloning a repository for the first time
Restart Flex with the dev profile
Check if it result in a successfully cloned repository after a while

I can verify that this works


try catch with keyboard for debug flag

add keyboard in catch under debug mode

I'm not sure what this means.
On Thu, Mar 9, 2017 at 4:45 PM, Erik R<EMAIL_ADDRESS>wrote:

add keyboard in catch under debug mode
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/DynaSim/DynaSim/issues/109, or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGOVW2wwQ-5UNL-PFP5OUJF26QtXIIrks5rkHL5gaJpZM4MYrLN
.


Changes in Home Assistant Core 2021.3

No 'version' key in the manifest file for custom integration 'hifiberry'.
This will not be allowed in a future version of Home Assistant.
Please report this to the maintainer of 'hifiberry'

See https://www.home-assistant.io/blog/2021/03/03/release-20213#breaking-changes
Under Custom integrations: Version warning

@willholdoway add the code below to manifest.json to solve the warning
"version": "0.0.1"


I need help with an error

[ Bot [#1] 2015-09-16 17:22:28] SUCCESS: Done Loading Bot!
[ Bot [#1] 2015-09-16 17:22:32] SUCCESS: User Authenticated!
[ Bot [#1] 2015-09-16 17:22:32] INFO: Trying to fetch trade offers (attempt 1/5)
[ Bot [#1] 2015-09-16 17:22:32] SUCCESS: Trade offers fetched.
[ Bot [#1] 2015-09-16 17:22:32] INFO: Downloading Schema...
[ Bot [#1] 2015-09-16 17:22:33] SUCCESS: Schema Downloaded!
[ Bot [#1] 2015-09-16 17:22:33] SUCCESS: Steam Bot Logged In Completely!
[ Bot [#1] 2015-09-16 17:22:33] ERROR: System.ArgumentException: Configured control class type was null. You probably named it wrong in your configuration file.
Parameter name: bot
at SteamBot.BotManager.UserHandlerCreator(Bot bot, SteamID sid) in c:\Users\Anthony\Desktop\bot_source\SteamBot\BotManager.cs:line 244
at SteamBot.Bot.GetUserHandler(SteamID sid) in c:\Users\Anthony\Desktop\bot_source\SteamBot\Bot.cs:line 806
at SteamBot.Bot.b__5(LoginKeyCallback callback) in c:\Users\Anthony\Desktop\bot_source\SteamBot\Bot.cs:line 476
at SteamKit2.CallbackMsgExtensions.Handle[T](ICallbackMsg msg, Action`1 handler)
at SteamBot.Bot.HandleSteamMessage(ICallbackMsg msg) in c:\Users\Anthony\Desktop\bot_source\SteamBot\Bot.cs:line 458
at SteamBot.Bot.BackgroundWorkerOnDoWork(Object sender, DoWorkEventArgs doWorkEventArgs) in c:\Users\Anthony\Desktop\bot_source\SteamBot\Bot.cs:line 976
[ Bot [#1] 2015-09-16 17:22:33] WARN: Restarting bot...

Any reason to believe this is a bug?  It looks like misconfiguration.

@BlueRaja, Yeah I can understand but I'm asking if anyone know's how to fix this error/misconfiguration.

Rebuild your project.
Go to your config.json and properly specify BotControlClass property.

I fixed it thank's for the help

@OhhTony This tracker is for bug reports, please use the SteamBot subreddit in the future.


Can we provide little more detail on error when google translate call fails

Right now it uses following code in case of error
err = 'Something went wrong. Google responded with a status-code:' + res.statusCode

May be we can use something like following
body = JSON.parse(body);
if (body && body.error && body.error.message) {
    msg = body.error.message;
}
err = 'Something went wrong. Google responded with a status-code:' + res.statusCode
    + (msg ? ' message:' + msg : '');

Let me know if you need a pull request.

This looks great, @basghar. If you submit a PR I'm happy to merge it in!

Done!!


Fix #291

Added a test to confirm #291.
Then made the change which fixes that issue.
I hope it's up to standards and we can get this fix through quickly. Let me know if any changes need to be made!

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Remove duplicate code to check email/username in volunteer_controller

The following code in volunteer_controller checks if there is a duplicate entry in the Volunteer table. This logic is already performed
exports.createVolunteer = function(req, res) {
var email = req.body.email_address;
var usern = req.body.username;
Volunteer.findOne( {$or: [{'email_address': email}, {'username': usern}]},
    function(err, volunteer) {
        if(volunteer != null) {
            //this is a duplicate entry
            req.session.email_duplicate = true;
            res.redirect('/volunteer/sign-up');
        } else {
            var volunteer = new Volunteer({
                first_name: req.body.first_name,
                last_name: req.body.last_name,
                email_address: req.body.email_address,
                username: req.body.username,
                password: SHA3(req.body.password).toString(),
                //TODO: Add confirm password?
                finished_training: false,
                approved: false,
                linked_in: req.body.linked_in,
                volunteer_question: req.body.volunteer_question
            });
            volunteer.save(function(err, volunteer) {
                if(err) {console.log(err);}
                else {
                    req.session.admin = volunteer.is_admin;
                    req.session.logged = true;
                    req.session.volunteerId = ObjectId(volunteer._id.toString());
                    req.session.email = volunteer.email_address;
                    req.session.fullname = volunteer.first_name + " " + volunteer.last_name;
                    req.session.finished_training = volunteer.finished_training;
                    res.redirect('/volunteer/training');
                }
            });
        }
    });

};
The above code has duplicate logic as the code block below in the volunteer controller.
exports.check_email_username = function(req, res) {
var email = req.body.email;
var username = req.body.username;
Volunteer.findOne({'email_address': email}, function(err, volunteer_email) {
var email_exists = (volunteer_email != null);
Volunteer.findOne({'username': username}, function(err, volunteer_username) {
var username_exists = (volunteer_username != null);
if (email_exists && username_exists) {
res.send("both");
} else if (email_exists) {
res.send("email");
} else if (username_exists) {
res.send("username");
} else {
res.send("neither");
}
});
});
}

Actually in a very convoluted way, this logic seems to enforce the "Incorrect Login" message. For that sake it might be worth it leaving it behind at the moment. Closing :(.


minor edit to new intel URL

#1277 does the same with wildcards in case they change it again

Please add the new URLs instead of replacing the old ones, in case they ever change their mind and revert the URL.

Duplicate of #1278


Fix __dlpack__ protocol

When doing interop tests with PyTorch two issues were found,
__dlpack_device__ returns the cupy device object instead of the id, so PyTorch crashes.
__dlpack__ gets the current torch stream, which defaults to 0 (legacy stream), but for some reason, CuPy seems to error on it. I think it should be accepted (cc @leofang)

pfnCI, test this please.

Jenkins CI test (for commit 73f8fd1beb75d5743bd88480fc25018fb65bacef, target branch master) failed with status FAILURE.

Jenkins, test this please

Jenkins CI test (for commit 69b6511d35de03fc281d40e612c8c4d0fd573303, target branch master) succeeded!

Jenkins, test this please

Jenkins CI test (for commit 4a1058719aad08022aa859939059ba50051f6af9, target branch master) succeeded!

CUDA 11.5 CI passed right on the time limit 😂

I'm sorry for coming late to the discussion here, but I'm against introducing this env var. What we should provide is a smooth experience between libraries that just work. I don't want to say "please set this CuPy env var because PyTorch has a bug", which imposes the responsibility to users and is bad messaging for promoting a new standard.

Otherwise this would defeat the purpose of all the hard debates for removing 0 ...

I agree on this point, but as long as all producers are implemented correctly there's should be no issue. And the only known bad implementation is PyTorch which does not use PTDS.

This is a workaround, not a permanent thing.

We can possibly remove this workaround before the CuPy v11 final release considering PyTorch releases are out every 3 months 😃

I don't want to say "please set this CuPy env var because PyTorch has a bug", which imposes the responsibility to users

I agree, but

and is bad messaging for promoting a new standard.

And the only known bad implementation is PyTorch which does not use PTDS.

We need to be future-proof. Other libraries will catch up and some of them might mess up like PyTorch did in the first few iterations, and we won't know if each of them is on PTDS or not.
I'd say while we don't wanna introduce something for others' fault, we also don't want CuPy to be blamed when something hard to debug happens. Plus, the way I see it, the error message is actually doing a good thing to the community: it prompts users to report a very clear bug for upstream to fix.

(Hmm maybe I'm an enthusiastic fan of the Postel's Law 😅)

We need to be future-proof. Other libraries will catch up and some of them might mess up like PyTorch did in the first few iterations, and we won't know if each of them is on PTDS or not.

I agree with this. However, PyTorch/CuPy integration is a "real" use-case for us that users will likely start using immediately after CuPy v10 is out. I don't want to see many users defining CUPY_DLPACK_ACCEPT_STREAM_ZERO=1 which will be a short-lived API (i.e., likely to be removed once PyTorch is fixed). If users get used to defining it everywhere, we cannot be a "future-proof".
How about emitting a warning like this, then?
Stream 0 is passed from a library that owns a tensor you are converting from; CuPy assumes it as a legacy default stream.
Please report this problem to the library as this violates the DLPack protocol.

Changed to use warning, PTAL!

fixed flake8 😥

(Sorry, I pushed to Emilio's branch because I couldn't disable auto merge)
Jenkins, test this please

Jenkins CI test (for commit e2882053bf1ce75dfe7b2c7947f0ae6fe9274a93, target branch master) failed with status FAILURE.

Jenkins, test this please

Jenkins CI test (for commit e2882053bf1ce75dfe7b2c7947f0ae6fe9274a93, target branch master) succeeded!

pfnCI, run Jenkins please.

Jenkins CI test (for commit 199c4e0df639fd9fcc5e38aa912a692108b9e2e8, target branch master) succeeded!

Confirmed that warning is displayed as expected. (as reviewed the message needs to be fixed)
>>> torch.utils.dlpack.from_dlpack(cupy.arange(10))
/home/maehashi/.pyenv/versions/local-3.9.5/lib/python3.9/site-packages/torch/utils/dlpack.py:61: UserWarning: Stream 0 is passed from a library that owns a tensor you are converting from; CuPy assumes it as a legacy default stream. Please report this problem to the library as this violates the DLPack protocol.
  dlpack = ext_tensor.__dlpack__(stream=stream.cuda_stream)
tensor([0, 1, 2, 3, 4, 5, 6, 7, 8, 9], device='cuda:0')

torch: 1.10.0+cu113

updated the warning message


Deployment of the serverless IIIF application in the eu-west-1 region fails

I tried to deploy the serverless IIIF application using https://eu-west-1.console.aws.amazon.com/cloudformation/home?region=eu-west-1#/stacks/create/template?templateURL=https://nul-public.s3.amazonaws.com/serverless-iiif/deploy.yaml.
The process terminate with a rollback with a CREATE_FAILED error related to Dependencies50202cd119. The explaination of the error was:

Error occurred while GetObject. S3 Error Code: PermanentRedirect. S3 Error Message: The bucket is in this region: us-east-1. Please use this region to retry the request (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: a4f0d97a-3e93-42e5-8a84-f9e717469023).

I retry the deployment in the us-east-1 region and the deploy procedure works fine.

Hmm. Yes, the bucket with the Lambda function code is in us-east-1, which ties the deployment to us-east-1. I can look into some solutions, but relocating the code, customizing the template, and then redeploying using the custom template might be the best you can do for now.

Once #2 is merged, you should be able to just rebuild, package, and deploy with something like:
cd dependencies/nodejs
npm install
cd ../..

aws cloudformation package \
  --template-file ./template.yml \
  --s3-bucket my-package-bucket \
  --region eu-west-1 \
  --output-template-file package_output.yml

aws cloudformation deploy \
  --region eu-west-1 \
  --template-file ./package_output.yml \
  --stack-name serverless-iiif \
  --capabilities CAPABILITY_IAM \
  --parameter-overrides SourceBucket=my-image-source-bucket

Note: you'll need node 10 to rebuild the dependencies. 12 seems to be broken (I'll add an issue on this)

Deploying using SAM
Windows key + “Ubuntu” to run Ubuntu on WSL.
Clone and cd to serverless-iiif repo.
nvm use 10.19.0
cd dependencies/nodejs
npm i
cd ../../
sam deploy --guided
Stack Name [sam-app]: name-your-stack
AWS Region [us-east-1]: your-region
Parameter SourceBucket []: image-bucket-name
Parameter StageName [latest]:
Confirm changes before deploy [y/N]: n
Allow SAM CLI IAM role creation [Y/n]: y
Save arguments to samconfig.toml [Y/n]: y

SAM worked for me, but npm install has to be done in a linux environment. I did the following on a mac:
docker run -v "$PWD":/var/task lambci/lambda:build-nodejs12.x npm install


5.7 - 15: Sửa Webhook - Sửa send actions Label link created

Checked Label link created hiển thị trạng thái on

https://onedrive.live.com/View.aspx?resid=495A9FD49F594800!152&authkey=!AIjA8V7ngGWbw7g


On the issue of the message content not being formatted after selecting JSON format for display

The encoding received by subscription cannot be displayed in JSON format. If I paste the JSON format of the published message, I should take the initiative to help me format the JSON format after pasting it. However, now there is no help for me to format the JSON format, so I must re-select the JSON format every time. I think that's what a lot of developers want！
Thank you！

@BarryYBL Hello! Thanks for your feedback! YES, you are right, currently it does not automatically help you format JSON data, if you need to format, you need to paste in Plaintext mode, and then select to JSON format, in order to automatically help you format. JSON format is currently the most useful, can only help you check whether the format is correct, later we can optimize the automatic formatting of the problem.

Thank you very much

Hi, thanks again! Currently supports automatic beautification of received JSON format data.

And you can right-click to use the context menu to beautify JSON data.

OK，veryGood！


Support for u8string?

In c++20, u8string is added.
Is there any plans to add convertion between std::string and std::u8string,
and also support something like
std::u8string utf8::utf16to8(std::u16string)?

Sorry for the late answer.
I am planning to add support for std::u8string in release 4.0. But I am not sure what do you mean by "conversion between std::string and std::u8string". What encoding would you expect the std::string to be?

Encoding of std::string is also utf8, I just mean the type convertion between std::u8string and std::string, i.e. something like
std::string utf8::utf8tostr(std::u8string)
I am currently facing some problems like this.
Thanks in advance for the update.

Fixed in release 4.0.0


Using Only oisy-wallet-signer for Authenticated Canister Calls

Hi everyone,
I’m not sure if this is the right place or the best way to ask, but I have a question regarding authenticated canister calls. Specifically, is it possible to perform authenticated canister calls using only the oisy-wallet-signer, similar to how I’ve used the classic AuthClient or NFID to generate an identity and an agent?
Any guidance or examples on how to achieve this would be greatly appreciated.
Thank you!

Hi,
OISY does not, at least currently, delegate sessions, but it does support ICRC-49, which allows dApps to execute canister calls through the wallet.
My understanding is that the foundation generally recommends using IdentityKit for clients. It is compatible with React. If you are using another technology, you can implement the flow yourself by using the signer-js library, which is used under the hood by this solution.
Alternatively, if none of the above fits your needs, you can also take a look at the oisy-wallet-signer, which includes an opinionated client.
Hope that helps.


Establish Working CONTRIBUTING

The author is not satisfied with the current state of CONTRIBUTING.md and wants to update it.

Contributing Guidelines
The author(s) of this repository appreciate external feedback and contributions.
To improve this feedback process, we urge you to read and adhere to the
following guidelines:

Provide clear, evidenced arguments for your changes, where possible this will aid future onlookers in understanding why certain features came to be the way they are. Additionally, this facilitates the author(s) in learning why and how they've erred. Finally, taking the time to make your arguments clearer can prevent the creation of feedback that is misguided, incorrect, or inadequate relative to other possible changes.

[additional guidelines pending]

The updated contents should be general enough such that they can be still effective across most of the author's repositories without further edit. To some degree, the author wants CONTRIBUTING.md to reflect the author's preferred norms around code-development and communication.

The following are example CONTRIBUTING files to work from:

https://github.com/Yelp/detect-secrets/blob/master/CONTRIBUTING.md
https://github.com/python/mypy/blob/master/CONTRIBUTING.md

The template CONTRIBUTING can be included as a dropdown in the template CONTRIBUTING.

Notes and considerations for the content of CONTRIBUTING should be stored in

https://github.com/AFg6K7h4fhy2/AFg6K7h4fhy2/tree/main/decisions


Bug fix/cleanup 06052020

Scope & Purpose
This fixes warnings such as
2020-05-05T23:35:15Z [24504] P WARNING [66666] {cluster} Loading the new plan took: 0.628109

that frequently occur in devel.
In current devel, we are currently spending lots of time in ClusterInfo::loadPlan(). The code in loadPlan() always throws away all LogicalCollection instances and replaces them with new ones. Even if the underlying collections didn't change. This permanent deletion and recreation of LogicalCollection instances is not free, and that's why in the past we added tuning knobs in RocksDBCollection and RocksDBIndex so that they don't create in-memory caches for these objects. More precise, we added an isAStub() getter to LogicalCollection that RocksDBCollection and RocksDBIndex check before adding an in-memory cache instance.
This PR reuses that logic so that we don't create revision tree objects for collections from the ClusterInfo. These are expensive to create, but unnecessary for the ClusterInfo's LogicalCollection object instances.
This change should prevent the issue from happening in almost all cases.

[x] Bug-Fix for devel-branch (i.e. no need for backports?)
[ ] The behavior in this PR can be (and was) manually tested (support / qa / customers can test it)
[x] The behavior change can be verified via automatic tests

Testing & Verification
This change is already covered by existing tests, such as all tests.
http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/9755/

http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/9757/

Tests blue

Re-running tests after small changes:
http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/9765/

Tests ok


Package in Debugger Has Issues With Values

If I debug this code where it's reference Spackle as a package:
var range = 1..50000;
var partitions = range.Partition(7);
Console.Out.WriteLine(partitions.Length);

foreach(var partition in partitions)
{
	Console.Out.WriteLine($"{partition}\t\t{partition.End.Value - partition.Start.Value}");
}

When I step into Partition(), I get the code in the debugger as expected, but...the local values seem "off":

I see the same thing, although my experience is slightly worse. I don't get an instruction pointer (the yellow arrow) and it is getting confused on whether RangeExtensions.cs is loaded or not.
I'll ask for some help.

Not likely it, but when you build this library, is your working tree clean? If you type git status before you build, you should see: nothing to commit, working tree clean.

@richlander I looked, and right now git status is giving what you expected it would. But, I don't remember if I built the .nupkg and .snupkg with everything committed as expected. I'll try making a new version and ensure the status of the repo is good.

@richlander I pushed a 9.1.5 version, making sure the repo was in the expected status when I built it, and I'm still seeing the issue :(

@JasonBock please try enabling "Suppress JIT optimizations on module load (Managed only)" under Debug->Options

That seems to have done the trick :)
One thing....I would've never figured this out myself. It may be worth updating any related docs on this topic to enable this setting (or it may already exist and I missed it).


Type for ContextRegistry

I believe the type for ContextRegistry could be improved by removing the index signature. Leaving it means that no matter what I write in (for example) ContextProvider @key - Glint won't complain. If the index signature is not there, only valid keys will be accepted. Which is a much better developer experience. What do you think?

@boris-petrov I think that suggestion makes sense!
Restricting the provider component (and decorator) to only accept explicitly declared keys might help developers catch certain bugs early by warning them when they're trying to use unknown context keys.
The registry is defined the way it is now to make it easier for developers to adopt this addon, though as it matures I can definitely see us switching to more strict types.

Thanks for the answer! I've opened a PR for this. I'm not sure how this index-signature makes it easier to adopt the addon - it only would allow people to make typos that are not caught. Maybe I'm missing something - if you think it's not the right time, you can close the PR or leave it open for later. :)

I'm not sure how this index-signature makes it easier to adopt the addon - it only would allow people to make typos that are not caught

The way it's currently typed makes it easier because a developer doesn't have to add keys to the context registry to use this addon (without typescript complaints).
It's a minor thing, though it does lower the barrier of adopting the addon a little bit. But I agree with you that this is the less type-safe way to do it, as you don't get any hints on whether the keys you're adding are in fact correct.

Ah, I see what you mean. Well, I would argue that if one is using JS only that's not a problem. If one is using TS, they would certainly want more type-safety anyway. But you're technically right so I'll leave the decision whether to merge the commit to you. :)

fwiw, I think this is a good idea, and would love to see the above mentioned PR merged :)


v0.9.3 breaks imports with SvelteKit

Just saw the new version tagged and updated, but it does not seem to work with SvelteKit. So if you have this issue, you can stay on 0.9.2 for now.
Here is a SvelteLab reproduction:
https://www.sveltelab.dev/k303hv6xldifpue
 The plugin "vite:dep-scan" was triggered by this import

    src/lib/stores/user.ts:3:26:
      3 │ import { persisted } from 'svelte-persisted-store';
        ╵                           ~~~~~~~~~~~~~~~~~~~~~~~~

✘ [ERROR] Failed to resolve entry for package "svelte-persisted-store". The package may have incorrect main/module/exports specified in its package.json. [plugin vite:dep-scan]

I can confirm this change breaks Vite's build process (So even just Vite + Svelte)

I can confirm the same thing happens for me.
It's caused by an attempt to fix this issue: https://github.com/joshnuss/svelte-persisted-store/issues/258
It seems simply adding type: "module" is not enough.

what's needed is adding exports field to package.json
<EMAIL_ADDRESS>@joshnuss I suggest you add a publint as part of your CI / prepublish checks: npx publint

Thanks for reporting!
Sorry about that.
It is now fixed in ddfe9d41b0ec1476f1d0f96e0411f2c48b0317de.
Please update to v0.9.4


Support Periodic Bib Sync

Reported by Scott Sutter:

The only problems we ran into with the App were (that may have been user error):
The bib number for one runner (Ken Clark #364) did not appear in the grid view.
Doesn’t appear the App fully synced with the Check-In App.

Resolution for now is to simply toggle back to normal entry mode and back into bib grid mode. In the future we may want to support a true sync model to ensure that bib numbers are up to date in the app.

Closing in favor of #39, because they are very related. #39 will add both a manual refresh and an auto refresh every minute.


WFLY-2627 test for override transaction type through ejb-jar.xml

Test for https://issues.jboss.org/browse/WFLY-2627
https://bugzilla.redhat.com/show_bug.cgi?id=1180556
replace PR for this https://github.com/wildfly/wildfly/pull/7164

Can one of the admins verify this patch?

This is ok to test

Windows Build 1002 is now running using a merge of f93d606d44a1bbbb58494d67dac064ea6c2df7e1

Linux Build 5892 is now running using a merge of f93d606d44a1bbbb58494d67dac064ea6c2df7e1

Linux with security manager Build 871 is now running using a merge of f93d606d44a1bbbb58494d67dac064ea6c2df7e1

Linux with security manager Build 871 outcome was SUCCESS using a merge of f93d606d44a1bbbb58494d67dac064ea6c2df7e1
Summary: Tests passed: 839, ignored: 316 Build time: 0:05:21

Windows Build 1002 outcome was SUCCESS using a merge of f93d606d44a1bbbb58494d67dac064ea6c2df7e1
Summary: Tests passed: 2925, ignored: 312 Build time: 0:46:20

Linux Build 5892 outcome was SUCCESS using a merge of f93d606d44a1bbbb58494d67dac064ea6c2df7e1
Summary: Tests passed: 2925, ignored: 312 Build time: 0:47:22


False position readings

Came across false position reading this morning. Seems my car took a trip to the south pole :-).

I've pushed a fix for this, I'll create a new RC tonight

@bj00rn do you have a way of checking past longitude values?
Technically they should range from -180 to 180 but I have no idea of the format used by SAIC

For posterity, how to get lat longitude from ha db
find metadata_id:
sqlite> select * from states_meta where entity_id like "%pos%"

find state attributes:
select shared_attrs from states s JOIN  state_attributes sa ON s.attributes_id = sa.attributes_id where s.metadata_id =


Change the pattern for relative imports in scoped components

What
This is a complex problem that probably warrants a different long-term solution, but this unblocks things for now.
The normal pattern of from ...blueprint import components created a potential conflict when an archetype used a mix of components from blueprint and core components.
The next fix we tried of just import from ... import blueprint appeared to work, but led to circular import errors on archetypes, since components would try to import blueprints which would include archetypes before components was initialized.
We now only import the direct packages we need from the scope, but introduce an alias {scope}_{type} to avoid the collision.
Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested the web demo (if applicable):

Using newly built examples: app.rerun.io
Using examples from latest main build: app.rerun.io
Using full set of examples from nightly build: app.rerun.io

[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
[x] If applicable, add a new check to the release checklist!

PR Build Summary
Docs preview
Examples preview
Recent benchmark results
Wasm size tracking

On 0.14.1 on windows I get the following:

Is importing in this way deprecated?

rerun.blueprint isn't available on a public release, it will be published in 0.15
If you feel very adventurous you can try the pre-release, but be warned they break frequently and might have other rough edges :)

ah yeah everything in the repository naturally uses the latest version. Go to https://github.com/rerun-io/rerun/tree/release-0.14.1 to get the examples in a 0.14 compatible state


Rename Html to Template in Component

We'll need to update the cli template as well for component and page.


Possible addition to the list

One suggestion from Reddit was to add in the rule that no off-topic discussion is allowed as part of the NCoC.
I'm opening this issue for discussion on this suggestion.
Arguments for:
Explicit disapproval from flame-baiting discussion and knowledge that any occurrence will be met with a ban or some kind of warning.
Being explicit is better than rules being shrouded in mystery and applied with caprice.
Arguments against:
The NCoC has no say in what can and cannot be said.  It would be out of the scope of the NCoC.
Not allowing for off-topic discussion harms a lot of possible sort-of-related and harmless discussion on topics within the scope of the project at hand.
Alternative:
Instead of making it one of the rules, offer the suggestion in the FAQ to state that no off-topic discussion is allowed.
Or, offer a venue for off-topic discussion and point "offenders" to the proper place when wanting to discuss such matters, and separate project-related discussion and unrelated discussion.
Your thoughts?

I am against this change.
I would be for this change if there was a way to objectively define it. Unfortunately, there is not. (Not that I know of, anyways. Although if someone could rephrase this in an objective manner I wouldn't have this objection.)
And given that there is no objective definition, it seems to me that this rule would just end up with communities and projects get stuck endlessly debating as to what exactly is and is not "off-topic discussion", i.e. how members should behave in their communities.
And the NCoC is "[d]esigned to help you find communities and projects that will not get stuck endlessly debating how members should behave in their communities" (emphasis added).
As such, this would go rather directly against the concept of NCoC.

:-1:
Echoing @TheLoneWolfling 's comment here, this introduces something that can't be objectively defined. Anything can be made part of your project if twisted and pushed hard enough.
Keep it technical, shut up and code. Nothing else matters.

There will be a need to define a explicit definition of a off-topic conversation medium, this is really not an okay change for me, so I call -1 on this. Unless you can define the entity for this, it would end up vague and questionable


get neoscopes selected scope

added a function to call the name of the current selected scope
it's tiny but useful for me, because it can show me the selected scope in my nvim-lualine.. i have config like this
-- sections
lualine_x = { "require'neoscopes'.get_current_scope()" },

Hi Steffen,
There is already a function get_current_scope, which returns the scope object :)
I also show the scope in lualine, but with a custom function:
local function scope()
  local s = scopes.get_current_scope()
  if not s then return "" end
  return "󰍉 " .. s.name
end

require("lualine").setup({
   ...
   lualine_z = {scope}
})

good, sorry didn't saw that ,lol

Closing then :)


HIVE-25535: Adding table property "NO_CLEANUP"

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

@deniskuzZ @mattmccline-microsoft @sankarh Could you guys please review the PR.


Fully support syclcc in CMake

I’ve been trying to make hipSYCL work with a more “complex” CMake setup than what is used for the tests, in particular, one that finds and links other libraries (standard CMake stuff, really). I did manage to get it working, however not without some changes.
Right now there's a couple of issues as far as I can tell:
The most pressing one is the in-source temporary files. CMake often uses try_compile for feature detection or to determine a library version. For example, the FindMPI module compiles a small program to see if a particular library it found actually works. The problem is that these files are often located somewhere in a read-only location (if it’s a system installation), so syclcc cannot write its temporaries and the find_package call simply fails (and the reason is not particularly well communicated by CMake).
Now within syclcc you remarked that temporaries are located in-source for more robust include resolution, however so far I’ve had no problems with out-of-source builds. Maybe this could be made configurable through a CLI parameter? In any case I think writing into the source tree is a bit hairy and should best be avoided, at least by default.
Another thing is compiler detection. The very first thing CMake does is to compile a small program (however this time within the local CMakeTmp folder) to try and determine the compiler version. Right now this identifies nvcc as gcc, since (afaik) that is the default host compiler of nvcc. I’m not sure what the implications of this are, i.e. if there is any difference in parameters that will be passed to syclcc, e.g. something gcc-specific, which could then maybe interfere with the Clang preprocessing passes. As an aside, and to alleviate this, it might be worth considering setting the host compiler of nvcc to Clang by default, which would fit better with the rest of the compilation stages anyway, as they are all LLVM-based.
In addition to these points, if /tmp is a tmpfs mount, compilation performance could also be greatly improved by moving all temporaries there.
Finally, something that might be worth investigating is to provide a CMake function like ComputeCpp's add_sycl_to_target, as provided by their SDK. I see several benefits to this:

First it would allow to only compile certain translation units with the device compiler. For larger projects this could really cut down on compilation times.
Secondly, this would improve compatibility with existing projects that work with ComputeCpp.
This could also make the specification of rewrite paths -- as proposed in #20 --  more convenient, as instead of adding a CLI parameter this could be done through an additional parameter for add_sycl_to_target.

Hello there
I'm currently giving hipSYCL a go myself and I'm quite interested in this. Is any of you working towards any sort of implementation of this? I could have a go at writing some very basic find scripts on top of which we could start building upon if not.

It's at the moment not one of my priorities, but I'd love to merge a pull request and see this working if you want to have a go at it :)

I'll see if I can get something usable started in the next couple of weeks or so. Just had a kind of fiddly time getting my first example to build so, it's prime time for these niggles to be fresh in the mind. One of them, though, is something I want to understand the reason why before I put it in the change (if there's any particular one):
syclcc tries to suss out your backend through the HIPSYCL_PLATFORM environment variable but it alternatively takes a parameter so you can specify. If you do pass something there, though, and it DOES find the variable (say if you added your default to your bash profile), syclcc just nopes out. Is there any particular reason why it doesn't treat the parameter as an override instead of just exiting? That's the behaviour I expect (and this ties in because one of the things would have to be specifying the backend through a cmake cache variable)

Originally, there was only the environment variable. Later, when I added the CPU backend and needed to easily specify which backend to compile for in the cmake file of libhipSYCL, the command line variable was added. At the time, since I didn't want to worry about what overrides what and how to document such behavior clearly, it was decided that only either one of those two ways of specifying the platform could be set.
If you say that it's counterintuitive or makes implementing proper cmake support harder, feel free to change this behavior. It has bitten me as well sometimes ;)

Back when I implemented Clang-CUDA support into sylcc I did a quick survey at my office about whether an environment variable should take precedence over a CLI parameter or the other way round -- turns out the opinions differ :). That being said, --cuda-clang-compiler currently takes precedence over HIPSYCL_CUDA_CLANG_COMPILER, which is in line with what you're suggesting. In any case we should be consistent!
As mentioned in the original post I actually have a working CMake setup for my local experiments right now, but it's still a bit of a mess and needs cleanup before it can be upstreamed (and I'm still busy with unit tests - I'll hopefully submit a PR on that tomorrow or so btw). Of course I won't discourage a first time contributor so maybe we can join forces on this one somehow! I however think CMake config files are the way to go over find modules nowadays.

@psalz I do agree that config modules are the way to go, just find writing more classic style modules easier to do by hand (but still providing actual targets). My initial plan was to look at findHIP.cmake and how they're managing the build from there to get a starting point. If you make a PR and/or link a fork, I can help you iterate on this for sure. As I've mentioned, I've got some stuff I want to work on before so I should start looking at this in more depth in say a week or two (still trying to get this working at all as part of a slightly less hello-wordly project to begin with).
My initial mindset behind the VAR vs parameter thing is twofold:
The VAR is probably going to be something you set through your bash profile setup and then forget for the most part
If we're bringing this into cmake, we want to be able to toggle this from CMake, so something a bit like:
set(HIPSYCL_PLATFORM $ENV{HIPSYCL_PLATFORM} CACHE STRING "The backend to use for hipSYCL")
set_property(CACHE HIPSYCL_PLATFORM STRINGS "cpu;hip;cuda;nvcc")
if(NOT HIPSYCL_PLATFORM)
  set(HIPSYCL_PLATFORM "cpu" CACHE STRING "The backend to use for hipSYCL")
endif()

Because then you'd pass the option into CMake as part of your parameters.

I guess we have proper cmake support now ;)


Unsupported version

Hi.
I'm really interested in your parser, because it allows to define each field length individually. I need to append new registers to an existing database. However, the parser gives me the following message: "AssertionError: File 'FILENAME.DBF' has unknown/unsupported dBase version: -11.".
Is it possible to make it work?
Thank you very much.

Hi @kalihos,
The code only supports limited versions as you've discovered (the ones we needed for our work). I don't have time to work on this, but the code is not very complex, so if anyone wants to take a look at supporting more versions, a PR would be very welcome.

Hi @yortus,
Thank you very much. I could finally use a combination of two connectors (one for reading, one for writing in a new DBF), and it gave me no problems, so I close this.
Thanks again.


Display deprecated as a true/false string

Display deprecated as true/false or N/A. This is needed for https://github.com/ManageIQ/manageiq-ui-classic/pull/4509
Links [Optional]
https://bugzilla.redhat.com/show_bug.cgi?id=1610927
ManageIQ/manageiq#17884 & ManageIQ/manageiq#18217
https://github.com/ManageIQ/manageiq-ui-classic/pull/4509
ping @himdel @martinpovolny

@miq-bot add_label bug, blocker, hammer/yes
Fixes https://github.com/ManageIQ/manageiq-ui-classic/pull/4509#issuecomment-442452820


Azure Cloud

Hi
Thanks for putting this together.
Any plans to put together a similar solution using Azure cloud
Thanks

Hi @ravitola!
We are hearing that an Azure version would be of interest to people...we're still gathering feedback and if we do decide to Azure-ify this, we will let you know.


Fix field filtering and default values

Restores capability removed in https://github.com/UKHomeOfficeForms/hof-behaviour-summary-page/pull/4 for a default value to be used in place of undefined or empty values.
Also fixes functionality claimed to be added by that PR of not filtering zero-valued fields, which was broken due to the secondary pure-Boolean filter that was applied after the initial filter.
Now fields are only removed if they have a falsy, non-zero value and no default value is supplied.

Is this to fix the scenario where we have dependent and child fields and we would get some wacky things happening unless we add this https://github.com/UKHomeOffice/right-to-rent-check/blob/master/apps/right-to-rent-check/behaviours/filter-fields.js

Not really. It's to allow optional fields that were not filled out to be displayed on the summary page with a default message.
As it stands, it's impossible to have a field without a value show on the summary page.

Ok then it looks good to me


Unify cleanup source code to use stages storage through interface

Werf cleaning package should perform stages storage operations using storage.StagesStorage interface, which should be extended with appropriate operations.

outdated


Add Auto Daed for the slayer

there is a small problem when the boss has less life than the number that we put in the game crashes I think you would be how to get around this?

stop skidding


Not working Node-RED after install

I have installed this (node-red-contrib-norelite 2.6.1) but my dashboard is not working anymore.
Even the example doesn't want to work.

Did I miss something here?

What does the log say?

Closed as no feedback


Doesn't work on Secret Ninja Training School page

Like the title says, it doesn't seem to work on the Secret Ninja Training School page. It doesn't show up on the list of scripts so maybe something is missing for that page? I included a screenshot of what it looks looks like on the Secret Ninja page vs Island training page.
Love this script! I train multiple pets so this will make things much easier :D

Thanks for the comment!  It's true; I haven't been able to personally test this.  I can say that I made a typo when enabling it for Secret Ninja (And as I said, I can't test it myself yet x.x)
The correct link should be:
// @match        https://www.neopets.com/island/fight_training.phtml?type=status*
Instead of what I had before
// @match        https://www.neopets.com/island/fight_training.phtml?status*
You can probably patch this out yourself for now, but I will be pushing a fix soonish when I have a few more updates bundled!

That change worked! Thanks! :D


Ingest 50% of bionetworks datasets required for first 3 atlas integration efforts

We are at 35/56 for the first 3.  Target met.


Trouble compiling

Describe your bug here.
every time i try to build psych engine, it shows this error, i tried deleting the export folder many times and it didn't work. any help?
Command Prompt/Terminal logs (if existing)
Link: ApplicationMain.exe
   Creating library ApplicationMain.lib and object ApplicationMain.exp

Failed to update resources

Are you modding a build from source or with Lua?
Source
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
yes, i changed the project.xml, i removed the psych engine credits thing

ok, first things first, this is typically a non fatal issue, and entirely a not related to psych engine.
second does it not open the game when this error occurs?


Run pipeline with consolidated build scripts

What this PR does / why we need it?:

Does this PR introduce a user-facing change?

[ ] User guide
[ ] CHANGELOG.md

Which issue(s) this PR fixes:

Fixes #

Successful run: https://cloud.ibm.com/devops/pipelines/tekton/729b3aea-0a81-4b4d-bd42-7e5811980010/runs/bfb8cdfc-1e3a-430b-9f43-12afced16a49/deploy-acceptance-tests/run-stage?env_id=ibm:yp:us-south


Typescript: Type 'null' is not assignable to type 'PropValidator'

Version
2.5.16
Reproduction link
Vue.component('union-prop', {
  props: {
    anything: null,
    primitive: [String, Number],
    object: [Cat, User],
    regex: RegExp,
    mixed: [RegExp, Array],
    union: [User, Number] as {new(): User | Number}[] // requires annotation
  },
  data() {
    this.anything;
    this.primitive;
    this.object;
    this.union;
    this.regex.compile;
    this.mixed;
    return {
      fixedSize: this.union,
    }
  }
});

Steps to reproduce
Paste it into options-test.ts and run yarn test:types
What is expected?
No errors, type should be any
What is actually happening?

Type 'null' is not assignable to type 'PropValidator'

It works with strictNullChecks disabled, but the type is {} instead of any

Why would you even put null as a type or to say a prop can be anything (which can be done with a custom validator that always returns true)?

From https://vuejs.org/v2/guide/components-props.html#Prop-Validation

// Basic type check (null matches any type)

I've also seen it mentioned by you guys in quite a few issues on here too, and it seems to work just fine in regular JS.

This is impossible to do in current typing schema. You have to cast it manually.
anything: (null as any) as PropValidator<any>
We might change this in further version. We can exploit TS2.8's conditional type to model prop type. However, this might be a breaking change.

I personally prefer to rewrite typing schema with Vue 3.0. As said above, typing null as validator is impossible for current type files.

Why would this be a breaking change? Vue 2.5 required a specific version of typescript and wasn't considered breaking.


Added namespace in build.gradle

Applies to Android Only
Added namespace in module's build.gradle file to avoid "Namespace not specified. Specify a namespace in the module's build file." error. New version of Gradle requires namespace to be specified in build.gradle file.
Below is the error I was getting. But after adding namespace manually in package's build.gradle file, it fixed the issue.

Thanks!

You're Welcome! I spent half of my day finding the fix for this issue. 😅
Similar issue is there in google_mobile_ads plugin and I have also opened the pull request there. I hope they update it soon.


Template Updates: Beauty

Description
Bolded text are updates from April 6, 2021: https://docs.google.com/spreadsheets/d/1MFtHj7Xwdol9jSk80PXrxWNz_0h1tSfyEe3K7Bn2yZs/edit#gid=0

Page
Animations
Cosmetics

1
Fresh & Bright headline animation updated from custom "Bounce" to editor's "Pulse"; Remove animation on pink shape. Anonymous by line to fly in
Remove grid shape from background; Remove secondary white layer from headline; update type color to: #28292B

2
Remove animations on heart shapes; Update Text animation from custom "Bounce" to editor's "Pulse".
Combine heart shape (done); Remove second layer for type; change type color to #28292B

3
Need to know what "3" animation update is called; Remove animation on sage shape; change the custom animation on text to Fade In (3000ms); Headline and Image to fade in 3000ms
N/ A

4
Change little hearts custom "bounce" to "pulse".  Remove background animation.
Remove second layer for type. Increase little heart radius for more tappable space (60x60).

5
Update custom "bounce" on headline  to "pulse". Image to Fly in
Remove grid shape; remove stars; make image larger; update color to #28292B.

6
Update number headline from custom bounce to editor's pulse; text area animation update to fade in. Remove animation on pink shape and link area and buy now. Headline and Image to fade in 3000ms
Remove grid shape; remove second layer for type; change type color to #28292B.

7
Update custom bounce to editor's pulse; remove animations on buy now, background shapes, links.  Both images to Fly in
Remove grid shape; remove star

8
Update headline. and image from. custom bounce to editor's pulse; Update text to fade in; remove animation on get the look. Background shape behind image to fade in 3000ms
Remove text frame shape; portrait changed

9
Update headline custom bounce to editor's pulse; Update images to fade in; remove animations on all shapes and subheading text.
remove second layer for type. images updated.

See Figma for specifications: https://www.figma.com/file/NHHMwIfxMnz39NxqkrFb7R/Stories-Post-Stable?node-id=7216%3A549493
If design requests have updated please make note in a comment here so that testing is aware of updated specs.
Acceptance

Template is updated
Relevant stickers are created
No more custom animations

Verified in QA

These were bug bashed by design so i feel like we can close them.


Add Currency Converter

Type of change

[x] Added new project
[ ] Bug fix
[ ] New features
[ ] Enhanced documentation

Changes proposed in this pull request

Project name :

Currency Converter

Short description :

A Python application with a Tkinter GUI that allows users to convert currency with real-time exchange rates using the forex-python library.

Checklist

[x] The code is Python 3 compatible
[x] I have added relevant comments in my file to make code understandable
[x] I have added my project in a folder which includes all the necessary files

@IamSoo Can you please review this PR?


markup/asciidoc: Add support for .TableOfContents

Fill the .TableOfContents template variable when writing Asciidoc content.
This is done by letting Asciidoc render its TOC as HTML, then extract this
HTML rendered TOC, parse it into a tableofcontents.Root and finally remove
it from the HTML content.
This aims to stay in the logic that the Asciidoc parsing is entirely done
by the external helper.
See #1687

@rustysys-dev Thanks for your review. I've just fixed the conflicts in go.sum.

@bep I apologize if mentioning you on this PR discouraged (please let me know if it is)
That being said, I wanted to bring the Hugo teams attention to this PR as it fixes a feature that is broken for asciidoc, and is important for my team and I.
I checked the code, and the logic follows through, is formatted correctly, has tests and documentation.  If you have some time to approve/merge/comment, we would all appreciate it.

Not stale. @rustysys-dev any way to move this fix along aside from @npiganeau rebasing?

@forestsword As you said, aside from @npiganeau re-basing we cannot do anything with this unless someone who has merge permissions decides to take a look at this.  Once the re-basing is complete then we can try to get the attention of someone in charge again.

It wasn't fixed. That file was just moved to the new markdown/asciidocext. @npiganeau are you still interested in this, I can do a rebase with your code if you'd like and open a new PR.

If this looks good to the Asciidoc users in here, I'll happilly merge (once rebased).

Rebase is done

@muenchhausen

LGTM working as expected.

@muenchhausen

I will try it out in the weekend.

I was successfully able to run your changes.
Do you have a sample repo with an adoc file and a theme that uses .TableOfContents? I would like to see it.
We can also extend my sample repo hugo_asciidoc_ddd.
I found a small issue: Please correct your documentation and add empty lines between the headers. There is also a missing blank between :toclevels: and 4. Otherwise AsciiDoc won't be rendered correctly.

Documentation is corrected.
See https://github.com/muenchhausen/hugo_asciidoc_ddd/pull/2 for a sample with TOC extraction to .TableOfContent.

@npiganeau your changes work fine, thanks a lot! @bep I propose to merge.


Dimmer light switches listed as Light Modulator in iot.tuya.com are not displayed in HA

Hi, not sure what more to provide since the device is not shown in HA. I have several devices from this type, none is available in HA. Devices are visible in iot Tyua (see scr shot)
Device normal info

MoesHome
Model https://www.aliexpress.com/item/33010332202.html

@cocacoli4ko Can you provide your device specifications?

@tsutsuku I'm not sure how to get the specifications... Can I get this from the Tuya app or in the cloud? What exactly is needed - hardware inside or software version? I can try to ask the manufacturer too

@cocacoli4ko take a look at the issue template – https://github.com/tuya/tuya-home-assistant/blob/master/.github/ISSUE_TEMPLATE/bug_report.md, it has all the details on how to get the required info.

@andrey-yantsen Here's the data from the log:
device info
{
"active_time":<PHONE_NUMBER>,
"biz_type": 0,
"category": "tgq",
"create_time":<PHONE_NUMBER>,
"icon": "smart/icon/ay15327721968035jwx9/158754167737006edd612.jpg",
"id": "67146444c44f33b77b02",
"ip": "<IP_ADDRESS>",
"lat": "42.6824084",
"local_key": "ce0794d98ff9930f",
"lon": "23.2681686",
"model": "1路调光模块 1051路调光",
"name": "Лява",
"online": true,
"owner_id": "10662434",
"product_id": "uwajjpe6u24lmjqf",
"product_name": "Dimmer",
"status": [
{
"code": "switch_led_1",
"value": false
},
{
"code": "bright_value_1",
"value": 510
},
{
"code": "brightness_min_1",
"value": 10
},
{
"code": "led_type_1",
"value": "LED"
}
],
"sub": false,
"time_zone": "+02:00",
"uid": "eu1582446281837qkSql",
"update_time":<PHONE_NUMBER>,
"uuid": "67146444c44f33b77b02"
}
Device specifications
2021-09-09 10:13:43 DEBUG (Thread-4) [tuya iot] Request: method = POST, url = https://openapi.tuyaeu.com/v1.0/iot-03/open-hub/access-config, params = None, body = {'uid': 'eu1582446281837qkSql', 'link_id': 'tuya-iot-app-sdk-python.769577fe-113d-11ec-963e-b827eb4c0b7b', 'link_type': 'mqtt', 'topics': 'device', 'msg_encrypted_version': '1.0'}, headers = {'client_id': 'a3d8nrc4aqqf3kmfvqr3', 'sign': 'A6AEA914931C62DF50361FFFE1A3A390B293339C79486E741B9BC105FD620ACD', 'sign_method': 'HMAC-SHA256', 'access_token': '9a092c960288d3e97f84466252a32dc2', 't': '1631171623445', 'lang': 'en'}
2021-09-09 10:13:43 DEBUG (SyncWorker_2) [tuya iot] Request: method = GET, url = https://openapi.tuyaeu.com/v1.0/users/eu1582446281837qkSql/devices, params = None, body = None, headers = {'client_id': 'a3d8nrc4aqqf3kmfvqr3', 'sign': '46F2CE85E89AC10447151C8ECCC742ACD37D240257A0532CF3FE10EC04191388', 'sign_method': 'HMAC-SHA256', 'access_token': '9a092c960288d3e97f84466252a32dc2', 't': '1631171623448', 'lang': 'en'}
2021-09-09 10:13:43 DEBUG (Thread-4) [tuya iot] Response: {
"result": {
"client_id": "cloud_dd1b3e0ea44d82e0a0d432dc3d325527",
"expire_time": 7200,
"password": "2fe505eb1a42f0e6de3af5a3d2b29620",
"sink_topic": {
"device": "cloud/token/out/{device_id}"
},
"source_topic": {
"device": "cloud/token/in/e17d84a807f65f3aafb48514f8d01790"
},
"url": "ssl://m1.tuyaeu.com:8883",
"username": "cloud_e17d84a807f65f3aafb48514f8d01790"
},
"success": true,
"t":<PHONE_NUMBER>594
}

@andrey-yantsen Actually I'm confident about the device info, but I'm not sure if the Device specifications is matching it, could you tell me what should match between both? I have a lot of devices connected...


Error backing up: sqlite3.OperationalError: unable to open database file

Hello,
Short
I am facing a sqlite3.OperationalError: unable to open database file error when running:
$ docker exec -u "${PUID}:${PGID}" -it linkding python manage.py backup backup.sqlite3

I have followed  the official guide. I thought it was permissions problem but does not seem to be the case. See below the longer response.
Longer
I have a local environment where I am testing a backup solution using docker-compose.yml:
  linkding:
    image: sissbruecker/linkding:latest
    container_name: linkding
    hostname: linkding
    user: "${PUID}:${PGID}"
    environment:
      LD_SUPERUSER_NAME: bphenriques
    volumes:
      - "/tmp/home-server/linkding:/etc/linkding/data"
    restart: unless-stopped
    env_file:
      - secrets.env.example
    ports:
      - "3005:9090"

And I created the script that boils down to docker exec -u "${PUID}:${PGID}" -it linkding python manage.py backup backup.sqlite3. PUID and PGID prints to 1000 and 100, respectively.
Leading to:
Traceback (most recent call last):
  File "/etc/linkding/manage.py", line 21, in <module>
    main()
  File "/etc/linkding/manage.py", line 17, in main
    execute_from_command_line(sys.argv)
  File "/opt/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
    utility.execute()
  File "/opt/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/venv/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/opt/venv/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute
    output = self.hanthe user and group matches the db.sqlite3dle(*args, **options)
  File "/etc/linkding/bookmarks/management/commands/backup.py", line 20, in handle
    backup_db = sqlite3.connect(destination)
sqlite3.OperationalError: unable to open database file

My first impressions were permissions issues, but then I added the -u flag to be consistent with the docker-compose.yml file with no success. I then entered the container and checked permissions and it seems fine:
On the container:
$ python manage.py backup output.sqlite3
Traceback (most recent call last):
  File "/etc/linkding/manage.py", line 21, in <module>
    main()
  File "/etc/linkding/manage.py", line 17, in main
    execute_from_command_line(sys.argv)
  File "/opt/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
    utility.execute()
  File "/opt/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/venv/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/opt/venv/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute
    output = self.handle(*args, **options)
  File "/etc/linkding/bookmarks/management/commands/backup.py", line 20, in handle
    backup_db = sqlite3.connect(destination)
sqlite3.OperationalError: unable to open database file
$ ls -la /etc/linkding/data
total 392
drwxr-xr-x 3 1000 users   4096 Feb  8 12:49 .
drwxrwxr-x 1 root root    4096 Feb  8 12:49 ..
-rw-r--r-- 1 1000 users 303104 Jan 27 08:24 db.sqlite3         # Note: seems readable
-rw-r--r-- 1 1000 users  32768 Feb  8 12:49 db.sqlite3-shm
-rw-r--r-- 1 1000 users  45352 Feb  8 12:49 db.sqlite3-wal
drwxr-xr-x 2 1000 users   4096 Jan 27 08:24 favicons
$ id
uid=1000 gid=100(users) groups=100(users)                    # Note: the user and group matches the db.sqlite3

On my host:
$ ls -la /tmp/home-server/linkding/
total 392
drwxr-xr-x  3 bphenriques users   4096 Feb  8 12:49 .
drwxr-xr-x 20 bphenriques users   4096 Feb  4 18:08 ..
-rw-r--r--  1 bphenriques users 303104 Jan 27 08:24 db.sqlite3
-rw-r--r--  1 bphenriques users  32768 Feb  8 12:49 db.sqlite3-shm
-rw-r--r--  1 bphenriques users  45352 Feb  8 12:49 db.sqlite3-wal
drwxr-xr-x  2 bphenriques users   4096 Jan 27 08:24 favicons
$ id bphenriques
uid=1000(bphenriques) gid=100(users) groups=100(users),1(wheel),57(networkmanager),131(docker)   # Note: matches the ids inside the container

Thank you :bow:
Edit: for this local test environment I added a single bookmark so there is something in the db.

Ok, noticed taht the stacktrace points to line 20: https://github.com/sissbruecker/linkding/blob/master/bookmarks/management/commands/backup.py#L20
Perhaps the error occurs because there is no file which is expected as we are in the process of creating a new one.

Found the error, The /etc/linkding folder is always owned by the root inside the container. However, for users that are not running the docker as root, we should actually have permissions to the /etc/linkding/data as part of the volume mounting process.
Having that said the following commands are now working:
$  docker exec -u "${PUID}:${PGID}" -it linkding python manage.py backup /etc/linkding/data/backup.sqlite3
Copied 50 of 74 pages...
Copied 74 of 74 pages...
Backup created at /etc/linkding/data/backup.sqlite3
$  docker cp linkding:/etc/linkding/data/backup.sqlite3 "${target_dir}/linkding/backup.sqlite3"
                                               Successfully copied 305kB to /tmp/tmp.uBybe7ECaH.restic-backup/linkding/backup.sqlite3

Suggestion: add a note to the documentation for users running docker without root


test-branch/execute-job/quoted-authorization/8ef93dc4-99da-4816-b7af-c6e621d5f33e

PR for testing 534492619ea4698c9c3024f8e33124b47800f064

/canonical/self-hosted-runners/run-workflows 534492619ea4698c9c3024f8e33124b47800f064


Steam store page translation

Translation of the Steam store page short and full description.
(this comment will be updated if more changes will be made before this pull request's merge/closing)

Thank you very much for the store translation!


Question: Possible to Save Current Time When Using Template to Create Note

Hi, any advise on how to set the current date & time when I create the note using template? Currently, the template has "created" field in frontmatter which store the created date & time of the template file. Hence, when I create note using template, the note created with the template's created date & time instead of current date & time. Example as below.
Template Note A - "created" field save as 01-Mar-2024 09:00
New Note Name B (created based on Template Note A) - "created" field save as 01-Mar-2024 09:00 (the same as Template Note A). How to make it that New Note Name B store current date & time in "created" field?

Hey @kennygokh , this sounds like an odd scenario. Have you ignored the folders that include your templates?

Hi Peter,
Thanks for you advice. I have tried ignore Templates folder and it looks like working now.
Regards.
Kenny Go
On 4 Apr 2024 at 20:01 +0800, Peter Kaufman @.***>, wrote:

Hey @kennygokh , this sounds like an odd scenario. Have you ignored the folders that include your templates?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

I am going to close this as it seems to already have been addressed by ignoring folders.


bundler does Ruby string interpolation on Gemfile leading to arbitrary Ruby code execution

This is a bit strange
$ cd $(mktemp -d)
$ echo 'gem="#{`cowsay bundler stahp >&2`}"' > Gemfile
$ bundle install
 _______________
< bundler stahp >
 ---------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
The Gemfile specifies no dependencies
Resolving dependencies...
Bundle complete! 0 Gemfile dependencies, 1 gem now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.

 I'm fully expecting to hear "yes, it is expected behaviour" and "there are so many ways a malicious Gemfile can hurt you, this is not strange or dangerous"

At least to the extent that it is expected that instance_eval-ing the contents of the Gemfile leaves a pretty open door, yes: https://github.com/bundler/bundler/blob/master/lib/bundler/dsl.rb#L40-L41 :)
Given the history here and, as you say, installing gems which can invoke native build scripts and post-install fu are pretty fraught with general peril, I doubt it'd be worth the trouble to be more selective in how the contents of the Gemfile are processed.
But, I also suppose one could argue that instance_eval is an overly-convenient way to go about things here.

Ah. Right. Gemfiles are basically entirely executed as Ruby. I thought I was being clever in using string interpolation.
% echo '`cowsay oh I see now >&2`' > Gemfile
% bundle install
 ______________
< oh I see now >
 --------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
The Gemfile specifies no dependencies
Bundle complete! 0 Gemfile dependencies, 1 gem now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.

For the record, we have definitely talked about creating a Gemfile parser/interpreter in the future that does not use instance_eval. The catch is that if we do that, many people/companies will no longer be able to do unusual or sketchy things in their Gemfiles—that's good, in that there's less sketchy stuff happening, but that's bad in that then those people will want us to fix their problem a different way. Right now instance_eval is the sweet spot for giving people flexibility while keeping most people on the same page.


update link on main

Is this needed? Does the README.md affect the tket website?

Yes you are right, we don't need that


Speed up GDScript::get_must_clear_dependencies()

get_must_clear_dependencies() has a N^3log(N) time complexity, and this can very quickly slow down the quitting process as more gdscripts are added in a project. This change improves it to N^2log(N).
Instead of using all the inverted dependencies, we do the same with all (non-inverted) dependencies, which is N times faster.
Fixes #85435

For the record, your commit seems not to be linked to your GitHub account. See: Why are my commits linked to the wrong user? for more info.

get_must_clear_dependencies() has a N^3_log(N) time complexity, and this can very quickly slow down the quitting process as more gdscripts are added in a project. This change improves it to N^2_log(N).

This is an improvement indeed but I think GDScriptLanguage::finish() shouldn't lead to any checks for dependencies like that? :thinking: On finalization all scripts are to-be-cleared anyway, so there's no point to check/clear the full chain of dependencies for every script. Iterating over every script and clearing only its own refs to any other script should be sufficient to get rid of all cross dependencies. Meaning the finalization should be doable linearly (O(N)).
Note that I'm not really familiar with the GDScript internals so maybe I'm missing something and it's not that simple?
Anyway, could potentially be done in another PR, this is already an improvement.

But this isn't about GDScriptLanguage::finish(), isn't it?

It is and it isn't, depends how you look at it. :upside_down_face:
#85435 which this PR aims to fix is specifically about slow quiting (both editor/runtime) when there are many cross referencing/dependant scripts. This is caused by the slow execution of GDScriptLanguage::finish(). And why is GDScriptLanguage::finish() so slow? Because it's calling GDScript:clear() many times and GDScript::clear() is slow with the current implementation.
So this PR makes GDScript:clear() faster which is good on its own, regardless of what calls GDScript::clear(). :+1: This of course makes also GDScriptLanguage::finish() faster as a result, which improves the quitting time.
What I've said in https://github.com/godotengine/godot/pull/85603#issuecomment-1836988340 is that GDScriptLanguage::finish() can potentially be made faster as it shouldn't need to call GDScript:clear() in its current form at all, because on finalizing all scripts clearing non-direct script dependencies shouldn't be needed (and that's what's done as a part of GDScript:clear()). Clearing only direct dependencies for all scripts would also result in no cross dependencies in the end and would be faster.
TLDR: this PR is good on its own but GDScriptLanguage::finish() could still be made faster.

BTW Yeah, would be nice if some benchmark times would be provided for before/after. In the end even if it helps with #85435 (it does) it still might need be considered as not fixing it if the timings are still not satisfying.

Can confirm that with The Mirror we see a hugely expensive shutdown time because of this function.
Benchmarked using superluminal profiler and it showed this function was consuming 100% CPU for over 90 seconds during shutdown.
I'll test this fix and report back the app close time :)

4 seconds to close the editor (previously multiple minutes)
4 seconds to close the app (previously 2 minutes or more)
This makes it much more deterministic for me.
Tested on windows.

Thanks! And congratulations on your first merged Godot contribution! That's a very cool way to enter the space 🙂

Thanks! Glad to help 🙂

@eldidou Don't hesitate to join our developer's chat. We have a GDScript public meeting tomorrow.

Cherry-picked for 4.2.2.

Seeing as how this slowdown still remains a problem when you go into the hundreds of scripts, I've gone ahead and made the change that was talked about earlier in this thread, by simply skipping the must_clear_dependencies work altogether. You'll find the change in #94505.
It seemed like a straight-forward enough of a change, and passes all the unit tests and whatnot, but I'd appreciate some more eyes on it.


Update output description

Having Amazon Resource Name (ARN) in the description made me think it was a properly formatted arn instead of just the name.
Maybe changing the description text might make it clearer?

Fixes https://github.com/HENNGE/terraform-aws-ecs/issues/6

@stupoid Can you also update https://github.com/HENNGE/terraform-aws-ecs/blob/master/modules/core/service/README.md#outputs ? 🙏

can you sync the fork to let gh actions run? thanks


Update functions-reference-python.md

Add details about ApplicationInsights connectionstring config.

@ramthi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

@ktoliver can this be merged?

@ramthi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@ramthi I can sign off after you accept my update.

@ggailey777 this fell off my radar.  Just accepted your suggestion..can you pl. merge?

Thanks @ramthi #sign-off

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Broken Schema types

Using typescript 4.4.2, use-tweaks 0.3.1, and tweakpane 3.1.0:

Return type for useTweaks is {}, regardless of whether I pass in a type for the Schema generic or not. Am I missing something?

I tried upgrading use-tweaks to v0.3.2-alpha.0 and the issue seems to have been addressed


Add support to edit text in current text field of front most window

I often find my myself editing text in web forms (just like this one) and happen to spot a typo. Currently this requires the following steps:

CMD + A
CMD + C
CMD + Space, "replace s/…/…"
CMD + V

I wonder if there's a way to eliminate steps 1, 2 and 4? Ideally I'd just type text, trigger the workflow and just issue the replacement command rather than interacting with the clipboard myself, especially as the current way of working sort of pollutes the clipboard history without need.
Thanks for the great workflow! 🙃

I'm not sure how possible this is since we work just on the clipboard. Although I'd love to know if you have any ideas.
My suggestion is using a vim plugin for your browser. There are ones just for textareas and some for the whole browser. I believe these allow inline replacements.