You're great!

Wish i knew this module earlier thank you so much!

I've been updated for Parse JS SDK 1.8.2
https://github.com/gimdongwoo/TiParseJS/tree/master/dist

Thanks!
On May 26, 2016 7:50 AM, "Dongwoo Gim"<EMAIL_ADDRESS>wrote:
I've been updated for Parse JS SDK 1.8.2
https://github.com/gimdongwoo/TiParseJS/tree/master/dist
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/nitrag/TiParseJS/issues/5#issuecomment-221849978

The new sdk's doesnt support collections anymore im curious how you guys implement collections in your project.

That's interesting. I'm not using collections. @gimdongwoo any thoughts?

@nitrag so you use the object.extend i guess? and retrieve information?


Switch almalinux image to quay.io

@k-rister Can I merge as is or you prefer the merge commit to be squashed ?

I'm fine with as is.


Getting Started with Serenity

Question:
[New to Serenity]

Is Serenity is for Server side only?
How to achieve for User/Client side of serenity.

Thanks..

Serenity is Web Application Framework for Rapidly Developing Line of Business Application from database tables ( though you are not restricted to create any sort of application with it, it's great framework)

When serenity generates the code for UI it also generates API for the same to access from any rest client (Mobile / WPF / Any Language)

You need to use Cookie based authentication to login and retain the cookie client side to make a call
If you are able to implement IdentityServer4 working with Serenity you can also use Token Authentication and lot of other types authentication with Serenity

hope this answers you questions

Thanks for the info.
because i'd like to try this serenity framework as may server side for my projects/program.

There is a great guide at https://legacy.gitbook.com/book/volkanceylan/serenity-guide/details (online or PDF)

hi @Estrusco .. user guide is already in my bookmark thanks..

One thing.. how to run this sample from master into local computer. seems like i cannot find the startup project ..
Thanks.

Read the guide plz, all you need is there


Telmos/acag int jumpbox

:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/cloud-adoption-guide/intermediate-stage/jumpbox-explainer.md
:warning:Warning
View
Details

docs/cloud-adoption-guide/intermediate-stage/jumpbox-explainer.md

Line 22: [Warning] Invalid file link:(~/reference-architectures/virtual-machines-linux/jumpbox.md).
Line 23: [Warning] Invalid file link:(~/reference-architectures/virtual-machines-linux/linux.md).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/cloud-adoption-guide/intermediate-stage/jumpbox-explainer.md
:warning:Warning
View
Details

docs/cloud-adoption-guide/intermediate-stage/jumpbox-explainer.md

Line 19: [Warning] Invalid file link:(~/reference-architectures/virtual-machines-linux/jumpbox.md).
Line 20: [Warning] Invalid file link:(~/reference-architectures/virtual-machines-linux/linux.md).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Keyboard Manager: Switching Ctrl and Alt keys does not work (MacOS-like keyboard layout)

Microsoft PowerToys version
0.75.0
Installation method
PowerToys auto-update
Running as admin
No
Area(s) with issue?
Keyboard Manager
Steps to reproduce
I am both a Mac user and a Windows user. In order not to be confused I tried to make my Windows keyboard layout more Mac-like by switching Ctrl (left) and Alt (left) keys. As you can see from the screenshot the mapping it accepted and works (1). The tool also correctly can detect Alt (right). I am using a German keyboard and the Alt (right) key is also called "Alt Gr". AS shown in (2). The config (2) was not active I just added it for the sake of this Issue report to show you that your editor correctly identifies the Alt (right) key.
Copy-Paste also works like on the Mac, so instead of Windows keys Ctrl + C, I can press Alt + C to copy. So far so good. What does not work anymore is the curly braces {}. On the German keyboard you are using Alt (right)/Alt Gr + 0 for this. It does not work at all. So what I conclude is that your editor shows the correct config, but at evaluation time there seems to be a bug.
✔ Expected Behavior
I can use Alt (right)/Alt Gr the same as before e.g. for inserting curly braces, because I do not re-configured the keys.
❌ Actual Behavior
Alt Gr does not work anymore for instance for inserting curly braces.
Other Software
This behavior is independent of any editor. It is the same in Edge, Notepad++, ...

Forgot to attach the picture with my config. Only (1) was active, (2) is only for showing that left and right are correctly distinguished. Sorry, it is in German


[pthreads:x86-windows / pthreads:x64-windows] build failure

Host Environment

OS: Windows 10
Compiler: 2021-05-05-9f849c4c43e50d1b16186ae76681c27b0c1be9d9

To Reproduce
Steps to reproduce the behavior:
./vcpkg install pthreads
Failure logs
CMake Error: Problem with archive_write_finish_entry(): Can't restore time
CMake Error: Problem extracting tar: D:/TOOLS/vcpkg/downloads/pthreads4w-code-v3.0.0.zip
Call Stack (most recent call first):
scripts/cmake/vcpkg_extract_source_archive.cmake:46 (vcpkg_execute_required_process)
scripts/cmake/vcpkg_extract_source_archive_ex.cmake:118 (vcpkg_extract_source_archive)
scripts/cmake/vcpkg_from_sourceforge.cmake:229 (vcpkg_extract_source_archive_ex)
ports/pthreads/portfile.cmake:21 (vcpkg_from_sourceforge)
scripts/ports.cmake:141 (include)

It's a cmake bug, see https://gitlab.kitware.com/cmake/cmake/-/issues/19132.
Please track this issue in https://github.com/microsoft/vcpkg/issues/17489.


为什么demo跑出来的acc值都不变，有没有交流群

想问问有没有交流群可以交流心得的
想问下，为什么跑项目esim的demo例子，多个epoch的acc值一直不变。同样的我改成了中文的，情况也是一样，能跑通但是每个epoch的验证acc值都是不变

For less formal discussion we have a chat room on WeChat (mostly Chinese speakers). MatchZoo-py core developers are almost always present; feel free to find us there and we're happy to chat. Please add YQ-Cai1198593462 as your WeChat friend, she will invite you to join the chat room.

嗯嗯 谢谢～


Profile setup

In this milestone, I :

Created a route and a view component.
Used <NavLink /> for the page navigation links
Styled active class to indicate which section/page the user is currently on using textDecoration : underline
Fixed linter errors

Thanks for the review and approval 👍


Thoughts on upgrading this to use ES6 and webpack 2?

I would gladly help out just not sure if you want to move that way or not.

This actually works with ES6 and webpack 2. Can you give me an example use case where it doesn't?

That was terrible wording.  I should have asked if we wanted to add ES6 and webpack 2 docs.

Oh! Yes! Let's improve that. There's a tiny blurb about Webpack 2 in the README, but it could be improved. Would you like to makeapullrequest.com?

I can :)

Awesome! Don't forget to add yourself to the list of contributors :)


feat(env): IO_MAX_WAIT_TIME setting for replica timeout

This PR adds an environment variable "IO_MAX_WAIT_TIME" for istgt.
This setting is the maximum time istgt need to wait for response from replica. If replica doesn't respond with in this configured value, istgt will disconnect that replica.
Signed-off-by: Vitta<EMAIL_ADDRESS>

@vishnuitta  let's add a changelog file, named changelogs/unreleased/324-vishnuitta,  with one-linear description of the change

@vishnuitta let's add a changelog file, named changelogs/unreleased/324-vishnuitta, with one-linear description of the change

I'm adding a oneliner as feat(env): IO_MAX_WAIT_TIME env setting for replica timeout


[Groups UI] - Vaults endpoints

POST /w/[wId]/vaults - create vault
{
  name: "vault name",
  members: [ uids ]
}

GET /w/[wId]/vaults - list vaults
[
 {
  name: "vault name"
 }
]

GET /w/[wId]/vaults/[vId] - get vault info (?)
PATCH /w/[wId]/vaults/[vId] -
{
 name: "name"
 members: [ uids ]
 content : [
  { data_source: id , parents: [ ... ] }
 ]
}

GET /w/[wId]/vaults/[vId]/data_sources - get all vault data_source_views:
[
  {
    category: ["managed"|"files"|"webfolder"|"apps"]
    createdAt: ..,
    updatedAt: ..,
    editerByUser: { },
    usage: 10,
    data_source: {
      name: "managed_notion",
      connectorProvider: "notion",
      ...
    },
]

GET /w/[wId]/vaults/[vId]/data_sources?category=["managed"|"files"|"webfolder"|"apps"]
filtered by category
GET /w/[wId]/vaults/[vId]/data_sources/categories :  GroupedDataSourceViewType[]
[
 { category:"connected", count: 10, usage: 10 },
 { category:"folder", count: 20, usage: 10 }
]

GET /w/[wId]/vaults/[vId]/data_sources/[dsvId]/content?parentId
similar to w/[wId]/data_sources/[name]/managed/permissions
can be used for managed/folders/website ? returns a ContentNode[]. Add file size, number of children (is possible)

members
GET /w/[wId]/vaults/[vId]/members - get members list
POST /w/[wId]/vaults/[vId]/members - add member

Let's be more explicit I think with /../vaults/../data_sources and /../vaults/../data_source_views
Aggregating different objects under the same endpoints is generally something we live to regret + it's not RESTful?

I'm not sure I understand your concerns about unifying everything behind a single endpoint. The logic for displaying content nodes remains unchanged. The vault path determines the current user's access to the resource.
In the app, I've started to implement this approach and created a common interface using duck-typing. This allows us to use the new DataSourceOrView type across various contexts where the behavior isn't affected by whether it's a data source or a view. For example, in the assistant builder and when browsing the tree, there's no difference between selecting a data source or a view.
This change will help us transition and ensure the UI isn't cluttered with typeguards in 50+ different places.
Curious to hear your thoughts/FUD you might have about the approach we take here.

My main concern is that it's 100% sure we don't want to do that in the public API so it begs the question for our internal API.
Short term this seems desirable indeed and since this is for internal use this is easy to refactor so I'm not too worried but I still think it's possible we'll want to move away from it at some point... but that's likely a bias towards dead simple API and code constructs vs more abstracted layering.
Here my unexpressed worry is that it's going to be harder for new comers to understand quickly DataSourceOrView and find where the "real code" is. I know we have different sensibilities on that topic.

Basically we want to strike the right tradeoff between the dead simple with lots of diff and the purely abstract with indeed much less diff but so much abstraction that it's impossible to find what code is run when 👍

Absolutely, I’m totally on the same page regarding the public API! My main point here is about the internal API. We don't necessarily need to mirror the architecture of the public API for internal use. The internal API should first meet our needs and abstract complexity if we can/need.

Basically we want to strike the right tradeoff between the dead simple with lots of diff and the purely abstract with indeed much less diff but so much abstraction that it's harder to find what code is run when 👍
Aligned!


AudioStreamPlayer does not stop playback

Godot version:
3.2.1
OS/device including version:
Windows 10 64-bit
Issue description:
AudioStreamPlayer does not stop playback if stream position is zero.
In my project sometimes there are situations when states change very quickly, one state plays sound effect, another stops it.
I found out that
$sfx.play()
$sfx.stop()

is not working as expected.
Steps to reproduce:
Add AudioStreamPlayer, load sound stream and execute play() stop() methods in once block.
Minimal reproduction project:
AudioStreamPlayerPlayStop.zip

It seems the call to stop is too quick.
$AudioStreamPlayer.play()
OS.delay_msec(15)
$AudioStreamPlayer.stop()

Delay of 15ms or makes it work fine.

@Anutrix $AudioStreamPlayer.call_deferred("stop") might be a cleaner way to do it, as it will exactly wait for 1 rendered frame before stopping.

I tried both methods, but that didn't work.

I use temporary solution:
# For playback.
if $AudioStreamPlayer.stream_paused:
	$AudioStreamPlayer.stop()
	$AudioStreamPlayer.stream_paused = false

$AudioStreamPlayer.play()

# For stopping.
$AudioStreamPlayer.stream_paused = true

I just ran into this issue, which is still present in Godot 3.2.2

Does anyone know if there is a fix for this or a workaround?
I have tried all of the above and had no success.
Thanks

Does anyone know if there is a fix for this or a workaround?
I have tried all of the above and had no success.
Thanks

@Manx191 Depending on what you're trying to achieve, you may have more luck swapping out the stream resource to play a different sound (or setting it to null).

@Manx191 Depending on what you're trying to achieve, you may have more luck swapping out the stream resource to play a different sound (or setting it to null).

@Manx191
Try this:
$AudioStreamPlayer.stop() $AudioStreamPlayer.seek(-1)

@Manx191
Try this:
$AudioStreamPlayer.stop() $AudioStreamPlayer.seek(-1)


automatically filled out hashtags shouldn't be cached

Here's what I see as potentially confusing: When a user loads iD from an external page that initializes the chanset comment with some text that includes some hashtags, these are also set in the new hashtags list (and hashtags field of the osm changeset). These hashtags are kept in the browser's cache just like manually entered hashtags. If a user is not aware about what hashtags are, they could continue to commit other changes with these hashtags, even though these hashtags likely don't apply anymore. A similar case is when a user opens jobs from multiple HOT tasking manager projects, without thinking about cleaning up the hashtags list when changing from one HOT project to another one. Here's an example, where the hashtags includes multiple #hotosm-project- ids, even though it obviously should only belong to one: http://www.openstreetmap.org/changeset/51495572
I think automatically parsed hashtags shouldn't be persisted/cached. Additionaly, if iD is opened with an external changeset-comment "template", and if that one includes any hashtags, the existing cached hashtags should probably be cleared (because it would be easy to overlook any existing hashtags that likely not fit the current task anymore in a longish list of automatically filled out list of hashtags).

I think automatically parsed hashtags shouldn't be persisted/cached. Additionaly, if iD is opened with an external changeset-comment "template", and if that one includes any hashtags, the existing cached hashtags should probably be cleared

I agree, this was something I wasn't too sure about when I implemented the feature - so I just made it work like the existing comments field - then added the automatic parsing later, which I realize now can conflict with the cached ones.


Configure find my mouse activation.

Description of the new feature / enhancement
I would like it as tripple ctrl or double some other custom key?
Scenario when this would be used?
Double ctrl happens too often in normal use as a developer
Supporting information
when copy and pasting content rapidly i  trigger this feature way too often.

https://github.com/microsoft/PowerToys/issues/14651 would be the tracking issue here


Add Hooktube to supported sites

https://github.com/rg3/youtube-dl/commit/8b561bfc9d15bf487be0e0bb5bb1d7248fd321d3

This file is autogenerated.


Feature Request - Add an option to add the default language comments to all language files

We need to have the default language comments (English in our case) carried into ALL of the resulting language files. I am not seeing a way to do it nor do I see any options around it.

You could use the scripting module to synchronize the comments

@bhartsfield any luck trying to script this?

No. I haven't had the time to look into it. The person managing the files is just doing it manually until I can put some time into it.


update(cmake): bumped libs to 0.10.4

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

/kind release

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area engine

/area tests

/area proposals

/area CI

What this PR does / why we need it:
Bump the libs version to 0.10.4.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
The same changes have been introduced in the 0.34.x branch, too. (https://github.com/falcosecurity/falco/pull/2422/commits/84ab4087705734bd4b425c1491e5633a53f28ae1)
Does this PR introduce a user-facing change?:

build: upgrade libs to 0.10.4

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: alacuku
Once this PR has been reviewed and has the lgtm label, please assign leogr for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

Thank you!
Formally, this is part of
/milestone 0.34.1

LGTM label has been added.  Git tree hash: 762e1f4bdbd4cdad89a812c5118007b32f86218e

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

Needs approval from an approver in each of these files:

OWNERS [leogr]

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

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

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,leogr]

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


Discussion for some French translations

Many thanks for this very nice, interesting and promising package!
Most of the French wordings are perfectly translated (congratulations!) but others look a bit strange IMHO. Since I'm unsure of what would be the best translations, I open this issue in order other French-speaking people could give their opinion so that we can reach a consensus.
Controversial translations
Here are the translations that IMHO need to be discussed:
"Table" vs "Tableau"
type = table ,
  gender = f ,
  Name-sg = Table ,
  name-sg = table ,
  Name-pl = Tables ,
  name-pl = tables ,

"Table" is the translation used by e.g. babel-french but many users feel a bit uncomfortable with this translation since "Tableau" is much more common.
"Point" vs "Item"
type = item ,
  gender = m ,
  Name-sg = Point ,
  name-sg = point ,
  Name-pl = Points ,
  name-pl = points ,

"Point" is maybe appropriate, but "Item" is also a French word which not so uncommon and relies clearly on the LaTeX command \item.
"Démonstration" vs "Preuve"
type = proof ,
  gender = f ,
  Name-sg = Démonstration ,
  name-sg = démonstration ,
  Name-pl = Démonstrations ,
  name-pl = démonstrations ,

"Démonstration" is clearly an appropriate translation of "Proof" but "Preuve" is also appropriate, understandable, more directly derived from "Proof"... and shorter.
"Liste" vs "Listing" vs "Code"
type = listing ,
  gender = f ,
  Name-sg = Liste ,
  name-sg = liste ,
  Name-pl = Listes ,
  name-pl = listes ,

I guess "Liste" would be confusing for French-speaking people, as they wouldn't have in mind a printed source code. Conversely, "Listing" is a French word less confusing. Maybe "Code" could also be an option.
Non-controversial translations
I guess the following translations don't need any discussion:
type = book ,
  gender = m ,
  Name-sg = Livre ,
  name-sg = livre ,
  Name-pl = Livres ,
  name-pl = livres ,

type = part ,
  gender = f ,
  Name-sg = Partie ,
  name-sg = partie ,
  Name-pl = Parties ,
  name-pl = parties ,

type = chapter ,
  gender = m ,
  Name-sg = Chapitre ,
  name-sg = chapitre ,
  Name-pl = Chapitres ,
  name-pl = chapitres ,

type = section ,
  gender = f ,
  Name-sg = Section ,
  name-sg = section ,
  Name-pl = Sections ,
  name-pl = sections ,

type = paragraph ,
  gender = m ,
  Name-sg = Paragraphe ,
  name-sg = paragraphe ,
  Name-pl = Paragraphes ,
  name-pl = paragraphes ,

type = appendix ,
  gender = f ,
  Name-sg = Annexe ,
  name-sg = annexe ,
  Name-pl = Annexes ,
  name-pl = annexes ,

type = subappendix ,
  gender = f ,
  Name-sg = Annexe ,
  name-sg = annexe ,
  Name-pl = Annexes ,
  name-pl = annexes ,

type = page ,
  gender = f ,
  Name-sg = Page ,
  name-sg = page ,
  Name-pl = Pages ,
  name-pl = pages ,
  rangesep = {\textendash} ,

type = line ,
  gender = f ,
  Name-sg = Ligne ,
  name-sg = ligne ,
  Name-pl = Lignes ,
  name-pl = lignes ,

type = figure ,
  gender = f ,
  Name-sg = Figure ,
  name-sg = figure ,
  Name-pl = Figures ,
  name-pl = figures ,

type = footnote ,
  gender = f ,
  Name-sg = Note ,
  name-sg = note ,
  Name-pl = Notes ,
  name-pl = notes ,

type = endnote ,
  gender = f ,
  Name-sg = Note ,
  name-sg = note ,
  Name-pl = Notes ,
  name-pl = notes ,

type = note ,
  gender = f ,
  Name-sg = Note ,
  name-sg = note ,
  Name-pl = Notes ,
  name-pl = notes ,

type = equation ,
  gender = f ,
  Name-sg = Équation ,
  name-sg = équation ,
  Name-pl = Équations ,
  name-pl = équations ,
  refpre = {(} ,
  refpos = {)} ,

type = theorem ,
  gender = m ,
  Name-sg = Théorème ,
  name-sg = théorème ,
  Name-pl = Théorèmes ,
  name-pl = théorèmes ,

type = lemma ,
  gender = m ,
  Name-sg = Lemme ,
  name-sg = lemme ,
  Name-pl = Lemmes ,
  name-pl = lemmes ,

type = corollary ,
  gender = m ,
  Name-sg = Corollaire ,
  name-sg = corollaire ,
  Name-pl = Corollaires ,
  name-pl = corollaires ,

type = proposition ,
  gender = f ,
  Name-sg = Proposition ,
  name-sg = proposition ,
  Name-pl = Propositions ,
  name-pl = propositions ,

type = definition ,
  gender = f ,
  Name-sg = Définition ,
  name-sg = définition ,
  Name-pl = Définitions ,
  name-pl = définitions ,

type = result ,
  gender = m ,
  Name-sg = Résultat ,
  name-sg = résultat ,
  Name-pl = Résultats ,
  name-pl = résultats ,

type = remark ,
  gender = f ,
  Name-sg = Remarque ,
  name-sg = remarque ,
  Name-pl = Remarques ,
  name-pl = remarques ,

type = example ,
  gender = m ,
  Name-sg = Exemple ,
  name-sg = exemple ,
  Name-pl = Exemples ,
  name-pl = exemples ,

type = algorithm ,
  gender = m ,
  Name-sg = Algorithme ,
  name-sg = algorithme ,
  Name-pl = Algorithmes ,
  name-pl = algorithmes ,

type = exercise ,
  gender = m ,
  Name-sg = Exercice ,
  name-sg = exercice ,
  Name-pl = Exercices ,
  name-pl = exercices ,

type = solution ,
  gender = f ,
  Name-sg = Solution ,
  name-sg = solution ,
  Name-pl = Solutions ,
  name-pl = solutions ,

Many thanks for this very nice, interesting and promising package!

Thanks! I hope you enjoy it!

Most of the French wordings are perfectly translated (congratulations!) but others look a bit strange IMHO.

This is most appreciated. My contact with French is restricted to reading (thus passive), and literature at that, so quite distanced from the kind of vocabulary needed for this task. I did use as reference some packages which translate document elements as a reference (babel, cleveref, translator, translations), but there is only so much I could do.  And my criterion here is that it should sound good and be common usage to French speakers, which I'm not. So, as humble as your opinion may be, it is better than mine.

Since I'm unsure of what would be the best translations, I open this issue in order other French-speaking people could give their opinion so that we can reach a consensus.

I'm glad you opened the discussion. Thank you very much. I'll comment on each of your suggestions.
"Table" vs "Tableau"
I knew this one would be contentious. babel sets \tablename to "Table" and \listtablename to "Liste de tableaux". translations and translator follow babel, cleveref uses "Tableau".
My thought here was to follow babel because, in this case, it should match the caption, which is ultimately set by it. If pretty much everyone just changes babel's default here, it might be a case to use "Tableau". But if opinions diverge, I'd stick with babel for the mentioned reason.
"Point" vs "Item"
Point taken :). Funny enough, being myself a native speaker of Portuguese, I've chosen "Item" for it.
"Démonstration" vs "Preuve"
I followed here translator and translations, if I recall. Anyway, I'm less concerned it is directly derived from the English word, than with what is the most common use for French speakers for the purpose. But the length argument is a good one here, "Démonstration" is indeed too damn long.
"Liste" vs "Listing" vs "Code"
I was unsure of this one. I like "Listing", and I didn't know it existed in French. "Code" sounds damn good at first sight, and it would be an alternative for several languages. And I almost included a code type in the package. There's only one problem, it is a numberless word, so the plurals don't work and, hence, we'd have to use "Code something", e.g. "Code block" or whatever, in which case, the term sounds less appealing. Anyway, if "Liste" can be confusing, it is a good reason for something else.
Non-controversial translations
Well, if any other French speaker wants to chime in about other translations, it is certainly much welcome.
All in all, I'll suggest the following. For table, I'd need a strong reason do diverge from babel, so if a number of people agree "Tableau" it is indisputably better, I'd consider it. For the remainder suggestions, I'm ready to go with your take, if you do think they represent an improvement. So far you've only told to me they are "controversial", please tell me if you think there is a clear case for them. If you feel some of the cases represent an improvement, beyond being controversial, I'm quite ready to take your opinion over mine. Even if we do so provisionally, pending other French speakers also commenting here, for which I'll leave this issue open for some time.

Just adding some information here. I was researching the use of "Démonstration" vs "Preuve" by mathematicians, and searched for French associations of the area. I found the Société Mathématique de France, which provides a couple of LaTeX document classes (smfart.cls and smfbook.cls), in which \proofname is set as \def\proofname{D\'emonstration}.
I also found that you, @dbitouze , maintain the gzt classes for La Gazette des Mathématiciens, from the same Association. So, I suppose you can tell us what is the most common use among French mathematicians. :-)

On some French LaTeX newsgroup and mailing list, I asked French people to continue the discussion here, but those who answered preferred to discuss there.
Here is what emerged from these discussions (combined with your remarks).
Non-controversial translations
"Table" vs "Tableau"
There is some consensus to not diverge from babel as you suggest. But, instead of hard-coding "Table", it would be better to stick with \tablename which may be redefined by the user (directly or via \frenchtablename provided by babel-french). Here is what I suggest:
\documentclass[french]{article}
\usepackage[T1]{fontenc}
\usepackage{zref-clever}
\usepackage{babel}

\ExplSyntaxOn
\zcLanguageSetup{french}{
  type = table ,
  gender = f ,
  Name-sg = \text_titlecase:n { \tablename } ,
  name-sg = \text_lowercase:n { \tablename } ,
  Name-pl = \text_titlecase:n { \tablename }s ,
  name-pl = \text_lowercase:n { \tablename }s ,
}
\ExplSyntaxOff

\begin{document}

\section{Par défaut}

\begin{table}[ht]
  \centering
  Foo
  \caption{Foo}
  \zlabel{foo}
\end{table}

La \zcref{foo} est très intéressante !

\section{tablename $\to$ Tableau}

\renewcommand*\tablename{Tableau}

\begin{table}[ht]
  \centering
  Bar
  \caption{Bar}
  \zlabel{bar}
\end{table}

Le \zcref{bar} est très intéressant !
\end{document}

IMHO, these ways of doing:

relying on names defined by babel (and polyglossia) instead of hard-coding,
relying on \text_titlecase:n, \text_lowercase:n, etc. in order to reduce redundancy,

should be used as well for:

the other (numbered) names

  \chaptername
  \appendixname
  \figurename
  \tablename
  \partname
  \pagename
  \proofname

the other languages.

"Point" vs "Item"
No real consensus: it could be "Point", "Item", "Numéro". I suggest letting "Point".
"Démonstration" vs "Preuve"
No real consensus but, as advised before, maybe the best would be to rely on \proofname which may be redefined by the user (directly or via \frenchproofname provided by babel-french). BTW, I don't see any use case for "Proof" since, usually, proofs are unnumbered.
Non-controversial translations
Well, other French speaker wanted to chime in about other translations! :wink:
Page
\pagename instead of "Page" (as advised above) and, for rangesep, \textendash → -:
type = page ,
  gender = f ,
  Name-sg = \text_titlecase:n { \pagename } ,
  name-sg = \text_lowercase:n { \pagename } ,
  Name-pl = \text_titlecase:n { \pagename }s ,
  name-pl = \text_lowercase:n { \pagename }s ,
  rangesep = {-} ,

Footnotes
Though it could be seen as a bit pedantic:
type = footnote ,
  gender = f ,
  Name-sg = Note infrapaginale ,
  name-sg = note infrapaginale ,
  Name-pl = Notes infrapaginales ,
  name-pl = notes infrapaginales ,

(or a better way by using \text_titlecase:n, \text_lowercase:n, etc.)
End notes
type = endnote ,
  gender = f ,
  Name-sg = Note finale ,
  name-sg = note finale ,
  Name-pl = Notes finales ,
  name-pl = notes finales ,

(or a better way by using \text_titlecase:n, \text_lowercase:n, etc.)
Subappendix
Suggested by some people:
type = subappendix ,
  gender = f ,
  Name-sg = Sous-annexe ,
  name-sg = sous-annexe ,
  Name-pl = Sous-annexes ,
  name-pl = sous-annexes ,

(or a better way by using \text_titlecase:n, \text_lowercase:n, etc.)
Paragraph
I don't see the point for (sub)paragraph: just as for (sub)subsection, the reader of the document just doesn't care the paragraph he's interested in, has been introduced by the author with a \paragraph command. IMHO, a single "Section" name is enough for ((sub)sub)section and (sub)paragraph (AKA ((sub(sub(sub)))sub)section).

On some French LaTeX newsgroup and mailing list, I asked French people to continue the discussion here, but those who answered preferred to discuss there.
Here is what emerged from these discussions (combined with your remarks).

Thank you very much for reaching out to other people and bringing a summary of it here.

Well, other French speaker wanted to chime in about other translations! :wink:

This is great and appreciated.
I'll comment on each case below, but a general issue first, relative to the general suggestion of using babel set variables to populate the dictionaries. This is one thing I had considered, and eventually I have decided not to share plumbing with babel/polyglossia. Doing so would complicate things quite considerably and, though admittedly there would be some gain, I don't think it is large enough to grant it. I don't mean to say I know for sure this is the best decision, but I have put quite some thought into it, and have made a call about it. I'd like to stick to it, at least until this is proven to bring more problems than it solves.  In particular, the current design of the package allows for the lang option to receive values current, main or an arbitrary language, and this can also be set locally. Given that the variables set by babel would only correspond to the current language, it would be quite immediate to break the current structure.
Besides, relying on a single variable to generate four cases is not sufficiently general. For example, not necessarily adding an s to the end is sufficient to generate a plural.
In other words, by design, things should be smooth by default, but if you choose to change, e.g. \tablename, it is expected that you also set corresponding names for zref-clever:
\addto\captionsfrancais{%
   \renewcommand*\tablename{Tableau}%
}
\zcLanguageSetup{french}{
  type = table ,
    Name-sg = Tableau ,
    name-sg = tableau ,
    Name-pl = Tableaux ,
    name-pl = tableaux ,
}

This is some setup required, but I don't think this should be a big deal, since it would be done only once in the preamble. And in most cases would not be needed at all.
"Table" vs "Tableau"
I'll stick to "Table" then, following babel.
"Point" vs "Item"
Ok, "Point" it is.
"Démonstration" vs "Preuve"
I'll leave it to "démonstration" for the time being then.
Btw, I'm not a mathematician, but if by "usually" you mean "never" (or "almost never"), I might just drop the type. There are a number of types provided in the dictionaries which do not have any counter association by default, they are just there available for the convenience, in case someone decides to use them. This is one of them. It doesn't do any harm, but if its use is just too exceptional, we might just leave it out.
"Liste" vs "Listing" vs "Code"
Where there any suggestions on this one? As far as I can tell, the "least bad" would be "listing", is that your thought too?
Page

\textendash → -

Ah! Good typographical convention catch. I'll change it.
Footnotes and End notes
Well, I don't know of the usage in French, but indeed "Note infrapaginale" sounds heavy to me. But if you're sure, I'll change it. Please confirm. For endnotes, I agree they may require some more "explanation" since they are not within immediate reach.
Subappendix
I don't disagree with the translation, of course. But this sounds more of a consistency issue. Why would "subapendix" be called "sous-annexe" when a "subsection" is called "section"? As a matter of fact, this is my fault. I don't recall why I added the subappendix type in the first place (probably some remnant of an intermediate state for the appendix package support). I'll think of it and, if the later is indeed the case, I might drop the type altogether.
Paragraph
This is indeed debatable, but less an issue for the dictionary than one for the countertype setup. I think it makes sense to distinguish paragraph, but I don't have a strong opinion here. And I don't expect many people to keep numbering as deep as pararagraphs to start with. But changing it is a matter of:
\zcsetup { countertype = { paragraph = section , subparagraph = section } }

But, beyond French usage here, do you think this would be a better default?
Again, thank you very much for your input and for going out of your way to seek other people's opinion on this.

I've taken a look at the discussions at GUTenberg and fr.comp.text.tex (https://groups.google.com/g/gut_fr/c/rNLm6weGcyg and https://groups.google.com/g/fr.comp.text.tex/c/Fa11Tf6MFFs) and I have some comments which may be useful or perhaps of interest.
The first thing I noticed is that there appeared to be an implicit presumption that its hard to escape from the built-in dictionary values. In fact, the built-in dictionaries are just the defaults, the reference types are fully configurable (at least to the same extend as the built-in dictionaries are able to). True, one can always go with ⟨terme préféré⟩~\zref{⟨label⟩} or  ⟨terme préféré⟩~\zcref[noname]{⟨label⟩} for an occasional local special case. But one should not need to resort to them just because they don't like the dictionary defaults. In this case, it is just a matter of configuring the type to other values with \zcLanguageSetup or \zcRefTypeSetup. The defaults are expected to be reasonable, and are hopefully useful to many, but nobody is bound to them in any way.
Second, the case of footnotes. In this regard, it is important to note that the reference types in the dictionaries are not equally important. On a first level, there are types created to cater for counters underlying LaTeX (kernel) or standard classes document elements: sectioning, table, figure, footnote, and so on. Second, types created for the purpose of handling elements created by some popular packages, e.g. endnote. Third, some types which I have included for presumed common use cases for convenience, and which might be leveraged by the user if they so want to, but which are not associated to anything by default. An example of the later is the note type. In particular, I have created this for the sake of some languages for which the best passing term is specific for "footnotes" (English, German), and I thought it might be useful to have a generic type as well, thus "notes". But, my initial thought at least, is that for languages for which a generic term would be fit for the footnote type (French among them, so I thought), there would be no harm in them being equal. In sum, what I'm trying to say is: choose the best term for the footnote type for the sole sake of how you'd like to refer to this document element, and not to "distinguish it from the note type" or to "educate the masses". The note type is of little consequence, the footnote, quite the contrary. I do think "note infrapaginale" is a poor choice but, that said, it is up to you folks.
Third, it did not appear in the discussions, one of the features of the package which I think (and hope) might be particularly interesting for French speakers (and other languages with inflected articles), which is the nudge option. This feature offers some guard against what was correctly named "aberrations" of the kind of automation zref-clever provides. (Those interested may want to take a look at the "Options" and "Internationalization" sections of the manual).
Finally, I'd like to thank very much everyone who weighted in those threads, and particularly to @dbitouze for conducing them. That was much appreciated.

I've taken a look at the discussions at GUTenberg and fr.comp.text.tex (https://groups.google.com/g/gut_fr/c/rNLm6weGcyg and https://groups.google.com/g/fr.comp.text.tex/c/Fa11Tf6MFFs) and I have some comments which may be useful or perhaps of interest.

Congratulations for the investigations and the pain of reading French! :smile:

The first thing I noticed is that there appeared to be an implicit presumption that its hard to escape from the built-in dictionary values. In fact, the built-in dictionaries are just the defaults, the reference types are fully configurable (at least to the same extend as the built-in dictionaries are able to). True, one can always go with ⟨terme préféré⟩~\zref{⟨label⟩} or  ⟨terme préféré⟩~\zcref[noname]{⟨label⟩} for an occasional local special case. But one should not need to resort to them just because they don't like the dictionary defaults. In this case, it is just a matter of configuring the type to other values with \zcLanguageSetup or \zcRefTypeSetup. The defaults are expected to be reasonable, and are hopefully useful to many, but nobody is bound to them in any way.

OK. IMHO, the objection was for occasional local special cases, but good to know.

Second, the case of footnotes. In this regard, it is important to note that the reference types in the dictionaries are not equally important. On a first level, there are types created to cater for counters underlying LaTeX (kernel) or standard classes document elements: sectioning, table, figure, footnote, and so on. Second, types created for the purpose of handling elements created by some popular packages, e.g. endnote. Third, some types which I have included for presumed common use cases for convenience, and which might be leveraged by the user if they so want to, but which are not associated to anything by default. An example of the later is the note type. In particular, I have created this for the sake of some languages for which the best passing term is specific for "footnotes" (English, German), and I thought it might be useful to have a generic type as well, thus "notes". But, my initial thought at least, is that for languages for which a generic term would be fit for the footnote type (French among them, so I thought), there would be no harm in them being equal. In sum, what I'm trying to say is: choose the best term for the footnote type for the sole sake of how you'd like to refer to this document element, and not to "distinguish it from the note type" or to "educate the masses". The note type is of little consequence, the footnote, quite the contrary. I do think "note infrapaginale" is a poor choice but, that said, it is up to you folks.

OK, I see. So I guess we can let (n|N)ote(s) for both type = footnote, type = endnote and type = note.

Third, it did not appear in the discussions, one of the features of the package which I think (and hope) might be particularly interesting for French speakers (and other languages with inflected articles), which is the nudge option. This feature offers some guard against the occasional "aberrations" the kind of automation zref-clever provides may indeed sometimes produce. (Those interested may want to take a look at the "Options" and "Internationalization" sections of the manual).

Indeed (I must admit I didn't read carefully the whole documentation yet). Maybe some examples in the documentation would be helpful.

Finally, I'd like to thank very much everyone who weighted in those threads, and particularly to @dbitouze for conducing them. That was much appreciated.

You're welcome.

OK, I see. So I guess we can let (n|N)ote(s) for both type = footnote, type = endnote and type = note.

Done. Thanks again.

Indeed (I must admit I didn't read carefully the whole documentation yet). Maybe some examples in the documentation would be helpful.

Admittedly, it is somewhat hard to provide self-sufficient examples of it, since it is more of a "workflow" kind of feature. But the Internationalization section (roughly the second half of it) of the manual has a detailed description of the intended use of the feature, with some small examples included.

Hi,
Concerning the "Démonstration" vs "Preuve" I think Preuve is more related to material things and it's closer to "evidence" in english while demontsration denote more so act or so reasoning to prove something. Both are perfectly fine but I think french mathematicians will use more the "Démonstration" word. Using preuve is an englisism in this context I thinkso you made the good choice.
The Académie française says :
Preuve : Vérification d’une opération de calcul, qui se fait généralement par l’opération opposée. La preuve de la division se fait par la multiplication. Preuve par neuf, méthode fondée sur les propriétés arithmétiques du nombre neuf et qui permet de vérifier le résultat d’une multiplication.
Démonstration : Action de démontrer ; résultat de cette action. Démarche rationnelle qui établit la vérité d’une proposition.
So from my understanding the Démonstration is more general and enforce the fact you are doing some reasoning and acting to show the veracity.
As french native speaker I have always heard my teachers say "démonstration" and seen it on french books. The Nicolas Bourbaki group for example always use it.

Hi @flagarde , thank you for chiming in! I think "Démonstration" is a keeper indeed, opinions seem to converge. Even when "Preuve" would be formally correct, it seems to be considered an anglicism (which probably is indeed, the interesting bit is how people feel about it), and "Démonstration" is not only more precise but also preferred and commonly used for the purpose at hand, which in this case should match technical/specialized jargon.

Concerning the other "controversial translations" pointed by @dbitouze :
"Table" vs "Tableau"
Both are perfectly french word and both are recommanded by the Académie française. Tableau is more an everyday word so I would be tempted to use Table as it looks more appropriate for books.
"Point" vs "Item"
Point is more appropriated because the word Item exists in french but don't have the meaning we want in this case. Again the Académie française explicitly point this as englisism in this case
"xxe siècle. Emploi substantivé d’item I, par l’intermédiaire de l’anglais où ce mot signifie « numéro, article »." An other alternative would be ÉLÉMENT :
Ce qui entre dans la constitution d’un ensemble.
1. Chaque partie identifiable à l’intérieur d’un ensemble qu’elle contribue à former.

"Liste" vs "Listing" vs "Code"
I agree with @dbitouze that List would be very confusing for a french speaker. However the word listing is not recommanded by the Académie française https://www.dictionnaire-academie.fr/article/DNP0453. And even the meaning of this englisism has not the meaning we want but is related to the action of creating a table using some software. Code or code source would be a better solution as mentioned. The code source solution stress the fact it should be compiled or will generate something or will do something.

Hi @flagarde , thanks again for adding to the discussion.
"Table" vs "Tableau"
With respect to this one, it seems clear by now that both would be legitimate choices, and that the preference is divided. In this case, the fact that babel uses "Table" for \tablename is enough reason to keep it for the type here, since it should match the caption text by default. Again, this is just the default, and can be reconfigured for those who prefer it different.
"Point" vs "Item"
That's what we've kept, thanks for bringing further reasons to having done so.
"Liste" vs "Listing" vs "Code"
Here, the consideration by @dbitouze that "Liste" would be confusing was enough for me to drop it. I went with "Listing" as the least bad alternative. But this is admittedly a difficult one, and not just in French. In particular, using "Code" has the problem of it being a numberless word, and thus the plurals don't work (see  https://github.com/gusbrs/zref-clever/issues/1#issuecomment-979211870). As far as I can tell, "Code source" would also be affected by the same problem. Would something like "comme on peut voir en Code sources 2 et 4 ..." really sound good in French? I doesn't sound good to me, but perhaps I'm thinking in another language.
Btw, the link you provided, suggests another alternative: "Listage". Is it a good one? Better than "Listings"? (Just asking, not really proposing. If my Portuguese ears can be any reference, this would likely suffer from the same potential confusion as "Liste").
From my perspective, the requirements for this one are that it must be a good default to encompass anything which may regularly be included in listing or lstlisting environments. And, in general, we are not looking for the "perfect translation for the English word used for the type" but rather the term a French speaker would commonly use to refer to the document object in question, and a numbered object at that. I make this distinction here because "Code" and "Code source" seem to fit better "what the object contains" than "the object itself". So I'd more naturally think "listings contain source code" than "listings and source codes can be used interchangeably". But, again, perhaps I'm just thinking in English.
What do you both say?

For me Listage sounds very weird and really looks as a englicism and even carry some pejorative tone but maybe is just my fealing about it. Anyway even the definition the Academie is giving for such word is not describing what we want.
For the Code word I think the problem is that for a french speaker it seems to miss some word describing the code. Code is (I tried to find one but was unable to find one) never alone :
code secret
code d'honneur
code vestimentaire
....

the only situations I was able to find with code alone looks just a short-cut for 1. password and 2. source code and seem to be not appropriated in writting.
For me :
 "comme on peut voir dans le code source 1"
 "comme on peut voir dans les code source 2 et 4"

looks ok, others alternatives i can think of are :
"Source" and "série d'instructions" or "Programme"
"série d'instructions" has the advantage that série is a not so bad synonym of "liste" wich is close to the Listing word and can carry the notion of order (cannot be mixed) while at least for me the liste doesn't carry in french or is less evident
liste de course
liste de noms
etc...

and instruction can be related to some rules, codes you need to follow, that for me represent quite well what a program or "Listing" is : some rules you have to follow in order.
The only draw back I can see is that it maybe carry a more low level (CPU level) meaning in computing science. I think french speaker will be more tented to say Programme for high level code and "série d'instructions" for low level.
Programme can carry a meaning of listing and is not only related to computers.

Hi @flagarde , this is a tricky one indeed. I suspect that not even in English the word is that good, as a lot of stuff can go into a listings environment, such that choosing a single word which is generic enough is a hard task, and whatever the result, it will be unsatisfying to some extent.
As to your suggestions, I think "Programme" is not general enough. A typical use case of listings/lstlistings is for code snippets. A "program" is comprised of a "series of instructions", but not any "series of instructions" make a "program".  Regarding "série d'instructions", it sounds a little too heavy for the purpose. Reiterating the point I made earlier, it seems to work better to describe the "content of the environment", than to be a "good name to refer to the document element".
If "source" or "code source" work well in French, even in the plural, those seem reasonable alternatives, I think. I admit I still favor either "Listing" or "Listage", as they seem the least surprising here to me. But I'm not French...
And since this is a somewhat specialized/jargon term, ideally we should cater for its use in computer sciences literature, but we'd have to rely on someone acquainted with the subject.
Anyway, do you really think that "source" or "code source" is what "the median French-speaking LaTeX user would expect/want" for it, instead of "listing"/"listage"? (And consider this is a default value, which should be reasonable, and hopefully useful to most people, but it is also always configurable for anyone who wants something else.)

hi @gusbrs
I can only talk for myself but Listage sounds ugly and a "des-englisism" and would refers for a french speaker to "the action of doing a list" and will have nothing to do with the "Listing". Using Listing has the advantage to stress that it is an englisism and so will warn it is maybe not what a french speaker would expect from the french word "Liste" which is represented by "Itemize" in LaTeX.
"source" or "code source" work well in French, I think even people with no computing background will have a naive idea of what will be the purpose of the text inside the document element you are refering to.
I think the best option would be to stay with "Listing" and ask more people if the other alternatives seam better for them

Hi, @flagarde . Ok, we leave it at "Listing" for the time being then. And thank you very much for your input in the discussion.

I had promised to leave this one open for a while, but I think it's been long enough now. Thanks again to all who contributed.


Added missing parentheses

See this issue:
https://github.com/kayak/pypika/issues/335

Ok I see this broke a lot of stuff. Maybe some of you experts on pypika have another idea.

Can you please provide a test case for this? The change looks incorrect to me, since if this refers to a database column the parentheses would not be required, for example SELECT * FROM table WHERE 'a' in foo
In other cases, where a tuple is used, the python tuple should end up being wrapped by the class pypika.Tuple. Is there a case where that is not occurring?

In other cases, where a tuple is used, the python tuple should end up being wrapped by the class pypika.Tuple. Is there a case where that is not occurring?

In the issue, I provided an example where the pypika is not generating a valid SQL query.

Ok, I understand. In that case, instead of adding the parenthesis in the sql, you should probably set kwarg subquery=True, because this change could lead to cases where parentheses are added where they shouldn't be. In the example below the subquery argument is explicitly set to true for the container argument. You might not need to remove it from kwargs here, can try it without doing that and see if the tests pass. I think this should fix it for your case, but let me know if it doesn't.
Please also add a test to cover your use case.
    def get_sql(self, subquery=None, **kwargs):
        return "{term} {not_}IN {container}".format(
              term=self.term.get_sql(**kwargs),
              container=self.container.get_sql(subquery=True, **kwargs),
              not_='NOT ' if self._is_negated else ''
        )

Coverage decreased (-0.06%) to 97.406% when pulling 7569f7af9a898e8955d52e4ab9f1bd90c6fcaa39 on Kulu-M:Fix#335 into 2cdce151431d69a90dff13c6d6f1e07cad0187c5 on kayak:master.

@twheys I added the test case, everything is working now.

Looks good. Merged and published a new patch version 0.35.11


Images overlap unread messages bar

As you can see, the image is overlaying on top of the unread messages bar. I assume this is a z-indexing issue and is probably quite easily fixed with a z-index: 999; or the like. Funny styling go brr.

I'm certain that's an issue with Discord itself, as I've had it happen to me without the theme enabled.
(and after just checking, it seems like they fixed that as it's no longer happening on my end)


feat: improve e2e tests reliability

Signed-off-by: Jorge Turrado<EMAIL_ADDRESS>Summary of changes:

argo-rollouts e2e test used outdated manifest and that's why it fails:

Small improvements in mysql

Redis e2e tests don't use pvc any more (slow responses sometimes provisioning them produces timeout on tests)

Influxdb e2e test doesn't use pvc any more (slow responses sometimes provisioning them produces timeout on test)

Checklist

[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)
[x] Tests have been added
[x] A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
[x] A PR is opened to update the documentation on (repo) (if applicable)
[x] Changelog has been updated and is aligned with our changelog requirements

/run-e2e

/run-e2e mysql*

/run-e2e

/run-e2e

/run-e2e

/run-e2e

/run-e2e

/run-e2e

/run-e2e sql

/run-e2e

/run-e2e

/run-e2e

/run-e2e sql

/run-e2e sql

/run-e2e sql

/run-e2e sql


[Question] Why do i get kicked out from the server?

Checks

[X] I confirm that I have searched for existing issues / pull requests before reporting to avoid duplicate reporting.
[X] I confirm that I noted that if I don't follow the instructions, the issue may be closed directly.

Description
I installed the mod on my server and now every time I want to send a message through minecraft's internal chat I get kicked out from it with this message:
java.lang.nullpointerexception: cannot invoke "string.replace(java.lang.charsequence,java.lang.charsequence)" because "input" is null
Also, I don't know how to disable discord from seeing the commands that are sent from within the server. I do a lot of server work and I have to be administrative constantly changing game modes and I'm not interested in seeing this from the discord chat.

Firstly, have you read the docs about the configurable options?
Secondly, the information you provided is not enough for that exception, full log file and config file is needed.

Closing this issue due to inactive.


Uncaught RangeError: Maximum call stack size exceeded

Hey,
I get this error when trying to use Leaflet.EdgeBuffer
Uncaught RangeError: Maximum call stack size exceeded
at NewClass._getTiledPixelBounds (leaflet.edgebuffer.js:24)
at NewClass._getTiledPixelBounds (leaflet.edgebuffer.js:25)
Leaflet 1.0.1 with the following code to create a map
import '../vendor/leaflet.edgebuffer.js' [...] L.tileLayer('http://a.basemaps.cartocdn.com/light_all/{z}/{x}/{y}.png', {       subdomains: '1234',       type: 'osm',       edgeBufferTiles: 1,       attribution: 'Map tiles by CartoDB, under CC BY 3.0. Data by OpenStreetMap, under ODbL.'     }).addTo(map);
Any ideas what I am doing wrong? Thanks!

I get this exact issue when placing two Leaflet maps onto one page. It is fine with only one.

With two maps, with edgeBufferTiles set to 0 on both (to disable the default of 1, as per the demo) it fails for both maps, causing this error.
I have logged the options for both maps. Very strange! I am using TileJSON, could this be part of the issue? Works perfectly fine with a single map.
https://i.imgur.com/Zzjdq5U.png

Thanks for the report and the info. I think the issue is in the way the plugin is overriding the _getTiledPixelBounds method when its initialisation code is run for a second time; the plugin is overriding the method for a second time, which results in it calling itself recursively until the js engine runs out of stack space.
I won't be able to look in detail at this until next week. If you need to get it working urgently, a workaround might* be to use es6 module import, e.g. import * as L1 from 'leaflet'; import * as L2 from 'leaflet'; or something like that and use L1 for the first map and L2 for the second.
*Disclaimer: This is just a wild stab in the dark, I honestly don't know if that'll work or not.

This should now be fixed in v1.0.3. Please reopen this issue if you still have a problem.

I still have this issue in v1.0.3 and it also occurs with just a single map.
I'm using leaflet-edgebuffer in an Angular 2 project with TypeScript built with Angular CLI.
Nonetheless i'm just doing a simple import of leaflet and leaflet-edgebuffer
import 'leaflet'; import 'leaflet-edgebuffer';
and also a simple tileLayer creation
L.tileLayer('http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {         attribution: 'Map data © OpenStreetMap contributors',         maxZoom: 18,         edgeTileBuffers: 1     });

I've got the same issue with v1.0.3 and a single map.
I'm using a tileLayer with this Zoomify plugin.

The Zoomify plugin doesn't seem to be causing the issue. This happens even with an OSM layer.

@TolonUK Is there anything i can do to tackle down this bug?

Thanks @flumpt, I think debugging the initialisation of leaflet-edgebuffer might shed some light on this. I'm guessing there's still a situation where a call in the initialisation is unintentionally recursive. Can you investigate to find out which call this is?

@TolonUK I'll try my best and get back to you asap.

Okay, i actually don't know what exactly the problem is, but i think i solved it. I just looked at Leaflet.Editable and how they're initializing their plugin. I created a pull request with the changes and would appreciate if you check it out: #12
On another note: I don't know why, but in the example i mentioned above, i used edgeTileBuffers instead of the correct parameter edgeBufferTiles.

Thanks, @flumpt! #12 seems to fix this for me.
Though I can see a significant performance decrease with edgeBufferTiles set to low numbers like 2 on a rather beefy machine. Is that to be expected?

@jvolker Do you only experience the performance decrease with #12?

I couldn't make it work with the latest release (and I actually think neither with any other release). So only this version compared to not using the plugin at all.
Can you recommend any other version/setup that I could test with in particular? Could you please give some advice to measure the performance properly?
Thanks.

Okay, i can't really help you measuring or optimizing the performance. Maybe @TolonUK can help you out.
As i pointed out, i just looked at another leaflet plugin to fix the initialization process and did not really digged deeper.

@jvolker I'll keep an eye on any change in performance when I review #12. In the meantime, can you quantify the performance decrease and compare that with the increase in number of tiles being loaded? An edgeBufferTiles value of 2 could increase the number of tiles loaded by 25 times in the worst case, so some observable performance decrease should be expected.

Just to note that I couldn't get the current version working by using import 'leaflet-edgebuffer' or import * as L1 from 'leaflet-edgebufer' but #12 fixes the issue for me. import 'leaflet-edgebuffer' works fine now.

I tested this on a much slower machine and didn't see those performance drops. So I started chrome on my development machine with all plugins disabled and closed all tabs as well. The performance seems to be much better now.
And I should probably look into cleaning up my chrome extensions. ;)
I used stats.js to measure frame rates (it doesn't give an average value) while wildly panning the map:
at 1920 x 1006 pixels on i7-6700K @ 4.00GHz:
edgeBufferTiles at

0  >> 55 - 60 fps
5  >> 55 - 60 fps
8  >> 45 - 61 fps
10  >> 31 - 60 fps
15  >> 15 - 60 fps

at 1536 x 736 pixels on i7-4600U @ 2.10GHz:
edgeBufferTiles at

0  >> 57 - 61 fps
5  >> 55 - 60 fps
8  >> 21 - 62 fps
10  >> 13 - 60 fps
15  >> 4 - 61 fps

Please let me know if you have better ideas of how to measure this. But I think it's enough to see that there is no larger performance drop over what has to be expected.

PR #12 looks good and has been merged (815ce89). Thanks @flumpt!


Quantitative Evaluation on DTU

Hi @Totoro97 , this is great work!
I noticed that the published code doesn't contain scripts for quantitatively evaluating the reconstructed surface against the DTU ground truth. Your packaged DTU dataset doesn't contain ground-truth shapes either.
Could you please share your scripts for quantitative evaluation of DTU scenes? If you can also share the ground truth shapes (packaged with your DTU data) to use with your scripts, that would be amazing!
Thanks and Regards,

Thank you very much~


Dagre ranksep

@ferhoyos , I think if you rebase your branch on master this should reduce to just two files.  The only real changes are i the two LayoutFactory classes.  I applied a custom value to the ranksep value, and it seems to get us back to about where we were before.

Thanks @jshaughn. I have added your changes manually to the original PR.


SwipeRefresh as a child doesn't expand

Not sure if it's an issue related to #18 but having SwipeRefresh as a child of the body blocks the toolbar from expanding. You can  only expand the toolbar on a fling or when the SwipeRefresh is refreshing. View system components first expand the toolbar then activates Swiperefreshlayout pull gesture.

Hello! I have found a workaround, you can use the SwipeRefresh param swipeEnabled to fix this:
SwipeRefresh(
        swipeEnabled = **scaffoldState.toolbarState.progress == 1f**,
        state = refreshState,
        onRefresh = onRefresh,
        modifier = modifier,
)

hello, any updates on this? I am using PullToRefreshBox and as @TepesLucian mentioned, it can only collapse. once it collapses, it can't expand back because PullToRefreshBox is blocking it. any workaround?


Fixes a null pointer that eventually happend

See https://github.com/playframework/playframework/issues/6151

I don't think this is the right solution - it's too broad.  We want to not remove the handler if the channel is already inactive.  If the handler is already removed for some other reason, then we want this to fail, as @gmethvin pointed out, doing that allowed us to detect a bug in Akka streams.

I've created #16 that only removes the handler if the channel is active.

@jroper Agreed. I was going to suggest a similar solution to #16. Thanks 👍

After looking at #16 I agree, too. Way more clean.


1 != bool 1 always conditions holding

What did you do?
Perform the following formula at prometheus UI:
1 == bool 1  --------------->1
1 != bool 1 ---------------->0
but in prometheus rules, these two formula always alerting !
What did you see instead? Under which circumstances?

It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.


Fixes incorrect array_like type for URLSearchParams.entries()

I believe I followed the contributing guide, let me know if you would like any other changes.
This PR is to change the return value of the Webapi__Url.URLSearchParams.entries binding from array_like(string) to array_like((string, string))
$ node lib/js/tests/Webapi/Webapi__Url__test.js
value1 key1
value2 key2
[ [ 'key1', 'value1' ], [ 'key2', 'value2' ] ]

Fixes #190

@yawaramin would you prefer rebasing away the merge conflicts or just a merge?

@illusionalsagacity re: merge or rebase, whichever you prefer. At the end I will squash and merge anyway.

Alright that should resolve those


QueuePoller sometimes stops and ceases to work

Hi @marcanpilami
Sometimes, when DB server has been restarted, queue pooller ceases to work.
We can submit new jobs to the JQM, but, JQM doesn't want take it to execution.
All jobs stay in state 'SUBMITTED'.
In the same time, JQM web console continue working fine, after DB restart.
See logs in attachments
jqm-ctco-orke.log

Hi. Trying to qualify the "sometimes". Is it just after the db was restarted (and it may be still starting) or are you sure the db is ready to process queries when starting JQM?

Disregard previous question. This is a bug in DB Failure handling with maria DB. Will fix.


Differences in GDAL and Xarray Encoding of Zarr

The discrepancies between GDAL and Xarray encoding of Zarr have been frequently noted, making it crucial to compile a comprehensive list of these differences.
While I have not observed many contrasts in the encoding of coordinates and data, aside from the projection metadata attribute, it remains essential to document and comprehend these disparities.
This will enable us to collaborate towards a shared understanding and possibly a harmonized approach.

This is closely related to #7.

Maybe ? I have not noticed any difference between GDAL/xarray coordinates. I'm busy restoring all those Zarr from past project to confirm.
Have you seen any difference ?


Add a bigint class to dart:core

Since dart is moving to 64-bit integers, we should add a bigint class to dart:core.
Would also fix #10245.

Related: https://github.com/tc39/proposal-bigint.


microsoft.graph.directorySetting is missing a filter restrictions annotation.

Filtering should be restricted on /settings (microsoft.graph.directorySetting) as the API does not support $filter. Requests with a filter query parameter fail with a 400 Filtered searches against this resource are not supported.

This was resolved by: https://github.com/microsoftgraph/msgraph-metadata/pull/227


[Qbicc] Try NativeJDB with code compiled with qbicc

Dependent on #4 reimplementation. Can be done after removing scaffolding.

gdb2JNISignaturemethod in Translator generates correct JNI signature for Qbicc apps
All Java-related Qbicc symbolFunctions can be identified by _J prefix, for example

"_JHelloNested_HelloNested_00024Greeter_greeter__3Ljava_lang_String_2_LHelloNested_HelloNested_00024Greeter_2"

which can be useful when filtering out C classes


Configuration#9: Step#1: alpha_S=0.4, matter: q_0=1 | matterlbt: q_0=2.5: matterlbt01

run the simulation with the above config by jetscape,
transfer the final state hadron to the related directory named as config-XX-final-state-hadrons
after doing step1 on all 12 simulations go to step 2 for the configurationX

port to Excel for overleaf


🐛 [Bug report]: fix header items alignment

Descrcibe the bug?
We need to improve the alignment of these items for better UI design. The logo should be aligned with the banner text, and the search bar should be centered.
Steps to reproduce the bug?
.
Expected behavior
.
Desktop (Please provide your system information)
brave
kali
Mobile (Please provide your device information)
No response
Screenshot / Screenshare

Relevant log output
No response
Record

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[ ] I want to work on this issue

Code of Conduct

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

Hey @priyankarpal, you can assign this issue to me. I will work on it.

Hey @priyankarpal, you can assign this issue to me. I will work on it.

sure


Multiple simultaneous snapshots result in silent failure and/or corruption of at least one snapshot

When running with embedded etcd, the semaphore that prevents more than one snapshot from being executed at a time is not working. If multiple snapshots are run at the same time, one will succeed, while the other will silently fail - from the CLI's perspective. There is an error reported on the server side:
CLI:
root@k3s-server-1:~# k3s etcd-snapshot save & k3s etcd-snapshot save; sleep 5
INFO[0000] Snapshot on-demand-k3s-server-1-1718750355 saved.
[1]+  Done                       k3s etcd-snapshot save
root@k3s-server-1:~#

Service log:
INFO[0116] Saving etcd snapshot to /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355
{"level":"info","ts":"2024-06-18T22:39:15.15636Z","logger":"etcd-client","caller":"snapshot/v3_snapshot.go:65","msg":"created temporary db file","path":"/var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355.part"}
{"level":"info","ts":"2024-06-18T22:39:15.158226Z","logger":"etcd-client.client","caller":"v3@v3.5.9-k3s1/maintenance.go:212","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":"2024-06-18T22:39:15.158266Z","logger":"etcd-client","caller":"snapshot/v3_snapshot.go:73","msg":"fetching snapshot","endpoint":"https://<IP_ADDRESS>:2379"}
{"level":"info","ts":"2024-06-18T22:39:15.158438Z","caller":"v3rpc/maintenance.go:126","msg":"sending database snapshot to client","total-bytes":2936832,"size":"2.9 MB"}
INFO[0116] Saving etcd snapshot to /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355
{"level":"info","ts":"2024-06-18T22:39:15.172618Z","logger":"etcd-client","caller":"snapshot/v3_snapshot.go:65","msg":"created temporary db file","path":"/var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355.part"}
{"level":"info","ts":"2024-06-18T22:39:15.173781Z","caller":"v3rpc/maintenance.go:166","msg":"sending database sha256 checksum to client","total-bytes":2936832,"checksum-size":32}
{"level":"info","ts":"2024-06-18T22:39:15.173823Z","caller":"v3rpc/maintenance.go:175","msg":"successfully sent database snapshot to client","total-bytes":2936832,"size":"2.9 MB","took":"now"}
{"level":"info","ts":"2024-06-18T22:39:15.173926Z","logger":"etcd-client.client","caller":"v3@v3.5.9-k3s1/maintenance.go:220","msg":"completed snapshot read; closing"}
{"level":"info","ts":"2024-06-18T22:39:15.174275Z","logger":"etcd-client.client","caller":"v3@v3.5.9-k3s1/maintenance.go:212","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":"2024-06-18T22:39:15.174303Z","logger":"etcd-client","caller":"snapshot/v3_snapshot.go:73","msg":"fetching snapshot","endpoint":"https://<IP_ADDRESS>:2379"}
{"level":"info","ts":"2024-06-18T22:39:15.174516Z","caller":"v3rpc/maintenance.go:126","msg":"sending database snapshot to client","total-bytes":2936832,"size":"2.9 MB"}
{"level":"info","ts":"2024-06-18T22:39:15.177892Z","logger":"etcd-client","caller":"snapshot/v3_snapshot.go:88","msg":"fetched snapshot","endpoint":"https://<IP_ADDRESS>:2379","size":"2.9 MB","took":"now"}
{"level":"info","ts":"2024-06-18T22:39:15.177961Z","logger":"etcd-client","caller":"snapshot/v3_snapshot.go:97","msg":"saved","path":"/var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355"}
INFO[0116] Reconciling ETCDSnapshotFile resources
I0618 22:39:15.183024      55 event.go:307] "Event occurred" object="local-on-demand-k3s-server-1-1718750355-f4beb3" fieldPath="" kind="ETCDSnapshotFile" apiVersion="k3s.cattle.io/v1" type="Normal" reason="ETCDSnapshotCreated" message="Snapshot on-demand-k3s-server-1-1718750355 saved on k3s-server-1"
{"level":"info","ts":"2024-06-18T22:39:15.192288Z","caller":"v3rpc/maintenance.go:166","msg":"sending database sha256 checksum to client","total-bytes":2936832,"checksum-size":32}
{"level":"info","ts":"2024-06-18T22:39:15.192392Z","caller":"v3rpc/maintenance.go:175","msg":"successfully sent database snapshot to client","total-bytes":2936832,"size":"2.9 MB","took":"now"}
{"level":"info","ts":"2024-06-18T22:39:15.192535Z","logger":"etcd-client.client","caller":"v3@v3.5.9-k3s1/maintenance.go:220","msg":"completed snapshot read; closing"}
{"level":"info","ts":"2024-06-18T22:39:15.199162Z","logger":"etcd-client","caller":"snapshot/v3_snapshot.go:88","msg":"fetched snapshot","endpoint":"https://<IP_ADDRESS>:2379","size":"2.9 MB","took":"now"}
ERRO[0116] Failed to take etcd snapshot: could not rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355.part to /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355 (rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355.part /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355: no such file or directory)
INFO[0116] Reconciliation of ETCDSnapshotFile resources complete
INFO[0116] Reconciling ETCDSnapshotFile resources
I0618 22:39:15.214006      55 event.go:307] "Event occurred" object="local-on-demand-k3s-server-1-1718750355-dcf0a5" fieldPath="" kind="ETCDSnapshotFile" apiVersion="k3s.cattle.io/v1" type="Warning" reason="ETCDSnapshotFailed" message="Failed to save snapshot on-demand-k3s-server-1-1718750355 on k3s-server-1: could not rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355.part to /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355 (rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355.part /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355: no such file or directory)"
INFO[0116] Reconciliation of ETCDSnapshotFile resources complete

ERRO[0116] Failed to take etcd snapshot: could not rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355.part to /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355 (rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355.part /var/lib/rancher/k3s/server/db/snapshots/on-demand-k3s-server-1-1718750355: no such file or directory)
The two snapshots use the same timestamp in the file name, and race to create and the same snapshot and temp files.

This is the root cause of https://github.com/rancher/rancher/issues/45770 - I'm not sure why multiple snapshots are being taken at the same time, but it shouldn't blow up like this.
This may also be the root cause of other errors as discussed in slack here and here, where snapshot restore is exiting with an odd error about the checksum. If the save path races differently, I could see one operation renaming the file out from underneath the other while the file was still being written, leading to the snapshot getting corrupted - which seems to be what the restore is complaining about. We've not been able to get an actual copy of a snapshot that fails to restore with this error, to see if it is actually corrupted or not.
starting kubernetes: preparing server: start managed database: expected sha256 [255 75 90 78 90 111 68 23 86 217 93 179 107 108 119 123 137 66 118 159 13 222 254 55 165 179 240 118 42 106 52 227], got [78 59 101 77 122 31 226 10 108 170 71 20 56 213 159 175 121 211 215 158 194 45 204 220 42 9 244 230 144 201 194 32]
https://github.com/etcd-io/etcd/blob/v3.5.11/etcdutl/snapshot/v3_snapshot.go#L450
https://github.com/etcd-io/etcd/blob/v3.5.11/etcdutl/snapshot/v3_snapshot.go#L308

The full stack on the restore error is:
go.etcd.io/etcd/etcdutl/v3/snapshot.(*v3Manager).Restore
	/go/pkg/mod/github.com/k3s-io/etcd/etcdutl/v3@v3.5.9-k3s1/snapshot/v3_snapshot.go:254
github.com/k3s-io/k3s/pkg/etcd.(*ETCD).Restore
	/go/pkg/mod/github.com/k3s-io/k3s@v1.28.10-0.20240517003114-1c33ee685998/pkg/etcd/etcd.go:1486
github.com/k3s-io/k3s/pkg/etcd.(*ETCD).Reset
	/go/pkg/mod/github.com/k3s-io/k3s@v1.28.10-0.20240517003114-1c33ee685998/pkg/etcd/etcd.go:410
github.com/k3s-io/k3s/pkg/cluster.(*Cluster).start
	/go/pkg/mod/github.com/k3s-io/k3s@v1.28.10-0.20240517003114-1c33ee685998/pkg/cluster/managed.go:71
github.com/k3s-io/k3s/pkg/cluster.(*Cluster).Start
	/go/pkg/mod/github.com/k3s-io/k3s@v1.28.10-0.20240517003114-1c33ee685998/pkg/cluster/cluster.go:91
github.com/k3s-io/k3s/pkg/daemons/control.prepare
	/go/pkg/mod/github.com/k3s-io/k3s@v1.28.10-0.20240517003114-1c33ee685998/pkg/daemons/control/server.go:261
github.com/k3s-io/k3s/pkg/daemons/control.Server
	/go/pkg/mod/github.com/k3s-io/k3s@v1.28.10-0.20240517003114-1c33ee685998/pkg/daemons/control/server.go:35
github.com/k3s-io/k3s/pkg/server.StartServer
	/go/pkg/mod/github.com/k3s-io/k3s@v1.28.10-0.20240517003114-1c33ee685998/pkg/server/server.go:56
github.com/k3s-io/k3s/pkg/cli/server.run
	/go/pkg/mod/github.com/k3s-io/k3s@v1.28.10-0.20240517003114-1c33ee685998/pkg/cli/server/server.go:498
github.com/k3s-io/k3s/pkg/cli/server.RunWithControllers
	/go/pkg/mod/github.com/k3s-io/k3s@v1.28.10-0.20240517003114-1c33ee685998/pkg/cli/server/server.go:48
github.com/rancher/rke2/pkg/rke2.Server
	/source/pkg/rke2/rke2.go:123
github.com/rancher/rke2/pkg/cli/cmds.ServerRun
	/source/pkg/cli/cmds/server.go:168
github.com/urfave/cli.HandleAction
	/go/pkg/mod/github.com/urfave/cli@v1.22.14/app.go:524
github.com/urfave/cli.Command.Run
	/go/pkg/mod/github.com/urfave/cli@v1.22.14/command.go:175
github.com/urfave/cli.(*App).Run
	/go/pkg/mod/github.com/urfave/cli@v1.22.14/app.go:277
main.main
	/source/main.go:23
runtime.main
	/usr/local/go/src/runtime/proc.go:267

Validated on Version:
-$  k3s version v1.30.2-rc3+k3s1 (aa4794b3)

Environment Details
Infrastructure
Cloud EC2 instance
Node(s) CPU architecture, OS, and Version:
ubuntu
AMD
Cluster Configuration:
-3 node server
-1 node agents
Steps to validate the fix

Install k3s etcd embedded
Take etcd snapshot more than once at the same time
validate error response

Reproduction Issue:

 k3s -v
k3s version v1.27.15-rc1+k3s1 (102e42a5)
go version go1.21.11

k3s etcd-snapshot save & k3s etcd-snapshot save; sleep 5

WARN[0000] Unknown flag --write-kubeconfig-mode found in config.yaml, skipping
WARN[0000] Unknown flag --tls-san found in config.yaml, skipping
WARN[0000] Unknown flag --cluster-init found in config.yaml, skipping
WARN[0000] Unknown flag --protect-kernel-defaults found in config.yaml, skipping
WARN[0000] Unknown flag --selinux found in config.yaml, skipping
WARN[0000] Unknown flag --node-external-ip found in config.yaml, skipping
WARN[0000] Unknown flag --node-ip found in config.yaml, skipping
WARN[0000] Unknown flag --secrets-encryption found in config.yaml, skipping
WARN[0000] Unknown flag --kube-apiserver-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-apiserver-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-apiserver-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-apiserver-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-apiserver-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-apiserver-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-apiserver-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-apiserver-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-apiserver-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-controller-manager-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kube-controller-manager-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kubelet-arg found in config.yaml, skipping
WARN[0000] Unknown flag --kubelet-arg found in config.yaml, skipping
WARN[0000] Unknown flag --node-label found in config.yaml, skipping
WARN[0000] Unknown flag --node-label found in config.yaml, skipping
WARN[0000] Unknown flag --node-label found in config.yaml, skipping
FATA[0000] see server log for details: Internal error occurred: etcd-snapshot error ID 20267
INFO[0000] Snapshot on-demand-ip-172-31-4-174.us-east-2.compute.internal-1719002637 saved.
[1]+  Done                    k3s etcd-snapshot save

$ journalctl -xeu k3s.service | grep "snapshot"

Jun 21 20:23:09 ip-172-31-1-64 k3s[13884]: time="2024-06-21T20:23:09Z" level=error msg="Failed to take etcd snapshot: could not rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390.part to /var/lib/rancher/k3s/server/db/snapshots/on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390 (rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390.part /var/lib/rancher/k3s/server/db/snapshots/on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390: no such file or directory)"
Jun 21 20:23:09 ip-172-31-1-64 k3s[13884]: I0621 20:23:09.912916   13884 event.go:307] "Event occurred" object="local-on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390-c93945" fieldPath="" kind="ETCDSnapshotFile" apiVersion="k3s.cattle.io/v1" type="Warning" reason="ETCDSnapshotFailed" message="Failed to save snapshot on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390 on ip-172-31-1-64.us-east-2.compute.internal: could not rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390.part to /var/lib/rancher/k3s/server/db/snapshots/on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390 (rename /var/lib/rancher/k3s/server/db/snapshots/on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390.part /var/lib/rancher/k3s/server/db/snapshots/on-demand-ip-172-31-1-64.us-east-2.compute.internal-1719001390: no such file or directory)"

Validation Results:

k3s etcd-snapshot save & k3s etcd-snapshot save; sleep 5
FATA[0000] see server log for details: Internal error occurred: etcd-snapshot error ID 14571
INFO[0000] Snapshot on-demand-ip .us-east-2.compute.internal-1719002785 saved.
[1]+  Done                    k3s etcd-snapshot save

$ journalctl -xeu k3s.service | grep "snapshot"

 Jun 21 20:20:01 ip-172-31-7-229 k3s[13083]: time="2024-06-21T20:20:01Z" level=info msg="Starting managed etcd snapshot ConfigMap controller"
Jun 21 20:20:02 ip-172-31-7-229 k3s[13083]: time="2024-06-21T20:20:02Z" level=info msg="Reconciling snapshot ConfigMap data"
Jun 21 20:22:52 ip-172-31-7-229 k3s[13083]: time="2024-06-21T20:22:52Z" level=info msg="Saving etcd snapshot to /var/lib/rancher/k3s/server/db/snapshots/on-demand-ip- us-east-2.compute.internal-1719001372"
Jun 21 20:22:52 ip-172-31-7-229 k3s[13083]: {"level":"info","ts":"2024-06-21T20:22:52.098617Z","logger":"etcd-client","caller":"snapshot/v3_snapshot.go:65","msg":"created temporary db file","path":"/var/lib/rancher/k3s/server/db/snapshots/on-demand-ip-1 -229.us-east-2.compute.internal-1719001372.part"}
Jun 21 20:22:52 ip-  k3s[13083]: {"level":"info","ts":"2024-06-21T20:22:52.101602Z","logger":"etcd-client.client","caller":"v3@v3.5.13-k3s1/maintenance.go:212","msg":"opened snapshot stream; downloading"}
Jun 21 20:22:52 ip-  k3s[13083]: {"level":"info","ts":"2024-06-21T20:22:52.101781Z","logger":"etcd-client","caller":"snapshot/v3_snapshot.go:73","msg":"fetching snapshot","endpoint":"https://<IP_ADDRESS>:2379"}
Jun 21 20:22:52 ip- k3s[13083]: {"level":"info","ts":"2024-06-21T20:22:52.111894Z","caller":"v3rpc/maintenance.go:126","msg":"sending database snapshot to client","total-bytes":5713920,"size":"5.7 MB"}
Jun 21 20:22:52 ip-  k3s[13083]: time="2024-06-21T20:22:52Z" level=error msg="etcd-snapshot error ID 11914: snapshot save already in progress"
Jun 21 20:22:52 ip- k3s[13083]: time="2024-06-21T20:22:52Z" level=error msg="Sending HTTP 500 response to <IP_ADDRESS>:50686: etcd-snapshot error ID 11914"
Jun 21 20:22:52 ip-  k3s[13083]: {"level":"info","ts":"2024-06-21T20:22:52.160236Z","caller":"v3rpc/maintenance.go:175","msg":"successfully sent database snapshot to client","total-bytes":5713920,"size":"5.7 MB","took":"now"}


Title: want to add a random joke app

Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like.
Hey project admin I'm a GSSOC  participant and I want to add a random joke web app created with HTML CSS and JS to the current repository. the jokes are coming through third party API so it is a good practice for beginners how to use API and handle asynchronous tasks.
please go through my issue and assign me this issue to work on.
Describe alternatives you've considered.
No, I have not described any alternative.
Add any other context or screenshots about the feature request here.

/assign


Merge high speed camera windows

Can we merge the two camera views into one visualizer window? Just to reduce the clutter of windows open

I guess I can take care of this.
I was waiting for this to implement real-time lick visualizer to be combined into the same window.
in case I'm incapable, preemptively circling @ZhixiaoSu


add TestConfChangeRemoveLeader3B

Added a simple test to check if the request to remove the leader in a membership change is handled correctly, as the author said in the paper, especially when there are only two members, interesting things may happen when removing the leader

@ZYFZYF Removing peer in a two node cluster is a very interesting problem when using an apply after commit conf change strategy. What I am interesting is that, can you raft implementtation still pass this test(or other 3B test cases) when running this these cases repeatly for 512 times or more.

I ran this test 512 times and found no problems. As for other tests, it takes a long time to run 512 times(~100+h). I am still working on it(have found some bugs and fixed)


Port exposed not working

PWD seems to awesome platform for docker practice.
I am trying to access port exposed using nginx docker
docker run  -d -p 8080:80 nginx
Below is running container

But getting below error

Sometimes get

Hope this will be soon resolved and thanks in advance.

I can confirm, it was reported on the Docker forum as well
https://forums.docker.com/t/stuck-on-getting-started-part-4/140350
so I checked and it didn't work for me either.

hi, this is fixed now!

hi, this is fixed now!

Hey Marcosnils, you are superman.
Thanks alot :)


Retry if the http return is incorrect.

Sometime, the bitindex will return 502.
Add a retry function to make sure the code will not stop if this happens.
e.g:  Expecting value: line 1 column 1 (char 0), Retrying in 1 seconds...

Hmm, this is a bit different. Usually in bit/bitcash/etc, we've just had different APIs to try. Could we just add another API?
If we're getting that json parsing error, there's probably a spot where we are calling r.json() without r.raise_for_status() or checking the status code manually.
I like the idea, but this is a fairly notable change so I'm a little hesitant. If we do this here, I think maybe bit and bitcash should get it as well. I like keeping the code bases sort of similar as they have a ton in common.

Sorry, What you mean "different API"?
Even r.json() raise a json parson error, in general, it is caused by a 502 code.
It supposes to be a transition error and should be able to resolve by the retry (catch Exception) here.
What is bit and bitcash? Is that for BSV?

So we can try hitting the same API over and over, or we can have different APIs that we try in series. You can see this in bitcash and bit.
https://github.com/ofek/bit
https://github.com/sporestack/bitcash
(bitsv's predecessors)
We shouldn't even try to parse json if the API returns non 2XX. The exceptions being caught are ConnectionException and something else. That will raise an error that won't get caught and we'll stop right there. It's also kind of ugly in my opinion.

If we retry with different APIs, one possible risk is different APIs are not in the same status, such as the UXTO. Then the tx been built later will be illegal in one API but legal in another. This will make the debugging very difficult and confusing, which I believe we should avoid.
Consider the real business usage in the future, I think the client will prefer to stop syncing the data instead of writing some wrong data.
Do you mean you wish to add something like:
if r.status_code != 200:
raise ConnectionError
to retry before parse?
I have no strong preference here, per my understanding, both ConnectionError and ParseError (as a consequence) could be covered by the current code.
The only reason I did not add those condition check is to avoid those duplicated code.
Of course, If you like I could add those 200 condition check to each function.

If we retry with different APIs, one possible risk is different APIs are not in the same status, such as the UXTO. Then the tx been built later will be illegal in one API but legal in another. This will make the debugging very difficult and confusing, which I believe we should avoid.

Yes, agreed. This is already the case. Being able to easily toggle APIs is probably the best option here. I'm saying that this is fairly tried and tested in bit and bitcash. It's not perfect in those, but this really should only matter for 0-conf transactions. Which are important, for sure, but if you need a lot of consistency you should really be running a local daemon or forcing use of one API.
If we could configure API ordering and retry behaviors, I think that would be ideal. Of course some day being able to speak the Bitcoin RPC protocol would be ideal.
About the json parsing, here's a change for bit recently that's probably a little better than what I was doing before: https://github.com/ofek/bit/pull/68

I have no strong preference here, per my understanding, both ConnectionError and ParseError (as a consequence) could be covered by the current code.

It's not, unless I'm missing something.
https://github.com/AustEcon/bitsv/blob/master/bitsv/network/services.py#L317
I mean, with the status code checking we should be okay. But if you are seeing json parsing errors, it almost certainly means there's part of the code where we are not doing that. Or where one of our APIs is being evil and throwing an error without a 5XX. I just don't like that json error, the user should never see that as it's confusing and doesn't make it obvious what the real problem is.
@AustEcon, do you have any thoughts on this?

I can't look at this properly right now. Almost at work for a busy day.
There are a few things to sort out. I do want to work towards having the NetworkAPI class working well (what PrivateKey.send() etc uses) and handling retrys and redundancy/ alternative apis intelligently and in a way that ideally is compatible with bit and bitcash syntax as much as possible as @Teran-mckinney says...
So my initial thoughts (without any feedback) were to make NetworkAPI do retrys then if fail switch EVERYTHING over to a different api to stop sync issues with different utxos...

I can't look at this properly right now. Almost at work for a busy day.
There are a few things to sort out. I do want to work towards having the NetworkAPI class working well (what PrivateKey.send() etc uses) and handling retrys and redundancy/ alternative apis intelligently and in a way that ideally is compatible with bit and bitcash syntax as much as possible as @Teran-mckinney says...
So my initial thoughts (without any feedback) were to make NetworkAPI do retrys then if fail switch EVERYTHING over to a different api to stop sync issues with different utxos...

Good idea to use r.raise_for_status(), it is clear.  I am also fine to move the logic into NetworkAPI .
I just have some concern about switching the backend.
Consider we are tracking the unspent in the memory, and writing the data to the block, which means the library is not in stateless, If we switch to another backend implicitly, It might be risky to maintain the consistent status?
My understanding is the NetworkAPI solution (GET_BALANCE_MAIN=[]) might be a good idea to switch backend,  if the library is a read-only lib, just show some data to the client. But now the API has included the broadcast operation, I am not sure is that a right choice for us to do this now.
I don't have much background about the existing design.  Appreciate if you guys could share more insight about the design here.

I'm sorry, I still need to look this over.
Looks like we also have this: https://github.com/AustEcon/bitsv/pull/20
Heading to bed for now.

Yes. We have been discussing with the hackathon on that we want to wire this up. @joshua-s has to sleep now. But I am very happy with what he's done from my POV. No paths will be changed but now well organised into modules.
As more APIs get added will keep things tidy this way. I'm testing now.

Or should we do the same thing but only to the NetworkAPI section (where all of the logic re: retrying and toggling over to alternative APIs can be handled in one place?)

I definitely prefer this route, having retry and service switching more central.
@carpemer, your points about keeping API use consistent do make sense. But I think most APIs will broadcast a "valid" TX and not complain about unspents. And this would only happen if the default was down.
I still think this can never be "production quality" without a native Bitcoin daemon. Which neither bit, bitcash, nor bitsv supports...  yet. But it can work fairly well, all things considered.

@teran-mckinney, @carpenter and I had a chat in slack earlier and basically came to same conclusion.
After the recent refactoring it reinforces going this approach (with all of the redundancy handling stuff in network.py). So we can possibly expect a PR from carpenter in a couple of weeks when he gets some time to work on it.

I'll close this PR for now seeing as though a lot has changed since then and we know what the reason was for the 502 error.


Question on closing of registration process for testing stations

Your Question
I have a question regarding the closing of the registration process for testing stations, which was announced via https://github.com/corona-warn-app/cwa-registrierung/commit/db7ec076dc37175c7805b75c5b335cd04f0ee2f0.
Does this only affect registration of RAT testing stations or also PCR testing stations?

Internal Tracking ID: EXPOSUREAPP-13062

Hi @Ein-Tim, your question was forwarded.

@thomasaugsten I'm sure you know that. Maybe you could quickly clarify?

@dsarkar Is there an update on this issue available?

@Ein-Tim I will ask that question again internally.

The question itself, which I asked in the OP of this issue, is still valid, but, as the CWA project went into ramp-down mode, I'm not interested in an answer to this question anymore. I'm therefore closing this issue now.


refactor(p-dict-list): delete PDictList and replace it with PTag

To Reviewers

[ ] Skipping review is not a problem (style, chore ONLY)
[x] Not that difficult

Type of Change

[ ] New feature
[ ] Bug fixes
[ ] Feature improvement

[ ] These changes require a usage change

[x] Others (performance improvement, refactoring, CI/CD, etc.)

Checklist

[x] Updated Storybook documents
[x] Tested with console

Description

The utilization of PDictList was low, so delete it and replaced with PTag. (PDictList의 활용도가 낮아, 이를 삭제하고 PTag로 대체함)
Tested on Console and Storybook.

:tada: This PR is included in version 1.1.0-beta.439 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


update to work with neuron 1.9.7

Neuron 1.9.7 changed the way the query results look. I've updated the different files. I'm not sure if I got all of it.
Please have a look @oberblastmeister 🚀

Cheers 👍

Can we merge this @oberblastmeister ?

@frandsoh probably worth putting whitespace/formatting changes into another PR? Otherwise hard to see the actual changes to logic.


Tests should clean up their temporary directories

Currently, running the unit tests leaves temporary directories, such as the following, around:
image_client_test972400759
image-relocation-test741069180
system-download-test541304860

These should be deleted, regardless of whether the tests pass or fail.

No longer required since #949.


Make npm scripts cross-platform

Make npm scripts cross-platform
Several scripts that use runtime environment variable initialization (VAR=value cmd arg1 arg2) would not work on Windows, and we've learnt that a number of our contributors are not necessarily Macintosh and Linux users but Windows users. Hence, this update is supposed to ease running the npm scripts for them.
Scripts Affected

"dev:backend": "PORT=5000 nodemon -w ./server server/server.js"
"lint": "DEBUG=eslint:cli-engine eslint --fix ."
"lint:check": "DEBUG=eslint:cli-engine eslint ."

Note
cross-env is worth checking out. I've used it before for this particular cross-platform fix and it is pretty convenient and efficient.

curious - why is this necessary inside of a codespace? do you also want to support outside of a codespace?

we're currently working on making the codespaces experience more seamless and with a higher core count which should hopefully make it so this issue doesn't feel needed so we're going to punt on this one for now.

curious - why is this necessary inside of a codespace? do you also want to support outside of a codespace?

Hey Debbie! Apparently so, that was part of the discussion in the previous few cohorts. Codespaces aren't completely reliable and much of the big stories take a local development setup to develop, so it is only on us to make it easier to set up fresh development environments locally as well.


pull request for e2e test at 01/31/2017 01:26:13

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.