Make the Necromancer's Staff

No, we won't make an own Issue for every weapon, but I'm not sure how to do this particular one, so here's a chance to make decisions. ;)
So, how should the Necromancer's Staff work?
My idea is to touch (punch) an undead creature and basically replace its AI with that of a dog, so it follows you around and attacks whatever attacks you (and/or what you attack). Any other ideas?
What should the crafting recipe be? Should there be different versions?
Should it only work on zombies? Or also skeletons?
How many undead should one staff control?
Should it be safe to use or could the undead break your control?

Well I sort of based it on the necromancer's abilities from Diablo II where you were able to revive the enemies you killed into a skeleton minion or summon a living clay golem from the ground.
They would work just like a dog where they would follow you around and attack any enemies in sight.
I'm not sure reviving corpses would be a good idea so having it able to sort of tame the undead would probably work best.

"Should it only work on zombies? Or also skeletons?"
"Should there be different versions?"
I have an idea to make different versions for every type of undead creature. Its appearance should differ a bit, the simplest way is to change some colors. Zombie staff should be cheaper/easier to obtain   than skeleton staff, etc. Recipe should also contain a part of desired creature (example: rotten flesh for zombie staff).
This weapon must be balanced somehow (I suggest weak durability and charge mechanic [you have to click and hold mouse button on enemy for few seconds)].

"for every type of undead creature":
Well, if we will start working on the unbelievable "Integration update", we will have to include new ones for every mob other mods add. I think, that it would be better, if we do this in groups, like 1 for undead creatures, 1 for players (I think we can make a separate one for them), 1 for animals etc.
This would keep the mod as small as possible :3

"Well, if we will start working on the unbelievable "Integration update", we will have to include new ones for every mob other mods add. I think, that it would be better, if we do this in groups, like 1 for undead creatures, 1 for players (I think we can make a separate one for them), 1 for animals etc."
I'm totally for not doing that. :P
I mean, some animals are already tamable and "taming" players would be horrible.
I think it might work best if there are, like three versions and zombies are available at tier one and tier two or three enables using it on skeletons or something.
And instead of hardcoding it, we could just have a registration method to allow certain creatures for the staff. In case anyone wants his modded undead creatures to be mindbroken. ;)

After sending this, I came up with another idea. We could just use a point system.
For example:
Zombies cost 5 points.
Skeletons cost 15 points.
Raising a zombie from a players corpse could cost 25 points, but gives you a minion with all the armour the player dropped on death. (just a quick idea)
So, let's say the tier 1 staff gets 20 points.
That would let you control up to 4 zombies or 1 skeleton and one zombie.
Any attempt to use it for more could give some "nice" feedback from the staff. I think some seconds of wither effect would be fitting here?

How about adding staff for creatures living in the Nether (zombie pigmans and wither skeletons)?

@CorruptedSlime: I hadn't really thought about that...put it would not be that much of an issue with the point system. I'll just have to find out how strong wither skeletons are, since I've never thought against them that much.^^
So...the basic AI is done, but I'm not sure if I should leave it at that. It's quite passive and maybe the necromancer should have to actually use the staff to call his minions and make them attack? I'll make a poll in the forum...

Finally had the time to make some progress on this...imagine how cool it would be with a texture. hint, hint

I don't think need that here anymore ^^


Comment all code

static/js/

[ ] app.js

static/css

[ ] pomf.css

php/

[x] upload.php
[ ] grill.php
classes/

[ ] Response.class.php
[ ] UploadException.class.php
[x] UploadedFile.class.php

moe/

[ ] index.php
panel/

[ ] index.php
[ ] search.php

includes/

[ ] api.php
[ ] core.php
[ ] settings.inc.php

You should edit the issue description to have a list of checkboxes for all files containing code in need of comments, so we can visually see what we need to work on.
Maybe something like:

dir

[x] blah.css
[ ] blah2.js

dir2

[x] blah3.php

Waiting PR, no work needed

app.js commented in 7c4688a9b21e5d18e4ad34111c168755013a3a7a


Remove extensionType variables

I'm refactoring the CLI code and I noticed we are passing the type as a variable to generate the functions code from the liquid files, but it's actually not needed, as every function only allows one value.
Also, some functions like cart-transform are already hard-coded: https://github.com/Shopify/function-examples/blob/4b19a27376926ccd5fcea7d8537ebe6c2c497682/checkout/wasm/cart-transform/default/shopify.function.extension.toml.liquid#L2
So I'm hard-coding all the values, which will simplify the CLI code and the Partners API with the function specifications.

@dphm it should be fine because like @gonzaloriestra said, each function is written for a specific API type so there's no reason not to hard-code it:

it's actually not needed, as every function only allows one value


Vet clinic database: database performance audit

-- Add an email column to your owners table
ALTER TABLE owners ADD COLUMN email VARCHAR(120);

-- This will add 3.594.280 visits considering you have 10 animals, 4 vets, and it will use around ~87.000 timestamps (~4min approx.)
INSERT INTO visits (animal, vet_id, visit_date) SELECT * FROM (SELECT id FROM animals) animal_ids, (SELECT id FROM vets) vets_ids, generate_series('1980-01-01'::timestamp, '2021-01-01', '4 hours') visit_timestamp;

-- This will add 2.500.000 owners with full_name = 'Owner ' and email =<EMAIL_ADDRESS>(~2min approx.)
INSERT INTO owners (full_name, email)
SELECT 'Owner ' || generate_series(1, 2500000), 'owner_' || generate_series(1, 2500000) ||<EMAIL_ADDRESS>ON CONFLICT DO NOTHING;

After repeating 6 times, got >=1000ms:

Confirm execution times:
SELECT COUNT(*) FROM visits where animal_id = 4;

SELECT * FROM visits where vet_id = 2;

SELECT * FROM owners where email =<EMAIL_ADDRESS>
EXPLAIN ANALYSIS:

After INDEXING solution:

Thank you for the approval @Reem-lab


Is it possible to add the speed property on the return?

It would be really nice if this library really supports speed.

are we gettting speed in result ? I could not get it .


[ext_proc] Ext proc half close on destroy and defer reset till trailers received.

Commit Message: [ext_proc] Ext proc half close on destroy and defer reset till trailers received.
Additional Description: In Grpc, the trailers carries the grpc-status header terminates a rpc stream. Our current flow ignores the trailers by closeStream and resetStream all together, the later resetStream call would signal the remote server a CANCEL, while clean the sidestream and ignore any possible trailers that might have been sent by ext_proc server.
This PR would defer the cleanup of the side stream till a trailers been received, or till a cleanup timer fires.
Risk Level: medium
Testing: unit tests
Docs Changes:
Release Notes:
Platform Specific Features:

/retest

yeah, it's a patch from the internal CL.


prefer reporting problems to bugtracker / website before maintainer

If a package has a bugtracker / website url refer the user to those in case of problems. If neither of these URLs is specified in the manifest continue to reference the maintainers directly.
This might be useful across all active ROS distros. So considering it for backporting to indigo-devel.
@ros/ros_team Please review.

This looks great! thanks for the quick fix.


PSSecurityException with Powershell on Windows 10

When the default powershell profile e.g. C:\Users\Michael\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 contains some scripts, starting the powershell with terminal-plus raises a PSSecurityException.
The powershell in terminal-plus seems to run with another execution policy: Get-ExecutionPolicy in terminal-plus is Restricted, whereas the global powershell execution policy has been set with Set-ExecutionPolicy RemoteSigned -Scope LocalMachine.

The launching of powershell is handled by one of my dependencies called winpty. I will have to check with that developer about this.


+oneWthPerHost not implemented in standalone builds

Original issue: https://charm.cs.illinois.edu/redmine/issues/1790

$ ./charmrun ./jacobi 2 2 2 40 +vp8 +balancer RotateLB +LBDebug 1 +oneWthPerHost
Running command: ./jacobi 2 2 2 40 +vp8 +balancer RotateLB +LBDebug 1 +oneWthPerHost

Charm++> No provisioning arguments specified. Running with a single PE.
         Use +auto-provision to fully subscribe resources or +p1 to silence this message.
Charm++: standalone mode (not using charmrun)
Charm++> Running in Multicore mode:  1 threads
Converse/Charm++ Commit ID: v6.8.0-423-g3aa5cfe08
CharmLB> Verbose level 1, load balancing period: 0.5 seconds
CharmLB> Load balancer assumes all CPUs are same.
Charm++> Running on 1 unique compute nodes (8-way SMP).
Charm++> cpu topology info is gathered in 0.001 seconds.
WARNING: +oneWthPerHost is a command line argument beginning with a '+' but was not parsed by the RTS.
If any of the above arguments were intended for the RTS you may need to recompile Charm++ with different options.
[0] RotateLB created
iter 1 time: 0.100631 maxerr: 2020.200000
iter 2 time: 0.102280 maxerr: 1696.968000
iter 3 time: 0.098243 maxerr: 1477.170240
iter 4 time: 0.098893 maxerr: 1319.433024
iter 5 time: 0.101593 maxerr: 1200.918072
iter 6 time: 0.101801 maxerr: 1108.425519
iter 7 time: 0.105620 maxerr: 1033.970839
iter 8 time: 0.107805 maxerr: 972.509242
iter 9 time: 0.109841 maxerr: 920.721889
iter 10 time: 0.107849 maxerr: 876.344030
iter 11 time: 0.106372 maxerr: 837.779089
iter 12 time: 0.110128 maxerr: 803.868831
iter 13 time: 0.112698 maxerr: 773.751705
iter 14 time: 0.104304 maxerr: 746.772667
iter 15 time: 0.103350 maxerr: 722.424056
iter 16 time: 0.116914 maxerr: 700.305763
iter 17 time: 0.109865 maxerr: 680.097726
iter 18 time: 0.107713 maxerr: 661.540528
iter 19 time: 0.101935 maxerr: 644.421422
iter 20 time: 0.101064 maxerr: 628.564089
[Partition 0][Node 0] End of program

All of the other +oneWthPer* options work.
Running with or without charmrun doesn't matter.

Original date: 2018-02-01 17:11:33

I specifically did not add oneWthPerHost to standalone builds (which are all multicore has) because host count is not relevant to a single machine--it is always one.

Original date: 2018-02-01 17:38:56

Yes, but we should accept that argument since it does make sense, and because we should always parse and consume all of these options. If the options don't make sense, we can throw a warning or error, but we shouldn't let the argument through to the user's arguments.

Original date: 2018-02-01 21:30:36

~~https://charm.cs.illinois.edu/gerrit/3608~~ https://github.com/UIUC-PPL/charm/commit/66b4e46cb6b406aa538730b3c3233a5fc6fe67a4


[Do not merge] Add support for subaddresses

PLEASE READ
Submitted a PR to the light wallet spec highlighting a different way of supporting subaddresses: https://github.com/monero-project/meta/pull/647
I anticipate closing this PR, and opening a new PR implementing the proposal accepted there.

Update [1/3/21]: scanner picks up on outputs sent to subaddresses when there are 3+ outputs in a transaction involving subaddresses
Overview
This PR adds support for subaddresses in monero-lws. All monero-lws server endpoints that take an address can instead take a subaddress with this PR. For example, to login with a testnet subaddress:
curl  -w "\n" -X POST http://<IP_ADDRESS>:8443/login -d '{"address": "BffjVfkhQiZZfc4mU9xHGZQHNfgvz1PG367Pwhed2yob1qXf96eMydYT8tTkev8RBsMQMyJChTdqae5JN1sFjknFRWBEqQh", "view_key": "f747f4a4838027c9af80e6364a941b60c538e67e9ea198b6ec452b74c276de06", "create_account": true, "generated_locally": false}'

I implemented a migration to add a falsey is_subaddress boolean to every address stored in the db, since all addresses already stored must be primary addresses. The migration runs the first time you run monero-lws, then doesn't run again. I took inspiration from monero/src/blockchain_db/lmdb/db_lmdb.cpp in how to structure the migration.
Also, drawing attention to 2 things in particular in this PR:
1. Potential subaddress leak
If you give someone your subaddress, they can use your subaddress to query the server to see if your subaddress is stored on the server, but cannot gain information beyond the fact that it is or is not stored. They would still need your view key to get more information beyond the fact that the subaddress is stored. The fact that it's stored is revealed to someone calling any of the endpoints and providing a subaddress with a different view key from the one already stored, which would return with a "bad view key" error iff already stored. This leak does not affect primary addresses.
I figure the added complexity to avoid this leak may not be worth the gain for monero-lws, since if you give someone your subaddress, and also give them the endpoint of your monero-lws server, you may already be comfortable with them knowing you're monitoring that subaddress on your own server already. I figure this would be a worse implication for MyMonero (and not monero-lws) since you probably don't want to tell someone who you give your subaddress to that you're using MyMonero by default (they would be able to find out if you're using MyMonero with just your subaddress), and therefore it's worth preventing in MyMonero's case if they start supporting subaddresses.
Without modifying the light wallet API, the simplest safe solution to prevent this I can think of (with no timing attack) would be to allow storage of all subaddress/view key pairs (i.e. allow duplicate subaddresses across different view keys). monero-lws admins could approve create/import requests by referencing the view key, rather than address (so an admin accepting a single view key could approve multiple create/import requests at once). There would be no uniqueness constraint on addresses this way, but rather on address/view key pairs. The plumbing to get this working would be a bit more work, but happy to do it if it's the desired solution.
2. Equality check on secret keys
The equality check on crypto::secret_key uses libsodium's constant time crypto_verify_32. This is critical. If it didn't compare in constant time, and compared the lws::db::view key types with a naive byte comparison, it could leak the view key via a timing attack.

I'm curious to why you choose to return bad view key and not just a 401 response?

I'm curious to why you choose to return bad view key and not just a 401 response?

TL;DR because I believe a timing attack could theoretically still leak whether or not it's stored, and figured since it's not a perfect defense, may as well return the clear error to users who fat finger the view key.
There are 2 cases that need to be handled:
(1): the signup case (create_account set to true)
(2): all other cases
On (1) the signup case, if a user provides a different view key than one already stored, it would need to return successfully without writing the create request to the db (in the happy case, when you provide a fresh subaddress/view key, it writes the create request to the db). Not writing the create request to the db takes less time than writing it to the db. So someone should be able to theoretically infer if the account is already stored or not by timing how long the response takes, regardless of what view key they provide.
On (2) it's a bit more subtle. If you hit a route and the server sees the account is stored, it will compare the view key provided in the REST request with the one stored. This would take more time to do than if the account simply were not present in the db in the first place. Therefore someone recording times could potentially still learn that the view key they're providing is incorrect, and subaddress is stored or not. So I figured as long as it's not a perfect defense, might as well return bad view key to make it clearer what the issue is to an honest user fat fingering the view key.
The reason I suggested actually storing all address/view key pairs as a solution is to guarantee the round trip time to server is expected to be the same in all cases.

Well, okay.. That kinda makes sense :smiley:
The timing attack part. Wouldn't that require the attacker to be on the same server to make sense?
At any time, I'm running at least 8 VPS on my server, each running multiple services, all sharing one physical network interface, all battling for CPU slots, not to mention RAM. Response times would depend on what else is going on, I would think.

I think you're right there's a solid chance the timing attack is impractical to pull off in a lot of (maybe even all?) cases. And perhaps that's a good enough reason to handle the return cases as described (signup always succeeds, others fail with non-descript error), rather than just assume all servers are automatically compromise-able by this theoretical timing attack.
But I would also guess for certain honest users and certain circumstances, they may be more likely to be vulnerable. E.g. maybe a user who runs the server on machine with a slow HDD or running low on space or other poor specs, and is only running monero-lws so response times are more consistent. Even then I'm not sure how feasible it is.
Maybe there is also some way for an attacker to hit the server in a way that would make it more likely to pull off with accuracy. I'm not sure.
It feels like leaving a potential blind spot that I felt more comfortable either just assuming is compromised, or removing the blind spot entirely. But perhaps you are right that maybe it's worth assuming it may be difficult if not impossible to pull off. Still, I wouldn't feel comfortable assuming I'm safe from the attack. I originally wrote the code this way we're discussing, and included a comment that there may be a timing attack vulnerability and it just felt wrong to leave in and justify the more complex behavior to always return success on signup, even when not technically succeeding and not writing the request to the db

So, assuming your environment has not been compromised, timing attacks are off the table.
Now, correct me if I got something wrong. Sub-addresses are derived from your primary. Why would you need/want to sign up again, using a sub-address/view-key, when you already got a primary account? Shouldn't you be able to fork out a sub-address, and expect your primary to register a "payment" ?

Upon re-reading prior discussions, I forgot I didn't handle the case when there are 3+ outputs in a tx involving subaddresses. Will implement it as part of this PR too.

Shouldn't you be able to fork out a sub-address, and expect your primary to register a "payment" ?

The server could implement a lookahead when scanning for outputs like wallet2 does. So for all primary addresses stored, it could also derive X subaddresses (50*200 is the default in wallet2), and then compare against all of these subaddresses when scanning for outputs. This would be harder to scale for a server (10k subaddress comparisons per output, for all primary addresses stored on the server).
Generally this would also be a bigger change to the light wallet REST API in that the tx's and outputs and info returned for a primary address are also from all subaddresses. I think a larger change to the API is ultimately warranted to support subaddresses in the most optimal way (also including support for the account/subaddress abstraction). The idea with this PR was to support them in a way that meshes with the API today without too much hassle, and later on think through a larger API change and collaborate with other light wallet ecosystem folks.
I discussed this^ a bit with @vtnerd over DM, and you can see some related discussion on it here.

Why would you need/want to sign up again, using a sub-address/view-key, when you already got a primary account?

Alternatively, without too much hassle we could maintain the format of the API, but on the backend require the primary address to be stored first before allowing new subaddresses to be added to the watch-list via /login. This is another plausible way to prevent the timing attack. When a user tries to login with a subaddress, the backend could first see if the view key is stored alongside the primary address, then derive a large number of subaddresses and see if the one the user provides is among them. It could start out with the default lookahead of 50*200, and need to think further on how to handle the case with more subaddresses.

So, assuming your environment has not been compromised, timing attacks are off the table.

I wouldn't say this with 100% confidence. I read this as "the attacker needs to have access to the environment to pull off the timing attack", but I think in theory the attacker may be able to pull it off without special privileges over the environment where the server is hosted. For example, if the user hosting the server has a disk that happens to write extremely slowly, then I think they'd be vulnerable to the timing attack in the signup case (i.e. in this case, it's just dependent on the user's existing environment, and isn't something the attacker necessarily needs to have control over).
Also: happy New Year to you as well!! 😃 an enjoyable discussion to cap the year :)

Upon re-reading prior discussions, I forgot I didn't handle the case when there are 3+ outputs in a tx involving subaddresses. Will implement it as part of this PR too.

Shouldn't you be able to fork out a sub-address, and expect your primary to register a "payment" ?

The server could implement a lookahead when scanning for outputs like wallet2 does. So for all primary addresses stored, it could also derive X subaddresses (50*200 is the default in wallet2), and then compare against all of these subaddresses when scanning for outputs. This would be harder to scale for a server (10k subaddress comparisons per output, for all primary addresses stored on the server).
Generally this would also be a bigger change to the light wallet REST API in that the tx's and outputs and info returned for a primary address are also from all subaddresses. I think a larger change to the API is ultimately warranted to support subaddresses in the most optimal way (also including support for the account/subaddress abstraction). The idea with this PR was to support them in a way that meshes with the API today without too much hassle, and later on think through a larger API change and collaborate with other light wallet ecosystem folks.
I discussed this^ a bit with @vtnerd over DM, and you can see some related discussion on it here.

Why would you need/want to sign up again, using a sub-address/view-key, when you already got a primary account?

Alternatively, without too much hassle we could maintain the format of the API, but on the backend require the primary address to be stored first before allowing new subaddresses to be added to the watch-list via /login. This is another plausible way to prevent the timing attack. When a user tries to login with a subaddress, the backend could first see if the view key is stored alongside the primary address, then derive a large number of subaddresses and see if the one the user provides is among them. It could start out with the default lookahead of 50*200, and need to think further on how to handle the case with more subaddresses.

So, assuming your environment has not been compromised, timing attacks are off the table.

I wouldn't say this with 100% confidence. I read this as "the attacker needs to have access to the environment to pull off the timing attack", but I think in theory the attacker may be able to pull it off without special privileges over the environment where the server is hosted. For example, if the user hosting the server has a disk that happens to write extremely slowly, then I think they'd be vulnerable to the timing attack in the signup case (i.e. in this case, it's just dependent on the user's existing environment, and isn't something the attacker necessarily needs to have control over).
Also: happy New Year to you as well!! 😃 an enjoyable discussion to cap the year :)

Look-ahead on 10K sub-addresses could become expensive on a server hosting wallets for multiple users, and is probably not a good idea for a program with light in the name :smile: so some method to add sub-addresses is needed.
If sub-addresses are treated as new accounts, that's pretty much it. But if they are linked to a primary address, I think some kind of short lived session should exist, created by a login primary-address + view-key, or the adding of sub-addresses should be an extension to the login endpoint request. How is that?

Look-ahead on 10K sub-addresses could become expensive on a server hosting wallets for multiple users, and is probably not a good idea for a program with light in the name :smile: so some method to add sub-addresses is needed.
If sub-addresses are treated as new accounts, that's pretty much it. But if they are linked to a primary address, I think some kind of short lived session should exist, created by a login primary-address + view-key, or the adding of sub-addresses should be an extension to the login endpoint request. How is that?

idea for a program with light in the name

The wallet is light, not the server :)
But did you measure how much resources it takes for 10k subaddresses lookahead? If I had to guess it should be next to unnoticeable with a slight RAM increase.
Subaddresses use a lookup table so there is no impact on scanning time.

idea for a program with light in the name

The wallet is light, not the server :)
But did you measure how much resources it takes for 10k subaddresses lookahead? If I had to guess it should be next to unnoticeable with a slight RAM increase.
Subaddresses use a lookup table so there is no impact on scanning time.

Syncing 10K blocks on a i7-5500/16GB gobbles up 80% CPU for 3-4 mins. one primary and no account/sub-addresses used, both client and server running off SSD. Not exactly light load.
But, if this thing can handle, say 100 primary, with 10K look-ahead, without noticeable impact on performance, that would be nice :smiley:

Syncing 10K blocks on a i7-5500/16GB gobbles up 80% CPU for 3-4 mins. one primary and no account/sub-addresses used, both client and server running off SSD. Not exactly light load.
But, if this thing can handle, say 100 primary, with 10K look-ahead, without noticeable impact on performance, that would be nice :smiley:

Syncing 10K blocks on a i7-5500/16GB gobbles up 80% CPU for 3-4 mins. one primary and no account/sub-addresses used, both client and server running off SSD. Not exactly light load.

3-4 mins sounds a bit long for scanning 10k wallet blocks, but I don't have monero-lws compiled to test it myself. On my system monero-wallet-cli takes less than 20 seconds to scan 10k blocks.

But, if this thing can handle, say 100 primary, with 10K look-ahead, without noticeable impact on performance, that would be nice 😃

If implemented correctly subaddresses shouldn't have any impact on scanning time, only RAM, but this has to be tested :)

Syncing 10K blocks on a i7-5500/16GB gobbles up 80% CPU for 3-4 mins. one primary and no account/sub-addresses used, both client and server running off SSD. Not exactly light load.

3-4 mins sounds a bit long for scanning 10k wallet blocks, but I don't have monero-lws compiled to test it myself. On my system monero-wallet-cli takes less than 20 seconds to scan 10k blocks.

But, if this thing can handle, say 100 primary, with 10K look-ahead, without noticeable impact on performance, that would be nice 😃

If implemented correctly subaddresses shouldn't have any impact on scanning time, only RAM, but this has to be tested :)

The 10K blocks synced was done by monero-wallet-gui on Windows, against a "local" monerod running on Slackware 14.2.
Connecting to monerod and syncing a wallet, seems to have very limited impact on the server +2-3% CPU

The 10K blocks synced was done by monero-wallet-gui on Windows, against a "local" monerod running on Slackware 14.2.
Connecting to monerod and syncing a wallet, seems to have very limited impact on the server +2-3% CPU

The 10,000 subaddress comparisons per output could just be a hash table lookup (constant time avg lookup), but I would think the 10,000 subaddress public view keys would be read into memory for each primary address stored on the server. Napkin math: 10,000 * 32 bytes * number of primary addresses stored = 0.32 mb per primary address stored = 1 GB for ~3,000 primary addresses = 10 GB for addresses = 100 GB for 312,500 addresses etc. So it would become a significant consumer of RAM when we're talking 10's-100's of thousands of primary addresses stored on the server.
An additional caveat, as mentioned in that other subaddress PR, because of the 3+ output case, when scanning tx's involving subaddresses searching for outputs belonging to subaddresses, I'll need to use the additional tx public keys stored for each output to derive shared secrets for each additional tx public key. This will add to scanning time depending on how many 3+ output tx's involving subaddresses there are.
Naturally it makes sense to discuss the resource cost of a lookahead approach when scanning here, but just to be clear I think deciding on this optimal lookahead approach is out of scope for this PR, mostly since it would need a larger change to the light wallet API which is upstream
The goal with this PR is to get subaddresses working without a change to the API. Which makes sense to do for the long term anyway imo in case a user wants to more granularly work with subaddresses.

If sub-addresses are treated as new accounts, that's pretty much it

That's this PR's approach to get initial subaddress support working :)

But if they are linked to a primary address, I think some kind of short lived session should exist, created by a login primary-address + view-key, or the adding of sub-addresses should be an extension to the login endpoint request. How is that?

This is doable without adding to the endpoint's expected params instead of the approach taken in this PR, like how I mentioned starting at "Alternatively" in the above comment. Just require the user hit the server with the primary address first. This is a tradeoff though: if you give the server your primary address and view key, the server can derive all subaddresses and see all outputs belonging to your account. Maybe users might not want to give their primary address to the server for this reason, to allow scanning of some subaddresses on a case-by-case basis when the user wants. Figure it would make sense to leave as an option for users

The 10,000 subaddress comparisons per output could just be a hash table lookup (constant time avg lookup), but I would think the 10,000 subaddress public view keys would be read into memory for each primary address stored on the server. Napkin math: 10,000 * 32 bytes * number of primary addresses stored = 0.32 mb per primary address stored = 1 GB for ~3,000 primary addresses = 10 GB for addresses = 100 GB for 312,500 addresses etc. So it would become a significant consumer of RAM when we're talking 10's-100's of thousands of primary addresses stored on the server.
An additional caveat, as mentioned in that other subaddress PR, because of the 3+ output case, when scanning tx's involving subaddresses searching for outputs belonging to subaddresses, I'll need to use the additional tx public keys stored for each output to derive shared secrets for each additional tx public key. This will add to scanning time depending on how many 3+ output tx's involving subaddresses there are.
Naturally it makes sense to discuss the resource cost of a lookahead approach when scanning here, but just to be clear I think deciding on this optimal lookahead approach is out of scope for this PR, mostly since it would need a larger change to the light wallet API which is upstream
The goal with this PR is to get subaddresses working without a change to the API. Which makes sense to do for the long term anyway imo in case a user wants to more granularly work with subaddresses.

If sub-addresses are treated as new accounts, that's pretty much it

That's this PR's approach to get initial subaddress support working :)

But if they are linked to a primary address, I think some kind of short lived session should exist, created by a login primary-address + view-key, or the adding of sub-addresses should be an extension to the login endpoint request. How is that?

This is doable without adding to the endpoint's expected params instead of the approach taken in this PR, like how I mentioned starting at "Alternatively" in the above comment. Just require the user hit the server with the primary address first. This is a tradeoff though: if you give the server your primary address and view key, the server can derive all subaddresses and see all outputs belonging to your account. Maybe users might not want to give their primary address to the server for this reason, to allow scanning of some subaddresses on a case-by-case basis when the user wants. Figure it would make sense to leave as an option for users

I don't think the memory requirement are scary at all. If you need to host 10K primary accounts with sub-addresses, you probably can afford dedicated hardware to run it on.
Also, I don't see the use-case, where you would need a hosted wallet, for single dedicated sub-addresses, but maybe that's just me. Wasn't sub-addressed supposed to be single use anyway?
Yeah, we got a bit side tracked withe the look-ahead discussion. I still think a 401 response is better than a more descriptive error, thus not leaking information.

If you need to host 10K primary accounts with sub-addresses, you probably can afford dedicated hardware to run it on.

Fair point, though at some point it would be infeasible (3 million addresses = 1 TB of RAM, 30 million = 10 TB etc.)

Also, I don't see the use-case, where you would need a hosted wallet, for single dedicated sub-addresses, but maybe that's just me. Wasn't sub-addressed supposed to be single use anyway?

Fair enough, I agree not a strong use case. Probably would be very few users if any who wouldn't send their primary address to a light waller server if they're using a light wallet server and were given the option not to. Not much reason to do that.
So perhaps it would be a reasonable solution in this PR to require the primary address be stored before storing any subaddresses for an existing view key. The only challenge with this approach then is dealing with the lookahead in a solid way.
I'm ok with the non-descriptive error approach as well (even though I would still feel uneasy about the timing attack vector), but curious to hear your thoughts on the solution to allow duplicate subaddresses to be stored for different view keys, and for admins to manually accept create/import requests by referencing a view key rather than an address? This should definitively close the timing attack vector.
In summary, there are 4 options on the table for this PR:
(1) as is with descriptive error that says "bad view key"
(2) nondescriptive error + signup always returns success (timing attack may still be an issue)
(3) require primary address be stored first before storing subaddresses (need to handle lookahead correctly)
(4) allow duplicate subaddresses to be stored
I personally still like option 4 if we don't want to leak that a subaddress is stored. It is simplest to reason through I think

I guess I don't understand your option 4. Is the view-key derived per sub-address or the primary view-key?
I like the login with primary address/key thingy.
That would fail probes early, while costing a DB search (time), returning valid or invalid. 200 Ok token or 401 Invalid credential
That would give option to validate sub-address/view-key doing some math.
I also think, you are much deeper into this Monero thingy, than me, so I'm probably better served by your instinct :smiley:

Update: scanner now picks up on 3+ output tx's involving subaddresses

I guess I don't understand your option 4. Is the view-key derived per sub-address or the primary view-key?

In option 4, there would be 0 server-side validation that the subaddress is derived from the secret view key. The server would simply assume any subaddress / secret view key pairs it receives are valid and store them. Even if the provided subaddress is not derived from the secret view key, it will store in the db and the server would attempt to scan outputs sent to this invalid subaddress / secret view key pair. The scanner simply would not pick up on outputs sent to this invalid pair, and the server would never return tx's associated with this invalid key pair (get_address_txs e.g. would succeed with an empty array every time). If the honest user comes along later and tries to login with the valid subaddress / secret view key pair, then the server would allow them to, would store this new key pair, would be able to scan and return tx's associated with this correct key pair etc.
Option 3 has grown on me too for the same reason: it fails early on and the DB is kept clean with valid subaddresses. I'll think further/look to wallet2 some more on handling the lookahead in that option.

I also think, you are much deeper into this Monero thingy, than me, so I'm probably better served by your instinct smiley

You've been around longer than me so your instincts/insights have been super helpful :)

Heads up: going to start using the term "standard" address instead of "primary" since it seems more widely referred to as "standard" address.
More importantly, I think this is what both you guys (@trasherdk and @selsta) were initially thinking too, but I'm starting to think the simplest (and most future-proof) thing would be for the server to just not accept subaddresses over the API at all, rather:

the server would just implement whatever default lookahead the server host wants (monero-lws could default to 50*200)
/get_address_info, /get_address_txs, and /get_unspent_outs would return data for an entire wallet, rather than just the standard address
the client would manage subaddress creation on its end without touching the server (client adds "accounts" and "addresses within accounts" locally, gives them out to counter-parties when requesting payment, server will pick up on them via lookahead when scanning for received outs)
when the client is reading received outputs, the client can validate the outputs really belong to the user and slot them into the correct subaddresses (note: the client would also implement a lookahead in addition to the server)

With this approach, the API wouldn't really change much, just that the aforementioned endpoints would return wallet-level info by default, rather than standard address-level info.
If there is demand from lots of individual light wallet users to pre-load tons of subaddresses before accepting payments to them, the server can also support a user-specific desired lookahead over the /login endpoint. This seems like more of a nice-to-have than a necessity imo. I think we can get away without it until the transition to the next gen protocol.
I think this API approach is also most in line with what's brewing with JAMTIS. In JAMTIS, the server wouldn't even be able to separate data by subaddresses, and would just scan wallet-level potential received outs. The client in JAMTIS would manage the lookahead and subaddress state.
Ultimately, it just does not seem desirable to treat subaddresses as distinct scanned wallets at the API layer and on the backend as this PR does. As discussed above, users aren't going to use the feature like that. Users will want wallet-level data, and that seems to be the long term direction we are headed anyway with JAMTIS. It doesn't really seem useful to allow subaddresses in place of the address param in the API, and it brings annoying complications with it (like how to safely deal with the leak as discussed above).
Planning to submit a PR to the light wallet REST API spec fleshing this out. And I'll probably end up closing this PR and opening a new one implementing that.

This has already been implemented, so the PR is no longer relevant.


Set client URL from async storage?

I have setup redux with this middleware but I would like to set the 'url' for the client, and change it with Async storage, as the user enters their server URL and the api calls are made from that
I see you can have multiple clients but how can I set the client URL from within the app and save and load that from async storage

@kenji-1996 is there any update regarding that issue ?


X-ray IDs should not saved in the access history

Describe the bug
In Access from history section of the options page, X-ray IDs are saved as well as Lambda function names.
They should not be saved.

Not fixed. Reopen.

Fix confirmed.

Not fixed on the options page. When opening xray from the options page, the id is saved...


Nextset ver 2.0

When submitting a connector, please make sure that you follow the requirements below, otherwise your PR might be rejected. We want to make you have a well-built connector, a smooth certification experience, and your users are happy :)
If this is your first time submitting to GitHub and you need some help, please sign up for this session.

[1] I attest that the connector doesn't exist on the Power Platform today. I've verified by checking the pull requests in GitHub and by searching for the connector on the platform or in the documentation.
[1] I attest that the connector works and I verified by deploying and testing all the operations.
[1] I attest that I have added detailed descriptions for all operations and parameters in the swagger file.
[1] I attest that I have added response schemas to my actions, unless the response schema is dynamic.
[1] I validated the swagger file, apiDefinition.swagger.json, by running paconn validate command.
[1] If this is a certified connector, I confirm that apiProperties.json has a valid brand color and doesn't use an invalid brand color, #007ee5 or #ffffff. If this is an independent publisher connector, I confirm that I am not submitting a connector icon.

If you are an Independent Publisher, you must also attest to the following to ensure a smooth publishing process:

[ ] I have named this PR after the pattern of "Connector Name (Independent Publisher)" ex: HubSpot Marketing (Independent Publisher)
[ ] Within this PR markdown file, I have pasted screenshots that show: 3 unique operations (actions/triggers) working within a Flow. This can be in one flow or part of multiple flows. For each one of those flows, I have pasted in screenshots of the Flow succeeding.
[ ] Within this PR markdown file, I have pasted in a screenshot from the Test operations section within the Custom Connector UI.
[ ] If the connector uses OAuth, I have provided detailed steps on how to create an app in the readme.md.

Hi @taiSateraito, thank you so much for submitting your update. we have an old open pull request for your connector. We can't have two pull requests for the same connector.
please let us know which one you would like to proceed with.
Thank you so much for understanding. We really appreciate your hard work with us.

Hi @taiSateraito, thank you so much for submitting your update. we have an old open pull request for your connector. We can't have two pull requests for the same connector. please let us know which one you would like to proceed with. Thank you so much for understanding. We really appreciate your hard work with us.

I would like to proceed PR #1713
Can you review it for me?
Thank you for your support

Hi @taiSateraito, I hope you are doing well. I am trying to set up a meeting with you to discuss you pull request.
Can you please check my email, or please send us an email to<EMAIL_ADDRESS>so I can send you our availability.
I look forward to hearing from you.
Thank you very much.

Dear Amjed Ayoub,
I am Tai from Sateraito Office.
Thank you for your contact.
I try to pull request. However, I received some errors.
Can you show me how to solve this problem?
Best Regards, Tai.

Hi @taiSateraito, I hope you are doing well. I am trying to set up a meeting with you to discuss your pull request.
Please send us an email to<EMAIL_ADDRESS>so I can send you our availability.
I look forward to hearing from you.
Thank you very much.

This is a bad pr. Please work with Amjed to submit a clean PR.


'renderDefaultValues' does not exist in type 'Options'

I just recently converted my Storybook instance to TypeScript, and I'm noticing type errors here when using 2.0.1. I would expect what I have below to not produce an error as this option was introduced in 2.0.

Looking through the installed node_modules folder for 2.0.1, I see the following present in storybook.d.ts:
export interface Options {
  /** hides the `arg ref` label on each control */
  hideArgRef?: boolean;
  /** sets the custom type reference in the Custom Elements Manifest */
  typeRef?: string;
  /** Adds a <script> tag where a `component` variable will reference the story's component */
  setComponentVariable?: boolean;
  /** doesn't render attributes when their value is equal to the default value of that attribute */
  renderDefaultAttributeValues?: boolean;
}

Based on what is in the branch main, renderDefaultAttributeValues no longer exists and was replaced with renderDefaultValues, which makes me wonder if there was an issue with the initial publishing of 2.0.0 that is causing the types for the new option to not be included in the bundle. I tried downgrading to 2.0.0 and I see the same problem.

You're right. The type is different in the package for some reason. I redeploy to see if I can get it fixed.

This should now be fixed in release 2.0.2

Looks good! Thanks


Fix Docker-all-in-one Tendermint download link

Signed-off-by: David Dashyan<EMAIL_ADDRESS>Issues Resolved
Resolves issue #2691

Codecov Report

Merging #2692 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2692   +/-   ##
=======================================
  Coverage   93.32%   93.32%
=======================================
  Files          46       46
  Lines        2712     2712
=======================================
  Hits         2531     2531
  Misses        181      181


Suggested refactoring

Hi there,
I was working on subscriptions for which there is no API class like SendEmailApi and I noticed that the following logic si repeated multiple times in each API class
// authentication (APIKeyHeader) required
if (!string.IsNullOrEmpty(Configuration.GetApiKeyWithPrefix("Authorization")))
    if (!localVarRequestOptions.HeaderParameters.ContainsKey("Authorization"))
        localVarRequestOptions.HeaderParameters.Add("Authorization",
            Configuration.GetApiKeyWithPrefix("Authorization"));
// authentication (Basic) required
// http basic authentication required
if (!string.IsNullOrEmpty(Configuration.Username) || !string.IsNullOrEmpty(Configuration.Password))
    localVarRequestOptions.HeaderParameters.Add("Authorization",
        "Basic " + ClientUtils.Base64Encode(Configuration.Username + ":" + Configuration.Password));
// authentication (IBSSOTokenHeader) required
if (!string.IsNullOrEmpty(Configuration.GetApiKeyWithPrefix("Authorization")))
    if (!localVarRequestOptions.HeaderParameters.ContainsKey("Authorization"))
        localVarRequestOptions.HeaderParameters.Add("Authorization",
            Configuration.GetApiKeyWithPrefix("Authorization"));
// authentication (OAuth2) required
// oauth required
if (!string.IsNullOrEmpty(Configuration.AccessToken))
    localVarRequestOptions.HeaderParameters.Add("Authorization", "Bearer " + Configuration.AccessToken);

// make the HTTP request

If I might, I suggest creating a new method like AddAuthenticationHeaders in ApiClient and calling it at the beginning of ExecAsync, you are already setting things up from configuration in that location, so why do half the job in ApiClient and half in each method of each API class, move all there 🤷🏻♂.

Also, the code will never enter the third block of if-if-add which is identical to the first.
if (!string.IsNullOrEmpty(Configuration.GetApiKeyWithPrefix("Authorization")))
    if (!localVarRequestOptions.HeaderParameters.ContainsKey("Authorization"))
        localVarRequestOptions.HeaderParameters.Add("Authorization",
            Configuration.GetApiKeyWithPrefix("Authorization"));

Hi @BluMichele,
thank you for suggested updates and for using our library.
We are planning to fully refactor this library in the next major version release your suggestions will be taken into account. We'll keep you informed.
Kind regards,
Petra


Refactor components and path. Moved to .jsx default extension.

Refactor application tree:

app/App.jsx
app/Components/**/*.jsx

Changed webpack configurations in order to support .jsx default extensions for components.

Hi @erremauro.
The .jsx extension was required in the past to explicitly identify react components and parse JSX. When using a transpiler such as Babel, this is no longer necessary (as it automatically identifies React components based on import declarations).


feat: change_matching ... with tactic

This PR implements the change_matching p with r tactic, which replaces each p in the target with r if p and r are definitionally equal. This is like rewrite [show p = r by rfl], but the replacement does not depend on their being a type-correct motive. The tactic is comparable to the Lean 3 change p with r tactic.
Closes #5116

This feels similar to the equals conv tactic. Is there a way to use this similarity for a more consistent syntax?
Also, will there be change .. to .. by .., for when the proof isn't just rfl? I see rw [show a = t by tac] a lot, and it looks very clumsy.
Or am I derailing this, if this is less about rewriting and more about changing defeq terms?

@nomeata This one's just for defeq replacement. If it weren't for that, it would be like using pattern p <;> equals t => rfl.
Now's a good time to think about whether this Lean 3 era syntax could be improved, but I haven't thought of anything better. Maybe change p => r? It seems like there ought to be a defeq version of conv for precise navigation and unfolding/replacement...

Maybe change p => r

Not sure, => is often a tactic herald (case, conv, tactic).
As we discuss this I wonder if a better UX design would be to have similar tactics for the defeq and the rewriting case, and they differ in their suffix. A user likely has a certain aim (goal should be X), and that's what's on their mind first. So they write change X and if it holds definitionally, then great! If not they'll get a suitable error message and can continue with by to prove the equation using a tactic (or maybe using to give a term?).
So maybe same with change p to e? Maybe equals t could have the by optional?
(All not fully throught through, at this time of week :-))

Oh, and I keep writing change p to t rather than with, which somehow sounds unnatural to me. Is that just me? Or is this maybe a kludge to avoid new keywords?

@nomeata change with is a bit unnatural, but it's understandable. Normally you'd say "change to" or "replace with". Yes, it's a keyword kludge — I think every Lean 3 tactic used only "at"/"using"/"with"/"generalizing" clauses.
change by is interesting, though it's incompatible with how this change with tactic works. I suppose change with by could go through the process of checking the motive for type correctness and performing the rewrite when there's this by clause (change with computes a motive, but there's no need to check it for type correctness). For just change by, Mathlib has convert_to, which creates side goals when things aren't defeq (after applying zero or more congruence lemmas), which covers that use case I think.

Do we have a strong reason to stick to what we had in lean 3 or can we polish it a bit. For example these sound better to me

change p to e
replace p with e
replace p = e (slight, but neat abuse of notation)

All of these could support an optional proof with by, the last even with :=.
I'm not sure if change p to e and change p to e by tac are too incompatible. Sure, from an implementation point of view theory are different tactics, but both user intention, and the effect on the goal are very compatible, so it seems plausible to present them to the user as variants of the same idea?
And if we had that I think there is room for change by as well. The congruence applying class of functions is in my mind a separate and more complex and less predictable thing. If I have a + b as a goal, then change to b + a by … is a reasonable natural step where the user probably does not want congruence to be applied. In fact I almost always when using convert have to look up how to limit it (using 3, right - odd syntax again) because it often does too much. So it seems to make sense to offer something more basic, more predictable.
(I snuck in a to here, but probably that's not an improvement over the existing change b + a, although the missing preposition has bothered me a bit before - after all change e doesn't actually change e.)

I'm not attached to change with, other than the convenience of not needing to add any new keywords, and other than my own convenience to be able to close this issue that was assigned to me :-)
I wanted to say that change with should have the same head keyword as change, but maybe it would be ok to have a different keyword. Unfortunately though replace is taken. I don't think we should consider renaming the change tactic itself — that would be some unnecessary breakage of code and teaching material. (The = idea doesn't work since it's common to use change when the goal is an equality.)
Regarding the by variants, these are just completely different tactics, so I'm not sure it's worth discussing it here on this PR, though of course it's worth making sure there are syntax variations available. (Note that convert_to defaults to doing just one level of congruence, so it's not too unpredictable.)

What do you think of non-keywords keywords here (nonReservedSymbol)? Will that work well and give us some syntactic breathing room, or is that a bad idea?

it doesn't work as is, because it follows an expression, and it will mix up the pseudo-keyword with an application to a similarly named identifier. You might be able to get it to parse as desired using notFollowedBy?

I'd like to avoid non-reserved keywords — I find them to feel a bit hacky (though please feel free to experiment to see if it can work well here). What do you think about change_matching p with r @nomeata ? I also tried change p for r, but term-for gets in the way. One more syntax I considered is change p := r or change_matching p := r.

Started a Zulip discussion


Support query, mutation hooks

const hooks = {
  viewer: {
    pre: (next, root, args, {rootValue}) => {
      const {request} = rootValue;
      // authorize the logged in user based on the request
      authorize(request);
      // modify arguments ...
      // args.id = 'userid';
      next(root, args, {rootValue});
    },
    post: (next, value) => {
      console.log(value);
      next();
    }
  },
  singular: {
    pre: (next, root, args, {rootValue}) => next(),
    post: (next, value) => next()
  },
  plural: {
    pre: (next, root, args, {rootValue}) => next(),
    post: (next, value) => next()
  },
  mutation: {
    pre: (next, args, {rootValue}) => next(),
    post: (next, value) => next()
  }
};
const schema = getSchema(models, {hooks});

lgtm
Are you planning to add an example hook to the todo app? For example console log when an item was marked as resolved.

@hekike

Would you not pass value through to next(value) in your post hooks?

@burkhardr You can pass a value, in that case the next middleware will get it, otherwise it gets the default arguments.

Brilliant! LGTM :shipit:


🌱 Disable dependabot auto rebasing when any PR is merged

Signed-off-by: Spencer Schrock<EMAIL_ADDRESS>What kind of change does this PR introduce?
Dependabot config update

[X] PR title follows the guidelines defined in our pull request documentation

What is the current behavior?
Dependabot auto rebases every one of its open PR when any PR gets merged into main.
This leads to a lot of unneeded CI runs.
What is the new behavior (if this is a feature change)?**

disables automatic rebasing, so we can rebase 1 by 1 as needed when we approve PRs
includes some missed Dockerfiles. Some of the distroless base images are 1 year out of date.

[ ] Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes
NONE

Special notes for your reviewer
Docs for this flag are here
Does this PR introduce a user-facing change?
For user-facing changes, please add a concise, human-readable release note to
the release-note
(In particular, describe what changes users might need to make in their
application as a result of this pull request.)

NONE

Thank you! We should also consider weekly interval for these PRs maybe.

+1 makes sense to me if we currently have too many PRs to merge daily. That can be a separate issue/PR


⚠ TorrentLeech has degraded performance

In 6b57c51, TorrentLeech ($TL) experienced degraded performance:

HTTP code: 200
Response time: 4407 ms

Resolved: TorrentLeech performance has improved in 00b4eab after 6 minutes.


Default if no match

Total idiomatically supports defaulting if there is no match using const default or \_ -> default instead of _case like so:
data Example a b c = C1 a | C2 b | C3 c deriving (Generic)

makePrisms ''Example

instance (Empty a, Empty b, Empty c) => Empty (Example a b c)

getString :: Example String Double Int -> String
getString = const "not a string"
    & on _C1 (\s -> s)

Maybe this should be documented? Maybe a synonym _default = const?

Wow, that never occurred to me!  Neat trick!
Yeah, I'd be happy to include _default = const.  Would you be able to write up a pull request for this?

Done and done. You can also emulate case statements that aren't lambda cases but I don't see much value in it. Also, I'm wondering about the type sig of on.
on
    :: ((a -> Either a Void) -> i -> Either l r)
    -> (l -> o)
    -> (r -> o)
    -> i
    -> o

Is it always the case in actual use that a ~ l?

So if you use a lens then it will be the case that a ~ l.  I just left it with the more general type just to be safe since in theory the user might want to provide something more general than a lens.


How to use NPM ?

Hello,
I was just wondering how I can use NPM inside of NodeOS ?
The OS started, it launched a REPL session correctly.
But when I type "npm something", it tells me that NPM should be run outside of the REPL. So I press Ctrl+D to quit the REPL and then... The OS doesn't do anything! I can only type things, they appear on screen, but nothing happens.
So how are we supposed to use NPM ?

How have you downloaded and exec the OS? You should get up to a shell on
the standard prebuilds, if you got a REPL then something went wrong...
El 8/2/2016 12:07, "p4ulolol"<EMAIL_ADDRESS>escribió:

Hello,
I was just wondering how I can use NPM inside of NodeOS ?
The OS started, it launched a REPL session correctly
But when I type "npm something", it tells me that NPM should be run
outside of the REPL So I press Ctrl+D to quit the REPL and then The OS
doesn't do anything! I can only type things, they appear on screen, but
nothing happens
So how are we supposed to use NPM ?
—
Reply to this email directly or view it on GitHub
https://github.com/NodeOS/NodeOS/issues/205.

I downloaded the pre-build i386-pc_iso version from the Releases page. The only thing I can say is that the REPL works fine.

What's the prompt of the REPL? This should tell you in what step it failed.
El 8/2/2016 12:21, "p4ulolol"<EMAIL_ADDRESS>escribió:

I downloaded the pre-build i386-pc_iso version from the Releases page. The
only thing I can say is that the REPL works fine.
—
Reply to this email directly or view it on GitHub
https://github.com/NodeOS/NodeOS/issues/205#issuecomment-181320290.

NodeOS-mount-filesystems. Also I noticed I had this error before :
Could not find userfs: [Error: /dev/sdb2 not exists]
And then it prompted me for the path to userfs. As I didn't know what to type, I pressed enter and it told I won't be able to save changes.

Then there you have the answer, it can't find the users partition :-) Just
set the path to the partition and you are fine.
Are you using it in real hardware? This should not give problems on QEmu...
We don't have yet a proper way to autodetect partitions and it's hardcoded
the most usual one, pull-requests are welcome :-)
El 8/2/2016 12:27, "p4ulolol"<EMAIL_ADDRESS>escribió:

NodeOS-mount-filesystems. Also I noticed I had this error before :
Could not find userfs: [Error: /dev/sdb2 not exists]
And then it prompted me for the path to userfs. As I didn't know what to
type, I pressed enter and it told I won't be able to save changes.
—
Reply to this email directly or view it on GitHub
https://github.com/NodeOS/NodeOS/issues/205#issuecomment-181324801.

Ok :-) but what path should I give ? The path where it is on my harddisk, like C:\etc. ? Or the cygwin path ? (/cygdrive/c/users/paul/downloads/i386-pc_iso )

Ok :-) but what path should I give ? The path where it is on my harddisk,
like C:\etc. ? Or the cygwin path ?
(/cygdrive/c/users/paul/downloads/i386-pc_iso )

You need to give the path to the device on Linux, like /dev/sdb2. Are you
getting this error on QEmu? That's sounds terrible bad... :-/ How are you
running it?

Yes I get this error on QEmu, that's why I can't figure what path I have to give...
I run it using cygwin, with this command : sh run.sh (the run.sh file is the one which is present in the pre-build archive)

Try with /dev/sda2. Since you are using the iso image instead of the qemu
image it could be trying to find the partition in the wrong place since
it's intended to be flashed on a pendrive and run on real hardware, where
usually there's already a hard disk, but on QEmu doesn't.
El 8/2/2016 12:42, "p4ulolol"<EMAIL_ADDRESS>escribió:

Yes I get this error on QEmu, that's why I can't figure what path I have
to give...
I run it using cygwin, with this command : sh run.sh (the run.sh file is
the one which is present in the pre-build archive)
—
Reply to this email directly or view it on GitHub
https://github.com/NodeOS/NodeOS/issues/205#issuecomment-181330008.

Nop, /dev/sda2 doesn't exist. I tried with /dev/sda , but it obviously didn't work.
Maybe I should just take the qemu image. I took the iso one thinking I would get an ISO file, to run on a VM, but I was wrong

The ISO image should work on virtual machines, but it's not so tested. Yes,
it's better you take the QEmu one ;-)
El 8/2/2016 12:53, "p4ulolol"<EMAIL_ADDRESS>escribió:

Nop, /dev/sda2 doesn't exist. I tried with /dev/sda , but it obviously
didn't work.
Maybe I should just take the qemu image. I took the iso one thinking I
would get an ISO file, to run on a VM, but I was wrong
—
Reply to this email directly or view it on GitHub
https://github.com/NodeOS/NodeOS/issues/205#issuecomment-181333624.

Well with QEmu one, I also have a strange error (I took a screenshot because I was too lazy to retype it) : http://grab.by/NWYW
And I don't know how to get the ISO file from rootfs and usersfs... I knew how to do with a kernel using xorriso on a linux machine, but not on my Windows one...
I don't think that just copying those files in an iso file would work...

That error doesn't makes sense. Honestly, I don't know what's happening
here and don't have a Windows machine to test, sorry :-(
El 8/2/2016 13:26, "p4ulolol"<EMAIL_ADDRESS>escribió:

Well with QEmu one, I also have a strange error (I took a screenshot
because I was too lazy to retype it) : http://grab.by/NWYW
And I don't know how to get the ISO file from rootfs and usersfs... I knew
how to do with a kernel using xorriso on a linux machine, but not on my
Windows one...
I don't think that just copying those files in an iso file would work...
—
Reply to this email directly or view it on GitHub
https://github.com/NodeOS/NodeOS/issues/205#issuecomment-181343868.

Ok, well I'll search for a solution, I tell you if I find one

Good thing I'm good at reading errors :)
There seems to be an issue in NodeOs-mount-filesystems on line 36 of index.JS
It claims that the directory /tmp/dev has not been mounted. I'll look into this later.

Ok, thank you lite.

@piranna where is this module on Github?

You can find it in my account, there was a conflict with nodeos-mount-rootfs. I'll need someday to clean up NodeOS organization and remove old ones...

Any progress with that?

Has this error ever re-occured? I can take a look right now.

I have been using npm from inside NodeOS without problems...
El 12/6/2016 4:32 AM, "Lite McFish"<EMAIL_ADDRESS>escribió:

Has this error ever re-occured? I can take a look right now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NodeOS/NodeOS/issues/205#issuecomment-225406058, or mute
the thread
https://github.com/notifications/unsubscribe/AAgfvhXwpEk3aB-df2JIgQHKxcKqtqNUks5qK2-1gaJpZM4HVb1u
.

Let's close it for now, but if this re-occurs assign me to it.


Fix readme image of Bugsnag plugin

Fixes a broken image on the Bugsnag plugin readme.

Closing. We need to take a larger look at readme quality. I opened a ticket instead.


test(feature-section): add e2e-storybook

Related Ticket(s)
#7758
Description
Add e2e storybook tests for feature section
Changelog
New

checks eyebrow, heading, and copy content
checks if content on left and image on right (media align: right)
checks if content on right and image on left (media align: left)
loaded and clickable card link
customize card link from local to external

Changed

{{changed thing}}

Removed

{{removed thing}}

@ariellalgilmore thank you for this!
Looks like some tests are failing:

@jeffchew updated!!


Inconsistent Spacing on MudGrid and MudStack

Bug type
Component
Component name
MudGrid/MudStack
What happened?
When using MudGrid and MudStack with the same Spacing value, the Grid has twice as much space between children as the Stack does.
Expected behavior
Both MudGrid and MudStack should have the same space between children when using the same Spacing value.
Reproduction link
https://try.mudblazor.com/snippet/ckccuVblBaLARuJH
Reproduction steps

Create a MudGrid with a Spacing and some MudItem children.
Create a MudStack with the same Spacing and some children.

Relevant log output
No response
Version (bug)
6.0.11
Version (working)
No response
What browsers are you seeing the problem on?
Chrome, Microsoft Edge
On what operating system are you experiencing the issue?
Windows
Pull Request

[X] I would like to do a Pull Request

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I think updating the values for each of the Grid spacings in this snippet should align the MudGrid and MudStack spacing.
https://github.com/MudBlazor/MudBlazor/blob/fa8743a052159ba128f7a809bc217f90006f722c/src/MudBlazor/Styles/components/_grid.scss#L16-L23


Status Changes

Fixes #107
Modifications

The condition LastTransitionTime is used to track when the condition Status or Reason changed.
Moved setting ObservedGeneration at the beginning of the reconciliation process.
Removed initializing conditions to Unknown in-memory at the beginning of the reconciliation to simplify the LastTransitionTime logic.
Removed the check for Numaflow backward compatibility on ObservedGeneration and removed unit tests related to LastTransitionTime since it is now not changing at every update. If we want to track when a condition was last updated (any field change), we should include a LastUpdateTime field.
Moved Pipeline Status processing logic after the call to reconcile() to get the latest Pipeline status even in case of Pipeline pausing or failures.

Verification
Manually tested changes by creating and editing a PipelineRollout consecutively to make sure the proper condition values would change as expected.

Codecov Report
Attention: Patch coverage is 49.09091% with 28 lines in your changes missing coverage. Please review.

Project coverage is 52.66%. Comparing base (02ea51c) to head (46e3c85).

Files
Patch %
Lines

internal/controller/pipelinerollout_controller.go
50.98%
21 Missing and 4 partials :warning:

...nternal/controller/isbservicerollout_controller.go
0.00%
2 Missing :warning:

internal/util/kubernetes/dynamic_client.go
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #122      +/-   ##
==========================================
- Coverage   52.92%   52.66%   -0.27%
==========================================
  Files          15       15
  Lines        1521     1540      +19
==========================================
+ Hits          805      811       +6
- Misses        593      602       +9
- Partials      123      127       +4

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Mac 文件的隐藏与显示 - 落叶的博客 | Luoye Blog

https://19860320.xyz/2017/02/22/Mac-文件的隐藏与显示/
Every failure is leading towards success.

欢迎大家发表看法


class Licence Document: complicated way to name a Standard Licence?

Very often, we want to name a Standard Licence for a dataset, e.g. "CC BY-NC".
For this purpose, we use the property licence for class Distribution.
This property is meant to "...refer to the licence under which the Distribution is made available. This SHOULD be a reference to a concrete standard license."
However, we found a very complicated way to name a standard licence under class Licence Document here:
In the definition for class Licence Document, the standard licence is named under a (new) property "standard licence".
However, it would be easier to just name the standard licence as the range of property licence for class Distribution.
Example:
<dcat:distribution>
   <dct:license rdf:resource="http://publications.europa.eu/resource/authority/licence/CC_BY_4_0"/>
<dcat:distribution>

Easy and conforms to DCAT-AP!
So, let's give up the property "standard licence"!

I agree with suggesting the usage of this "short" representation for well-known licenses, and we can also recommend the usage of this vocabulary (http://publications.europa.eu/resource/authority/licence) that I think is currently not mentioned in the spec. However, I would keep also the "verbose" possibility not to break backward compatibility. I think it was added to allow the specification of "custom licenses" since we have an optional property of LicenseDocument to add the license text as a string.

Related also to #27


Inconsistent auto-updating

Hi, thanks for creating this plugin!  I was about to create an issue since one type of search was auto-updating (5 minute interval), but another type was not at all.  This happened multiple times.  But now the opposite has happened, where the one that was not updating before now does update, and the other one does not.  So I don't have any helpful clues.  They are both pretty basic.
<!-- note-overview-plugin search: /"- [ ]" -->
<!-- note-overview-plugin search: type:todo iscompleted:0 -->
I can't seem to get github to display them correctly, but each is using 3 lines in Joplin.  "search" starts the second line in both cases, and the third line is "-->".  None of the lines have trailing spaces.

If the note is displayed, it is not updated, only when you trigger a manual update.
With the automatic update only notes that are not displayed are updated.

Thanks! That was the issue.  I have also found that manual update only works in markdown mode, which is fine.  It seems hyperlinked titles can only be clicked in markdown mode as well.  But in rich text mode, clicking does work if you hold Ctrl.


Add pageLoadedCallbacks structure and triggers

Add pageLoadedCallbacks structure and triggers as an unified interface for pageLoaded event callbacks

Thank you very much for your pull request!
Added in SVN Revision 839, which will be synced to GitHub in a few hours.
Therefore closing the Pull Request.


devicetree: Add ranges property support for PCIe node

This requirement originates from : https://github.com/zephyrproject-rtos/zephyr/pull/25166#discussion_r423409878
For PCIe, supported outbound memory windows should be parsed by ranges property in DT node.
Below are more details:
Linux supports parsing of ranges and dma-ranges property under pcie node.
pcie node example:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/msm8996.dtsi#n750
Parsing of ranges(for OB resources) and dma-ranges(for IB resources) is supported via below function:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/pci/of.c#n250
This ranges supports passing type of resource(IO/MEM/PREFETCH, etc) that can be mapped to given OB window resource and PCI OB->AXI translation addresses.
However, all this is w.r.t. PCIe RC, we don't have such requirement for PCIe EP.
For PCIe EP, we would ideally want to just parse the multiple OB region addresses, DT node would look like:
pcie@4e100000 {
    ....
    ranges = <0x0 0x50000000 0x0 0x8000000>,
             <0x4 0x00000000 0x0 0x8000000>;
    ....
};

and change driver like:
   .map_low_base = DT_INST_PROP_BY_IDX(0, ranges, 0), /* should hold 0x50000000  */
   .map_low_size = DT_INST_PROP_BY_IDX(0, ranges, 1), /* should hold 0x8000000 */
   .map_high_base = DT_INST_PROP_BY_IDX(0, ranges,2), /* should hold 0x400000000*/
   .map_high_size = DT_INST_PROP_BY_IDX(0, ranges, 3), /* should hold 0x8000000 */

Currently, I am parsing specific properties(namely map_lowmem_*/map_highmem_*) from DT, and would like to replace like above. This enhancement is useful if we want to support multiple outbound windows.

@galak do you think this should be discussed at dev-review? I don't know PCIe.

@galak do you think this should be discussed at dev-review? I don't know PCIe.

Let's discuss it a little in this issue first.
@Abhishek-brcm can you explain the use case a bit more for PCIe EP.  I'd expect that the host system would be configuring the EP BARs to convey the PCIe bus address space to the EP.  So what exactly is the ranges property in the DTS describing?

I'd expect that the host system would be configuring the EP BARs to convey the PCIe bus address space to the EP.

That's right from RC point of view. Host would configure EP BAR to convey its RC's PCIe address space. It is later used by EP to route the inbound transactions.

So what exactly is the ranges property in the DTS describing?

Here, we are talking about the outbound transactions from EP, wherein EP would map Host address(to be read/write) to its outbound memory to generate outbound transaction.
We want to parse the outbound memory regions supported by EP to be parsed from DT.
In Linux, while RC node has support for parsing outbound memory regions as explained in the issue description, it does not have this support for EP node. For EP nodes, range is being supplied through reg property itself. For example, in below EP node, addr_space conveys entire OB range :
pcie1_ep: pcie_ep@51000000 {
    reg = <0x51000000 0x28>, <0x51002000 0x14c>, <0x51001000 0x28>, <0x1000 0x10000000>;
    reg-names = "ep_dbics", "ti_conf", "ep_dbics2", "addr_space";
    ...
};

However, considering that there could be multiple discrete OB regions supported by EP (We have 2 in our current implementation of driver) OR
RC support could be enhanced to generate Memory read/write transactions through OB memory instead of just Cfg read/write as it is now, ranges property parsing is good addition.

What address space are the ranges mapping between?
Is there a reference to a linux dts that is using ranges as you mention?  I glanced at several EP bindings but didn't seem ranges used in them like (Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt and designware-pcie.txt).  I even seen comments like:
From designware-pcie.txt:
    (The old way of getting the configuration address space from "ranges"
    is deprecated and should be avoided.)

What address space are the ranges mapping between?

For EP, we do not give fixed mapping through the DT node. We only have to give the available outbound region. The Host address(PCIe address) to be mapped changes runtime and is passed to the PCIe driver by the requester. That is the core functionality of EP driver.

Is there a reference to a linux dts that is using ranges as you mention? I glanced at several EP bindings but didn't seem ranges used in them

As I had mentioned in above comment, "In Linux, while RC node has support for parsing outbound memory regions as explained in the issue description, it does not have this support for EP node"..
Only RC has support for parsing OB memory regions, But along with it, it mentions PCIe address range to be mapped as well:
pcie0_rc: pcie@48000000 { {
...
                ranges = <0x83000000 0x0 0x42000000 0x0 0x42000000 0 0x2000000>,
                         <0x43000000 0x4 0x00000000 0x4 0x00000000 0 0x80000000>;
...

Here:
ranges = <[PCI resource flags(cell 1)]  [RC Outbound address(cell 2 and 3)] [PCIe address to be mapped(cell 4 and 5)]  [size(cell 6 and 7)]>

From designware-pcie.txt:
(The old way of getting the configuration address space from "ranges"
is deprecated and should be avoided.)

This comment seems specific to designware RC's configuration address space, unrelated.
However, considering the fact that we don't really need to parse either PCI resource flags or PCIe address to be mapped for EP node, we just need the OB memory ranges, we could use reg property itself to achieve this - like how Linux does (I have given example in above comment).
@stephanosio do you agree?

Based on slack discussion for the brcm EP use case encoding should be done as part of the reg property.
If there's a desire to support PCIe RC in Zephyr please let us know as there's a bit of support we'd need to add to the devicetree scripts to handle a PCIe address space and bus parsing which doesn't exist today.

@galak @stephanosio  I have updated PCIe EP PR  https://github.com/zephyrproject-rtos/zephyr/pull/25166 to use reg property to specify the available outbound memory ranges. Please review the same.
As for ranges support, I am okay to defer this issue until/if more mature PCIe RC support is required in zephyr.

For reference, I pushed ranges parsing at #37668

This has been implemented and merged in #38106


Segmented Controls

@Uttkarsh-raj  try to make exact UI given in the figma file and try implementing each of them.
Also please add the section of segments on home screen and implement segment there just like other components.

@Bhavikk01 The packages are not too flexible and there is not much liberty given.... Ill still try to get close to it..


EventProjectionist & EventHandler refactor

This is a pretty big refactor that cleans up the EventProjectionist class, and changes the EventHandler interface.
Notable changes:

EventProjectionist lost a lot of weight, and the method's intentions are a lot more clear now imo. It's easier to read through and grasp the core concepts of the package
A lot of logic has been moved to an EventHandlerCollection class. This class contains EventHandler instances, no more instantiate call every time you need something
EventHandler now has a handles and handle method, so you can implement the internals however you like (not tied to the default array subscribtion notation). The EventProjectionist doesn't need to know how to handle events anymore.
shouldBeCalledImmediately was missing on the Projector interface
Didn't need to change any tests, so nothing changed in the public API, except for a different exception type

Very nice work 👍


Many to many relationship

Add a many to many relationship.
In this case the involved entities are Allergy, and Allergies for a patient.
Use new application frame UI

I saw that you removed all this.i18nService.get for the instant, remember if the screen refreshes the instant is not working and considering that this is a seed to play and to learn, in my opinion, people need to have both examples in the code.
Apart from that, is OK, thank you

According to @apenalver2 comments, I have used this.i18nService.get instead of this.i18nService.instant


fix typos

function name 'fn_cdc_map_time_lsn' should be 'fn_cdc_map_time_to_lsn'

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

Docs Build status updates of commit 1949536:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/relational-databases/system-functions/sys-fn-cdc-map-time-to-lsn-transact-sql.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@rwestMSFT,
Can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@jborsecnik I made a suggested change. Once that's implemented I'll approve the PR.

@jborsecnik I made a suggested change. Once that's implemented I'll approve the PR.

PR team can also make those changes if you want. If so, let us know and sign off. Thx!

@jborsecnik If you can make that minor tweak then please do!

Docs Build status updates of commit 1949536:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/relational-databases/system-functions/sys-fn-cdc-map-time-to-lsn-transact-sql.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Translation function "gettext as __" is not working

The function __( is not translating.
For example the string "SQL Editor"
Expected results
I expect the function __() applied to a string, translate the string
Actual results
The app keeps showing the english translation
Screenshots

How to reproduce the bug

Change the language to spanish
The submenú "SQL Editor" is not translated to "Editor SQL"

Environment

superset version: Superset 0.999.0dev
python version: 3.6.8
node.js version: 12.10.0
npm version: 6.14.2

Checklist
Make sure these boxes are checked before submitting your issue - thank you!

[X] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[X] I have reproduced the issue with at least the latest released version of superset.
[X] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional comments
If I change from __() to _() the label "SQL Editor", it works

maybe you have no meaages.mo ，try this command pybabel compile -d <the superset install path>\translations\

maybe you have no meaages.mo ，try this command pybabel compile -d <the superset installed path>\translations\

Yes, I did that also: pybabel compile -f -d superset/translations -l es. I forgot to put it in the bug description


Log the number of blobs parsed when GC

I suspect the blobService to not return the complete list of existing blobs. That would explain why I need to run multiple times the GC to do a full clean up.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "patch-1" git@github.com:gbougeard/distribution.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Closing as wildly outdated. Feel free to reopen.


Cant reduce the silence timeout

Is there a way to reduce the duration of silence the plugin waits before returning a result on android?
right now it waits around 1 second to detect that the speech has stopped before returning a result
i would like to tweak that value to 0.5 seconds if possible

ok issue solved
i added these lines to the plugin java file
intent.putExtra(RecognizerIntent.EXTRA_SPEECH_INPUT_COMPLETE_SILENCE_LENGTH_MILLIS, 500);
intent.putExtra(RecognizerIntent.EXTRA_SPEECH_INPUT_POSSIBLY_COMPLETE_SILENCE_LENGTH_MILLIS, 500);


setDistributedTracingMode should be the method name

Fixing issue https://github.com/microsoft/ApplicationInsights-node.js/issues/568

Duplicate of #567 so I think this can be closed


[CORE] Remove TPC-H test dataset from module backends-velox, use the one from gluten-core uniformly

Use gluten-core/test/resources/tpch-data-sf100 uniformly in tests where tpch dataset is needed.

@zzcclp This is the attempt to use Parquet data in gluten-core from backend-velox's test code. But it seems that the resource files in core jar cannot be accessed from other modules.
I am thinking to introduce an env var like GLUTEN_HOME to pass to test suites to avoid specifying relevant paths in other modules. otherwise we'll continue breaking the module encapsulations.


First exercise with this repository

This entry has the exercise about Create image with the key word about Big data and Machine learning

@microsoft-github-policy-service agree company=Universidad Industrial de Santander


Allow for deferred responses with ipc

This PR makes modifications to the service and service intraprocess manager to enable deferred services when using IPC.

I tested the current branch and passed the following unit tests demonstrating the current implementation passes:
TEST_F(TestRos2DeferredServices, test_deferred_service)
{
    auto node_options = rclcpp::NodeOptions().use_intra_process_comms(true);

    auto service_node = rclcpp::Node::make_shared("service_test_node", node_options);
    auto client_node = rclcpp::Node::make_shared("client_test_node", node_options);

    const std::string service_name = "test_service";

    auto service = service_node->create_service<example_interfaces::srv::Trigger>(
        service_name,
        [&i, service_node](const std::shared_ptr<rclcpp::Service<example_interfaces::srv::Trigger>> service_handle,
             const std::shared_ptr<rmw_request_id_t> header,
             const std::shared_ptr<example_interfaces::srv::Trigger::Request> request)
            {
                example_interfaces::srv::Trigger::Response response;
                response.success = true;
                service_handle->send_response(*header, response);
            },
        rclcpp::ServicesQoS().get_rmw_qos_profile(),
        nullptr);

    auto client = client_node->create_client<example_interfaces::srv::Trigger>(service_name);

    auto executor = std::make_shared<rclcpp::executors::SingleThreadedExecutor>();
    executor->add_node(service_node);
    executor->add_node(client_node);

    bool response_received = false;
    auto request = std::make_shared<example_interfaces::srv::Trigger::Request>();
    auto result = client->async_send_request(request);

    auto future_status = executor->spin_until_future_complete(result, std::chrono::seconds(1));
    if (future_status == rclcpp::FutureReturnCode::SUCCESS) {
        response_received = true;
    }

    EXPECT_TRUE(response_received);
}

TEST_F(TestRos2DeferredServices, test_deferred_service_async)
{
    auto node_options = rclcpp::NodeOptions().use_intra_process_comms(true);

    auto service_node = rclcpp::Node::make_shared("service_test_node", node_options);
    auto client_node = rclcpp::Node::make_shared("client_test_node", node_options);

    const std::string service_name = "test_service";

    auto fcn = [] (const std::shared_ptr<rclcpp::Service<example_interfaces::srv::AddTwoInts>> service_handle,
        const std::shared_ptr<rmw_request_id_t> header,
        const std::shared_ptr<example_interfaces::srv::AddTwoInts::Request> request)
    {
        // Do work
        std::this_thread::sleep_for(std::chrono::seconds(1));
        example_interfaces::srv::AddTwoInts::Response response;
        response.sum = request->a + request->b;
        service_handle->send_response(*header, response);
    };

    auto service = service_node->create_service<example_interfaces::srv::AddTwoInts>(
        service_name,
        [&fcn](const std::shared_ptr<rclcpp::Service<example_interfaces::srv::AddTwoInts>> service_handle,
             const std::shared_ptr<rmw_request_id_t> header,
             const std::shared_ptr<example_interfaces::srv::AddTwoInts::Request> request)
            {
                std::thread workerthread(fcn, service_handle, header, request);
                workerthread.detach();
            },
        rclcpp::ServicesQoS().get_rmw_qos_profile(),
        nullptr);

    auto client = client_node->create_client<example_interfaces::srv::AddTwoInts>(service_name);

    auto executor = std::make_shared<rclcpp::executors::SingleThreadedExecutor>();
    executor->add_node(service_node);
    executor->add_node(client_node);

    auto request = std::make_shared<example_interfaces::srv::AddTwoInts::Request>();
    request->a = 2;
    request->b = 3;
    auto result = client->async_send_request(request);

    bool response_received = false;
    auto future_status = executor->spin_until_future_complete(result, std::chrono::seconds(3));
    if (future_status == rclcpp::FutureReturnCode::SUCCESS) {
        auto response = result.get();
        EXPECT_EQ(response->sum, 5);
        response_received = true;
    }
        EXPECT_TRUE(response_received);
}

@mauropasse @alsora this PR is now open for review

In the unit tests that I posted above, I am seeing an intermittent failures with the following error:
[ RUN      ] TestRos2DeferredServices.test_deferred_service_async
[rcl|context.c:157] failed to finalize rmw context while cleaning up context, memory may be leaked: Finalizing a context with active nodes, at /home/ubuntu/workspace/.conan_homes/x86_64_gcc10/.conan/data/ros2-core/humble.irbt1/brewst/stable/build/1a0f0cfe0fbc25b4639787f9d79d4ce91db8c417/_ws/src/ros2/rmw_fastrtps/rmw_fastrtps_cpp/src/rmw_init.cpp:159
[ERROR] [1706223531.672432412] [rclcpp]: failed to finalize context: error not set

My suspicion is that there is a race condition in the shutdown of the rclcpp context and the service. Perhaps the storage of the shared_ptr service handle_ by the ServiceIntraProcess that I added is causing this issue. @mauropasse Thoughts?

Unit tests passing now without the aforementioned issue. Should I just merge now?


Beacon or Eddystone

Beacon or Eddystone？

i have more success with eddystone, can read between iOS devices but not android yet

Hi, I'm curious which library/framework do you use on iOS for scanning Eddystone?


[chore]: Refer to MAINTAINERS.md in main from iroha1-main

Description
To avoid maintaining two separate MAINTAINERS lists (with the same content), only refer to it from the iroha1-main branch.
Benefits
No need to keep two files in sync.
Checklist

[x] I've read CONTRIBUTING.md
[x] I've used the standard signed-off commit format (or will squash just before merging)
[x] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

cool

@nxsaken do you want me to force-merge this?

@ryjones I wanted you to take a look since this file affects processes, and maybe there is a good reason this file has been maintained on two branches separately that I'm unaware of.

@nxsaken no good reason


add reverse iframe approach once ledger contract support is released

will not be needed any more with #140


Support using trackBy for datagrids using clrDgItems

Summary
Support using trackBy for datagrids using clrDgItems
What is the change?
The request is to support trackBy on datagrids using clrDgItems so that the original data reference can be swapped out, but still maintain the clarity built-in goodness (filtering, sorting, paginating, clrDgPreserveSelection, and more?)
Why should it go in Clarity?
This is an enhancement that would save some non-ideal workaround code in the case where we want data to update but don't have server-side sort/filter/pagination
Does this change impact existing behaviors? If so how?
This change should not impact existing behaviors
If this change introduces a new behavior, is this behavior accessible?
There should be no new UX behavior as a result of this change
Use case
Our use case is that we have data in grids that can have changing columns, such as a state column that goes from "Pending" to "Connected".  We want to be able to easily swap the old data out for the new, and the cleanest would be to simply reassign what is being fed into clrDgItems
Examples
Workarounds
Here's my stackblitz workaround to sync the data without touching any references that clarity needs in order to keep existing functionality in place: https://stackblitz.com/edit/slack-dg-single-selection-memory-ttt9cw?file=src%2Fapp%2Fapp.component.html

Hi @moiraine
Thanks for the stackblitz and suggestion! I'll take this back to @hippee-lee and @gnomeontherun for triage.

Clarity does support trackBy on clrDgItems, so I'm not exactly sure if there is anything that we need to do. I'm going to close this as already a feature.


update default list of members for pagination flagging

Issue #, if available:
Description of changes:
Adds a couple new default input/output member names that will flag an operation for missing pagination
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Public documentation for MissingPaginatedTrait is out of date https://smithy.io/1.0/guides/model-linters.html


Update playwright driver to 1.29.1

ref: https://github.com/microsoft/playwright-python/pull/1684/files

documentation will be fixed in another PR.

Really lovely work @YusukeIwaki! Thank you for this


Incorrect redundant bracket warning with Template Haskell and type applications

Hlint says that this bracket is redundant, but without it the parse returns the operator @$ instead, and I believe TypeApplications requires no space between the @ and the type, hence the bracket is necessary here:
foo = [|get @($r)|]

Almost the opposite of https://github.com/ndmitchell/hlint/issues/558

Indeed, a curious find. We have the blanket rule that if an atom is surrounded by brackets then those brackets are redundant. But that's clearly not the case here, so I think we'll need to figure out a better way to express this concept.

After taking a closer look, its a weird one, because the @ is an expression, but the ($r) is a type. I've made it so that splice types aren't necessarily atomic, which fixes this bug. It might remove some potential warnings, but given the number of splices in types its probably not that high.

Thank you!


samba: resurrect cross compilation patch

Things done
The patch was dropped in https://github.com/NixOS/nixpkgs/pull/328355, but still required for cross compilation.

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Cross build fails with:
error: output '/nix/store/1dvanx1bjrxqsvdvrhhrhzh03a958mkn-samba-riscv64-unknown-linux-gnu-4.20.4' is not allowed to refer to the following paths:
         /nix/store/px2nj16i5gc3d4mnw5l1nclfdxhry61p-python3-3.12.7

Investigating.

consider adding a test that covers cross compilation to make it less likely the patch gets dropped again? could just be passthru.tests.cross = pkgsCross.aarch64-multiplatform.samba

Cross build fails with:
error: output '/nix/store/1dvanx1bjrxqsvdvrhhrhzh03a958mkn-samba-riscv64-unknown-linux-gnu-4.20.4' is not allowed to refer to the following paths:
         /nix/store/px2nj16i5gc3d4mnw5l1nclfdxhry61p-python3-3.12.7

Investigating.

I can reproduce this issue.

It still shows up for me. I have no clue :p
I'm trying to build a raspi image.

Maybe you are on the wrong branch/commit, please double check.

You were correct, works perfectly!