Revise Editor

As of now, the editor is implemented with the help of a standalone instance of the Monaco Editor using an old very undesirable iframe. This needs to be done properly.
Either the project needs to be revised, so that Custom-MADE will use the

ReactJS-Monaco,
or we are going to replace Monaco by an entirely new approach like Sprotty, respectively recent research results developed by @rrcomtech.

@rrcomtech Did your recent search yield any new insights on how to display and transform circular graphs into ECore. Could we, thus, use your recent research results?

To put it short: yes, we can use cyclic graphs. This is achieved by using cross-references and adding support to the language server to handle those references.
The example language server with cross-reference handling, which could be generated by an M2-generator, is given under the following umbrella repository (links to a frontend project and the language server):
https://github.com/rrcomtech/Visualization_of_DSL_Families

@rrcomtech In which way does Theia recognise the approach of renaming mdr-dsl into any other arbitrary folder as a plugin to start?
Ref: We talked about introducing an abstraction that allows for using multiple languages with the Theia approach. Thus, the folder will be named something unknown atm.

The folder mdr-dsl, which is a Theia extension, is referenced by the actual browser application. The application is located in the browser-app folder and identified by the package.json. There you will find an entry containing the name(s) of the Theia extension(s), which includes mdr-dsl. So to rename the folder of a Theia extension, simply change the folder name and the entry in the browser-app/package.json.
New Theia extensions are added in a similar way.
To add more languages to Theia, one should copy the folder template (formerly named mdr-dsl) and apply the necessary domain-specific changes (path to language server, file extension, ...). Finally add the new folder name to the list of Theia extensions in browser-app/package.json.
Visualization support is included, if the mdr-dsl template is used. For that it heavily relies on mdr-sprotty.

@rrcomtech please see the pull request #34


Made a custom attribute for rotateOrder to store a default value in a controller. #328

https://github.com/mgear-dev/mgear4/issues/328
Here is the reported issue in the forum.
http://forum.mgear-framework.com/t/mgear-viewport-menu-resets-the-rotarte-order-always-to-xyz/3574

@joji2468ng  I am very sorry, I didn't expect you will jump on this so fast!  But the solution provided will break back compatibility with all the previously generated rigs.

My idea was to add a new attr to store the default rot order as metadata, and later update the reset tools to use it if the control has it.
That will keep the improvement hidden from the user and compatible with old rigs and ongoing productions that want to update to the latest mgear.
In general, a solution that needs to update all the components should be the last option.
I feel terrible to not merge this after all your hard work, but I can't 🙇

Thank you for the feedback, I will follow your idea and fix it with metadata!

Thanks @joji2468ng
Before start will be good to prepare a little bullet list with the parts that we want to change, before committing any change 🙏
Just to be sure. I don't want to waste your time 🙇


Typescript client - generated parameter not typed as array for dictionary query params

I am raising this as it follow on from https://github.com/RicoSuter/NSwag/issues/3529, which I have determined in slightly different.
I'm trying to define a swagger file that will allow for URLs for in the following format
?filter[aField]=value&filter[otherField]=otherValue
I have worked out that the following swagger definition allows Swagger.UI to process the inputs properly, and create the correct URL
            "name": "filter",
            "in": "query",
            "style": "deepObject",
            "schema": {
              "type": "object",
              "additionalProperties": {
				  "type": "string"
				},
            }

The deepObject property is required for Swagger.UI to work correctly.
This nicely produces the typescript method definition of
filter: { [key: string]: string; } | undefined
However, the code to parse this query parameter is just defined as
url_ += "filter=" + encodeURIComponent("" + filter) + "&"
This is not how a dictionary for a query parameter. At least not a deepObject type. I think the following code would be required in Client.RequestUrl.liquid to replicate the desired approach
{%     elseif parameter.IsDictionary && parameter.IsDeepObject -%}
	for (let key in {{ parameter.VariableName }}) {
		if (Object.prototype.hasOwnProperty.call({{ parameter.VariableName }}, key)) {
			url_ += "{{ parameter.Name }}[" + key + "]=" + encodeURIComponent("" + {{ parameter.VariableName }}[key]) + "&";
		}
	};

Was there any work on this?
The C# generator has the same problem it recognises the parameter as Dictionary and ends using this:
{% elsif parameter.IsDictionary -%}
foreach (var item_ in {{ parameter.VariableName }}) { urlBuilder_.Append(System.Uri.EscapeDataString(item_.Key) + "=").Append(System.Uri.EscapeDataString(ConvertToString(item_.Value, System.Globalization.CultureInfo.InvariantCulture))).Append("&"); }

What would work is the modified lined used from the IsDeepObject segment:
{% elseif parameter.IsDictionary && parameter.IsDeepObject -%}
foreach (var item_ in {{ parameter.VariableName }}) {
    urlBuilder_.Append(System.Uri.EscapeDataString("{{parameter.Name}}[{{item_.Key}}]") + "=").Append(System.Uri.EscapeDataString(ConvertToString(item_.Value, System.Globalization.CultureInfo.InvariantCulture))).Append("&"); }
}


Add Italian translation

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines.
[ ] Tests for the changes have been added (for bug fixes / features).
[ ] Docs have been added / updated (for bug fixes / features).

PR Type
What kind of change does this PR introduce?

[ ] Bugfix.
[ ] Feature.
[ ] Code style update (formatting, local variables).
[ ] Refactoring (no functional changes, no api changes).
[ ] Build related changes.
[ ] CI related changes.
[ ] Documentation content changes.
[x] New translation

What is the current behavior?

Issue Number(s): N/A
What is the new behavior?
Add Italian language support
How to use?
In NexT _config.yml:
...

Does this PR introduce a breaking change?

[ ] Yes.
[x] No.

OMG stop it :)

Sorry, I think I'm pretty done with this one :D Adapting Next to my blog had some requirements :P

U can make big pull with all changes. It can be find as Big pull request template in PULL_REQUEST_TEMPLATE: just comment standart template and uncomment big template with <!-- -->. See example of big pulls there (Fixes and enhancements. [XX]).

Ah ok, well, I usually prefer to split PR in small chunks anyway. Much easier to review them :D
But If I annoy with this attitude, I'll go for big PR next time :) Thanks!

I usually do small PR's, but something big templates looks better and easy to edit errors i think. U can do templates any u want, but see on big template — mb it will better for u, who knows.


Add remove support for storages

Closes #230
TODO

[ ] Update docs
[x] Add changelog

We can skip documentation for this method as we do not have any documentation for the storage API


Braces around author last name when exporting BibTeX

Hi,
when exporting references as BibTeX, authors' last names (1) are surrounded by brackets. This causes a problem with sorting names with non-dropping particles, such as van Gogh (which should be sorted in the G), and also when trying to capitalize the particle (as in the beginning of a sentence) (2).
(1) author = {{Sturt}, Patrick},
author = {{van Gogh}, Vincent},
(2) \Citet{vangogh}  gives  "angoghVANGOGH (1888)"
I have updated to the last version (1.6.75) and tried several solutions proposed in issues #353 and #348, but the problem persists. Is there a way to change this way of exporting to BibTeX? (This didn't happened a few months ago, and I have noticed the exporter to BibLaTeX does not have the same issue).
Thanks!
Report ID: JZFA2GPA

@nickbart1980, any thoughts on this matter?

Standard disclaimer and warning: I don’t use BibTeX myself, and https://ctan.org/pkg/bibtex advises: “In fact, it is best to avoid BibTeX in favour of biber and BibLaTeX, if at all possible.”
As to sorting, BibTeX seems too inflexible. (BibLaTeX is more capable.) AFAICT, in BibTeX you can either keep van and Gogh together, or sort by Gogh, but not both. For the latter, use [Gogh][Vincent van] in Zotero.
I can also reproduce the capitalisation issue (see https://www.sharelatex.com/project/57f0c653164f26ac79654c20). This, it seems, is a natbib bug, since Yoyodyne Inc., a corporate name, is affected, too – and at least for corporate names, wrapping the name in braces is not a BBT peculiarity but has always been the recommended solution (see https://tex.stackexchange.com/questions/10808/using-a-corporate-author-in-the-author-field-of-a-bibliographic-entry-spell).
Hence I don’t think either of the two is a really a BBT issue at all.
So I’d say, best report this to natbib and/or consult TSE for possible workarounds.

@sanmame NM, turning of particle-handling causes the last name to be wrapped. Looking into that.

@retorquere Oh, sorry, I submitted a different author with a single last name. I believe it was [Kennedy] [Christopher], which results in
author = {{Kennedy}, Christopher},
Yes, as @nickbart1980 says, this only happens for one-word last names when `Move name-particles (de, von, ...) to the family name' is disabled.
The problem with sorting and capitalization of non-dropping particle surnames disappear when I manually take the brackets off the last name. For what you I've understood, the way BBT deals with name particles is by wrapping multiple-word last names. If turning off particle-handling didn't add any braces in any name, the issue would be solved.
@nickbart1980 Thanks, I'm planning to change to BibLaTeX, but I'm too far into my dissertation to make the change now, so I'd prefer to stick with BibTeX. I solved the sorting problem for non-dropping particle names by adjusting the rule for sorting in the bibliography style, so that works for now.
Thanks for looking into it!

I have tests running on a version that usually will not add braces around a last name when particle parsing is off. The exception is if the last name contains a space, comma, or the word and.

@nickbart1980 {Macedo, Agostinho José da Costa de} should be fine without a braced lastname yeah?

@nickbart1980 is bracing for lastnames with a space too eager? Is testing for comma and and sufficient?

https://github.com/retorquere/zotero-better-bibtex/releases/download/builds/zotero-better-bibtex-1.6.75-circle-2896.xpi will already leave alone [Kennedy] [Christopher], but will still brace [von Fintel][Kai]. Awaiting feedback from @nickbart1980 on that -- I really don't have a deep understanding of Bib(La)TeX, and @nickbart1980 knows a lot of edge cases I don't.

First, citeproc-js parses Zotero two-fields names, e.g., [van Last] [First von, Jr.] as follows: leading lowercase words in the first field as non-dropping particles (here, van), and lowercase trailing words in the second field (after removing any suffixes, i.e., stuff after a comma) as dropping particles (here, von). Quotes (["van Last"]) can be used to parse the whole first field as a last name, i.e., no particle involved. Also note that, to the best of the whole Zotero/CSL/citeproc-js communities’ knowledge, dropping and non-dropping particles never seem to co-occur.
BBT should of course try to emulate citeproc-js’s parsing behaviour. Problems: bibtex cannot distinguish dropping and non-dropping particles at all. Hence, for bibtex (not biblatex!) treating a non-dropping particle as a fixed part of the last name is arguably the least bad option. (biblatex can, sort of, distinguish DP and NDP via the useprefix option, but only for a complete list of authors, not individually. The present issue is not about biblatex, however – right?)
I’d say, for bibtex

[van Last][First] should always be mapped to bibtex author={{van Last}, First}, typically rendered as “van Last, First” (as mentioned above, given the limitations of bibtex, treating a non-dropping particle as a fixed part of the last name is arguably the least bad option).

["van Last"][First] should definitely be mapped to bibtex author={{van Last}, First} (biblatex, too, BTW).

[Last][First von] should without exception be mapped to bibtex author={von Last, First} (in bibtex, prefixes come always before Last, never after First), typically rendered as “Last, First von”.

Hence I’m not even sure whether we’d ever need a BBT option Move name-particles (de, von, …) to the family name at all.
@retorquere’s questions:

[Gogh][Vincent van] should always produce author={van Gogh, Vincent} (no braces, and never author={Gogh, Vincent van} – in bibtex, prefixes come always before Last, never after First)

author={Macedo, Agostinho José da Costa de} is fine.

“… is bracing for lastnames with a space too eager? Is testing for comma and and sufficient?” – Not sure I understand: if Zotero’s [Last] fields contain , or and at all (not too likely) these are certainly not supposed to be parsed as (field?) separators – they should be left alone. (A , or ,! in [First] are a different story and separate the genuine First (plus possibly a dropping particle) from the suffix.)

“will already leave alone [Kennedy] [Christopher], but will still brace [von Fintel][Kai].” – Fine.

BBT should of course try to emulate citeproc-js’s parsing behaviour.

BBT in fact uses the citeproc particle parser

The present issue is not about biblatex, however – right?)

Right.

I’d say, for bibtex

[van Last][First] should always be mapped to bibtex author={{van Last}, First}, typically rendered as “van Last, First” (as mentioned above, given the limitations of bibtex, treating a non-dropping particle as a fixed part of the last name is arguably the least bad option).

I think that's the current behavior if parseparticles is on (which is the default). {van Last, First} also renders as “van Last, First” right?

["van Last"][First] should definitely be mapped to bibtex author={{van Last}, First} (biblatex, too, BTW).

I have to look into this but I think that's also the current behavior.

[Last][First von] should without exception be mapped to bibtex author={von Last, First} (in bibtex, prefixes come always before Last, never after First), typically rendered as “Last, First von”.

Hence I’m not even sure whether we’d ever need a BBT option Move name-particles (de, von, …) to the family name at all.

I think that came about from #411

[Gogh][Vincent van] should always produce author={van Gogh, Vincent} (no braces, and never author={Gogh, Vincent van} – in bibtex, prefixes come always before Last, never after First)

OK, that's something I'll have to fix.

author={Macedo, Agostinho José da Costa de} is fine.
EDIT: Wait, assuming this comes from [Macedo][Agostinho José da Costa de], it should be author={de Macedo, Agostinho José da Costa}

That's specifically in response to #411

“… is bracing for lastnames with a space too eager? Is testing for comma and and sufficient?” – Not sure I understand: if Zotero’s [Last] fields contain , or and at all (not too likely) these are certainly not supposed to be parsed as (field?) separators – they should be left alone. (A , or ,! in [First] are a different story and separate the genuine First (plus possibly a dropping particle) from the suffix.)

That's really just an artifact of how I treated non-particle-parsed names. I agree it's not likely. The #411-inspired behavior may need work.

After some adjustments, this is what I get with particle parsing on:
[van Gogh][Vincent] => {{van Gogh}, Vincent}
[Humboldt][Alexander von] => {von Humboldt, Alexander}
[Beauvoir][Simone de] => {de Beauvoir, Simone}
["de Gaulle"][Charles] => {{de Gaulle}, Charles}
[King][Martin Luther, Jr.] => {King, Jr., Martin Luther}
[Stevenson][Adlai E.,! III] => {Stevenson, III, Adlai E.}
[boven d'Eert][Christianus] => {{boven d'Eert}, Christianus}
['s-Gravesande][Goverdus] => {'s-Gravesande, Goverdus}
[De Quincey][Thomas] => {{De Quincey}, Thomas}
[Ortega y Gasset][José] => {{Ortega y Gasset}, Jos{\'e}}
[D’Amato][Alfonse] => {D'Amato, Alfonse}
[Sadat][Anwar el-] => {el-Sadat, Anwar}
[La Follette][Robert M., Sr.] => {{La Follette}, Sr., Robert M.}
["de la Mare"][Walter] => {{de la Mare}, Walter}
[DeGette][Diana] => {DeGette, Diana}
[Saunders][John Bertrand de Cusance Morant] => {Saunders, John Bertrand de Cusance Morant}
[Dumas][Alexandre, père] => {Dumas, p{\`e}re, Alexandre}
[Van Rensselaer][Stephen] => {{Van Rensselaer}, Stephen}
[L’Enfant][Pierre-Charles] => {L'Enfant, Pierre-Charles}
["van Gulik"][Robert] => {{van Gulik}, Robert}
[Sackville-West][Victoria] => {Sackville-West, Victoria}
[Vaughan Williams][Ralph] => {{Vaughan Williams}, Ralph}
[Mies van der Rohe][Ludwig] => {{Mies van der Rohe}, Ludwig}
[d’Alembert][Jean le Rond] => {d'Alembert, Jean le Rond}
[Tocqueville][Alexis de] => {de Tocqueville, Alexis}
[La Fontaine][Jean de] => {de {La Fontaine}, Jean}
[La Salle][René-Robert Cavelier de] => {de {La Salle}, Ren{\'e}-Robert Cavelier}
[du Puy de Clinchamps][Philippe] => {{du Puy de Clinchamps}, {\relax Ph}ilippe}
[Stein][Heinrich Friedrich Karl vom und zum] => {vom und zum Stein, Heinrich Friedrich Karl}
[Silva][Agostinho da] => {da Silva, Agostinho}
["da Gama"][Vasco] => {{da Gama}, Vasco}
[D’Annunzio][Gabriele] => {D'Annunzio, Gabriele}
[Da Ponte][Lorenzo] => {{Da Ponte}, Lorenzo}
[Della Robbia][Luca] => {{Della Robbia}, Luca}
[Este][Beatrice d’] => {d'Este, Beatrice}
[Medici][Lorenzo de’] => {de'\hspace{0pt} Medici, Lorenzo}
[al-Hakim][Tawfiq] => {al-Hakim, Tawfiq}
[Le Vayer][François de La Mothe] => {{Le Vayer}, Fran{\c c}ois de La Mothe}

Curious about references like Da Ponte -- it doesn't have an NDP, should it be braced, or should or just be {Da Ponte, Lorenzo}? And it looks like the Citeproc particle parser is picking up père as a suffix rather than a title.
and these if I turn particle parsing off:
{Humboldt, Alexander von}
{Beauvoir, Simone de}
{King, Martin Luther, Jr.}
{Stevenson, Adlai E., III}
{Sadat, Anwar el-}
{{La Follette}, Robert M., Sr.}
{Dumas, Alexandre, p{\`e}re}
{Tocqueville, Alexis de}
{{La Fontaine}, Jean de}
{{La Salle}, Ren{\'e}-Robert Cavelier de}
{Stein, Heinrich Friedrich Karl vom und zum}
{Silva, Agostinho da}
{Este, Beatrice d'}
{Medici, Lorenzo de'\hspace{0pt}}

As you can see turning off particle parsing doesn't uniformly solve #411. Perhaps for that I should still parse particles but just stuff them on the firstname in DP NDP order.

Just leaving the NDP at the end of the name but still putting the suffix right (in an attempt to address #411, if in fact the solution requested there is a proper solution) would get me:
{Humboldt, Alexander von}
{Beauvoir, Simone de}
{Sadat, Anwar el-}
{Tocqueville, Alexis de}
{{La Fontaine}, Jean de}
{{La Salle}, Ren{\'e}-Robert Cavelier de}
{Stein, Heinrich Friedrich Karl vom und zum}
{Silva, Agostinho da}
{Este, Beatrice d'}
{Medici, Lorenzo de'\hspace{0pt}}

The following all look ok:
["da Gama"][Vasco] => {{da Gama}, Vasco}
["de Gaulle"][Charles] => {{de Gaulle}, Charles}
["de la Mare"][Walter] => {{de la Mare}, Walter}
["van Gulik"][Robert] => {{van Gulik}, Robert}
[Beauvoir][Simone de] => {de Beauvoir, Simone}
[boven d'Eert][Christianus] => {{boven d'Eert}, Christianus}
[d’Alembert][Jean le Rond] => {d'Alembert, Jean le Rond}
[D’Amato][Alfonse] => {D'Amato, Alfonse}
[D’Annunzio][Gabriele] => {D'Annunzio, Gabriele}
[DeGette][Diana] => {DeGette, Diana}
[du Puy de Clinchamps][Ph�ilippe] => {{du Puy de Clinchamps}, {\relax Ph}ilippe}
[Dumas][Alexandre, père] => {Dumas, p{\`e}re, Alexandre}
[Este][Beatrice d’] => {d'Este, Beatrice}
[Humboldt][Alexander von] => {von Humboldt, Alexander}
[King][Martin Luther, Jr.] => {King, Jr., Martin Luther}
[L’Enfant][Pierre-Charles] => {L'Enfant, Pierre-Charles}
[Medici][Lorenzo de’] => {de'\hspace{0pt} Medici, Lorenzo}
[Ortega y Gasset][José] => {{Ortega y Gasset}, Jos{\'e}}
[Sackville-West][Victoria] => {Sackville-West, Victoria}
[Saunders][John Bertrand de Cusance Morant] => {Saunders, John Bertrand de Cusance Morant}
[Silva][Agostinho da] => {da Silva, Agostinho}
[Stein][Heinrich Friedrich Karl vom und zum] => {vom und zum Stein, Heinrich Friedrich Karl}
[Stevenson][Adlai E.,! III] => {Stevenson, III, Adlai E.}
[Tocqueville][Alexis de] => {de Tocqueville, Alexis}
[van Gogh][Vincent] => {{van Gogh}, Vincent}

The next group does not need any extra braces:
[Da Ponte][Lorenzo] => {{Da Ponte}, Lorenzo}
[De Quincey][Thomas] => {{De Quincey}, Thomas}
[Della Robbia][Luca] => {{Della Robbia}, Luca}
[La Follette][Robert M., Sr.] => {{La Follette}, Sr., Robert M.}
[La Fontaine][Jean de] => {de {La Fontaine}, Jean}
[La Salle][René-Robert Cavelier de] => {de {La Salle}, Ren{\'e}-Robert Cavelier}
[Le Vayer][François de La Mothe] => {{Le Vayer}, Fran{\c c}ois de La Mothe}
[Mies van der Rohe][Ludwig] => {{Mies van der Rohe}, Ludwig}
[Van Rensselaer][Stephen] => {{Van Rensselaer}, Stephen}
[Vaughan Williams][Ralph] => {{Vaughan Williams}, Ralph}

The following ones seem to need the extra braces, or else the hyphen disappears when rendered with latex/natbib (see https://www.sharelatex.com/project/57f0c653164f26ac79654c20) – might need further research:
['s-Gravesande][Goverdus] => {'s-Gravesande, Goverdus}
[al-Hakim][Tawfiq] => {al-Hakim, Tawfiq}
[Sadat][Anwar el-] => {el-Sadat, Anwar}

As to “turning particle parsing off” I'm afraid I don't think this is a good idea at all – the result just does not conform to bibtex standards, however loose you might interpret them.
From Patashnik, Oren. 1988. “BibTeXing.” http://mirrors.ctan.org/biblio/bibtex/base/btxdoc.pdf:

To summarize, BibTEX allows three possible forms for the name:
"First von Last"
"von Last, First"
"von Last, Jr, First"
You may almost always use the first form; you shouldn’t if either there’s a Jr part, or the Last part has multiple tokens but there’s no von part.

Again, none of the names from the two “particle parsing off” lists conforms to these standards, so no bibtex processor (bibtex, biber, …) will parse these correctly. If the output looks ok, that's just a conincidence.
(Of course I know what motivated this modification: It was trying to get display and sorting right ["Doe, John von", sorted under "D" rather than von Doe, John", sorted under "V"] in the absence of any suitable bibtex styles. Still, the solution would be to fix the styles (or switch to biblatex), not disregarding the stardards.)

When I apply the rule "add braces when a non-dropping particle is present", my list almost equals yours+corrections, but I'm left with {Ortega y Gasset, Jos{\'e}} which wouldn't get braces because there's no NDP, and {al-Hakim, Tawfiq}, because the CSL particle parser thinks there's no NDP.
These would all get braces because there's an NDP:
{{'s-Gravesande}, Goverdus}
{{al-Hakim}, Tawfiq}
{{d'Alembert}, Jean le Rond}

WRT #411, is sortname that could be sensibly used? Do you have an idea (an MWE if you have the time & inclination) of how this could be achieved even if some extra LaTeX code would be involved?
@danilomm, #411 concerns a request you put in, could you join the discussion?

(@danilomm this is relevant because if the option to turn off particle parsing is off-spec it becomes candidate for removal)

Just for completeness, this is what is currently exported for BibLaTeX for these references:
[van Gogh][Vincent] => {van Gogh, Vincent}
[Humboldt][Alexander von] => {von Humboldt, Alexander}
[Beauvoir][Simone de] => {de Beauvoir, Simone}
["de Gaulle"][Charles] => {{de Gaulle}, Charles}
[King][Martin Luther, Jr.] => {King, Jr., Martin Luther}
[Stevenson][Adlai E.,! III] => {Stevenson, III, Adlai E.}
[[National Aeronautics and Space Administration]] => {{National Aeronautics and Space Administration}}
[boven d'Eert][Christianus] => {boven d' Eert, Christianus}
['s-Gravesande][Goverdus] => {'s- Gravesande, Goverdus}
[De Quincey][Thomas] => {De Quincey, Thomas}
[Ortega y Gasset][José] => {Ortega y Gasset, José}
[D’Amato][Alfonse] => {D’Amato, Alfonse}
[Sadat][Anwar el-] => {el- Sadat, Anwar}
[La Follette][Robert M., Sr.] => {La Follette, Sr., Robert M.}
["de la Mare"][Walter] => {{de la Mare}, Walter}
[DeGette][Diana] => {DeGette, Diana}
[Saunders][John Bertrand de Cusance Morant] => {Saunders, John Bertrand de Cusance Morant}
[[Marcus Aurelius]] => {{Marcus Aurelius}}
[Dumas][Alexandre, père] => {Dumas, père, Alexandre}
[Van Rensselaer][Stephen] => {Van Rensselaer, Stephen}
[L’Enfant][Pierre-Charles] => {L’Enfant, Pierre-Charles}
["van Gulik"][Robert] => {{van Gulik}, Robert}
[Sackville-West][Victoria] => {Sackville-West, Victoria}
[Vaughan Williams][Ralph] => {Vaughan Williams, Ralph}
[Mies van der Rohe][Ludwig] => {Mies van der Rohe, Ludwig}
[d’Alembert][Jean le Rond] => {d’ Alembert, Jean le Rond}
[Tocqueville][Alexis de] => {de Tocqueville, Alexis}
[La Fontaine][Jean de] => {de La Fontaine, Jean}
[La Salle][René-Robert Cavelier de] => {de La Salle, René-Robert Cavelier}
[du Puy de Clinchamps][Philippe] => {du Puy de Clinchamps, {\relax Ph}ilippe}
[Stein][Heinrich Friedrich Karl vom und zum] => {vom und zum Stein, Heinrich Friedrich Karl}
[Silva][Agostinho da] => {da Silva, Agostinho}
["da Gama"][Vasco] => {{da Gama}, Vasco}
[D’Annunzio][Gabriele] => {D’Annunzio, Gabriele}
[Da Ponte][Lorenzo] => {Da Ponte, Lorenzo}
[Della Robbia][Luca] => {Della Robbia, Luca}
[Este][Beatrice d’] => {d’ Este, Beatrice}
[Medici][Lorenzo de’] => {de’ Medici, Lorenzo}
[al-Hakim][Tawfiq] => {al- Hakim, Tawfiq}
[Le Vayer][François de La Mothe] => {Le Vayer, François de La Mothe}

of which
{d’ Este, Beatrice}
{de’ Medici, Lorenzo}
{al- Hakim, Tawfiq}

at least look wrong to me.

I'm looking back at https://github.com/retorquere/zotero-better-bibtex/issues/384#issuecomment-152018315, and there you say "anything with a space needs braces". Change of insight?

Oh wait, you later say "anything that starts with a lowercase letter", but also "just brace  the lot" (https://github.com/retorquere/zotero-better-bibtex/issues/384#issuecomment-153413361).

as an aside, I don't believe for a second that any reference manager that isn't Bib(La)TeX native comes even close to what BBT can output, and that in large part thanks to feedback from @nickbart1980 et al and reports like those from @sanmame and @danilomm -- so thanks for that guys(?)

I'm losing the whole picture here -- @nickbart1980, could you edit the BibTeX and the BibLaTeX for these references to have the correct author field? I have added the input from Zotero in a note field in those files, please don't edit that field, it's just for ease of reference.

Also, assuming @danilomm from #411 uses BibLaTeX, how would the desired name-sorting be achieved there? And is there still really a difference between BibTeX and BibLaTeX output when it comes to name handling besides the BibTeX exporter adding \relax after particles ending in punctuation?

I trick I sometimes see on TSE is to add (configurably of course) the non-particled last name as a no-op to force sorting, something like
author = {\noop{Macedo}de Macedo, Agostinho José da Costa}

would this work? And would \vphantom{...} be a viable \noop{...}? Or is sortkey an option here?

Ok, let me start with the first questions I haven't answered yet:

{Ortega y Gasset, Jos{\'e}}: my mistake; doesn't actually need braces.

“{al-Hakim, Tawfiq}, because the CSL particle parser thinks there's no NDP.” – Really? I would have thought the the citeproc-js particle parser should find an NDP here. Anyway, I used to recommend bracing al-Hakim, or else bibtex doesn't render the hyphen. Might need further consideration, too.

I’ll need some time for the other questions …

The space between al- and Hakim was my doing -- the csl parser correctly identified al- as an NDP, but I was under the impression from #384 that for BibLaTeX a space was always needed after a particle even when the particle ends in punctuation, but that doesn't render sensibly for me here. Test file for BibLaTeX has been updated accordingly, but feel free to change the author field where you see fit. For BibTeX the name including NDP is braced, for BibLaTeX currently not (as reflected in the current test files)

For biblatex, the space between al- and Hakim (and between any other prefix that ends with punctuation and Last) is needed, plus \DeclarePrefChars{'’-} in your preamble.  Without this command, {al- Hakim} will indeed not render sensibly, i.e., the space will not be removed – that’s what you saw, right?
biblatex manual:

\DeclarePrefChars{<characters>}
This command declares characters that are to be treated specially when testing to see if \bibnamedelimc is to be inserted between a name prefix and a family name. If a character is in the list of <characters>, \bibnamedelimc is not inserted. It is used to allow abbreviated name prefices like ‘d’Argent’ where no space should be inserted after the apostrophe. The default setting is: \DeclarePrefChars{'}

… so you will need to add the smart apo and the hyphen to the list yourself.
For ghastly details, see https://github.com/plk/biblatex/issues/346.

That's what I saw, indeed. I take it there's no (safe) way to add the DeclarePrefChars to the generated biblatex? I mean when you say "yourself" you mean the LaTeX author, not @retorquere?
That's some piece of work that thread of biblatex. Test files have been adjusted to have the space back.

“… when you say "yourself" you mean the LaTeX author …” – Yes.
“I take it there's no (safe) way to add the DeclarePrefChars to the generated biblatex?” – I’m not aware of any. I tried adding @preamble{ \DeclarePrefChars{'’-} } to the beginning of a biblatex file, but only got an error message back: syntax error: found "{'â-}", expected end of entry ("}" or ")") (skipping to next "@"). Any ideas on this?

How about something like @preamble { "\DeclarePrefChars{'’-}" }? I see some use this format. I had forgotten about @preamble -- certainly BibTeX ought to recognize it. The BibLaTeX manual makes no mention of it, but TSE seems to approve, and plk seems to think it should work.

My LaTeX-foo isn't particularly spectacular, but if I read aforementioned ghastly details it looks like \DeclarePrefChars isn't cumulative, correct? \DeclarePrefChars{'}\DeclarePrefChars{-} is equivalent to \DeclarePrefChars{-}?

OK, @PREAMBLE{ "\DeclarePrefChars{'’-}" } seems to do the trick (i.e., latex output is “al-Hakim” rather than “al- Hakim”).
(And, no,  \DeclarePrefChars does not seem to be cumulative.)

The biblatex export now has the preamble, and the corresponding test file has been updated.

@nickbart1980, the updated test files are here: BibTeX and BibLaTeX.

I'm trying to figure out whether #411 is about sorting (display van Gogh under G) or sort+display (display Gogh, van under G). And whether either of those is achievable under BibTeX and BibLaTeX. Thoughts?

@sanmame the fix I have lined up only partially addresses your case; simple names like Sturt will work as you want, but we're still sussing out how to get \Citet to work with multi-part names with particles, assuming it can be done at all.

I'm trying to figure out whether #411 is about sorting (display van Gogh under G) or sort+display (display Gogh, van under G). And whether either of those is achievable under BibTeX and BibLaTeX. Thoughts?

display-and-sort, I’d say. Easy in biblatex, which has a sensible default of useprefix=false.  Difficult in bibtex, in particular since there seem to be next to no official styles that do display-and-sort (collected complaints from 1999: https://groups.google.com/forum/#!topic/comp.text.tex/pQCPH3fwGSE).
Custom styles doing “sort-only” can be generated with latex makebst; custom styles doing “display-and-sort” could be crafted following the instructions in https://groups.google.com/forum/#!msg/comp.text.tex/-rqV6aig14c/smHVXULxZS4J.
Anyway, constructs like author = {Oliveira, Maria Manuel Lobo Pinto de} as suggested in #411 are not syntactically correct in bibtex, and I don't feel BBT should support them. We'd better try to provide hints, where necessary, how to create custom styles.

I see that that thread also mentions the noop trick.

A prelim test with the noops for bibtex is here

Well, I’d rather use \noopsort, as recommended by Patashnik (1988) himself, even if this needs to be defined in the @preamble – less surprising, and easier to discover for users who come across \noopsort and are unsure what it does.
Also, I’d limit the use of \noopsort to the case where BBT converts a CSL non-dropping particle to a fixed part of a bibtex last name, i.e. “van Gogh” and friends – possibly as an option (some might still prefer to have it sorted under “V”).
For “von Humboldt”, “de Oliveira” and the like, there’s no sensible way around fixing broken bibtex styles if users want/need to follow the European traditions of dropping the “dropping” particles (i.e., “Humboldt” in text, and “Humboldt, Alexander von” in the reference list – also prescribed by the Chicago Manual of Style, BTW, see 16e, 8.7–8.9 and 8.11). This would obviously take care of sorting in those cases, too. So \noopsort would only provide a benefit here with broken styles (for the sorting), but unnecessary clutter with styles that drop “dropping” particles.
IMHO, this is all BBT can (and should) do. @sanmame (#565) and @danilomm (#411) will now still have to contact the style authors (actually I don’t even know which style(s) they have been using …) or TSE to get their .bst styles fixed – quoting the Chicago Manual plus the comments on broken bibtex styles and these instructions if necessary.
(Please don’t ask me, I don’t hack .bst styles anymore, sorry. – My point of view, again, is: “In fact, it is best to avoid BibTeX in favour of biber and BibLaTeX, if at all possible.”)

Well, I’d rather use \noopsort, as recommended by Patashnik (1988) himself, even if this needs to be defined in the @preamble – less surprising, and easier to discover for users who come across \noopsort and are unsure what it does.

The reason I was thinking \vphantom is that it would not have the potential for conflicts. Not likely of course that a user should have defined \noopsort, but if there's a conflict-free option that sounds appealing to me. It's going to go behind an option in any case.

Also, I’d limit the use of \noopsort to the case where BBT converts a CSL non-dropping particle to a fixed part of a bibtex last name, i.e. “van Gogh” and friends – possibly as an option (some might still prefer to have it sorted under “V”).

That is the case right now on the branch I'm working on it. It's an option, off by default. I may make it an export option rather than a global option at some point, but that requires more work, and I have my hands full with the 5.0 port I should really get started on.

So \noopsort would only provide a benefit here with broken styles (for the sorting), but unnecessary clutter with styles that drop “dropping” particles.

Ugh. Nice.

(the `noopsort stuff aside, are the current testfiles OK as far as you could tell?)

Not quite:
bibtex
s/\relax{}/\relax /g
s/note = {[Medici][Lorenzo de'\hspace{0pt}]}/note = {[Medici][Lorenzo de']}/g (zero-width space after de’)
biblatex
s/author = {de’ Medici, Lorenzo}/author = {de’\mbox{} Medici, Lorenzo}/  (\hspace{0pt} didn’t work as expected when testing with biber 2.6/biblatex 3.5)

There's a difference between \relax{}... and \relax ...?
I've updated the relax bits in the test files, but I don't understand the 2nd comment? Or do you mean that the note field doesn't have the actual ZWS? That'd be correct, as BBT has been set to translate to LaTeX constructs for that run, I can't do that on a field-by-field basis.
On the 3rd comment, should that have read s/author = {de’\hspace{0pt} Medici, Lorenzo}/author = {de’\mbox{} Medici, Lorenzo}/? I take it it should have and have made that change in the test files.

What about #69 when it comes to space over {}?

“There's a difference between \relax{}... and \relax ...?” – We need an actual space for parsing, so blah\relax{}blah will not do (blah\relax{} blah would but we don't need the {}).

You wouldn't put latex commands as in [Medici][Lorenzo de'\hspace{0pt}] into Zotero fields, would you?

FWIW, author = {de’ Medici, Lorenzo} is what I saw ...

Happy to oblige, but who's "we"? And the \relax bits were only for BibTeX right, not BibLaTeX?
No, the Zotero source has [Medici][Lorenzo de<ZWS>] in the note field, but when I export that, it get's translated into \hspace (or soon \mbox). The field is just for reference, if you want to know what's actually input you'd need to look at the reference source
In the BibTeX file (that'd be odd) or in the biblatex file (that looks to be correct but there is a ZWS after the ' but it doesn't show of course. Are you saying a ZWS should be expanded even for BibLaTeX?

I used to settle on {} rather than a space to separate commands because of #69 and the fact that I generate the LaTeX char-for-char, and something like x<XWS><space>y means different things when exported as x\mbox<space><space>y and x\mbox{}<space>y.

OK, test files have been updated (and tests run green against them). I've opted for \relax{} if that's all the same otherwise -- it's the easiest for me to generate without having to build in hard-wired exceptions to the Unicode -> LaTeX converter.

Updates test files again for:

BibLaTeX
BibTeX
BibTeX with noopsort

(for things that need change, please indicate which of the three it concerns)

Dear @retorquere ,
I'm sorry for the delay in joining the discussion.
I guess that in some point it became too technical to me. In the end, did the change affect the previous behavior or not?

Ok, to recap: For bibtex (not biblatex) #411 is a complaint about dropping particles (DP) not being dropped, and #565 is one about non-dropping particles (NDP) not being demoted when sorting.
Given the limitations of bibtex, this is what can be done on the BBT side (.bst styles will also have to be fixed):

map CSL DP to regular bibtex prefix

if prefix ends with punctuation, insert \relax<SPACE> between prefix and Last

map CSL NDP plus CSL Last to one multi-part bibtex Last, wrapped in braces as {NDP Last}

if prefix ends with punctuation, do not insert space between prefix and Last
optionally, prepend {\noopsort{last}}

without noopsort, behaviour matches CSL’s “demote-NDP: never”
with noopsort,    behaviour matches CSL’s “demote-NDP: sort-only”
(note that bibtex cannot emulate CSL’s “demote-NDP: display-and-sort”, but this seems to be the least frequently used variant anyway)

Now, I don’t know why the actual bibtex diehards haven’t been doing this all along, but I’ve tried to set up a rudimentary testbed for BibTeX and BibTeX with noopsort at https://www.sharelatex.com/project/57f75dae51d67edf7b912fc2. Feel free to try this out
This uses either plain.bst (to check whether “John van Doe” comes out right) or a crude hack of chicago.bst, called mychicago2.bst (to check the “Doe, John van” form, and sorting).
Maybe something similar could be included into the BBT tests, and the pdfs made available? Visual inspection of the formatted latex output is the most meaningful test after all.
Results:

\relax{}<SPACE> does not work, it has to be \relax<SPACE>

Hufflen (2006) recommends {\aftergroup\ignorespaces}<SPACE> instead (if that’s easier for BBT than \relax<SPACE>)

multipart Lasts containing lowercase words (“Mies van der Rohe”) need to be wrapped in braces (unlike biblatex!)
no protection needed after punctuation that should be followed by space (“de'” in “de' Medici, Lorenzo”) (unlike biblatex!)
\noopsort{Last} does not work, it has to be {\noopsort{last}}

last also has to be lowercase here, at least in front of (single-word) prefixes, or else they are not parsed as prefixes at all
alternative: do not use \noopsort{Last} if there is a prefix; properly fixed, CMoS conformant .bst styles will sort such entries correctly anyway.

PRs for BibTeX and BibTeX with noopsort are out.

{\aftergroup\ignorespaces}<SPACE> is easier for me to insert than \relax<SPACE>
this should now be the case
I don't know if this is the case currently, but if there's a test for it it'll show up
is now the case

can I just always lowercase?
is this the preferred alternative?

It is in principle possible to have the BBT tests render the references; assuming \nocite{*} works for both BibTeX and BibLaTeX, it'd be easy to just generate templates (I think...). But I don't know if all latex processors are guaranteed to return bit-for-bit duplicates if you render the same file another time; if not, there's not much use in using them in tests, although I could leave them as artifacts somewhere for eyeballing.

{\aftergroup\ignorespaces} is easier for me to insert than \relax
this should now be the case
I don't know if this is the case currently, but if there's a test for it it'll show up
is now the case
can I just always lowercase?
is this the preferred alternative?

Any bits missing here?

“… I could leave them as artifacts somewhere for eyeballing.”

That’s what I had in mind. – Or maybe run pdftotext and compare its outputs?

I meant: is "alternative: do not use \noopsort{Last} if there is a prefix" the preferred alternative, or is the current behavior (after adjusting for your test files) just as good? If it's just as good, I'm converging on the tests running green, and I'd like to cash that in.
Perhaps on the pdftotext... I dunno, maybe, I have no idea how good it is and how well the pdfs generated by the various LaTeX processors are well suited to it. It's also majorly sensitive to bibstyle in play, etc, so it may be a significant effort to get something useful going here. In any case it's a different issue from what we're dealing with here in #566.

just as good?

Not as clean, but sorting with non-CMoS conformant .bst styles is better, so: ok.

… majorly sensitive to bibstyle in play …

Expected output (whether pdf or pdftotext output) always has to be defined relative to a specific combo of texfile, bibfile, and bibstyle …

I've merged your test files (thanks for those), combining my latest changes with the updated test files, tests are running on them here.

And now here... forget about them, I'll report back when I have the trivial stuff done.

Tests run mostly green. Can you look at the remaining fails (in red)?
Any suggestion for how to call the noopsort option in the prefs pane?

See new PR.
Maybe:

“Instruct BibTeX to disregard prefixes when sorting”
“BibTeX: Disregard prefixes when sorting”

Tests run green and preference has been added. @danilomm, this will affect you, as it changes the behavior that was added for #411 -- sorting will be fixed (I hope), but name display will be unchanged. Is this something you can live with, or could you use biblatex (much recommended)?
There remains then the original problem @sanmame brought in: is there a way to have \Citet work using braced names? @sanmame, is it feasible for you to use biblatex?

@retorquere Great, thanks, now \Citet is working for single-word last names. I'll try biblatex.
Thanks for the help!

Super, then I'm closing this. @danilomm, if this does not solve the problem you raised in #411 (to the extent that that problem is solvable in BibTeX), please re-open #411.


The entry of RS_IsoSeq pipeline to use proovread for correction?

I'm sorry if you got my emails (I'm not sure whether my email was sent successfully or not).
I've six SMRT cells and some Hiseq NGS data from transcriptom sequencing for a species without ref. genome. I am planning to use RS_IsoSeq pipeline to get polished full length reads by:

ConsensusTools.sh CircularConsensus ... to get reads of insert (css reads)
pbtranscript.py classify  ... to get full length reads.
pbtranscript.py cluster ... to do Isoform level clustering and get consensus reads.
ice_polish.py  ... to run Quiver to get polished consensus reads.

After polished by quiver process, I will get low quality and high quality consensus sequences.
I learned from [https://github.com/BioInf-Wuerzburg/proovread/issues/41] that he tried to use proovread to correct  low quality consensus sequences from Quiver, but I don't know what is going on, whether it was successful or not.
My question is:
Can I use proovread to correct both high and especially Low quality consensus sequences?
I'm also a bit confused that if I corrected PACbio reads from step 1 (css reads) (this is normally used for proovread input, right?), then can I still use RS_IsoSeq pipeline for subsequent analysis, or should I use other tools (what?)?
I'm really new on PACbio analysis. Sincerely hope you could give me some suggestions.
Thank you!

You can use proovread to try and further corrected hi- as well as low-consensus sequences. However, your hi-quality data should already be pretty error free. Use --no-sampling for transcriptome data runs.
Usual input for proovread are "reads of inserts" (also referred to subreads). Whether or not subreads from the template have already been merged into a single consensus (ccs) or not does not matter, as proovread will do that if necessary.
If you run proovread correction after step 1, I think 2,3 and 4 should still be possible. However, I have not used the pipeline myself. In particular, I do not know, how full length reads are determined, and whether that might be affected by prior correction with proovread. Clustering should work, yet the differences between reads should be much smaller, since most errors have already been removed.

The most interesting reads to correct are probably reads deemed full-length, but which did not get a lot o hits during clustering, i.e. rare transcripts with low pacbio coverage. Not sure though, if you can get that information from your data.

Thank you very much, thackl! I'll try correction for both ccs subreads and quiver low quality sequences if I can. I tested proovread for one small piece of file, it seems all right. But before running proovread for the whole data, could you help me to estimate how many short reads I need and how long will it take to run proovread?
I have got six reads of insert (ccs reads), each with ~140Mb (for example, one file has 67000seqs2100bp).
The final quiver LQ sequences for the pooled six files is also ~140Mb (2658bp58260seqs).
My species has no reference genome, and the estimated genome size is ~3Gb.  What is the minmum required short reads for correction? Do I need 3Gb50x of short reads? How long will it take if I use 3Gb50X to correct the 140Mb long reads?
Thank you!

Just to clarify - are you planning to correct your transcriptome PacBio reads with genomic Illumina reads?

Both my pacbio and NGS are from transcriptome sequencing.


Fix non-cached client

Here, we incorrectly assume that the client is a non-cached client:
https://github.com/cert-manager/trust-manager/blob/f2da89271eb887093f434a4e79b80d1fee02a212/pkg/bundle/bundle.go#L57-L60
This results in caching all these resources fully. Additionally, we are already caching the metadata-only representation of these resources, effectively caching each resource twice (more info: https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/builder/options.go#L103-L132).
In this PR, I fix this issue and also rename the client field to directClient to make clear that this client is not cached.
Also, I simplified the cache.go code a bit by using an external library.
fixes #91

/retest

👋 Controller Runtime maintainer here!
Apologies for the confusion here with our UX, need to think more about how to improve it long term. A few things that I can clarify:

Controllers using Manager's Clients are by default using a cached clients for read operations.
Any Get() call with a typed (e.g. appsv1.Pod{}), or unstructured, or partial metadata starts an internal cache that watches those objects. If there are 3 calls with the same GroupVersionKind, but with a typed/unstructured/metadata object, 3 total caches are started, causing duplication.
To avoid caching specific resources, I'd suggest using either a live client (APIReader), like this PR proposed, or even better you can configure the manager to always avoid caching certain types; the check is done per GroupVersionKind, and applies to every object.

The above needs to be improved, and frankly all of the options we have should eventually go in a builder of sorts for both controllers and the manager itself, instead of being in Options.

Thanks for that great description @vincepri !

or even better you can configure the manager to always avoid caching certain types;

What would be some reasons why this would be better than standalone live client? Maybe because it uses the same rate limiting for all requests? Otherwise it feels like it would be unlikely that a person down the line adding a GET request for a new type would actually remember to add it to uncached types unless they've memorized that this needs to be done.

What's better probably depends on what you're looking the default behavior to be like, if one prefers the default to be always uncached, an APIReader is probably a better choice. On the flip side, if you only want to avoid caching certain objects for reasons like size, freshness, etc, the cached client is preferred. Usually caches come in handy when lots of Get/List requests are performed against the same objects, it avoid overloading the API Server with many roundtrips.

Thanks that makes sense! I was worried that perhaps there's something that we're missing out by using APIReader to GET objects that we know we don't need to cache (as opposed to using client obtained from the manager). We do use cache for the objects that need to be retrieved in full frequently 👍🏼


Added file to reproduce ewels/MultiQC#1446

x-ref https://github.com/ewels/MultiQC/issues/1446
@ErikDanielsson - for next time, as this is a different repo you need to reference ewels/MultiQC#1446 in the commit message to tie the commit to the issue, instead of just #1446 👍🏻


[backward incompatible] Add ENTRYPOINT to the Dockerfile

If we add:
ENTRYPOINT ["gitlabform"]

...to our Dockerfile running the app with Docker will be a bit easier:
docker run -it -v $(pwd):/config ghcr.io/gitlabform/gitlabform:latest # no more extra "gitlabform" here!

But this will make the syntax documented here https://gitlabform.github.io/gitlabform/installation/ now work anymore as that last "gitlabform" will start to be interpreted as a parameter passed to the app...
So we would need to do this in a major version update.

On second thought, it's not a good idea. This would make the syntax for CI/CD use a bit less readable. Now you have to use a full command, see https://gitlabform.github.io/gitlabform/automation/#running-in-an-automated-pipeline.
Closing then.


fix: use type module in package.json and update file extensions

fixes https://github.com/portabletext/react-portabletext/issues/33
The build step now produces correct file extensions for ESM module resolution

Fixed in v2.0.1


It says python not found

IT SAYS PYTHON NOT FOUND, BUT I HAVE PYTHON

Reinstall and make sure you thick add to path on the installation screen.


Temporal utilities miss variations due to daylight savings

    #[cfg(feature = "chrono-tz")]
    #[test]
    fn test_temporal_array_timestamp_hour_with_dst_timezone_using_chrono_tz() {
        //
        //<PHONE_NUMBER> converts to 2021-10-30 17:59:07 in time zone Australia/Sydney (AEDT)
        // The offset (difference to UTC) is +11:00. Note that daylight savings is in effect on 2021-10-30.
        // When daylight savings is not in effect, Australia/Sydney has an offset difference of +10:00.

        let a = TimestampMillisecondArray::from_opt_vec(
            vec![Some(1635577147000)],
            Some("Australia/Sydney".to_string()),
        );
        let b = hour(&a).unwrap();
        assert_eq!(17, b.value(0));
    }

This test fails - it returns 16 instead of 17 and demonstrates that the offset for the timezone is not correctly taking daylight savings into account.
Originally posted by @novemberkilo in https://github.com/apache/arrow-rs/pull/849#issuecomment-955647565

I have a fix in the works - please assign to me as appropriate. // @alamb

@alamb I have a fix on a branch that builds off my work in #849 -- here is the diff https://github.com/novemberkilo/arrow-rs/compare/master...novemberkilo:topic/dst-bug-temporal
I suggest we work through #849 and then I will put up a PR separately.


feat: skipSchemaCreation option

Case
In some postgres databases there may be no permissions to execute statement
CREATE SCHEMA IF NOT EXISTS "public"

which causes migrate function to fail with "permission denied for database ...".

Temporary solution:
find node_modules/drizzle-orm -type f -exec sed -i '/CREATE SCHEMA IF NOT EXISTS/d' {} \;
find node_modules/drizzle-kit -type f -exec sed -i '/CREATE SCHEMA IF NOT EXISTS/d' {} \;


  I'll try harder to keep my criticism to the constructive sort... Again.
I will probably fail, but I'll try to vent my spleen in pull requests rather than Reddit posts.

You show some symptoms of sleep deprivation. Please take care of yourself!
Notice that this a professional working environment and not a place for ranting. I'll close this issue since it distracting.

@icefoxen Some of your feedback has good points and I'm listening. You don't have to worry about me taking it personal or anything.
Sometimes I see people posting things telling that they are very anxious about the response. This is often a sign of lack of sleep, so it is best to tell people just in case. It is hard to know. Seems to happen a lot on the Internet.


Centre container on IE

add width: 32rem;
alpha order those properties

It’s for IE’s benefit - older IE needs the width set explicitly or it doesn’t understand the auto that centres the container, & the container sticks to the left.

If this was an intended troll, have my claps.

Thanks!


feat: add hover mixin

Mixin +hover() -> @media (only screen and (hover: hover))
Add hover for only support hover device.

Thank you for the tool that allowed me to save a lot of time.

nice feature but is not working with double brackets...
output css:
@media (only screen and (hover: hover)) {... }
maybe you can change it like this:
rupture-hover(density = null, orientation = null, fallback-class = null)   condition = "hover: hover";   @media only screen and ({condition})     {block}


Commits

Do you guys know how can I check no of commits I made? Please let me know.

Go to your own repository and you will find it there.


python37Packages.django_3: 3.1.3 -> 3.1.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python37Packages.django_3 is: "A high-level Python Web framework"
meta.homepage for python37Packages.django_3 is: "https://www.djangoproject.com/"
meta.changelog for python37Packages.django_3 is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

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

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

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

found 3.1.4 with grep in /nix/store/il6293fsmkiqjkc9p66jxyp7cskn7bll-python3.7-Django-3.1.4

directory tree listing: https://gist.github.com/8a0835adc9a7c319f73bf6d8c441f4cb

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

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

21 total rebuild path(s)

6 package rebuild(s)

6 x86_64-linux rebuild(s)
6 i686-linux rebuild(s)
3 x86_64-darwin rebuild(s)
6 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
gnomeExtensions.gsconnect
lyx
python37Packages.django_3
python38Packages.django_3
python39Packages.django_3
recoll

Instructions to test this update (click to expand)

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

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

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

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

3 packages built:

python37Packages.django_3
python38Packages.django_3
python39Packages.django_3

Maintainer pings
cc @georgewhewell @lsix for testing.

Result of nixpkgs-review pr 105773 run on x86_64-darwin 1

3 packages built:

python37Packages.django_3
python38Packages.django_3
python39Packages.django_3


Agent evaluation hydra configuration error

Hi,
Wanted to evaluate an agent with simple command
HYDRA_FULL_ERROR=1 python sheeprl_eval.py fabric.accelerator=gpu  checkpoint=logs/runs/dreamer_v3/MsPacmanNoFrameskip-v4/2024-03-24_20-28-49_dreamer_v3_MsPacmanNoFrameskip-v4_5/version_0/checkpoint/ckpt_600000_0.ckpt

However, it gets this error message:
Traceback (most recent call last):
  File "/home/sam/dev/sheeprl/sheeprl_eval.py", line 4, in <module>
    evaluation()
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/main.py", line 90, in decorated_main
    _run_hydra(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 394, in _run_hydra
    _run_app(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 457, in _run_app
    run_and_report(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 222, in run_and_report
    raise ex
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 219, in run_and_report
    return func()
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 458, in <lambda>
    lambda: hydra.run(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/hydra.py", line 105, in run
    cfg = self.compose_config(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/hydra.py", line 594, in compose_config
    cfg = self.config_loader.load_configuration(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/config_loader_impl.py", line 142, in load_configuration
    return self._load_configuration_impl(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/config_loader_impl.py", line 253, in _load_configuration_impl
    defaults_list = create_defaults_list(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 753, in create_defaults_list
    overrides.ensure_overrides_used()
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 168, in ensure_overrides_used
    raise ConfigCompositionException(msg)
hydra.errors.ConfigCompositionException: Could not override 'checkpoint'. No match in the defaults list.
To append to your default list use +checkpoint=logs/runs/dreamer_v3/MsPacmanNoFrameskip-v4/2024-03-24_20-28-49_dreamer_v3_MsPacmanNoFrameskip-v4_5/version_0/checkpoint/ckpt_600000_0.ckpt

Then if I try the suggested command, it does
HYDRA_FULL_ERROR=1 python sheeprl_eval.py fabric.accelerator=gpu  +checkpoint=logs/runs/dreamer_v3/MsPacmanNoFrameskip-v4/2024-03-24_20-28-49_dreamer_v3_MsPacmanNoFrameskip-v4_5/version_0/checkpoint/ckpt_600000_0.ckpt
Traceback (most recent call last):
  File "/home/sam/dev/sheeprl/sheeprl_eval.py", line 4, in <module>
    evaluation()
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/main.py", line 90, in decorated_main
    _run_hydra(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 394, in _run_hydra
    _run_app(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 457, in _run_app
    run_and_report(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 222, in run_and_report
    raise ex
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 219, in run_and_report
    return func()
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/utils.py", line 458, in <lambda>
    lambda: hydra.run(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/hydra.py", line 105, in run
    cfg = self.compose_config(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/hydra.py", line 594, in compose_config
    cfg = self.config_loader.load_configuration(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/config_loader_impl.py", line 142, in load_configuration
    return self._load_configuration_impl(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/config_loader_impl.py", line 253, in _load_configuration_impl
    defaults_list = create_defaults_list(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 746, in create_defaults_list
    defaults, tree = _create_defaults_list(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 716, in _create_defaults_list
    defaults_tree = _create_defaults_tree(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 356, in _create_defaults_tree
    ret = _create_defaults_tree_impl(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 457, in _create_defaults_tree_impl
    return _expand_virtual_root(repo, root, overrides, skip_missing)
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 280, in _expand_virtual_root
    subtree = _create_defaults_tree_impl(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 573, in _create_defaults_tree_impl
    add_child(children, new_root)
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 520, in add_child
    subtree_ = _create_defaults_tree_impl(
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 488, in _create_defaults_tree_impl
    config_not_found_error(repo=repo, tree=root)
  File "/home/sam/dev/sheeprl/.venv/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 800, in config_not_found_error
    raise MissingConfigException(
hydra.errors.MissingConfigException: In 'eval_config': Could not find 'checkpoint/logs/runs/dreamer_v3/MsPacmanNoFrameskip-v4/2024-03-24_20-28-49_dreamer_v3_MsPacmanNoFrameskip-v4_5/version_0/checkpoint/ckpt_600000_0.ckpt'

Available options in 'checkpoint':
	default
Config search path:
	provider=hydra, path=pkg://hydra.conf
	provider=main, path=pkg://sheeprl.configs
	provider=schema, path=structured://

Am I missing something or it's a bug?

Hi @geranim0, you should call the evaluation script with python sheeprl_eval.py checkpoint_path=/path/to/checkpoint ....
Can you try this?

Ah... Sorry... Missed the _path! It works


ci: Bump cyclonus to v0.4.7

We're observing periodic flakyness [1] with the Cyclonus tests.
As a first step on improving this, bump the test suite to
the latest version.
[1] https://github.com/cilium/cilium/actions/workflows/conformance-k8s-network-policies.yaml?query=event%3Aschedule
TODO:

[ ] drop runs on pull_request
[ ] figure out whether we need include or exclude flags since mode is now gone

@mattfenwick since you originally contributed the test, if you have time, could you take a quick look at the failing runs and see if they're cyclonus related or if they're pointing to an actual issue with Cilium? Much appreciated!
And could you also check my changes in this PR. Should I have some --include flag?

hi @joamaki !!  This is interesting, it looks like Cyclonus is finding discrepancies between actual and expected connectivity:
2022-02-09T00:29:08.7209949Z Summary:
2022-02-09T00:29:08.7210223Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7210369Z |              TEST              | RESULT  |   STEP/TRY    | WRONG | RIGHT | IGNORED |
2022-02-09T00:29:08.7210626Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7210769Z | 1: should support a            | failure |               |       |       |         |
2022-02-09T00:29:08.7211013Z | 'default-deny-ingress' policy  |         |               |       |       |         |
2022-02-09T00:29:08.7211282Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7211401Z |                                |         | Step 1, try 1 |     2 |    70 |       9 |
2022-02-09T00:29:08.7211673Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7211793Z |                                |         | Step 1, try 2 |     1 |    71 |       9 |
2022-02-09T00:29:08.7212056Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7212177Z | 2: should support a            | success |               |       |       |         |
2022-02-09T00:29:08.7212412Z | 'default-deny-all' policy      |         |               |       |       |         |
2022-02-09T00:29:08.7212679Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7212799Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7213063Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7213180Z |                                |         | Step 1, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7213441Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7213569Z | 3: should enforce policy based | success |               |       |       |         |
2022-02-09T00:29:08.7213713Z | on Multiple PodSelectors and   |         |               |       |       |         |
2022-02-09T00:29:08.7213847Z | NamespaceSelectors             |         |               |       |       |         |
2022-02-09T00:29:08.7214113Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7214284Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7214555Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7214668Z |                                |         | Step 1, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7214932Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7215057Z | 4: should enforce multiple,    | success |               |       |       |         |
2022-02-09T00:29:08.7215184Z | stacked policies with          |         |               |       |       |         |
2022-02-09T00:29:08.7215321Z | overlapping podSelectors       |         |               |       |       |         |
2022-02-09T00:29:08.7215453Z | [Feature:NetworkPolicy]        |         |               |       |       |         |
2022-02-09T00:29:08.7215715Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7215887Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7216155Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7216258Z |                                |         | Step 1, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7216520Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7216633Z |                                |         | Step 2, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7216897Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7217011Z |                                |         | Step 2, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7217274Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7217391Z |                                |         | Step 3, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7217643Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7217757Z |                                |         | Step 3, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7218019Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7218256Z | 5: should support allow-all    | success |               |       |       |         |
2022-02-09T00:29:08.7218369Z | policy                         |         |               |       |       |         |
2022-02-09T00:29:08.7218633Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7218748Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7219011Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7219118Z |                                |         | Step 2, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7219381Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7219518Z | 6: should allow ingress access | success |               |       |       |         |
2022-02-09T00:29:08.7219639Z | on one named port              |         |               |       |       |         |
2022-02-09T00:29:08.7219900Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7220015Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7220281Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7220382Z |                                |         | Step 2, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7220643Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7220810Z |                                |         | Step 2, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7221080Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7221215Z | 7: should enforce updated      | success |               |       |       |         |
2022-02-09T00:29:08.7221327Z | policy                         |         |               |       |       |         |
2022-02-09T00:29:08.7223278Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7223409Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7223692Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7223806Z |                                |         | Step 2, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7224067Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7224319Z |                                |         | Step 2, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7224590Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7224727Z | 8: should allow ingress access | success |               |       |       |         |
2022-02-09T00:29:08.7224858Z | from updated namespace         |         |               |       |       |         |
2022-02-09T00:29:08.7225110Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7225226Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7225488Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7225600Z |                                |         | Step 1, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7225861Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7225979Z |                                |         | Step 2, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7226240Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7226343Z |                                |         | Step 2, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7226602Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7226740Z | 9: should allow ingress access | success |               |       |       |         |
2022-02-09T00:29:08.7226863Z | from updated pod               |         |               |       |       |         |
2022-02-09T00:29:08.7227300Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7227415Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7227684Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7227803Z |                                |         | Step 1, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7228056Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7228170Z |                                |         | Step 2, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7228434Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7228549Z |                                |         | Step 2, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7228812Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7228949Z | 10: should deny ingress access | success |               |       |       |         |
2022-02-09T00:29:08.7229069Z | to updated pod                 |         |               |       |       |         |
2022-02-09T00:29:08.7229396Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7229514Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7229782Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7229893Z |                                |         | Step 2, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7230154Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7230288Z | 11: should work with Ingress,  | success |               |       |       |         |
2022-02-09T00:29:08.7230420Z | Egress specified together      |         |               |       |       |         |
2022-02-09T00:29:08.7230681Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7230783Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7231105Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7231217Z |                                |         | Step 1, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7231481Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7231594Z |                                |         | Step 2, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7231856Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7231969Z |                                |         | Step 2, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7232222Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7232357Z | 12: should support denying     | success |               |       |       |         |
2022-02-09T00:29:08.7232484Z | of egress traffic on the       |         |               |       |       |         |
2022-02-09T00:29:08.7232613Z | client side (even if the       |         |               |       |       |         |
2022-02-09T00:29:08.7232748Z | server explicitly allows this  |         |               |       |       |         |
2022-02-09T00:29:08.7232861Z | traffic)                       |         |               |       |       |         |
2022-02-09T00:29:08.7233123Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7233226Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7233489Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7233604Z |                                |         | Step 1, try 2 |     0 |    72 |       9 |
2022-02-09T00:29:08.7233867Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7234002Z | 13: should stop enforcing      | success |               |       |       |         |
2022-02-09T00:29:08.7234136Z | policies after they are        |         |               |       |       |         |
2022-02-09T00:29:08.7234250Z | deleted                        |         |               |       |       |         |
2022-02-09T00:29:08.7234730Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7234832Z |                                |         | Step 1, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7235099Z +--------------------------------+---------+---------------+-------+-------+---------+
2022-02-09T00:29:08.7235213Z |                                |         | Step 2, try 1 |     0 |    72 |       9 |
2022-02-09T00:29:08.7235475Z +--------------------------------+---------+---------------+-------+-------+---------+

But it's not finding very many discrepancies AND they're flakes ... so I wonder what would happen if we bumped up the retries?  Also I like your idea of upgrading to newest cyclonus!

@mattfenwick bumping retries might make sense!
Could you help out figuring which flags we should use in the tests? I changed the original --mode=upstream to --include=upstream-e2e which I thought would've been about the same, but it doesn't seem to run any tests: https://github.com/cilium/cilium/runs/5124735501?check_suite_focus=true.

Hi @joamaki !!!  I just looked into this, I think you have to do this:
--include upstream-e2e --exclude ''

because somebody (oh wait it was me lol) seems to have added upstream-e2e to the default exclude list ... whoops !

Just tested running from source, go run main.go generate --include upstream-e2e --dry-run --exclude '':
testing 13 cases

test #1: should support a 'default-deny-ingress' policy
 - tags: deny-all, direction, ingress, miscellaneous, rule, upstream-e2e
test #2: should support a 'default-deny-all' policy
 - tags: deny-all, miscellaneous, rule, upstream-e2e
test #3: should enforce policy based on Multiple PodSelectors and NamespaceSelectors
 - tags: miscellaneous, upstream-e2e
test #4: should enforce multiple, stacked policies with overlapping podSelectors [Feature:NetworkPolicy]
 - tags: miscellaneous, upstream-e2e
test #5: should support allow-all policy
 - tags: allow-all, miscellaneous, rule, upstream-e2e
test #6: should allow ingress access on one named port
 - tags: direction, ingress, miscellaneous, named-port, port, upstream-e2e
test #7: should enforce updated policy
 - tags: miscellaneous, upstream-e2e
test #8: should allow ingress access from updated namespace
 - tags: miscellaneous, upstream-e2e
test #9: should allow ingress access from updated pod
 - tags: miscellaneous, upstream-e2e
test #10: should deny ingress access to updated pod
 - tags: miscellaneous, upstream-e2e
test #11: should work with Ingress, Egress specified together
 - tags: miscellaneous, upstream-e2e
test #12: should support denying of egress traffic on the client side (even if the server explicitly allows this traffic)
 - tags: conflict, miscellaneous, upstream-e2e
test #13: should stop enforcing policies after they are deleted
 - tags: action, delete-policy, deny-all, miscellaneous, rule, upstream-e2e

👍 👍

I can't find the cyclonus logs on https://github.com/cilium/cilium/actions/runs/1828316245 , not sure if I'm looking in the wrong place -- if they're not captured, is there a way that we can capture them?

I can't find the cyclonus logs on https://github.com/cilium/cilium/actions/runs/1828316245 , not sure if I'm looking in the wrong place -- if they're not captured, is there a way that we can capture them?

I guess it needs to be pulled out of the cyclonus pod somehow? e.g. with kubectl logs.

@mattfenwick ok here's some logs now from the test run: https://github.com/cilium/cilium/runs/5358346163?check_suite_focus=true. Seems to take much longer to run than the v0.2 version and there seems to be many failures. I don't know how to interpret this. Could you take a look?

hi @joamaki !!  Looks like this is still timing out?
It currently runs on 2 ports and 3 protocol, making things take longer.  There's a couple more flags you can add which will make it go faster: --server-port 80 --server-protocol tcp
Full mock example:
go run main.go generate --include upstream-e2e --dry-run --exclude '' --mock --server-port 80 --server-protocol tcp

ooh yeah I just looked more closely at the results :) running on just TCP (instead of UDP+TCP+SCTP) will make this go muuuuuuch faster :) :)

Successful run here: https://github.com/cilium/cilium/runs/6090085687?check_suite_focus=true. Disabling the running of the test on pull requests now.

@nbusseneau PTAL, thanks!


Random Red Lines in Timeline Render Bar

Apple Feedback Assistant ID: FB13434993
DESCRIBE THE BUG:
Sometimes Final Cut Pro 10.7 will show random red lines in the render bar, even if there's nothing in the primary storyline or secondary storyline.

TO REPRODUCE:
Unfortunately it seems random.

EXPECTED BEHAVIOUR:
These red bars should only be for Apple's internal debugging?

SCREENSHOTS:

SPECS:

2021 16-inch MacBook Pro
macOS Sonoma 14.1.2
Final Cut Pro 10.7

Since we sometimes see this in some difficult cases, it would be good to have additional info on what the red render bars mean. I examined this under XCode, and found a few things but unfortunately not a complete answer.
The "render dots" are officially called the "render indicator". The FCP private library that manages that is TLKit (Timeline Kit). The class is TLKRulerLane and the instance method which draws the render dots is updateRenderIndicator. I don't have a current replication scenario for the "red render bar" case, but in all the normal cases, the stack trace when calling -[TLKRulerLane updateRenderIndicator] looks like this the below.
There are about 77 different instance methods within the TLKRulerLane class. In theory this class is the only code that updates the render indicator lane. However I don't see any of its methods which refer to debugging or invalid render state.
There are two methods which refer to something being wrong:

invalidateTimecodeSize
invalidateRulerSegments:startingAt

However, without a replication scenario, it's difficult to dig any deeper.
On 1-12-22 I filed bug FB9842233, "Retimed FCP clip becomes black or deleted after Edit>Remove Effects on multiple clips". It could cause red render bars in some failure modes. That began on 10.5.3, was filed on 10.6.1 and fixed on 10.6.2. The retiming aspect is interesting because that might involve the above method invalidateTimecodeSize, but that's just a guess. See attached of timeline with red render bars and XML analysis.
My current gut feel is the red render bars are more likely an unpredictable failure mode than an undocumented debug feature. If we ever have a portable replication scenario on a current version, I can study it more.
Normal stack trace when updating "render indicator" (render dots) above timeline ruler:
0 -[TLKRulerLane updateRenderIndicator]
1 _NSThreadPerformPerform
2_ CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCEO_PERFORM_FUNCTION_
_CRunLoopDoSourceO
4 _CFRunLoopDoSourcesO
中
5 _CFRunLoopRun
6 CFRunLoopRunSpecific
7 RunCurrentEventLoopInMode
8 ReceiveNextEventCommon
9_BlockUntilNextEventMatchingList/nModeWithFilter
10 _DPSNextEvent
11 - [NSApplication(NSEventRouting)
_nextEventMatchingEventMask:untilDate:inMode:dequeue:]
12 - [NSApplication run]
13 LKApplicationMain
14 start

FCP_Bug_FB9842233.txt

The Final Cut Pro team tells me:

The red line is designed to indicate when something is wrong with the time range of the segment. For example, it could mean that the edit is not aligned at the proper time, or there’s something about the clip’s time for that edit/segment that is off. Essentially it’s an error in the timeline.

Here an example of the red line:

It only works for clips on the Primary Storyline:

This is a 25fps timeline, and the clips that have the red lines are all 23.976fps or 24fps. These are all BRAW Toolbox clips.
Here's a FCPXML of the timeline:
https://gist.github.com/latenitefilms/ae58d43e3bfe8e3684b2e0fd92bff810

I loaded your XML (sans data); I see the red render bar. I think they set that in TLKit  -[TLKRulerLane updateRenderIndicator], but without source code, I can't tell where.
It's not in -[TLKTimelineView rulerStyle] or -[TLKRenderBarLayer setRenderDescription:]. I checked -[TLKRulerLane updateRenderIndicator], -[TLKRenderBarLayer setRenderDescription:], and -[TLKDataSourceProxy renderInfoForTimeRange:] but could not find where they are setting the red render bar (hence I can't tell the specific criteria).  However, it's probably sufficient to know it means a timeline error.
I also used "log show" to check the MacOS and FCP log output, but I didn't see any assertions or other messages related to this.

Have you played with Hopper?

Yes I have it. It's impressive but I haven't used it that much. For this
case I just used XCode and lldb, plus symbol lists made with 'nm'.  I
should have used Hopper.
-- Joe
On Tue, Feb 6, 2024 at 5:12 PM Chris Hocking @.***>
wrote:

Have you played with Hopper https://www.hopperapp.com?
—
Reply to this email directly, view it on GitHub
https://github.com/CommandPost/FCPCafe/issues/285#issuecomment-1930925458,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APRV3ATLPUEHSP2K5QCGXKDYSK2F3AVCNFSM6AAAAABAD7Q6I6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQHEZDKNBVHA
.
You are receiving this because you commented.Message ID:
@.***>


MQTTnet Downloaded Code Causes Error Just Opening MQTTnet.sln in VS 2019 or VS2022

Downloaded MQTTnet-master.zip, extracted to C:\Users\MySelf\source\repos\MQTTnet-master
Opened MQTTnet.sln with VS2019  produced 8 errors. The following is first error
Severity	Code	Description	Project	File	Line	Suppression State
Error	NETSDK1045	The current .NET SDK does not support targeting .NET 7.0.  Either target .NET 6.0 or lower, or use a version of the .NET SDK that supports .NET 7.0.	MQTTnet	C:\Program Files\dotnet\sdk\6.0.113\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets	144
Opened MQTTnet.sln with VS2022  produced 8 errors. The following is first error
Severity	Code	Description	Project	File	Line	Suppression State
Error		Project "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\WindowsXaml\v17.0\Microsoft.Windows.UI.Xaml.CSharp.targets" was not imported by "C:\Program Files\dotnet\sdk\7.0.102\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.targets" at (37,3), due to the file not existing.	MQTTnet.Extensions.WebSocket4Net	C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\WindowsXaml\v17.0\Microsoft.Windows.UI.Xaml.CSharp.targets	37
What version of VS was used to open  MQTTnet.sln with no errors?

I can build  the entire solution perfectly using Visual Studio 2022. Please make sure that the .NET 7.0 SDK is installed.

I downloaded the latest version of .NET SDK and installed it
C:\Users\MySelf\source\repos\MQTTnet-master - Subset>dotnet --info
.NET SDK:
Version:   7.0.102
Commit:    4bbdd14480
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.19045
OS Platform: Windows
RID:         win10-x64
Base Path:   C:\Program Files\dotnet\sdk\7.0.102\
Host:
Version:      7.0.2
Architecture: x64
Commit:       d037e070eb
.NET SDKs installed:
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.526 [C:\Program Files\dotnet\sdk]
3.0.101 [C:\Program Files\dotnet\sdk]
3.1.426 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
5.0.303 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]
5.0.416 [C:\Program Files\dotnet\sdk]
6.0.113 [C:\Program Files\dotnet\sdk]
7.0.102 [C:\Program Files\dotnet\sdk]
Still getting errors, 3
Severity	Code	Description	Project	File	Line	Suppression State
Error		Project "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\WindowsXaml\v17.0\Microsoft.Windows.UI.Xaml.CSharp.targets" was not imported by "C:\Program Files\dotnet\sdk\7.0.102\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.targets" at (37,3), due to the file not existing.	MQTTnet	C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\WindowsXaml\v17.0\Microsoft.Windows.UI.Xaml.CSharp.targets	37
Severity	Code	Description	Project	File	Line	Suppression State
Error	MSB4057	The target "CollectUpToDateCheckBuiltDesignTime" does not exist in the project.	MQTTnet	C:\Users\MySelf\source\repos\MQTTnet-master - Subset\Source\MQTTnet\MQTTnet.csproj	1
Severity	Code	Description	Project	File	Line	Suppression State
Error		SourceRoot items must include at least one top-level (not nested) item when DeterministicSourcePaths is true	MQTTnet	C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\Roslyn\Microsoft.Managed.Core.targets	236
What am I missing?

My error, I opened a copy of MQTTNet that I tried to fix yesterday.
Opening original download of  MQTTNet cause 7 errors, first one
Severity	Code	Description	Project	File	Line	Suppression State
Error		Project "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\WindowsXaml\v17.0\Microsoft.Windows.UI.Xaml.CSharp.targets" was not imported by "C:\Program Files\dotnet\sdk\7.0.102\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.targets" at (37,3), due to the file not existing.	MQTTnet	C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\WindowsXaml\v17.0\Microsoft.Windows.UI.Xaml.CSharp.targets	37

No "WindowsXaml" folder in my "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft"


docs(website): fix markdown link

Fixes the CONTRIBUTING.md link within the README.md of the website package (which currently points to nowhere).

@all-contributors please add @schlusslicht doc


Security - Endless spinner when try to close account

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open http://staging.new.expensify.com/
Log into a new account (expensifail and gmail)
Go to Settings > Security > Close account
Enter default contact method
Tap on "Close account" button

Expected Result:
Account should be close.
Actual Result:
Endless spinner is diaplayed when try to close account.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/78819774/14809f4d-5fdd-492e-a623-72d4b3a13854
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

Email or phone of affected tester (no customers):
Please fill this out. If this issue is related to the account you are using it can help us identify the cause.

I think we can make it a non-blocker as I'm unable to reproduce on staging.

Not able to reproduce - closed<EMAIL_ADDRESS>successfully
Checking for updates
Chrome Version 114.0.5735.133 (Official Build) (x86_64)
MacOS 13.3.1 (22E261)

@lanitochka17 are you able to reproduce this?

@slafortune Not reproduce. Issue fixed
https://github.com/Expensify/App/assets/78819774/ed01ad76-eb4d-4b22-bfa8-553046a6846a


Added join lines action

"join air"
"join block air"
Fixes #50
Checklist

[x] I have added tests
[x] I have updated the docs and cheatsheet
[x] I have not broken the cheatsheet

@pokey poke!

@pokey Nudge nudge!

@pokey I added a test with an empty line in the middle

@pokey Any more problems on this?


feat(fuck): hr component

ref: #5

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

3 of 4 (75.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+4.3%) to 64.286%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/fuck/hr/index.tsx
2
3
66.67%

Totals

Change from base Build<PHONE_NUMBER>:
4.3%

Covered Lines:
9

Relevant Lines:
14

💛  - Coveralls