[cassandra] Update CassandraCQLClient to use PreparedStatement for better performance

Addressing issue #458. The PreparedStatement is created and cached following the same approach as in JdbcDBClient. Here are the numbers before and after the use of PreparedStatement:
Apache Cassandra version: 3.11.1, replication_factor = 3, QUORUM consistency level
Server: 3-node Google Cloud Platform (GCP) n1-standard-16 machine, 16 VCPU's, 60GB memory, 2 x 375 GB direct attached SSD
YCSB parameter: recordcount=1000000, operationcount=10000000, maxexecutiontime=90
Before:
Workload   : Throughput(ops/sec) - OpType & AverageLatency(us)
workload a : 64956.256567473 - [READ]: 4282.700504426243 [UPDATE]: 3346.0443676539962
workload b : 63345.63794747335 - [READ]: 3949.758514786955 [UPDATE]: 3189.5031351661996
workload c : 64365.03672249063 - [READ]: 3849.324261325788
workload d : 66134.2080457653 - [READ]: 3777.5643821626963 [INSERT]: 3162.619993576045
workload e : 7939.354223757893 - [INSERT]: 16607.25331648768 [SCAN]: 31967.764074558985
workload f : 42042.92384862897 - [READ]: 4218.613333769682 [READ-MODIFY-WRITE]: 7568.5240789843865 [UPDATE]: 3351.4569375155224
After:
Workload   : Throughput(ops/sec) - OpType & AverageLatency(us)
workload a : 74710.34153952844 - [READ]: 3762.9415808058598 [UPDATE]: 2873.006871596396
workload b : 70607.19238937287 - [READ]: 3542.8850799849365 [UPDATE]: 2852.0433860133608
workload c : 72872.62719944527 - [READ]: 3399.9530996221742
workload d : 80464.90059049785 - [READ]: 3111.0480158195774 [INSERT]: 2492.7417853628635
workload e : 8376.560197625033 - [INSERT]: 15429.41884128906 [SCAN]: 30362.55064932235
workload f : 43846.903949293024 - [READ]: 4074.0924531425676 [READ-MODIFY-WRITE]: 7230.656645026845 [UPDATE]: 3152.440234449529
Also changed the update() method to use Cassandra UPDATE statement. While it may not matter to YCSB, there are subtle semantic and on-disk differences between INSERT and UPDATE statements so changing to use the statement type that matches the action taken.
Suggestions and comments are welcome.

@robertpang Could you please review #930 ?

@cricket007 Reviewed #930 with feedback.

A gentle reminder. May I ask for a review? Thanks.

I'd say your PR is more focused than #930. You only concern yourself with the core workload value for readallfields=true. You therefore aren't reading fieldcount from the properties, nor do you care about checking fields.size() in any of the methods. Only insert & update use values.size().
Because of this, I still don't think your codes are very different from #930. If you only focus on this conditional.
     if (readallfields || fields == null) {
        ps = statement;
      }

In #930, there is no re-creation of any INSERT (therefore UPDATE), or DELETE. Only value binding. Sure, if there is no such operation being done, I agree the query doesn't need pre-prepared. If you would like to add that functionality, you can PR against my branch.
You implement update, which I’m fine with implementing as well. You mention differences with INSERT for TTL and non-key fields to null, which I’m not even sure YCSB does that. At least when all the fields are used by default.

I think we can minimize the changes just preparing the statements on-demand and caching them as they are issued … This way the code will be more concise

The same amount of changes are required, whether if done in init, or the operation body, no?
You mention concerns about duplicative QueryBuilder calls. Taking your delete method as an example, you are re-building that query for every call to that method. Matter of fact, I see you kept the QueryBuilder in each of the operations. I think this code would be better if you prepared the statements once per YCSB Client. That is why they were moved into init. It is only in the case where readallfields != true && fields.size() > 1 when the QueryBuilder is required to build the dynamic queries based , which again, isn’t tested with the core workloads. Speaking of tests, you may want to add unit tests for preparing statements.
Additionally, I think trace should be enabled before the debug block. Not sure if any extra information for the query would be printed in the debug in that case, but printing the bound query only prints it with the bind markers, not the bound values.

@cricket007
I'd say your PR is more focused than #930. You only concern yourself with the core workload value for readallfields=true. You therefore aren't reading fieldcount from the properties, nor do you care about checking fields.size() in any of the methods. Only insert & update use values.size().

Thanks for your review. I think there is a misunderstanding. My PR does not assume any specific workload. That is the reason why it does not depend on any of the core workload properties. On the other hand, your PR #930 depends heavily on those properties and pre-prepares the statements in init() specifically for core workload. For other 3rd-party workloads, say one that updates 2 fields in one UPDATE statement (possible by writing their own Java class instead of using CoreWorkload.java), PR #930 will fall back to preparing the statement on-the-fly. So your PR is essentially special-casing for core workloads.

I think we can minimize the changes just preparing the statements on-demand and caching them as they are issued … This way the code will be more concise

The same amount of changes are required, whether if done in init, or the operation body, no?

I am unsure about that by comparing the code changes in #930 and #1051.

You mention concerns about duplicative QueryBuilder calls. Taking your delete method as an example, you are re-building that query for every call to that method. Matter of fact, I see you kept the QueryBuilder in each of the operations. I think this code would be better if you prepared the statements once per YCSB Client. That is why they were moved into init.

I gave your approach of pre-preparing the statements in the init() call some consideration. In order to avoid special-casing for core workload like your PR #930 does, it will require pre-preparing all possible combinations of fields in SELECT, SCAN and UPDATE which is not a good idea. I am unsure if special-casing is right or how much additional performance gain there by preparing in init() vs. on-demand.

Speaking of tests, you may want to add unit tests for preparing statements.

Actually the existing YCSB tests for database bindings should cover that sufficiently because the prepared statements will be exercised identically by the existing tests.

@cricket007
Taking your delete method as an example, you are re-building that query for every call to that method. Matter of fact, I see you kept the QueryBuilder in each of the operations.

I updated my PR to avoid rebuilding query in each call to look up the prepared statement. I will resist pre-preparing the statements init() call just for the core workload but leaving other workloads behind. In typical perf tests, the workloads will be run sufficiently long that will amortize the statement preparation overhead. Also, there is already an existing feature request for warm-up step and PR #423 that implements it. I think a warm-up step is a better solution and the right thing to do in general.

I agree a warm up step makes sense. Without knowing what the reported YCSB time is truly supposed to track, having the operation metrics collecting the time for preparing a statement, even if just once, personally doesn't seem to be beneficial. Especially when there are a few extra  cycles to build a query, then check if it exists.
It's fair to say I'm not actively committed to maintaining #930 - and as stated in there, it's a subset of changes pulled out of #98 anyway, so I don't take full ownership of the changes applied or feel too sentimental about the logic for whether or not the queries are pre-prepared. It just doesn't make sense to me to use the QueryBuilder any more than necessary.
The efforts on improving cassandra performance  from #98 was two years ago, and #930 was stalled because I moved off a Cassandra project, but now this one exists... My point is that the idea is all the same. We just want PreparedStatements. I don't think it's a competition about whose PR is the most feature complete, or smallest diff, or even runs the fastest... I therefore don't know if it makes sense to have conflicting PR's.
I was curious if you'd attempted to run #930 on your own Cassandra installation, and let us know your runtime observations. I'd say it's only fair since I've attempted to run this code on mine.
Good news, though, after restarting my cluster and ensuring my run operation count is the same as the load count, I get no longer get failures for any of the workloads
In any case, do you have the metrics before and after you've avoiding rebuilding the query?

In any case, do you have the metrics before and after you've avoiding rebuilding the query?

To get relatively stable results, I reran YCSB for both cases for comparison:
With "rebuilding of query string" each time:
Workload  : Throughput(ops/sec) - [OpType]: AverageLatency(us)
workloada : 75162.94490492443 - [READ]: 3712.1089108339993 [UPDATE]: 2888.704308151015
workloadb : 67909.13129211901 - [READ]: 3689.397479301242 [UPDATE]: 2940.169769332547
workloadc : 69994.59330610122 - [READ]: 3545.0229683819425
workloadd : 80389.16570982907 - [READ]: 3112.1529029615385 [INSERT]: 2576.228139670966
workloade : 9139.419222017554 - [INSERT]: 16478.908145375284 [SCAN]: 27726.20359205211
workloadf : 42685.014031399995 - [READ]: 4214.090543587963 [READ-MODIFY-WRITE]: 7408.185535755213 [UPDATE]: 3191.565620861078
Avoiding "rebuilding of query string" each time:
Workload  : Throughput(ops/sec) - [OpType]: AverageLatency(us)
workloada : 75513.54220835501 - [READ]: 3673.8378600034207 [UPDATE]: 2892.9287559957697
workloadb : 69190.1279509431 - [READ]: 3620.280420324173 [UPDATE]: 2893.411130372632
workloadc : 70800.90139868474 - [READ]: 3503.7249451185417
workloadd : 81300.8949273007 - [READ]: 3077.658212308622 [INSERT]: 2543.7350429854373
workloade : 9118.100530873942 - [INSERT]: 16500.140610961367 [SCAN]: 27720.53545060734
workloadf : 42777.93789412096 - [READ]: 4207.477092418291 [READ-MODIFY-WRITE]: 7391.952508237535 [UPDATE]: 3182.462351490101
There is marginal improvement by avoiding rebuilding the query string but it could be within the margin of "noise". I will say the use of prepared statements produces the most noticeable improvement and the rest is much less significant.

@cricket007 I had a chance to run your changes and here are the results:
Workload  : Throughput(ops/sec) - [OpType]: AverageLatency(us)
workloada : 74418.30454850802 - [READ]: 3734.5562832495884 [UPDATE]: 2930.176013898976
workloadb : 69482.58862789287 - [READ]: 3604.6540608078462 [UPDATE]: 2900.3556340663317
workloadc : 71126.4640554743 - [READ]: 3486.99938534114
workloadd : 78548.23786875833 - [READ]: 3183.6267052581443 [INSERT]: 2635.479023040199
workloade : 9188.244087920182 - [INSERT]: 16515.41342873389 [SCAN]: 27551.95483939809
workloadf : 42633.837918666766 - [READ]: 4202.9597725177655 [READ-MODIFY-WRITE]: 7435.345286571684 [UPDATE]: 3228.3594059627408
As yo can see, the numbers are very similar. Therefore, the benefits of pre-preparing the statements in init() specially for core workload in your PR is negligible but it marginalizes other non-core workloads. In any case, I think it is better for the database bindings to stay workload-agnostic for it to be useful generally.

A gentle reminder again. May I ask for a review and approval to merge? Thank you.

@busbey ^^

Another gentle reminder again. May I ask for a review and approval to merge? Thank you. @busbey ??

@cricket007 and @robertpang should reviewers be checking this issue as well as #930? Or just one of them?
I'll work through these. To set expectations my time is currently very restricted (on the order of 1 hour a week); it'd be faster if another maintainer could take a look.

Thanks @busbey
I think we've determined both branches work, just a different methodology about how PreparedStatements should be maintained.
To sum up the differences,  #930 accounts for the readallfields attribute and adds an additional debug method to print the statement with its values, which makes for a larger diff. It also does not accommodate the UPDATE query of Cassandra, which there seems to be a few undocumented features about how it differs from an INSERT.

I think we've determined both branches work, just a different methodology about how PreparedStatements should be maintained.

So we'll have to pick one or the other, correct?

Unfortunately, or merge the non conflicting changes

@busbey Thanks for your review. Yes, both PR #930 and #1051 work. I have used #1051 successfully to benchmark Apache Cassandra (results here).
Apart from implementing UPDATE properly, my goal in #1051 is to keep the code change concise for easy review and merge. I avoided accounting for the readallfields attribute because it complicates the statement preparation and my tests show only very little benefits.

Hi there,
I can testify that we've been running this branch under heavy load multiple times on multiple platforms (GCE, AWS) and it's very stable. I hope it will get merge to master as soon as possible, especially since it passed all of the checks.
Dor (@Scylladb)

Thanks, @dorlaor.
Hi @busbey and other YCSB maintainers, just pinging again for the approval to merge. The use of PreparedStatement is crucial to us and others to get meaningful YCSB performance numbers against a Cassandra datastore. And as Dor @scylladb and us @yugabyte have used this branch to run YCSB benchmark against our own products successfully, we will be grateful if we can merge it into the master soon.
Thank you.

Hi @busbey and other YCSB maintainers, just pinging yet again for the approval to merge. This PR has been ready for merge for 4 months and we will appreciate if someone can review and give the approval soon. Thank you.

+1 for the need and I can attest it works fine
On Mon, Mar 26, 2018 at 12:27 PM, Robert Pang<EMAIL_ADDRESS>wrote:

Hi @busbey https://github.com/busbey and other YCSB maintainers, just
pinging yet again for the approval to merge. This PR has been ready for
merge for 4 months and we will appreciate if someone can review and give
the approval soon. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/brianfrankcooper/YCSB/pull/1051#issuecomment-376283109,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABp6RdXdU5lvbI_8ItpO-ZRIy8-5zXCxks5tiUEOgaJpZM4P-h2z
.

Hi @robertpang!
Brief status update: this is in my review backlog. I get the level of improvement and I want to see the Cassandra binding improved as much as anyone else does. I appreciate the level of effort that's come in thus far on getting prepared statements for cassandra ready and reviewed.
It looks like I started a review back in November before my dev time went to 0 for ~3 months for personal reasons. IIRC, when I last looked at things there were two different approaches to adding prepared statement support for the Cassandra bindings and the two authors didn't have consensus on which to use. That means I have to review both of them and then make a call on one, the other, or a merge of the two.
ATM, my priorities for what time I have on the project are centered on picking up the stale release cadence. (#981 tracks the 0.13.0 release, which has been in RC status since Jul 2017. Our last stable release was December 2016.)
Things that will help me review this faster:

The two authors coming to consensus on a single PR that they both agree is the best way forward for YCSB (because then I only have to evaluate and iterate on 1)
Folks reviewing gaps on the 0.13.0 RC (even though that release is going to go out this week, I've essentially just punted the test backlog to the 0.14.0 RC that will start shortly)
Folks reviewing open PRs for things that can easily land in the 0.14.0 RC
Folks reviewing open issues for things that might be blockers for the 0.14.0 RC

Any of those free up time from me (and any other maintainer who comes around with some time to invest), which makes it more likely we have time to spend on getting this merged.

If Scylla and others in the Cassandra space are throughly testing this PR, then I'll let this continue on here and close my branch.

Thanks, @cricket007. Appreciate it.
@busbey and other YCSB maintainers, appreciate your time and attention on this. We can now move forward with one PR (this). I will be here for any questions regarding this PR.

Hey guys, any progress? We just have folks who want to run YCSB and I push them elsewhere since there are no prepared statements in the master branch

The two authors coming to consensus on a single PR that they both agree is the best way forward for YCSB (because then I only have to evaluate and iterate on 1)
Folks reviewing gaps on the 0.13.0 RC (even though that release is going to go out this week, I've essentially just punted the test backlog to the 0.14.0 RC that will start shortly)
Folks reviewing open PRs for things that can easily land in the 0.14.0 RC
Folks reviewing open issues for things that might be blockers for the 0.14.0 RC

so far it looks like the first of my bullet points got done. Thanks for that everyone.
0.13.0 went out and #1117 covers the upcoming 0.14.0 release. Unfortunately, we still don't even have a solid enumeration of the testing needed there.
How about this: I'll prioritize getting this merged into master prior to the 0.14.0 release moving forward so long as someone commits to the needed cassandra testing for 0.14.0 RCs. any takers?

@busbey What do Cassandra tests involve and how frequent do you foresee them to be?

@busbey are you referring to these tests:
https://github.com/brianfrankcooper/YCSB/blob/master/cassandra/src/test/java/com/yahoo/ycsb/db/CassandraCQLClientTest.java
We tested this branch under non stop traffic at rate of multiple 100k ops (multiple ycsb processes and threads) and in parallel to several other databases what had their own load.

when we do a release we include the tested/supported state of each datastore binding (the docs on "writing release notes" in our release manager guide) should polly go into more detail.
basically, they're all listed as "experimental and untested" unless a) someone tests running them against a live instance and documents specific versions and instructions followed (preferably the README from the binding) or b) someone has previously done testing against a live instance and nothing for the specific binding has changed since then.
See, for example, the release notes for v0.12.0 and the sections "tested datastores" vs "untested datastores". Compare to comments on  issue #873, where folks stated that they had tested the various things.
How often this testing is needed depends on how often we put up RCs and how often the code changes. our last tested release was 0.12.0 in December 2016. my goal is to get us back on a regular cadence and hopefully it would be more frequent than once every 18 months.
Cassandra hasn't been in the tested-for-release group since v0.8.0 in April 2016. I'd love to see that change, which is why I'd be willing to delay 0.14 further to make it happen.

@busbey Thanks for explaining. As so, I will be glad to volunteer to do the testing for Apache Cassandra. I had run YCSB against Apache Cassandra on Google Cloud Platform a couple of times recently (see https://forum.yugabyte.com/t/ycsb-benchmark-results-for-yugabyte-and-apache-cassandra-again-with-p99-latencies/99) and will have no problem with that. After all, that is how I came to add support for prepared statements in the data binding and submit this PR for it to be included in YCSB.
While on this, I would like to ask to include our @YugaByte DB as a tested datastore for YCSB also. We support Apache Cassandra client driver and therefore its existing data binding works identically for us also. Will that be ok?

We test workloads of 1 billion keys (1TB-3TB) with this branch and
everything seems rock solid. Let us know what you wish
we should focus on.
YCSB Commands - Scylla (x8 YCSB clients) - Population: #nohup
~/YCSB/bin/ycsb load cassandra-cql -p hosts=[IPs] -p recordcount=1000000000
-p insertstart=0 -p operationcount=1000000000 -p insertcount=125000000 -p
cassandra.writeconsistencylevel=QUORUM -s -P workloads/workloada -threads
50 > 1load_scylla_1TB &- Workload A (uniform): #nohup ~/YCSB/bin/ycsb run
cassandra-cql -p hosts=[IPs] -p recordcount=1000000000 -p insertstart=0 -p
operationcount=125000000 -p insertcount=125000000 -p
cassandra.writeconsistencylevel=QUORUM -p
cassandra.readconsistencylevel=QUORUM -p maxexecutiontime=5400 -s -P
workloads/workloada -threads 35 > 1scylla_1TB_workloada &Workload A
(zipfian): #nohup ~/YCSB/bin/ycsb run cassandra-cql -p hosts=[IPs] -p
recordcount=1000000000 -p insertstart=0 -p operationcount=125000000 -p
insertcount=125000000 -p cassandra.writeconsistencylevel=QUORUM -p
cassandra.readconsistencylevel=QUORUM -p maxexecutiontime=5400 -s -P
workloads/zipfian_workloada -threads 40 > 1scylla_1TB_zipfian_workloada &
On Fri, Apr 27, 2018 at 4:47 PM, Robert Pang<EMAIL_ADDRESS>wrote:

@busbey https://github.com/busbey Thanks for explaining. As so, I will
be glad to volunteer to do the testing for Apache Cassandra. I had run YCSB
against Apache Cassandra on Google Cloud Platform a couple of times
recently (see https://forum.yugabyte.com/t/ycsb-benchmark-results-for-
yugabyte-and-apache-cassandra-again-with-p99-latencies/99) and will have
no problem with that. After all, that is how I came to add support for
prepared statements in the data binding and submit this PR for it to be
included in YCSB.
While on this, I would like to ask to include our @YugaByte
https://github.com/YugaByte DB as a tested datastore for YCSB also. We
support Apache Cassandra client driver and therefore its existing data
binding works identically for us also. Will that be ok?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/brianfrankcooper/YCSB/pull/1051#issuecomment-385120597,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABp6RQogz0di7Yv7Dta77jzp1dCfhfsRks5ts64UgaJpZM4P-h2z
.

While on this, I would like to ask to include our @YugaByte DB as a tested datastore for YCSB also. We support Apache Cassandra client driver and therefore its existing data binding works identically for us also. We have done a couple of test runs above to confirm that and can do another run. Will that be ok?

Yeah that sounds fine. IIRC we've had commercial vendor offerings listed before.

Any progress here?

@busbey Sorry for the delay as I was occupied with a major release. The couple of suggestions look good and take care of them right away.

Hi @busbey,
You can find the change with your comments fixed here: https://github.com/haaawk/YCSB/tree/i458
Best Regards,
Piotr (@scylladb)

Thanks, @haaawk for incorporating @busbey's feedback. I have pulled in your changes.
@busbey Thanks for your feedback. If all looks good in the latest changes, would you please approve and merge this PR? I can run the Apache Cassandra and @yugabyte tests for 0.14.0 once merged.

Rebased master with upstream and fixed the logger.info() call. Please let me know if more updates are needed in this PR.

Just waiting on the Travis build. Thanks for pushing on this!

@busbey Thanks for accepting and merging the PR. I will test 0.14.0 against Apache Cassandra and @yugabyte once the release staging branch is cut.


LibreOffice Spreadsheet crashes while try to set border to cell(s)

Version: <IP_ADDRESS>.0+
Build ID: 00m0(Build:2)

Could we have more details:
What LO versions crash? What architecture (i686 or amd64)? What channel are you using? Does it matter what borders to set? I ask because I tried with the latest master (<IP_ADDRESS> LibreOffice) and a random border for a random cell worked fine.

Could we have more details:
What LO versions crash? What architecture (i686 or amd64)? What channel are you using? Does it matter what borders to set? I ask because I tried with the latest master (<IP_ADDRESS> LibreOffice) and a random border for a random cell worked fine.

amd64
nix-env -iA nixos.pkgs.libreoffice
libreoffice-<IP_ADDRESS>
Where you get <IP_ADDRESS>?

amd64
nix-env -iA nixos.pkgs.libreoffice
libreoffice-<IP_ADDRESS>
Where you get <IP_ADDRESS>?

amd64
nix-env -iA nixos.pkgs.libreoffice
libreoffice-<IP_ADDRESS>
Where you get <IP_ADDRESS>?

This is the version in NixPkgs git master.
It has not been built by Hydra, though. A pity. So for now the only way
to get it is to build it.
If you have some disk space to spare, you can get a one-click install
from http://hydra.nixos.org/build/29628063 (<IP_ADDRESS>)
Some <IP_ADDRESS> is also in unstable channel.
I am currently downloading <IP_ADDRESS> from cache…

amd64
nix-env -iA nixos.pkgs.libreoffice
libreoffice-<IP_ADDRESS>
Where you get <IP_ADDRESS>?

This is the version in NixPkgs git master.
It has not been built by Hydra, though. A pity. So for now the only way
to get it is to build it.
If you have some disk space to spare, you can get a one-click install
from http://hydra.nixos.org/build/29628063 (<IP_ADDRESS>)
Some <IP_ADDRESS> is also in unstable channel.
I am currently downloading <IP_ADDRESS> from cache…

Got /nix/store/94ix7j27fzp26i72vc3bdz06py5gxm7v-libreoffice-<IP_ADDRESS> from Hydra, set a random border, doesn't crash for me (amd64, Intel i7)

Got /nix/store/94ix7j27fzp26i72vc3bdz06py5gxm7v-libreoffice-<IP_ADDRESS> from Hydra, set a random border, doesn't crash for me (amd64, Intel i7)

I think your system libs different that my..
for example my glibc is 2.21
(gdb) backtrace
#0  0x00007f160f220cc8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0
What version of your glibc?

I think your system libs different that my..
for example my glibc is 2.21
(gdb) backtrace
#0  0x00007f160f220cc8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0
What version of your glibc?

I have multiple. Well, what is the path to your LibreOffice? Maybe I can
get the exact same closure from cache…
I think when I ran LibreOffice from 15.09 release, it got glibc 2.21.
/nix/store/r5kd93xi2pwpycaj1jlimfgzrhslyryl-glibc-2.21 to be precise.
I do hope the problem is not about video driver difference (there are
two actually global things: session like DBus etc., as I am on
not-exactly-NixOS, and video stack where rolling back is some amount of
hassle, although unlike NixOS I can try rebuilding and running a second
X11 session).

(gdb) backtrace
#0  0x00007f160f220cc8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0
#1  0x00007f16106c013e in osl_waitCondition () from /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-<IP_ADDRESS>/lib/libreoffice/program/libuno_sal.so.3
#2  0x00007f16106c79a8 in osl_joinProcessWithTimeout () from /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-<IP_ADDRESS>/lib/libreoffice/program/libuno_sal.so.3
#3  0x0000000000406257 in sal_main_with_args ()
#4  0x00000000004033ca in main ()
I am not guru, but can suggest to you get binded libraries by gdb:
$ soffice --calc &
[1] 10190
$ gdb --pid=10190
About the video driver...May be it's idea..For example, now the Firefox has some artifacts on the toolbar icons. The web pages renders correctly as I see and other apps also correctly. I seen before like that when try to switch an acceleration(SNA) from UXA method on the other distros.
Now SNA(i915) is enabled, so, I will try to switch to UXA.

(gdb) backtrace
#0  0x00007f160f220cc8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0
#1  0x00007f16106c013e in osl_waitCondition () from /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-<IP_ADDRESS>/lib/libreoffice/program/libuno_sal.so.3
#2  0x00007f16106c79a8 in osl_joinProcessWithTimeout () from /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-<IP_ADDRESS>/lib/libreoffice/program/libuno_sal.so.3
#3  0x0000000000406257 in sal_main_with_args ()
#4  0x00000000004033ca in main ()

This is the segfault backtrace for setting the border? I hoped there
would be more hints about what went wrong…

I am not guru, but can suggest to you get binded libraries by gdb:
$ soffice --calc &
[1] 10190
$ gdb --pid=10190

strace -f -s 9999 -o /tmp/log /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-<IP_ADDRESS>/bin/scalc

I can see very well that
/nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libc.so.6
gets opened, yes.
Still doesn't change the behaviour.

About the video driver...May be it's idea..For example, now the Firefox has some artifacts on the toolbar icons. The web pages renders correctly as I see and other apps also correctly. I seen before like that when try to switch an acceleration(SNA) from UXA method on the other distros.
Now SNA(i915) is enabled, so, I will try to switch to UXA.

I have SNA and i915. Not artifacts in Firefox, though.

Hm, your mentioning toolbars reminded me that I have a relatively narrow LibreOffice window by default and don't see the entire toolbar.
Reproduced the crash by using the toolbar button (previously I only tried borders via cell formatting)
scalc --backtrace seems to give a nice backtrace via gdb. Will try to understand whether it is a unique problem now…

OK, there is a very similar upstream problem, and an alleged fix for it is included into our LibreOffice build, and still <IP_ADDRESS> crashes in the same place.

It's my imperfection that I did't give complete path to reproduce.
We had waste time, sorry.

It's my imperfection that I did't give complete path to reproduce.
We had waste time, sorry.

You could reasonably expect that I would not have the crucial button
just behind the edge of the window…
What surprises me is that apparently the problem is slightly different
from the problem recently fixed in upstream… At least with <IP_ADDRESS>,
where it should have been fixed.

(triage) has this been fixed @danykey @7c6f434c?

My impression is that current LibreOffice-still (which is from the next branch) lacks this problem. Can you reproduce it now. @danykey ?


Regnal year fencepost

The year in which an Emperor dies - is it the last year of their reign, or the first of their successors?

Answer - it's both, but I'm leaving it as-is for now: the year in which the emperor takes the throne is the first of his reign


is this project out of maintain or what?

no code commit sinec 2 years ago?

You can check on JanusGraph.
http://janusgraph.org/
more details: https://www.google.com.tw/search?q=janusgraph+titan

thanks. so we can close this issue.


Sample instances are not cleared from the Playground when adding custom shapes.

I'm just getting acquainted with shaperone and want to thank you for you work on this project - it is extremely cool and fills a critical gap in the data-centric approach to model-driven UI. Truly, hats off to you!
I've been using the playground to manually add in a custom shape and the form generation is working beautifully, but when I look at the data captured by the form it only includes the sample instances that are of a different type than the target class that I'm defining:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix schema: <http://schema.org/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix vcard: <http://www.w3.org/2006/vcard/ns#> .

<http://example.com/Jane_Doe> a schema:Person ;
	schema:name "Janet" .

<http://example.com/John_Doe> a schema:Person ;
	schema:name "John Doe" ;
	schema:age 17 ;
	schema:knows [
		rdf:type schema:Person ;
	] ;
	<http://id.mazetx.com/mio/hasAttribute> <http://id.mazetx.com/mio/AmyotrophicLateralSclerosis> ;
	<http://id.mazetx.com/mio/digitalObjectIdentifier> "http://mygwasstudy.com"^^xsd:anyURI ;
	<http://id.mazetx.com/mio/pValue> "0.0000123"^^xsd:float ;
	<http://id.mazetx.com/mio/oddsRatioLow> ".1"^^xsd:float ;
	<http://id.mazetx.com/mio/oddsRatioHigh> ".4"^^xsd:float ;
	<http://id.mazetx.com/mio/standardError> ".09"^^xsd:float .

Is there a way to clear out the sample instances and provide my own initial instance(s) that match the target class for the node shape I'm defining?

@tpluscode do you recommend sticking with the playground here or are there other examples where I could get started with a simple app?

Sure, here is a link to the example I'm working on.
You'll notice that the IRI for the shape I define is http://example.com/GWASTraitAssociationShape, that the target class is http://id.mazetx.com/mio/GWASTraitAssociation, and that I don't include any sample instances data.
However, the data I enter into the form is rendered as properties attached to <http://example.com/John_Doe> a schema:Person ;...
What I was hoping to do is clear out all the triples from the schema:Person example so that the generated form data is a valid shape. So if I would expect to see something like:
_:b0 a <http://example.com/GWASTraitAssociationShape> ;
	<http://id.mazetx.com/mio/hasAttribute> <http://id.mazetx.com/mio/AmyotrophicLateralSclerosis> ;
	<http://id.mazetx.com/mio/digitalObjectIdentifier> "http://mygwasstudy.com"^^xsd:anyURI ;
	<http://id.mazetx.com/mio/pValue> "0.0000123"^^xsd:float ;
	<http://id.mazetx.com/mio/oddsRatioLow> ".1"^^xsd:float ;
	<http://id.mazetx.com/mio/oddsRatioHigh> ".4"^^xsd:float ;
	<http://id.mazetx.com/mio/standardError> ".09"^^xsd:float .

Or perhaps if I included an initial instance in my shape of <http://example.com/study1> a <http://example.com/GWASTraitAssociationShape> then the generated example would be
<http://example.com/GWASTraitAssociationShape> a <http://example.com/GWASTraitAssociationShape> ;
	<http://id.mazetx.com/mio/hasAttribute> <http://id.mazetx.com/mio/AmyotrophicLateralSclerosis> ;
	<http://id.mazetx.com/mio/digitalObjectIdentifier> "http://mygwasstudy.com"^^xsd:anyURI ;
	<http://id.mazetx.com/mio/pValue> "0.0000123"^^xsd:float ;
	<http://id.mazetx.com/mio/oddsRatioLow> ".1"^^xsd:float ;
	<http://id.mazetx.com/mio/oddsRatioHigh> ".4"^^xsd:float ;
	<http://id.mazetx.com/mio/standardError> ".09"^^xsd:float .

Does that make sense?

Sorry for coming back late. As it happens, I initially misunderstood you question. 🤦
You're right to observe that the usage is not perfect regarding the graphs and how the resources and shapes are selected for the form.
That said, you can always clear or modify the data graph yourself. However, that still keeps the URI information and I notice in your case that it prompts recreates that John_Doe resource with a blank trait. You can get around that but it's awkward at best
Please see what I just pushed. A small change, so that when you clear the right hand side editor


Everytime I get .nvm/nvm.sh: line 62: syntax error near unexpected token `}'

On mac os x, in .bash_profile, everytime I get .nvm/nvm.sh: line 62: syntax error near unexpected token `}'

What did it end up being?

In fact, I found that the issue was because the file .bash_profil where I put
export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
... was using UNIX LF. To remove the error, you have to setup Unicode UTF-8 and Windows CRLF.
Would be great to have this working without having to setup bash_profile with these parameters! A.

I'm confused; why would bashrc - a linux file - use anything but LF?
Certainly a mix of line endings would break things, glad you figured it out.

I was wrong. In fact, I figured out what causes the issue: in bash_profile, there is the alias "alias fi='sudo find . -iname'"
When I remove it, it works!

I don't know much about POSIX, but did you reproduce locally ?

Yes, I definitely reproduced it locally.
Using \fi doesn't fix it, so I'm really not sure how it would be possible to address inside nvm.

Same issue. Just restarted the iTerm fixed it.

Also had aliased Linux keyword do -- changed docker alias to d and re-sourced the entire thing which worked!
If you're having issues check you're not aliasing Linux keywords.


Failed to list new CRDs when using informer and lister

What happened:
Now clusternet failed to list CRDs when using informer and lister. When we add new crd instances, the lister could not list the new instances.
What you expected to happen:
Our informer should behave like what Kubernetes does.
How to reproduce it (as minimally and precisely as possible):

Create a new foo object in sample-controller repo.
Run this demo.

package main

import (
	"flag"
	"net/http"
	"time"

	"github.com/clusternet/clusternet/pkg/wrappers/clientgo"
	"k8s.io/apimachinery/pkg/labels"
	"k8s.io/client-go/tools/clientcmd"
	"k8s.io/klog/v2"

	// Uncomment the following line to load the gcp plugin (only required to authenticate against GKE clusters).
	// _ "k8s.io/client-go/plugin/pkg/client/auth/gcp"

	clientset "k8s.io/sample-controller/pkg/generated/clientset/versioned"
	informers "k8s.io/sample-controller/pkg/generated/informers/externalversions"
	"k8s.io/sample-controller/pkg/signals"
)

var (
	masterURL  string
	kubeconfig string
)

func main() {
	klog.InitFlags(nil)
	flag.Parse()

	// set up signals so we handle the first shutdown signal gracefully
	stopCh := signals.SetupSignalHandler()

	cfg, err := clientcmd.BuildConfigFromFlags(masterURL, kubeconfig)
	if err != nil {
		klog.Fatalf("Error building kubeconfig: %s", err.Error())
	}

	// This is the ONLY place you need to wrap for Clusternet
	cfg.Wrap(func(rt http.RoundTripper) http.RoundTripper {
		return clientgo.NewClusternetTransport(cfg.Host, rt)
	})

	exampleClient, err := clientset.NewForConfig(cfg)
	if err != nil {
		klog.Fatalf("Error building example clientset: %s", err.Error())
	}

	exampleInformerFactory := informers.NewSharedInformerFactory(exampleClient, time.Second*30)
	lister := exampleInformerFactory.Samplecontroller().V1alpha1().Foos().Lister()
	// notice that there is no need to run Start methods in a separate goroutine. (i.e. go kubeInformerFactory.Start(stopCh)
	// Start method is non-blocking and runs all registered informers in a dedicated goroutine.
	exampleInformerFactory.Start(stopCh)

	for {
		fooList, err := lister.List(labels.Everything())
		if err != nil {
			klog.Fatalf("Error listing foos: %s", err.Error())
		}
		klog.Infof("Foo list size: %d", len(fooList))
		for _, foo := range fooList {
			klog.InfoS("List contains foo", "foo", klog.KObj(foo))
		}
		time.Sleep(5 * time.Second)
	}
}

func init() {
	flag.StringVar(&kubeconfig, "kubeconfig", "", "Path to a kubeconfig. Only required if out-of-cluster.")
	flag.StringVar(&masterURL, "master", "", "The address of the Kubernetes API server. Overrides any value in kubeconfig. Only required if out-of-cluster.")
}

The demo will list 1 foo. Then we create a new foo, the lister still print there are 1 foo in clusternet. The new one could not be listed.

Anything else we need to know?:
Environment:

Clusternet version:

Clusternet-agent version (user clusternet-agent --version=json): v0.11.0
Clusternet-hub version (user clusternet-hub --version=json): v0.11.0

Kubernetes version (use kubectl version):
Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Others:

Fixed by #433


[Draft] Replace cached time with system clock in MasterService debug logs

Description
Cached Time gives imprecise duration in computing multiple computation time since it caches every 200ms and multiple operation in MasterService regarding cluster state creation, update, publish require time frames less than 200ms during debugging. So changing the computation time to consume System.nanotime() to get clock time instead of cached time. This is essential when debug logs are enabled - else this is not logged by default.
Before:
[2023-05-31T11:38:34,142][DEBUG][o.o.c.s.MasterService    ] [master1] took [0s] to compute cluster state update for [index-aliases]
[2023-05-31T11:38:34,307][DEBUG][o.o.c.s.MasterService    ] [master1] took [0s] to notify listeners on successful publication of cluster state (version: 55109, uuid: Fc58ns6mRHCNuxcvADvfOg) for [index-aliases]
[2023-05-31T11:38:32,416][DEBUG][o.o.c.s.MasterService    ] [master1] took [0s] to compute cluster state update for [cluster_reroute(reroute after starting shards)]
[2023-05-31T11:38:32,416][DEBUG][o.o.c.s.MasterService    ] [master1] took [0s] to notify listeners on unchanged cluster state for [cluster_reroute(reroute after starting shards)]
[2023-05-31T11:38:34,307][DEBUG][o.o.c.s.MasterService    ] [master1] took [0s] to notify listeners on successful publication of cluster state (version: 55109, uuid: Fc58ns6mRHCNuxcvADvfOg) for [index-aliases]

After:
[2023-06-02T12:28:49,551][DEBUG][o.o.c.s.MasterService    ] [master1] took [2ms] to notify listeners on unchanged cluster state for [index-aliases]
[2023-06-02T13:10:17,855][DEBUG][o.o.c.s.MasterService    ] [master1] took [93ms] to compute cluster state update for [index-aliases]
[2023-06-02T13:10:47,875][DEBUG][o.o.c.s.MasterService    ] [master1] executing cluster state update for [index-aliases]
[2023-06-02T13:10:47,876][DEBUG][o.o.c.s.MasterService    ] [master1] took [0s] to compute cluster state update for [index-aliases]
[2023-06-02T13:10:47,877][DEBUG][o.o.c.s.MasterService    ] [master1] took [0s] to notify listeners on unchanged cluster state for [index-aliases]
[2023-06-02T13:34:24,247][DEBUG][o.o.c.s.MasterService    ] [master1] took [0s] to notify listeners on successful publication of cluster state (version: 60931, uuid: G8fs82mZROGv4C0ufnehKA) for [index-aliases]

Related Issues
Resolves https://github.com/opensearch-project/OpenSearch/issues/7849
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff
[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Looks like some tests are failing?

We should change ClusterAplplierService class as well.
https://github.com/opensearch-project/OpenSearch/blob/aa2158555c7fea440d8de80b939a8c646aa5d415/server/src/main/java/org/opensearch/cluster/service/ClusterApplierService.java#L715

I would want us to double click on this to see if we really need this accuracy. Based on my understanding we are simply using this for debugging. What are the actionable items if these numbers stack around few seconds lets say.

@Bukhtawar Given the frequency of these logging/actions, we should not be causing any regression in performance. Since the default cluster manager election timeout duration is 500ms, majority of these Cluster State updates are expected to be of the order of ms only.
We might be over-precise in time computation for actions spanning over seconds, but that should be okay if it is not causing any performance regression. Thoughts?

IMHO we should show correct time over incorrect time unless it was a performance optimization, so +1 for this change.

@sandeshkr419 either way, could you please help iterate this to 🟢 ? thanks!

We should change ClusterApplierService class as well.
https://github.com/opensearch-project/OpenSearch/blob/aa2158555c7fea440d8de80b939a8c646aa5d415/server/src/main/java/org/opensearch/cluster/service/ClusterApplierService.java#L715

@shwetathareja Will check what are the time intervals here to see if we need to change here or not.

@shwetathareja Will check what are the time intervals here to see if we need to change here or not.

Applier thread is run after new state is published. Any new state has to be applied by the node for it to be usable. If any applier/ listener takes longer, it can cause over state application to take long. This also runs in single thread. There are multiple appliers and listeners that run in sequential order. If cluster state application takes in secs, we need accurate break down across those appliers and listeners. I am fine if you want to raise different PR. Please don't close the issue  https://github.com/opensearch-project/OpenSearch/issues/7849 though.

@andrross want to take a look at the updated version? much appreciated


Possibility to style markers with css hover

eventDiv_ (with 0.1 opacity) was overlaying labelDiv_, for this reason if you tried to style labelDiv_ with css :hover you didn't notice about the effect. You always was hovering eventDiv_. More info https://github.com/angular-ui/angular-google-maps/issues/1574#issuecomment-150467740
Closes #4
Breaking changes:  Events can't be captured even if the label is in the shadow of a google.maps.InfoWindow.

http://htmlpreview.github.io/?https://rawgit.com/IvanCoronado/running-statistics-from-Barcelona/master/dist/index.html#/
This project working with my PR version

I'm a little unclear as to what the problem is. In angular-ui/angular-google-maps#1574 I can see a link to a working application example, but not to a non-working version.
I can see the pulse on hover in this version, and I can see the rotation on hover in this version.
Both versions are using CSS styling by the looks of things.

@jesstelford
You can see the pulse in this version but hovering eventDiv_ wich always has 0.1 opacity (and you can't overwrite this property), we can't reach to labelDiv_ wich is the real label.
If you type console.log(document.getElementsByClassName("marker")) we get 12 markers (6 labelDiv_ and 6 eventDiv_ ).
The main problem is that evenDiv_ it's a clone of labelDiv_ with 0.1 opacity and has higher z-index, so you never touch labelDiv_ and hover css style are being applied about eventDiv_.
If you check this version with  console.log(document.getElementsByClassName("marker")) we get 6 markers, i removed the eventDiv_ so we can hover the labelDiv_.

Ah, ok, so you're saying that the pulse animation is not as expected because it has a 0.1 opacity?
That makes sense. I need to weigh this change up against the need to support the use-case it was designed for: ensuring labels correctly receive pointer events when behind a shadow.
We could also look at an alternative fix, ie; pollyfill pointer-events in oldIE, then apply that to the shadow, removing the need for this hack entirely.
I'll have a look when I get a bit more time.

Yes, you can't animate color because opacity.
El lun., 26 oct. 2015 0:13, Jess Telford<EMAIL_ADDRESS>escribió:

Ah, ok, so you're saying that the pulse animation is not as expected
because it has a 0.1 opacity?
That makes sense. I need to weigh this change up against the need to
support the use-case it was designed for: ensuring labels correctly receive
pointer events when behind a shadow.
We could also look at an alternative fix, ie; pollyfill pointer-events in
oldIE https://github.com/kmewhort/pointer_events_polyfill, then apply
that to the shadow, removing the need for this hack entirely.
I'll have a look when I get a bit more time.
—
Reply to this email directly or view it on GitHub
https://github.com/jesstelford/node-MarkerWithLabel/pull/5#issuecomment-150986431
.

I guess worst case (going against the intended design); could it be an optional behavior via options?


Add missing TMX tags

An user on Discord asked for the TMO cars' tags to be added, so I added every tag missing. Also fixed a typo with the Reactor tag
Proof of the changes working:

Thanks!


Fix cache error on read only system

Silently handle errors in the timezone-cache without stopping execution.
Add set_tz_cache_location() so user can provide alternative location, in case default not accessible.
Resolves issue #1107

@fredrik-corneliusson - would you mind porting these changes in base and utils into _TzCache?

Sure, but will probably not have time to work on it today.

@paulmcq Thanks for reviewing. But we are planning to merge in big changes from dev branch soon, so these particular review comments will be redundant.


Add dismissible notification when a model deployment fails

Closes: https://github.com/opendatahub-io/odh-dashboard/issues/1584
Description

How Has This Been Tested?

Test Impact

Request review criteria:

Self checklist (all need to be checked):

[ ] The developer has manually tested the changes and verified that the changes work
[ ] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

this PR isn't ready yet. Accidently raised. Hence closing it for now.


Custom formats for latex citation

I believe to be doing the right thing, but am not getting the right results upon running the command :Telescope bibtex format=CiteT. Here is what I have in the config:
      custom_formats = {
        {id = 'citet', cite_maker = '\\citet{%s}'}
      },
      -- Custom format for citation label
      format = 'citet',
      -- Format to use for citation label.
      -- Try to match the filetype by default, or use 'plain'

I have also tested it with cite_maker = '#%s#' or with parentheses but would only get the citation key alone instead of wrapped inside the citation command that I want to be added as well.
I have also tried the command :Telescope bibtex but still get \cite{KEY} instead of \citet{KEY} as desired. Any pointers would be much appreciated.

Thanks for posting about this issue. That seems like some sort of regression with telescope load-order. I tested it on my system and had the same issue. Which plugin manager are you using? I fixed the issue by removing the require"telescope".load_extension("bibtex") from the config section in lazy.nvim and put it bellow where I call telescope.setup(). Otherwise, the custom_formats table was empty upon initializing telescope-bibtex. I will adjust the README for that. Let me know if that works for you as well

Thanks for your response! I am using packer (for now) and would like to try to emulate what you suggest above. Right now I have this in my config file
local status_ok, telescope = pcall(require, "telescope")
if not status_ok then
  return
end

local actions = require "telescope.actions"

telescope.setup {
  defaults = {
  ...

  load_extensions = { "yank_history", "bibtex" },
  extensions = {
    bibtex = {
      depth = 1,
      -- Depth for the *.bib file
      custom_formats = {
        {id = 'citet', cite_maker = '\\citet{%s}'}
      },
      -- Custom format for citation label
      format = 'citet',
...

When you say 'put it below telescope.setup()' are you suggesting that I delete load_extensions = { "yank_history", "bibtex" }, from telescope.setup() and instead create a new block below like:
require"telescope".load_extensions = { "yank_history", "bibtex" }

I tried this but it gave me an error and as I'm sure you can tell, I'm not experienced enough to know what I'm doing wrong.
Thanks again for your help,
Ben

I didnt know you could have load_extensions in the telescope setup function... is that a new feature? But yes, I would suggest you remove "bibtex" there (you can keep "yank_history" there if it works) and then add require"telescope".load_extension("bibtex") (note singular) right below telescope.setup{}

I tried adding require"telescope".load_extension = { "yank_history", "bibtex" } after telescope.setup{}, but it only worked with the plural load_extensions. Otherwise I got the error:
packer.nvim: Error running config for telecope-bibtex.nvim: [string "..."]:0: attempt to call field 'load_extension' (a table value)

I noticed that it didn't care if load_extensions was plural when inside telescope.setup{}. It would pull up the Telescope search either way, but I'm still getting citations of the form acharya2017 instead of \citet{acharya2017} upon running the command :Telescope bibtex format=citet. Is there anything else you might suggest that I try?
Thanks for the help!

Don't use "= {...} after setup, you need to call the function: require"telescope".load_extension("bibtex")

I did some more testing and there seems to be a deeper issue with how the custom formats are set. I will look into this when I have the time, but for the next 2 weeks I cannot guarantee it. Thanks again for bringing this to my attention.

For now I pushed a quick fix so you can do :Telescope bibtex format_string=\\citet{%s} . I hope this helps somewhat.

Amazing, that works great! Thanks so much.


Fails on non-ASCII characters in SQL comments

Migration fails on German or Russian letters in SQL comments with this message:
pgmigrate.MalformedStatement: Non ascii symbols in file: migrations/V0005__initial_companies.sql, 'ascii' codec can't encode characters in position 447-451: ordinal not in range(128)
When comments are removed it works again.

Actually, it's not a bug, it's a feature :) We even have a test for that. Because generally it brings more problems than benefits.
But if you do really want it, you can workaround it in the following way.

Got that. It would be great to have it in documentation. I'll get back with PR for that soon.


Wind gauge "jumping" through N (0 degrees)

Hi,
When sailing due north, or very close, as the boat goes between 357 and 3 degrees, the moment it goes through 360/0 the Wind Gauge seems to be doing a full rotation it looks like it jumps. All the other times it's smooth. In contrast the Radial Gauge - Marine Compass works fine.

Can you share Kip and Browser specs that you are running please?
Thanks

Hi,
Thanks for the quick response.
I run Kip 1.3.0 on OpenPlotter 3 64-bit.
Browser: Chrome Version 111.0.5563.147 (and 112.0.5615.50). Both Official Build 64-bit on Windows 11.
Also in Chrome 111.0.5563.116 on Android 11.
Many thanks,
Yiannis

For some reason a fix was applied to wind angle/speed indicators but not the face plate. I'll fix it.
Do you find that the gauge of useful? Something's not 100% right  and trying to figure out what to adjust. I feel like there is too many things moving around but it's not visually clear what it means. Do you agree?
#Primary visual indicators goals

apparent wind angle to monitor jibe/tack proximity and maximum sail trim/speed
Apparent wind speed to indicate appropriate sail configuration (reefs and such)
how tight you are to Closed Hauled to optimize VMG

##Secondary

True wind speed and angle
Wind shifts

#Minimal widget config options
##Required for optimal Widget usage:

taking angle to reflect vessel specific Closed Hauled start ranges down to 70 degrees where Close Reach starts

##Advanced options

Could have wind strength to vessel specific Reef setup with a  visual indicator
real-time Closed Hauled adjustment following a polar map


DefaultValue(0) not populating in Swagger UI

Property in swagger UI left empty and if I marked field as required I should manually set value.
I kinda see what's happening but when I explicitly define that I want to see that value I believe it should be there.

[JsonProperty("offset")]
[DefaultValue(0)]
public int Offset { get; set; }

I could do with a little more information - perhaps some screenshots to fully understand your issue?

I could do with a little more information - perhaps some screenshots to fully understand your issue?

I defined default values on properties

But when I try it - field is empty and if it is required I have to define it manually every time.

I defined default values on properties

But when I try it - field is empty and if it is required I have to define it manually every time.

Technically, this issue should be posted to the swagger-ui project instead of Swashbuckle. However, I believe one could argue that the behavior you're seeing is correct.
The pre-populated values in the UI text boxes are client-side defaults, whereas the [DefaultValue] attribute states the server-side default. There's a subtle difference here that you need to take into account. The server-side default is the value that the server will assume if not explicitly provided by the client whereas the client-side default is merely the value that the client feels is most convenient to pre-populate for the user. For an optional parameter, pre-populating with the server-side default is kind of redundant - you may as well leave it blank as that's the value that the server will assume anyway. I expect this is exactly the rationale for the behavior you're observing.

Technically, this issue should be posted to the swagger-ui project instead of Swashbuckle. However, I believe one could argue that the behavior you're seeing is correct.
The pre-populated values in the UI text boxes are client-side defaults, whereas the [DefaultValue] attribute states the server-side default. There's a subtle difference here that you need to take into account. The server-side default is the value that the server will assume if not explicitly provided by the client whereas the client-side default is merely the value that the client feels is most convenient to pre-populate for the user. For an optional parameter, pre-populating with the server-side default is kind of redundant - you may as well leave it blank as that's the value that the server will assume anyway. I expect this is exactly the rationale for the behavior you're observing.

Basically I expected that answer, but sometimes it feels wrong

Basically I expected that answer, but sometimes it feels wrong


Raspberry Pi Compile Issue

sudo make -f Makefile.linux throws the error:
writeentropy.c: In function ‘readNumberFromFile’:
writeentropy.c:29:29: error: comparison is always true due to limited range of data type [-Werror=type-limits]

Fixed: like 28 of writeentropy.c, change:
char c;
to:
signed char c;

Thank you so much!!! This made everything work fine. I kept getting this error when it should be a simple compile command! (Maybe you were trying to follow the same tutorial/blog post? I officially owe you a beverage.

Fixed by https://github.com/leetronics/infnoise/pull/27

leetronics #27 has meanwhile been merged into master, so the issue should be fixed.


python37Packages.croniter: 0.3.37 -> 1.0.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python37Packages.croniter is: "croniter provides iteration for datetime object with cron like format"
meta.homepage for python37Packages.croniter is: "https://github.com/kiorky/croniter"
meta.changelog for python37Packages.croniter is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.0.1 with grep in /nix/store/5mn2gwxsykmmwc83si9bglba093vmpd8-python3.7-croniter-1.0.1

directory tree listing: https://gist.github.com/2e1885a06e2611725b96103fd81f6af8

du listing: https://gist.github.com/dde235f19c4000088a93b95ece6c994a

Rebuild report (if merged into master) (click to expand)

44 total rebuild path(s)

11 package rebuild(s)

11 x86_64-linux rebuild(s)
11 i686-linux rebuild(s)
11 x86_64-darwin rebuild(s)
11 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
apache-airflow
python37Packages.apache-airflow
python37Packages.croniter
python37Packages.privacyidea
python37Packages.python-miio
python38Packages.croniter
python38Packages.privacyidea
python38Packages.python-miio
python39Packages.croniter
python39Packages.privacyidea
python39Packages.python-miio

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/5mn2gwxsykmmwc83si9bglba093vmpd8-python3.7-croniter-1.0.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python37Packages.croniter https://github.com/r-ryantm/nixpkgs/archive/cc10ccea68975072a2fb553b3c730c7abea7d35f.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/5mn2gwxsykmmwc83si9bglba093vmpd8-python3.7-croniter-1.0.1
ls -la /nix/store/5mn2gwxsykmmwc83si9bglba093vmpd8-python3.7-croniter-1.0.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages failed to build:

apache-airflow (python37Packages.apache-airflow)
python37Packages.python-miio
python38Packages.python-miio
python39Packages.python-miio

6 packages built:

python37Packages.croniter
python37Packages.privacyidea
python38Packages.croniter
python38Packages.privacyidea
python39Packages.croniter
python39Packages.privacyidea

Maintainer pings
cc @costrouc for testing.

Was superseded by https://github.com/NixOS/nixpkgs/pull/117448


I found this in your repo

thank you for visiting our repo. We fixed the issue by saving that pic in our local file 👯 🤣


Determine whether or not we should squash the 11 commits we made fixing Travis

Commits between 6295e6879835d61f5a931171d94e3e6ef4e4ca58 and 7a864d414697928c5e5d849a73e5f572f9bafec2 added nothing other to the codebase and were intended to fix Travis. These should probably be squashed to keep our history clean but 6 releases were created within these commits and I'm unsure how this will affect Git / NPM if they are squashed.

Deciding against this, too late to clean up the history now.


update packages and use Node 12 (BREAKING CHANGE)

BREAKING CHANGE: update to Firebase v8

https://firebase.google.com/support/release-notes/js#8.0.0

Changes:

update packages (npm update)
update Firebase (npm i firebase@latest) -- BREAKING CHANGE
update checkout, upload artifact, and preview action versions
use Node 12 for builds as it's recommended for @grpc/grpc-js (Resolves #73)

npm ci now runs in ~20-30s instead of a few minutes

i.e. https://github.com/cusec/2021/runs/1378144049

see https://github.com/cusec/2021/issues/73#issuecomment-724478212 for more details

@gordonpn I recall you mentioning once that the npm installs started taking way longer on your machine once, this/#73 might be related to it if you're using Node 14? :thinking:


vbump sts to fix a couple table designer issues

This PR fixes #20950
This PR fixes #20838
https://github.com/microsoft/sqltoolsservice/compare/<IP_ADDRESS>...<IP_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 41.958%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
28913

Relevant Lines:
64017

💛  - Coveralls


Chapter 3 - Discrepancy between Book and GitHub Code

When working through the examples in Chapter 3, I copied the example code from GitHub for Chapter 3 (https://github.com/geerlingguy/ansible-for-devops/tree/master/orchestration).
I noticed that the IP addresses for the VMs don't match between the code on GitHub and the book.
Book:  <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>
GitHub:  <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>
This caused a minor hiccup when running the example from the book:
ansible app -b -a "service chronyd restart" --limit "<IP_ADDRESS>"
Also wanted to say thank you for the excellent book, I've been enjoying it a lot.

Submitted a PR (#521) for this.

I actually updated those IP addresses just recently due to some changes in Vagrant, requiring the new IP ranges. I haven't had time to publish an updated version of the book manuscript yet, but will hopefully do so early this year.


More gas oracles

Motivation
This adds the ProviderOracle that allows runtime selection between provider gas methods and gas oracles. Such runtime selection is very useful for building stacks that work on multiple chains, such as production and local test.
It also adds a default_for_chain constructor that looks at the chain_id and tries to build a sensible default. This is a bit proof-of-concept. It would be nice to add a builder pattern where you can provide api-keys.
Architecturally this all feels a bit off to me. ProviderOracle exists basically because GasOracle and Middleware overlap in functionality. The Provider implementation also does quite a bit of magic under the hood to get EIP1559 estimates. IMHO it would be cleaner if this was all done through something like GasOracle's. But simply factoring it out doesn't work because gas prices are required to sign transactions, and at least currently Provider provides a complete implementation. Makes me think the Middleware really should be broken up in separate parts relating to the transaction lifecycle (gas pricing, gas estimation, gas escalation, nonce, signing, broadcasting, monitoring, etc). (Also seems related to #592)

Solution

PR Checklist

[ ] Added Tests
[ ] Added Documentation
[ ] Updated the changelog

cc @oliver-giersch

Makes me think the Middleware really should be broken up in separate parts relating to the transaction lifecycle (gas pricing, gas estimation, gas escalation, nonce, signing, broadcasting, monitoring, etc). (Also seems related to https://github.com/gakonst/ethers-rs/issues/592)

This is not a bad idea, although it does prevent you from join'ing all the futures for gas price + gas estimation + nonce, which is a nice performance boost. Do you wanna drop any thoughts on the architecture in the issue?

(Think this needs some fixes around WASM)

I removed the default_for_provider function. It was constructing a reqwest client with timeout, which is not available on WASM, causing the build to fail. I split the LogQueryError out to it's own PR #1615 .


dlib::optional

This is work in progress.
This is inspired by Sy Brand's tl::optional repo and https://github.com/bitwizeshift/BackportCpp.git
I've tried a few different ways of doing things. For example, i didn't like using union but it turns out you can't use aligned_storage if you want things to be constexpr and direct initialization to work.
I have to say, this is an education in C++ initialization. It's laughable how complicated an object that is either active or None can be. C++ is so messed up. And yet, I love it

It's ready. I think it's a good addition

Sweet, I'll look in a bit :D

Sorry, not yet. Haven't forgotten though 😅

I quite like the .then() pattern, i.e. continuations. I wonder how hard it would be to enhance dlib::thread_pool so support continuations on tasks and combine them using free functions like when_all(), when_one(), when_seq(), or alternatively using &&, ||, >>. Then use another function wait() to wait for the task graph to complete.

I quite like the .then() pattern, i.e. continuations. I wonder how hard it would be to enhance dlib::thread_pool to support continuations on tasks and combine them using free functions like when_all(), when_one(), when_seq(), or alternatively using &&, ||, >>. Then use another function wait() to wait for the task graph to complete.

Yeah, depends on how heavy handed you want the implementation to be.  Like if every call to any of these functions spawned a new thread that just waited on the future(s) to be ready that's easy.  But something less heavyweight gets tricky fast.


Issues with references

It's possible to direct build, but planned build is not possible.

Ok, it seems manually deleting the entries of the items from the build file, seems to fix the issue.

It's because bushes, etc can't be build as a plan. It's a caught exception, though (thus it's a warning) ;) Otherwise it would stop building any other piece on that blueprint.

Ok, maybe I explained a little poorly. I can directly build, with such a plan, but I can not just plan it. The building simply does not get set. After removing the dandelions, it worked like a charm.

Can you provide your .blueprint file? I'll try to recreate the issue then.

https://gist.githubusercontent.com/elonmir/ec1130047a3e7cabd849fe0e756e1d07/raw/07f3f4cb5be71ec01880734045918ca1c0d6c787/Elonmir_Debug.blueprint
Here you go, can't upload directly, due file extension.

Hey, I think I found the culprit. Fixed it on the current "planhammer" branch. I might need to get this over to the master, but the current revamp on that branch is kind of huge. And I am on vacation for another two weeks or so. So, long story short, willfix - might take some time ;)

Great I could contribute, even if  not codewise... :D

Alright, I am back and this problem should be fixed with the version 0.9.5, out on nexus and thunder (and here on git ofc)

Awesome!


Firefox/Safari extraneous data on generated app

My generated app looks perfect on chrome, but displays the following unexpected data on safari and firefox in the same text font as the "Edit src/MyApp.js and save to reload" text.
:host{min-height:100vh;display:flex;flex-direction:column;align-items:center;justify-content:flex-start;font-size:calc(10px + 2vmin);color:#1a2b42;max-width:960px;margin:0 auto}:host > *{display:flex}header{width:100%;background:#fff;border-bottom:1px solid #ccc}header ul{display:flex;justify-content:space-between;min-width:400px;margin:0 auto;padding:0}header ul li{display:flex}header ul li a{color:#ccc;text-decoration:none;font-size:18px;line-height:36px}header ul li a:hover,header ul li a.active{color:#000}main{flex-grow:1}.app-footer{color:#a8a8a8;font-size:calc(12px + .5vmin);align-items:center}.app-footer a{margin-left:5px}

This can be viewed at
http://delmevideoplayer.s3-website-us-east-1.amazonaws.com/

If it helps, the same (or appearing same) page from a git clone of open-wc-starter-app does not have the above extra text in safari or firefox

npm list lit-html shows this in open-wc-starter-app that doesn't show this problem
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
└──<EMAIL_ADDRESS>
and this in the generated project that appears to be broken
├─┬<EMAIL_ADDRESS>│ └─┬<EMAIL_ADDRESS>│   └──<EMAIL_ADDRESS>deduped
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
└──<EMAIL_ADDRESS>

The fixed for this was already merged.


Expose Other File Attributes in url_pattern

Apart from table columns, currently filename, size, md5_hex, md5_base65, and sha256 are accessible in url_pattern of asset annotation. We should expose other file related attributes as well.
Since we are using javascript File API, apart from the attributes that are currently used we have access to "MIME type" and "last modified date", which we can expose.

last modified date cannot be added as it is being deprecated and not supported https://developer.mozilla.org/en-US/docs/Web/API/File/lastModifiedDate.


Universal on Apple Silicon

I checked the macOS CtrlLr executable and it is x86_x64 universal. It does not support ARM64.
This would be needed for Logic Pro running natively and not under Rosetta2

Hello, if you compile the code by yourlsef you can choose to compile it for M1 as well. It's easy if you follow the guide linked here
https://godlike.com.au/index.php?id=361


[Feature Request] Log user deletion

Using V8.4.2 (upgrade to 8.5.x crashes, bug submitted)
Having just had an issue where a user had vanished (as in no longer in the Users table), I was surprised that user deletions are not logged - at least I could find no log entry after deleting a test user.
Please can this important event be logged with the user id deleted and the user doing the deletion. Using IDs instead of names should allow it to comply with GDPR.

@Surefyre in the meanwhile you can use the event "on_user_delete" following this documentation: Hooking into Application Events and add a Log message there. (see also Basic Logging Examples)

Thanks dimger, I was thinking I might have to go that route in the meantime, appreciate the links!

User deletions are already logged in version 8.5


Stress Test - eventhub schema update to match chaos-mesh v2.1.5

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-servicebus


apply_chat_template got 'str' object is not callable

I got the following error when I tried to use LocalChatCompletions.
lm_eval --model local-chat-completions --tasks mmlu_pro_biology  --model_args base_url=http://localhost:8080/v1/chat/completions/model --write_out --log_samples --output_path ~/trtllm/lm_eval/output_820 --apply_chat_template --limit 50 --batch_size auto
Traceback (most recent call last):
  File "/opt/conda/envs/py310/bin/lm_eval", line 8, in <module>
    sys.exit(cli_evaluate())
  File "/home/ubuntu/lm-evaluation-harness/lm_eval/__main__.py", line 389, in cli_evaluate
    results = evaluator.simple_evaluate(
  File "/home/ubuntu/lm-evaluation-harness/lm_eval/utils.py", line 397, in _wrapper
    return fn(*args, **kwargs)
  File "/home/ubuntu/lm-evaluation-harness/lm_eval/evaluator.py", line 295, in simple_evaluate
    chat_template=lm.chat_template(apply_chat_template),
TypeError: 'str' object is not callable

Hi! Could you try adding a model  to the model args? It's required by the tokenizer. I'll also add a warning.

@baberabb Thank you for the response. The above command can work before. After the #2129 merged, I got the above error.

@lxning thanks for letting me know, I'm looking into it now

Hi @lxning, it should be fixed in #2235, can you check that branch and let know if that works for you?

@KonradSzafer I tested #2235, it works now. Thank you for the fixing.

@baberabb hi! I got the same problem when using vllm:
lm eval --model vllm \
  --model args pretrained=$(model name},tensor parallel size=$fGpUs per model}, dtype=${dtype},gpu memory \ utilization=0.9,data parallel size=0 \
  --tasks mmlu \
  --num fewshot 5 \
  --output path ${output path} \
  --fewshot as multiturn \
  --apply chat template \
  --batch size $fbatch size}

lm_eval
--model vllm
--model_args pretrained={model_name},tensor_parallel_size=2,dtype=auto,gpu_memory_utilization=0.8
--tasks kmmlu
--batch_size auto
--output_path results
--wandb_args project=lm_evaluation_harness
When I run it like this, I get the same error.

@Am1n3e A strange thing is that I evaluate the same model on GSM8K rather than MMLU, it can work:
lm_eval --model vllm \
    --model_args pretrained=${model_name},tensor_parallel_size=${GPUs_per_model},dtype=${dtype},gpu_memory_utilization=0.9,data_parallel_size=0 \
    --tasks gsm8k \
    --output_path ${output_path} \
    --num_fewshot 5 \
    --apply_chat_template \
    --fewshot_as_multiturn \
    --batch_size ${batch_size}

@AIR-hl Thanks. Can you confirm the SHA version of the lm-eval you are using?

@AIR-hl I think the error is triggered when one uses the evaluation tracker.
Can you add the following: "--wandb_args project=test"

@AIR-hl Thanks. Can you confirm the SHA version of the lm-eval you are using?

Sorry, I have made some confusion, the ca3d86d6b8dea86211ec60b93c3c026ce73c9d60 version can work, the latest version can't

Weighed in here, cc @Am1n3e : https://github.com/EleutherAI/lm-evaluation-harness/pull/2235#issuecomment-2305141292
Happy to discuss this further though!

I believe the root cause is this line which has not been fixed in #2235.


Fix MQTT build

putIfAbsent() is a ConcurrentHashMap method.

I see, this would fail with JDK 1.7, and pass with 1.8... I'm merging

I'd suggest using the ConcurrentMap interface for the declarations rather than using the ConcurrentHashMap type directly, otherwise you can introduce scenarios where binaries produced from source compiled with JDK 8 targetting JDK7 won't actually work on JDK7 even though it is legal source and would work if compiled using JDK7.

@gemmellr I actually thought it was using ConcurrentMap, I read it wrongly... I will change it

Makes sense, but the change @clebertsuconic made was to another field, not the one I changed, which shows that there's a bunch of this pattern going in this file as well as in the overall tree. PR #93 deals with a number of them if you like to have declarations that way.

@scop ouch! :) Good catch!


Exception "Could not read data from Mi Flora sensor" (FW: 2.6.5)

Hi,
first of all: great library! Thanks! Unfortunately, I am getting the error
$ python3 demo.py --backend bluepy poll "XX:XX:XX:XX:XX:XX"
Getting data from Mi Flora
FW: 2.6.5
Name: Flower care
Traceback (most recent call last):
  File "demo.py", line 99, in <module>
    main()
  File "demo.py", line 95, in main
    args.func(args)
  File "demo.py", line 30, in poll
    print("Temperature: {}".format(poller.parameter_value(MI_TEMPERATURE)))
  File "/home/abo/.local/lib/python3.5/site-packages/miflora/miflora_poller.py", line 141, in parameter_value
    raise BluetoothBackendException("Could not read data from Mi Flora sensor %s" % self._mac)
btlewrap.base.BluetoothBackendException: Could not read data from Mi Flora sensor XX:XX:XX:XX:XX:XX

Versions:
Python v3.5.2
miflora v0.5
btlewrap v0.0.4
bluepy v1.3.0
Xubuntu v16.04.6 LTS
Searching for devices gave me 4 which is correct:
sudo python3 demo.py --backend bluepy scan
Scanning for 10 seconds...
Found 4 devices: [...]

3 (white, international version) of those 4 are working fine, having FW v2.7.0. The fourth device seems to be the chinese version (not white) running FW v2.6.5.
Do you have any idea why this doesn't work? (Even) the Mi Home android app is able to retrieve the data so the device seems functional ...
If you need more information, please let me know! Thanks in advance!

Okay, solved! I've upgraded to firmware v3.1.9 (using the Flower Care android app) and voila:
Getting data from Mi Flora
FW: 3.1.9
Name: Flower care
Temperature: 16.2
Moisture: 17
Light: 336
Conductivity: 93
Battery: 99

:-)
Sorry for the noise!


Refactor manual error handling to use aws/dynamodb constants

In several spots we manually parse the error returned by the aws/dynamodb library. When possible we should use the officially provided constants
E.G. https://github.com/vsco/domino/blob/master/domino.go#L1622

Done.
i.e. https://github.com/vsco/domino/blob/master/domino.go#L367

🏹


block: create Fetcher interface

This PR introduces a block Fetcher interface that will encompass the behaviour necessary for the BlockService to get new blocks either directly from a Core node or from the Celestia network.
It also adds an implementation of Fetcher for the Core Client
TODO

[x] Add BlockService to Full node

Related to #25 and #26

re https://github.com/celestiaorg/celestia-node/pull/59#discussion_r710060177 @Wondertan -- because this channel is specifically to listen for new block events.


defining an array in simple scheme

hi, Im trying to define an array in simple schema, so I'm wondering if there is an special way to define arrays in Simple Schema, because I have tried several ways and always geting errors
emails: {
type: Array,
},
"emails.$": {
type: Object
},
"emails.$.address": {
type: String,
autoValue: function() {
return Meteor.uuid();
},
regEx: SimpleSchema.RegEx.Email
},
"emails.$.verified": {
type: String,
autoValue: function() {
return Meteor.uuid();
},
but meteor is returning this  error
W20160804-00:58:33.026(-5)? (STDERR) Error: Emails is required
W20160804-00:58:33.028(-5)? (STDERR)     at getErrorObject (packages/aldeed_collection2-core/lib/collection2.js:437:1)
W20160804-00:58:33.029(-5)? (STDERR)     at [object Object].doValidate (packages/aldeed_collection2-core/lib/collection2.js:420:1)
W20160804-00:58:33.033(-5)? (STDERR)     at [object Object].Mongo.Collection.(anonymous function) as insert
W20160804-00:58:33.038(-5)? (STDERR)     at server/stratup.js:20:20
W20160804-00:58:33.042(-5)? (STDERR)     at C:\Users\def1\probar\sprint_1.meteor\local\build\programs\server\boot.js:304:5
only if I use the  optional true, meteor didn't show the error but mongo neither return the array

Closing old issues. Please comment if this is still an issue and should be reopened.


Centralize run options (and their docs) better

for #30

@m-mohr  in this PR I move (among other things) the docs about individual process testing and related options to the root README.
any remarks or concerns from you?


Fixing find toolbar checkboxes not being accessible through keyboard

Fixes #6210
The tab index was set on the checkbox labels, rather than on the checkboxes themselves. It seems that Chrome assumed that the user wanted to interact with the checkbox related to the label, but Firefox and Internet Explorer made a literal assumption and had the user interact with the label.

/botio-linux preview

Thanks for the patch!


Updating hbase bulkload staging dir to /user/hbase

Updating hbase bulkload staging directory to '/user/hbase' so it can also be shared for both hbase bulkloading and mapred jobs run by hbase user.

Closing for cleanup. Feel free to reopen if this work gets picked up later on.


isErrorModel check for base models

fix #2957

:x: There is undocummented changes. Run chronus add to add a changeset or click here.
The following packages have changes but are not documented.

:x:@typespec/compiler

You can try these changes at https://cadlplayground.z22.web.core.windows.net/prs/2968/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/prs/2968/


Rendering the openAPI specs

It would be nice to have rendered versions of the API spec that you could directly link to.

@cholmes is using swaggerhub to host the api docs.
https://app.swaggerhub.com/apis/cholmesgeo/STAC-standalone/0.5.1
There is a link to it on the api readme, but it is hard to find if you don't know it is there. Maybe we should make that link more visible?
https://github.com/radiantearth/stac-spec/tree/master/api-spec
The link is in the Specification section.

Thanks, that's a great start, but for the current state in dev there is no generated version, right? It would make easier to share ideas and discuss things currently in work with partners, collegues and so. For openEO we use the CI to generate the docs and host them on Github Pages. Could that be an option here, too?

I'm definitely super happy for a CI generated doc site. I used swaggerhub as it was the quickest way to get what I wanted. I guess one thing is we'd need a location on the web - may make more sense after we have #25 implemented (I haven't been pushing on it since the core spec was more important, but I think it's getting closer to being a priority - once we have landsat and sentinel datasets implemented as STAC and on STAC Browser I think is when it'll bubble to the top of my list).
Definitely happy to have the link more visible. I had thought it was, but on my latest structure update I agree it's a bit buried - we can pull it out and put it at the top of the document. Until we have generated docs we should just use swaggerhub - ipdating the swaggerhub should be part of the release process and I do try to do it. May have to figure out how to let other people update it if others are going to help out on releases.

Hosting can be done by GitHub itself. Works quite good for openEO at least: https://open-eo.github.io/openeo-api/v/0.4.0/apireference/
I may be able to assist setting this up.

Has been solved: https://stacspec.org/STAC-api.html and https://stacspec.org/STAC-ext-api.html


Sass needs to be replaced as it is EoL

While installing breakpoint 2.7.1, I noticed that it installs sass. (https://github.com/at-import/breakpoint/blob/2.x.x/Gemfile#L4) and there is this deprecation warning:
Ruby Sass has reached end-of-life and should no longer be used.

* If you use Sass as a command-line tool, we recommend using Dart Sass, the new
  primary implementation: https://sass-lang.com/install

* If you use Sass as a plug-in for a Ruby web framework, we recommend using the
  sassc gem: https://github.com/sass/sassc-ruby#readme

* For more details, please refer to the Sass blog:
  https://sass-lang.com/blog/ruby-sass-is-unsupported

v3 was just released. I'm dropping support for Ruby Gems as Sass has moved over to the Node ecosystem. The latest version of Breakpoint fully supports Sass 1.25+


Support comma separated databases in backup

Is your feature request related to a problem? Please describe.
If there are multiple databases in the dbms we should be able to backup them.
Describe the solution you'd like
The backup helm values should take comma-separated databases and all can be backed up from a single cron
Describe alternatives you've considered

Deploy cron per database for backup
Currently, I am using self-developed helm chart which uses neo4j and gcs-fuse

Hi @shubham030
As per the documentation neo4j-admin does not support multiple databases via the --database option
https://neo4j.com/docs/operations-manual/current/backup-restore/online-backup/
However, if you want to backup all the databases you can just mention * in the values.yaml for the database field and all the databases will be backed up
Hope this helps.
Thanks
Harshit

We can definitely provide support for comma separated databases but that will be a workaround and not through neo4j-admin
Let me know if the * solves your problem

We want to selectively backup the database, so '*' won't solve the issue. As for the workaround right now that is what we are using like running the neo4j-admin database backup in a loop for all the comma-separated values.

Appreciate your reply @shubham030
Will take a look at this and get this implemented before next release.
Thanks for raising this feature request.

That sounds good, let me know if you would like any help on this.

This is completed for both v5 and v4.4.
Will be part of 5.10.0 and 4.4.22
https://github.com/neo4j/helm-charts/pull/198
https://github.com/neo4j/helm-charts/pull/199
https://github.com/neo4j/helm-charts/pull/200


Ensure there is at least one routing hint when creating invoice

This PR do a bit of refactor of the part adding the routing hints to the invoice.
The motivation for this was a real case when a user had private channels with a node that is not the lsp (same case as changing lsp after some channels were opened).
Creating an invoice for that user resulted without routing hints. The invoice returned from greenlight without routing hints and we didn't add routing hints because our previous logic only added hints for the current lsp and the user still didn't have a channel with the current lsp...
The logic here has been simplified to this:

If we need to open a channel the routing hints are only the lsp with the zero channel id
If we don't need to open a channel we:

use all private channels of the node to create the routing hints array (one channel per peer).
We add to the invoice only the routing hints for peers that don't exist already in the hints returned from gl.

In addition, before using the node api to create the invoice we check if the user has routing hint candidates (private channels) and if not we return an early error.

Fixed conflicts with main.


not assignable to 'undefined', instead of 'never'

🔎 Search Terms
"not assignable", "never", "undefined"
🕗 Version & Regression Information
4.3.5
'undefined' error instead of 'never' ; the value undefined is considered valid
4.4.4, 5.0.4
Expected behavior
5.1.6, 5.7.2
'undefined' error instead of 'never' ; the value undefined triggers the 'never' message
Nightly
not available when testing
⏯ Playground Link
https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true&ts=5.7.2#code/C4TwDgpgBAKlC8UCwAoKUDeUCGAuKAdgK4C2ARhAE4A0UZA-PgRAG5VQC+UAPqultkaFWVWmSakKlTgG5UqAMYB7AgGdgUYPjiIMfHPgAM1feKiHUHGUA
💻 Code
type T =
  { a: number, b?: never } |
  { a?: never, b: number };

const t: T = { //  Types of property 'b' are incompatible. Type 'number' is not assignable to type 'undefined'
  a: 0,
  b: 0
};

🙁 Actual behavior
Type 'number' is not assignable to type 'undefined' is not relevant, since undefined cannot be the type of the t[b].
🙂 Expected behavior
The error should be about type 'number' not being assignable to type 'never'.
It is correctly displayed if the value undefined is used (after the regression at least).
Additional information about the issue
No response

You might want to explicitly mention that this is a problem because you're using --exactOptionalPropertyTypes; otherwise undefined would be allowed and the error message wouldn't be misleading.


Ugly flicker when having suggested prompt

have a squiggle
open inline chat for it
the UI flickers when coming up

https://github.com/user-attachments/assets/7e235ce5-3c3f-4333-bde9-637b05bdccaf

@roblourens I believe the is the same underlying cause as https://github.com/microsoft/vscode-copilot/issues/5522. Drilling into this and it seems that setting follow up always triggers a layout with the "old" dimensions which isn't going fit. I believe that explains why the editor is looking so weirdly. It only gets very little height left
IMO setting follow up should only trigger a content heigh change event so that the owner can issue a relayout but should not attempt to relayout with the existing dimensions. (maybe unless the number of follow up has changed in which case the content height didn't change...)

tried this is a notebook and it felt very jittery still (but in a regular file it was fine) should I create a new issue for this? Seems to be due to the inline fix dialog getting placed in one spot then immediately moved
https://github.com/microsoft/vscode/assets/26030610/b6405e15-e6d3-4ac3-9814-49d82ed9d715


Feature request: Allow multiple mntdir devices.

I tried to add two mntdir devices to a lxd container, but the second overwrites the first.
lxc config device add srv01:files2 mntdir disk source=/media/MEDIEN path=media/MEDIEN
lxc config device add srv01:files2 mntdir disk source=/cdata path=cdata

It should be possible to add multiple dirs i think.

that's because you're using the same device name for both, "mntdir". So the second redefines the "mntdir" device entry, overriding it.
Instead:
lxc config device add srv01:files2 mntdir-media disk source=/media/MEDIEN path=media/MEDIEN
lxc config device add srv01:files2 mntdir-cdata disk source=/cdata path=cdata

Should work fine.

That works, thanks a lot!


HTTP instrumentation not fully working

When instrumentation is setup, the HTTP gem will emit two events:

start_request.http – containing the request
request.http – containing the response

However, webmock is preventing the request.http event from firing.
To see this, run:
require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'

  gem 'webmock', '3.8.3'
  gem 'http', '4.4.1'
  gem 'activesupport', '<IP_ADDRESS>', require: 'active_support/notifications'
end

include WebMock::API

ActiveSupport::Notifications.subscribe(//) do |event, _|
  puts event
end

client = HTTP.use(instrumentation: { instrumenter: ActiveSupport::Notifications.instrumenter })

client.get('http://www.example.com/')

WebMock.enable!

stub_request(:get, "http://www.example.com/")

client.get('http://www.example.com/')

This outputs:
start_request.http
request.http
start_request.http

Thanks @austinthecoder . I have checked and I indeed WebMock don't support instrumentation offered by http.rb yet.

Thanks @bblimke. In your opinion, is this a feature? I was thinking of it as a bug because it's preventing some existing functionality.
I'm unfamiliar with the internals of both HTTP and webmock, but I can take a stab at this. Any tips/ideas of where I should look first?

@austinthecoder many http library features need to be implemented in WebMock, and it's likely that support for HTTP.use has been added after the adapter for WebMock has been implemented, that's why I think of it as a new feature that needs to be added to WebMock, but it all depends on interpretation :) I guess it only breaks for stubbed requests and WebMock doesn't actually break this behaviour for real requests?
Anyway, I don't know how instrumentation support is implemented in http, but most likely some method that is normally invoked in http gem, which triggers request.http is not invoked in the implementation here https://github.com/bblimke/webmock/tree/master/lib/webmock/http_lib_adapters/http_rb
I appreciate you are willing to have a look at it.
Perhaps @ixti can suggest where to look?

Sorry, missed notification. Will take a look this weekend.


*: Don't use Error::description

Signed-off-by: Brian Anderson<EMAIL_ADDRESS>
What problem does this PR solve?
Problem Summary:
Remove all uses of Error::description. This method is deprecated in current versions of Rust. The next toolchain upgrade will spew warnings about it without this patch.
What is changed and how it works?
No errors define description, and no future errors should define description. The user-facing impact of this should be minimal - maybe a few error messages will change, probably for the better.
Related changes
Check List
cargo check
Release note

/merge

/merge

It doesn't look like the errors could be from my patch.

/merge

/merge

@breeswish PTAL

/merge

/merge

/merge
I'm trying to see whether the error is the same every CI run.

/merge


Crash with react-native-debugger

react-native-debugger packs Redux Devtools and when a component wrapped with withStatechart unmounts, an error will be thrown due window.__REDUX_DEVTOOLS_EXTENSION__.disconnect being unavailable.
Checking if the function is available should fix it: https://github.com/fernandofranca/react-automata/commit/b04b969bb89f2b76fa3038ab26740d932a2607d4?diff=split

Thank you very much @fernandofranca for opening this issue.
I'm not familiar with react-native-debugger, but the disconnect method should exist in __REDUX_DEVTOOLS_EXTENSION__  (as described in the docs).
I recommend you open an issue in that package's repo and help make the API fully compatible.
I hope this makes sense for you.

Just in case, if anyone needs a simple solution:
if (window.__REDUX_DEVTOOLS_EXTENSION__ &&
  !window.__REDUX_DEVTOOLS_EXTENSION__.disconnect){
  window.__REDUX_DEVTOOLS_EXTENSION__.disconnect = () => {}
}


Fix TrailingWhitespace reported position

This PR fixes #1979

Thanks for picking this up!
I just scrolled quickly over the changes. At first glance, I'd say that this is a nice fix.
I'll take a closer look at this PR tomorrow.


JetBrains: Issue with loading Cody Recipes

At first glance it's not related to our latest changes.
Manual Retry fixes issue.

Link to reporter message: https://sourcegraph.slack.com/archives/C059N5FRYG3/p1698955627508139

@exigow I'm closing this since it's old and recipes/commands seem to be working correctly.


User-defined type not defined

Iam Using Access 2013 and i get " Compile Error: User-defined type not defined " when i compile my code
on the following line of code from the Space:
" Public Function Specs() As SpecSuite "
I already added the reference to Microsoft Scripting Runtime.
Thanks

Me too

I fixed by
Importing For Windows-only, include a reference to "Microsoft Scripting Runtime"

@hohaidang


Add Uzbek latin and cyrill locales

Q
A

Bug fix?
no

New feature?
yes

BC breaks?
no

Related tickets
fixes #X, partially #Y, mentioned in #Z

License
MIT

Thanks @Itach1Uchixa


Update converters for driver v2

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: gingerwizard:x: Dale McdiarmidDale Mcdiarmid seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.