fixed table detail row color when striped

Describe the PR
Fixes #1716
Small replication
As old BV the PR writes an hidden row when a detail row is opened in order to preserve table striped color

@VividLemon is it possible to have a new release? (0.16 or major) there are a lot of PR already merged but npm is still locked on 0.15.5.
Some issues reported in last few days are already solved...


logging: Make v2 the default, deprecate v1 (alternative 2)

Counter proposal to #41739.
Deprecated CONFIG_LOG2_MODE_DEFERRED and CONFIG_LOG2_MODE_IMMEDIATE.
Introduced CONFIG_LOG1 which enables legacy v1 (with cmake warning).
CONFIG_LOG_MODE_IMMEDIATE=y and CONFIG_LOG_MODE_DEFERRED=y enables v2.
Behavior for various use cases:
Using defaults
If logging was just enabled with CONFIG_LOG=y v2 instead of v1 will be used. If out of tree backend is used which does not support v2 API, application will assert when no backend that supports v2 is found. CONFIG_LOG1=y can be added to use legacy backend.
Explicitly using v1
If CONFIG_LOG_MODE_DEFFERED=y or CONFIG_LOG_MODE_IMMEDIATE=y was used v2 instead of v1 will be used. If out of tree backend is used which does not support v2 API, application will assert when no backend that supports v2 is found. CONFIG_LOG1=y can be added to use legacy backend.
Explicitly using v2
If CONFIG_LOG2_MODE_DEFFERED=y or CONFIG_LOG2_MODE_IMMEDIATE=y there will be cmake warning but there will be no change in implementation. CONFIG_LOG2_MODE_DEFFERED=y can be removed since deferred mode is the default one. CONFIG_LOG2_MODE_IMMEDIATE=yshall be changed toCONFIG_LOG_MODE_IMMEDIATE=y`.
With this approach, when logging v1 is removed, just CONFIG_LOG1 is removed.

this alternative is my favourite.

Like to only have one set of LOG_MODE_*.

Removed DNM and closed PR with alternative 1 as this one seemed to be leading. Please focus your review here so it can get in before freeze.

This is also my preferred solution. Thanks!
However, I am not familiar enough with the logging framework to provide a useful code review, so I will leave that to others.


Downsampling output tensor before using it as an input to a new layer

Hello,
I am trying to merge two layers using the functional API. Now my output shape from one layer is not the same as the output shape from the other layer. How may I go about downsampling or compressing the one with the higher image dimension?
eg -
downsample=(Merge(layerone,layersix],mode='concat')
layerthree=Convolution2D(128, 3,   3,activation='relu')(downsample)
Please make sure that the boxes below are checked before you submit your issue. If your issue is an implementation question, please ask your question on StackOverflow or join the Keras Slack channel and ask there instead of filing a GitHub issue.
Thank you!

[- ] Check that you are up-to-date with the master branch of Keras. You can update with:
pip install git+git://github.com/fchollet/keras.git --upgrade --no-deps

[ ] If running on TensorFlow, check that you are up-to-date with the latest version. The installation instructions can be found here.

[ -] If running on Theano, check that you are up-to-date with the master branch of Theano. You can update with:
pip install git+git://github.com/Theano/Theano.git --upgrade --no-deps

[ ] Provide a link to a GitHub Gist of a Python script that can reproduce your issue (or just copy the script here if it is short).

@raun1 how do you solve it ? Using the reshape?


⚠ Jenkins Plugins Artifactory has degraded performance

In 508314c, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1377 ms

Resolved: Jenkins Plugins Artifactory performance has improved in d73329b after 28 minutes.


i have a problem

Steps to Reproduce

Run flutter create bug.
Update the files as follows: ...
...

Expected results:
Actual results:

Logs

please follow the steps when filing an issue


[Docs] s/OS X/macOS/.

@swift-ci please smoke test

@shahmishal, could you confirm that the triggers all respond to "macOS" instead of/as well as "OS X"?

@shahmishal have you had time for this? (It's not a priority at all, just going through older PRs.)

@shahmishal One more ping here.  Did the check status commands get updated?

Not yet, we can close this for now.


Upgrade grafana to v6.1.6 to address a security patch

What this PR does / why we need it:
This PR addresses a security patch announced this morning. https://grafana.com/blog/2019/04/29/grafana-5.4.4-and-6.1.6-released-with-important-security-fix/
Which issue this PR fixes
Special notes for your reviewer:
@zanhsieh
@rtluckie
@maorfr
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign
/ok-to-test

/lgtm
thanks for contributing!


Added "Query" search that is available on playground

Yay on better search experience!

[pr-server]
View this change on PR Server


Stacks API getting started title formatting is broken

Not sure where the formatting is wrong, but this page https://docs.hiro.so/stacks-blockchain-api/getting-started has a title of "getting-started" instead of "Getting Started"

fixed


Is there a throttle feature to avoid duplicate call?

As title, is there a throttle feature to avoid duplicate calls?

There isn't, and it's not in the backlog.


Win 10 LTSB 2016 Build 10.0.14393.2608 not support

Hi,
Build 10.0.14393.2608 not support please add
in attach x64 version
[10.0.14393.2608_termsrv.zip]
(https://github.com/stascorp/rdpwrap/files/3016607/10.0.14393.2608_termsrv.zip)

Hi,
Build 10.0.14393.2608 not support please add
10.0.14393.2608_termsrv.zip


Add workaround to isComponentOfType for react-hot-loader@^3

As per discussions in https://github.com/react-toolbox/react-toolbox/issues/1443#issuecomment-312201476 #1148 and #1164, react-hot-loader also documents a workaround:
const ComponentType = (<Component />).type;
const element = <Component />;
console.log(element.type === ComponentType); // true

Would you consider this version of defaultChecker?

That's ok for me!

Hooray!


⚠ Bofrost.lu has degraded performance

In 56549e2, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1338 ms

Resolved: Bofrost.lu performance has improved in 9bf8820 after 6 minutes.


[BREAKING CHANGE] Switch to context based client

The current way to instantiate a new client, that supports authenticated actions is:
import { createSafeActionClient } from "next-safe-action";

export const action = createSafeActionClient({
  getAuthData: async () => {
    // return auth object
  },
});

Then, a new action that needs auth info is defined like this:
"use server";

import { z } from "zod";
import { action } from "@/lib/safe-action";

export const exampleAction = action({ input, withAuth: true },
  async (parsedInput, { userId }) => {
    console.log(userId);
    ...
  }
);

This implementation is fine for authentication/authorization purposes, but it's extremely specific too.
There's a better, easier, and generic way to implement auth actions and anything else a user needs: context.
⚠ BREAKING CHANGE: Context based client
Using context, you can define multiple clients for different purposes. Here are two examples with a base client, and an auth one:
import { createSafeActionClient } from "next-safe-action";

export const action = createSafeActionClient();
export const authAction = createSafeActionClient({
  buildContext: async () => {
    // return your context object, for example:
    return {
      userId: "123";
    }
  },
});

Then, a new action that needs auth info would be defined like this:
"use server";

import { z } from "zod";
import { authAction } from "@/lib/safe-action"; // import `authAction` client

// We don't need to pass an object with `input` and `withAuth` keys as first argument
// to the client here, because we know by the client name (`authAction`), that
// the second argument of function that defines server action's code will be { `userId` }.
export const exampleAction = authAction(input, async (parsedInput, { userId }) => {
    console.log(userId);
    ...
  }
);

With context based clients, the second argument of server action function (in this case { userId }), will always be the context object. If you don't define a buildContext function while instantiating a safe action client, then context would be an empty object.
The idea is to include these changes in version 3.0.0 of the library.

You can find and experiment with these new changes in the beta branch.


V11 comtability: Ringct type 3 is not allowed from v11

Demon produces error:
2019-02-28 10:32:53.305 [RPC0]  TRACE   blockchain      src/cryptonote_core/blockchain.cpp:2351 Blockchain::check_tx_outputs
2019-02-28 10:32:53.305 [RPC0]  ERROR   verify  src/cryptonote_core/blockchain.cpp:2437 Ringct type 3 is not allowed from v11
2019-02-28 10:32:53.307 [RPC0]  INFO    txpool  src/cryptonote_core/tx_pool.cpp:213     Transaction with id= <3906846c2faddeb21a2d9499673c62c579b78547652ec91fcf28f45c1714f1a1> has at least one invalid output
2019-02-28 10:32:53.307 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        2      add_tx
2019-02-28 10:32:53.307 [RPC0]  ERROR   verify  src/cryptonote_core/cryptonote_core.cpp:960     Transaction verification failed: <3906846c2faddeb21a2d9499673c62c579b78547652ec91fcf28f45c1714f1a1>
2019-02-28 10:32:53.307 [RPC0]  WARN    daemon.rpc      src/rpc/core_rpc_server.cpp:721 [on_send_raw_tx]: tx verification failed: invalid output
2019-02-28 10:32:53.307 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF       18    on_send_raw_tx
2019-02-28 10:32:53.307 [RPC0]  DEBUG   net.http        src/rpc/core_rpc_server.h:96    /sendrawtransaction processed with 0/18/0ms

when trying to send txs on v11 stagenet.

mymonero-app-js, core-js, core-cpp, libapp-js, and libapp-cpp have been updated with <IP_ADDRESS> compat. Can't test on mainnet yet as tx will fail submission validation (invalid output).

Thank you.
I see new PR with the changes merged just recently: https://github.com/mymonero/mymonero-app-js/commit/86039bdd14d7c2b2c879cce2ea464e1814a087e5
I will check on stagenet, as I already migrated all my stagenet nodes to v11, and will report back.

Little update. Now it sometimes works, but sometimes does not.
Its the same error as before, for txs that fail. Don't know yet, why some txs are different than others, why some fail.

Its different error after all. Orginal error was about invalid outputs. Some, as in most, fail do invalid input:
019-03-01 03:24:08.416 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        0          expand_transaction_2
510893 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        5            verRctMGSimple
510894 2019-03-01 03:24:08.422 [RPC0]  INFO    ringct  src/ringct/rctSigs.cpp:1066 verRctMGSimple failed for input 0
510895 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        5          verRctNonSemanticsSimple
510896 2019-03-01 03:24:08.422 [RPC0]  ERROR   verify  src/cryptonote_core/blockchain.cpp:2836 Failed to check ringct signatures!
510897 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        7        check_tx_inputs
510898 2019-03-01 03:24:08.422 [RPC0]  INFO    txpool  src/cryptonote_core/tx_pool.cpp:266 tx used wrong inputs, rejected
510899 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF        8      add_tx
510900 2019-03-01 03:24:08.422 [RPC0]  ERROR   verify  src/cryptonote_core/cryptonote_core.cpp:960 Transaction verification failed: <5a0845b47c4bd143cad71219df33e606b6a222fdd1c3b99a6e7d62dce7ea62b2>
510901 2019-03-01 03:24:08.422 [RPC0]  WARN    daemon.rpc  src/rpc/core_rpc_server.cpp:721 [on_send_raw_tx]: tx verification failed: invalid input
510902 2019-03-01 03:24:08.422 [RPC0]  DEBUG   perf    src/common/perf_timer.cpp:140   PERF       27    on_send_raw_tx
510903 2019-03-01 03:24:08.422 [RPC0]  DEBUG   net.http    src/rpc/core_rpc_server.h:96    /sendrawtransaction processed with 0/28/0ms

I prepared example of tx that fails. Maybe will be useful.
The tx in hex is here: https://paste.fedoraproject.org/paste/OikdL7u2fwdEicTvTglbIg
The view this tx in decoded form, please copy and paste the hex into the tx pusher of the onion explorer, e.g.: http://<IP_ADDRESS>:8082/rawtx and press Check. Trying to Push the tx, will result in invalid input error.
For comparison, this is example of tx that was accepted: http://<IP_ADDRESS>:8082/tx/b4e9b185fc03949b9982f4474831febb8a1827cfae1caa26356c9e75fb6801e5

@moneroexamples is it the same inputs that fail, or just that they all fail most of the time?

@luigi1111
yes. I have some suspicion now. I see now that
  "ecdhInfo": [ {
        "amount": "c99a65ab35b70809"
      }, {
        "amount": "231f5c0545e1dc1b"
      }],

Are short now. Before they were longer. I also see that ecdhInfo mask is gone for example. I think that I incorrectly handle this in openmonero. Subsequently wrong rct value is provided to mymonero.
Based on the api docks: https://github.com/monero-project/meta/blob/c139cb39ea56441fe7cb7ff13b74fe34b394f2f5/api/lightwallet_rest.md#import_request

rct is, for ringct outputs, a 96-byte blob containing the concatenation of the public commitment, then the ringct mask value, and finally the ringct amount value. For ringct coinbase outputs, the mask is always the identity mask and the amount is zero; for non-coinbase ringct outputs, the mask and amount are the respective raw encrypted values, which must be decrypted by the client using the view secret key. For non-ringct outputs, this field is nil.

So I think the question is, has the format changed now?
And txs that were successful, might have used only coinbase txs.

Ah, that makes perfect sense.
 Perhaps you could just send the field as either 96 or 40 bytes and the client could interpret based on length.
Otherwise you'd need some kind of versioning, or the API/server could calculate the values and send them the old way (that sounds pretty meh though).

Yes, this seems to be the case.
openmonero is only backend to mymonero frontend, so I need to try to handle this in a way mymonero expects it. For now I don't know if mymonero requires some other or new type/format of information in the rtc fields in its api or not?

@paulshapiro
Do you know if there were any changes made to rct fields in mymonero backend, and what are these fields now?

@moneroexamples we havent changed anything on the server yet. Still digging but haven't diagnosed yet. What we know so far is that monero_transfer_utils::_rct_hex_to_rct_commit could be updated for 40 byte fields… but it's actually functionally OK as it is because it's looking at the head of the string… and it also wouldn't cause an issue of 'invalid input' afaik. Does seem that sc_isnonzero from MLSAG_Ver must be returning false. We're continuing work to debug.

@paulshapiro
Thank you for update. I though that its already working for you, and it only does not work for openmonero. I also keep investigating on what's happening.

Hi
Got it working. Still need to fully test it, but now I dont see the issue anymore.
The solution (hopefully) seems to be to simply provide decrypted rtc_mask mask to the fronted. Subsequently, the frontend don't need to decrypt it anymore.
Patch that I used in mymonero-core-js:
diff --git a/src/monero_transfer_utils.cpp b/src/monero_transfer_utils.cpp
index 4d11a06..0428d47 100644
--- a/src/monero_transfer_utils.cpp
+++ b/src/monero_transfer_utils.cpp
@@ -154,6 +154,11 @@ bool _rct_hex_to_decrypted_mask(
        std::string encrypted_mask_str = rct_string.substr(64,64);
        THROW_WALLET_EXCEPTION_IF(!string_tools::validate_hex(64, encrypted_mask_str), error::wallet_internal_error, "Invalid rct mask: " + encrypted_mask_str);
        string_tools::hex_to_pod(encrypted_mask_str, encrypted_mask);
+
+    std::cout << "dont decrypt mask as now the decrypted mask is provided by backend" << endl;
+    decrypted_mask = encrypted_mask;
+    return true;
+
        //
        if (encrypted_mask == rct::identity()) { // NOTE: ringct coinbase txs have the identity mask manually provided unencrypted in the rct field by the hosted lightwallet backend
                decrypted_mask = encrypted_mask;

And on the backend I simply use decrypted rtc_mask now, as shown here: https://github.com/moneroexamples/xmregcore/blob/d6601b5286ae7d98d573cc1a43dedaa3f852363e/src/UniversalIdentifier.cpp#L185
the rtc amount value is same as before. Its short now, so its padded with zero to require length.

In my tests, this occurs anytime a coinbase output is used as an input to the new transaction, and not otherwise.
That includes sending any amount from a wallet containing only coinbase outs, but also from a wallet that contains a mix of smaller non-coinbase outs and larger coinbase ones: sending a larger amount (that would require using the coinbase outs as inputs) fails, but smaller amounts work fine.
All of the wallets I tested with contain only pre-fork outputs -- i.e., with a 32-byte amount and explicit 32-byte mask. So, although the format of the rct field will still be an issue for newer inputs, I don't think it is related to this error.

@ndorf
For me it seems to be working all fine now, and I'm pretty sure I have pre-v11 coinbase txs in my wallet. Do you have any wallet stagenet or testnet seed so that I can try to import it and check? Alternatively, you can use stagenet version of openmonero. I already updated it to v11 with the patched mymonero core js utils for testing: http://<IP_ADDRESS>:81/
If coinbase is causing problems, are you sure that this issue was solved (https://github.com/moneroexamples/openmonero/commit/fb20cb2179db6b6bda5285f432c7d10905501035/), or not reverted back in some commit? Before mymonero was also not able to spent any coinbase txs aswell, and what you describe seems as the same issue.

Oh, now I learned that there is also some issue in monero itself with coinbase txs: https://github.com/monero-project/monero/pull/5217
So maybe this is related and causing problems?

That should be unrelated as far as I know.

Are you sure. Because I see that the new monero issue is that it decodeRtc for coinbase txs, when it should not https://github.com/monero-project/monero/pull/5217/commits/fa2fbc3917774ee9615e1bcf1437d57ab400018f#diff-9d580668dab930045943902048e2ac22R11322
So maybe in openmonero I dont have this issue at all, because I've been always checking if I deal with coinbase or non-coinbase txs when decoding outputs: https://github.com/moneroexamples/xmregcore/blob/master/src/UniversalIdentifier.cpp#L166

Yes. Coinbase transactions don't normally have rtc fields. Unless the failing outputs have some wacky stuff going on, this is irrelevant.

Oh, now I learned that there is also some issue in monero itself with coinbase txs: monero-project/monero#5217

That change fixes a potential vulnerability stemming from maliciously crafted coinbase txes. Unless I'm misunderstanding something, it doesn't have anything to do with this error (after all, even before that change, there are no such errors when sending from the official wallet).
I think you're right in that you don't have to worry about that vulnerability, if you never decode the RCT amounts of coinbase transactions to begin with.

@ndorf
Yesterday I forked mymonero-core-cpp, so I can push the patch: https://github.com/moneroexamples/mymonero-core-cpp/commit/993cd4f07806ed042f2b22680e80ce75cebe8116 But it has the same change as before - do not decrypt  rtc mask as encrypted one is provided by the backend. For coinbase txs, the the rtc mask is identity mask anyway, so it didn't need decrypting in the first place. Thus probably that is why coinbase txs worked for v11.
To fully check on pre-v11 coinbase txs, I will spin up new v9 stagenet node or make new private stagenet.

@moneroexamples I think I have a wallet you can use, give me a few minutes.
If you do want to spin up a v9 stagenet node, you can do it much faster than normal, if you first run monero-blockchain-export on your existing node and then monero-blockchain-import --dangerous-unverified-import on the new one -- making sure to use the v0.13 version of the import utility. It will error out when it reaches the first RCTv2 tx; then you can just sync as normal (reorg should be 57 blocks or so, IIRC).

@moneroexamples https://github.com/ndorf/monero_tests/blob/master/testnet-v9-coinbase.seed

@ndorf
Thanks. I imported the wallet, and so far don't have any issue making txs. I did not relay them (dont want to destroy your wallet), but they deamon did not complained about them and I saw them in mempool. I can relay them, just to be sure if this wallet is disposable?
I don't have testnet version of openmonero running, so for now I can paste what get_unspend_outputs looks like for that particular wallet which cointans rtc field: https://pastebin.com/YvPgf2ps
If it was helpful, I could setup testnet version of openmonero online, so you can easly test it as well?

OK, so my issue must be an unrelated regression with respect to https://github.com/mymonero/mymonero-app-js/issues/240. Sorry for the distraction, and thanks for helping!
Back to the question of these RingCT outputs, since only the 40 bytes are required for them, it would be best if we only send those. The client just needs to handle that properly (decodeRct(..., true)).
Using the same field and deciding based on length, as luigi suggests seems fine, I think.

No problem.
You mean modifying this part in mymonero-core-cpp:
https://github.com/mymonero/mymonero-core-cpp/blob/71e383096f3c0dadebe729d61960085035f6e7b5/src/monero_transfer_utils.cpp#L164-L169
So that for v11 txs, decodeRct is used to decrypt the rtc mask?
But anyway, everything is fine with me, as long as the changes will be made clear so that I can adjust openmonero accordingly.

I guess I meant modifying that code to use rct::genCommitmentMask() for v11 txes, which is what rct::decodeRct(), via rct::ecdhDecode(), would do.
That creates a conflict with our workaround for #240, though. We can't send the identity mask if we're not sending any mask at all. However, we don't actually need to send any RingCT data for coinbase transactions. Therefore I propose we just use the magic string "coinbase" for those. So to summarize, we would have four possible values of the rct field:

null/undefined/empty: non-RingCT output (i.e, from version 1 tx)
string "coinbase" (length 8): RingCT coinbase output
string length 192: non-coinbase RingCT version 1 output with 256-bit amount and mask
string length 80: non-coinbase RingCT version 2 output with 64-bit amount and no mask

I think this covers all cases correctly with no sending of superfluous data.
For compatibility, the next client release could still support the encrypted_mask == rct::identity() hack, but after that it could (and I think should) be removed.
Thoughts on this? Am I missing anything?

I think something like this is what we would need client side -- that's not fully tested yet, though.

Sounds good. I will try to implement these changes in openmonero and use the updated mymonero-core-cpp and see how it goes.

@ndorf
I implemented changes for point 4 (string length 80: non-coinbase RingCT version 2 output with 64-bit amount and no mask) for now, and testing this. In this point, frontend generated decrypted mask and am getting same error as before tx verification failed: invalid input.
I think rtc_mask decoding procedure is incorrect. The rtc_mask value obtained from this procedure here : https://github.com/ndorf/mymonero-core-cpp/blob/feature/rct_v2/src/monero_transfer_utils.cpp#L169 is simply different from what it was before and daemon is rejecting it.
To rectify this I modified point 4 into: string length 144: non-coinbase RingCT version 2 output: <64 rct commit as before> + <64 correctly decrypted mask by the backend> + <16 rct amount>
Decrypted mask is done by the backend anyway, so maybe better to use it, rather then re-do the same calculations on the front-end?
I haven't checked other points yet.
What do you think about this?

I pushed a version with modified point 4: https://github.com/ndorf/mymonero-core-cpp/commit/84a4fe6bd3b5d7e45b406a805a078f09eac526a6
I started testing point 2 string "coinbase" (length 8): RingCT coinbase output. Seems to be ok for now.

@moneroexamples yes in order to "decrypt" successfully, the front end would need the same routine added. I'm not sure which I prefer at this point (and I also need some sleep). :) I think it's probably "more correct" to have the front end regenerate the deterministic mask, though it's likely not much different in practice. Cost to regenerate is pretty trivial though.

(tl;dr: one more change at https://github.com/ndorf/mymonero-core-cpp/commit/7f681b75192043b73bd23c5055011d49fbdd4240 fixes everything, I think)
@moneroexamples the elegant simplicity of your change on the OpenMonero side did not escape me. With the decrypted mask already being available in the right place at the right time, it's the best kind of 1-liner: a (-1)-liner. Unfortunately the situation with the MyMonero backend is quite the opposite. It's not infeasible, but it's a lot riskier than the solution I'm proposing here, especially given only a couple of days left to test everything. (To just scratch the surface, there is no decoding of transaction data, RingCT or otherwise, in the HTTP/API server itself.)
If it were the clearly correct solution, that might be a poor excuse, but given that it should be trivial for the client to compute the deterministic mask itself, there is no need to send that from the server for every output, I think that is preferable in and of itself.

I think rtc_mask decoding procedure is incorrect. The rtc_mask value obtained from this procedure here : https://github.com/ndorf/mymonero-core-cpp/blob/feature/rct_v2/src/monero_transfer_utils.cpp#L169 is simply different from what it was before and daemon is rejecting it.

It's definitely incorrect, otherwise it would be working :) what you might have missed is that although it is "different from what it was before," it must be different to be correct: see here
Luckily @paulshapiro was able to quickly notice that I made a mistake in my first change, and incorrectly applied an extraneous hash_to_scalar() to the derived key. After fixing that, it looks like everything is working. I still have a lot more testing to do, but I've successfully sent a few RCT Type 4 outputs already.

@ndorf @luigi1111
Thank for the feedback. The new changes too mymonero-core-cpp seem to be working now with original point 4 (80 characters long rtc field). So now I think the main thing to do is just more testing.

Hey @moneroexamples, for the purpose of triggering the core-cpp code to use the updated transaction construction method at the correct time, we have to add fork height info to get_unspent_outs now. We'll follow up shortly with info on how we're doing that. The parsing of these values will remain encapsulated within the core-cpp code.

@moneroexamples https://github.com/monero-project/meta/pull/287#issuecomment-470172708

Also, I'd like to propose three new fields in the get_unspent_outs response: block_height, next_fork_block_height and next_fork_version.
These would be for use by the client to determine whether or not to use, for example, RingCT type 4 when constructing new transactions.

What do you think?

In my tests, this occurs anytime a coinbase output is used as an input to the new transaction, and not otherwise.

Crud, light-wallet-server has a similar bug where the mask field should be initialized to the identity instead of zero.

null/undefined/empty: non-RingCT output (i.e, from version 1 tx)
string "coinbase" (length 8): RingCT coinbase output
string length 192: non-coinbase RingCT version 1 output with 256-bit amount and mask
string length 80: non-coinbase RingCT version 2 output with 64-bit amount and no mask
I think this covers all cases correctly with no sending of superfluous data.

I would consider changing the name from rct to distinguish the new field more clearly. Although perhaps older clients will incorrectly think its pre-ringct?
Either way, the scenario is just three: (1) no rct field pre-ringct, (2) rct field containing unencrypted mask which might be the (fixed/constant) identity mask for coinbases and (3) "rct": "implied" meaning the client can compute the ringct mask from the other information. If it helps the client at all, everything can be "squished" to just (1) and (2) but the server would have to compute the mask on the fly each time or store it. The server already is storing the mask somehow for these older transactions, but may lose space savings on newer transactions.
I see no reason to send the amount again, its already being sent in another field. Differentiating between coinbases is possible, but leaves an extra case for the client to handle and the only penalty are the transmission bytes for sending the identity mask. The server has a fixed string constant to send either way. Unless you were proposing to send the encrypted mask, instead of unencrypted?

@ndorf @paulshapiro
The new field is ok. I think its main use would be to allow deployment of new client now. Since mainnet is on v9 still, backend would sent "v9" or just "9" to the client to indicate using type 3 rtc txs. When mainnet hits v10 and then v11, clients would automatically switch to type 4 rtc because backend would indicate new version of the hf.

I would consider changing the name from rct to distinguish the new field more clearly. Although perhaps older clients will incorrectly think its pre-ringct?

Yeah, the format is exactly the same for rct types 1-3, so old clients can continue to just work (until the actual fork, of course.) There didn't see much risk in reusing the same field for the new format as well: any reasonable client would just fail to parse it, but the worst case scenario for even an unreasonable one is an invalid tx that will be rejected.

Either way, the scenario is just three: (1) no rct field pre-ringct, (2) rct field containing unencrypted mask which might be the (fixed/constant) identity mask for coinbases and (3) "rct": "implied" meaning the client can compute the ringct mask from the other information. If it helps the client at all, everything can be "squished" to just (1) and (2) but the server would have to compute the mask on the fly each time or store it. The server already is storing the mask somehow for these older transactions, but may lose space savings on newer transactions.
I see no reason to send the amount again, its already being sent in another field. Differentiating between coinbases is possible, but leaves an extra case for the client to handle and the only penalty are the transmission bytes for sending the identity mask. The server has a fixed string constant to send either way. Unless you were proposing to send the encrypted mask, instead of unencrypted?

I'm definitely proposing that we continue sending the mask encrypted, as we are already doing. It was already suggested that this be changed to decrypted, but that is not exactly an overnight change for the MyMonero backend. (It's also not backward compatible, for what little that's worth.)
It seems obvious now that the commitment shouldn't be needed either, but I hadn't realized it at the time. As for the encrypted amount, I'm pretty sure the MyMonero client will happily accept either format without it, so we can amend this update accordingly if you prefer. I hadn't mentioned that before now simply because I didn't want to muddy the waters. The purpose of this update wasn't to be perfect (just in case that's not obvious), but just to get the new-style outputs working in some way that everyone can implement, test and release in the couple of days left before the fork. I think it meets that goal, in spite of its rough edges. Do you disagree?
What I'm asking here is whether we can all live with the change as described here until the dust settles from this weekend's fork. At this point, @moneroexamples and I have each spent considerable time testing the updated client against our respective servers. Going back to square one is not only unappealing, to put it mildly, but given that the iOS version of the client still has to be reviewed and approved by Apple, basically means that there would be zero chance of having a working client on that platform in time.
Longer-term, there's no question that this entire field could use revisiting -- just for starters, there doesn't seem to be any good reason to be sending a blob instead of normal fields -- but what I'm suggesting (ok, insisting) is that we save that for a time when it can be discussed and done right to everyone's satisfaction without the time pressure of an imminent fork.

@moneroexamples

The new field is ok. I think its main use would be to allow deployment of new client now. Since mainnet is on v9 still, backend would sent "v9" or just "9" to the client to indicate using type 3 rtc txs. When mainnet hits v10 and then v11, clients would automatically switch to type 4 rtc because backend would indicate new version of the hf.

Exactly right, that's its only purpose. If the field is missing, the client will just assume the latest fork rules, as it would otherwise. So, it's optional; if you don't set it the new client won't work before the fork, but will afterwards, just like without the change.

The purpose of this update wasn't to be perfect (just in case that's not obvious), but just to get the new-style outputs working in some way that everyone can implement, test and release in the couple of days left before the fork.

The format didn't actually need to be changed if client side deployment is still an issue. If you are having issues with iOS updates, I suggest looking into those changes server side, which will have some additional computation overhead until the client updates get deployed.

I think it meets that goal, in spite of its rough edges. Do you disagree?

Yes, I disagree. We've now got multiple jacked up formats and never needed to change the format to meet the hardfork requirements. The only benefit is that server doesn't have to choose, right now, between a computation or storage hit to backwards support the format. So I regret for not jumping in sooner to this thread. Light-wallet-server was always storing the computed mask, so I didn't even see a reason to start a discussion about an API change when I updated it.
I'm certainly not going to recommend changes at this time - hopefully the special cases for the client can be smoothed out later.

Also, I apologize for the initial jacked up encoding scheme here. Its clearly crummy, and had it been "correct" from the beginning it would've been easier to make changes

@vtnerd @ndorf
I think its already too late to change the rct field, unless some bugs or issues are found.
But I think the rct field needs to be revisited anyway as it still needs some consideration. Two days ago when I was doing tests I found that there are still problems. I think they are not critical, but the problem is that rct field occurs in 2 api calls: get_unspent_outputs and get_random_outs.
So once we settled on new 4-point format of rct field for get_unspent_outputs, I naturally amended get_random_outs to also use the new format. The mysql-core-js was freezing at this time after the change - my guess, it does not account for format changes in  rct field in  get_random_outs. Maybe its already fixed, haven't checked yet? Or maybe my amendments in openmonero were wrong. Had not time to investigate further, so I just reverted to old format in  get_random_outs and it's been working fine.
So for now it seems that rct has to have two different formats. New format for get_unspent_outputs and old one for get_random_outs. I wonder how get_random_outs is handled in MyMonero? Does it still uses old format for rct field?
p.s.
What will be the new format for the fork_version field?

Another goof in the existing format, only the commitment is needed for the get_random_outs endpoint.
The new format cannot be used for get_random_outs if a coinbase is selected as a dummy output - which is very likely for testnet. The JS should get some exception deep within a cpp portion (or some such thing). The JS should be unable to compute a valid CT proof since it doesn't know the "dummy output" commitment. I'd have to look at the equations again, maybe the signer doesn't need the other commitments, but that doesn't seem correct.
Use the existing 96-character format, and put any valid hex values for the amount and mask portion. The client is unable to decrypt them anyway, and they aren't needed for the signature. Currently the JS should be ignoring everything but the first 64-hex characters. The light-wallet-server is actually sending an invalid format containing just the first 64 hex characters, and (I'm fairly certain that) the JS client code accepted this at some point. It looks like wallet2 requires the first 128-hex characters, crud.

Also the new field could work if get_random_outs returned an amount field for each output or more specifically coinbase outputs. The amount is stored as amount == 0 in the DB, which is why they get returned on calls to 0, but the amount is publicly known and not zero. The client could then compute the "zero-commitment" based on the amount specifically for coinbase outputs.

@moneroexamples fork_version is an integer in the range 1-255. It should be 9 now, and 10 after block 1788000 (on mainnet).
I realize now that the API document is not clear on the format of the get_random_outs response. The MyMonero server also sends only the commitment (32 bytes, or 64 hex chars) in those, no amount or mask.
Very concerning though, that you got the client to hang. I'll try to reproduce that in my tests.

@vtnerd I see your point now. Yes, we could have made it work without any client-side change by encrypting the generated deterministic mask and sending that. Perhaps that would have been preferable after all.
I take it that's what light_wallet_server is doing already? (The branch wasn't up to date yet, when I tried to look.) If so, that will continue to work, since that format remains exactly the same for rct v1.

@moneroexamples core-js and core-cpp have been updated with fork_version support

@ndorf
Probably rct field in get_random_outs should be renamed to "commitment" or something similar. As @vtnerd pointed out the problem I experience with get_random_outs and mymonero-core-js was that I assumed that rct is same as in get_unspent_outputs, and it was hanging at "coinbase" string probably. I didn't investigated this issue much at the time. Once there will be some peaceful time after the hf, maybe can revisit this issue.
@paulshapiro
Thanks for updated. I will pull the new changes and check how they work with new fork_version field.

I take it that's what light_wallet_server is doing already? (The branch wasn't up to date yet, when I tried to look.) If so, that will continue to work, since that format remains exactly the same for rct v1.

Yes, light-wallet-server is storing the mask unencrypted in its DB then computes the rct field on-the-fly. The mask is still computed for amount decryption anyway, so its still stored. The one bug is that coinbases are set to rct::zero() instead of rct::identity(), which will get pushed out next.


Untangle some service/worker responsibility confusion

Services enqueueing worker threads! Workers containing API call logic! It's Madness!
The new paradigm is much simpler:

Service classes are called synchronously, and wrap potentially complex business logic into a single operation.
Worker classes contain only scheduling logic and delegate any actual work to Service objects.

Now that there is some clarity of function, some class names have been updated to be clearer as to what task they perform.
All the synchronous calls to a Worker object's perform method have been replaced with calls to the relevant Service class instead. The PublishService was enqueuing API operations to run on a background thread, so calls to that class have been replaced with calls to a PublishWorker.
Finally, there was an erroneous put-content call to the publishing-api in the publish service class. This has now been removed.
Trello

What does "SRP" in the first commit message stand for?

@cbaines It's the S in SOLID

CI is unhappy

This is rebased on top of https://github.com/alphagov/publisher/pull/582 so it'll need that and https://github.com/alphagov/govuk-content-schemas/pull/552 to be merged before it can be merged into master.

I've updated the base-branch to be master, so this is merge-able once CI blesses the two dependant PRs.


Cannot assign to read only property 'progress'

Hi
During the upload process when I reach that point :
 xhr.upload.addEventListener('progress', function (e) {
as soon as I hit
file.progress  file.progress = {
                        status: UploadStatus.Uploading,
                        data: {
                            percentage: percentage,
                            speed: speed,
                            speedHuman: humanizeBytes(speed) + "/s",
                            startTime: progressStartTime,
                            endTime: null,
                            eta: eta,
                            etaHuman: _this.secondsToHuman(eta)
                        }
                    };

I have the following error Cannot assign to read only property 'progress'
my config
"@angular/cli": "^1.6.0",
"@angular/compiler": "5.0.3",
"@angular/compiler-cli": "5.0.3",
"ngx-uploader": "4.2.1",
"@ngrx/store": "4.1.0"
any idea ?
Thanks for your help

could you complete your config?

@retailify
here it is. I've fixed the issue that why I think it comes from somewhere else. since I've updates rxjs, angular and ngrx I got a lot issue with immutable, most of the time I have this error
Cannot assign to read only property

"dependencies": {
    "@angular/animations": "5.0.3",
    "@angular/common": "5.0.3",
    "@angular/core": "5.0.3",
    "@angular/forms": "5.0.3",
    "@angular/http": "5.0.3",
    "@angular/platform-browser": "5.0.3",
    "@angular/platform-browser-dynamic": "5.0.3",
    "@angular/router": "5.0.3",
    "@ngrx/effects": "4.1.0",
    "@ngrx/router-store": "4.1.1",
    "@ngrx/store": "4.1.0",
    "@ngrx/store-devtools": "4.0.0",
    "core-js": "2.5.1",
    "reflect-metadata": "0.1.10",
    "rxjs": "5.5.1",
    "ts-helpers": "1.1.2",
    "tslib": "1.8.0",
    "zone.js": "0.8.18",
    "@angular/cdk": "^2.0.0-beta.11",
    "@angular/material": "^2.0.0-beta.11",
    "@angular/upgrade": "^4.0.1",
    "@angularclass/conventions-loader": "^1.0.2",
    "@angularclass/hmr": "~1.2.2",
    "@angularclass/hmr-loader": "~3.0.2",
    "@ngrx/core": "^1.0.0",
    "@types/file-saver": "0.0.1",
    "angular2-ladda": "^1.2.1",
    "angular2-moment": "^1.3.3",
    "angular2-toaster": "^1.0.2",
    "angular2-virtual-scroll": "^0.3.1",
    "bootstrap": "4.0.0-alpha.6",
    "classlist.js": "^1.1.20150312",
    "file-saver": "^1.3.3",
    "font-awesome": "^4.7.0",
    "hammerjs": "^2.0.8",
    "ionicons": "^3.0.0",
    "jquery": "^3.1.1",
    "ng-http-cache": "^1.2.0",
    "ng2-ckeditor": "1.1.8",
    "ng2-right-click-menu": "0.0.11",
    "ng2-slim-loading-bar": "^4.0.0",
    "ng2-translate": "^4.2.0",
    "ngx-bootstrap": "^1.7.1",
    "ngx-malihu-scrollbar": "^1.1.1",
    "ngx-uploader": "4.2.1",
    "normalize.css": "^6.0.0",
    "obj-traverse": "^1.0.0",
    "reselect": "^2.5.4",
    "rimraf": "^2.6.1",
    "url-loader": "^0.5.8",
    "web-animations-js": "^2.2.5"
  },
  "devDependencies": {
    "@angular/cli": "^1.6.0",
    "@angular/compiler": "5.0.3",
    "@angular/compiler-cli": "5.0.3",
    "@types/core-js": "0.9.43",
    "@types/file-saver": "0.0.1",
    "@types/jasmine": "2.6.0",
    "@types/jquery": "^2.0.41",
<EMAIL_ADDRESS>"1.3.30",
    "@types/karma": "0.13.36",
    "@types/node": "8.0.28",
    "@types/webpack": "^2.0.0",
    "add-asset-html-webpack-plugin": "^1.0.2",
    "angular-router-loader": "0.6.0",
    "angular2-template-loader": "0.6.2",
    "assets-webpack-plugin": "^3.5.1",
    "awesome-typescript-loader": "3.2.3",
    "bootstrap-loader": "^2.0.0-beta.20",
    "bootstrap-sass": "^3.3.7",
    "chalk": "1.1.3",
    "codelyzer": "~2.0.0",
    "cross-env": "5.0.5",
    "del-cli": "^0.2.1",
    "es6-shim": "0.35.3",
    "file-loader": "1.1.5",
    "find-root": "^1.0.0",
    "html-loader": "0.5.1",
    "html-webpack-plugin": "^2.28.0",
    "jasmine-core": "2.8.0",
    "jasmine-marbles": "0.2.0",
    "jasmine-spec-reporter": "~3.2.0",
    "json-server": "0.12.0",
    "karma": "1.7.1",
    "karma-chrome-launcher": "2.2.0",
    "karma-cli": "~1.0.1",
    "karma-coverage-istanbul-reporter": "^0.2.0",
    "karma-jasmine": "1.1.0",
    "karma-jasmine-html-reporter": "^0.2.2",
    "karma-sourcemap-loader": "0.3.7",
    "karma-spec-reporter": "0.0.31",
    "karma-webpack": "2.0.4",
    "lite-server": "^2.3.0",
    "ngrx-store-freeze": "^0.2.0",
    "node-sass": "4.5.3",
    "normalize.css": "^6.0.0",
    "progress-bar-webpack-plugin": "1.9.3",
    "protractor": "~5.1.0",
    "raw-loader": "0.5.1",
    "rimraf": "2.6.2",
    "sass-loader": "6.0.6",
    "style-loader": "^0.16.0",
    "ts-node": "~2.0.0",
    "tslint": "~4.5.0",
    "tslint-loader": "^3.5.3",
    "typescript": "^2.5.2"
  }

Here how I fix (from the javascript I need to update the module and typescript)
instead of
file.progress = {
                        status: UploadStatus.Done,
                        data: {
                            percentage: 100,
                            speed: speedAverage,
                            speedHuman: humanizeBytes(speedAverage) + "/s",
                            startTime: progressStartTime,
                            endTime: new Date().getTime(),
                            eta: eta,
                            etaHuman: _this.secondsToHuman(eta || 0)
                        }
                    }

I change it for
 let fileObj = Object.assign({}, file);
 fileObj.progress = {
                        status: UploadStatus.Done,
                        data: {
                            percentage: 100,
                            speed: speedAverage,
                            speedHuman: humanizeBytes(speedAverage) + "/s",
                            startTime: progressStartTime,
                            endTime: new Date().getTime(),
                            eta: eta,
                            etaHuman: _this.secondsToHuman(eta || 0)
                        }
                    }

But still got issue !? so it doesn't come from ngx-uploader !? but from my config I I guess
Thanks for your help

Please fork the repo and build it (see Readme for that). The repo contains a working example with a simple node server to upload files. And checkout our package.json ;)

Do you fixed your problem?

@retailify
Hi thomas,
the component works pretty fine, the issue comes from somewhere else.
I've tested with the working example , all's good.
Thanks for your help

Fine :) Then I'm closing the issue.

yep :)
thanks
2017-12-22 9:39 GMT+01:00 Thomas Meitz<EMAIL_ADDRESS>
Fine :) Then I'm closing the issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bleenco/ngx-uploader/issues/403#issuecomment-353550227,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AP6Nk49GpAORO4_W1fTC8kCxoUhJmvWOks5tC2rKgaJpZM4RDSzi
.


TaskCollection.matching needs more elaborate description regarding task-configuration avoidance

Issue type
Wrong or misleading information
Problem description
Up to (including) 7.2, the task configuration avoidance documentation stated:

Instead of: TaskCollection.matching(groovy.lang.Closure)
Use: OK
This is OK to use because it does not require tasks to be created immediately.

For 7.3 this was changed in #17885 to

Instead of: TaskCollection.matching(groovy.lang.Closure)
Use: OK, with issues.
matching(Spec) requires all tasks to be created, so try to limit the impact by restricting the type of task, like withType(java.lang.Class).matching(Spec).

Besides the discrepancy of argument types in left and right column, while it affects both overloads the same,
both variants are misleading and it needs more elaborate description or instructions.
If you put the following into an empty build script (DSL doesn't matter):
tasks.matching {
    println("matching ${it.name}")
    it.enabled == true
}.configureEach { println("configure task $name conditionally") }
tasks.configureEach { println("configure task $name") }

tasks.register("foo") {
    dependsOn(tasks.matching {
        println("matching ${it.name} for dependsOn")
        it.enabled == false
    })
}

Then execute gw help, the output is
matching help
configure task help conditionally
configure task help

If you without further change execute gw :foo the output is
matching foo
configure task foo conditionally
configure task foo
matching help
configure task help conditionally
configure task help
matching projects
configure task projects conditionally
configure task projects
matching tasks
configure task tasks conditionally
configure task tasks
matching properties
configure task properties conditionally
configure task properties
matching dependencyInsight
configure task dependencyInsight conditionally
configure task dependencyInsight
matching dependencies
configure task dependencies conditionally
configure task dependencies
matching buildEnvironment
configure task buildEnvironment conditionally
configure task buildEnvironment
matching components
configure task components conditionally
configure task components
matching model
configure task model conditionally
configure task model
matching dependentComponents
configure task dependentComponents conditionally
configure task dependentComponents
matching outgoingVariants
configure task outgoingVariants conditionally
configure task outgoingVariants
matching resolvableConfigurations
configure task resolvableConfigurations conditionally
configure task resolvableConfigurations
matching javaToolchains
configure task javaToolchains conditionally
configure task javaToolchains
matching prepareKotlinBuildScriptModel
configure task prepareKotlinBuildScriptModel conditionally
configure task prepareKotlinBuildScriptModel
matching init
configure task init conditionally
configure task init
matching wrapper
configure task wrapper conditionally
configure task wrapper
matching buildEnvironment for dependsOn
matching components for dependsOn
matching dependencies for dependsOn
matching dependencyInsight for dependsOn
matching dependentComponents for dependsOn
matching foo for dependsOn
matching help for dependsOn
matching init for dependsOn
matching javaToolchains for dependsOn
matching model for dependsOn
matching outgoingVariants for dependsOn
matching prepareKotlinBuildScriptModel for dependsOn
matching projects for dependsOn
matching properties for dependsOn
matching resolvableConfigurations for dependsOn
matching tasks for dependsOn
matching wrapper for dependsOn
matching buildEnvironment for dependsOn
matching components for dependsOn
matching dependencies for dependsOn
matching dependencyInsight for dependsOn
matching dependentComponents for dependsOn
matching foo for dependsOn
matching help for dependsOn
matching init for dependsOn
matching javaToolchains for dependsOn
matching model for dependsOn
matching outgoingVariants for dependsOn
matching prepareKotlinBuildScriptModel for dependsOn
matching projects for dependsOn
matching properties for dependsOn
matching resolvableConfigurations for dependsOn
matching tasks for dependsOn
matching wrapper for dependsOn
> Task :foo UP-TO-DATE

So, whether TaskCollection.matching is fine or not, depends on the concrete usage.
If you pair it with configureEach to only configure matching tasks, it behaves perfectly fine regarding configuration avoidance.
But if you enumerate the task collection, for example by using it in dependsOn, each and every task gets realized to check the predicate, even if it results in an empty task collection like in the given example.
Page with the problem
https://docs.gradle.org/current/userguide/task_configuration_avoidance.html

Thank you for your interest in Gradle!
This is a valid documentation issue that we will address.


[Qt5] update to 5.15.5

Library name: Qt5
New version number: 5.15.5
https://github.com/qt/qtbase/releases/tag/v5.15.5-lts-lgpl

cc @Osyotr

I'll create a PR for this on Sunday.


factoring with CQM

Currently this is just a script. I could try to work it into the existing notebook or create a secon notebook

Oops, submitted to the wrong repo


Website createjs.com with source code is not available

For example:
curl https://code.createjs.com/1.0.0/createjs.min.js
curl: (6) Could not resolve host: code.createjs.com

Hey @tehvgg @gskinner, bumping this to confirm what @trycontrolmymind is reporting. As Adobe Animate relies on loading the CJS library from the CDN, this is causing lots of troubles for our animators at work. Can you please check this out as soon as possible? Thanks!

We're looking into this. It's strange, because the DNS is set to expire in exactly one year, so I'm curious if something glitched at NameCheap. Will update when I find more.

Here's the issue:
https://status.mediatemple.net/incidents/4dbtk0502rs0?u=44vghc9x46lq

Hello @gskinner, thank you for the prompt reply! Hopefully they resolve it soon!

Now fixed.

It was fixed, now it's down again :(

A potential alternative for the period of downtime (was shared by createjs twitter account):
<EMAIL_ADDRESS>

https://code.createjs.com/1.0.0/createjs.min.js seems accessible from Canada, but not from France. Outage now seems partial...

That's why you should never rely on a third party delivering any of your assets. Had the issue this morning, and cut the remote dependency ... you'll probably rely on a specific version of the lib anyway, so download it and put it in your static assets folder. Forget the cache argument ... it's worse that you sites start breaking.

Sorry for the delayed response. I've been dealing with this since I woke up - Media Temple suggested this was an isolated issue, but it impacted all of our domains hosted with them (though CreateJS experienced a much longer outage than the others).
It seems to be resolved globally now, and I've asked MT for info on what happened, and how we can be sure this isn't going to happen again.
https://dnschecker.org/#A/createjs.com

Thanks Grant.


Add support to install ACM on cluster and attach clusters to ACM hub

/lgtm

/verified

/verified


Add easy way to run shell commands respecting .zshrc

Currently, M-! does not respect the user's .zshrc. For instance, aliases defined there will not work. Commit c2216894826616e4a05a3fd6c7e7126b3e053788 attempted to fix this problem using the following tweak:
;;;; Shell commands

;;; Allow the use of shell functions and aliases in M-!. This works
;;; with at least bash and zsh, because the -i flag signifies
;;; interactive usage (so that your rc-file is read). Warning: may
;;; cause M-! to run noticeably slower if you do a lot of things in
;;; your shell's rc-file.
(setq shell-command-switch "-ic")

It turned out that M-! did indeed run a lot slower, so this change was quickly reverted in commit 8c0a283fbf4d17255e246b3c1aae6f4101aedeaa.
It would be nice if both options were available (i.e. run without .zshrc by default, but an option to run with .zshrc). It would be straightforward to toggle this with a prefix argument and rebind M-! and M-&, but M-! already takes a prefix argument to insert the output of the command at point. We could make it so that prefixing the command with two C-u's causes it to respect .zshrc, but this seems like a lot of C-u's. (On the other hand, this is the pattern that C-x C-s uses.)

M-! . ~/.zshrc && whatever RET is a perfectly reasonable workaround IMO.


object-store: add option to return list result as Arrow table

Moved to https://github.com/developmentseed/object-store-rs/issues/3


Fixes for multiple issues

Thanks again for submitting this pull request.
since it covers a number of separate issues, i'm not able to pull the entire patch in, but I have cherry picked several of your fixes into the latest code and released a new version.

closing out remainder of this request.  please open a new one if new changes are requested.


Update Detox and Detox Server to use Babel-Preset-Env

Overview
Remove deprecated package and updated to latest suggest package per Babel docs.

Discussion
I was noticing errors with a project that was not importing babel-preset-latest as a dev dependency. Rather than importing deprecated code I went ahead and updated to current logic.
Example:
detox test

would return
Couldn't find preset "latest" relative to directory "/Users/arista/***/node_modules/detox"

🙏 Really need this 🙏 Nice find/fix, @mrtnrst

What version of node do you guys use?
I am thinking of dropping Babel altogether, node 7.6 handles detox and async await with no need to transpile any code.

We are currently using v8.6 LTS. I thought for legacy support but unsure how far back you wanted to go.

263 days since Node 7.6 was released. Good time to say bye to Babel :)

I can open another PR to remove Babel if you aren't on it already. 🙇

yes, please do 🤗

@rotemmiz I removed the extra babel packages but kept the build. Also added a min version for node engines which will introduce a breaking change, let me know your thoughts.

This is not enough, I want to remove all trace of babel.

remove babel in deps
remove babel in builds (detox/build.sh, detox-server npm run build)
change package.json main in both from lib/index.js to src/index.js

Any quick way to point the package.json to this pull request?
Tried "detox": "wix/detox#404/head", but it gives an error Package "undefined@undefined" doesn't have a "name". because detox uses lerna and the root package.json is not the package I want.

hey @mrtnrst , any updates on your side ? If you need any help, please ping me.

@rotemmiz sorry I've had a busy week. Going to spend some time later today to try and get the CI issues resolved.

@rotemmiz so this was a lot easier than I originally thought! I just have to pay closer attention to my changes. 😁 🎉

Tested the PR, it works if I run npm run e2e:ios inside the detox/test folder.
But, tested on a an empty react-native project with detox and it says this:
Couldn't find preset "es2015" relative to directory "/Users/brunolemos/Projects/react-native-css-in-js-benchmarks/node_modules/detox/node_modules/child-process-promise"

@mrtnrst , one last thing, in order to really test it works, let's point the test project to use Detox from main and not specifically from source.
https://github.com/wix/detox/blob/master/detox/test/e2e/init.js
change:
const detox = require('../../src/index');

to
const detox = require('detox');

Then, if it passes CI, we're good.


Shouldn't allow spaces in username

Rancher versions: 2.0 master 2/28
Steps to Reproduce:

Create a user and have their username be "A B"

Results:  Allows spaces in username

@vincent99 can you give your two cents on this?
I believe you mentioned previously that we should not restrict this field to the typical basic ascii because of internationalization.
There is no technical reason on the backend to restrict " ", but I'll do it if you want.

I don't see any reason to restrict the charset of the username, unless they're indexed somewhere (which would mean a-z lowercase 0-9 and hyphen only)...

ok, will go with that. Assigning back over to @tfiduccia for QA consideration


Mediapipe with WebGL2...

Hello,
I compiled mediapipe for WebAssembly, and trying to use GPU backend for segmentation.
But unfortunately when I tried to use InferenceCalculatorGl and bind GPU buffer to tensor - it fails, because seems like only GL_SHADER_STORAGE_BUFFER buffer types are supported as input, which aren't supported in OpenGL ES 3.0 / WebGL2.
I know official webassembly module works with GPU backend. How can i make it working using the official source code ?

I tried to use new vision tasks API for gpu inferencing, and got the same issue:
Calculator::Open() for node "mediapipe_tasks_vision_image_segmenter_imagesegmentergraph__mediapipe_tasks_core_inferencesubgraph__inferencecalculator__mediapipe_tasks_vision_image_segmenter_imagesegmentergraph__mediapipe_tasks_core_inferencesubgraph__InferenceCalculator" failed: OpenGL ES 3.1 or above is required to use OpenGL inference.

Hi @Honya2000,
Could you kindly provide us with comprehensive details regarding the issue? This includes the steps you are following from our documentation, the operating system you are using, and the version of MediaPipe in use. Additionally, you may utilize the provided template to furnish us with all the necessary information.
Thank you!!


Task - Browse Collecting Event - Vue update.  [Was: 2. Task - Browse Collecting Events – UI Issues]

Feature or enhancement

Inconsistency between Browse COs and Browse CEs: In Browse CE, edit is initiated by either of two options:  a dedicated pen icon at the far right of the page, and via the navigate icon (which doesn’t have a mouseover title, BTW) at the very far right; in Browse CO, edit option is only available under the navigate radial, which requires two clicks to activate the edit. Fix: prefer one-click ‘edit’ option at far left of page under 'Navigate' panel under ‘Next/Previous’ buttons
Different displays for CEs, depending on whether you start from the Browse CE task or start from the Data Table Listing (found at https://sandwich.taxonworks.org/collecting_events/list). Either path can lead to the display of the same CE, but the displays are not consistent. (See https://sandwich.taxonworks.org/collecting_events/756093 vs. https://sandwich.taxonworks.org/tasks/collecting_events/browse?utf8=✓&collecting_event_id=&[collecting_event_id]=756093) Fix: merge two displays into one, but retain the CO table because knowing the associated COs is essential when viewing a CE.
Table shown under the CE displays the associated COs but missing life stage/caste. Fix: include data for life stage/caste
Data at top of page shows verbatim label information, e.g., MADG'R as opposed to full country name - Madagascar. Fix: use non-abbreviated country name from Data Attributes field

Location
Task- Browse Collecting Events
Screenshot, napkin sketch of interface, or conceptual description
No response
Your role
No response

@bpescador, @cgrinter, @rich-keller

@jlpereira Let's use this ID as the basis for Vue re-write.

@jlpereira same structural concepts as in Browse CO.
Panels (to start)

Header, as in CO.
Collecting event table as in CO, but without the Header (Row: Top, 1/2 width; center)
Map panel (just the map), includes all georeferences and GeographicArea shapes if present.  Also includes Verbatim point of a different color. (Row: Top, right column)
Georeferencs pane.  Table. Underneath map panel.
Identifiers panel.  As per CO, but just CE identifiers.  (Right column)
CollectionObjects panel - DwC table.  (Row: Bottom, full width).  Download icon inline with header.

... more to tbd

A couple more followups:

We'll return the one-click edit.  See in part below as to why we removed it.
Since edit is available in the Navigator, we decided to try and remove it and see how it went.  We recognize that the icon "panels" and layouts definitely need some unification and standardization in their location.  Our first attempt at this is Browse CO.  Our goal is to have users learn where to look to "see more", regardless of where they are at. We are trying to balance the number of clicks with the distraction of buttons that may/not be useful for specific workflows.  We are also trying to eliminate overlapping functionality. Note that we are working to having hotkeys that will toggle between edit-and views and related data in some cases.  We'll set them up in Browse CE/CO.  Keypresses are far more effective ways to navigate if efficience is the argument.  We're going to update buttons to reflect whether they open radial navigation (round), vs. other functionality.
The list view is not intended for day-to-day use, nor are the card views.  These are scaffolded views that let us get started.  If they are key parts of your workflow then we need to figure out what to replace them with.  For example lists in Filters (run a search with no parameters) can return the full paginated list.  Browse tasks are intended to replace show views.  Over-time we will increasingly hide Show data cards and their related scaffolded views.

Table shown under the CE displays the associated COs but missing life stage/caste. Fix: include data for life stage/caste

Definitely need a better CO table.  We will work to refactor two table views.  A TW native, and the DwC views.  We'll re-uses those views in multiple places.  TODO- crosslink to individual issues.

Data at top of page shows verbatim label information, e.g., MADG'R as opposed to full country name - Madagascar. Fix: use non-abbreviated country name from Data Attributes field

ur goal wuth the header is not to validate all data, it's to let the user know "I am in the right place", quickly. These tags must reference data available in all projects, i.e. they are standardized, therefor we can not include DataAttributes in them, sorry.


python312Packages.sentry-sdk_2: 2.13.0 -> 2.14.0

https://github.com/getsentry/sentry-python/blob/refs/tags/2.14.0/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[x] 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/)
24.11 Release Notes (or backporting 23.11 and 24.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

[x] Fits CONTRIBUTING.md.

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


Manually configure required ObjectMapper settings

This partially addresses #26, by explicitly setting FAIL_ON_UNKNOWN_PROPERTIES=false and registering JavaTimeModule to handle Instants. This pull request does not remove the ObjectMapper parameter from the AssemblyLineClient constructor; I don't think there's any reason to allow custom settings (we only use the mapper to read/write AL responses/requests), but I can't be sure.

@cccs-mdpouli I think this (mostly) fixes the underlying issue that you ran into with #106, at least in the sense that the client won't break; if you wanted to use the new fields, you would still need to update the client.


Don't call poll when keyseq_timeout is set to 0 to avoid broken poll implementation for devices on MacOS.

The poll system call is broken on MacOS and doesn't work properly for devices, such as /dev/tty.
As a result, reading single escapes is broken when using Behavior::PreferTerm, which causes rustyline to read from /dev/tty. After reading a single escape character, the subsequent call to poll will always return Ok(1), so rustyline will try to parse an escape sequence.
This PR makes a small change to at least improve the behavior when keyseq_timeout is set to Some(0). In this case, we bypass the call to poll altogether, and instead check whether there is any buffered input to determine whether a single escape keypress has been entered or if an escape sequence has been entered, which is a pretty effective heuristic.
I don't know if there's any good workaround for the broken poll implementation when keyseq_timeout is non-zero, but this is at least an improvement.
This should resolve https://github.com/kkawakam/rustyline/issues/607.

I manage to reproduce the issue.
Only with this patch to debug:
diff --git a/src/tty/unix.rs b/src/tty/unix.rs
index 08d7548..264fc3a 100644
--- a/src/tty/unix.rs
+++ b/src/tty/unix.rs
@@ -707,8 +707,10 @@ impl PosixRawReader {
         if n > 0 {
             return Ok(n as i32);
         }
+        debug!(target: "rustyline", "poll with: {:?}", timeout_ms);
         let mut fds = [poll::PollFd::new(self.as_fd(), PollFlags::POLLIN)];
         let r = poll::poll(&mut fds, timeout_ms);
+        debug!(target: "rustyline", "poll returns: {:?}", r);
         match r {
             Ok(n) => Ok(n),
             Err(Errno::EINTR) => {

And this example (timeout <> 0 + Behavior::PreferTerm ):
use rustyline::{Config, DefaultEditor, Result};

fn main() -> Result<()> {
    env_logger::init();
    let config = Config::builder()
        .behavior(rustyline::Behavior::PreferTerm)
        .keyseq_timeout(Some(50))
        .build();
    let mut rl = DefaultEditor::with_config(config)?;

    let _ = rl.readline("> ")?;
    Ok(())
}

RUST_LOG=rustyline=debug cargo run --example issue 2> debug.log

gives
[DEBUG rustyline] poll with: PollTimeout(50)
[DEBUG rustyline] poll returns: Ok(1)

on MacOS as you say.
But we cannot rely on timeout.
No issue with Behavior::Stdio:
[DEBUG rustyline] poll with: PollTimeout(50)
[DEBUG rustyline] poll returns: Ok(0)
[DEBUG rustyline] c: '\u{1b}' => key: KeyEvent(Esc, Modifiers(0x0))
[DEBUG rustyline] Emacs command: Abort

(I am going to check on Linux)

See #803

Would you mind reviewing / testing #803 ?


"Script" property from "Editor settings" should be erased/hidden

I was messing today with "script" property from Godot editor settings. Don't know what it does but I was able accidentally  erase all my editor settings :)
From what Reduz said on irc, this property "probably should not be there"  and ask me to open an issue as a reminder.
So hide this from gui or document it :)
Will label this as a bug since touching this property can be quite harmful.

it's gone


restore-repo does not correctly load "issue foreign ID"s

Description
In short: the struct field migration.Issue.ForeignIndex is missing a yaml:"foreign_id" annotation.
When importing a dump from YAML files via gitea restore-repo, the "foreign ID" of an issue is used to load that issue's comments (see func (r *RepositoryRestorer) GetComments(...)). On first glance this ID should be stored in issue.yml in the foreign_id field, but because there is only a JSON tag and not a YAML one, effectively Gitea is reading it from foreignindex.
This issue was introduced in fa73cbf5a7e84fab50ad5c8f3095b4dec8b4e879. Where all the fields that should get an underscore in the name are annotated for both YAML and JSON, the ForeignIndex is not:
type Issue struct {
	PosterID     int64             `yaml:"poster_id" json:"poster_id"`
	PosterName   string            `yaml:"poster_name" json:"poster_name"`
	PosterEmail  string            `yaml:"poster_email" json:"poster_email"`
	// ...
	IsLocked     bool              `yaml:"is_locked" json:"is_locked"`
	// ...
	ForeignIndex int64             `json:"foreign_id"`
}

Gitea Version
1.19.0+dev-289-gb36854df3
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
2.34.1
Operating System
No response
How are you running Gitea?
Built Gitea myself from its main branch.
Database
PostgreSQL

The fix is:
From 128e4f237cf952f9219f32bdfe86ffd40cec0f4c Mon Sep 17 00:00:00 2001
From: Matti-Ranta<EMAIL_ADDRESS>Date: Wed, 21 Sep 2022 16:32:21 +0200
Subject: [PATCH] accept yaml for foreign_id

---
 modules/migration/issue.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/migration/issue.go b/modules/migration/issue.go
index 78f648dd2..a23812eaf 100644
--- a/modules/migration/issue.go
+++ b/modules/migration/issue.go
@@ -25,7 +25,7 @@ type Issue struct {
 	Labels       []*Label          `json:"labels"`
 	Reactions    []*Reaction       `json:"reactions"`
 	Assignees    []string          `json:"assignees"`
-	ForeignIndex int64             `json:"foreign_id"`
+	ForeignIndex int64             `yaml:"foreign_id" json:"foreign_id"`
 	Context      DownloaderContext `yaml:"-"`
 }

--
2.30.2

and
From 7620c236a86d9cd9771e805ca4ee18e56cb48ede Mon Sep 17 00:00:00 2001
From: Matti-Ranta<EMAIL_ADDRESS>Date: Wed, 21 Sep 2022 16:24:01 +0200
Subject: [PATCH] if id is 0, then use local

---
 services/migrations/gitea_uploader.go | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/services/migrations/gitea_uploader.go b/services/migrations/gitea_uploader.go
index 21f587604..795ff4974 100644
--- a/services/migrations/gitea_uploader.go
+++ b/services/migrations/gitea_uploader.go
@@ -411,6 +411,10 @@ func (g *GiteaLocalUploader) CreateIssues(issues ...*base.Issue) error {
 				Type:         foreignreference.TypeIssue,
 			},
 		}
+
+		if is.ForeignReference.ForeignIndex == "0" {
+			is.ForeignReference.ForeignIndex = strconv.FormatInt(is.Index, 10)
+		}

 		if err := g.remapUser(issue, &is); err != nil {
 			return err
--
2.30.2


Replace underbar in Parameter Hints with color

I find the Parameter Hints in VS Code very hard to read in comparison to IntelliJ.
The main distraction is the underbar which hinders the read flow. The underbar distracts the pattern recognition of your eyes and makes it hard to read whatever is above it. There are whole studies on the topic of underbars and readability, see for example uxbooth.com.
You don't need to read a paper to come to the conclusion that reading text with an underbar is bad.
See for yourself how much easier it is without because you can read that much faster.
Instead of an underbar below the current parameter, using a color would be a much better choice. I personally like a bold orange color like in Webstorm, but would already be happy if just the underbar were gone. Please, reconsider this design choice.
VS Code

Webstorm

@misolori Makes sense to me, what do you think?

I'd be up to try this, we could either use the blue highlight we use for fuzzy search:

Or make the default text a shade of the foreground and make the highlight brighter:

We can show this in the ux channel to get feedback

Wow, I think the second one looks really good! The bright white highlight points directly to the relevant information and the shaded text doesn't distract anymore. I have to change my mind about color and and vote for simple bold white.
Btw. You guys are awesome for responding that fast and thanks for trying this change out!

I think using color for this purpose would basically prevent #55044

I would say adding a theme color.
@KamasamaK Yourn concern is valid. @misolori can we also try using a highlight overlay on top of current parameter, and source the color from editor selection background?


Open Source

https://twitter.com/EmilyKager/status/1321603336051789824

This was also mentioned:

https://twitter.com/laurieontech/status/1446450207395401730


Use Khronos loader for Pico and add store required manifest entries

As of PICO OS 5.9.0, PICO now uses the Khronos loader and has deprecated their own SDK.
After investigating a support query through our forums for deploying a Godot app to the Pico store, we were pointed to the Pico Quickstart page.
The key missing ingredient is likely the pvr.sdk.version manifest entry that now simply states "OpenXR" to indicate the Khronos loader is used.
This PR alters the PICO entry to use the Khronos loader and adds this new manifest entry. I have not merged the PICO settings into the Khronos loader section as the PICO permission requirements clash with HTCs permission requirements. Our only solution at the moment is to keep these as separate entries.
But everything seems to work otherwise.

Changed this the same way as #182 so we no longer need to keep the khronos binaries in our repo but they are pulled in as dependencies by gradle


Whisper responses

Briefly summarize your issue:
In the settings, I noticed a setting called "whispered responses". However after enabling this setting in the menu, alexa responds to whispered questions in full volume. Is this setting not functional in the current state of the sdk?
What is the expected behavior?
Alexa should respond to whispered questions by whispering
What behavior are you observing?
Alexa responds in full volume
Provide the steps to reproduce the issue, if applicable:
Enable whispered response setting, and speak to alexa. Alexa speaks at full volume in return to whispered questions.
What version of the AVS Device SDK are you using?
  1.10

Tell us what hardware you're using:

[ ] Desktop / Laptop
[X ] Raspberry Pi
[ ] Other - tell us more:

Tell us about your OS (Type & version):

[ X] Linux
[ ] MacOS
[ ] Raspbian Stretch
[ ] Raspbian Jessy
[ ] Other - tell us more:

Hi!
AVS SDK does not process the recorded voice on the client side, instead it sends it to AVS once you say a wakeword or use push-to-talk button. It might be more useful for you to ask this question on a general Alexa forums.

I am closing this issue due to inactivity. Please feel free to re-open it if it has been closed in error.

I have the same issue. When whispered responses are enabled in the Alexa app, they work on the Sonos One, but they don't work on the Rasperry PI. Tried it really a lot and it didn't work even once.
I understand that the recorded voice is not processed in the AVS SDK, but as it works with Sonos, there might be a difference in how it is sent to AVS?

I have the same issue. When whispered responses are enabled in the Alexa app, they work on the Sonos One, but they don't work on the Rasperry PI. Tried it really a lot and it didn't work even once.
I understand that the recorded voice is not processed in the AVS SDK, but as it works with Sonos, there might be a difference in how it is sent to AVS?


allow set a flag to compile the pattern

This PR allows to set a flag when configuring value masker ex:
<valueMask>
    <value>(?i)foo</value>
    <mask>*********</mask>
    <flag>8</flag>
</valueMask>

this example compiles the pattern with multiline

Hi @ahernandez-technisys,
Thanks for this contribution.
As you noticed, it is already possible to set/unset the flags directly in the regex pattern (feature supported by the Java Pattern itself). Why do you need another way of specifying flags?


feat: Add support for the portable version of maya, which can be foun…

Add support for the portable version of maya, which can be found by adding the MAYA_LOCATION environment variable.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 70.64%. Comparing base (c2efc6e) to head (998ea06).
Report is 8 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #37   +/-   ##
=======================================
  Coverage   70.64%   70.64%
=======================================
  Files          15       15
  Lines         637      637
  Branches       70       70
=======================================
  Hits          450      450
  Misses        175      175
  Partials       12       12

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

@yjjjj 根据这个文档设置下DCO
https://github.com/loonghao/maya_umbrella/pull/37/checks?check_run_id=24770817922


Check if a user is member of channel

Hi guys!,
How to achieve this?

I have added a bot as an admin to a public channel.
I have tried this:

@bot.command("channelstatus")
def channelstatus_command(chat, message, args):
    """shows the channel status of a user - joined or not"""
    status = chat.status_of(message.sender.username)
    chat.send("*%s*" % status)

It is showing this error:
File "app/bot.py", line 491, in channelstatus_command
    status = chat.status_of(message.sender.username)
  File "/app/.heroku/python/lib/python3.6/site-packages/botogram/objects/chats.py", line 213, in status_of
    raise TypeError("Not available in private chats or channels")
TypeError: Not available in private chats or channels

Can anyone please help me with this?

Hi, thanks for your issue!
This is a bug of botogram, we're working for a solution. For now you can use the raw getChatMember method:
status = bot.api.call("getChatMember", {"chat_id": chat.id, "user_id": message.sender.id})

Thanks for the quick reply....
How to check for a particular channel, if a user is a member?
Is it like this:
status = bot.api.call("getChatMember", {"chat_id": chat.id, "user_id": message.sender.id, "channel": '@channel'})

Do this:
bot.api.call("getChatMember", {"chat_id": "@yourchannel", "user_id": message.sender.id})

Thanks! it started working...

@abhi3700 don't close this, this is a bug that needs to be resolved.
What I sent you is just a temporary solution.

Okay!


dprint fails with "/nix/store/r4r6inyjds6ac9s3jjg398hi52v8i7ip-dprint/bin/dprint: line 3: exec: dprint: not found"

Describe the bug
I added dprint to my flake.nix:
programs.dprint = {
            enable = true;
            config = {
              includes = [ "**/*.json" ];
              plugins = [
                "https://plugins.dprint.dev/json-0.17.2.wasm"
              ];
            };
          };

Calling nix fmt then fails with /nix/store/r4r6inyjds6ac9s3jjg398hi52v8i7ip-dprint/bin/dprint: line 3: exec: dprint: not found
System information
This is on aarch64-darwin, but also occurs on other architectures.
my flake.lock entry is:
"treefmt-nix": {
      "inputs": {
        "nixpkgs": [
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified":<PHONE_NUMBER>,
        "narHash": "sha256-nnpCF/a5d0l68g/n4mAP+YUL+TxlYmmTK3HNzEy409Y=",
        "owner": "numtide",
        "repo": "treefmt-nix",
        "rev": "c1b28acff9d302b0924ee0d67c4a42d20eb11b28",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "treefmt-nix",
        "type": "github"
      }
    },

And my input is:
treefmt-nix = {
      url = "github:numtide/treefmt-nix";
      inputs.nixpkgs.follows = "nixpkgs";
    };

@gkze can you take a look since you introduced it in https://github.com/numtide/treefmt-nix/pull/73?
Something like this should fix it, but I don't have the environment to test it.
diff --git a/programs/dprint.nix b/programs/dprint.nix
index 0c64eec..54453b2 100644
--- a/programs/dprint.nix
+++ b/programs/dprint.nix
@@ -93,7 +93,7 @@ in
           configFile = mkConfigFile { config = cfg.config; };
           x = pkgs.writeShellScriptBin "dprint" ''
             set -euo pipefail
-            exec dprint --config=${configFile} "$@"
+            exec ${lib.getExe config.package} --config=${configFile} "$@"
           '';
         in
         (x // { meta = config.package.meta // x.meta; });

I got it working on my target repo with cfg.package, not sure how else I could test it


JsonObject polymorphism and avoid n+1 query

PR for #114
Introduced JsonResource which should be extended by all the Json entities of the API (Container, Image etc). This is for:

polymorphism (we will be able to have common iteration logic, for instance)
avoiding n+1 query problem.

Before this mechanism, the biggest issue was that the returned JsonObject (from the creation time) was not retained and thus, the client would have to call inspect() everytime they wanted some info about it, even data that can't be changed over time.

Job #115 is now in scope, role is REV

@llorllale I pulled quite a stunt here, have a look and let me know if something is not clear or if you have better suggestions. (let me know if it's more than 15min)
I had a user ask on the blog, about the first version of the library. He also said that he only needed local Docker + Container operations (which we almost have finished), so I would like to release 0.0.1 soon, maybe in the next 2 weeks :D

This pull request #115 is assigned to @llorllale/z, here is why; the budget is 15 minutes, see §4; please, read §27 and when you decide to accept the changes, inform @amihaiemil/z (the architect) right in this ticket; if you decide that this PR should not be accepted ever, also inform the architect; this blog post will help you understand what is expected from a code reviewer

Pull Request Test Coverage Report for Build 181

10 of 35 (28.57%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 85.373%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/main/java/com/amihaiemil/docker/JsonResource.java
5
30
16.67%

Totals

Change from base Build 177:
0.04%

Covered Lines:
286

Relevant Lines:
335

💛  - Coveralls

@amihaiemil I'm wary of doing this because of the lose of semantics.
I'm not an expert with docker although I've used it. How many fields does a user typically need to read? For instance, take a look at this:
C:\> docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
alpine              latest              3fd9065eaf02        4 months ago        4.15MB

That is usually enough for most use cases. Of course, if you want more details you can always just docker inspect alpine and read off of that returned json.

@llorllale It seems the most elegant to me. The user will be able to do the following:
for(Container c : docker.containers()) {
    System.out.println(c); //pring the whole Container json
    System.out.println(c.getString("State"));//print only the State from the Json.
}

This is the chill part of everything, I was actually taking into consideration to make Containers and the other plurals implement JsonArray somehow... but I dropped that idea :))

@amihaiemil that looks ok.
What I was trying to get at earlier is that I prefer having actual getters for fixed stuff if there's not too many of them.
So for example in the case of docker images above I'd have let's say:
interface Image {
    String repo();
    String tag();
    String id();
    Instant created();
}

The advantage I see in this is that we would be providing users with the semantics for commonly-read attributes of an Image, as reflected in the common usage of the docker CLI.
This can of course be enhanced with your proposal living side-by-side ("for extra/more advanced inspection, use the inspect() method").

@llorllale I see what you mean now.
I was thinking to let those "animators" for the client to implement, not us. I would simply expose JsonObject and let them animate it, so we don't have to worry that, in the future, the Docker API will change the format of the returned JsonObject.
We could implement Smart classes, though. That's a better approach: we don't animate the whole Json, but instead we offer comodity, "smart" methods to fetch the most read attributes, which are also highly unlickly to change.
It would be very similar to jcabi-github, we would have Image.Smart img = new Image.Smart(image)). WDYT?

@amihaiemil ok then

@rultor merge

@rultor merge

@llorllale Thanks for your request. @amihaiemil Please confirm this.

Order was finished: +15 point(s) just awarded to @llorllale/z

The job #115 is now out of scope

Payment to ARC for a closed pull request, as in §28: +10 point(s) just awarded to @amihaiemil/z

@0crat extra 30min @llorllale


Log records can be stored in wrong order

Hello,
I've found that log records could come in wrong order sometimes.
Suppose we have one ingestor and 2 forwarders (A and B), store node is offline at the beginning. If for example, ingestor will save two segments, one - from A in time range 2-5 and second - from B in time range 3-6. Than if we start store, it will start fetching segments and appending them to "active" (Consumer.active in the code). This buffer will have records in time range 2-5-3-6 and these records will never be reordered if I understood code correctly. So as a result  we'll see query output like:
default aaaaaaaaa 2018-06-13T18:07:11+03:00 foo 000000197 G
default aaaaaaaaa 2018-06-13T18:07:11+03:00 foo 000000198 J
default aaaaaaaaa 2018-06-13T18:07:11+03:00 foo 000000199 F
default bbbbbbb 2018-06-13T18:07:09+03:00 foo 000000150 T
default bbbbbbb 2018-06-13T18:07:09+03:00 foo 000000151 N
default bbbbbbb 2018-06-13T18:07:09+03:00 foo 000000152 S

I suppose this behaviour in not expected, so maybe it need to be fixed.
I would be very grateful to someone who'll clarify it.

I want all log records to be sorted by time. Now sometimes you can get wrong order, like in example above:
default aaaaaaaaa 2018-06-13T18:07:11+03:00 foo 000000199 F
default bbbbbbb 2018-06-13T18:07:09+03:00 foo 000000150 T

If you replace this line https://github.com/oklog/oklog/blob/master/pkg/store/consume.go#L223 by return c.replicate all segments will be merged by mergeRecords with establishing global order, so all lines in query output will be sorted.

But in line https://github.com/oklog/oklog/blob/master/pkg/store/consume.go#L208 you provide only one reader to mergeRecords function, so it won't sort records and will just append new segment to existing buffer.

mergeRecords takes the current set of records (c.active) and the new records to merge in to them (readResp.Body). The records are sorted by mergeRecords.

Sorry, but I don't understand, how it can modify c.active. mergeRecords takes io.Writer as its first argument, you can only append data to bytes.Buffer using this interface. All records in c.active will remain unchanged.
Here is comment for mergeRecords:
// mergeRecords takes a set of io.Readers that contain ULID-prefixed records in
// individually-sorted order, and writes the globally-sorted output to the
// io.Writer.


ng test errors out with "Unexpected string" after upgrade to Angular CLI 6

I have an Angular 5 project that I updated to use Angular 6/Angular CLI 6. Now, though, when I run my tests with ng test --watch=false, I get this error several times:
HeadlessChrome 66.0.3359 (Mac OS X 10.13.4) ERROR
  {
    "message": "Uncaught SyntaxError: Unexpected string\nat src/test.ts:1:8\n\nSyntaxError: Unexpected string",
    "str": "Uncaught SyntaxError: Unexpected string\nat src/test.ts:1:8\n\nSyntaxError: Unexpected string"
  }

Versions
Angular CLI: 6.0.3
Node: 9.11.1
OS: darwin x64
Angular: 6.0.3
... animations, cli, common, compiler, compiler-cli, core, forms
... http, platform-browser, platform-browser-dynamic
... platform-server, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.6.3
@angular-devkit/build-angular     0.6.3
@angular-devkit/build-optimizer   0.6.3
@angular-devkit/core              0.6.3
@angular-devkit/schematics        0.6.3
@angular/cdk                      5.2.5
@ngtools/webpack                  6.0.3
@schematics/angular               0.6.3
@schematics/update                0.6.3
rxjs                              6.2.0
typescript                        2.7.2
webpack                           4.8.3

karma.conf.js
const baseConfig = (config) => ({
  basePath: '',
  frameworks: ['jasmine', '@angular-devkit/build-angular'],
  plugins: [
    require('karma-jasmine'),
    require('karma-chrome-launcher'),
    require('karma-jasmine-html-reporter'),
    require('karma-coverage-istanbul-reporter'),
    require('karma-mocha-reporter'),
    require('@angular-devkit/build-angular/plugins/karma'),
    require('karma-webdriver-launcher')
  ],

  client: {
    clearContext: false // leave Jasmine Spec Runner output visible in browser
  },

  files: [
    {pattern: './src/test.ts', watched: false}
  ],

  mime: {
    'text/x-typescript': ['ts', 'tsx']
  },

  angularCli: {
    environment: 'dev'
  },

  coverageIstanbulReporter: {
    dir: require('path').join(__dirname, 'coverage'), reports: ['html', 'text', 'text-summary'],
    fixWebpackSourcePaths: true
  },

  reporters: config.angularCli && config.angularCli.codeCoverage
    ? ['mocha', 'coverage-istanbul']
    : ['mocha', 'kjhtml'],

  customLaunchers: {
    ChromeDebugging: {
      base: 'Chrome',
      flags: [ '--remote-debugging-port=9333', '--auto-open-devtools-for-tabs', 'http://localhost:9876/debug.html' ]
    },
    ChromeHeadless: {
      base: 'Chrome',
      flags: [
        '--headless',
        '--disable-gpu',
        '--no-sandbox',
        // Without a remote debugging port, Google Chrome exits immediately.
        '--remote-debugging-port=9222',
      ],
    }
  },

  port: 9876,
  colors: true,
  logLevel: config.LOG_INFO,
  autoWatch: false,
  browserNoActivityTimeout: 60000,
  browsers: ['ChromeHeadless'],
  singleRun: false,
  concurrency: Infinity,
  refresh: true
});

test.ts
import './polyfills.ts';

import 'zone.js/dist/long-stack-trace-zone';
import 'zone.js/dist/proxy.js';
import 'zone.js/dist/sync-test';
import 'zone.js/dist/jasmine-patch';
import 'zone.js/dist/async-test';
import 'zone.js/dist/fake-async-test';
import { getTestBed } from '@angular/core/testing';
import { BrowserDynamicTestingModule, platformBrowserDynamicTesting } from '@angular/platform-browser-dynamic/testing';

// Unfortunately there's no typing for the `__karma__` variable. Just declare it as any.
declare const __karma__: any;
declare const require: any;

// Prevent Karma from running prematurely.
__karma__.loaded = function() {};

// First, initialize the Angular testing environment.
getTestBed().initTestEnvironment(BrowserDynamicTestingModule, platformBrowserDynamicTesting());

// Then we find all the tests.
const context = require.context('./app/', true, /\.ts/);

// And load the modules.
context.keys().map(context);

// Finally, start Karma to run the tests.
__karma__.start();

@joeattardi Did you close this issue because you solved it? I'm running into the same problem, could you share your solution?

I generated a new application project via ng generate application and just copied everything from test.ts and karma.conf.js in the generated project. That seemed to fix the issue for me.

Ah, thanks. I'll give that a shot!

Generating a fresh project and using the karma.conf.js from that solved it for me too. Much obliged!

Had that issue too, it was because this line in my karma.conf.js  :
{
...
files: [
{ pattern: './src/test.ts', watched: false },
...
}

@SaydChada have you found any documentation of this change? What have you dont with the file './src/test.ts'


Deprecated QuickStart - 404 error code

It looks like Subaru finally deprecated remoteEngineQuickStartSettings ... Will verify when I get a chance to check the App.
RequestInfo(url=URL('https://mobileapi.prod.subarucs.com/g2v21/service/g2/remoteEngineQuickStartSettings/save.json'), method='POST'

Correction it looks like they have advanced to /g2v24 .. Testing a change

g2v24 imposed some changes to the JSON fields that the Subaru API returns. I think I've taken them all into account in the v0.7.0 branch. v0.7.0rc0 has been published to PyPI.

Tested Looks like its working on my two models. 👍


⚠ Bofrost.at has degraded performance

In 066669c, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1720 ms

Resolved: Bofrost.at performance has improved in 9fe3175.


[Bug]: Multiline paragraph returns with full JSON and Error

Bug Description
Multiline paragraph returns with full JSON and Error.
Relevant Screenshot

To Reproduce

Write a multiline paragraph
select-all text
use Writing assistant to repharse
full JSON with error returns

Debugging Log
[16:33:12.986] Logging Started...
[16:33:20.844] Writing Assistant[Hotkey] Processing complete
[16:33:20.854] Writing Assistant[Hotkey] Passing output 'Hi,

This is a Multi-line paragraph.

Im goin to Rephrase it with Writing Assistant by Chris Grieser.

Cheers' to Post Notification
[16:33:20.857] Writing Assistant[Post Notification] Processing complete
[16:33:20.859] Writing Assistant[Post Notification] Passing output 'Hi,

This is a Multi-line paragraph.

Im goin to Rephrase it with Writing Assistant by Chris Grieser.

Cheers' to Run Script
[16:33:22.339] ERROR: Writing Assistant[Run Script] execution error: Error: SyntaxError: JSON Parse error: Unterminated string (-2700)
[16:33:22.346] Writing Assistant[Run Script] Processing complete
[16:33:22.348] Writing Assistant[Run Script] Passing output 'ERROR: OpenAI response: {
  "id": "chatcmpl-9v2zBqC*CEN*0n",
  "object": "chat.completion",
  "created": 172*CEN*201,
  "model": "gpt-4o-2024-05-13",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hi,

This is a multi-line paragraph.

I'm going to rephrase it with Writing Assistant by Chris Grieser.

Cheers",
        "refusal": null
      },
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 83,
    "completion_tokens": 25,
    "total_tokens": 108
  },
  "system_fingerprint": "fp_3aa7262c27"
}
' to Replace
[16:33:22.349] Writing Assistant[Replace] Processing complete
[16:33:22.351] Writing Assistant[Replace] Passing output 'ERROR: OpenAI response: {
  "id": "chatcmpl-9v2*CEN*0n",
  "object": "chat.completion",
  "created": 17*CEN*01,
  "model": "gpt-4o-2024-05-13",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hi,

This is a multi-line paragraph.

I'm going to rephrase it with Writing Assistant by Chris Grieser.

Cheers",
        "refusal": null
      },
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 83,
    "completion_tokens": 25,
    "total_tokens": 108
  },
  "system_fingerprint": "fp_*CEN*"
}' to Copy to Clipboard

Workflow Configuration

Checklist

[X] I have updated to the latest version of this workflow.
[X] I am using Alfred 5. (Older versions are not supported anymore.)

Fixed.
Available in the Alfred Gallery in 1-2 days, or directly by downloading the latest release here: https://github.com/chrisgrieser/alfred-writing-assistant/releases/download/1.4.0/alfred-writing-assistant.alfredworkflow