Implement ObservableUWP that is mostly the same as ObservableWWW

Because UnityWebRequest adds support for other HTTP methods,
ObservableUWP has methods for PUT, DELETE and HEAD.
The conditional defines were taken out because UnityWebRequest is a new addition so it isn't supported on older versions of Unity. I'm not sure if it should be condionally taken completely out on older versions.

This is a great PR.. for me to get it working, I had to wrap the class in the UniRx namespace

You're missing the www.Send() lines in a few places.

I'd love to see that PR integrated as well! One note thought, System.Net.HttpStatusCode as available in Unity is missing a few broadly used HTTP status codes defined by recent HTTP extensions, for instance it lacks 422 Unprocessable Entity, so you may want to use a custom enumeration rather than the System one to be sure that those standard codes are being parsed and can be interpreted.

This is a correct ObservableUWP:
https://gist.github.com/doctorpangloss/b5677d2b925b5f07a8525760af25d818

+1 for this PR too


MaterialDesign automatical remove character underscore at label and listview

Description
I writting a little programm for myself and use a database for it.
If i save a entry and it's already exists, i will give them automatically a new name,
Using the currentname and adding "_1" to it.
then i show all items at a ListView.
Therefore i add ListviewItems during the runtime to my ListView.
And here is the bug: i read the correct name from the database (checked it many times),
but it displays not the correct name.
Read the name "water_1" correctly from the Database, but what it shows is "water1".
Tryed also to adding a label instead of a listviewitem.
Doesn't solve the issue.
Strange is, that only these underscores (is this the name of these character: _ ?) is removed
After trying many different things, i used made a very easy testproject (only nessesary code for reading from database and showing in a listview).
And now it shows my entries correctly.
Trying to manage, what is at my project other and remove all stylings.
Now it show my entries correctly.
Adding one style after the other and compiling and testing, it was easy to say,
that the MaterialDesign and it's styles are the cause of the problem.
Added some pictures to show the behavior
Repro steps
Please provide the steps required to reproduce the problem

Add MaterialDesign 3.0.1 to your project and use the themes

use one of the themes (tryed it with many different)

get data from behind and fill a ListView with ListviewItems, where some of the content has a _ in the namen - first of the _ will be removed.

Expected behavior
Show the name correctly
Actual behavior
Remove the first of the _
For example:
water_1 is shown as water1 in the listview
water_1_1 is shown as water1_1 in the listview
Known workarounds
don't knowing any workarounds
pictures for the issue:
using materialdesign themes:

that is my background datatable:

without using materialdesign themes:

Is this related to Paket?
schorsch2489<EMAIL_ADDRESS>schrieb am Sa., 22. Feb. 2020,
03:02:

Description
I writting a little programm for myself and use a database for it.
If i save a entry and it's already exists, i will give them automatically
a new name,
Using the currentname and adding "_1" to it.
then i show all items at a ListView.
Therefore i add ListviewItems during the runtime to my ListView.
And here is the bug: i read the correct name from the database (checked it
many times),
but it displays not the correct name.
Read the name "water_1" correctly from the Database, but what it shows is
"water1".
Tryed also to adding a label instead of a listviewitem.
Doesn't solve the issue.
Strange is, that only these underscores (is this the name of these
character: _ ?) is removed
After trying many different things, i used made a very easy testproject
(only nessesary code for reading from database and showing in a listview).
And now it shows my entries correctly.
Trying to manage, what is at my project other and remove all stylings.
Now it show my entries correctly.
Adding one style after the other and compiling and testing, it was easy to
say,
that the MaterialDesign and it's styles are the cause of the problem.
Added some pictures to show the behavior
Repro steps
Please provide the steps required to reproduce the problem

Add MaterialDesign 3.0.1 to your project and use the themes
2.
use one of the themes (tryed it with many different)
3.
get data from behind and fill a ListView with ListviewItems, where
some of the content has a _ in the namen - first of the _ will be removed.
Expected behavior
Show the name correctly
Actual behavior
Remove the first of the _
For example:
water_1 is shown as water1 in the listview
water_1_1 is shown as water1_1 in the listview
Known workarounds
don't knowing any workarounds
[image: 1 show listview with materialdesign]
https://user-images.githubusercontent.com/61337326/75084330-c8d57180-551f-11ea-9e84-71b074b5b303.png
[image: 2 background data table]
https://user-images.githubusercontent.com/61337326/75084331-c96e0800-551f-11ea-8e66-3ee4387151f7.png
[image: 3 correct view without materialdesign]
https://user-images.githubusercontent.com/61337326/75084333-ca069e80-551f-11ea-81d3-0194cedfeca3.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3800?email_source=notifications&email_token=AAAOANDX4N7XUL5L2ZIJJY3RECBUJA5CNFSM4KZNMQU2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IPOI6MQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAOANAMNEZYVDAJXZZHK3DRECBUJANCNFSM4KZNMQUQ
.

i'm not sure, what u meen, maybe you my version numbers?
Installed was:
MaterialDesignColors 1.2.2
MaterialDesignThemes 3.0.1
Are these the right informations?

I am asking since this project is unrelated to materialdesign. Should you
report it over there in their issue tracker?
schorsch2489<EMAIL_ADDRESS>schrieb am Sa., 22. Feb. 2020,
08:48:

i'm not sure, what u meen, maybe you my version numbers?
Installed was:
MaterialDesignColors 1.2.2
MaterialDesignThemes 3.0.1
Are these the right informations?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3800?email_source=notifications&email_token=AAAOANGLVMBX4FHEOC4B4OTREDKGVA5CNFSM4KZNMQU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMUZZWY#issuecomment-589929691,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAOANA7LFQJMJ2LOJUYZ23REDKGVANCNFSM4KZNMQUQ
.

oh sorry, i thought, i did it right.
is my first bug, which i want report.
used the website "http://materialdesigninxaml.net/"  and thinked it bring me to the right adress and location.
Now i don't know, what i had to do to get the bug to the right people.
Where did i find their issue tracker?

I assume
https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit
Am Sa., 22. Feb. 2020 um 09:54 Uhr schrieb schorsch2489 <
<EMAIL_ADDRESS>
oh sorry, i thought, i did it right.
is my first bug, which i want report.
used the website "http://materialdesigninxaml.net/" and thinked it bring
me to the right adress and location.
Now i don't know, what i had to do to get the bug to the right people.
Where did i find their issue tracker?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3800?email_source=notifications&email_token=AAAOANB53WS6BRHCMC3CQ7LREDR4XA5CNFSM4KZNMQU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMU25IQ#issuecomment-589934242,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAOANDX2JFBKSMLIX6TLXLREDR4XANCNFSM4KZNMQUQ
.


need compiled binaries for the user, and sometimes a new parser will need
updated scm queries.

Tree sitter's AST allows other functionality.
nvim-treesitter-textobjects
allows for key combinations like daf (delete around function) and
motions like ic (inside class). I don't believe these are impossible
with Textmate grammars, but I can't find any precedent of this either.
Isn't this a matter of naming rules properly?  Just like we currently
have the convention that "fooComment" is used for comments in the "foo"
filetype.

I'm not sure. If you have one function nested inside another, can you determine
where the inner one beings and ends?

Sounds like a lot of compromises to make the parser work fast.

IMHO, tree-sitter compromises on everything except speed and being able to
produce good results (assuming a good enough parser).

Just looking at the c/highlights.scm file, it seems that it's not just
translation, this also defines tokens such as "attribute".  Does
this mean there is duplication between files?

There's a few different ones. I'm not good at explaining what they translate
because I'm missing terminology with some internals here. Here are all the
queries for C:
https://github.com/nvim-treesitter/nvim-treesitter/tree/f499a711fa5c573b5ba0af09a3c9955a6c14b062/queries/c

Given that the above mentioned queries are only guaranteed to work
with the same version of the parser for which they were written, the
version of the query and the parsers needs to be kept in sync (neovim
addresses this by downloading a pinned version of the parser).
And how does an end user find out what highlight group to use for an
item?  Searching the files, what you can do with the current Vim syntax
plugins and a bit of guessing, seems too complicated.

highlights.scm translate tree sitter nodes into capture groups. These capture
groups map directly to well-known highlight groups.
See the section titled "The following captures are linked by default to
standard group-names" in the docs:
https://neovim.io/doc/user/treesitter.html#treesitter-highlight

I do think having support for multiple syntax sources is the best, because a
slow one can enhance the results of a fast one. There's also semantic
highlighting on top of syntax highlighting. For example, an LSP can point out
unused or deprecated tokens which can be highlighted as greyed-out and
strikethrough respectively.
On a separate note, some of the examples in this thread has proved that Vim's
current APIs are sufficient to implement any kind of highlighter as a plugin; I
don't think there's anything that needs to be done right now (aside from
writing plugins and continuing refining on them).

[...]

Tree sitter's AST allows other functionality.
nvim-treesitter-textobjects
allows for key combinations like daf (delete around function) and
motions like ic (inside class). I don't believe these are impossible
with Textmate grammars, but I can't find any precedent of this either.
Isn't this a matter of naming rules properly?  Just like we currently
have the convention that "fooComment" is used for comments in the "foo"
filetype.

I'm not sure. If you have one function nested inside another, can you
determine where the inner one beings and ends?

This depends on how the result of parsing can be accessed.  Currently we
only have synstack(), which is insufficient.  It requires returning more
information about each syntax item.  At least the start position.
Getting the end position would be nice, but it can be expensive if the
file was only partly parsed (to optimize performance).  E.g. if the
window shows the start of a long file, which contains a class that takes
up the whole file, the text could be shown by only parsing a limited
number of lines (window height), while parsing until the end of the
class can be a hundred times slower.  We probably need some option to
tell Vim whether speed is more important than complete information, or
the other way around.   I believe treesitter implementations always
parse the whole file anyway.

Just looking at the c/highlights.scm file, it seems that it's not just
translation, this also defines tokens such as "attribute".  Does
this mean there is duplication between files?

There's a few different ones. I'm not good at explaining what they translate
because I'm missing terminology with some internals here. Here are all the
queries for C:
https://github.com/nvim-treesitter/nvim-treesitter/tree/f499a711fa5c573b5ba0af09a3c9955a6c14b062/queries/c

That's what I was referring to, the "highlights.scm" file in that
directory.

Given that the above mentioned queries are only guaranteed to work
with the same version of the parser for which they were written, the
version of the query and the parsers needs to be kept in sync (neovim
addresses this by downloading a pinned version of the parser).
And how does an end user find out what highlight group to use for an
item?  Searching the files, what you can do with the current Vim syntax
plugins and a bit of guessing, seems too complicated.

highlights.scm translate tree sitter nodes into capture groups.
These capture groups map directly to well-known highlight groups.

However, besides "tree sitter nodes" there are literal keywords here.
It looks like the syntax file has been split in two parts that carefully
need to be kept in sync.  And errors will be quite hard to track down.
Would there be an error if the highlights.scm file uses a name that is
not a treesitter node?

I do think having support for multiple syntax sources is the best, because a
slow one can enhance the results of a fast one. There's also semantic
highlighting on top of syntax highlighting. For example, an LSP can
point out unused or deprecated tokens which can be highlighted as
greyed-out and strikethrough respectively.

I expect LSP to provide much more information, we don't intend to go
that way with syntax highlighting.  E.g., a variable name could be
highlighted if recognized, but there is no reference to where it is
declared.  LSP does provide that information.

On a separate note, some of the examples in this thread has proved
that Vim's current APIs are sufficient to implement any kind of
highlighter as a plugin; I don't think there's anything that needs to
be done right now (aside from writing plugins and continuing refining
on them).

The two main goals I see are:

Add grammers that are used by other editors, to avoid having to
maintain a Vim-specific implementation.  And the other way around:
a grammer written for Vim can also be used by other editors.

Provide a complete parsed syntax tree.  The current implementation
has some caching, but synstack() returns very limited information and
can be quite slow.  We would want something that allows for movement
commands, e.g. "jump to start of function".

--
BEDEVERE: Look!  It's the old man from scene 24 - what's he Doing here?
ARTHUR:   He is the keeper of the Bridge.  He asks each traveler five
questions ...
GALAHAD:  Three questions.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

And how does an end user find out what highlight group to use for an
item?  Searching the files, what you can do with the current Vim syntax
plugins and a bit of guessing, seems too complicated.

Treesitter provides a tool called Playground. It displays the whole AST with highlight groups. A user has to open this window, place the cursor on the symbol in source file so that relevant part of AST is highlighted, and thus you know the highlight group, and the range of text (in source file) it encompasses.
On a general note, treesitter grammar bugs can be hard to fix. This gets harder if the author also used external parser (written in C) in addition to treesitter's own parser. For non CFG like markdown using an external parser is not uncommon.

The current highlight groups are somewhat of a blunt instrument. Setting Special, for example, will affect a wide and varied selection of language-specific highlight links and achieving better granularity requires making highlight configurations for each language of interest (which can be many for a public colorscheme)... at the very least, it would be convenient for the 'standardized' highlight groups to reach a higher level of specificity with respect to the most universal language constructs (for example, "Import"/"Export" for import- and export-like keywords).

For the record, this is why Neovim has added a (larger) number of standard groups for tree-sitter highlighting (inspired by TextMate/Sublime scopes): https://neovim.io/doc/user/treesitter.html#treesitter-highlight-groups
All official tree-sitter queries are enforced by CI to use these (only) for consistency (although the fallback mechanism makes it possible to gracefully handle further specialization and provides an automatic language-specialization for colorschemes to use). Your needs are of course different, but I'm pretty happy with it.

I'll comment only once more so as not to further disturb the great number of people likely following this conversation: my suggestion of expanding the standardized highlight group set was partially inspired by tree-sitter. I use Vim 9.1 (and vim9 script) so tree-sitter isn't a solution for me although I have not once felt the power and performance of the current syntax highlighting system to be insufficient (although I do recognize some of the regex improvements suggested in comments above). In fact, Vim 9.1 performs exceptionally.
I wholeheartedly believe in Vim's highly considered approach, addressing shortcomings of pioneer solutions ("doing it right," as Bram had said). With that, I assume a major change (behind a feature flag or otherwise) is not around the corner. If, however, the interface (highlight groups, in this case) can be determined with the level of rigor we've come to expect from changes in the Vim project, syntax maintainers would ideally eliminate reliance on bespoke highlight groups.
This would result in a superior experience for syntax maintainers and end users without the need for immediate introduction of a new parsing system. In the event of deeper systemic changes (introduction of systems akin to TextMate or tree-sitter), the highlight group interface would remain the same and end users would benefit immediately from any performance- or matching-related improvements.

In the meantime... textmate highlighter:
github.com/icedman/vim-textmate

checking on treesitter status.
sqlite3.c (222k lines of code)

neovim > file loads, after a couple of seconds; lags on editing - next to unsuable
helix > looks like it doesn't enable treesitter for very large files (or may not be working)

tinywl.c (1000 lines of code)

no problem with both

my own thoughts if the aim of VIM is..

vim as a simple, lightning fast editor - avoid treesitter which adds a lot of dependencies, and a degraded performance for very large files (at least for now). for simple highlighting - treesitter is also overkill
vim as an IDE, with all the bells an whistles of tree parsing - maybe too late for this. there is already neovim :)

sqlite3.c (222k lines of code)

idk man, but if you are manually editing a file with 200k loc of c code, instead of programatically generating it, feels like you gotta be doin'g something wrong imho. i tried opening the treesitter c parser, and yes, it gets a little laggy. i did :TSDisable and then it got fast. it has 600k loc.
on the other hand tree-sitter is pretty useful great on the 95% of the non 200k+ loc files you edit.

Just so you know,  I do love treesitter and I use it with neovim. I've experimented it with vim also:
https://github.com/icedman/vim-treesitter
My comment is not entirely without off-hand or without thought as you seem to suggest.

I'm not accusing you of anything; but as you can see from the discussion here, many comments are made without thought. And I do think "checking on treesitter status", followed by these examples, is misleading (even if not deliberately). So it's important to provide context if you want to have a meaningful discussion. If you don't do it, I will (to the limit of my ability and interest).

The main drawback still applies: reliance on an external program.
LSP is worse tho because it depends on an external program and a build configuration... and the toolchain... and the build system ;-) Especially with Linux kernel tree this quickly becomes apparent and it starts show its ugly face.
TS is not as bad but is still quite faulty design given that it is not well integrated to the source code of vim.

This is not to compare to neovim but it is fair to state that it does not have fully builtin TS support. You need a separate plugin nvim-treesitter for compiling parser and generally make it usable.
I use this only to point out that there is no a proven example to this day of vim or any of it s forks demonstrating fully integrated TS support. So maybe the conclusion is that TS simply does not work for vim? I'd guess reality would be otherwise different in 2024.

vim pursue to a non-generic designed for vim grammar solution, maybe something that would take advantage of the new vim9script.

Writing a c++ parser in vim9script?

This is not to compare to neovim but it is fair to state that it does not have fully builtin TS support. You need a separate plugin nvim-treesitter for compiling parser and generally make it usable.
I use this only to point out that there is no a proven example to this day of vim or any of it s forks demonstrating fully integrated TS support.

Integrating Treesitter fully into Vim is not a good design choice. Treesitter uses a different parser for each language, which needs to be generated using a grammar.js file. Typically, this parser is compiled into a .so library and placed in the runtime path. "Full integration" implies compiling all these language parsers, even though most of them may not be used, and maintaining them as the grammar.js files change. Additionally, some languages have buggy "custom parsers" built on top of what Treesitter generates, exacerbating the issue.
Treesitter seems to be an unsuitable solution for a lightweight editor like Vim. Its main selling point is the availability of an Abstract Syntax Tree (AST). While I wrote a small plugin to display devdoc and found that Treesitter could have made my job easier (I had to use Pandoc to generate an AST instead), it is still an overly complex solution if its primary role is to color syntax, a non-essential feature in my opinion. Other use cases, such as additional text objects or scaffolding for refactoring, are already covered by basic Vim functionalities.
On the other hand, TextMate also has its issues. Its grammar differs significantly from Vim's syntax grammar, which is closely aligned with Vim's regex grammar. Integrating TextMate into Vim feels like forcing a square peg into a round hole unless Vim's regex grammar artifacts are modified to reflect TextMate's regex grammar.

vim pursue to a non-generic designed for vim grammar solution, maybe something that would take advantage of the new vim9script.

Writing a c++ parser in vim9script?

Why in the heck would you do that?

vim pursue to a non-generic designed for vim grammar solution, maybe something that would take advantage of the new vim9script.

Writing a c++ parser in vim9script?

Why in the heck would you do that?

For the memes, of course

Sorry bro, I ignore memes.

This is not to compare to neovim but it is fair to state that it does not have fully builtin TS support. You need a separate plugin nvim-treesitter for compiling parser and generally make it usable.
I use this only to point out that there is no a proven example to this day of vim or any of it s forks demonstrating fully integrated TS support.

Integrating Treesitter fully into Vim is not a good design choice. Treesitter uses a different parser for each language, which needs to be generated using a grammar.js file. Typically, this parser is compiled into a .so library and placed in the runtime path. "Full integration" implies compiling all these language parsers, even though most of them may not be used, and maintaining them as the grammar.js files change. Additionally, some languages have buggy "custom parsers" built on top of what Treesitter generates, exacerbating the issue.
Treesitter seems to be an unsuitable solution for a lightweight editor like Vim. Its main selling point is the availability of an Abstract Syntax Tree (AST). While I wrote a small plugin to display devdoc and found that Treesitter could have made my job easier (I had to use Pandoc to generate an AST instead), it is still an overly complex solution if its primary role is to color syntax, a non-essential feature in my opinion. Other use cases, such as additional text objects or scaffolding for refactoring, are already covered by basic Vim functionalities.
On the other hand, TextMate also has its issues. Its grammar differs significantly from Vim's syntax grammar, which is closely aligned with Vim's regex grammar. Integrating TextMate into Vim feels like forcing a square peg into a round hole unless Vim's regex grammar artifacts are modified to reflect TextMate's regex grammar.

Agree with you. Tree-sitter is made to work with multiple editors. Vim would benefit most something with similar high-level ideas but made only for vim. Lot of meat and cruft in tree-sitter comes from it being "too generic". Nice idea but the implementation is not that great and adds bunch of extra dependencies.
If I recall correctly, e.g. installing neovim pulled tree-sitter, which pulled whole nodejs as dep, which was just terrible. I mean for an "ubiquitos" test editor used in terminal you have to have nodejs installed to your machine.

If I recall correctly, e.g. installing neovim pulled tree-sitter, which pulled whole nodejs as dep, which was just terrible.

You don't. (Please, get your facts right before making a claim.)

If I recall correctly, e.g. installing neovim pulled tree-sitter, which pulled whole nodejs as dep, which was just terrible.

You don't. (Please, get your facts right before making a claim.)

But some of its parsers AFAIK anyway. You are correct about package deps. I.e. you don't need it but make tree-sitter usable, system in practice needs to have npm, right? Or can you get 100% user experience without npm?

Yes.

If I recall correctly, e.g. installing neovim pulled tree-sitter, which pulled whole nodejs as dep, which was just terrible.

Node.js is required to parse the JavaScript grammar file when creating a new parser, as noted in the dependencies section. However, end users only need the compiled object file or C source file containing the language-specific parser. Therefore, if my recollection is correct, end users don't need to install Node.js.

Yes, you can absolutely do without nodejs installed.
And you do not need that plugin, anymore than you need vim-polyglot in Vim.
(Source: Maintainer for both Neovim and nvim-treesitter.)
And I would appreciate you not throwing around words like "broken" without actual experience.

I'm unfamiliar what polyglot is. I only use a few plugins and most of them are from tpope:
  Plug 'catppuccin/vim', { 'as': 'catppuccin' }
  Plug 'kaarmu/typst.vim', { 'as': 'typst' }
  Plug 'tpope/vim-flagship', { 'as': 'flagship' }
  Plug 'tpope/vim-fugitive', { 'as': 'fugitive' }
  Plug 'tpope/vim-vinegar', { 'as': 'vinegar' }
  Plug 'vim-scripts/git_patch_tags.vim', { 'as': 'git_patch_tags' }

Just hoping that neither TS or LSP will never land as any sort of features to Vim. I'm happy to let NeoVIM to keep them. Since not a developer I leave it here ;-)

Since not a developer I leave it here ;-) And IMHO Vim does not need to compete with NeoVIM anyhow. Many systems programmers (like me) appreciate it being as low-level as it is because ubiquitos property is more essential than TS and LSP combined togethter.

welcome you to continue to use vim native syntax hl method, it is mostly strong and stable, though maybe there some issues with specific terminal etc, maybe.
btw or fyi: there semantic highlight from lsp too, it is not xxxvim's dedicated feat, you can try to play it if you like, what i say from my side: it is not so "beautify" or "wonderful".
official vim welcome you to play, anyway, good luck.

This gentleman took a crack at a plugin for TextMate and Vim.
Look what he has accomplished:  https://github.com/icedman/vim-textmate

This gentleman took a crack at a plugin for TextMate and Vim.
Look what he has accomplished: https://github.com/icedman/vim-textmate

I also took a crack at nvim plugin for textmate.. https://github.com/icedman/vim-textmate
70+ more from the nvim users :)


Implement cache: field for docker-executor

Love
Thank you very much for this great tool, that will help me a lot with a few more features 🥰
Request
Description
Gitlab caching mecanism is ignored. A simple implementation would suffice : always mounting, in docker volumes, the files listed in cache section, for example.
Symptom
Slow builds
Workaround
Description
In the case of Maven, I use :
  cache:
    paths:
      - .m2/repository
  variables:
    MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository"

Populate the .m2 with some commands before lauching the tool :
MAVEN_OPTS="-Dmaven.repo.local=.m2/repository" mvn dependency:go-offline --settings ./common/maven.settings.xml
MAVEN_OPTS="-Dmaven.repo.local=.m2/repository" mvn some-particular:runtime-goal --settings ./common/maven.settings.xml

And add .m2 to .gitignore
Impact

✅ low : needs actions once before/after a debugging session
medium : fixed using another top level .gitlab-ci.yml
high : needs deep refactoring, everywhere in templates or everytime or both

I've renamed the card, hope thats ok... But yeah, we need this feature, especially in docker-executor jobs (image:)

Implementing fully-featured cache can be complex. Gitlab zips/unzips and download/upload file, depending on the policy, and this can take significant time at runtime.
As a first and easy step, I tried (yes... I cloned the repo 🎉) to bind mount a cache folder stored under .gitlab-ci-local/cache by adding this line in code :
dockerCmd += `-v \${PWD}/.gitlab-ci-local/cache/.m2:/builds/.m2 `

for this example of cache usage (my main cache usage) :
.maven:
  cache:
    key: maven
    paths:
      - .m2

This works like a charm, and is super efficient : not a single file copy or move is involved. This can save a lot of time in the pipeline compared to Gitlab way of handling cache !
I suggest this as a first and super efficient implementation. Later, we can implement different (slower) policies, but we could keep this as the fastest implementation with an option like --ignore-cache-policy or --fast-cache.
What do you think @firecow ?

At first glance it sounds like a good idea. key: files: string[] cannot work exactly like this, but we could restrict it to "key: string".

Implemented in #121


Please setup the output to "English"

The output chats are in chinese

I would like to boost this

duplicate of #16

Just update, add new UI interface, you can set response language, and custom LLM setting.


Fix logo on PyPI

Change the Cirq logo to an absolute URL so it isn't a broken link on PyPI.

A new package would still have to be uploaded to fix this on PyPI.

Of course.


Improve syntax files

Added Jinja syntax and tweaked JavaScript syntax
Fixes #1362

Is there a way to avoid having the jinja filetype conflict with html? (they both have the same detection expression)

Oops, I should not have added the detection expression to the jinja syntax (you can remove that). The user can just optionally enable jinja syntax highlighting for all html files by putting this in settings.json:
"*.html": {
    "filetype": "jinja2",
}

Or maybe we could detect if the HTML file is inside a folder named "templates". Because that is where Jinja templates go in by default for the Flask framework


Avoid bounds checks in IDCD and IWHT

Before: https://godbolt.org/z/PTo583Y7o
After: https://godbolt.org/z/qdda8sxsr
No autovectorization, but at least the bounds checks are gone.

I don't know how to benchmark this change because the crate is not wired up to image (I think?) so my usual benchmarking harness doesn't work, and the crate doesn't contain any examples (understandably, for such an early stage).

When I made this function accept [i32; 16] tests broke, and I did not know enough about the format to understand why. So I just put the most lenient assert in place that would get rid of the bounds checks.


[Feature] Display detail information on console when result-set is 1

User story
When getting APIs or Applications with the following command:
apim get api -s api-env
I only get the summary/list information:
+--------------------------------------+-----------------------+------------------------------+---------+
| API-Id                               | Path                  | Name                         | Version |
+--------------------------------------+-----------------------+------------------------------+---------+
| 14295903-2583-430a-8e5b-fda415191639 | /api/hipaa/control    | Security-HIPAA-Control       |     1.0 |

But as we have only ONE result it is convenient to display additional information like the following:
Organization: Organization ABC
Created On: <Date>
Created By: <Date>
Granted Organizations: <List of org-names>
Subscribed applications: <List of Application names>
Custom-Policies: <List of policy names>
Tags: <List of Tag-Groups<List of Tags>>
Custom-Properties: <List of Key: Value pairs>

There might be more information for an API we may add.
Additional context
This requires to load additional information for that API from the API-Manager Adapter ad-hoc.

Example result
2291   INFO     APIManagerAdapter| Successfully connected to API-Manager (7.7.20200130) on: https://api-env:8075
2481   INFO          APIExportApp| 1 API(s) selected.
+--------------------------------------+------------------+--------------------+---------+
| API-Id                               | Path             | Name               | Version |
+--------------------------------------+------------------+--------------------+---------+
| 499e3f01-d531-4c3d-be56-e6947de9538d | /api/emr/surgery | EMR-System-Surgery |     3.7 |
+--------------------------------------+------------------+--------------------+---------+

A P I  -  D E T A I L S
Organization:            Plexus Health
Created On:              Tue Jun 23 09:55:39 CEST 2020
Created By:              API Administrator
Granted Organizations:   Plexus Health
Subscribed applications: Plexus Suite – Appointment Management, Plexus Health Center, Plexus Suite – Surgery Center, Plexus Suite – Patient Monitoring
Custom-Policies:         None
Tags:                    Industry: Healthcare, Type: Demo_Amplify_PlexusHealth, Category: Surgery
Custom-Properties:       customProperty1: Test-Input 1, customProperty2: 1, customProperty3: true


place search broken

http://healthsites.io/
The place name is not found. Instead a healthsite that is closest to the search is presented.
'Cape Town' becomes 'Cape Town Medi clinic' and returns a  'Server Error (500)'

it is working now. I think because it was still in migrations


refactor: ratings repository

Describe your changes
Related Issues / Projects
Checklist

[x] I've manually tested my code

Made some changes -- condensed diff here: https://github.com/osuAkatsuki/bancho.py/pull/599/files/18ae6bfde62398d606469f935cd679092f7bb04b..67db50335c56f101928fb41c5b7a1a2d1520ac27

There is also
https://github.com/osuAkatsuki/bancho.py/blob/fdb6cb6120939ded460e55d98b300973d811a4cd/app/objects/beatmap.py#L546


Fix for motion sensors

Couple changes to fix motion sensors and not return the base device on multisensors.

Coverage increased (+0.1%) to 87.477% when pulling 08e0875d5ef58f8a9a163823f0f966cbbf78b224 on w1ll1am23:fix_for_motion_sensors into c4bc3b8ce2f8eab48e60175d546e9cd3174120d6 on python-wink:master.

I'm glad they went this way.  Makes more sense.

published


Namespaces reference section + moonbeam docs

docs are live here: https://shorsher.github.io/firefly/head/reference/namespaces.html
in a chain with #966

Codecov Report

Merging #1012 (d87cfe3) into main (d7597a8) will decrease coverage by 0.16%.
The diff coverage is n/a.

:exclamation: Current head d87cfe3 differs from pull request most recent head c73e08f. Consider uploading reports for the commit c73e08f to get more accurate results

@@            Coverage Diff             @@
##             main    #1012      +/-   ##
==========================================
- Coverage   99.99%   99.83%   -0.17%
==========================================
  Files         299      307       +8
  Lines       19492    20264     +772
==========================================
+ Hits        19491    20230     +739
- Misses          1       19      +18
- Partials        0       15      +15

Impacted Files
Coverage Δ

internal/txcommon/txcommon.go
96.03% <0.00%> (-3.97%)
:arrow_down:

internal/blockchain/ethereum/address_resolver.go
96.42% <0.00%> (-3.58%)
:arrow_down:

internal/events/event_manager.go
96.63% <0.00%> (-3.37%)
:arrow_down:

internal/orchestrator/orchestrator.go
98.10% <0.00%> (-1.90%)
:arrow_down:

internal/data/data_manager.go
98.57% <0.00%> (-1.43%)
:arrow_down:

internal/operations/manager.go
98.61% <0.00%> (-1.39%)
:arrow_down:

internal/identity/identitymanager.go
98.73% <0.00%> (-1.27%)
:arrow_down:

internal/privatemessaging/privatemessaging.go
98.77% <0.00%> (-1.23%)
:arrow_down:

internal/events/aggregator_rewind.go
99.34% <0.00%> (-0.66%)
:arrow_down:

internal/events/aggregator.go
99.48% <0.00%> (-0.52%)
:arrow_down:

... and 67 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


OpenCV Server: Clearify how to run test in readme

What?
Talk about how to run the tests in the readme. Should add the command, if the user does not use the script

Will be implemented in branch #33

Completed in pr #33


Stream Parser for SQL scripts

Axel,
Have you considered a stream parsing approach to the SQL scripts instead of pulling an array of strings? It may be a more comprehensive way to handle multi-line comments and string literals (as the current partial tokenization method has some parsing issues around determining alternate quotes and regular quotes). It may also handle binary content better too (which I have not had very much luck thus far with flyway doing blobs). Anyway, just curious if you've given much consideration to this approach.
Cheers,
Adam

Was any work on this done ?
In https://github.com/flyway/flyway/issues/759 @axelfontaine said that in Flyway 3.1 he wanted to move to a streaming solution but as of today as far as I can tell we still have the same problem
Infact for it already chokes on SqlMigrationResolver trying to calculate a checksum

So we can hope to get this with 5.1? :)

@bjoernhaeuser What's your use case for this?

@axelfontaine I have a 20mb sql file which contains all test data which is relevant for our development environment. With flyway 4.2 the process is stuck in tokenizing the SQL file and in the end fails.

I generally don't suggest alternative packages while projects are still being maintained, but since this has been a known issue for almost 3.5 years, I'm going to go ahead in this case.  @axelfontaine, I hope you do not mind.
For those of you who cannot use Flyway because it crashes on large migrations, you might consider https://github.com/realtymaps/dbsync as a fully streaming alternative, at least until Flyway can stream as well.  It is a straight SQL-based migration tool like Flyway, and actually was inspired in many ways by Flyway.  However it has a much smaller memory footprint, particularly when processing large migrations.
It is not for everyone, of course -- it doesn't support as many databases as Flyway, and it doesn't have Maven or Gradle integration.  Instead it is a CLI tool, so it can be readily integrated even in many projects where Flyway is not convenient.
Disclaimer: I'm the developer and maintainer of dbsync.


scope['variable']  for proper variables handling... and some linter stuff

I found some issues which may be fixed:

in the templates' files for the services like webserver or worker the syntax for variables is as follow:

@foo

and it seems to be hard to reach them, so I propose to change it to the
scope['airflow::foo']

also there are some puppet-linter issues like:

$ puppet-lint modules/airflow/manifests/
modules/airflow/manifests//resource/service.pp - WARNING: arrow should be on the right operand's line on line 11
modules/airflow/manifests//params.pp - ERROR: trailing whitespace found on line 75
modules/airflow/manifests//config.pp - WARNING: arrow should be on the right operand's line on line 11

the celery_ssl_active should be done for an apache-airflow v1.9 It is necessary for proper application setup. My proposition is to set it false by default

Proposed PR is here: [issue_#6] scope['variable'] for proper variables handling... and some linter stuff


[convert] Handle file series as a multiframe file

Closes #1127
Depends on #1387

Ready for review.


Use Kubernetes common labels for services created for carrier apps.

This is the remaining work to be done on issue #150.
The task for this issue is to ensure that generic labels are put on carrier app services.

Notes ...

Putting labels on the service instance and service binding resources is, I believe simple. We are creating these resources, see internal/services/catalog_service.go, so we can add labels at will.

The secret generated by SV in response to us posting a service binding resource is a bit more complex. We have to wait for it to exist, and then can attach labels after the fact. We know what to wait for because we control the name of that secret. For the code we can use the existing function to label a namespace after the fact as an example.

Regarding the pods created by SV and backend broker in response to our service instance.
I do not see that as possible for us. We have no control at all over the broker and/or the chart it uses. Actually even the fact that it does use a chart is suspect. True for minibroker. Very untrue for the google service broker. That one creates the service in google, likely completely outside of our cluster. IOW we have nothing to attach labels to. And that is likely the general situation for any broker.

My personal recommendation is to have that last out of scope for carrier.
@kkaempf @jimmykarily :bell:

I agree with the Andreas' last point. The whole tagging story started as a way to know what to delete when uninstalling Carrier. That was a way to know what things we deployed and thus belong to Carrier (there is always the argument that once something is installed on the cluster and accessible then it no longer belongs to you but that's another story). Let's not make tagging more important than the problem it originally tried to solve.
There are other ways to ensure proper cleanup (e.g. owner relationships). Let's tag what we create for now.


WMI Lookups for certain HP models failing

I'm finding that certain model lookups aren't correct when querying against the SCCM DB. I'm not sure the source of the strings used to query, but I wanted to mention Im' willing to troubleshoot if you can provide what values to be looking at in SCCM and I can provide those fro the models I'm not seeing get picked up.
Thanks,
Sam N.

We are having similar wmi error in log for Lenovo models where I've added "SelectedModels" to the DATSettings.xml, but only "Lenovo models known in WMI" are added and selected.  A lot of our models are not even available in the model search.  Some are available by switching the Operating System options, but then the ones I select are removed if I switch that option to find the missing models.  Some models are just not there.

Update - v7.2.2 still has the issue that it is not finding our models in WMI.  Checking WMI Explorer the models show up, so not still not sure why this suddenly stopped working.


Restores display of object status when displaying helm status

Changes to the Kubernetes API server and kubectl libraries caused
the status to no longer display when helm status was run for a
release. This change restores the status display.
Generation of the tables for display was optionally moved server
side. A request for the data as a table is made and a kubectl
printer for tables can display this data. Kubectl uses this setup and
the structure here closely resembles kubectl. kubectl is still
able to display objects as tables from prior to server side
printing. Server side printing is able to handle non-core
resources like CRDs.
Note, an extra request is made because table responses cannot be
easily transformed into Go objects for Kubernetes types to work
with. There is one request to get the resources for display in
a table and a second request to get the resources to lookup the
related pods. The related pods are now requested as a table as
well for display purposes.
This is likely part of the larger trend to move features like
this server side so that more libraries in more languages can
get to the feature.
The fix only works for Kubernetes 1.15 and newer. This is when
the table functionality was added to the api server. Kubernetes
supports the latest 3 minor versions meaning kubectl does the
same. It only needs to support back to 1.15 now for table
display. In Kubernetes 1.14 kubectl can still display the table
information using different printing methods.
Closes #6896
If someone knows how to fix this without using server side printing I would appreciate knowing as it would enable support to 1.14 and older versions of Kubernetes.

Taking this for a spin and trying to sift through the Kubernetes codebase to see if there's a better way.

Note, the latest change also fixes sorting and versions of Kubernetes 1.14 and older.

Thanks for the reviews. This was a hairy problem.


Adding python3 compatibility

A proper fix for python3 compatibility.
Thanks to @kbroughton and @mikebryant in https://github.com/opentracing-contrib/python-django/pull/16
Full functionality is maintained

Hey @sigginet sorry for the late review - had my hands full doing other OT things ;)
Thanks for jumping in on top of #16 - I left some comments. Let me know :)

Most of the PR feedback here is more in line with what is already at https://github.com/opentracing-contrib/python-django/pull/25

Closing as this is fixed by #25


Option to render FileChooser as 'open' when loading

Would it be possible to make the step of clicking 'select' to open the FileChooser optional? I feel this might be useful for applications where clicking select to open the widget is somewhat redundant.

It's not directly exposed via a parameter, but before you display the widget you can use the _show_dialog() function to open up the dialog:
fdialog = FileChooser(
    os.getcwd(),
    filename='test.txt',
    title='<b>FileChooser example</b>',
    show_hidden=False,
    select_default=True,
    show_only_dirs=False
)

fdialog._show_dialog()
display(fdialog)

Let me know if that helps resolve the issue for you or if you have any additional questions.

Hi @crahan, yes that's great! Exactly what I was looking for:) Thanks a bunch!

Awesome, thanks for confirming!


wsa is not listed in default.xml

If you build following the instructions in README.md, and enable wayland support, then it won't download the repository, as it's not listed in default.xml, so repo will not download it.
It also makes it quite hard to understand what version of wsa one should be using.
Can you please add the correct version to default.xml? I would just open a PR, but I'm not sure that it should be using GPUOpen-Drivers/wsa@master .
Thanks in advance.

Sorry, looks like readme is left out to be updated. wsa is deprecated and it is integrated into Pal already. Will update the readme.

@JacobHeAMD It would probably be worth adding a warning (and not building WSA) if the user enables the BUILD_WSA option in cmake for xgl.
Cheers.


Combat and Log Tabs Don't Load Correctly W/ New Hero Matches

Clicking the Combat or the Log tab in matches where the new heroes have been played results in this:

The issue can also be replicated on Chrome:

It doesn't seem to happen in matches where the new heroes were not played.

Issue is fixed by adding new heroes to hero list, but we should still handle this without crashing

This should not be too hard to do, although now that the data for the new heroes has been added, you might need to repro it by faking some data or modifying the heroes object imported from dotaconstants to simulate not having a hero object for a new ID.


Feature/remove storage register

What does this PR do?
Removes the store and loaders from http handlers

+1


[Feature Request] Show the calculated benefit of curses / buffs in the "Calcs" tab

Hey again!
Just a low-prio feature, but I think this would be cool:
Hovering over the buffs at the top of the "calcs" tab could show the benefits of the eg. auras just like you do it in the skill-tree.
Here is some concept art with extensive use of Comic Sans to spice it up a little:

That one's been on the TODO list for a while; showing the effects granted by an aura/buff/curse skill is easy but calculating the effect of enabling/disabling the skill is a bit trickier. I'll get around to it some day though.

The modifiers granted by auras are now shown in the Calcs tab, and the effects of enabling/disabling a skill are shown in the Skills tab, so I'd consider this done.
No Comic Sans, though :P


fix: apply the input tags

Description
Ensures that the input tags are applied rather than applying a set of static tags.
Type of Change

[ ] Non-module change (e.g. CI/CD, documentation, etc.)
[ ] Azure Verified Module updates:

[ ] Bugfix containing backwards compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in locals.version.tf.json:

[ ] Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
[ ] The bug was found by the module author, and no one has opened an issue to report it yet.

[ ] Feature update backwards compatible feature updates, and I have bumped the MINOR version in locals.version.tf.json.
[ ] Breaking changes and I have bumped the MAJOR version in locals.version.tf.json.
[ ] Update to documentation

Checklist

[ ] I'm sure there are no other open Pull Requests for the same update/change
[ ] My corresponding pipelines / checks run clean and green without any errors or warnings
[ ] I did run all  pre-commit checks

@microsoft-github-policy-service agree


update to OpenAPI 3.1.x

Im trying to upgrade to openapi 3.1.0 to be able to use type: mutualTLS in the security scheme definition, and it throws an error that the version is not recognised.
Since the 3.1.0 upgrade has been around for quite some time, will it be supported anytime soon?
Screenshot of error below.

Actually supporting the features of 3.1.0 is probably a long way off since there are still 3.0 features incomplete 😬.
Reading the spec and just handling any breaking changes for the 3.0 features we do support is probably relatively easy, just a time investment.
I'm unlikely to have the time to do that anytime soon, but would welcome a PR from someone who does.

The changes are not too major, just moving in line with JSON Schema for the schema objects and a few simplifications to examples. https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0


Support authentication

Should support Git server authentication API similar to Isomorphic Git functions.

Authentication currently confirmed to work via HTTP basic auth header, but callers are supposed to supply it for the moment (example).
It should be improved by allowing to pass username & password parameters instead of pre-crafted HTTP header.


Running on Windows - Problems and Solutions

Great project and thank you for sharing!
I ran into a few issues while installing and have some solutions.
Problems

Qdrant didn't work on Windows 10
Unclear where data is supposed to be stored/loaded
Unclear where the app runs from when using docker

Solutions

Use docker for Qdrant - It seems that qdrant is very problematic running on windows natively

navigate to "docker" folder in main directory
docker compose up -d
Check qdrant container http://localhost:6333/dashboard

Download data from https://civitai.com/models/330412/prompt-quill-vector-data

Navigate: Qdrant Dashboard -> collections -> upload dataset
Name the new collection: prompts_large_meta
Unzip prompt quill vector file (19GB or so)
Populate the upload dialogue with the file and click upload
Patiently wait for Qdrant to do its thing. DO NOT CLICK AROUND. Go check out hackernews or something
It will finish eventually and now you can install the app with the one click method

Install the app

The app itself doesn't install into another docker container. I was confused by this at first. It simply uses docker for qdrant.
Click on one_click_install_docker.bat to install the main app. I still ended up with the vector data being downloaded, into the /installer_files/qdrant/ directory. I haven't deleted it yet but I assume you could as its using the docker container.
Once installed, use the start_prompt_quill_docker.bat to run. There will be a pull request with a change to this file shortly.

Thanks for pointing that out and digging into the details. I keep it open so maybe other people can learn from this until I learn how to fix the native install that most the time works but in some cases keep failing without any visible reason.


newPlayer

Coverage decreased (-7.4%) to 92.593% when pulling 32e7dbe87d433db24828798c383c48bbee0d3e2b on hibulix:newPlayer into 85eefbc6650b3ae36d1f559cebeb4b359e4c058c on MovingImage24:master.

Coverage remained the same at 100.0% when pulling 0e8de19e617d0a6372242687ab3c3866b8a3a3cd on hibulix:newPlayer into 85eefbc6650b3ae36d1f559cebeb4b359e4c058c on MovingImage24:master.


Wake Up from Touch

I tried this example without any changes, using some devboards I have, but with no luck.
Wake up from timer and GPIO, all work, but no luck with touch.
Any advice?

What kind of circuit are you using to connect the touch pad?
The example will also print some touch readings during calibration, can you paste the relevant part of the log here?

No specific circuit. Direct connection from touch pin/pad to ESP-WROOM-32.
I saw the code is doing some calibration. CMIIW, it expects the average touch reading to be above 300. In my case, average touch reading (when not touched) on the pin I use is above 1200. And when touched the reading is under 200. So I believe it meets the threshold.

This indeed is a regression. Looking into this.

I  just had access to my computer, here's the log requested:
Enabling timer wakeup, 30s
Enabling EXT1 wakeup on pins GPIO25, GPIO26
Touch pad #8 average: 1174, wakeup threshold set to 1074.
Touch pad #9 average: 897, wakeup threshold set to 797.
Enabling touch pad wakeup
Entering deep sleep

None of touch #8 or #9 that causes wake up from deep sleep.
Please take a look. Thanks!

As a temporary workaround, you may roll back to v2.0 release.
We're looking into this, but the issue looks pretty odd, may take some time to solve.

Ok, found the issue, will have the fix in master shortly. For now you can fix it locally:
From 1c3b40adeb1de0b18575d5419bfc61264b6ec733 Mon Sep 17 00:00:00 2001
From: Ivan Grokhotkov<EMAIL_ADDRESS>Date: Thu, 27 Apr 2017 12:42:56 +0800
Subject: [PATCH] esp32: select 8M clock as RTC_FAST_CLK on startup

Even though RTC_CLK_CONFIG_DEFAULT correctly had RTC_FAST_FREQ_8M as the
fast clock, the bootloader modified fast_freq field to the currently
selected RTC_FAST_CLK (so that the clock choice is not affected by the
bootloader). The application startup code never switched to 8M clock,
which caused the default (XTAL/4) to be used as RTC_FAST_CLK. This had
caused a number of issues, such as touch pads not working in deep sleep.

Fixes https://github.com/espressif/esp-idf/issues/542.
Ref TW12053.
---
 components/esp32/clk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/components/esp32/clk.c b/components/esp32/clk.c
index 449ea39..ce7b580 100644
--- a/components/esp32/clk.c
+++ b/components/esp32/clk.c
@@ -43,6 +43,7 @@ void esp_clk_init(void)
 {
     rtc_config_t cfg = RTC_CONFIG_DEFAULT();
     rtc_init(cfg);
+    rtc_clk_fast_freq_set(RTC_FAST_FREQ_8M);

 #ifdef CONFIG_ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
     select_rtc_slow_clk(RTC_SLOW_FREQ_32K_XTAL);
--
2.10.1 (Apple Git-78)

@igrr Superb! I can confirm it working flawlessly. Super thanks!
Side note, previously touchRead on each pad is around 50-100. Now, above 800. Is it affected by that change?

Your previous comment said

average touch reading to be above 300. In my case, average touch reading (when not touched) on the pin I use is above 1200. And when touched the reading is under 200.

Could you clarify in which case you saw 50-100? For 1cm^2 sized touch pads I'm getting ~1200 both with old and new code.

That's before applying your patch. My touch pad is like the picture below, about 2x1.5cm. I have another custom board, with similar size pad, the reading is around the same, again that's before the patch.
,

By the way, that reading difference that I experienced is not really a concern, though. You could close this issue. Again, thanks for the fix.


Move ObservedGeneration earlier in reconciliation

We need to updated ObservedGeneration just after
we reinit conditions to avoid race condtitions.
We are not depending on any additional subCR in placement so we don't need to check nothing more

@mrkisaolamb I'm wondering if actually we want to have the observedGeneration field in the last ring of the chain, which is in this case the Deployment.
I'm not sure it applies to this case, but we currently have this conversation [1] where the DeploymentReadyCondition could be marked as True when we know the subCR controller sees the last version of the StatefulSet (or Deployment in this case) spec. In theory that makes sense (and it allows to propagate the entire pattern to the lowest level), but I'm not sure about your thoughts on that front.
[1] https://github.com/openstack-k8s-operators/glance-operator/pull/501/files#r1553269854

@mrkisaolamb I'm wondering if actually we want to have the observedGeneration field in the last ring of the chain, which is in this case the Deployment. I'm not sure it applies to this case, but we currently have this conversation [1] where the DeploymentReadyCondition could be marked as True when we know the subCR controller sees the last version of the StatefulSet (or Deployment in this case) spec. In theory that makes sense (and it allows to propagate the entire pattern to the lowest level), but I'm not sure about your thoughts on that front.
[1] https://github.com/openstack-k8s-operators/glance-operator/pull/501/files#r1553269854

Hey @fmount, thanks! yes we had this discussion with Gibi on friday, I wanted to add this check but then I realize that first I need to check if there was no such logic on lower lvls. And answers is no there is not so definitly we need here this logic: deployment.Generation <= deployment.Status.ObservedGeneration

/lgtm

This will failed because of mariadboperator test, to land this patch we need first land mariadboperator update of lib-common

This will failed because of mariadboperator test, to land this patch we need first land mariadboperator update of lib-common

https://github.com/openstack-k8s-operators/mariadb-operator/pull/217  is merged but bumping to it locally still does not make the test pass.
  [FAILED] Timed out after 2.001s.
  Expected
      <[]string | len:1, cap:4>: ["PlacementAPI"]
  not to contain element matching
      <string>: PlacementAPI
  In [It] at: /home/gibi/go/pkg/mod/github.com/openstack-k8s-operators/mariadb-operator/api@v0.3.1-0.20240418060416-9de2d1f1915e/test/helpers/harnesses.go:311 @ 04/18/24 10:16:07.07

  Full Stack Trace
    github.com/openstack-k8s-operators/mariadb-operator/api/test/helpers.(*MariaDBTestHarness).RunBasicSuite.func2.4()
    	/home/gibi/go/pkg/mod/github.com/openstack-k8s-operators/mariadb-operator/api@v0.3.1-0.20240418060416-9de2d1f1915e/test/helpers/harnesses.go:311 +0x7b6
------------------------------
•••••••••••••••••••••••••••••••••••••

Summarizing 1 Failure:
  [FAIL] PlacementAPI controller when The  service is fully running [It] should move the finalizer to a new MariaDBAccount when create is complete

This will failed because of mariadboperator test, to land this patch we need first land mariadboperator update of lib-common

openstack-k8s-operators/mariadb-operator#217 is merged but bumping to it locally still does not make the test pass.
  [FAILED] Timed out after 2.001s.
  Expected
      <[]string | len:1, cap:4>: ["PlacementAPI"]
  not to contain element matching
      <string>: PlacementAPI
  In [It] at: /home/gibi/go/pkg/mod/github.com/openstack-k8s-operators/mariadb-operator/api@v0.3.1-0.20240418060416-9de2d1f1915e/test/helpers/harnesses.go:311 @ 04/18/24 10:16:07.07

  Full Stack Trace
    github.com/openstack-k8s-operators/mariadb-operator/api/test/helpers.(*MariaDBTestHarness).RunBasicSuite.func2.4()
    	/home/gibi/go/pkg/mod/github.com/openstack-k8s-operators/mariadb-operator/api@v0.3.1-0.20240418060416-9de2d1f1915e/test/helpers/harnesses.go:311 +0x7b6
------------------------------
•••••••••••••••••••••••••••••••••••••

Summarizing 1 Failure:
  [FAIL] PlacementAPI controller when The  service is fully running [It] should move the finalizer to a new MariaDBAccount when create is complete

updated now tests past

side note I also see the unstable test but for me it sometimes happens with doubled timeout as well so I think is not just slow but somehow racy.
  2024-04-19T17:59:16+02:00	INFO	Controllers.PlacementAPI	Deployment c73457aa-43f7-44dc-a808-a - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"c73457aa-43f7-44dc-a808-a","namespace":"74dee9cb-8f03-4879-a2bf-a87443a7e9fd"}, "namespace": "74dee9cb-8f03-4879-a2bf-a87443a7e9fd", "name": "c73457aa-43f7-44dc-a808-a", "reconcileID": "ba41cd30-d377-4f73-bf86-5d55f74e417b"}
  2024-04-19T17:59:16+02:00	INFO	Controllers.PlacementAPI	Deployment is not ready	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"c73457aa-43f7-44dc-a808-a","namespace":"74dee9cb-8f03-4879-a2bf-a87443a7e9fd"}, "namespace": "74dee9cb-8f03-4879-a2bf-a87443a7e9fd", "name": "c73457aa-43f7-44dc-a808-a", "reconcileID": "ba41cd30-d377-4f73-bf86-5d55f74e417b"}
  2024-04-19T17:59:16+02:00	INFO	Controllers.PlacementAPI	Waiting for the Deployment to become Ready before exposing the sevice in Keystone	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"c73457aa-43f7-44dc-a808-a","namespace":"74dee9cb-8f03-4879-a2bf-a87443a7e9fd"}, "namespace": "74dee9cb-8f03-4879-a2bf-a87443a7e9fd", "name": "c73457aa-43f7-44dc-a808-a", "reconcileID": "ba41cd30-d377-4f73-bf86-5d55f74e417b"}
  [FAILED] in [It] - /home/gibi/go/pkg/mod/github.com/openstack-k8s-operators/mariadb-operator/api@v0.3.1-0.20240418060416-9de2d1f1915e/test/helpers/harnesses.go:311 @ 04/19/24 17:59:20.338

But we can take this issue separately.

ohh looking at the logs the reconciler did not triggered again for 4 seconds so based on this this deployment is never updated after the last reconcile.
...
oh maybe our test makes the deployment ready too early and the reconciler bumps the spec after the test made the deployment ready and therefore bumping the generation.

side note I also see the unstable test but for me it sometimes happens with doubled timeout as well so I think is not just slow but somehow racy.
  2024-04-19T17:59:16+02:00	INFO	Controllers.PlacementAPI	Deployment c73457aa-43f7-44dc-a808-a - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"c73457aa-43f7-44dc-a808-a","namespace":"74dee9cb-8f03-4879-a2bf-a87443a7e9fd"}, "namespace": "74dee9cb-8f03-4879-a2bf-a87443a7e9fd", "name": "c73457aa-43f7-44dc-a808-a", "reconcileID": "ba41cd30-d377-4f73-bf86-5d55f74e417b"}
  2024-04-19T17:59:16+02:00	INFO	Controllers.PlacementAPI	Deployment is not ready	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"c73457aa-43f7-44dc-a808-a","namespace":"74dee9cb-8f03-4879-a2bf-a87443a7e9fd"}, "namespace": "74dee9cb-8f03-4879-a2bf-a87443a7e9fd", "name": "c73457aa-43f7-44dc-a808-a", "reconcileID": "ba41cd30-d377-4f73-bf86-5d55f74e417b"}
  2024-04-19T17:59:16+02:00	INFO	Controllers.PlacementAPI	Waiting for the Deployment to become Ready before exposing the sevice in Keystone	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"c73457aa-43f7-44dc-a808-a","namespace":"74dee9cb-8f03-4879-a2bf-a87443a7e9fd"}, "namespace": "74dee9cb-8f03-4879-a2bf-a87443a7e9fd", "name": "c73457aa-43f7-44dc-a808-a", "reconcileID": "ba41cd30-d377-4f73-bf86-5d55f74e417b"}
  [FAILED] in [It] - /home/gibi/go/pkg/mod/github.com/openstack-k8s-operators/mariadb-operator/api@v0.3.1-0.20240418060416-9de2d1f1915e/test/helpers/harnesses.go:311 @ 04/19/24 17:59:20.338

But we can take this issue separately.

ohh looking at the logs the reconciler did not triggered again for 4 seconds so based on this this deployment is never updated after the last reconcile.
...
oh maybe our test makes the deployment ready too early and the reconciler bumps the spec after the test made the deployment ready and therefore bumping the generation.

so when the test updates the mariadbaccount to the new one the reconciler will update the deployment at least with a new label about the new config hash to trigger pod restart. I'm not sure that causes the Deployment generation to increase. But if so then we don't make the new Deployment generation ready in https://github.com/openstack-k8s-operators/placement-operator/blob/887edc53c4171811abb0e8856dcd6efeddd9431d/tests/functional/placementapi_controller_test.go#L911  I need to log things out to know more...

side note I also see the unstable test but for me it sometimes happens with doubled timeout as well so I think is not just slow but somehow racy.
  2024-04-19T17:59:16+02:00	INFO	Controllers.PlacementAPI	Deployment c73457aa-43f7-44dc-a808-a - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"c73457aa-43f7-44dc-a808-a","namespace":"74dee9cb-8f03-4879-a2bf-a87443a7e9fd"}, "namespace": "74dee9cb-8f03-4879-a2bf-a87443a7e9fd", "name": "c73457aa-43f7-44dc-a808-a", "reconcileID": "ba41cd30-d377-4f73-bf86-5d55f74e417b"}
  2024-04-19T17:59:16+02:00	INFO	Controllers.PlacementAPI	Deployment is not ready	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"c73457aa-43f7-44dc-a808-a","namespace":"74dee9cb-8f03-4879-a2bf-a87443a7e9fd"}, "namespace": "74dee9cb-8f03-4879-a2bf-a87443a7e9fd", "name": "c73457aa-43f7-44dc-a808-a", "reconcileID": "ba41cd30-d377-4f73-bf86-5d55f74e417b"}
  2024-04-19T17:59:16+02:00	INFO	Controllers.PlacementAPI	Waiting for the Deployment to become Ready before exposing the sevice in Keystone	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"c73457aa-43f7-44dc-a808-a","namespace":"74dee9cb-8f03-4879-a2bf-a87443a7e9fd"}, "namespace": "74dee9cb-8f03-4879-a2bf-a87443a7e9fd", "name": "c73457aa-43f7-44dc-a808-a", "reconcileID": "ba41cd30-d377-4f73-bf86-5d55f74e417b"}
  [FAILED] in [It] - /home/gibi/go/pkg/mod/github.com/openstack-k8s-operators/mariadb-operator/api@v0.3.1-0.20240418060416-9de2d1f1915e/test/helpers/harnesses.go:311 @ 04/19/24 17:59:20.338

But we can take this issue separately.

ohh looking at the logs the reconciler did not triggered again for 4 seconds so based on this this deployment is never updated after the last reconcile.
...
oh maybe our test makes the deployment ready too early and the reconciler bumps the spec after the test made the deployment ready and therefore bumping the generation.

so when the test updates the mariadbaccount to the new one the reconciler will update the deployment at least with a new label about the new config hash to trigger pod restart. I'm not sure that causes the Deployment generation to increase. But if so then we don't make the new Deployment generation ready in
https://github.com/openstack-k8s-operators/placement-operator/blob/887edc53c4171811abb0e8856dcd6efeddd9431d/tests/functional/placementapi_controller_test.go#L911
I need to log things out to know more...

Indeed something changes in the Deployment that bumps it generation after the mariadbaccount is changed and generation 2 never made ready by the test as we don't expect it generation bump. We need to dig more what changes in the deployment:
2024-04-19T18:20:52+02:00	INFO	---Test---	!!!	{"depl.Generation": 1, "depl.Status.ObservedGeneration": 1}
  2024-04-19T18:20:52+02:00	INFO	---Test---	Simulated DB Account completed	{"on": {"name":"some-new-account","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}}
  2024-04-19T18:20:52+02:00	INFO	---Test---	Service should move to run fully off MariaDBAccount a2566ac4-1a9e-4471-a57e-f40ea1863584/some-new-account and remove finalizer from a2566ac4-1a9e-4471-a57e-f40ea1863584/some-old-account
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Successfully ensured MariaDBAccount some-new-account exists; database username is placement_da24	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "0312ce70-2d81-4bf1-92cb-a9302b7701a1", "ObjectType": "*v1beta1.MariaDBAccount", "ObjectNamespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "ObjectName": "some-new-account"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Applied new databasehostname hostname-for-openstack.a2566ac4-1a9e-4471-a57e-f40ea1863584.svc to MariaDBDatabase placement	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "0312ce70-2d81-4bf1-92cb-a9302b7701a1"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Secret 70956c7d-da7b-4ebe-b12c-c-config-data successfully reconciled - operation: updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "0312ce70-2d81-4bf1-92cb-a9302b7701a1"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Input maps hash input - n5cfh65h5bfhf7h586h694h5c5h5c6h7dhf6h547h5bch5dfh69h589h5f6h8h97h555hb8h584h5ddh9fh554h646h594h9fh67dh5d4h89hd9h554q{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "0312ce70-2d81-4bf1-92cb-a9302b7701a1"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Successfully ensured MariaDBAccount some-new-account exists; database username is placement_da24	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "169e5663-0e22-4576-a56d-d4bf4600d29e", "ObjectType": "*v1beta1.MariaDBAccount", "ObjectNamespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "ObjectName": "some-new-account"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Applied new databasehostname hostname-for-openstack.a2566ac4-1a9e-4471-a57e-f40ea1863584.svc to MariaDBDatabase placement	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "169e5663-0e22-4576-a56d-d4bf4600d29e"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Input maps hash input - n5cfh65h5bfhf7h586h694h5c5h5c6h7dhf6h547h5bch5dfh69h589h5f6h8h97h555hb8h584h5ddh9fh554h646h594h9fh67dh5d4h89hd9h554q{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "169e5663-0e22-4576-a56d-d4bf4600d29e"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Successfully ensured MariaDBAccount some-new-account exists; database username is placement_da24	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "c5501a9f-5720-4ef5-b5d2-d3616457147f", "ObjectType": "*v1beta1.MariaDBAccount", "ObjectNamespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "ObjectName": "some-new-account"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Applied new databasehostname hostname-for-openstack.a2566ac4-1a9e-4471-a57e-f40ea1863584.svc to MariaDBDatabase placement	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "c5501a9f-5720-4ef5-b5d2-d3616457147f"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Service placement-public - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "c5501a9f-5720-4ef5-b5d2-d3616457147f"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Service placement-internal - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "c5501a9f-5720-4ef5-b5d2-d3616457147f"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Reconciling Service	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "c5501a9f-5720-4ef5-b5d2-d3616457147f"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Deployment 70956c7d-da7b-4ebe-b12c-c - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "c5501a9f-5720-4ef5-b5d2-d3616457147f"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Deployment is not ready	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "c5501a9f-5720-4ef5-b5d2-d3616457147f", "deployment.Generation": 2, "deploymentStatus.ObservedGeneration": 1, "instance.Status.ReadyCount": 1}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Waiting for the Deployment to become Ready before exposing the sevice in Keystone	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "c5501a9f-5720-4ef5-b5d2-d3616457147f"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Successfully ensured MariaDBAccount some-new-account exists; database username is placement_da24	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "7db64b86-9d22-437e-8ce4-b80caee6a539", "ObjectType": "*v1beta1.MariaDBAccount", "ObjectNamespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "ObjectName": "some-new-account"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Applied new databasehostname hostname-for-openstack.a2566ac4-1a9e-4471-a57e-f40ea1863584.svc to MariaDBDatabase placement	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "7db64b86-9d22-437e-8ce4-b80caee6a539"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Service placement-public - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "7db64b86-9d22-437e-8ce4-b80caee6a539"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Service placement-internal - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "7db64b86-9d22-437e-8ce4-b80caee6a539"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Reconciling Service	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "7db64b86-9d22-437e-8ce4-b80caee6a539"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Deployment 70956c7d-da7b-4ebe-b12c-c - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "7db64b86-9d22-437e-8ce4-b80caee6a539"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Deployment is not ready	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "7db64b86-9d22-437e-8ce4-b80caee6a539", "deployment.Generation": 2, "deploymentStatus.ObservedGeneration": 1, "instance.Status.ReadyCount": 1}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Waiting for the Deployment to become Ready before exposing the sevice in Keystone	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "7db64b86-9d22-437e-8ce4-b80caee6a539"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Successfully ensured MariaDBAccount some-new-account exists; database username is placement_da24	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "71c483c7-9483-4872-933b-0556ea3a2aab", "ObjectType": "*v1beta1.MariaDBAccount", "ObjectNamespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "ObjectName": "some-new-account"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Applied new databasehostname hostname-for-openstack.a2566ac4-1a9e-4471-a57e-f40ea1863584.svc to MariaDBDatabase placement	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "71c483c7-9483-4872-933b-0556ea3a2aab"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Service placement-public - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "71c483c7-9483-4872-933b-0556ea3a2aab"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Service placement-internal - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "71c483c7-9483-4872-933b-0556ea3a2aab"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Reconciling Service	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "71c483c7-9483-4872-933b-0556ea3a2aab"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Deployment 70956c7d-da7b-4ebe-b12c-c - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "71c483c7-9483-4872-933b-0556ea3a2aab"}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Deployment is not ready	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "71c483c7-9483-4872-933b-0556ea3a2aab", "deployment.Generation": 2, "deploymentStatus.ObservedGeneration": 1, "instance.Status.ReadyCount": 1}
  2024-04-19T18:20:52+02:00	INFO	Controllers.PlacementAPI	Waiting for the Deployment to become Ready before exposing the sevice in Keystone	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "71c483c7-9483-4872-933b-0556ea3a2aab"}
  2024-04-19T18:20:53+02:00	INFO	Controllers.PlacementAPI	Successfully ensured MariaDBAccount some-new-account exists; database username is placement_da24	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "f8a989a4-b1bf-4d2e-8233-8be5bc683d93", "ObjectType": "*v1beta1.MariaDBAccount", "ObjectNamespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "ObjectName": "some-new-account"}
  2024-04-19T18:20:53+02:00	INFO	Controllers.PlacementAPI	Applied new databasehostname hostname-for-openstack.a2566ac4-1a9e-4471-a57e-f40ea1863584.svc to MariaDBDatabase placement	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "f8a989a4-b1bf-4d2e-8233-8be5bc683d93"}
  2024-04-19T18:20:53+02:00	INFO	Controllers.PlacementAPI	Service placement-public - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "f8a989a4-b1bf-4d2e-8233-8be5bc683d93"}
  2024-04-19T18:20:53+02:00	INFO	Controllers.PlacementAPI	Service placement-internal - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "f8a989a4-b1bf-4d2e-8233-8be5bc683d93"}
  2024-04-19T18:20:53+02:00	INFO	Controllers.PlacementAPI	Reconciling Service	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "f8a989a4-b1bf-4d2e-8233-8be5bc683d93"}
  2024-04-19T18:20:53+02:00	INFO	Controllers.PlacementAPI	Deployment 70956c7d-da7b-4ebe-b12c-c - updated	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "f8a989a4-b1bf-4d2e-8233-8be5bc683d93"}
  2024-04-19T18:20:53+02:00	INFO	Controllers.PlacementAPI	Deployment is not ready	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "f8a989a4-b1bf-4d2e-8233-8be5bc683d93", "deployment.Generation": 2, "deploymentStatus.ObservedGeneration": 1, "instance.Status.ReadyCount": 1}
  2024-04-19T18:20:53+02:00	INFO	Controllers.PlacementAPI	Waiting for the Deployment to become Ready before exposing the sevice in Keystone	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"70956c7d-da7b-4ebe-b12c-c","namespace":"a2566ac4-1a9e-4471-a57e-f40ea1863584"}, "namespace": "a2566ac4-1a9e-4471-a57e-f40ea1863584", "name": "70956c7d-da7b-4ebe-b12c-c", "reconcileID": "f8a989a4-b1bf-4d2e-8233-8be5bc683d93"}
  [FAILED] in [It] - /home/gibi/go/pkg/mod/github.com/openstack-k8s-operators/mariadb-operator/api@v0.3.1-0.20240418060416-9de2d1f1915e/test/helpers/harnesses.go:311 @ 04/19/24 18:20:54.799

/retest


Only support FIELD_ELEMENTS_PER_BLOB values that are a power of 2.

We do not want to support or maintain this case, so let us be explicit about it.
This should solve #226

LGTM


use eslint-, stylelint- & prettier-config from natterstefan/eslint-config-ns

See https://github.com/natterstefan/eslint-config-ns

Coverage remained the same at 83.402% when pulling 4f7fdb00ca0f5815f2f6632a1aece53f8926312e on feature/0.0.2-linter-config into 23e1a6a5160e653ad4ef70d93240161c8f6cc59b on master.


Image Gallery Favourite image feature and section

Story

As a .............

I Want .............

So That .............

Acceptance Criteria

Given .............

When .............
Then .............

Given .............

When .............
Then .............

Implementation Notes

Heart button by the picture so user can favourite an image
A section where user can retrieve the images they have marked as favourite

Checklist:

[ ] I have defined the user story
[ ] I have defined some acceptance criteria
[ ] I have included any implementation notes
[ ] I have included all relevant links

just a nice to have, so if you can, do it on week 4


Add HaveMethod expression

Feature Request

Q
A

New Feature
yes

RFC
no

BC Break
no

Summary
I would like to enforce this constraint:
Rule::allClasses()
        ->that(new HaveNameMatching('App\*\Command\*Handler'))
        ->should(new HaveMethod('__invoke'))
        ->because('command handlers should be invokable');

ATM we don't have any mechanism to check stuff on class implementation, isn't it?

I think this is a useful addition. Would you elaborate a bit more about how is it supposed to work? In particular:

should the class directly implement the method or it can also inherit it?
should pattern matching work?

Regarding your questions:

Class can implement or inherit the method.
Patter matching could be useful, someone could enforce rules like "Repository should have findBy* methods"; even I dislike it, there are frameworks that work this way.

I am not sure we capture inherited methods in ClassDescritpion objects but we can probably discuss the implementation later
For consistency we should also have a NotHaveMethod

At the moment we don't have a mechanism to check stuff on class implementation because we were focused on rules for dependencies.
We can try to understand if now it's time to develop something to create rules for methods.

That's a good point with __invoke for command handlers, but isn't self validated at runtime? It sounds more of unit test territory than architect decision.
As for generic methods, shouldn't developer cover this with interfaces? Maybe only magic method expression?

Would love to see this feature coming!
One of my use case would be to check for "valid" method names on a controller. Valid according to this list of actions: https://laravel.com/docs/9.x/controllers#actions-handled-by-resource-controller
Example:
Rule::allClasses()
        ->that(new ResideInOneOfTheseNamespaces('App\Http\Controllers'))
        ->should(new HaveMethod(['index', 'create', 'store', 'show'...]))
        ->because('something');


cargo build --bin src/main.rs

When I have src/main.rs as well as src/bin/x.rs, I can run cargo build --bin x to build only the latter, but I can't find a way to build only the former. Is there a way or is this missing?

You can run src/main.rs with cargo build --bin name-of-your-package as that's the auto-assigned name to src/main.rs

Could have sworn I tried that. But it works.


Browsing HTML file in Modern View of Classic Site

Hello Team, What is the expected behavior when browsing HTML file (Present in Documents library) in Modern view of Classic site? I am able to browse the page normally. Is this issue only in Classic sites? Can you please let me know.
Thanks,
Bhanu

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

ID: 46053cad-6e95-c45d-608f-5262c31b0eeb
Version Independent ID: 641cf9a1-7e4c-ea58-dd55-dcb80b80435d
Content: Migrating from the permissive browser file handling to the default strict browser file handling
Content Source: docs/solution-guidance/security-permissivesetting.md
Product: sharepoint
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

Thank you for your submission. This GitHub issue list is targeted only for SharePoint development issues. If this is a capability question/discussion, please use the SharePoint TechCommunity.
If it is an issue is related to out-of-the-box capabilities of SharePoint or not related to SharePoint, we cannot process is through this channel. Please submit your finding using the Tenant administrator support channels in your tenant or using Premier support, if that’s available for you. Sorry for the inconvenience.


Still seem to be a lot of errors in swift 3.0 branch

I'm trying out the 3.0 swift branch, however there seem to be a lot of errors still

Did you figure out a way to make it work with swift 3?

coming coming 🚀


Exclude empty string as missing values in table specification?

@peterdesmet, see https://github.com/enram/vpts-csv/blob/main/vpts-csv-table-schema.json#L259, whereas this is not mentioned in the specs

@adokter preferred to express missing values as NA in the CSV files, see https://github.com/enram/vpts-csv/issues/23#issuecomment-1123960877.  I personally prefer empty values because it is more of a default and makes data files smaller. @adokter do you stick with your preference?
Note: if we stick with the current recommendation, I think that (existing) files that have coded it as empty strings should not fail validation. So I would therefore allow both, but recommend (therefore SHOULD not MUST) to use NA when producing VPTS CSV.

I stick with my preference but don't feel extremely strongly, as long as nodata and undetect values remain distinguishable, and get mapped in bioRad objects to old NA/NaN conventions for these two.

In that case I prefer to express nodata as empty values in CSV, as that sticks closer to conventions and is less verbose.
@adokter in R (default behaviour) both empty values and NA values are interpreted as NA (and "NaN" as NaN), so there is no issue there.
Using this test.csv:
# with read.csv
> read.csv("test.csv")
#              type value
# 1        undetect   NaN
# 2    nodata_as_NA    NA
# 3 nodata_as_empty    NA

# with readr
readr::read_csv("test.csv")
# A tibble: 3 × 2
#   type            value
#   <chr>           <dbl>
# 1 undetect          NaN
# 2 nodata_as_NA       NA
# 3 nodata_as_empty    NA

@stijnvanhoey I would then suggest to update the specs:

nodata values SHOULD be expressed as empty values.
But still leave "NA" in missingValues as a valid way to express those.

Updated in the standard:
https://github.com/enram/aloftdata.eu/blob/b3745dba08f7a17e3fa94ac5358a2f1bd2e1ee80/pages/vpts-csv.md?plain=1#L31-L34
missingValues remains the same (so NA as empty value is allowed, but not mentioned under SHOULD):
https://github.com/enram/vpts-csv/blob/1272c02df3913dfcd5138acd772dac8a1b194ff1/vpts-csv-table-schema.json#L258-L261


fix(disk/lsblk): support older lsblk without JSON mode, using --pairs

Cherry-picked from https://github.com/leptonai/gpud/pull/275.
Address https://github.com/leptonai/gpud/issues/272.
/cc @sunhailin-Leo

Cherry-picked from #275.
Address #272.
/cc @sunhailin-Leo

LGTM; 😄


Want to add a PANDAS cheatsheet.md in src/pages/sheet

@aryankashyap7 pls assign me this issue

Pandas cheatsheet is already added in the cheat list collection


Added support for FlatHash.com avatar images

RoboHash.org is great, but I had some feedback from someone that they were too playful (personally I think they're awesome). So I added FlatHash.com support for some less goofy images.

Current coverage is 94.42%

Merging #20 into master will not affect coverage as of 552b927

@@            master     #20   diff @@
======================================
  Files           16      16
  Stmts          269     269
  Branches        37      37
  Methods          0       0
======================================
  Hit            254     254
  Partial          7       7
  Missed           8       8

Review entire Coverage Diff as of 552b927

Powered by Codecov. Updated on successful CI builds.

Please give me a shout when this is merged. I'd like to grab the NuGet update! :) Thx!

hey, looks good. I'll need to make a few changes to make it a non-breaking release, then I'll push it to the build server (which will push it to nuget on success)

@jsauvexamarin the updated version has been pushed to the build server
and will be published to nuget when it suceeds.
You can check the status of the build, if it hasn't been published yet here: https://ci.appveyor.com/project/AdmiringWorm/faker-cs/build/<IP_ADDRESS>