So far, I cannot reproduce the problem (Linux). For a newly started game turning the TV on/off does not break the hover (note that switching on is not done using the off-button, but using a channel button).

My assumption is that even a savegame might not help. I don't know if I can make myself clear. The savegame does not contain absolutely all data and not all game status is persisted and taken from that data. That is, if something is broken internally and not "repaired" by loading the game, it remains broken (e.g. maybe the broken hover for the TV). Likewise, not everything broken is transferred to the savegame. So maybe the hover status is not persisted and loading in a freshly started game will not have the problem anymore.


The commits of this change were taken to merge to the 4.8.0 branch, a complete deployment was tested with 3 `Wazuh indexer` nodes, 1 `Wazuh dashboard`, 1 `Wazuh manager` master and 1 `Wazuh manager` worker and the deployment was carried out successfully.

$node1host = '172.31.23.191'
$node2host = '172.31.28.121'
$node3host = '172.31.24.156'
$masterhost = '172.31.28.245'
$workerhost = '172.31.28.97'
$dashboardhost = '172.31.31.95'
$indexer_node1_name = 'node1'
$indexer_node2_name = 'node2'
$indexer_node3_name = 'node3'
$cluster_size = '3'
$indexer_discovery_hosts = [$node1host, $node2host, $node3host]
$indexer_cluster_initial_master_nodes = [$node1host, $node2host, $node3host]
$indexer_cluster_CN = [$indexer_node1_name, $indexer_node2_name, $indexer_node3_name]
# Define stage for order execution
stage { 'certificates': }
stage { 'repo': }
stage { 'indexerdeploy': }
stage { 'securityadmin': }
stage { 'dashboard': }
stage { 'manager': }
stage { 'agent': }
Stage[certificates] -> Stage[repo] -> Stage[indexerdeploy] -> Stage[securityadmin] -> Stage[manager] -> Stage[dashboard] -> Stage[agent]
Exec {
 timeout => 0,
}
node "ip-172-31-26-67.us-west-1.compute.internal" {
 class { 'wazuh::certificates':
 indexer_certs => [["$indexer_node1_name","$node1host" ],["$indexer_node2_name","$node2host" ],["$indexer_node3_name","$node3host" ]],
 manager_master_certs => [['master',"$masterhost"]],
 manager_worker_certs => [['worker',"$workerhost"]],
 dashboard_certs => ["$dashboardhost"],
 stage => certificates,
 }
 class { 'wazuh::repo':
 stage => repo,
 }
}
node "ip-172-31-23-191.us-west-1.compute.internal" {
 class { 'wazuh::repo':
 stage => repo,
 }
 class { 'wazuh::indexer':
 indexer_node_name => "$indexer_node1_name",
 indexer_network_host => "$node1host",
 indexer_node_max_local_storage_nodes => "$cluster_size",
 indexer_discovery_hosts => $indexer_discovery_hosts,
 indexer_cluster_initial_master_nodes => $indexer_cluster_initial_master_nodes,
 indexer_cluster_CN => $indexer_cluster_CN,
 stage => indexerdeploy,
 }
 class { 'wazuh::securityadmin':
 stage => securityadmin,
 }
}
node "ip-172-31-28-121.us-west-1.compute.internal" {
 class { 'wazuh::repo':
 stage => repo,
 }
 class { 'wazuh::indexer':
 indexer_node_name => "$indexer_node2_name",
 indexer_network_host => "$node2host",
 indexer_node_max_local_storage_nodes => "$cluster_size",
 indexer_discovery_hosts => $indexer_discovery_hosts,
 indexer_cluster_initial_master_nodes => $indexer_cluster_initial_master_nodes,
 indexer_cluster_CN => $indexer_cluster_CN,
 stage => indexerdeploy,
 }
}
node "ip-172-31-24-156.us-west-1.compute.internal" {
 class { 'wazuh::repo':
 stage => repo,
 }
 class { 'wazuh::indexer':
 indexer_node_name => "$indexer_node3_name",
 indexer_network_host => "$node3host",
 indexer_node_max_local_storage_nodes => "$cluster_size",
 indexer_discovery_hosts => $indexer_discovery_hosts,
 indexer_cluster_initial_master_nodes => $indexer_cluster_initial_master_nodes,
 indexer_cluster_CN => $indexer_cluster_CN,
 stage => indexerdeploy,
 }
}
 node "ip-172-31-28-245.us-west-1.compute.internal" {
 class { 'wazuh::repo':
 stage => repo,
 }
 class { 'wazuh::manager':
 ossec_cluster_name => 'wazuh-cluster',
 ossec_cluster_node_name => 'wazuh-master',
 ossec_cluster_node_type => 'master',
 ossec_cluster_key => '01234567890123456789012345678912',
 ossec_cluster_bind_addr => "$masterhost",
 ossec_cluster_nodes => ["$masterhost"],
 ossec_cluster_disabled => 'no',
 stage => manager,
 }
}
 node "ip-172-31-28-97.us-west-1.compute.internal" {
 class { 'wazuh::repo':
 stage => repo,
 }
 class { 'wazuh::manager':
 ossec_cluster_name => 'wazuh-cluster',
 ossec_cluster_node_name => 'wazuh-worker',
 ossec_cluster_node_type => 'worker',
 ossec_cluster_key => '01234567890123456789012345678912',
 ossec_cluster_bind_addr => "$masterhost",
 ossec_cluster_nodes => ["$masterhost"],
 ossec_cluster_disabled => 'no',
 stage => manager,
 }
}
node "ip-172-31-31-95.us-west-1.compute.internal" {
 class { 'wazuh::repo':
 stage => repo,
 }
 class { 'wazuh::dashboard':
 indexer_server_ip => "$node1host",
 manager_api_host => "$masterhost",
 stage => dashboard,
 }
}

In addition, the documentation was modified so that the distributed example does not try to install Wazuh agent on the nodes and the commits were moved to merge to the `4.8.0` branch of `wazuh-documentation`.


Well, the reason was that we were (read: I was) was working from URL which has the states but not a proscription on how they're exposed. Personally, I'm inclined to follow the web idl definition now that I know it exists. What do you think, @jasnell? Maybe we either just add the web idl def form or compat flag in the change to the web idl def form?


The channel tooltip is only visible when the game is not "paused".

If the game is not paused the game logic for "button reaction" is a simple check of the "mouse position" (for hover) and "click" (for activation)

Maybe that "paused" thing is what borks it for @scr0llbaer9000


Like not worth a compat flag as long as there are no conflicts in the names. Let's just add the additional ones from the spec alongside the current set. If we want to deprecate the old names later we can do so with a compat flag then.


The error is caused by very long programme titles, e.g. "Dynamit - Das Magazin Spezial: Prince Carl und Lady Dee (5/5): Dynamit Prince Carl und Lady Dee Spezial - Schlussfolge (Block 1/1)".

If the tooltip width exceeds the screen width, the tooltip is moved to the left (base.framework.tooltip line 154). There is no guard that the resulting x position remains positive. And possibly the calculation of the delta is also buggy, because with x-position 41, tooltip width 830 and screen width 800 the resulting tooltip x-position after moving is -3839.

Potential TODOs:
* check and possibly fix calculation of tooltip-deltas
* improve framework, so that original x-position is stored and is restored if title/content change (moving tooltip is only temporary)
* tooltip title is single line, so programme tooltip should possibly ensure the title passed has a maximum length


While this of course is a bug in the framework I have to ask:

Seriously? I mean ... seriously? Titles should be way way shorter - so that the ellipsis (...) does not cut away important parts and the title is still distinguishable from other elements of that series/franchise.


I guess the length of the title is due to it's being a series episode. I would not extend the framework to allow multi-line tooltip headers! This is an absolute border case. Ensuring that the tooltip does not permanently disappear from the screen should be enough. (Making sure the resulting x coordinate is not smaller than 0 and restoring it to its original value should be enough).


So in case `urlConfig` or some other configuration setting would be changed in `remark-validate-links` (unlikely, given that this project is GitHub / GitLab / Bitbucket focused), maybe it could work like this:

Config:

js
baseDir: '/src/pages',
extension: 'mdx',

`src/pages/lib-1/index.mdx`

mdx
To read more, check out the docs about `lib-2`!

The link above would be resolved to the file ` /src/pages/lib-2/docs.mdx`


Good to hear the feedback here that it has started to work for some of you. Just for awareness, the PG is still actively working on completing implementing this scenario. This means for now that it might already work for you, but specific scenarios, such as when you're using taxonomy driven user profile fields, might not work yet. Keep this in mind when switching to the Azure AD / Entra ID option. Test everything thoroughly. If it works for your use case, you're good to go, if it doesn't yet, bear a little longer with us, it's still work in progress.


hello @chrisjbryant
I think the error comes from the code you provided.
you should process the text with **nlp function** before doing the for loop like this:

`doc = nlp(sent)`


your code should look like this :

`nlp = spacy.load("en_core_web_sm")
sent = "I didn't go to the bank at the weekend."
doc = nlp(sent)

for tok in doc:
 print(tok.text, tok.lemma_)
`


`I -PRON-
did do
n't not
go go
to to
the the
bank bank
at at
the the
weekend weekend
. .
`


I -PRON-
did do
n't not
go go
to to
the the
bank bank
at at
the the
weekend weekend
. .


@bcaimano ... as a follow up here, but only partially related to this issue... at some point in the not too far off future we really need to go through an audit just how far our implementation of `WebSocket` strays from the standard API definition. We may not necessarily close those gaps but we at least want to document them more thoroughly. Just something to keep in mind as you're thinking about this.


I got the error: the current user has insufficient permissions to perform this operation for:
SetMultiValuedProfileProperty
SetSingleValueProfileProperty for property: SPS-Location

 However, SetSingleValueProfileProperty does work for other custom properties

I use PNP.framework, set ClientContext using new AuthenticationManager().GetACSAppOnlyContext(siteurl, clientid, secret)

 Thanks


Ah! My bad, that was a mistake in my demo code above.

I did some more testing as the error appeared in my code when I upgraded spacy in my app, but when I test a clean spacy install, lemmatisation works as expected. So most likely not a spacy problem!


My bad, that was a typo in my example code. I have updated it now. The error is still present in spacy.


Hi @chrisjbryant, can you set up a fresh virtual environment and run this script there? I can't reproduce this. If I run

python
import spacy
print(spacy.__version__)
nlp = spacy.load("en_core_web_sm")
sent = "I didn't go to the bank at the weekend."
for tok in nlp(sent):
 print(tok.text, tok.lemma_)

my output is:

3.7.2
I I
did do
n't not
go go
to to
the the
bank bank
at at
the the
weekend weekend
. .


I was previously using a conda env, but just tried with venv and same result. :/

Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

3.7.2

... print(tok.text, tok.lemma_)
...
I I
did did
n't n't
go go
to to
the the
bank bank
at at
the the
weekend weekend
. .


Huh, after noticing I ran this with Python 3.9 I set up a clean venv with Python 3.10 - there I can reproduce this. We'll look into it.


I can confirm that this is a bug. A few of the attribute ruler patterns were switched from `LOWER` to `NORM` in v3.7.x (to generalize a bit better overall), but "did" is already normalized to "do" by the tokenizer, and then the "did n't" pattern no longer matches as intended.

You can add the old rule back to the current `en_core_*` models as a workaround:

python
nlp.get_pipe("attribute_ruler").add(
 patterns=[[{"TAG": "VBD", "LOWER": "did"}]],
 attrs={"POS": "AUX", "LEMMA": "do"},
 index=0,
)


Just to make sure, don't forget to check other cases too, since I now also recreated it with `hadn't`!


Yeah, we'll review all the changes. (The underlying idea was to use `NORM` to match more variants of contractions with apostrophes.)


Yeah sure that is redundant in that case here and can be shortened.

But in general, such long titles (especially in series when combining general and episode title) can exist.


But not when clicking the power button, right?

Is there a misunderstanding here?

The expectation is absolutely that, just as in real life, when you switch the TV off with the main black power button, you can also switch it on again with the black button (as was the case in Mad TV afair). And I figure it is still reproducible that this doesn't work?

I indeed was wrong in OP that the TV was broken "indefinitely", as it can be switched on again by clicking on one of the channel buttons. For some reason it didn't dawn on me to try that. `:)`


I might have remembered wrong about old TVs... But for me they are simply 5 "switches". Press one and the others are deactivated.
So power off will switch off other buttons too etc.

Of course this can be changed. Guess that code is around 15 yrs old now ;-)


yeah the 4 channel buttons can be switches, but the power button is its own thing.

When switching on with the power button, the last "active" channel can be shown again.
(In real life, channel buttons on most TVs weren't switches either though, the last "state" was not remembered, and channel 1 was shown when switching on.)


I believe data.table was made to play nicely with any package, by following many conventions from base R.
Making a "seal approved" may give an impression that some packages works better with data.table, while others don't work well or don't work at all with data.table...

Rather than having community of packages I would prefer to have all packages to be in a community.


Thanks for your feedback on it. I agree that data.table is nicely designed to work well with all sorts of packages (and in ways that are not always obvious!). I don't think our intention would be to say there are certain packages that work best with data.table and others don't. The goal would be to help build the community around data.table. This was just one idea of how we could engage more R users and get them into the data.table repository more. We would also hope that it would spawn more ideas of how to use data.table with other packages, across more situations. The documentation (and other resources) are vast on data.table but I think there is still a lot of users that don't find it (and how to use it) early enough.

Do you have other suggestions on how to make entry into data.table use and development easier?


I have been using data.table as a user, but I know that many parts have been written in C. I have no clue where I could start to learn C to make meaningful contributions.

I would like to have some guidelines for novice users who want to contribute to data.table.


Is there anything besides an approval process {data.table} maintainers would be committing to as part of this?

Would the approval be granted in perpetuity / renewed regularly / granted with possible revocation under "certain circumstances" (which)?


For simplicity, my suggestion would be to show the channel of the "active" player when switching on, again.


I was on the same boat, reading code of PRs was quite useful, but what was game changer is to start coding, I started with rolling mean. Then I received great feedback in my PRs, mostly from Matt, so it was easy to pick up good practices. Often I draft naive version in R, to reflect how I will code it in C, I might even skip using functions like `sum` and code it as a for loop.


An immediate solution would be to use a custom admonition that is collapsible. With some tweaking, this could be made to look similar to what Amazon do - if, say, you do not like the border around the admonition. If you use the block syntax that the Pymdown Extensions provide then you don't have to worry about indentation as much.


Just a heads up. This was a tooling issue. Resolved in my AOT generation sequence:
 URL

What I did uncover in my investigation to resolving this was that some apps worked fine with gen_snapshot obfuscation disabled, some did not. The Flutter Package examples worked, while Gallery and Wonders did not. Enabling obfuscation enabled Gallery and Wonders to work as expected. I raised this on the hacker-tools discord channel.


More specifically, you could try and adapt what I've done here: URL The example was specifically targeting code blocks, but it could be adapted for any content.


Source of the project you are going to contribute to.
And which function... The one that doesn't exist yet :)


@AngelFelizR The r-contributors slack (r-contributors.slack.com) hosted a book club on learning C for R users last year:

 URL

I believe there are videos still available; try asking in the `#book-club-modern-c` channel there. Otherwise expressing new interest is a way to get the book club running a second time (others have already inquired).


As for data.table's own C code, I think the most straightforward stuff would be:

 - cj.c
 - coalesce.c
 - fifelse.c
 - idatetime.c
 - nafill.c
 - rbindlist.c
 - transpose.c


@MichaelChirico, thank you for your advice. I hope to contribute C code in the long term to continue progressing this amazing project.

I want to be prepared to the point where we can task moving data.table to work with data on disk.

I am here because the data.table survey asked if I wanted to contribute, so I started reading the issues.


Thanks for suggesting! We'll evaluate this as a potential change request in the future. If you want to go ahead and check if you can find any potential approaches how this can be elegantly solved, feel free to share them here!


This issue should be closed after adding the mirror attribute (true, false) to the camera plugin itself


Oops. Somehow missed that last comment. I'll respond with details in a few minutes.


1. I'll try to bump logging and attach. If I can reproduce with my bare bones example project, it'll be pretty straightforward, otherwise I need to do some log cleanup and might take a bit.

2. I may be confusing things with terminology. I have a multi-root workspace with ~60 defined roots. All but 5-6 of those have their own Python environment defined with pytest tests. We do have them organized into smaller subsets (e.g. stages, packages, etc. as I described above), but from a VSCode view, everything is on one level, so my roots might be:

 packages :: A (./packages/A)
 packages :: B (./packages/B)
 stages :: C (./stages/C)
 stages :: D (./stages/D)

 When I'm refreshing tests, I might see the tests for `packages :: A`, then refresh and see only the tests for `stages :: C`, but never all of the tests.

3. Those are pytest plugins, not VSCode extensions. Can't really disable them because they're in use by our tests.


Thanks again for the report, we've updated this in the internal attribute ruler data and added a test to `spacy-models`, so let's hope this is fixed in the next round of pipeline releases (probably pipeline version v3.8.0).


That test run is from this example repository. It replicates the behavior I see on my real project and answers your question 3 above since it doesn't use any pytest plugins. It's also almost identical in structure to my real repo (question 2), though that's grown by a few roots since I created the example.

 URL


Users are heavily impacted by this, so I would like to bump this to critical, with a focus on fixing timers. Timers are different from message correlation has they don't involve inter-partition communication, which may help narrow the scope of the fix for now (i.e. writes are guaranteed to succeed).

That said, I noticed some possible concurrency issues with the `DueDateTimerChecker`, which could lead to more timers than required being scheduled under high load.

If enabled, the `DueDateTimerChecker` runs in the asynchronous scheduler actor, separately from the stream processor.

However, both actors will access the `DueDateTimerChecker`:

`DueDateTimerChecker#scheduleTimer` is called from the engine/side-effects, i.e. processing actor. It then:

- Accesses the following state: `shouldRescheduleChecker`, `checkerRunning`, `nextDueDate` (rw)
- Checks if the checker is currently running. This is a non-volatile boolean check.
- If it's not running, it schedules a task.

At the same time, scheduling is done on the async scheduler actor. This is the `TriggerEntitiesTask`. It:

- Accesses the following state: `shouldRescheduleChecker`, `checkerRunning` (rw), `nextDueDate` (rw)

Is this correct? If so we have non-volatile state being accessed by two different actors, and possibly some race conditions on when and if to schedule the next timer.

Moving on the the possible solution. In order to keep it light of course, we'd need to to have a way to identify a timer trigger uniquely. Since every time instance can only be scheduled for trigger once in the state, it should be enough to distinguish them with the timer key, which is a single long.

The general idea, then, is to cache locally in the `DueDateTimerChecker` state (or some state) which commands have been written, so as to avoid writing them again. A perfect cache would be unbounded - you'd have to possibly store as many timers in there as could possibly exist (worst case scenario). But a lossy cache is probably acceptable. Take `LongHashSet` from Agrona - an empty, pre-initialized set instance of 1 million keys takes 8MB of memory. Filled, it takes about twice, ~16MB. It's a bit hard to add LRU behavior to such a set however. Eviction could be random to keep things simple/fast, or we can use a `SortedSet`. However, a `TreeSet` takes about ~60MB for 1 million longs, so it's already substantially heavier - but it's pretty easy/fast to add LRU eviction to it. So on the off chance the key was evicted _before_ it was removed explicitly from the cache, you'd potentially still write a second trigger command. But the bigger the cache, the less likely this is to happen.

I sync'd with @Zelldon today about this, and we decided to move forward with the local cache, only for checkers which perform no inter-partition communication.

For timers, we'll use the timer key as the unique cache ID. When iterating of timers, if the timer key is in the cache, then we skip it. Once the task result is built, we can populate the cache with all the timer keys we will be writing. Since the scheduler (even async) is sequenced, we're guaranteed that this write will succeed, or the whole thing will fail (and the cache would be "restarted"). We won't be touching things like leader election and so on. On recovery, it's still possible that the same timers would be triggered twice, but the overload load will be greatly reduced.

This solution is likely adaptable to other checkers which run locally, such as job timeout and message expiry. For messages we can easily use the key. For jobs, we can't use the job key, since you can have multiple activations/time outs. We could use the job key if we can guarantee that the cache is properly cleaned up whenever the job is activated.

Anyway, long winded comment to say we'll get started on a bounded lossy cache-based prototype.


I've been thinking recently that instead of a full-blown installation of Dribdat, a hackathon organizer should be able to quickly generate a `hackathon.json` or META-tags for the Schema.org spec using a simple tool, like a one-page app with a form to fill out, a CSV to upload or paste in - and then they can do what they want with the generated file. In this project, we could also then use the backboard app to offer quick visualization or static-site deployment of the hackathon for archiving purposes.


another way to contribute, even without knowing much about how data.table works (in C or otherwise), is to look at the open issues, and try to see if you can reproduce a bug report, then add a comment on the issue that explains what you did and whether or not the issue is reproducible. (and if you can make a simpler example than what is reported, that is even better)


Hello, thank you for the detailed logs and all the notes I really appreciate it. I am going out of office for the next 3 weeks and therefore will not be able to help in this time. I will loop in @karthiknadig in case you have outstanding questions to get by in the meantime.

Additional, @karthiknadig do you know what this log is saying / if it might impact?

2023-11-06 14:16:30.540 [warning] Failed to check if /alt/source/vscode-test-discovery/group1/group1_p3/.venv/bin/python is an executable [Error: ENOENT: no such file or directory, lstat '/alt/source/vscode-test-discovery/group1/group1_p3/.venv/bin/python'] {
 errno: -2,
 code: 'ENOENT',
 syscall: 'lstat',
 path: '/alt/source/vscode-test-discovery/group1/group1_p3/.venv/bin/python'
}


So, several of our projects don't have Python environments but it seems like the Python plugin tries to find the virtualenv anyway. I left that configuration in the example so it mirrored my actual project. Those are the Node errors that get thrown when it tries to find `${workspaceRoot}/.venv/bin/python` and it doesn't exist.


realized now this isn't the problem- seeing other messages elsewhere which show it did run and this was just a warning.


New thought actually, @karthiknadig what do you think about the theory that in this multiroot workspace case the results are attempting to be parsed by the wrong adapter (like an adapter from a different workspace) instead of the one which it actually correlates to. Therefore it would error out all the other workspaces instead of just letting them wait for their response to be returned. Thinking `this._onDataReceived.fire({ uuid: '', data: '' });` this line here if deleted might lead to success since it doesn't cause unsuccessful resolves on other workspaces. But I am unsure if I am getting the multiroot scenario correctly @karthiknadig for this to be true


That makes sense. This should get addressed when we use the per-run named-pipe server.


Just to confirm: are you saying that if you pass `--obfuscate` to `gen_snapshot` then thing work _correctly_ and if you do **not** pass `--obfuscate` then things work _incorrectly_? I am a bit puzzled.


@mraleph

Correct. It's as if in the non-working case it's taking an alternate entry. Non-working cases default to platform channel.

The other pattern I determined is the working cases are all "local" packages. The non-working case use "remote" packages.

Not sure if Android and iOS default to having obfuscation set. If so that might explain why it's now showing up.

There was another issue a while back about obfuscation breaking dart registration I was looking at. Which introduced the --source solution.


After this change we got several complaints from those who still uses Specify 6 for work.
I copy one detailed report here:

 “Since last week I have had an issue when opening Collection Object-forms, or opening new or existing Collection Object Attachments:
 Multiple pop-up windows with “An Issue of Concern” appear – I have attached jpeg-screencaps of the four different types I have identified.
 Also, it seems that the Collection Object Attachment-form has been expanded with new fields – I have attached another screencap of this.
 Could you please fix this; the pop-up windows appear *every* time I open Collection Object or Collection Object Attachments and being force to close the windows *every time* is wasting a lot of time, when I am working in Specify.”

Fix is needed.


@bobcolner thanks for reporting. SSO configs may not yet be fully supported


So in the end, we'll build the cache on the stream processor side. I describe the approach we ended up with in the description of this PR: URL

Let me know if you have questions. For now it's entirely on the stream platform/ZDP side, but it's still useful to know how it works. Plus, if you want to cache future scheduled commands in the future, you'll need to know where to add them :upside_down_face:


@deepthidevaki and I looked into this a bit from the angle of "let's improve flow control in general". In particular, URL was at the back of our minds.

We think that a first step in the right direction would be to remove the `LogStorageAppender` in general and replace it with a simple limiter that sits in front of the `Sequencer` to protect the raft thread from overloading it with too many writes. We think that a fixed limit or a simple RTT based limit would work well for this.

As a second step, we can move the flow control for user commands away from the `CommandApi` and implement it in front of the `Sequencer` instead. The idea here is to have one common place where flow control for commands is implemented. User commands would then acquire permits from two limiters, the configured one for user commands (AIMD by default), and the raft thread limiter.
To implement this, I propose a new class that sits in front of the `Sequencer`. The `Mixer` would decide which flow control to use, based on the _source_ of records. Sources would be _User Commands_, _Processing Results_, _Internal Commands_ and _Remote Commands_.

**After implementing the first two steps, the system behavior should remain almost the same**. User commands go through a configurable limit while other records such as processing results, internal commands (e.g. timer triggers), and remote commands (e.g. message correlation) are only held back by the limiter that protects the raft thread.

Building on top of this, we can think about adding flow control for _Remote Commands_. The challenge here is that we probably can't just drop commands silently. Let's take message correlation as an example: When a _Correlate_ command is sent to a remote partition, the sent time is updated immediately and the correlation is only attempted again after 10 seconds. If we were to introduce a limiter for remote commands, we might run into problems because every dropped command will result in at least 10 seconds of delay. Ultimately, a solution similar to URL would be desirable. The difference here is that we must wait for the command to be received, written _and committed_ on the remote partition. Currently, this is not possible because inter-partition communication is a one-way channel from sender to receiver.
Instead, we can extend the inter-partition command sender to take a completion callback that is executed whenever the command is written on the remote partition. We can then use that for message correlation (and possibly other performance sensitive features such as signals) to shorten the retry interval for messages that were not written on the receiver.

[tasklist]
## Refactoring flow control
- [ ] Let the `Sequencer` write directly to the raft thread
- [ ] Implement a `Mixer` component in front of the `Sequencer`
- [ ] The `Mixer` protects the raft thread from overloading
- [ ] The `Mixer` provides metrics for flow control state
- [ ] Record writers are categorized by use-case
- [ ] The `Mixer` applies flow control for user commands
- [ ] Cleanup: Building a `LogStreamWriter` should not be async


Hello,
Many users reported me this problem for a long time, and most of the time there is a problem for the container to access to the DNS servers, and it's related to a misconfiguration or a bug in their docker installation.
Look at this : URL


@Vlek Yes, this has now finally made into a stable release in version 3.7.0.

The tracking issue for the feature is #2689 and the initial modularization work was done in #2595.

@raffael0 Do you want to receive this bounty through the polybar collective? It seems to be really easy, they even auto-generate the invoice for you. Payouts can be made through direct bank transfer or paypal.

@Vlek Appreciate you paying out a bounty for this 😃. If Raffael accepts, you can make a one-time donation to the collective with the desired amount and I will coordinate this being paid out through the collective's expense system.


Wow. Yeah i'll gladly take the bounty in any way that is easiest for you.
Thank you! Just let me know what I have to do


See some benchmark results courtesy of @Zelldon - URL :tada:


A prequel to Ole's comment above.

We prototyped flow control in Sequencer. We added separate request limiters for user commands, remote commands and internal commands. Processing result from stream processor is never rejected. All limiters are configured to use AIMD. Limiters for internal and remote commands are configured to be more lenient to ensure internal backlog can make progress even if there is high load from users, but this is up for discussion.

Although our main goal is to limit remote commands, we first evaluated with a high load of timers because it was the easiest to setup a benchmark with timers. **Result: The cluster with the limiters for internal-commands is still running strong after a couple of days. The reference benchmark is almost dead now with 400Mil of processing queue size.**

Reference
image

POC with flow control for user, remote and internal commands.
image

Next question is how this type of flow control works for remote commands. As Ole explained before, rejecting remote commands can cause higher delay in message correlation mainly because we are not retrying aggressively enough. In a very high load, similar to what we saw in the support incident, it is probably fine. But in a normal load scenario we have to ensure that the messages are still correlated in real-time. We have not evaluated this yet. So as a next step, I would like to evaluate the impact of flow control for remote commands. Based on the results, we can decide whether we want to add request limiters for remote commands in the Sequencer (together with better retry strategy on the sender) or add caching similar to the timers proposed for #13870 or a combination of both.

Nevertheless, we should take the next steps proposed by Ole above.


@deepthidevaki just want to mention that we already implemented caching for the writes in URL


I think caching for remote commands is gonna be really tricky. I suppose you could do it on the receiver side :thinking: That would reduce a bit the load on the remote commands for back pressure I guess.


That's great! Once @Vlek sends the money, I can create an invoice invitation for you and you simply have to fill out the payment details. Is your protonmail email ok?

@Vlek You can now make a "Custom Contribution" with the desired amount here: URL


True. We don't have a prototype for it yet.

We discussed the following for backpressure approach
1. Buffering in the receiver and receiver can retry (limit the number of retries) if the write was rejected due to backpressure. This can put more pressure on receiver which might be already overloaded.
2. Buffering in the Inter-partition sender and retry if the write was rejected due to backpressure. (limit the number of retries). The record is already buffered in the engine, but we have to buffer it again in inter-partition sender.
3. Somehow the recurrent checkers in engine should know to retry faster if it was rejected due to backpressure. Needs more information exchange between the inter-partition transport and the checkers.

1 and 2 is in the direction of providing more reliable transport for inter-partition.

Alternate is to follow the caching approach used for timers, to reduce the chance of backpressure due to sender repeatedly trying to send the same commands. But here the most tricky is that the we can mark it as written only when the receiver has written and committed the command. Also how to handle if the command was rejected -> should retry again?

Adding backpressure will be the easiest part to implement, but the problem is that in specific workloads there is a chance that a few messages get delayed forever because they were unlucky and get caught in the backpressure loop.


We took it off the ZPA board, as ZDP has found a solution on their side 🙇 Thanks again @Zelldon and @npepinpe


Hello,
thank you very much for your help and information. I have now solved the problem by including the IP of a name server in the docker-compose.yml:

 jdownloader:
 image: antlafarge/jdownloader:latest
 container_name: jdownloader
 restart: on-failure:10
 hostname: jdownloader_dock
 dns: 8.8.8.8

It is working. :-)


@patrick96 @raffael0 sent. $100 for the bounty, $20 toward Polybar. Thank you both!

image


That's very generous, thank you very much!

@raffael0 I have sent you an invoice invitation, let me know if everything works out.


Hi!

This looks like a wonderful job. But this new timer cache doesn't solve my problem with bunch of UNIQUE timers from DIFFERENT process instances. I've illustrated my problem here URL My comment was stated as duplicate of this issue which was likely fixed with timer cache solution in PR #15136 (for 8.3).

I could not understand how this cache solution will help me but had some hope and belief. Well, there no miracle happened.
I've just tested on 8.3-stable
image

Thousands or millions of unique timer events still overload brokers:
image

This is my process with timer:
image


We're working on another solution for that in parallel. URL

I know the issue specifies IPC, but the proposed solution will enforce rate limits between the different categories, user submitted commands, internal/scheduled commands, and remote ones.


Same problem, new log.

 URL

It is always a bit of a problem that there is almost never anyone with any ideas to solve problems in the Yunohost surrounding, I mean I tried the easy stuff, I played with the permissions of the log... but is seems the error comes regardless of he permission setting for the file/folder.

It's sad that Synapse server only worked for a few weeks and then after an update stopped working.


In spacy v2 the tokenizer and lemmatizer exceptions were both maintained as part of the tokenizer, but now in v3 the tokenizer exceptions are in the tokenizer settings and the lemmatizer settings are in the `attribute_ruler`. If you want to see all the details, look at the rules in `nlp.tokenizer.rules` and `nlp.get_pipe("attribute_ruler").patterns`. If you'd like, you can customize any of these rules/patterns in the `en_core_web_*` pipelines as necessary for your task.

The existing lemmatizer exception only applies to `"doin'"` and not `"doin"`, but looking again at the details there are some mistakes in the current rules, which have the lemma as "doing" instead of "do", so we'll get that updated for the next model release (probably v3.8.0).


It was unclear to me before whether we want to add flow control for internal commands now that we have the caching solution. It seems caching did not fully solve the problem encountered by a user. Flow control for internal commands would likely solve the reported issue.

So I'm putting this issue back to inbox to discuss it in next traige/planning. It would make sense to start implementing the changes proposed in the above comment even if we don't have a completed solution for IPC.


The existing lemmatizer exception for `"doin'"` is not working for me either. This must be related to #13098 because after adding

nlp.get_pipe("attribute_ruler").add(patterns = [[{'LOWER': "doin'"}]], attrs= {'LEMMA': 'do'}, index= 0)

the lemmatization works as intended.


@jwinarske , would it be possible for you to make actual repro out of URL for example? This should help understand better where in the stack there is obfuscate vs non-obfuscate confusion.

cc'ing @stuartmorgan since it seems to be in plugins/packages realm.


It is unclear to me what the expected outcome of this issue is given that URL and URL both explained that what this issue lists under "expected results" is in fact a bug that we intend to fix.

As far as I can tell this is a duplicate of URL


@stuartmorgan this is a new issue. Which in everything I've read should not behave this way. There is also another issue that drove the --source option; where dart plugin registrant was ignored only when obfuscated was set. Which indicated this might be a leftover corner case. Cross compiling an AOT by script or manually on a host machine is a valid use case. Dart pluginn registrant (vm entry) works today if I enable obsfucation when dealing with "remote package" definitions. In all cases of "local packages" plug-in references work with or without obfuscation.


Ah, thanks for the note about that. My intention was that `NORM` would help here with `doin'` vs. `doin’`, but the tokenizer exceptions are more complicated than I remembered. I'll just revert all the `NORM` changes back to `LOWER` for the next model release so it goes back to the v3.6.0 behavior. (If these changes are causing problems for you, it should work fine to use the v3.6.0 `en_core*` models with v3.7.0.)


It would be helpful if you could add more detail to the STR then. Right now the STR section is just links to a script that appear to be part of a build process rather than actual steps, so I was trying to extrapolate from that, and it appeared that you were describing a situation where—when building for a third-party embedding—the `flutter`-tool-generated first-party registrant code is sometimes being run and sometimes not (which in the important respects would be the same as URL


Thanks for the help, the v3.6.0 `en_core*` models indeed work better for my task.


I understand that the exact details of what you are saying is different between the case where the registration runs and the case where it doesn't are different. That's why I said it would be the same "in the important respects".

I'm still not clear whether my understanding of the issue described in my last comment is correct or not. Please provide actual *steps* to reproduce the issue so that it's clear what the scenario is here.


Same as #682, I think?

Thanks for letting me know :+1: hope we'll be able to fix it


This is something very useful for me because I'm importing some resource from external sources like rabbit exchanges and queues but these resources doesn't have any additional information like tags or customized field. In this case all my resources goes to same owner, for example. That would be great if we had a tool to edit these components after the importing.


Holger recommendation is as follow. I cannot find "chgtol" in the Qucs settings.

You may add this line to the netlist.
.options abstol=10u chgtol=1e-10 method=gear
 Because you have high voltages, chgtol and abstol reduce the precision requirements, especially the gear method here yields a transient solution. It looks strange though, and you should simulate up to 1 s to see the output signal decay.


Yes, the options helps. You may use the .OPTIONS device.
image


Output is wrong. Supposed to look like the following.
6-phase-rectifier

6-phase-rectifier-out


Holger said to use Delay instead of Phase for the AC source. This and the changes to Transient Parameters seems to solve the issues.

Can the "Qucs" AC source have VO (offset) and TD (delay) added as a parameter? The "Spice" AC source usage is a bit confusing.

Attached is the "good and bad" schematics. As shown below, when using Delay in the AC source, the 120 and 240 Degree transformer outputs had a +/-200 volt DC offset. Unsure how this is possible. The offset occurs even if the diodes are removed.

Waiting for Holger to verify if this is a bug.

2023-11-14_152103

6_Phase_Rectifier.zip


Hey @crystall-bitquill,

I'm also experiencing the same issue reported here. I've using a snapshot build and getting the following log line (identifying details removed). I'm thinking we need to include the exception type in the log line.

WARNING: Continuing monitoring after unhandled exception was thrown in monitoring thread for node -02. .us-west-2.rds.amazonaws.com: null
Nov 14, 2023 9:23:23 PM software.amazon.jdbc.plugin.efm.MonitorImpl run


Yes, you may use the generic SPICE source for this purpose:
image

No, this is done intentionally for Qucs compatibility. This node never caused problems before.


The "ac Voltage Source" at the bottom of the Sources menu is a Spice only component so Qucs compatibility isn't an issue. It has a single default entry of "Vac" which is wrong. ngspice thinks it is a DC source. Why was this device created when "V Source" is available.

Can you alter "ac Voltage Source" by adding all the parameters to the Menu so the User can change them?

2023-11-15_111458

2023-11-15_111955

2023-11-15_113042

2023-11-15_113155


Yes, I have just added the TD and VO parameters for AC source. This fix will be available since the new release.

image


The "ac Voltage Source" at the bottom of the Sources menu will still be wrong if not changed or deleted. Why was it created?

2023-11-15_115150


This device was added by @MikeBrinson long time ago. I cannot say what was the purpose for this device. I am also finding two type of source confusing. I may delete it in the next release. The *V source* device would be sufficient if one need full SPICE definition.


Not logging to a file is my solution for now.

use this config in /etc/matrix-synapse/log.yaml


Just bumping. I indeed noticed this as well. I'm seeing the default sizes appearing in the editor alongside custom ones as well as in the DOM as variables. I can't actually find a way to remove them. I don't think this happened in the past so I'm not sure what changed. I'm running 6.4.1 and the Gutenberg 17.0.2


Also noting that this can cause a known issue where two type sizes can conflict with eachother. If two type sizes have the same value then selecting one will cause the block to revert to the first matching style that appears in the list. Normally this isn't a big issue, unless the default styles don't disappear when you define custom ones. The default styles appear first in the list so selecting a custom style with the same value forces it to select the default.


No, the variable should be wrapped in braces like `{Rs1}` Otherwise Ngspice may interpret it as the model.


Holger corrected the XSPICEPS1S2 subcircuit. AFAIK, the info in the online help is wrong.

I found another issue, Cores.lib uses the same data for every core so only one core is correct....


Yes, I have also noticed that the Cores.lib uses duplicate data. Unfortunately, I have no source data for this library and cannot provide the fix. The library was developed by @MikeBrinson around 2015. I cannot say where did he take the cores data.


The help on readthedocs.io should be deprecated and replaced by the new tutorial. It contains a lot of outdated information. I have started to collect the new documentation here: URL But this a slow process. Writing documentation requires much more time effort than writing a code.


Here is the updated Transformers.lib. All identified errors have been fixed.

I left the "Cores" data in Transformers.lib and Cores.lib as it was. I could not find any info on the web. Looks like manually pulling data from B/H plots would be required. Some of the cores are nothing a user would ever make a transformer.

I requested info from Mike Brinson...

Transformers.zip


This issue is tough to diagnose because there doesn't seem to be a pattern to the failed writes.

There was a potential issue with the db write operation. These writes were being executed separately and individually, in a way where some could succeed, others could fail, and the user processing the package receipt wouldn't know anything was amiss.

This update will restructure the way the write operation is handled. The receipted box and specimens in the box will be written in a batch - either 100% pass or 100% fail. Error handling will be implemented to trace any error's source and show a useful error message in the BPTL dashboard. This way, if we have future errors, we'll have a better handle on the source. In the failed cases, it's possible a simple retry will succeed.

Additionally, we're implementing a check to make sure a box hasn't already been marked received. This should solve the possibility of accidentally scanning a tracking number twice in the 'package receipt' form. Now, if a package has already been received, the user will receive a warning about the already received status. Clicking 'cancel' will terminate the operation, clicking 'continue' will process the double receipt and add a `'forceWriteOverride' = true` property to the box.

The PR should be out for review tomorrow. Please let me know if any changes are requested to this update.

Box - accidental double receipt screenshots (from dev):
<img width="1185" alt="Screenshot 2023-11-16 at 4 04 34 PM" src=" URL
<img width="964" alt="Screenshot 2023-11-16 at 4 06 08 PM" src=" URL


Hi @andrecloutier-pd,

Thanks for trying out the snapshot build and for letting us know about the logs. There were some changes merged recently (PR #718) that make the logger message include the entire exception. Could you kindly check out the latest snapshot build and let us know how that goes?

Thank you!


It would be nice to be able to load an absolute path... in this case I don't have a way to set the current working directory, and `file:///c:/...` or `file://c:/...` do not work. It ends up prepending the current path (which again I don't have control over) and attempting to load like `c:\tmp\file:\c:\` for `node file:///c:/tmp/shell/node_modules/...` I just happen to be in c:\tmp when testing this, but that is not likely to be the path.


I just went ahead and published updated v3.7 `en` models, which now should be available through `spacy download`.


I just wanted to let you know that I received the money. Thank you @Vlek for the generous bounty and @patrick96 for being a great maintainer and organizing the payout!


I have been scratching my head for months why I didn't get my Debug, Verbose and Information messages in my output when calling Functions in Modules. It's funny when they advise us to move from Write-Host to Write-Information and then make InformationPreference SilentlyContinue the default.

By accident I found this thread and I now prefix DebugPreference, VerbosePreference and InformationPreference with $Global and suddenly I get everything I've been missing, all the feedback I had programmed into my functions but could only see when running from my local system.

So this is absolutely still a thing on PowerShell 7, Mr. Bot.


Update: After discussion with @HopkinsDC, the desired behavior on override (2nd receipt):

(1) received specimens: use new date or retain old date? --- **Retain old date**
(2) unreceived specimens: use new data or use old date? --- **Use new date**
(3) Full specimen received timestamp: use new date or retain old date? --- **Retain old date**
(4) box received timestamp: use new date or retain old date? --- **Retain old date**


See #2307. It's not as slow as you might expect (though noticeably slower than the fastest+simplest linters)


Marking this as closed by #2307. please file any residual FR as a follow-up


Sorry, I can't tell from what's posted there what the error might be. I'm going to need some more information to be able to help. It is still the case that Alpine images don't support ARM yet, if that helps.


hi @JohannesLichtenberger can confirm the latest changes now work successfully for me. Awesome!


Let me add one more comment. This line in the docker-compose file:

 volumes:
 - /opt/sirix/sirix-data:/opt/sirix/sirix-data

Causes the launch to fail unless the folder is specifically created and mapped in Docker. I was able to make it boot by creating a test folder in my user dir and making it available in Docker desktop app:

` - /Users/james/sirix-data:/opt/sirix/sirix-data`


Bonjour @kdubuc et @A709197

J'ai constaté que la fonctionnalité d'export de PJ vers Plat'AU a été intégrée au GitHub du SDIS62 pour la partie concernant le dépôt prevarisc-passerelle-platau (#45).

Toutefois, pour pouvoir exploiter cette amélioration de la passerelle, il faudrait aussi récupérer l'adaptation de l'application : Remontée de documents vers Plat'AU #698.

Est-ce qu'un merge de cette PR est prévu ?

Merci d'avance pour un retour de votre part.


effectivement, la fonctionnalité d'export de documents est livrée ! URL

nous maintenons activement la passerelle, mais pas le dépot prevarisc. Pas de merge de prévu de notre côté, mais vous pouvez le faire directement sur votre version de prevarisc en utilisant la branche de travail URL


Thanks a lot. Can you check if it's working without the existing `sirix-data` folder? I've just committed a fix, hopefully: URL


I have the exact same problem, let me know if I can provide some feedback


The checkpoints represent temperature values that define the desired temperature range for the corresponding container. For instance, if the checkpoint is 42.0, then the temperature $t \in[42.0 - \delta, 42.0 + \delta ]$ for some $\delta \geq 0$. Currently, the configured $\delta$ is set to 5.

@ge0rgemera highlighted that when adjusting the checkpoints, they typically modify the integer part of the float and very rarely alter the first decimal. Therefore, we should focus on storing checkpoint values that adhere to these patterns.


@deepthidevaki can you link the prototype PR/branch here? thanks!


In my case, the workaround was relatively simple: I added a *lot* (350+) of covers all at once, in a short timeframe, so I could rewrite the `update_at` fields on those relatively easily with this query:

UPDATE album SET updated_at = created_at WHERE updated_at > '2023-03-06' AND updated_at < '2023-03-10' AND created_at < '2023-03-01';

But of course, if I fix an old cover again, that poor old album is going to come back up the list and try to play with the young kids and everyone is going to look at him sideways and think "ok boomer" and release a barely hidden sigh that will just make everyone really uncomfortable...


You have set ND_RECENTLYADDEDBYMODTIME to true which is not what you want from what your description reads.

 URL

The functionality you describe is implemented with #2553 as long as you dont Set ND_RECENTLYADDEDBYMODTIME (default is False)


A question: Is it possible to run scripts using in release instead of debug?


The main option is to edit debug profile to look like release.

This is under discussion in the RFC


Hmm... well that setting doesn't do what I thought it did though: I thought that would set the `created_at` field on import, but from what you seem to be saying here, it influences how the albums are *displayed*?

the `created_at` fields are correctly set here, just to be really clear.


That's correct. It is used for controlling how to display the Recent Added Albums view.


okay, so couldn't this be made in reverse, like at import time, if that setting is on, use the file mtime as the `created_at` field instead of `updated_at`? for me this thing is completely setup backwards, but maybe that's just me. :)


An outstanding item for me is to look into how we should handle symlinks. My guess is we'll resolve them so the manifest dir will be after resolving symlinks.


Item Borders was determined to not be compatible because it creates a new matrix stack (#65). As far as its behavior with AutoHud, that is peculiar. You may notice that while it may fade ItemBorders, it will not animate it, whether Raised is installed or not. This is likely because of the same reason.


I think the fields should be used for what they mean: `created_at` for when the file was created/first imported (see #1350), and `updated_at` for when was the last time the record was changed in the DB. Inverting these two can cause confusion when maintaining the codebase, and it is just a matter of displaying sorted by one or the other, with no need to change their semantics.

Also, making this distinction at scan time, means that if you want to change it, Navidrome needs to rescan everything again - with a full scan - which can take days sometimes for some large libraries.


i see. so what are my options here?

i guess i could remap the `created_at` timestamp to `updated_at` if the latter is lower? would that work?


That should be the behaviour if you remove `ND_RECENTLYADDEDBYMODTIME: "true"`. The default behaviour (`false`) is to use import date (or birth date as per #1350)


okay well maybe that's where my confusion comes from: I thought `ND_RECENTLYADDEDBYMODTIME` was a feature flag that enabled the "birth date used on import" defined in #1350 - those two are actually unrelated?


No it is not!

`ND_RECENTLYADDEDBYMODTIME` selects whether to use `created_at` (false, default) or `updated_at` (true) for sorting the Recently Added albums view. This was implemented by #822 a couple of years ago.

#1350 (fixed by #2553) was released in 0.50.0, which replaces import date with birth date, on systems that support it, as that's a sensible thing to do (use the actual file creation date instead of the import date)


costly

I wonder if this is the same issue? Two days ago we got a budget warning from AWS. Something had generated a few gigabytes (or hundreds of dollars depending on how you want to measure it) of cloudwatch log entries. The CPU was spinning on 100% generating the output in the image as fast as it could.

No wonder AWS is big business for Amazon


Hi.

I've tested this case URL Seems like queue size is really capped now (was up to 1mil events, now up to 500k events). But this the only good news. Overall performance became lower, windows of unavailability became wider. It's reasonable, because number of timer events doesn't change it's just processed slower now.

image

I've expected that with limited processing of timer events - there will be some "bandwidth" for processing new events (create new PIs). That' doesn't happen.


This could be because in the poc, we deliberately configured flow control for user commands and internal commands differently. We are more aggressively rejecting user commands while accepting more internal commands.


After the permission issues I played around with the permissions, I don't remember the permission when the crashes started. I tried some different combinations of user:group and some different permissions for the folder, the files...

Now it is:

drw-rwx---+ 1 matrix-synapse root 88 Oct 19 20:58 ./
drwxr-xr-x 1 root root 3.6K Nov 19 00:00 ../
-rw-rw----+ 1 matrix-synapse matrix-synapse 0 Oct 19 20:58 homeserver.log
-rw-rw----+ 1 matrix-synapse root 24K Nov 22 20:21 turnserver.log
-rw-rw----+ 1 matrix-synapse root 5.1K Oct 1 11:58 turnserver.log.1


Ah, you raised this here as well. Link for reference: Crendgrim/AutoHUD#79

I can confirm that AutoHUD is incompatible with ItemBorders for the same reason as #65. I sent a PR to ItemBorders that has not been accepted (or responded to) yet.

If there is a further incompatibility between AutoHUD and Raised, I'm happy to investigate that, but I believe this to be ItemBorder's doing (AHilyard/ItemBorders#20, AHilyard/ItemBorders#21).


I wonder if the extension/plugin proposed by @facelessuser can be further extended to expand horizontally as well?

As per the linked issue I logged URL in the tech docs we often work with data tables, and tables are known to span wide.

It would be amazing to have an option to expand in both ways as shown here in the description.

**I am willing to sponsor this work.**


Hi @kimble, thank you for reaching out with this information.

The driver logs thrown by the monitoring thread are necessary to inform the user of potential monitoring problems. This info can help the user and team diagnose and address issues that may arise. However, we understand that the volume of logs generated by this particular scenario was greater than you expected. To address this, we have created PR #751, which lowers the logging level for the particular messages you are seeing to avoid potential surprises for other customers. Thank you for raising your concern. Please note that you can also filter the logs using the properties file. For example, to filter out the logs in the posted image you can add the following line to your `.properties` file:

software.amazon.jdbc.plugin.efm.MonitorImpl.level=OFF

Regarding the memory leaks issue, we have made improvements to the monitoring objects to ensure they are synchronized and the driver does not cache references to them in PR #718.
We will keep you updated for when we create an official release containing this fix.

In the meantime, could you please help us further improve our driver by checking out our snapshot build containing changes from PR #751 and PR #718, and send us the unhandled exceptions your application is throwing so we can triage it?


Reducing the log level will probably just hide the problem that there is a thread consuming 100% printing the lines from my screenshot over and over as fast as it can.

Not sure what you mean by this?


this has happened to me as well, when previewing a large pdf using lf, my window manager just froze


Hi, thanks for reporting this. This is happening because Chafa delegates to ImageMagick when there's no internal loader to handle the file format. ImageMagick gets very enthusiastic and sometimes trips on its own shoelaces.

The problem is fixed in master and will go away in the next release -- see #157.

In the meantime, you should be able to curb problematic formats in ImageMagick's configuration. On my distro, this lives in `/etc/ImageMagick-7/`. The best way is to list it in the security policy file:

1. Find the format identifier by running `magick -list format`.
2. Add it to the policy file (`policy.xml`), e.g:

sh

The default configuration varies between Linux distros; mine already has PDF on the do-not-load list, and it looks like DjVu support is not built in at all.


@yurisuika Thanks for letting me know about the issue having to do with Item Borders and not with Raised. But is there still a way to get Raised to work with AutoHUD without having to turn the fade option off?

Thanks!


新版本已由 lib32-gst-bad-ugly 提供，该包提供下面四个包：

 lib32-gst-libav
 lib32-gst-plugins-ugly
 lib32-gst-plugins-bad-libs
 lib32-gst-plugins-bad


I have worked around the issue by giving the working (WinSW-wrapped) service a different name (such as `windows_exporter_winsw`). Now I only have to delete/disable the `windows_exporter` service after every update of windows_exporter, but an update is a change anyways so it doesn't matter that we tack on another required follow-up change.

Using the EXE would be very inconvenient for two reasons:

1. We use package managers like `chocolatey` or `winget` to provision and update software, and both only carry the MSI installer. To use the EXE installer we would have to create and maintain a custom software package.
2. The EXE download is not an installer, just a "portable" executable. This means it doesn't register its presence on the system with the MSI software database or the registry keys for ARP. This means it won't be tracked by software inventory systems. We have to verify that updates are being installed and are working as expected in case our deployment contains a (logic) error.

Software that's in the MSI database or at least the registry can easily be inventoried and tracked across thousands of systems by external tools.


To confirm, the request originated from a need to manage the `windows_exporter` service, due to the MSI-provided service failing to start?

Is that still the case now that #1047 (`window_exporter` >= `v0.20.0`) has been implemented?


I believe I'm seeing this with Paint.NET.

Steps to repro:
1) Download and install Paint.NET v5.0.11, or use the portable version. Both available here: URL . That version of Paint.NET is using .NET 7.0.12

2) Place the two files in this ZIP into `%LOCALAPPDATA%\paint.net\Optimization`:
Startup.profiles.bad.zip
<img width="733" alt="image" src=" URL

3) Try to start Paint.NET, either by double-clicking its icon or running `paintdotnet.exe` at the command-line

Expected: It works

Actual: App does not start, and you see errors in the event viewer like so:
image

If this isn't the same issue then I can file a new issue for it, but this is causing misery for a non-trivial number of people who use my app 😢 In the short-term I can just disable the use of `ProfileOptimization` and release a hotfix for the app


Ca a l'air d'être OK mais je t'avoue que je check pu ca depuis un méchant bout, car je n'utilise plus les compteurs d'énergies fournis par l'intégration depuis que j'ai connecté mes thermostats hilo directement par zigbee. Mais bon, les compteurs ont l'air OK dans las section "statistics" présentement.


I have a fix for this lined up in the next AutoHUD release, though for Fabric only.

@yurisuika is there a way similar to Fabric's ObjectShare to easily get the HUD offset on Forge?


Je vais fermer et suivre ça dans #319 comme c'est un duplicate plus récent. Merci de ta réponse!


I have deprecated the red AC source. The remaining issues with the transformer library will be fixed in #367 Closing this as completed.


Bonjour,

Les changements de la base de données sont dans des pull requests de prevarisc sans merge dans le master, est ce qu'ont doit les appliquer ?


Bonjour,

Cette évolution nécessite effectivement une mise à jour de Prevarisc en lui-même pour pouvoir être pleinement exploitée. Je vous renvoie vers la discussion du sujet sur le ticket de l'évolution d'export des rapports qui suggère d'appliquer les modifications.

Dans tous les cas, la sélection des documents à envoyer sur Plat'AU s'effectue directement depuis Prevarisc.

Cordialement,
Maxime Merrien


Oui effectivement

pour que ce soit plus clair, j'ai détaillé cela dans le readme URL


I'm seeing the same settings in both places (WP 6.4 + GB trunk); however, the four default font sizes ('Small', 'Medium', 'Large', 'Extra Large') appear first in the block styles, but last in the global styles. In other places where Gutenberg provides default values for something we add a `default*` option to disable showing those settings, but I don't see one for font sizes right now.

So, it sounds to me like there are two parts to solving this fully.

1. Add a `defaultFontSizes` option that allows for the default size options to be hidden.
2. Ensure that the order of the default, theme, and user sizes are the same in both places when they are all enabled.


Ookay... I completely misread this! thanks for the clarification...

is there a way to *rescan* files so that their creation date is retrofitted back into the `created_at` field?


Try a full rescan. If that doesn't work, there's no other option except for re-adding all your files, which currently will make you lose your playlists and favourites/ratings/play counts :/


I encountered the same issue and after quite some digging in code this seems to be indeed because in `validatePostResponseAsync` method, the default value in `this.options.wantAssertionsSigned` is true if not specified in SamlConfig whereas it was false in v3.

@cjbarth are you sure this is an intended behavior ? I feel `wantAssertionsSigned` should be false if not specified in config


The change was intended as it is in harmony with the secure-by-default philosophy that we have here. Please feel free to put up a PR to help us with our README.


@Crendgrim Thanks a lot for fixing this issue in the newest version! I'm very grateful. As for the problem with Item Borders and Raised, i will be patient, no worries :D


Ok I understand but then indeed it would be great to specify it in documentation, I can open a PR for that 👍
What would have been really helpful also is to add it as a breaking change in the changelog, I don't know if it's automatically generated or if it's possible to also update it now


I had this problem when I logged to the server via SSH.
I forgot to forward my agent via `-A` flag.

`ssh -A $user:$host`
I leave it here, probably for myself in the future and maybe for the others that encounter this issue


I agree this would be useful to highlight as a breaking change in the Changelog.


Work is still ongoing - 11/28 Dec release. Sandra to add to Punchlist.


Should be fixed by the recently merged #1100 - let me know if that isn't the case.


I've explored this in #370
For now, adding full support is too much effort for me alone. I'll focus on #248 and come back to this later. If anyone knows of a good ActivityPub hackathon, ping me!


Hi @tea-de-kay, thanks for opening this issue!

Note that this behaviour is currently by design due to limitations with VS Code API. However, we are experimenting with some fixes to improve this experience. I will update this thread when the changes are checked in.


i noticed to that if the song already has a `created_at` timestamp, a full rescan will not refresh it with the file creation date.


Hi @kimble,

1. The logs will only be printed if you choose to enable `FINEST/DEBUG` level logs. You can also disable logging for that particular thread.
2. We have released v2.3.1 containing fixes from #751 and #718. Could you please give it a try? If the issue persists can you please send us the driver logs related to the issue?


Flutter currently doesn't offer an easy way to add context menus.


Closing this tracking issue since the remaining issues are low priority, and we can review them separately. I added them to the eng tracking board.


Usually, if your channel app is still under development, this means you are not adding your LINE account as a testing account to your app. Please check and confirm the Developer Console and add your account in the tester list.


can you explain more detail about the tester list and testing account?


You can find the related setting in the LINE Developer Console (login from URL check your channel and invite the LINE account to the tester list.

<img width="1132" alt="截屏2023-12-05 13 18 45" src=" URL

For more, please also check this documentation: URL


But when i use the other user line account in iOs, is it necessary for this steip?


Only users on this list are allowed to use your channel while it is under development. After you mark the channel to be published, all LINE users can login to your channel.


My channel has been published. But the issue still be here and only happen in iOS when user has not login account in Line app


If the user does not yet log in the LINE iOS app, then it is the expected behavior: LINE app recognize the auth request from the LINE SDK and try to read the login status from itself. If not yet login, then it goes to an error handling process since no login user yet there in LINE.


That's right. Like the android, when navigate to line app for login, i can handle action in app. No need switch to web app


@Boyuan-Yu You asked: Can you help me confirm the following?
First - please also see the desktop layout - URL Orchid (the designer) created the components page, but we also need to look at the design page to see what's most up to date. The pointGroup component should be the same whether desktop or smartphone, but I want to make sure we pickup all the latest - which would be in the design page (rather than the components page looking at the column on the right of figma).

1. The Point Group component has 3 states: Default, Edit, View. In Default, clicking ‘Edit’ button goes to Edit state, and Clicking arrow on the right top goes to View state.
 - What all the states are is a conclusion you will figure out as you are implementing. But I think there is one other state besides what you mention for choosing the lead item.

3. The Point Group component takes a PointObj which is the lead point and the rest pointObjs are in the list of the lead PointObj.
- The rest are in the groupedPoints of the lead PointObj

4. I assume the Select Lead component takes a list of PointObj.
- Select Lead is a Button, with an onDone function. The onDone function for each button should be associated to the object it references. Could be by object, or could be by _id in the object. Depends on how you implement it. When you get there I can help.

- 5. Since there is no dark mode for Point, I assume no dark mode for PointGroup?
Correct.


Most likely you run Crow on XWayland and it works with other XWayland applications, like Google Chrome.


Could you tell how can I check it?

I tried
xlsclients
 as a random internet advice tells. It tells that Google Chrome does run on XWayland, but Crow doesn't:
Screenshot from 2023-12-06 22-22-15


@tuyen3962 Ummm, thanks for the explanation.

I will record this and start a discussion with the team to see if we can improve it. But since it is already a long-lasting LINE iOS app behavior and not directly involved with LINE SDK side, it may take a while before a decision can be finally made. Let me try!


**Initial notes:**
This is a separate issue from missing tube received timestamps but stems from the same ‘receive packages’ function.
Link to that issue: URL

The two boxes involved:
Box440 - shipment submitted 11/16/2023
Box972 - shipment submitted 11/22/2023

Box440:
•marked ‘received’ and has received timestamp 12/04/2023.
Specimens in box 440 have received timestamp:
specimen level - 12/4/2023
tube level - 12/4/2023
tube level, mouthwash - no mouthwash tube for collection

Box972:
•marked ‘not received’ and does not have received timestamp.
•Specimens in Box972 have received timestamp:
specimen level 12/4/2023
tube level, non-mouthwash 12/4/2023
tube level, mouthwash - 11/24/2023

The ‘receive packages’ function searched for this tracking number and probably executed correctly the first time.
The second time, it got a list of both boxes (duplicate tracking numbers), and defaulted to picking the first one. There’s no currently logic to tell it which box to pick when setting the received timestamp. We should have more specific logic here so duplicate tracking numbers aren't an issue in the future.

**Action:**
Tighten up the logic & conditions used in the ‘receive packages’ function so it knows what box to pick in a duplicate tracking number scenario.

We have a couple of options here, but I need to recreate this with duplicate tracking numbers in dev and run testing to find the most reliable method for selecting the right box in a duplicate tracking number scenario.

I’ll roll it into the ‘receive packages’ function update I’m currently working on. That's a full stack update with changes on the BPTL end and in ConnectFaas. This will pair well with the ‘package already received’ functionality I'm building.


Now that you've mentioned it, I'm on `3.1.0` currently and don't remember hitting the same issue in these past few months (I have reinstalled OS tho).

I suggest that we close this issue, I'll update to `3.2.0` and if it starts happening again I'll reopen it :)


We found to be able to support "use_frameworks" by modifying .podspec file.

**Method**
1. Download current react-native-star-io10 (`yarn install` , etc.)
2. Add the following code to the react-native-star-io10.podspec file located in the node_modules directory.
3. Build it.

**Modification**

Please add the following code the above `s.vendored_frameworks = 'ios/libs/StarIO10.xcframework'`.

 podspec
 if ENV['USE_FRAMEWORKS']
 header_search_path = [
 '$(SRCROOT)/../../node_modules/react/** $(SRCROOT)/../../node_modules/react-native/**'
 ]

 exclude_source_file_name = [
 'libs/StarIO10.xcframework/ios-arm64_x86_64-simulator/StarIO10.framework/Headers/*.h libs/StarIO10.xcframework/ios-arm64_x86_64-simulator/StarIO10.framework/PrivateHeaders/*.h'
 ]

 s.pod_target_xcconfig = {
 "HEADER_SEARCH_PATHS" => header_search_path.join(" "),
 "EXCLUDED_SOURCE_FILE_NAMES" => exclude_source_file_name.join(" ")
 }
 end


Would it be possible to get an update on this, we currently have to resort to pretty ugly code to have a custom AgroalDataSourceListener so that transaction management for Oracle works properly under Quarkus.
See URL for more details on that


Unfortunately I didn't have time to make progress on this.

I had to work on the Agroal code recently, and noticed this:

 URL

If Vert.x threads are killed in the same way, there's indeed a chance the order is undetermined (vertx threads may be killed before or after agroal connection pools, depending on who knows what)


@kmranjo can you do two things:

- confirm that I've updated this to reflect the capability we're testing in the prototype?
- Review the content from the older ticket (below Delete this?) and determine what's relevant to keep?


@colinmurphy01 I updated the info above to include the hypothesis I think we are testing, but want to confirm with @partly-igor and @sarahmhgov that this looks correct.
I also updated the info below the "delete" line to be a bit closer to the concept we're considering, but a lot of it is very specific to implementation and I don't think we're there just yet. Not sure if it is valuable to keep all that since we might need it eventually (even if edited), or if it woudl be cleaner to delete it all and get the design fully where we want it before looking at that level of detail for how the component will work. Thoughts?


Also not working for me with same config as @rairaman
I'm on `v0.9.2 3c695d7ba9`, linux ubuntu 22.04. I tried both zsh and bash, and even python with `duckdb.sql()`.
Nothing works.
A colleague of mine has it work on his mac, his aws profile looks the same :shrug:


You were right:

pavel@pavel-ux31a:~$ env | grep QT
QT_ACCESSIBILITY=1
QT_IM_MODULE=ibus
pavel@pavel-ux31a:~$ export QT_QPA_PLATFORM=wayland
pavel@pavel-ux31a:~$ env | grep QT
QT_ACCESSIBILITY=1
QT_QPA_PLATFORM=wayland
QT_IM_MODULE=ibus
pavel@pavel-ux31a:~$ crow
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
QSocketNotifier: Can only be used with threads started with QThread

Now the shortcuts don't work in either Chrome or gedit. Crow app itself also works worse, e.g. not all entered text is displayed.

I wish shortcuts worked across all apps, and Crow worked well.

What should I do?


On Wayland there is no API for global shortcuts. Each DE implements global shortcuts in its own specific way and you need to manually register D-Bus commands on shortcuts. But now you should have working selection translation. Try it out.

This is odd. I assume that it could be some GNOME-specific bug. I run the app my phone on Phosh (a DE similar to GNOME, but mobile oriented) and the app work fine.


Thank you for explanation.

I created a Gnome shortcut running dbus-send, disabled global shortcuts in Crow, and now the shortcut works in both Chrome and gedit:
image

The shortcut works both with Crow running with QT_QPA_PLATFORM=wayland and without it. Which option should I use?


The hypotheses look good to me.

Agree that some of the implementation details in the AC below the delete line is a little early, and may change based on feedback we hear next week. Wondering if we refine this ticket after the round of research?


With this update, any time duplicate tracking numbers are found, a scrollable, selectable list of possible box matches will be returned to the BPTL user (ordered by recency).

The BPTL user can manually verify the box based on boxID, shipping date, origin site, and received date (listed as 'not yet received' if new), and select the box to continue processing the shipment. After selecting a box and clicking continue, the receipt process will be handled as expected.

<img width="935" alt="Screenshot 2023-12-08 at 3 31 52 PM" src=" URL


Re: GitHub Project Board - this issue moves with URL I'm Leaving 819 in the development category during the review cycle to avoid confusion.


Re: GitHub Project Board - This issue moves alongside URL I'm leaving this out of the 'reviews' sections to avoid confusion.


Thanks @StephanieWeinstein. I was really under the gun time-wise because of our dev freeze EOD today, so if we find anything that needs fine-tuning that can certainly happen!


With this parameter it will run "natively" on Wayland. Without it will run through XWayland. It's a compatibility layer.
On my phone I set this variable globally for all Qt applications.


Maybe killing the applications threads don't cause an explicit rollback of the transaction?

I can't really comment on Quarkus internals, but the root cause of my issue is that Oracle commits on close.
The dirty workaround I have now simply makes sure there is always an explicit rollback before the close.
I believe the custom listener I made is triggered by the `dataSource.close()` in the code you mentioned.

I'm not sure what the best solution is for Quarkus.
The "explicit rollback before close" solution seems pretty robust to me.
But you could argue it's redundant and should be handled by the code behind @Transactional and the shutdown order.


If you used `@Transactional(rollbackOn={Exception.class})` (and you said earlier you did try that), then `InterruptedException` definitely should cause a rollback, at least that's how I understand the spec.
But yes, maybe the bug is there, we'll need to check.

Yeah that... is really a dubious design choice. I guess we could override this behavior by default if there's a setting in the JDBC driver, but then if you had to resort to complicated listeners, I guess there isn't such a setting.

Exactly. Because there might be other, similar problems caused by this (still hypothetical) wrong shutdown order.


Not exactly like that, but what you can do is have the NonbondedForce compute only the reciprocal space term. Do that by calling `setIncludeDirectSpace(False)`. Then you can use a CustomNonbondedForce to compute the direct space part, both Coulomb and LJ, in whatever way you want.


After building myself, it works:

./build/release/duckdb
v0.9.3-dev1243 6af3519ec1
D call load_aws_credentials();

Gives me a nice table full of credentials, while

duckdb
v0.9.2 3c695d7ba9
D call load_aws_credentials();

Gives me an empty table.


How does the GroupPoint Component get the values for dem-info like "Republican, 45 ,UT"? Are they in pointObj?


Yes, the natbib style for citations is nice because it contains some useful information (author and year) right where the citation is located. It is a good idea if you have a file for a paper that you use the same naming convention. It does help with traceability. That is what I've tried to do in the pub repo. I slipped a few times, but most of the files have natbib style names.

If there are files that would be helpful for @JacquesCarette and me to read, it is a good idea to put the paper somewhere, or link to its public version, when that exists. For files that don't have a public version you can't put them in a public repo, but you could put them in a private repo, like the pub repo mentioned above.


@smiths If there are some papers that are public and some that I've had to request access to on ResearchGate, would it make sense to store all related papers in a pub repo so that they're in one place?


I have posted a workaround that we think is relevant to this issue at Issue #90.
We would appreciate it if you could refer to this.


Hey @kunjgit ! Thank you so much for your raising the issue💗
 It’s all yours, you can come anytime again and make some contributions! 🚀
 Alone, we can do little, but together we can do so much! 😇


I sure hope not - I'm late to the party, and I love this browser.
I hope all is well!


@Drakonas This project is notorious for late updates to new releases or skipping several releases alltogether, sadly. Hence the period of time without committs is nothing new. While this doesn't mean that the project is dead, it also speaks for itself that the current team might not be up to the task of maintaining such a big project.

As Youtubers recently made quite a splash to push Thorium and that Google increased its release cadence, I fear that it collapses under the burden. No timely releases are a major security concern. And as I love Thorium, and its current state saddens me just as well as you.

What this project is in dire need of:

1) automated builds and releases
2) timely updates

From the answers I've seen before, it comes down to costs and time issues. The builds are made manually at the moment.


If you look at the author page you can see almost zero activity recently, not just about this project. Let's hope he'll come back.


Similar report just came in #435, too.

I believe something changed in the alpine image, since we test alpine in the CI pipeline and it passed last week, but started failing yesterday with the new image

- pass URL
- fail URL

Will investigate. In the meantime, a workaround is to use `ruby:3-alpine3.18`


In the past I asked on the Forge Discord if there was an analog to ObjectShare with Forge and the post was just deleted, so if they don't want me to know I guess I cannot answer you. It would be great if there were.

If you are willing to have a soft dependency, in the `RaisedConfig` class I have some public static methods that should expose these variables such as `RaisedConfig.getHud()`. You'd just have to run a check like `ModList.get().isLoaded("raised")`.
 URL

Sorry for the slow response.


This could possibly be implemented by adding a shortcut to the app in the SendTo folder, and reading the path to the file/folder from the command line arguments (in the `main` function).


It is fine to store publicly available papers in your repo, but I find that I don't do it. I keep a bib file (References.bib) in my publications repo. If there is a public link it is stored with the reference.


It looks like email notifications are set up on an individual basis. Would you like to be signed up for them as well @smiths?

## Formatting
The format of the glossary should be trivial to parse and easy to add to. CSV probably makes sense for its flexibility, and using natbib will allow for an unambiguous traceability to sources. I should make a private GitLab repo for publications so they are all in one place and named consistently. If possible, publicly available sources (e.g., Google Scholar) should be found, but if the only way to get access is through McMaster or through requesting it, it's private.

## Test Factors/Area of Confidence
The test factors from Perry might not be complete, independent, or comprehensive, but they may be useful as part of the "area of confidence" analysis; regardless, this is something to potentially return to. For now, either this "area of confidence" (or software quality, as I've been implicitly using it!) information can be left to the analysis phase, or recorded in these "simple" terms as a reminder to go deeper in the analysis phase

## Research
I should be looking "forward" to see if any resources (particularly ROoST) have been cited in more recent works! I should also be doing an "active search" by writing down what I do and what process(es) I use. For example,
- realizing that making this glossary is a "subsubtask"
- following citations (e.g., [1] from Engstrom)
- "looking forward", as mentioned above

Regardless, we noted that the notion of "intervention" from Engstrom likely isn't useful to us (or, at the very least, is out of scope) since it is too meta. I wondered about how it related to equivalence classing, but Dr. Carette pointed out that it is still a "live question", since it is something that could be generated, and isn't just an out-of-scope process for designing test cases.


Issue tested in dev. Ready for stage.

Screenshot 2023-12-12 at 11 37 26 AM


Nice summary of the meeting @samm82 and yes, please add me to email notifications as well.


Domonique tested it in Dev and it worked. Se issue #819 for her comment


image
my test shows error when adding FedEx number in shipping daashboard that is a duplicate.


I copied `/lib/ld-musl-x86_64.so.1` from `ruby:3-alpine3.18` Docker image and that seems to fix the problem, so it would appear that the problem is related to some change in Musl libc or how Musl is compiled.

By looking the exported symbols from the library (e.g., `readelf -Ws --dyn-syms /lib/ld-musl-x86_64.so.1 | grep posix_fallocate64`) I've confirmed that the symbol `posix_fallocate64` is present in the previous version but missing in the new version. I'm not sure yet if this was intended or if it was an oversight. I'll try to dig more.


@wyattks Yep, that confused me at first. I traced it out because I was unfamiliar with it -- that warning was implemented to be site-specific, so it does not catch duplicates across different sites, which is (I think) what happened in the case of this issue. One shipment from Chicago, another from KPGA.

I considered this box selection to be a more flexible solution...and also to serve as a code template for other parts of our apps that need similar response flexibility from the server in the future.

We can also strengthen this duplicate tracking number warning in the future or remove it...whatever your team decides.

Please let me know if you need me to set any custom data on the back end in dev so you can test the solution as if the boxes came from different sites. Thanks.


Just so my previous comment doesn't obscure the status:
This is tested in dev and ready for stage.


Just a note: the symbol missing for the user in #435 is `fcntl64`, where the one reported missing in this issue is `posix_fallocate64`.


If you look into his activity back in 2022, it seems that, much like this year, he was mostly inactive from november. Activity picked up again by January. Maybe he's on vacation?

Honestly I don't care at this point. I've been watching this project and feeling pretty much the same as @ms178 , and now from what is transpiring from #463 , I think I'll jump ship altogether.


OK, it seems this was an intentional breaking change in Musl 1.24:

So if I understood correctly, functions with the `64` suffix were dropped and the correct fix is to use the unsuffixed versions instead.

Here are examples of other projects that were also affected by this:
- URL
- URL


@pdfrod Thank you so much for doing this research! I should have time tomorrow to investigate if I can work around this in the native (precompiled) gems.


I hope somebody remakes a similar project so it's under a significantly less concerning developer.


Hi all,

We've recently added an **experimental** Host Monitoring Plugin (PR #764) to the driver, called the Host Monitoring Plugin v2. More information can be found here. The Host Monitoring Plugin v2 is functionally equivalent to the Host Monitoring Plugin and they are configured using the same parameters. The Host Monitoring Plugin v2 was created to address the issues that you all have been experiencing, and it is meant to be a more stable version of the Host Monitoring Plugin.

As it is currently an experimental plugin, please note that it should be tested before being used in a production environment. This plugin can be tried out by using the snapshot build `aws-advanced-jdbc-wrapper-2.3.2-20231213.213138-10.jar`. For more information on using a snapshot build, see this page. If you are able to test out the plugin, please let us know if you encounter any errors or if this plugin was able to resolve the issues you've encountered.

Thank you!


Hi @abdoofathy95,

To update you, similar issues (#675) have been reported regarding a memory leak in the Host Monitoring plugin.

We've recently added an **experimental** Host Monitoring Plugin (PR #764) to the driver, called the Host Monitoring Plugin v2. More information can be found here. The Host Monitoring Plugin v2 is functionally equivalent to the Host Monitoring Plugin and they are configured using the same parameters. The Host Monitoring Plugin v2 was created to address the issues that you and others have been experiencing, and it is meant to be a more stable version of the Host Monitoring Plugin.

As it is currently an experimental plugin, please note that it should be tested before being used in a production environment. This plugin can be tried out by using the snapshot build `aws-advanced-jdbc-wrapper-2.3.2-20231213.213138-10.jar`. For more information on using a snapshot build, see this page. If you are able to test out the plugin, please let us know if you encounter any errors or if this plugin was able to resolve the issues you've encountered.

Thank you!


I'm not sure there's a fix for this other than for rake-compiler-dock to support generating native musl-specific gems. Upstream issue is URL


yeah ... i am going to have to go back to FIrefox ... the "furry porn" stuff i think should be removed and has no place in a project like this (not even "offended" or "think of the children!" about it) ... the other stuff i saw just now ... figuring some people were going overboard BUT THEN seeing proof ... I cant have anything by this dev on my PC ... i am done .... and this was the first non-bloated (looking at Brave and Vivaldi) Chromium based browser i liked ... ever ... but yeah ... forget all the good stuff .... now maybe if another dev does the same sort of work, removes all that crap and takes OVER the project ... I may come back

this dev may do great coding work but this content i have seen on his/her repos is not acceptable to me ... and yes i admit again i thought some users were going overboard ... just seeing one "furry porn" pic at first.


Yeah, honestly the furry porn shit was bad on its own, and that in it of itself got me to start pulling it from computers i installed it on. Even still, at that point i would have been willing to give it another shot in the future.

When somebody archives a site titled the way that repo was titled, and has those types of images for _any_ reason, I no longer trust the main dev of this project, and so far i don't really trust any of the other devs I've seen so far, while i don't recall that they have done much to lose trust, they haven't done much to regain trust from a currently tainted project.

It would be nice if somebody else remakes a similar project, but with everything that has come out, it cannot be under the current main dev.


@Drakonas @fernandofig @Xmetalfanx @elmuz @ms178 @pixelpicnic No it is NOT dead. Im going to be completely honest, I was in inpatient rehab for alcohol, something I have struggled with since 15 years old.

I also happen to have covid right now too (i caught it at the facility, as did 10 others), but I will get a release out as soon as I can (because I want a new version too for tha security fixes)

I will be making a note on the previous release and upcoming release to explain why I was "dead" for a month.


@Xmetalfanx @SethbotStar You guys do know it was an archive of an anti circumcision website that was around for over a decade until the hosters shut down > URL


Thanks for looking into this; I did wonder if it was upstream.

I'll pin to alpine-3.18 for now.


This Issue is to be fixed by PR #33, but it should be revisited when we develop code that remotely changes the values of the checkpoints.


Is there an issue outlining what should be checked or changed when that code is developed?


I was thinking that we could create it once we agree on the structure of the code in Issue #30.


Noting here that after designing the mechanism for remotely setting checkpoints, some of the code in PR #33 might need to re-visited, as it will be possible to simplify it under the assumption that checkpoints will not be set via other channels.


We just discovered the same issue in our application. Whenever we have the following code:

js
someAPI.updateEntity(entity)
 .then(async () => {
 await invalidate("app:someEntity")
 await goto("/url/of/entity")
 })

we end up with the respective load function being called twice:

Screenshot 2023-12-15 at 18 43 56

To add to the fun, if we have something like this:

js
someAPI.updateEntity(entity)
 .then(async (res) => {
 await invalidate("app:someEntity")
 await invalidate("app:listOfEntities")
 await goto("/url/of/entity")
 })

we end up with the load function that has `depends("app:someEntity")` being triggered 3 times (the `depends("app:listOfEntities"` load function is in the `+page.ts` of a parent route).

We tried that both with using URL or custom identifier, the results are the same.

I'd argue that the severity is more than "annoyance", as this slows down the page, as we have to wait for 2 or 3 repeated GET requests to finish. Also it puts unnecessary pressure on the API server, as it has to serve a lot of pointless GET requests.


Do you still face the issue with latest versions without having to perform `git gc` as a workaround ? If the issue persists, it would be great if you can share a minimal repro.


Tested receipt of duplicated FedEx ID. Worked as expected.

Image

Ready for production


is the RPi onboard WiFi able to do AP + STA at the same time? and if so, how to do this to get AP + STA running?


I came to open a issue specifically asking for this implementation. Big support


So I decided to write a plugin as well for this and put it on NPM: URL

It's kind of similar to the one pasted above by @vanceeasleaf in that it uses Babel, but with some key advantages:

- Handles source maps
- Operates on the modules directly before they are written to chunks instead of transforming the chunks, meaning Babel helper injections won't pollute the global scope and it still works if an "eval" `devTool` is used
- Uses `@babel/preset-env` to be able to just specify targets and so that the generators can also be transpiled down to ES5 (just `plugin-transform-async-to-generator` is not enough)

Functionally it seems to work fine. The biggest issue I have is that it doesn't use `@babel/plugin-transform-runtime` because it's way too late in the Webpack process to handle injected imports. So if you have a lot of TLAs or even just 1 or 2 that permeate and result in a lot of downstream async modules, then the repeated helper and regenerator functions add up quickly in a large bundle. I plan to try and address this: URL

@alexander-akait or @vankop if you have any ideas or advice on the best way to seamlessly add the `@babel/runtime` dependencies, I would appreciate it. I'm looking at doing something similar to the way `ProvidePlugin` works, but I'm just starting to get myself familiar with how the `InitFragment` class works. I'm not sure if there is a hook order that will work to replace the imports or if I need to flag and rebuild to make it work.


Closing since this meeting has occurred and items are either in progress or to be revisited later.


This looks to be the cause of this issue with the Cognitive Speech Services SDK when running via Cloudflare Pages Functions. The Speech Services SDK checks the WebSocket readyState against WebSocket.OPEN, which works fine in a browser but fails in a Cloudflare function.

My current workaround is to define these manually:

export async function onRequest(context) {

 WebSocket.prototype.CONNECTING = 0;
 WebSocket.prototype.OPEN = 1;
 WebSocket.prototype.CLOSING = 2;
 WebSocket.prototype.CLOSED = 3;

...

Just reporting for posterity in case someone comes across the same issue. From the discussion above, I guess workerd isn't yet compliant with the standard for the WebSocket interface, but as soon as the open PR lands, that should be fixed.


If anyone else is coming up against the same problem, this seems to be an issue with Cloudflare workerd (see my comment here).

There's an open PR which looks like it should fix this.