Restore event log replay functionality.

[Pull] the event log replay functionality out of v1.14 of Vere with the intention of it landing in v1.19.

1.14 was reverted due to some kind of corruption error but the error was from a different part of the release so the idea here is to extract the replay improvements from 1.14 and make a PR that just contains those

None of the meld/memory paging/printing stuff, just the replay.
Not this, for instance: https://github.com/urbit/urbit/pull/6159/files#diff-9b3877485f99b0b6591908d549b6ac16cf7e327e33d941018ca339e590622a47R648
Hmm, it seems to rely on automeld. Moving convo to issue.

_cw_play in main.c uses u3o_auto_meld and thus implicates the whole meld set of changes.

@belisarius222 what was actually causing the memory corruption issue?  It wasn't the meld stuff was it?

Automeld was added (ported) for that feature, specifically. On that branch / as of that pr, it wasn't used anywhere else.

What I'm worried about is that I'm going to inadvertently regress something. There are a lot of data structures with single elements added because of all the automeld and CLI options.
Git diffs don't work because the repo rearchitecture changed so many minor things as to be unwieldy.
Thoughts?
Example: the code I'm adding back in refers to gar_w in _u3e_pool.
https://github.com/urbit/urbit/blob/a7880717e3c77c21e185ffe52a4982b0b3bd52d1/pkg/urbit/include/noun/events.h#L45
So I have to add this back in, or I have to backtrace the entire logic for why it's not there now.
Include all of the guard page stuff as well then?

Here's the direct comparison:  https://github.com/urbit/vere/compare/urbit-v1.14-rc3...vere-v1.17
I've been working off of https://github.com/urbit/urbit/pull/6159/files to make changes thus far.

@sigilante what's the difference between the functionality you're referring to here and the functionality provided by the existing --replay-from NUMBER, --replay-to NUMBER, and --replay options?

@matthew-levan This restores the 1.14 replay stuff:

adds the play command, for improved replay of large event logs,
with automatic retry of bail:meme after pack (or meld with --auto-meld),
snapshot updates after errors or interruption (via ctrl-c), and
optional full replay (without editing files in the pier).

The git diff troubles should no longer exist; when we migrated repos, I ran git filter-repo on https://github.com/urbit/urbit to filter out non-runtime commits, which obviously rewrote a ton of commits. I forgot to push the tags, but I just pushed urbit-v1.14-rc3 now, which yields a much saner, 84-commit diff for you to work off of. I'll push the remaining urbit-* tags soon.

Much more manageable than the 600+ files, 90,000+ additions I was trying to filter against!

To confirm then: I do need to add back in the guard page stuff, since that is part of the changes the play command relies on.  @mcevoypeter

@belisarius222 says the guard page stuff isn't in scope, so I'll prepare a quick summary of where it's currently referred to in the play work and post for comment.

Basically:

u3_mars_play relies on u3m_save
u3m_save refers to u3e_fault
u3e_fault has a new prototype and refers as well to u3P.gar_w, the guard page
gar_w is added in events.h

The simplest solution is to make u3_mars_play not use u3m_save if possible.

Just call u3e_save() instead of u3m_save().

The current status is that the branch code correctly produces working fake ships etc.
Replay doesn't error but appears to hang.  No event replay logging is visible.  There's a _term_it_refresh_line function that I can use but isn't implemented in current develop.
The ship cannot be terminated in replay mode.  This may be due to terminal changes in Ctrl+C/Ctrl+Z handling.
./bazel-bin/pkg/vere/urbit play zode
loom: mapped 2048MB
boot: protected loom
live: logical boot
boot: installed 652 jets
--------------- bootstrap starting ----------------

boot: 1-4

--------------- bootstrap complete ----------------

---------------- playback starting ----------------

play: events 5-123

OK, that's a complete review against the 1.14 codebase, and removal of some extra demand paging bits that I leaked in.
Still hangs on the actual replay tho.

Huh.  Deleting the pier results in:

Regular behavior when the ship is booted (replay events)
Hanging behavior when the ship is just urbit played

It's playing some events (bootstrap) but not others???

What's does a debugger say it's doing when it's hanging? Can you get a backtrace?

It's cycling between allocate.c (u3a_celloc) and hashtable.c (_ch_node_git).  Ted is going to look over it with me this afternoon.

Are you on macOS? If so, there's an issue with -O3 -g on macOS that leads to a hang that sounds similar to yours. b16ada6baaccdce2a3dda78caf70b55d8dbbc28e removes -g when compiling on macOS.

No, it's not, and it looks like it is in fact playing back events but incredibly slowly.  (I left it for hours and it has the arvo kernel processing happening now.)

Nock being suddenly, shockingly slow means that jets aren't firing. You're properly setting u3o_hashless, which is the first thing I would've checked.  Nearly all of the 1.14 commits were from Joe so he should know what's important to cherry pick over to get the replay bits of it up and running.

I teach ASL tonight then I'll take a look at it first priority Thursday morning.  Ted and I got a lot of review through it and I'll follow up ASAP.

Wait.  This is my vanilla vere build.
urbit 1.18-9500da18fd
boot: home is nec
loom: mapped 2048MB
lite: arvo formula 2a2274c9
lite: core 4bb376f0
lite: final state 4bb376f0
boot: loading pill /home/neal/urbit/vere/solid.pill
boot: parsing %solid pill
loom: mapped 2048MB
boot: protected loom
live: logical boot
boot: installed 652 jets

Note that last line:  there should be 351 jets.  So something's wrong with my local bazel build.  Switching to chat to follow up on whether this is general (and needs another issue) or a local misconfiguration.

Obviously things "work"—ships are functional etc.—but since I'm trying to debug jets not firing this may be relevant.

OK, I've narrowed down the slow patch to u3m_soft_top, line
  if ( 0 == (why = (u3_noun)_setjmp(u3R->esc.buf)) ) {

_setjmp slowing things up in the replay?

Status as of now:

default replay (not with play command) appears to be normal
the SIGINT handler for play may not be registered somewhere it needs to be (Ctrl+Z doesn't actually kill it).
the jet situation is ambiguous, but I do know that some jets (like +add) are firing

The blocker is analyzing why _setjmp is so slow, which is beyond my current C.

Bigger picture:  why does urbit play look so different from _pier_play(), which is what triggers when the checkpoint is gone on a regular ship start?

Following up on the scenarios:

No checkpoint, slow replay.
Any checkpoint, fast (regular) replay.
Any checkpoint, forced (play -f) full replay, slow replay.

The place I checked next is in _cw_play, but ful_o isn't not set in one and set in the other, so I don't think it's this conditional changing anything.
  if ( c3y == ful_o ) {
    u3l_log("mars: preparing for full replay\r\n");
    u3m_init((size_t)1 << u3_Host.ops_u.lom_y);
    u3e_live(c3n, u3_Host.dir_c);
    u3e_yolo();
    u3m_pave(c3y);
    u3j_boot(c3y);
    u3A->eve_d = 0;
  }
  else {
    u3m_boot(u3_Host.dir_c, (size_t)1 << u3_Host.ops_u.lom_y);
  }

So what's making the difference in speed presumably arises from what's being done differently elsewhere.
The next place to focus in on is u3_mars_play.

re terminal output shenanigans: as of v1.17 u3l_log does not require trailing \r\n. Adding those in anyway will result in extraneous newlines/whitespace. Shoot me a dm if you're still seeing anomalous output outside of that. You shouldn't need to call any of the _term_* functions explicitly.

@Fang- since I may as well clean up some code while I have this pulled up, is there a reason to not change failure messages from fprintf to u3l_log?
For instance,
      fprintf(stderr, "mars: disk read meta fail\r\n");

Pretty sure everything that uses fprintf happens before the IO drivers have been initialized. u3l_log depends on the term.c driver.
u3l_log may fall back to doing fprintf anyway if the driver hasn't been initialized yet, but I'd just leave existing calls for what they are. There might be another reason why they're explicit fprintfs that I'm not aware of. (And the changes would be outside the scope of this PR anyway.)

~master-morzod and I went through this. He suspects that either the compiler jets are not firing for some reason or the hash table (memoization) "incomprehensibly slower." It's not clear why this would be the case given what's actually in this PR—it should either work or break in an obvious way. "Something strange is happening here."

@sigilante can you write up exact repro steps here for @mcevoypeter ? He'll take a look on Monday.

Clone the current i/157 branch.
Build it normally.
Boot a fakezod.
Scenario A:  rm -rf zod/.urb/chk/* && urbit zod—this should be a normal playback.
Scenario B:  rm -rf zod/.urb/chk/* && urbit play zod—this is very slow, and it seems to be in the compiler code.
Scenario C:  mv zod/.urb/chk/* zod/.urb/bhk, then boot the ship and do some things, then mv zod/.urb/bhk/* zod/.urb/chk && urbit play zod—this is a normal playback.
Scenario D:  As C except urbit play -f zod—this is a very slow playback.

Scenarios B and D are the odd ones.

Thanks, @sigilante. After playing around with this this morning, I'm not seeing anything that makes me think it's a build system issue, especially because normal replay works as expected. I'm going to comb through the diff between this branch and develop to see if anything jumps out at me and will update here later today.

I let the fakezod run the slow version all weekend, and it got through event 10.  I think it is the compiler jets failing to fire (for whatever reason).

Update from the sync, @barter-simsum is testing replay from live -> release to make sure regular replay still works post doccords.

Boot a comet
Do some stuff, delete the chk, run a replay (test using what's currently on the live network).
Confirm that works
Install soon channel binary via next (put soon in pace file in .bin and .run next)
|ota ~marnec-dozzod-marzod - this will install the pre-release 415 arvo
Delete the comet's chk
Run a replay
Confirm that works

The goal is to confirm regular replay is fine post doccords (and is working on the current live network too).

Replay works. Vere binary pulled from edge rather than soon and soon didn't seem to support a high enough kelvin version.

Sweet - thanks for testing, we're good for tomorrow's release then. The issue seems isolated to this PR's code then which we can debug. If it's not figured out today it won't make this release for Feb 7th. If it merges sometime prior to Feb 7th then it'll get into the branched release with a target ship date of Feb 14th.

I have an idea that'd be interesting:

Cherry pick the 1.14 replay code into 1.15 and build it with the old build system
Cherry pick the 1.14 replay code into 1.16 and build it with the new build system
1.15 and 1.16 are code equivalent, only the build system is different
Compare the results

Basically is the weird jet behavior something about this PR and 1.15 or something about the build.

Yes, that's an interesting idea.  I'll try to play with that during the release call tomorrow.

I spent a good chunk of today looking into why urbit play <pier> runs so slowly on i/157/event-log-replay-restoration. I couldn't find any build-system related explanation, nor could I find any errors related to migration from the old repo to the new one. I do think @zalberico's idea is a good one to gain further insight into this bug.
As a result of combing through the diff for this feature, I realized that we can implement an improved event log replay with much less additional complexity than the version that shipped with v1.14 at the expense of retrying events that fail because they run out of memory i.e. bail meme.
We can easily use the existing replay implementation--the one a ship goes through at launch--to implement the play subcommand and simply exit successfully right after replay finishes. After each replay batch succeeds, we'll take a snapshot. We can also allow the user to specify the batch size for replay from the command line, which will enable users to replay as few as a single event at a time. The combination of snapshotting after each successful replay batch completion and configurable replay batch size is still a major improvement.
I have a working implementation of this, albeit without the command line configurable batch size, but that won't take much effort to implement.

@sigilante @Fang- fprintf() is preferable for error messages, because the u3l_log() implementation can be much more complex (async in the presence of IPC) and therefore less reliable. This has been a support obstacle in the past.
@mcevoypeter the improved error handling and event retry was the main reason for adding a separate replay command. It was only separate because mars/urth isn't shippable -- it's preferable for replay to be automatic in almost all cases. Snapshot updates on error/exit would definitely be an improvement, but doing so after every batch will result in a very high write() volume (unless batch size is increased massively, which will likely have performance problems). Async replay is just much more difficult to control.
I'll take another turn with this PR in a debugger as soon as I can.

I understand the value that the improved error handling and event retry brings, but the simple, piggybacking approach I detailed above still does add value. In the interest of delivering an improved replay experience to users in the short term, I'd argue we should ship the piggybacking approach while we figure out what's going on with this the more full-featured version. I implemented the command line arguments, and, all told, the diff is ~80 lines. If we squash and merge the resulting PR, it'll also be trivial to revert should we want to do so in the future.

I have been comparing jet invocations in u3j_kink for the two sequences.
The regular replay (boot and replay, the fast existing one) and the slow replay (urbit play, this PR) appear to be basically identical, with two more Nock invocations in the slow replay.
The full output is way too long for this PR discussion, but the relevant portion (at event 5 onwards), looks like this:
"regular":
$u3j_kink nock

$u3j_kink nock

$u3j_kink nock

$u3j_kink nock
$u3j_kink nock
$u3j_kink nock

*u3j_kink jet
*u3j_kink jet
$u3j_kink nock
...

slow:
$u3j_kink nock

$u3j_kink nock

$u3j_kink nock

$u3j_kink nock
$u3j_kink nock
$u3j_kink nock
$u3j_kink nock
$u3j_kink nock
*u3j_kink jet
*u3j_kink jet
$u3j_kink nock
...

Everything before the event replay is identical, hundreds of lines' worth.  This tends to undermine the hypothesis that compiler jets aren't firing.

I think u3j_kink looks up jets, right?  It being fired doesn't mean the jets were actually found, you'd need to see which branch it took

Right, I'm printing nock/jet in the conditional after they're found.
Anyway, it looks like my replay is locally slow anyway in both cases right now, so the mystery deepens for me.

https://github.com/urbit/vere/issues/157#issuecomment-1409485099
@sigilante were you able to try that?

I have an idea that'd be interesting:

Cherry pick the 1.14 replay code into 1.15 and build it with the old build system
Cherry pick the 1.14 replay code into 1.16 and build it with the new build system
1.15 and 1.16 are code equivalent, only the build system is different
Compare the results

Basically is the weird jet behavior something about this PR and 1.15 (code equivalent to 1.13 and 1.16) or something about the build (since we never tested this code outside of 1.14, that's the other variable - this test would reduce the variable down to only the different build system which is the only thing different between 1.15 and 1.16 so we at least know for sure if it's that or not).

@sigilante were you able to try that?

I didn't do it against 1.15 and 1.16 yet—just against an updated develop.  I'll give it a shot.

Reopening - it got automatically closed accidentally by github due to a referenced issue (the simple replay command fix)

Trying to build the old versions in the monorepo is now a phenomenal pain.
I have been unable to get v1.15 with these changes to compile due to header/linker stuff, will play with it more.
I can get v1.16 with these changes to compile and parse a pill, but the Dojo will not load.

Have a gander at #210 for a fix.
It clobbered some changes that I need to restore but it plays at regular speed.

This is really bizarre.
There's still a big diff between those two PRs, due to many other changes throughout the repo. It tried merging develop back into each branch. Other than whitespace, the only differences I see are the order of header includes in main.c, and the set of headers included in mars.c. Header conventions were changed in a big way while replacing the build and exiting the monorepo. But I'm quite surprised to see this causing behavior changes or bugs like this instead of just failing to build.

#includes and which directory files are located are the big differences.

The #210 PR's diff include some code dropped from serf.c (_serf_space and _serf_prof``, a usage_cerror message inmain.c, and in disk.c some code in _disk_read_one_cband_disk_serialize_v1`.  What should I do with that, as I'm not sure what it's for offhand?

@sigilante I left a review on your pr requesting some changes. But all the things you mentioned here are good and should be kept.

@sigilante can you be more specific? Which blocks of #includes changed and in which files? And what do you mean exactly by "where directory files are located"? It'd be great if we could understand what single change causes this work to break.

@mcevoypeter here's the diff of the merges i mentioned above: https://pastebin.com/YPnG7kF8

If I build a fakezod from the 1.15 solid.pill, then urbit play replay is fast.
If I build a fakezod from the 1.19 solid.pill, then urbit play replay is slow.

Based on this, I'm going to say that urbit play and the associated changes are not the problem, they are a symptom of something else (maybe urth/mars split?) going wrong.

To add on what @sigilante said, it is also slow on fakezods freshly booted with urbit-1.17.pill and urbit-1.18.pill pills (both from bootstrap.urbit.org).

I'm confused - I thought we already confirmed that the performance is fast with the changes in the diff Joe linked here?: https://pastebin.com/YPnG7kF8 - and this diff was the cause (for some as yet unknown reason). If that's the case we'd expect 1.15 to be fast and 1.19 to be slow (if it doesn't have the change in the diff).
And we have a working change in #210
Are you saying that's not the case and #210 is also slow?

I'm saying it is a function of the pill used to boot Arvo.

@zalberico, @sigilante was testing this code on a fakezod he had booted with a 1.15 pill this entire time, so we were under the impression that we had something working. However, I tried to test it on my machine last week and confirmed that it's slow on ships booted with any of the future pills (1.16 through 1.19).

I understand, thanks and good catch debugging!

Matt tested 1.16

The pills alone can't explain the difference, if we're able to boot the ships but then not replay them with the new implementation). The only way I can explain that is in differences between jet state/dashboards (between serf.c and mars.c) -- I observed that above and can reproduce if needed. I still do not understand how the differing header includes can still compiles and runs, but produce different behavior. I believe that something about the way we are now declaring/initializing global variables is to blame.

The change in how we declare and define global variables is now standard: we now declare global variables as extern in the appropriate header file and define them in the appropriate source file corresponding. Before, we were defining global variables in header files, which causes multiple definition errors at link time (when using standard header inclusion practices).
I agree it's weird that the differing includes produce different behavior. However, it's also positive pressure since the behavior difference likely means we were getting away with something we shouldn't have been able to before the switch to the new build system (and accompany header inclusion pattern changes).
All that said, I noticed u3j_Dash is not defined in pkg/noun/jets.c, which it should be. However, after defining it and replaying with play, I'm not seeing any difference in behavior: event 7 still takes a prohibitively long time. It's also worth pointing out that u3_Host has no clear owning file, so its definition may be worth looking into.

@joemfb pointed my attention back at L25 of pkg/noun/BUILD.bazel, which uses the -force_load option to resolve a linker error that otherwise occurs during build.[^1]
However, the slow urbit play functionality occurs for me on both my macos-aarch64 and linux-x86_64 machines, so I don't think this particular wart in our build configuration is the culprit.
I will keep exploring tomorrow and report back here as I uncover anything of interest.
[^1]:
Undefined symbols for architecture arm64:
  "_u3o_Config", referenced from:
      _main in main.o
      __cw_utils in main.o
      __cw_serf_writ in main.o
      __king_dawn in libvere.a(king.o)
      _u3_king_commence in libvere.a(king.o)
      __serf_grab in libvere.a(serf.o)
      _u3_serf_work in libvere.a(serf.o)
      ...
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

@matthew-levan which branch/commit are you building/running from, and with which pills? Are you booting and replaying with the same binary?

@joemfb yesterday's builds were from jb/moar-replay using pills 1.16 through 1.19, booted and replayed with the same binary (the one built from your branch).

I have built two branches now, all essentially identical to jb/moar-replay.  They exhibit the same behavior.

@sigilante @joemfb What do you think is to be done about this PR, given that it is slow because of failed jet firings under certain conditions?  I'm guessing we should fix whatever that problem is before merging this, despite the fact that it doesn't seem like this PR is itself causing that issue.

I'm of the opinion that we should not merge this until the root cause is fixed.  The different behavior on pills of various runtime versions is cursed.


Workaround for installing OT Feature Freezer on Mac?

I'm on Mac OS Ventura 13.2.1, and the OS will not allow me to install the Feature Freezer because the developer isn't identified. I've  tried everything that I can find documented, but it seems those workarounds were for a previous OS. Can anyone help? Thank you

Did you try Ctrl-click the .app then choosing Open > Open, and then repeating this if needed?

A colleague just found an alternate version - and it worked! Thank you so much!

If someone is having the same issue in the future, this is the one that worked: https://github.com/twardoch/fonttools-opentype-feature-freezer/blob/master/download/OTFeatureFreezer.dmg


Fix set external buffer

Background
External color buffers got cleared when zoom in/out map.

Change List

setExternalBuffer

Coverage remained the same at 80.185% when pulling 39e0a428e3c7f90d9c83a8a3b32431f1ab6eeea4 on xx/ext-buffer into d7822c4613ffe4a27b780c8f9a087b03f4f57eea on master.


You may regret the Mit/Apache 2.0 license stack.

I am writing about a concern that you may regret your permissive license stack. Many open source projects have used permissive licenses, only to regret it when a faceless corporation forks the source code to make a freedom subtracted software package without giving anything back to the people that originally developedthe software. What happens when Amazon turns Locutus into a product, makes enhancements, and then refuses to give anything back to you, not even the documentation on how to implement the changes yourself. This has happened to many projects, such as netbsd, which apple and microsoft forked the network stack from without giving anything back to netBSD, not even a statement of gratitude. Amazon Web Services has taken many opens source projects without giving back to the people who made them. I do not want this to happen to you. Rememer that once this happens to you, you have no right to complain, since you allowed them to do it.  I would recommend you upgrade to a weak copyleft license to preserve the freedom of others. I would recommend the LGPL 3.0 for the citcumstances of Locutus, since you want to allow code written for locutus to run under its own license. This will also allow Locutus to be combined into Web Browsers and other apps while preserving Freedom of those who use Locutus. This will make sure that corporations that use Locutus still have to give back to the community. The best time to make this change is after Locutus 1.0 releases to the General Public.

The choice of license was a condition of a funding grant that paid for quite a bit of development over the past year.
I agree with you that this has been a problem with open source. However, it's difficult for me to imagine Amazon being able to turn Locutus into a product.
That said, we now have other funding sources that don't have that restriction, so some components will likely be LGPL going forward (where we think a more Stallmanesque license is appropriate).


Spelling in docs

Step 3
"Thenn in Github"
https://docs.digger.dev/getting-started/github-actions-and-gcp

Thanks for reporting! Fixed now :)


[improve][client-c++]Support include message header size when check maxMessageSize

Master Issue: #17188
Motivation
See: #17188
Modifications
Support include message header size when check maxMessageSize for cpp client
Verifying this change

[x] Make sure that the change passes the CI checks.

This change is already covered by existing tests, such as testMaxMessageSize、testNoBatchMaxMessageSize、testChunkingMaxMessageSize.
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API: (yes / no)
The schema: (yes / no / don't know)
The default values of configurations: (yes / no)
The wire protocol: (yes / no)
The rest endpoints: (yes / no)
The admin cli options: (yes / no)
Anything that affects deployment: (yes / no / don't know)

Documentation
Check the box below or label this PR directly.
Need to update docs?

[ ] doc-required
(Your PR needs to update docs and you will update later)

[x] doc-not-needed
(Please explain why)

[ ] doc
(Your PR contains doc changes)

[ ] doc-complete
(Docs have been already added)

Odd, why is the java client compilation failed?
https://github.com/apache/pulsar/runs/8033665923?check_suite_focus=true
Error:  Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project pulsar-client-original: Compilation failure
Error:  /Users/runner/work/pulsar/pulsar/pulsar-client/src/main/java/org/apache/pulsar/client/impl/BatchMessageContainerImpl.java:[222,39] no suitable method found for sendMessage(long,long,int,org.apache.pulsar.common.api.proto.MessageMetadata,io.netty.buffer.ByteBuf)
Error:      method org.apache.pulsar.client.impl.ProducerImpl.sendMessage(long,long,int,org.apache.pulsar.client.api.MessageId,org.apache.pulsar.common.api.proto.MessageMetadata,io.netty.buffer.ByteBuf) is not applicable
Error:        (actual and formal argument lists differ in length)
Error:      method org.apache.pulsar.client.impl.ProducerImpl.sendMessage(long,long,long,int,org.apache.pulsar.common.api.proto.MessageMetadata,io.netty.buffer.ByteBuf) is not applicable

Odd, why is the java client compilation failed? https://github.com/apache/pulsar/runs/8033665923?check_suite_focus=true
Error:  Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project pulsar-client-original: Compilation failure
Error:  /Users/runner/work/pulsar/pulsar/pulsar-client/src/main/java/org/apache/pulsar/client/impl/BatchMessageContainerImpl.java:[222,39] no suitable method found for sendMessage(long,long,int,org.apache.pulsar.common.api.proto.MessageMetadata,io.netty.buffer.ByteBuf)
Error:      method org.apache.pulsar.client.impl.ProducerImpl.sendMessage(long,long,int,org.apache.pulsar.client.api.MessageId,org.apache.pulsar.common.api.proto.MessageMetadata,io.netty.buffer.ByteBuf) is not applicable
Error:        (actual and formal argument lists differ in length)
Error:      method org.apache.pulsar.client.impl.ProducerImpl.sendMessage(long,long,long,int,org.apache.pulsar.common.api.proto.MessageMetadata,io.netty.buffer.ByteBuf) is not applicable

See: #17300

@RobertIndie PTAL.

@RobertIndie @merlimat @Demogorgon314 Could any of you leave a 2nd review?


Add checker for different usage of type in func arguments

Add checker consistent usage of types in function declarations
func some(a int, b int, c int) {
    ...
}

vs
func some(a, b, c int) {
    ...
}

If @Quasilyte is ok with this addition I'll update readme as well.

It's done in https://github.com/go-critic/go-critic
Docs: https://go-critic.github.io/overview.html#paramTypeCombine-ref

@cristaloleg maybe @a-urth wants to have an opportunity to change combined types into separate definitions. Some programmers dislike a, b, c T notation.
@a-urth, is that so?
I need some time to think about it and ask others about their opinion.
I'll post back soon.

Yes, but it suggest one way of doing it while go-consistent check for one already used most in the system.

@Quasilyte exactly. We have this discussion in our project and want to stick to the way which is already mostly used.

The argument I've got from several sources:

Sometimes f(x, y T) is more readable, especially in those small signatures, but for all other cases more verbose form is preferred.

The bad part is that this preference allows both forms to co-exist in one codebase.
But if we have a way to disable checks, it's probably not a big deal.

I still think that implementing this as a check for lintpack is more useful as it can have more options.
As an example of such standalone check or a bundle of checks there is https://github.com/quasilyte/go-police, it can be built with https://github.com/go-lintpack/lintpack in the same way as https://github.com/go-critic/go-critic, or you can build a linter that includes both gocritic and your personal checks.
I can help you porting that check, if you have any questions, there is https://t.me/go_critic_eng and https://t.me/go_critic_ru (depending on the language you prefer).
The problem with go-consistent is that it works sub-optimal when both alternative may be desired to live inside a single project. I don't know how to approach that yet.


Error installing nokogiri (<IP_ADDRESS>)

Hi -
When I run vagrant up I get the following message:
vagrant-bindfs missing, please install the plugin:
vagrant plugin install vagrant-bindfs
When installing vagrant-bindfs, I get the following message:
An error occurred while installing nokogiri (<IP_ADDRESS>), and Bundler cannot continue.
Make sure that gem install nokogiri -v '<IP_ADDRESS>' succeeds before bundling.
I tried gem install nokogiri -v '<IP_ADDRESS>' which returns:
Successfully installed nokogiri-<IP_ADDRESS>
Running vagrant plugin install vagrant-bindfs still returns the error though. Any ideas?
Thanks!

Just to double-check, did you attempt to install the vagrant-bindfs plugin using this command: vagrant plugin install vagrant-bindfs? I ask because I can't think of why Bundler would be involved in the install process (as noted in the error message).

Yes - vagrant plugin install vagrant-bindfs
After running the above I get:
Installing the 'vagrant-bindfs' plugin. This can take a few minutes...
Bundler, the underlying system Vagrant uses to install plugins,
reported an error. The error is shown below. These errors are usually
caused by misconfigured plugin installations or transient network
issues. The error from Bundler is:
An error occurred while installing nokogiri (<IP_ADDRESS>), and Bundler cannot continue.
Make sure that gem install nokogiri -v '<IP_ADDRESS>' succeeds before bundling.
Thanks again for your help!

If I remember correctly, this has to do with vagrant and system using different ruby binaries. Are you using RVM or rbenv?
—
Sent from Mailbox
On Sun, Mar 8, 2015 at 9:24 PM, Brendan Griffiths
<EMAIL_ADDRESS>wrote:

Yes - vagrant plugin install vagrant-bindfs
After running the above I get:
Installing the 'vagrant-bindfs' plugin. This can take a few minutes...
Bundler, the underlying system Vagrant uses to install plugins,
reported an error. The error is shown below. These errors are usually
caused by misconfigured plugin installations or transient network
issues. The error from Bundler is:
An error occurred while installing nokogiri (<IP_ADDRESS>), and Bundler cannot continue.
Make sure that gem install nokogiri -v '<IP_ADDRESS>' succeeds before bundling.
Thanks again for your help!
Reply to this email directly or view it on GitHub:
https://github.com/roots/bedrock-ansible/issues/140#issuecomment-77791041

RVM

Hi --
Reinstalling Vagrant seemed to fix the issue for me.
One more question -- It seems like every page is returning the WordPress home page (even linked JS/CSS files come back with the default page). Is there something I'm missing in the configuration? I assume this has something to do with the nginx config?
Thanks again for your help!

It could but check to make your WP url settings are correct here: https://github.com/roots/bedrock-ansible/blob/master/group_vars/development#L19-L20
Closing this the original issue is not related to this project in itself.


Minio won't support the api gateway anymore, so...

... I wanna know how that will affect this project.
Greetings~

It doesn't.


Modern UI: Average Response Time and 95th percentile have the same color

Prerequisites

[X] I am using the latest version of Locust
[X] I am reporting a bug, not asking a question

Description
Average Response Time and 95th percentile have the same color.

Actually, is it possible to turn off average response time?
Command line

Locustfile contents
-

Python version
3.11
Locust version
2.23.0
Operating system

Thanks! I knew on the old UI we used to limit the percentiles display to two, I forgot we didn't set a limit on the new UI. How does something like this look? (I will set a limit to 6 percentiles)

As for the average, there isn't currently a way to disable it. The reason is because PERCENTILES_TO_CHART only accepts integers. Most likely we would need to set a boolean or create a new argument in order to be able to disable showing the average. What do you think @cyberw? Should we have a way of disabling showing the average stat in the charts?

The suggested colors look great imo :)
I'm in no rush to add a feature to disable average.


Add AddEndpointsApiExplorer to DefaultSetup

Add builder.Services.AddEndpointsApiExplorer() to builder.Services.AddDefaultSetup().

Can you describe a bit more why this is needed and for what?

This is related to the issue where I couldn't see the asp.net identity endpoints in swagger.
The solution was to add the code above to my Program.cs, although I invoked AddDefaultSetup() with OpenAPI enabled in the options.

Can you pls a full code sample here?


Help

Hi there:
Can I ask you a code question?
I am a novice,and I can use sequelize or better-sqlite3 to connect a sqlite file.
I can not correct load the db file by any ways.
I created a test.js file like this:
const Database = require("better-sqlite3");
const db = new Database("test.db", {
  verbose: console.log,
});

const search = (keyword) => {
  const searchAction = db.prepare(`select * from demo`);
  const res = searchAction.all();
  console.log(res);
  return res;
};

module.exports = {
  search,
};

I use it in node cli, everything is ok.But I can not take this in api scripts.It can not read any table.
thanks!

My bad.I do not know nextjs runtime.storage path is error,I should learning more hard!


Preset "Date" and "Number" fields missing labels once inserted

Description
Most preset form elements have a field label and hint text (as well as autocomplete attributes) prepopulated, except date and number.
Steps to reproduce

Go to "Add a form element"
Click on "Date"
See it inserted in the form builder edit, check preview screen as well
Go to "Add a form element"
Click on "Number"
See it inserted in the form builder edit, check preview screen as well

Details

Browser: Edge
Operating system: Windows
Environment: App router PR
Language: French
Viewport: Tablet

Expected behaviour
Consistent experience where all presets have label?
EN: Date
FR: Date
EN: Amount
FR: Montant
Screenshots or videos

I picked up on this too, but interestingly that's the way it is in Staging/prod currently - so, not a bug.
@connorscarolyns can you confirm if this is by design?

@Abi-Nada This being one of our earlier elements, I don't believe we had any hard or fast rules in creating them. This was by design, because we don't really know the exact question they may be asking, it could be any kind of date or phone number, so the question part was left blank. Maybe it should have a preset question, although what we would put in the case of number field I'm not sure what would make sense.

Not a bug, but perhaps a backlog item.
Since we're now categorizing these as "presets" I think we should consider including a generic placeholder label/question as we do for other preset form elements ex: "Amount" and "Date". It's a weird experience to have preset hint text here but not a preset label. Also all the other presets we have currently have placeholder text pre-determined. Of course the option to modify/edit/customize the text here is available as it is for name/attestation/address etc. I think being consistent in our approach here would help to make things clearer.

Yeah that makes sense - I'll keep this in the backlog as an item to be pulled in + good to include this conversation to reference when we pick it up, but I'm going to remove it from our current scope of bug fixes for the App Router

Sounds good to me too


kube-dns stop working after upgrade to 1.6.2 from 1.5.4 using kops rolling-update

I upgraded cluster from 1.5.4 to 1.6.2 using kops update/rolling-update features.
Initially I was seeing following error with weave-net.
bkpandey [12 minutes ago]
modprobe: module br_netfilter not found in modules.dep
Ignore the error if "br_netfilter" is built-in in the kernel
2017/05/16 01:42:13 error contacting APIServer: the server has asked for the client to provide credentials (get nodes); trying with fallback: http://localhost:8080
2017/05/16 01:42:13 Could not get peers: Get http://localhost:8080/api/v1/nodes: dial tcp [::1]:8080: getsockopt: connection refused
Failed to get peers

Once I deleted weave-net deployment manually and re-created it, stop seeing that error. Now I am seeing following,
 kubectl logs kube-dns-16966370-02741  --namespace=kube-system kubedns
E0516 17:11:28.050939       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: the server has asked for the client to provide credentials (get services)
I0516 17:11:28.413863       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
I0516 17:11:28.913878       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
E0516 17:11:29.052806       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Endpoints: the server has asked for the client to provide credentials (get endpoints)
E0516 17:11:29.052806       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: the server has asked for the client to provide credentials (get services)
I0516 17:11:29.413835       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
I0516 17:11:29.913822       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
E0516 17:11:30.054696       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: the server has asked for the client to provide credentials (get services)
E0516 17:11:30.054707       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Endpoints: the server has asked for the client to provide credentials (get endpoints)
I0516 17:11:30.413847       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
I0516 17:11:30.913821       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
E0516 17:11:31.056598       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: the server has asked for the client to provide credentials (get services)
E0516 17:11:31.056598       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Endpoints: the server has asked for the client to provide credentials (get endpoints)
I0516 17:11:31.413867       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
I0516 17:11:31.913832       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
E0516 17:11:32.058466       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Endpoints: the server has asked for the client to provide credentials (get endpoints)
E0516 17:11:32.058521       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: the server has asked for the client to provide credentials (get services)
I0516 17:11:32.413821       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
I0516 17:11:32.913855       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
E0516 17:11:33.060197       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Endpoints: the server has asked for the client to provide credentials (get endpoints)
E0516 17:11:33.060237       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: the server has asked for the client to provide credentials (get services)
I0516 17:11:33.413805       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
I0516 17:11:33.913821       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
E0516 17:11:34.062302       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Endpoints: the server has asked for the client to provide credentials (get endpoints)
E0516 17:11:34.062380       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: the server has asked for the client to provide credentials (get services)
I0516 17:11:34.413816       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
I0516 17:11:34.913869       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
E0516 17:11:35.064285       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Endpoints: the server has asked for the client to provide credentials (get endpoints)
E0516 17:11:35.064361       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: the server has asked for the client to provide credentials (get services)
I0516 17:11:35.413949       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
I0516 17:11:35.913850       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
E0516 17:11:36.065885       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Endpoints: the server has asked for the client to provide credentials (get endpoints)
E0516 17:11:36.065884       1 reflector.go:199] k8s.io/dns/vendor/k8s.io/client-go/tools/cache/reflector.go:94: Failed to list *v1.Service: the server has asked for the client to provide credentials (get services)
I0516 17:11:36.413823       1 dns.go:174] DNS server not ready, retry in 500 milliseconds
F0516 17:11:36.913871       1 dns.go:168] Timeout waiting for initialization

Also seeing similar error message in kubernetes-dashboard also
kubectl logs kubernetes-dashboard-2457468166-mfz3g  --namespace=kube-system
Using HTTP port: 9090
Creating API server client for https://<IP_ADDRESS>:443
Error while initializing connection to Kubernetes apiserver. This most likely means that the cluster is misconfigured (e.g., it has invalid apiserver certificates or service accounts configuration) or the --apiserver-host param points to a server that does not exist. Reason: the server has asked for the client to provide credentials (get .meta.k8s.io)
Refer to the troubleshooting guide for more information: https://github.com/kubernetes/dashboard/blob/master/docs/user-guide/troubleshooting.md

Hi @pandeybk,
You presumably found out that Kubernetes v1.6 has changed quite a lot compared to the previous versions (RBAC, different endpoint for the API server, etc.) but managed to resolve it on your own.
Feel free to reach out on our Slack channel if you have any remaining question.


CartSession addline - Attempt to read property "id" on null

Lunar version: 1.0.0-beta6
Laravel Version: 11.33.2
PHP Version: 8.3.14
Database Driver & Version: Mysql 8.0.33

Expected Behaviour:
I try in CartSession addline.
Actual Behaviour:
Have error: Attempt to read property "id" on null
Full Code:
public function addToCart(Request $request)
{
// Валидация входных данных
$request->validate([
'variant_id' => 'required|integer',
'quantity' => 'required|integer|min:1',
]);
    // He Find
    //dd(\Lunar\Models\ProductVariant::find($request->variant_id));

    // Get error: Attempt to read property "id" on null
    CartSession::addLines([
        [
            'purchasable' => \Lunar\Models\ProductVariant::find($request->variant_id),
            'quantity' => $request->integer('quantity'),
        ],
    ]);

    return 1;
}

Steps To Reproduce:

Can you provide the full stack trace or shared Flare error.
Are you able to provide a failing test?

@artur33s - 2 minutes after I posted my comment I figured out the issue, if you look at the Vendor Frames in Flare, it seems to be failing (for me at least) on the tax calculation.  If so, you can setup a tax class for that product or simply go to you config->lunar->cart and comment out 'Lunar\Pipelines\Cart\CalculateTax::class' from the 'cart' node.  Worked for me!

Have you got taxes set-up correctly?

Im not using Taxes, but i add Zone Taxes and error not showing. Its work!
Thanks!


Allow rcheckin to associate/close work-items

This is a feature-request/idea.

If the work-item doesn't exist, it will fail with a message.
Instead associate you could also use the close command to close the work-item.

Good idea. Maybe since we use git-tfs-id for some pieces, we should use git-tfs as a prefix for some of these special operations.
Perhaps something like git-tfs-work-item: <item id> <action>.

We don't work with TFS workitems, so I don't know anything about them basically. It is up to you, guys, sorry.

No problem - I'll assign it to myself and work on it. It's feature/134 in my fork.

Going to close this issue, since the pull request is where most of the action is happening now.


#12, Fixed nihang akkad bonus

Issue #12
Fixed Nihang Behavior when Akkad is Suzed: https://www.youtube.com/watch?v=QG4Cg0o8Slw

So, they weren't melee class, they have their own promotion tree PROMOTION_CLASS_NIHANG

Rebased


error to access chrome

Issue Type: Feature Request
the following issue i am facing :
unable to launch browser: "spawn  ....\chrome.exe  EACCES"
VS Code version: Code 1.64.2 (f80445acd5a3dadef24aa209168452a3d97cc326, 2022-02-09T22:02:28.252Z)
OS version: Windows_NT x64 6.3.9600
Restricted Mode: No

what are you trying to do?
please provide reproducible steps.


Restructure wiki page organization

I'm planning on restructuring the wiki pages to have categories and subcategories, as illustrated in this repo:
https://github.com/adriantanasa/github-wiki-sidebar

Wiki sidebar has now been updated.


Livestream: Description area lost sidebar

It doesn't affect me since I don't use it to scroll, but I assume it's needed for consistency and small set of users.

Good catch...usually don't run into longer ones. Rafael recent hid the double scroll, but yeah, we should handle this too.


AN in browser MVP: Create syncing component

Sync one type of data from blockchain & put it into rudimentary DB

Closing this since Alex's PR (https://github.com/AugurProject/augur/pull/906) has been merged. Still need to add blockstream to retrieve new blocks after initial sync, which will be done in https://github.com/AugurProject/augur/issues/951.


There seems to be a typo in azure_iot_hub.c line 134

Variable defined as directMethodCallbackh(...) should be directMethodCallback(...)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 523ad25d-ef35-4653-4bb4-d01795828e4d
Version Independent ID: 25b26299-d3ca-45fa-54a1-923c0aca80d0
Content: Azure Sphere with Azure IoT Hub - sample application
Content Source: AzureSphere/articles/app-development/azure-iot-sample.md
Product: azure-sphere
GitHub Login: @pennyo
Microsoft Alias: azurespheredocs

Not an issue after I uninstallde the Connected Service for IoT Hub extension in VS 2017.

@jrchinchilla Sorry for the delay. I am closing old issues. Closing this one since you were able to resolve it yourself. Thanks for reaching out!


hello ,is it support unreal metahuman?

amazing work! i want to know is it support unreal metahuman?

You are welcome to test it in the demo we provide.


fix: err on missing local and global

Proposed fix in ref to #29
Show error on :checkhealth only if local and global executable is missing for any specified tool.

This seems perfect. I'll have to check this out on my pc later


feat/add arm64 support

This PR adds the Dockerfile to make linux/arm64 and darwin/arm64 builds easier/possible.
closes #603
closes #505

Thanks! What's the debian-based container size compared to alpine?

Thanks! What's the debian-based container size compared to alpine?

On darwin/arm64 with the latest version of Docker Desktop, the final image size seems to be 98MB.

We need to check the size diff for i64

lol, no, i meant x86-ia64 (amd64)

also, you may want to rebase on #614

Ok, i just checked.  When running just docker-build with the old dockerfile (using the #614 for speed up):
> just docker-file
...
> docker images
REPOSITORY                                TAG             IMAGE ID       CREATED          SIZE
ghcr.io/maplibre/martin                   latest          8b3e3e02fc34   22 minutes ago   31.1MB

with the proposed docker image (same cargo patch), the result is
REPOSITORY                                TAG             IMAGE ID       CREATED          SIZE
ghcr.io/maplibre/martin                   latest          aadb127bb44d   31 seconds ago   104MB

I don't think growing the image size by over 3x just to make mac docker images is a good proposition because the vast majority of these images are used on linux servers (this might change in the future).

Ok, i just checked. When running just docker-build with the old dockerfile (using the #614 for speed up):
> just docker-build
...
> docker images
REPOSITORY                                TAG             IMAGE ID       CREATED          SIZE
ghcr.io/maplibre/martin                   latest          8b3e3e02fc34   22 minutes ago   31.1MB

with the proposed docker image (same cargo patch), the result is
REPOSITORY                                TAG             IMAGE ID       CREATED          SIZE
ghcr.io/maplibre/martin                   latest          aadb127bb44d   31 seconds ago   104MB

I don't think growing the image size by over 3x just to make mac docker images is a good proposition because the vast majority of these images are used on linux servers (this might change in the future).

The size may be 3x difference, but numerically, is 100MB ever a dealbreaker over 30MB for users where you can assume their average image size is > 300MB? (We use martin and our images are way above that usually)
The other thing is, this PR is not about fixing Mac images, it's about fixing arm64 as a whole, since if you try to build the old image on linux/arm64, it'll fail due to an issue with musl and glibc differences on arm64 intrinsics. I can attempt to bring the image size down a bit, but I doubt it's worth the effort. I'd say for most solid images on Dockerhub are usually below the 200MB mark and this change still keeps us there.

also, you may want to rebase on #614

Can do.

@nyurik Just rebased on top of nyurik/martin@8ef895306d5150a26e2f773dd06f4c34143a2911

@nyurik I was able to cut 10MB by stripping the symbols release binary.

Sorry, I meant arm64 for linux.  I don't think shaving the 3MB and loosing all symbols is a good path. I would much rather have proper stack traces with symbols if something happens, rather than having hard-to-parse stacktraces -- those 3MB actually add value.  What I am concerned with is that we want to add 70MB to an image without any benefit to the existing user base.  70MB might not sound like a lot, but this is a waste that I would rather avoid unless absolutely must have.
I propose we figure out how to build with musl/libc on arm64 - it shouldn't be THAT difficult I would think.  If we can't, lets just create a new arm64.Dockerfile that we will use for arm64 builds.

Regardless - I don't think that's the issue - there seem to be some issue with dockerx and manifests - and that's the same thing I saw before with @stepankuzmin 's PR

Regardless - I don't think that's the issue - there seem to be some issue with dockerx and manifests - and that's the same thing I saw before with @stepankuzmin 's PR

That is a known issue - https://github.com/docker/buildx/issues/59
It can be remedied by building the ARM image as a separate step. I could work on that, as long as there is some guarantee that the working solution would be merged. Wouldn't want to work on something that maintainers don't want to go forward with.

That I'm sure we will do, just possibly as arm64 specific docker file so to keep the image size low for others

That I'm sure we will do, just possibly as arm64 specific docker file so to keep the image size low for others

Got it, then I think I should go forward with arm64 specific Dockerfile and leave the current one as it is then.

@nyurik Seems to build fine, although slow, which is expected with emulation. For the time being, we can't run the DB tests on the ARM image yet because of unavailability of an ARM image for PostGIS. I'm looking into submitting a patch for that down the line.

@Volatus or @stepankuzmin could you verify that the arm64 image is published properly under the main tag?

@Volatus or @stepankuzmin could you verify that the arm64 image is published properly under the main tag?

@nyurik
The image seems to be there but the manifest list entry is not correct.

that's not good :(
can it be that the publish step needs to be modified as well somehow, to preserve the platform?

that's not good :(
can it be that the publish step needs to be modified as well somehow, to preserve the platform?

Maybe try adding the platforms option to the push step as well?

Hmm, it seems the push step for some reason re-builds the docker image -- https://github.com/maplibre/martin/actions/runs/4545573925/jobs/8013094651
This is not good for several reasons - most importantly because it seems it uses a different dockerfile in that step...  Any thoughts of why that might be?

@Volatus @stepankuzmin please retest - i think i fixed it, but no idea if the metadata is correct

Weirdly enough, there are two architectures listed: arm64 and unknown. Should the x86-amd64 specify its metadata in some other way?  https://github.com/maplibre/martin/pkgs/container/martin/81143769?tag=main

And one more interesting tidbit: the image tagged as arm64 is actually amd64!  And I wasn't able to download the unknown/unknown image, so i have no idea what that one is... Any ideas how to fix this? I would hate to revert this PR.
❯ docker pull --platform linux/arm64 ghcr.io/maplibre/martin:main
main: Pulling from maplibre/martin
fcdb9667c46b: Pull complete
bc959a36ad3b: Pull complete
Digest: sha256:248ef4abb68d3fe2dc1af2068984850fad48bc3d500af67bbfb9b3485620f8c9
Status: Downloaded newer image for ghcr.io/maplibre/martin:main
WARNING: image with reference ghcr.io/maplibre/martin was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64
ghcr.io/maplibre/martin:main

I did receive a reply on stackoverflow about this https://stackoverflow.com/questions/75872905/building-both-amd64-and-arm64-with-github-workflows-from-different-files/75873049#75873049

I think if both of them have their own manifest step, it should end up working.

@nyurik It's surely not the case the issue is due to order right?
https://github.com/maplibre/martin/blob/eae422a2112d214b60cb7edc257dbdeeadc96e49/.github/workflows/docker.yml#L21-L25

@Volatus definitly not because i added the QEMU configuration after I saw the issue. Before this, QEMU was configured with ALL


Update cn.json

VINXIS — Today at 9:38 PM
@Ryuusei Aika remove undefined line 116 and the comma on line 115


Update edit distance calculation to factor in length

It does not make sense to factor in length in a region that is highly variable in size. This would introduce reference bias.


Implement Leyshock's Grand Compilation

Is your feature request related to a problem? Please describe.
Need to add this trinket to simc + trinket sims
Additional context
Spreadsheet mapping spells to buff

First round of implementation is done: https://github.com/simulationcraft/simc/commit/3d86e04bf27ef8f9c34e4cc64fad3c724d540140
Closing this for now, will tweak things as needed from here.


[3.2] Add missing "normalized" accessor property to glTF document

This PR adds missing "normalized" accessor property to the scene importer for glTF. It fixes issue #44744 for Godot 3.2.
I say missing, because the code already supports the normalized accessor property, but does not use the glTF files values.
This complements a similar PR for the master branch (#44745), as it has the same issue. I created a separate PR as a simple cherry-pick cannot be done as the glTF module has been refactored in the master branch.

Thanks!

Nice -- fixes the Blender 2.91 exported gltf files.  Thanks!


Deferred bt_conn_tx causes sysworkq deadlock

Mesh pb-gatt sends several GATT notifications in a row. It runs in system workqueue thread context, so that it is possible to cause deadlock after recent changes that deferred bt_conn_tx callback to system workqueue.
While sending several notifications in a row, bt_att_send takes tx_sem
int bt_att_send(struct bt_conn *conn, struct net_buf *buf, bt_conn_tx_cb_t cb,
		void *user_data)
{
...
	/* Don't use tx_sem if caller has set it own callback */
	if (!cb) {
		k_sem_take(&att->tx_sem, K_FOREVER);
		if (!att_is_connected(att)) {
			BT_WARN("Disconnected");
			k_sem_give(&att->tx_sem);
			return -ENOTCONN;
		}
	}
...
}

that is later given by bt_conn_tx.
static void att_pdu_sent(struct bt_conn *conn, void *user_data)
{
	struct bt_att *att = att_get(conn);

	BT_DBG("conn %p att %p", conn, att);

	k_sem_give(&att->tx_sem);
}

As a result running bt_att_send and bt_conn_tx from the same thread causes deadlock in ATT.
This regression was introduced with:
362497235df575586a049dd92216910c99e79094

RTT_Terminal_201906131359.log

So we been blocking on system wq since bt_gatt_* do block when BT_ATT_ENFORCE_FLOW is set, we could perhaps make att.c queue if the semaphore cannot be taken and we don't really need to save the callback as the semaphore is only used when it is set to NULL, then we resume when the previous packet completes.

Actually that still likely to block if we hold on the buffer into a queue it will likely block on bt_conn_create_pdu waiting for buffer to become available, so this one maybe more complicated to deal with, perhaps we will have to have the bt_att_req for notification as well so we can queue them up without requiring a buffer though the bt_att_req is something Id like to make internal to the stack so we can queue things up on its own without requiring the client to manage the pool of request.

I'm trying to use smp_svr on zephyr 802718a773 with nrf52840_pca10056 and have problems I'm told are related to this issue.
When I run sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' echo hello, I eventually see Error: can't discover services: ATT request timeout: req timeout.
Here is a btmon trace: https://gist.github.com/mbolivar/d0ea16d55ffaf9d05482eea36175a967
The problem persists even if I add # CONFIG_BT_ATT_ENFORCE_FLOW is not set to my prj.conf, as suggested by @carlescufi. Enabling bluetooth debugging with CONFIG_BT_DEBUG_LOG=y doesn't produce much difference either:
***** Booting Zephyr OS zephyr-v1.14.0-1473-g6e3083fe310f *****
Bluetooth initialized
Advertising successfully started

[00:00:00.008,850] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.008,850] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.008,880] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 1.14 Build 99
[00:00:00.010,742] <inf> bt_hci_core: Identity: e4:ce:3c:20:bb:b2 (random)
[00:00:00.010,772] <inf> bt_hci_core: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[00:00:00.010,772] <inf> bt_hci_core: LMP: version 5.0 (0x09) subver 0xffff
uart:~$ Connected
Disconnected (reason 19)
Advertising successfully started

@mbolivar could you try reverting 8a7615f4a3d8932481277dffd41a4a72febd0a61 as well?

@mbolivar could you try reverting 8a7615f as well?

You may want to revert 2699d05e45f58897edd7d6d3718c254224390667 as well.

@mbolivar could you try reverting 8a7615f as well?
You may want to revert 2699d05 as well.

If the issue is flow enforcement related I'd say leave commit 269d05 as-is and revert 8a7615f
That way you're making TX callbacks happen sooner while keeping the RX callbacks later, which is essential for avoiding the race condition where we get new incoming data before we've been notified that some related piece of outgoing data has been transmitted over the air.

Btw, should there be a k_yield after this line:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/mgmt/smp.c#L277

could you try reverting 8a7615f as well?

same timeout result.

You may want to revert 2699d05 as well.

Same result as well (with both reverted).

could you try reverting 8a7615f as well?

same timeout result.

You may want to revert 2699d05 as well.

Same result as well (with both reverted).

I guess it is a different problem then, do you actually get any traffic? Or perhaps there is something with the user_data that has been changed, thought it had been increased from 7 to 8 bytes.

I guess it is a different problem then, do you actually get any traffic? Or perhaps there is something with the user_data that has been changed, thought it had been increased from 7 to 8 bytes.

I assume so; the device does say that it's connected and disconnected. Does the btmon trace I posted earlier help answer the question?
Here is another one for 8a7615f reverted, with the same diff on smp_svr/prj.conf: https://gist.github.com/mbolivar/c5d36baf581fc47a6d51257164adfe78
The device logs:
***** Booting Zephyr OS zephyr-v1.14.0-1467-g8cb8b2553045 *****
Bluetooth initialized
Advertising successfully started

[00:00:00.008,880] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.008,880] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.008,911] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 1.14 Build 99
[00:00:00.010,803] <inf> bt_hci_core: Identity: e4:ce:3c:20:bb:b2 (random)
[00:00:00.010,803] <inf> bt_hci_core: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[00:00:00.010,803] <inf> bt_hci_core: LMP: version 5.0 (0x09) subver 0xffff
uart:~$ Connected
[00:00:57.810,913] <dbg> bt_att.bt_att_accept: conn 0x20000630 handle 0
[00:00:57.810,913] <dbg> bt_att.bt_att_connected: chan 0x2000077c cid 0x0004
[00:00:57.818,695] <dbg> bt_att.bt_att_recv: Received ATT code 0x02 len 2
[00:00:57.818,695] <dbg> bt_att.att_mtu_req: Client MTU 512
[00:00:57.818,725] <dbg> bt_att.att_mtu_req: Server MTU 252
[00:00:57.818,725] <dbg> bt_att.att_mtu_req: Negotiated MTU 252
[00:00:57.833,099] <dbg> bt_att.att_rsp_sent: conn 0x20000630 att 0x2000077c
[00:00:57.833,221] <dbg> bt_att.bt_att_recv: Received ATT code 0x10 len 6
[00:00:57.833,282] <dbg> bt_att.att_read_group_req: start_handle 0x0001 end_handle 0xffff type 2800
[00:00:57.833,312] <dbg> bt_att.read_group_cb: handle 0x0001
[00:00:57.833,343] <dbg> bt_att.read_group_cb: handle 0x0009
[00:00:57.833,404] <dbg> bt_att.read_group_cb: handle 0x0010
[00:00:57.833,709] <err> log: argument 3 in log message "%s: start_handle 0x%04x end_handle 0x%04x type %s" missing log_strdup().
uart:~$ Disconnected (reason 19)
Advertising successfully started
[00:01:27.938,323] <dbg> bt_att.bt_att_disconnected: chan 0x2000077c cid 0x0004

It's a bit unclear from your logs, @mbolivar do I understand correctly that just reverting 8a7615f didn't help?
As far as I see there are two issues:

deadlock, caused by trying to send data from the same thread as is used for the TX callback
race condition, i.e. us getting a new incoming packet before being notified that the previous outgoing one has been transmitted

The reason I suggested reverting 8a7615f is that it should improve on both issues: with both RX and TX callbacks being on sys wq means you can't currently send more data from the callback without risking a deadlock. Reverting the patch also makes the TX callbacks happen sooner, since there's one less deferral to another thread, so the race condition should be less likely.
As for the log_strdup warning, I've opened a PR that should hopefully fix it: #16819

It's a bit unclear from your logs, @mbolivar do I understand correctly that just reverting 8a7615f didn't help?

Yes, that is correct.
The btmon trace in https://github.com/zephyrproject-rtos/zephyr/issues/16803#issuecomment-501808742 is with just  8a7615f reverted. The timeout result is the same. The device logs in that comment are from the same test run.

@mbolivar ok, then I agree with @Vudentz that further studying is needed since this sounds like something else than we've originally been looking at.

Should I open a separate bug?

@mbolivar try with https://github.com/zephyrproject-rtos/zephyr/pull/16820 maybe it help with you issue as well.

@mbolivar try with #16820 maybe it help with you issue as well.

@Vudentz I tried with c01c68ab48 (and a clean tree, no prj.conf changes) and got similar results.


notes behind the player or the opponent?

What feature do you want to get added on the base engine?
an event or option in the chart editor that makes the notes behind the player and/or the opponent
To test your sight, and reliability, please select the option of what should NOT be requested.
A good idea

No one's gonna use that and it's just distracting??

Test = failed

sorry but you are wrong
soulless dx has that effect on a song
it looks very cool

No one's gonna use that and it's just distracting??

sorry but you are wrong
soulless dx has that effect on a song
it looks very cool

Damn!! One song!! That's so many!!

wtf

Damn!! One song!! That's so many!!

wtf

No one's gonna use that and it's just distracting??

distracting is the point

Test failed, also you can do this with hscript easily

Too much of an issue for a thing that will very likely not be used in many mods.


Updates for Batch Management 2020-03 API version

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[x] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[x] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

/azp run automation - sdk

This API version has not had SDKs published for it yet (we were waiting for these changes to be merged).
The following two changes are additions required for JEDI:
Info 1040 - AddedReadOnlyPropertyInResponse - The new version has a new read-only property 'privateEndpointConnections' in response that was not found in the old version.
Info 1040 - AddedReadOnlyPropertyInResponse - The new version has a new read-only property 'requiredZoneNames' in response that was not found in the old version.

The following changes are corrects to errors in the specification (these properties were always required, we just didn't specify correctly). Also note, since these properties were only added on an object which is returned from GETs, it's documentation as required is just an FYI that the server will always return it.
Error 1034 - AddedRequiredProperty - The new version has new required property 'status' that was not found in the old version.
Error 1034 - AddedRequiredProperty - The new version has new required property 'status' that was not found in the old version.

Please let me know what we should do to silence the errors in the PR gate.

/azp run automation - sdk

Can one of the admins verify this patch?

@erich-wang  - since SDKs have not yet shipped for this API version, I believe these breaking changes should be okay -- can you advise on what we can do to flag these changes as okay for the purposes of CI?

@erich-wang - since SDKs have not yet shipped for this API version, I believe these breaking changes should be okay -- can you advise on what we can do to flag these changes as okay for the purposes of CI?

Approve the breaking change since there's no sdk released for this version.
@matthchr , please fix ModelValidation error https://dev.azure.com/azure-sdk/public/_build/results?buildId=347822&view=logs&j=8d2f9c49-cd83-5a9d-f3fe-2fd651afa742&t=43324f1f-6724-5d61-785f-f0ac9fd256a1

/azp run automation - sdk

@erich-wang I fixed the model validation failures (sorry about missing that before).

@matthchr , I send email to swagger team to look into the model validation error.


Support negated filters

#288

Could you add a test case for the multi-negation, !(a && b && c), as described in #288 ?

This should really be merged into develop, but at the time of creation it depended on code in effects not yet merged into the develop branch.

Approved. Merge whenever you'd like.

Merged 11ab287af239824e8e4662d1b40b45ab10776753


Implement reporting of status to Discord

Using the iTunes interface from #58, the token system from #59, and the settings from #62, re-implement the sending of iTunes information to Discord via Discord RPC.

Closing due to iTunesRichPresence no longer being maintained.


haskell builder: don't copy packages from GHCs

In order to build the package databases that we will use when compiling
a Haskell package, we iterate over the relevant dependencies, and if
they contain a package db, we copy its contents over.
So far so good, except when one of those dependencies is GHC. This
doesn't happen ordinarily, but it will happen when we construct the
package database for compiling Setup.hs.  This is compiled for the
build architecture, so we get the build deps, including both the native
and the cross GHC (if there is one).
In this case, we end up copying the packages from the GHC's package
database. This is at best unnecessary, since we will get those packages
from the GHC when we compile with it.
At worst, however, this is semantically questionable. We can end up
having multiple copies of e.g. Cabal with the same version, but
(potentially) different contents. At the moment, GHC will expose one of
these at semi-random depending on which one it looks at "first".
However, there is a MR open in GHC which as a
side effect will instead expose both, leading to ambiguous module
warnings (which is not unreasonable, since it is ambiguous).
So what can we do about it? The simplest solution is just to not copy
the package databases from GHC. GHC is special in this regard, so I
think it's okay to treat it specially.
This PR should have no effect on anything now, but will prevent any
breakage when/if the GHC patch lands.

I've opened this against haskell-updates - or should it be staging?
I've tested this by building our packages that use the nixpkgs Haskell infrastructure, using this patch and a GHC patched with the change in the linked MR. That builds and works fine on NixOS and macOS.
Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

I use haskell-updates for release-19.03 at the moment. The branch should switch back to targeting master in a day or two, then I'll change pick up this change and merge it.

Merged to haskell-updates in 19e09114ba3088f64ceecaae12bb2052384dd96e. This will go to master once the test builds are complete.

Thanks!

I'm not sure I quite followed the workflow process there, but I'd appreciate it if this got into release-19.03 as well if it hasn't already.


Number of rows that are being displyed is limited

Hi,
Right now, I only can see top 10 rows in the unexpected rows and missing rows categories and most of the time the number of rows are more than 10 rows and these are being skipped for the display purpose and right now don't have any provision to see all the rows.
Is there anyway to extract all rows that are not matched or not expected, if so how and if not, can I except in future release ?
Thanks.
Krishna

Hi,
I have updated the configuration as suggested here (http://www.nbi.io/docs/config-profile-failure-report/) and don't find any difference in the result set. It still displays same 10 rows after making the changes to the configuration file.
Thanks,
Krishna

Same here. I added the following to my .config file:
<nbi testSuite="UnitTesting\UnitTesting.nbits">
   <failure-report-profile
        threshold-sample-items="250"
        max-sample-items="200"
        expected-set="Full"
        actual-set="Full"
        analysis-set="Full"
    />
 </nbi>

But I received the following result back:
<![CDATA[
ResultSet with 140 rows

     KEY (Text) | KEY (Text) | KEY (Text) | KEY (Text) | KEY (Text) | KEY (Text) | KEY (Text) | VALUE (Numeric)  (+/- 0.00)
     ---------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------------------------
     HR         | 2016       | 2          | 500        | 16000      | C0000075   | (empty)    | -750.000000
     HR         | 2016       | 2          | 500        | 16000      | C0000104   | (empty)    | -427.710000
     HR         | 2016       | 2          | 500        | 16000      | C0000229   | (empty)    | -150.600000
     HR         | 2016       | 2          | 500        | 16000      | C0000828   | (empty)    | -11176.170000
     HR         | 2016       | 2          | 500        | 16000      | C0001092   | (empty)    | -686.400000
     HR         | 2016       | 2          | 500        | 16000      | C0001285   | (empty)    | -6.500000
     HR         | 2016       | 2          | 500        | 16000      | C0004611   | (empty)    | -7.700000
     HR         | 2016       | 2          | 500        | 16000      | C0004906   | (empty)    | -6280.000000
     HR         | 2016       | 2          | 500        | 16000      | C0005755   | (empty)    | -3614.000000
     HR         | 2016       | 2          | 500        | 16000      | C0006960   | (empty)    | -2941.500000

130 (of 140) rows have been skipped for display purpose.]]>

Which version of NBi? Should have been fixed in 1.11

Version 11.0.35723

Huuum, it should be fixed according to this thread [https://github.com/Seddryck/NBi/issues/98] Could you try with the preview version attached to this issue or with the official release of 1.12

Hi @Seddryck ,
With 1.12 I managed a successful test. Thanks for your support! This issue may be closed now.


.mkv file type support

Hello, Please update file type support .mkv in plyr.

This is mostly a wrapper of the HTML5 player. Media types support is dependant on the browser and the HTML5 standards hence no .mkv support.

As above. See https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Containers#mp4
You're best off with an mp4 at this point, possibly with a webm if you can.


Unable to install numpy==1.18.4

I cloned this repo and checkout "dependabot/pip/transformers-4.30.0" branch and when I ran,

pip install -r requirements.txt, I get below error, do i need to do anything else.

Collecting numpy==1.18.4
  Using cached numpy-1.18.4.zip (5.4 MB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [58 lines of output]

Any help will be greatly appreciated.

I am running this in CPU on my laptop. Do we need any higher configuration. I tried this both on windows and linux configuration.

i got a different error regarding numpy
i installed cython3 and that was fixed
i got a new error
ERROR: Could not find a version that satisfies the requirement torch==1.5.1 (from versions: 1.11.0, 1.12.0, 1.12.1, 1.13.0, 1.13.1, 2.0.0, 2.0.1)
ERROR: No matching distribution found for torch==1.5.1

im running it in mint os -v 21

Did you use apt-get or pip to install cython3?

fck i cleared my terminal
i typed cython3 to see if that exists
and i was prompted with do this to install cython
i think i dit it with apt
but not sure if i used sudo

the requirements are completely wrong for all of them
altough i was able to download them
they are not recognised untill they are of latest version
im getting runtime errors now

Same with me, when I go latest, I get Runtime error as below

Epoch:   0%|                                                                                | 0/5 [00:00<?, ?it/s]
Traceback (most recent call last):
  File "C:\my-applications\python\Resume-NER\train.py", line 45, in <module>
    train_and_val_model(

...

  File "C:\Users\prask\AppData\Roaming\Python\Python311\site-packages\torch\utils\data\_utils\collate.py", line 138, in collate
    raise RuntimeError('each element in list of batch should be of equal size')
RuntimeError: each element in list of batch should be of equal size
``


Automatic Renewal

I am using the program for a couple of web sites. The automatic renewing of the certificates works so far (new certificates are created and can be found in IIS), but they are not assigned to the corresponding web site, this has to be done manually.
The scheduled task is executing the following command:
letsencrypt.exe --accepttos --renew --baseuri "https://acme-v01.api.letsencrypt.org/"
What do I have to do to assign the new certificates to the (virtual) web server in IIS automatically? Or is this not possible?
Thanks for answers!
Michael

It would be helpful if you could post the output that is written to the screen when you renew the certificate. Then we can determine why it's not working the way you expected it to work.

Thanks for the answer. It is done by the Scheduled Task, so I wonder if there is any kind of log file where I can find some output. What I found in the Windows Event Log was the following:
09:00:04 - Let's Encrypt Windows Simple (LEWS)
09:00:04 - Software version "198.4.6605.15190" ("RELEASE")
09:00:05 - Renewing certificate for "www.mydomain.com"
09:00:22 - Adding certificate "www.mydomain.com 2018.6.1 9:00:15 " to store "WebHosting"
09:00:22 - Removing certificate "www.mydomain.com 2018.4.6 9:00:18 " from store "WebHosting"
09:00:22 - Renewal for "www.mydomain.com" succeeded
09:00:22 - Next renewal scheduled at "2018.7.26 7:00:22 "
So obviously it gets a new certificate, removes the old certificate but does not assign the new certificate.
Best wishes
Michael

It seems like you haven't set up any installation steps for these renewals. How have you initially created them? Manual input I guess? The program will not try to update IIS unless it's told to install to IIS. You should re-create the certificates in simple mode (which automatically sets up IIS installation) or use advanced mode and select the IIS plugin when it asks for installation steps.

Thank you, I am trying this, and will give Feedback in two months (so please don't close it, I will when it worked)
Just a question of interest: What is missing in the command line that I used to set up the certificates?
letsencrypt.exe --accepttos --plugin manual --manualhost www.somewebsite.com --webroot X:\Sites\somewebsite.com
Best wishes
Michael

Here are the parameters for IIS installation: https://github.com/PKISharp/win-acme/wiki/Installation-plugins#iis-web
If you want to try if it works without waiting two months you can just force a renewal by the way 😄 from the command line --renew --forcerenewal or from the GUI "renew specific".

Thanks, that worked perfectly.
Best wishes
Michael


Adding Animation

Describe the feature

Your landing page already looks fantastic, but incorporating animations could make it even more captivating. With my experience in this area, I'm eager to contribute to this enhancement.
If you could assign me this task under GSSOC24, I would be thrilled to work on it.

Add ScreenShots

On hovering the cursor on the image you can see the animation
I would like to add this feature on you site
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Assigned!


fix(annotation): use the same out target property as drawOutsideTarget :)

:tada: This PR is included in version 1.0.0-alpha.12 :tada:
The release is available on npm package (@alpha dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.11 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.1 :tada:
The release is available on npm package (@alpha dist-tag)
Your semantic-release bot :package::rocket:


Migrate zulip-archive to GHA cronjob

We should move the zulip-archive onto GHA, which should also let us keep it in closer sync with upstream (we've fallen considerably behind). https://github.com/zulip/zulip-archive#running-zulip-archive-as-a-github-action describes how to set it up.

This is done -- https://github.com/rust-lang/zulip_archive/!


openrct2: 0.3.2 -> 0.3.3

Motivation for this change
Bump OpenRCT2 to its latest release.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 116402 at 226be786 run on x86_64-linux 1

1 package built successfully:

openrct2

1 suggestion:

warning: unclear-gpl
gpl3 is a deprecated license, check if project uses gpl3Plus or gpl3Only and change meta.license accordingly.
Near pkgs/games/openrct2/default.nix:76:5:
   |
76 |     license = licenses.gpl3;
   |     ^


vulnerable dependency kind-of

This package's dependency kind-of has vulnerability CVE-2019-20149. The problem would be solved by upgrading to the latest version of kind-of. See #2 (test passes on the branch)

Any update on this?

I created similar tickets for packages that @jonschlinkert manages.  As of now, I haven't heard back from him.
https://github.com/doowb/set-getter/issues/2
https://github.com/jonschlinkert/lazy-cache/issues/9
https://github.com/jonschlinkert/repo-utils/issues/3
Jon might not be available anymore to maintain those packages. That's bad news considering the number of daily downloads each of the packages have.
I ended up publishing an updated version of repo-utils.  I will probably do the same to the rest of the packages as well.

I forked the repository and published a new package to NPM.  The new package uses the latest dependencies and as of now, has no other security vulnerabilities.
New repository: https://github.com/OronNadiv/to-object-path
New NPM Package: https://www.npmjs.com/package/to-object-path-js

The linked CVE specifies kind-of >= 6.0.0 and < 6.0.3. Version 3.2.2 does not fall within this range, which is fine to use here. Some additional discussion can be found here.
Since the update isn't necessary by itself, I'm going to close this issue and we'll update the dependency next time we update this module.


[Swift APIView] Fix issue with throwing inits

Recent refactor dropped throws annotations from throwing inits. This PR restores them.

@mpodwysocki please take a quick second look. Here's the APIView diff that shows it only has the intended side effect on Chat.
https://apiviewstaging.azurewebsites.net/Assemblies/Review/0bd4804692e14f59a3361cfcc27ede12/acb4a15d16aa447db8729d90337f9b1e?diffRevisionId=98638d35f71c4b6b9fe16deb53a77f1d&doc=False&diffOnly=True

@mpodwysocki please take a quick second look. Here's the APIView diff that shows it only has the intended side effect on Chat. https://apiviewstaging.azurewebsites.net/Assemblies/Review/0bd4804692e14f59a3361cfcc27ede12/acb4a15d16aa447db8729d90337f9b1e?diffRevisionId=98638d35f71c4b6b9fe16deb53a77f1d&doc=False&diffOnly=True

Yes, that change looks good now


[android] Android App Bundle

https://developer.android.com/platform/technology/app-bundle

It really reduces the size of the app by 50% without any issue.

I'm just wondering the acrobatics we'll have to do to distribute our app.
If we distributed installers for each architecture it would reduce even more than 50% since we include a bunch of dynamic libraries for all architectures ARM32, ARM64, x86 and x86_64
Will most likely try to get this ticket out the door for our next release

Finally got this one down, indeed it reduced the app size by 50% in the best case.

Told you.


[ Feature Request] Gas Multiblock Tanks

Hi there. Im not shure but that dosent exist i think and it would be really awsome to have Multiblock Gas Tanks like the Fluid one

Rotary Condensentrator + Dynamic Tanks


Process idea: Make a long list of all classes and properties to foster discussion and the decisions

I was thinking on how to get an overview of where we are and what is still to be done - and how to foster systematical approving process to what we are working on. I'm not sure if Protégé has a way to do the following, so here is just a random idea I was thinking on:
Idea: We could (automatically) create a long list of all classes and properties (object, data) e.g. as an CSV file, that could be uploaded to Google spreadsheet.
For example, each class would be on a separate line. And in the next column would be the status of the class: "approved" / "not approved" / "feature suggestion" ...
Such lists could be made for fostering e.g. following discussions:

class hierarchy -- each subclass relation correct and approved, each line would contain one class relation e.g. Group -- subclassOf Asset ==> approved / not approved
class name
class description
property name
property hierarchy
property domain
property range
...

...If Protégé or Github supports such systematical way of going through these things, even better.
Such list approach could perhaps be the way of working when we have the big cleaning first done.
If you think this list approach could be useful, I can probably quite easily write a script that reads the OWL file and creates the lists (e.g. csv files) automatically.

This can be done by adding a kind of status annotation property and using this.
With a sparql query, you can make your table of course.

Using this branch https://github.com/tormodv/ccdm/tree/StatusProperty
Try this query:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX ec: <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#>
SELECT  DISTINCT *
	WHERE {
	_:a rdf:type owl:Class .
	_:a rdfs:label ?label .
	_:a ec:status ?status .
}

Manually maintaining the documentation in Confluence and keeping it in sync with the model file(s) would come along with respective efforts and up-to-dateness risks. To address that, I (like Tormod) propose to maintain the documentation rather directly within the Ontology and export it to Confluence, or any other documentation target. Maintaining the documentation at the same place together with the model would make it easy to manage and synchronize improvements and extensions.
We already have and use various annotations that document the CCDM entities, and we could easily add some further ones if required - or use "EntityStatus" individuals for annotation instead of numerous literal annotation properties (TBD). Some SPARQLs could easily generate lists of classes and their properties including their constraints and expose relations, directly based on the owl contents. We plan this anyway already for the CDK. Strategically, we could achieve a single source of truth here, with which we can maintain and version control the model and its documentation in a single OWL file and make both machine-readable and reusable from there. Also, we would remain open for potential further internationalization as well as any other kind of documentation target in the future, in any environment, with pretty few effort.

With the recent reports, I prepared such lists. I could refine them, such that they can be exported to Confluence. However, the question is, if we not just wanted to maintain them in Ontologies and export them e.g. to Excel in case needed. TBD.


Line Shift

If we select more than one line and do CTRL + C then CTRL + V, the pasted line will shift.
But it does this often, though not always.
Edit: Especially PHP files.

@ReturnMe Can you please better explain what the problem is? I have tried selecting a bunch of lines and pasting them, and I do not notice any shifting.


Relationships: create a blogpost referencing existing author?

Currently in docs example it would create a new author every time creating a blog post, but would it be possible to pass ID of existing author entity and avoid duplication?

https://docs.chiselstrike.com/reference/entity-crud-api/relationships#add

For that, you would want to use an indirect relationship using an Id<> type field.
https://docs.chiselstrike.com/reference/data-modeling/relationships#indirect-relationships


Add new category

Add new category "Event aggregator and messenger". Move Mediator.Net and MediatR. Add new Rx Event Aggregator and TinyMessenger

I create new PR with new cat #571


Change logger summary output for elastalert compatibility

Description
Change logger summary output for elastalert compatibility
Changelog

Broke summary output down from having all the information under the "event" to separate fields, that elastalert can parse
Also standardized event message so that elastalert can pull all the summary messages.

Superceded by #1130


update packages

:white_check_mark: Build TheIdServer 2.0.1-fix-dependencies1-0021 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/4e57a03dfe by @)


update(readme): modern eBPF probe has feature parity and is out of wip.

What type of PR is this?
/kind documentation
Any specific area of the project related to this PR?
Does this PR require a change in the driver versions?
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/cc @Andreagit97
:P
/milestone 0.11.0

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, jasondellaluce
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, hbrueckner, jasondellaluce
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Opt-in to set Connection:Close on downstream requests

Fixes / New Feature #

There's certain scenarios where Connection:Close is needed (i.e. disabling persistent http connections). This PR let's us be able to configure ConnectionClose: true|false under GlobalConfiguration or per Route in the Ocelot configuration files.

Proposed Changes

If ConnectionClose is set to true in configuration, add the Connection header with value Close to indicate to the server to not keep the connection open

Side note: When benchmarking this on Azure Kubernetes Service (AKS), we observed that we got a higher throughput when running with Connnection:Close than using the Ocelot.Provider.Kubernetes package (which queries the Kubernetes API prior to sending each request). This is one scenario where this PR is beneficial.

Build failed, probably fixed by #1436 ?

Please do the following:

Merge PR 1
Rebase feature branch onto develop
Resolve all merge conflicts

@bjartekh  Hi Bjarte!
I thought you needed some help to resolve conflicts. 😉
The feature branch has been rebased onto ThreeMammals:develop successfully!
Welcome to code review!
Good luck!

I see that develop branch in your fork is too old.
Could you Sync fork please? So, the develop branch will be updated with all top commits!
Could you add me as collaborator to your forked repo please? I will update develop branch.

The build is 🟢  Wow! 🤯 😻

@bjartekh, are you available? Could you please continue working on your pull request?


Enable compilation with Jack

Jack toolchain is deprecated since 20170314, so it's not worth enabling now.
https://android-developers.googleblog.com/2017/03/future-of-java-8-language-feature.html
https://sites.google.com/a/android.com/tools/tech-docs/jackandjill


no config helper from user side

Description
Removes the Config helper class from user side

PR changing the example app:
https://github.com/aerogear/cordova-showcase-template/pull/6


Possible to to download movies ?

is it possible to download movies that  i bought with python and sync it with the library ? iTunes produce horrible speeds ..i tried with IDM but that don't work bcs i can't play the file maybe library sync issue .

Hi! What’s your use case with itunespy in this case? As far as I known there’s no way to download movies through this API since there’s no authentication.
Sent with GitHawk

Thanks for the reply ...the thing is download speed with iTunes is very maybe that is itunes.exe limitation that's why i wanted to know if it was possible to download movies or songs with a python based downloader so that i can play it with itunes offline

As far as I know there's no way to do it through this API, since you can only retrieve public resources and not things that require authentication. Good luck with your search, though!


Unable to get response from third party api...

Hi,
I am trying to fetch movies/tv-shows info using alluc.ee API (http://wiki.alluc.to/API-access)
but it is giving me 500 error.. the weird thing is when i use postman or browser for GET request...
https://www.alluc.ee/api/search/stream?user=gkrwxi229akhjsn&password=gkrwxi229akhjsn&count=99&from=0&getmeta=0&query=The Maze Runner+2014+movie+lang:en+host:openload.co

it's working perfectly fine. but from server side it is giving me Captcha error...
this is the link of hosted application => http://<IP_ADDRESS>/test

any help would be appreciable

I think this is unrelated to adonis, you'd be better off asking on Stack Overflow, try including the code you're using to make the request.
That said... the api could have captcha protection for specific user agents.

thanks, as it is not relevant .. closing this...