italics in title - capitalization

The title in Zotero standalone application:
Effects of open- and closed-system temperature changes on blood O2-binding characteristics of Atlantic bluefin tuna (Thunnus thynnus)
I exported the collection from Zotero using Better Bibtex.
The final result in the bibliography:
Brill, R. W. and Bushnell, P. G. (2006). Effects of open- and closed-system temperature changes on blood O2-binding characteristics of Atlantic bluefin tuna (thunnus thynnus). Fish Physiology and Biochemistry, 32(4):283–294.

The "O" in O2 is capitalized.
The "A" in Atlantic is capitalized.
The "T" in Thunnus is NOT capitalized.

I think that a problem develops when the ... is converted to \emph{}.
I looked at the entry in BibDesk:
Effects of open- and closed-system temperature changes on blood {{O}}{\textsubscript{2}}-binding characteristics of {{Atlantic}} bluefin tuna ({\emph{Thunnus thynnus}})
I added a second set of {} brackets in BibDesk:
{{\emph{Thunnus thynnus}}} instead of {\emph{Thunnus thynnus}}
and the bibliography printed with the correct capitalization...
Therefore in the Better Bibtex conversion, 2 sets of brackets are needed around the \emph{} to get the correct format in the .bbl file and ultimately the bibliography...
I hope this can be fixed!
Thanks,
Allison

There are subtle differences between bibtex and biblatex (see https://github.com/retorquere/zotero-better-bibtex/issues/383, search for “This is just one of the small differences between bibtex the program and the btparse library used by biber”).
Could you provide details on whether you’re using bibtex and biblatex, or, better, an MWE?
And do you see the unexpected behaviour when exporting with Better Biblatex?

What I am doing:
Zotero-->Export Collection with Better BibTeX-->compile with BibTeX in TeXShop using the natbib package (\bibliographystyle{apalike})

I tried exporting with Better BibLaTeX but that created many other types errors when I compiled using in BibTeX (+natbib) in TeXShop because I use natbib.  I am going to submit this paper to a journal and I need to use natbib.

In the export collection with Better BibTeX, everything works great except for the capitalization for words in the title that are in between ....  I've been manually fixing the problem but the process is a bit repetitive.

I would include a MWE except I am not really sure what to attach because there are a bunch of GUIs and a plugin.  If you can give me a few more details about what you want in a MWE, I can try...

(thanks @nickbart1980 for jumping in; this aspect you know better than me, and I'm away with my family for a few days)
I think he means it'd be helpful if you could get us a compilable example that exhibits the issue - feel free to edit https://www.sharelatex.com/project/54feca38f58d781e0c982eeb .
It'd also be very helpful to have a copy of the reference - you can either right-click the reference and submit an error report, but then @nickbart1980 won't be able to access it. The other way is to export the reference as "BetterBibTeX JSON" and attach the resulting file as a text file here.

I get the same result, i.e., {{Atlantic}} bluefin tuna ({\emph{Thunnus thynnus}}), from both Better Bibtex and Better Biblatex export, and a lowercase “thunnus” in the pdf in both cases. Based on the discussion at https://github.com/retorquere/zotero-better-bibtex/issues/383, I would have expected {{Atlantic}} bluefin tuna ({{\emph{Thunnus thynnus}}}) – at least for Biblatex, but right now it would seem Bibtex (which was never that much in the focus of my attention) needs that, too.

Can either of you right-click that reference and submit an error report? That will get me the reference as a test case.

Wow, that was trickier than I thought. I ended up rewriting the markup parser -- BBT is better off for it, but quite an effort.
I currently get what I think is the right output if I generate
{Hello and \emph{{{Thunnus}} thynnus} instead of \emph{{{Thunnus}} thynnus}}

Is that OK? It's easy to generate with the new parser, and the proposed
{Hello and {{\emph{Thunnus thynnus}}} instead of {{\emph{Thunnus thynnus}}}}

would be a) a lot harder, and b) not necessarily correct if I remember our discussions -- shouldn't the thynnus part be available to the biblatex title caser?
BTW, for English titles, this would become
{Hello and \emph{{{Thunnus}} Thynnus} instead of \emph{{{Thunnus}} Thynnus}}

as the case preserver wouldn't protect the lowercase word. This is the expected behavior, correct?

… shouldn't the thynnus part be available to the biblatex sentence caser?

Absolutely right.
What’s more, I just realised that the original example, though it can be expected to work with a sentence-case style (APA, …), will fail with a title-case style (Chicago, …), since it does not follow best current practice:
Species names (also units such as “nm”, “kg”; in fact any stuff that should never undergo case changes, no matter what the style wants in general) need to be protected against case changes by enclosing them in … – e.g., Thunnus thynnus, or Thunnus thynnus.
Thunnus thynnus, though possibly even uglier, should of course work, too.
And when protected, the thynnus part should of course not be available to the biblatex sentence caser.

Well as luck would have it, that's what the current implementation does. I
use the citeproc-js titlecaser, which keeps stuff like nm in lowercase (I
think), and my parser naturally separates out Thynnus for protection.
I'll probably complete the latex generation later tonight knowing that I'm
on the right track.

@nickbart1980 to protect something like thynnus, it would have to be added to the titleCaseLowerCase. A full list of words would be undoable, but at least the user can add words themselves.
Help me remember: titlecasing was only for english, but was case preservation (the {{...}} stuff) for all languages, or only english? All languages, right?

… to protect something like thynnus, it would have to be added to the titleCaseLowerCase. A full list of words would be undoable, but at least the user can add words themselves.

That’s not what I meant. Users themselves need to protect unusual strings such as species names by wrapping them in …, so the Zotero title field would have to contain, e.g.,
Effects of open- and closed-system temperature changes on blood O2-binding characteristics of Atlantic bluefin tuna (Thunnus thynnus)
Even with a plain Zotero/Word-or-LO workflow this is needed, or else styles such as Chicago would render Thunnus Thynnus. BBT should simply propagate this protection.

… case preservation (the {{...}} stuff) …

Languages other than English don’t have case conversion, and so don’t need case preservation either.

To recap, and I know I'm being repetitive here, but I need to get this right:
There are two ways in which I fiddle with the text:

Title casing, which changes How to derive Ought from Is into How to Derive Ought from Is, and
Case preservation, which changes How to derive Ought from Is into How to derive {{Ought}} from {{Is}}

or a combination of the two. So the correct behavior is:

If the reference is not English, do neither
If the reference is English, for a specific set of fields always apply both

or is it

If the reference is not English, do neither
If the reference is English, for a specific set of fields (like title, shorttitle) always apply both, and for another specific set of fields (like journaltitle, type), apply only case preservation

I'm asking because the current implementation is closer to the latter than the former.

Correction: the current behavior is more like:

If the reference is English, for a specific set of fields (like title, shorttitle) always apply both, and for another specific set of fields (like journaltitle, type), apply only case preservation
If the reference is another language, only apply case preservation to title, shorttitle, journaltitle, type...)

Should words that start after a : or . be treated as if they appeared at the start of a sentence?

#435 indicates at least for type I should always wrap words with uppercase, regardless of whether they appear at a sentence-start. Are there more fields like this? Or should I only not wrap leading words if they're strictly <Upper><lower>*?

OK, I think I have most issues ironed out now. There's a few things the bibtex generator does differently than previously; they're all correctable, but I want to know whether this is acceptable output. First line is input language + input string, second line is bibtex, casePreserved and titleCased as per earlier rule (but feel free to correct):
<none>  : <<The largest U.S. companies would owe $620 billion in U.S. taxes on the cash they store in tax havens, the equivalent of our defense budget. [Tweet]>>
bibtex  : <<The Largest {{U.S}}. Companies Would Owe \$620 Billion in {{U.S}}. Taxes on the Cash They Store in Tax Havens, the Equivalent of Our Defense Budget. [{{Tweet}}]>>

<none>  : <<Nodo unitatis et caritatis: The Structure and Argument of Augustine's De doctrina Christiana>>
bibtex  : <<\emph{{{Nodo unitatis et caritatis}}}: The {{Structure}} and {{Argument}} of {{Augustine}}'s \emph{{{De doctrina Christiana}}}>>

fr      : <<La démocratie. Sa nature, sa valeur>>
bibtex  : <<La d{\'e}mocratie. {{Sa}} nature, sa valeur>>

<none>  : <<Social Capital Predicts Happiness: World-Wide Evidence From Time Series>>
bibtex  : <<Social {{Capital Predicts Happiness}}: {{World-Wide Evidence From Time Series}}>>

<none>  : <<Lieb-Robinson bounds, Arveson spectrum and Haag-Ruelle scattering theory for gapped quantum spin systems>>
bibtex  : <<{{Lieb-Robinson}} Bounds, {{Arveson}} Spectrum and {{Haag-Ruelle}} Scattering Theory for Gapped Quantum Spin Systems>>

<none>  : <<Salmonella in Pork (SALINPORK): Pre-harvest and Harvest Control Options Based on Epidemiologic, Diagnostic and Economic Research: Final Report>>
bibtex  : <<\emph{Salmonella} in {{Pork}} ({{SALINPORK}}): {{Pre-harvest}} and {{Harvest Control Options Based}} on {{Epidemiologic}}, {{Diagnostic}} and {{Economic Research}}: Final {{Report}}>>

<none>  : <<Automated Defect Prevention : Best Practices in Software Management>>
bibtex  : <<Automated {{Defect Prevention}} : Best {{Practices}} in {{Software Management}}>>

en      : <<(Liquid+liquid) equilibrium of {water+phenol+(1-butanol, or 2-butanol, or tert-butanol)} systems>>
bibtex  : <<({{Liquid}}+liquid) Equilibrium of \{water+phenol+(1-Butanol, or 2-Butanol, or Tert-Butanol)\} Systems>>

<none>  : <<The physical: violent volcanology of the 1600 eruption of Huaynaputina, southern Peru>>
bibtex  : <<The Physical: Violent Volcanology of the 1600 Eruption of {{Huaynaputina}}, Southern {{Peru}}>>

<none>  : <<Technical Report : Towards a Formally Verified Proof Assistant>>
bibtex  : <<Technical {{Report}} : Towards a {{Formally Verified Proof Assistant}}>>

<none>  : <<Full-text databse>>
bibtex  : <<{{Full-text}} Databse>>

<none>  : <<High Performance Computing (HiPC), 2011 18th international conference on>>
bibtex  : <<High {{Performance Computing}} ({{HiPC}}), 2011 18th International Conference on>>

<none>  : <<High-speed jet flows over spillway aerators>>
bibtex  : <<{{High-speed}} Jet Flows over Spillway Aerators>>

<none>  : <<Replicate Zotero key algorithm · Issue #439 · retorquere/zotero-better-bibtex>>
bibtex  : <<Replicate {{Zotero}} Key Algorithm $\cdot$ {{Issue}} \#439 $\cdot$ Retorquere/Zotero-Better-Bibtex>>

<none>  : <<11-Oxygenated Steroids. XIII. Synthesis and proof of structure of Δ1,4-Pregnadiene-17α,21-diol-3,11,20-trione and Δ1,4-Pregnadiene-11β,17α,21-triol-3,20-dione>>
bibtex  : <<{{11-Oxygenated Steroids}}. {{XIII}}. Synthesis and Proof of Structure of {{$\Delta$1,4-Pregnadiene-17$\alpha$,21-diol-3,11,20-trione and $\Delta$1,4-Pregnadiene-11$\beta$,17$\alpha$,21-triol-3,20-dione}}>>

<none>  : <<Computational Models of Non-cooperative dialogue>>
bibtex  : <<Computational {{Models}} of {{Non-cooperative}} Dialogue>>

<none>  : <<Dr. Strangelove or: how I learned to stop worrying and love the bomb>>
bibtex  : <<Dr. Strangelove or: How {{I}} Learned to Stop Worrying and Love the Bomb>>

<none>  : <<The Multiobjective Traveling Salesman Problem: A Survey and a New Approach>>
bibtex  : <<The {{Multiobjective Traveling Salesman Problem}}: A {{Survey}} and a {{New Approach}}>>

<none>  : <<Classical signature of quantum annealing>>
bibtex  : <<Classical Signature of Quantum Annealing>>

<none>  : <<Defining and detecting quantum speedup>>
bibtex  : <<Defining and Detecting Quantum Speedup>>

de      : <<Sozialpolitik und Sozialstaat: Soziologische Analysen>>
bibtex  : <<Sozialpolitik und {{Sozialstaat}}: Soziologische {{Analysen}}>>

<none>  : <<Effect of immobilization on catalytic characteristics of saturated Pd-N-heterocyclic carbenes in Mizoroki-Heck reactions>>
bibtex  : <<Effect of Immobilization on Catalytic Characteristics of Saturated {{Pd-N-heterocyclic}} Carbenes in {{Mizoroki-Heck}} Reactions>>

<none>  : <<High-speed Digital-to-RF converter>>
bibtex  : <<{{High-speed Digital-to-RF}} Converter>>

<none>  : <<Some remarks on ’t Hooft’s S-matrix for black holes>>
bibtex  : <<Some Remarks on {{'t Hooft's}} {{S-matrix}} for Black Holes>>

por     : <<In memoriam, na cidade>>
bibtex  : <<In memoriam, na cidade>>

<none>  : <<Norm and Action. A Logical Enquiry>>
bibtex  : <<Norm and {{Action}}. A {{Logical Enquiry}}>>

<none>  : <<The physical volcanology of the 1600 eruption of Huaynaputina, southern Peru>>
bibtex  : <<The Physical Volcanology of the 1600 Eruption of {{Huaynaputina}}, Southern {{Peru}}>>

fr      : <<Critique d'une métanotion fonctionnelle. La notion (trop) fonctionnelle de « notion fonctionnelle »>>
bibtex  : <<Critique d'une m{\'e}tanotion fonctionnelle. {{La}} notion (trop) fonctionnelle de \enquote{notion fonctionnelle}>>

Sorry for the delay, but I’m willing to get to the bottom of this; might take a while though. In any case, your list of examples will be very helpful.
A few things I spotted straight away:

non-English items

If an entry is not English, and the export format is biblatex, just leave it the title as it is.

Of course I’m assuming that exported biblatex items receive a valid non-English langid tag.

If an entry is not English, and the export format is bibtex, I’d recommend simply protecting the whole title (and other title-like fields); a single pair of curly braces is sufficient.

\enquote{notion fonctionnelle}: this requires loading the csquotes package – is this intended?
The A in Norm and {{Action}}. A {{Logical Enquiry}} needs to be protected, too – or else it appears in APA as Norm and Action. a Logical Enquiry.
All examples of Zotero title fields that use title case do not follow what Zotero/CSL considers to be best practice, and since there are many of them I find that highly confusing. Could we change these, or at least most of them?

In general, if you want to try things for yourself, the most relevant tests are

Compare BBT’s output with the output of Zotero/citeproc-js – case should be identical.

Compare the output of (a.) biblatex-apa using BBT’s biblatex output, and (b.) apacite using BBT’s bibtex output with the original title in Zotero – again, case should be identical.

Thanks for your comments. In order:

OK, so titlecase + preserve for english (or no language specified, assumed english), or no changes + make sure a langid is present (this is the current behavior in the branch I'm working on)
csquotes is only enabled if you set a hidden pref that specifies which character pairs you want to replace -- if the hidden pref is non-empty, the assumption is you will have loaded csquotes. The pref is empty by default.
Gotcha. Done.
Sure, you can change them however you like, and I'll regenerate. The strings are here

As to testing myself

yes please
how do I do this for Zotero/citeproc-js
can you set up the MWE for the biblatex case? I'll add the references later.

testing / 2.: see edit above

BTW, why the simpler {{<everything>}} format for BibTeX? I mean, if BibTeX applies case folding, wouldn't you want to have that possible, and if it doesn't, why is the protection necessary? Would it have to be {{{<everything>}}} for similar reasons we do it for biblatex?

Current state (these are all tests that are currently failing. Most of these will be trivially correct, and on your say-so, I'll just mark them in the test set. I'll get started on the Zotero/Citeproc verification.
test/fixtures/export/Better BibLaTeX.007.json
fr-FR   : [Test of markupconversion: Italics, bold, superscript, subscript, and small caps: Mitochondrial DNA2 sequences suggest unexpected phylogenetic position of Corso-Sardinian grass snakes (Natrix cetti) and do not support their species status, with notes on phylogeography and subspecies delineation of grass snakes.]
biblatex: {Test of markupconversion: Italics, bold, superscript, subscript, and small caps: Mitochondrial DNA\textsubscript{2} sequences suggest unexpected phylogenetic position of Corso-Sardinian grass snakes (\emph{Natrix cetti}) and \textbf{do not} support their \textsc{species status}, with notes on phylogeography and subspecies delineation of grass snakes.}

test/fixtures/export/Dollar sign in title not properly escaped #485.json
<none>  : [The largest U.S. companies would owe $620 billion in U.S. taxes on the cash they store in tax havens, the equivalent of our defense budget. [Tweet]]
biblatex: {The Largest {{U.S}}. Companies Would Owe \$620 Billion in {{U.S}}. Taxes on the Cash They Store in Tax Havens, the Equivalent of Our Defense Budget. [{{Tweet}}]}

test/fixtures/export/map csl-json variables #293.json
dan     : [En ny sociologi for et nyt samfund. Introduktion til Aktør-Netværk-Teori]
biblatex: {En ny sociologi for et nyt samfund. Introduktion til Aktør-Netværk-Teori}

test/fixtures/export/map csl-json variables #293.json
fr-FR   : [La démocratie. Sa nature, sa valeur]
biblatex: {La démocratie. Sa nature, sa valeur}

test/fixtures/export/Export Forthcoming as Forthcoming.json
<none>  : [Social Capital Predicts Happiness: World-Wide Evidence From Time Series]
biblatex: {Social {{Capital Predicts Happiness}}: {{World-Wide Evidence From Time Series}}}

test/fixtures/export/biblatex; Language tag xx is exported, xx-XX is not #380.json
fr-FR   : [Le poêle de Descartes]
biblatex: {Le poêle de Descartes}

test/fixtures/export/Normalize date ranges in citekeys #356.json
fr-FR   : [Œuvres de Descartes]
biblatex: {Œuvres de Descartes}

test/fixtures/export/markup small-caps, superscript, italics #301.json
fr-FR   : [Les interventions éclairées devant la Cour européenne des droits de l'homme ou le rôle stratégique des amici curiae]
biblatex: {Les interventions \emph{éclairées} devant la Cour européenne des droits de l'homme ou le rôle stratégique des \emph{amici curiae}}

test/fixtures/export/markup small-caps, superscript, italics #301.json
fr-FR   : [Opinion et conseil dans la doctrine juridique savante (<sc>xii</sc>e-<sc>xiv</sc>e siècles)]
biblatex: {Opinion et conseil dans la doctrine juridique savante (\textsc{xii}\textsuperscript{e}-\textsc{xiv}\textsuperscript{e} siècles)}

test/fixtures/export/don't escape entry key fields for #296.json
fr-FR   : [Les actes de l’Administration [1949-1950]]
biblatex: {Les actes de l’Administration [1949-1950]}

test/fixtures/export/bookSection is always converted to @inbook, never @incollection #282.json
fr-FR   : [Problèmes d’organisation de l’Administration [1966-1967]]
biblatex: {Problèmes d’organisation de l’Administration [1966-1967]}

test/fixtures/export/Better BibTeX does not use biblatex fields eprint and eprinttype #170.json
<none>  : [Lieb-Robinson bounds, Arveson spectrum and Haag-Ruelle scattering theory for gapped quantum spin systems]
biblatex: {{{Lieb-Robinson}} Bounds, {{Arveson}} Spectrum and {{Haag-Ruelle}} Scattering Theory for Gapped Quantum Spin Systems}

test/fixtures/export/Capitalisation in techreport titles #160.json
<none>  : [Salmonella in Pork (SALINPORK): Pre-harvest and Harvest Control Options Based on Epidemiologic, Diagnostic and Economic Research: Final Report]
biblatex: {\emph{Salmonella} in {{Pork}} ({{SALINPORK}}): {{Pre-harvest}} and {{Harvest Control Options Based}} on {{Epidemiologic}}, {{Diagnostic}} and {{Economic Research}}: {{Final Report}}}

test/fixtures/export/German Umlaut separated by brackets #146.json
German  : [Planung öffentlicher Elektrizitätsverteilungs-Systeme]
biblatex: {Planung öffentlicher Elektrizitätsverteilungs-Systeme}

test/fixtures/export/Better BibLaTeX.021.json
en      : [(Liquid+liquid) equilibrium of {water+phenol+(1-butanol, or 2-butanol, or tert-butanol)} systems]
biblatex: {({{Liquid}}+liquid) Equilibrium of \{water+phenol+(1-Butanol, or 2-Butanol, or Tert-Butanol)\} Systems}

test/fixtures/export/Better BibLaTeX.016.json
<none>  : [The physical: violent volcanology of the 1600 eruption of Huaynaputina, southern Peru]
biblatex: {The Physical: Violent Volcanology of the 1600 Eruption of {{Huaynaputina}}, Southern {{Peru}}}

test/fixtures/export/autoexport.json
<none>  : [Comparing archival policies for Blue Waters]
biblatex: {Comparing Archival Policies for {{Blue Waters}}}

test/fixtures/export/autoexport.json
<none>  : [Application centric energy-efficiency study of distributed multi-core and hybrid CPU-GPU systems]
biblatex: {Application Centric Energy-Efficiency Study of Distributed Multi-Core and Hybrid {{CPU-GPU}} Systems}

test/fixtures/export/autoexport.json
<none>  : [An overview of CMIP5 and the Experiment Design]
biblatex: {An Overview of {{CMIP5}} and the {{Experiment Design}}}

test/fixtures/export/thesis zotero entries always create  bibtex entries #307.json
nob     : [CTR Det multiple arkæologiske objekt. Et studie af materialitet og arkæologiske tekstiler]
biblatex: {CTR Det multiple arkæologiske objekt. Et studie af materialitet og arkæologiske tekstiler}

test/fixtures/export/Export of creator-type fields from embedded CSL variables #365.json
<none>  : [A film]
biblatex: {A Film}

test/fixtures/export/Export of creator-type fields from embedded CSL variables #365.json
<none>  : [A report]
biblatex: {A Report}

test/fixtures/export/Export of creator-type fields from embedded CSL variables #365.json
<none>  : [Dr. Strangelove or: how I learned to stop worrying and love the bomb]
biblatex: {Dr. {{Strangelove}} or: How {{I}} Learned to Stop Worrying and Love the Bomb}

test/fixtures/export/Export of creator-type fields from embedded CSL variables #365.json
en      : [The one with the Princess Leia fantasy]
biblatex: {The One with the {{Princess Leia}} Fantasy}

test/fixtures/export/arXiv identifiers in BibLaTeX export #460.json
<none>  : [BV Master Action for Heterotic and Type II String Field Theories]
biblatex: {{{BV Master Action}} for {{Heterotic}} and {{Type II String Field Theories}}}

test/fixtures/export/arXiv identifiers in BibLaTeX export #460.json
<none>  : [Classical signature of quantum annealing]
biblatex: {Classical Signature of Quantum Annealing}

test/fixtures/export/arXiv identifiers in BibLaTeX export #460.json
<none>  : [Defining and detecting quantum speedup]
biblatex: {Defining and Detecting Quantum Speedup}

test/fixtures/export/Ignoring upper cases in German titles #456.json
de      : [Sozialpolitik und Bevölkerungsprozeß]
biblatex: {Sozialpolitik und Bevölkerungsprozeß}

test/fixtures/export/Ignoring upper cases in German titles #456.json
de      : [Schwindet die integrative Funktion des Sozialstaates?]
biblatex: {Schwindet die integrative Funktion des Sozialstaates?}

test/fixtures/export/Capitalize all title-fields for language en #383.json
en      : [A carbocyclic carbene as an efficient catalyst ligand for C–C coupling reactions]
biblatex: {A Carbocyclic Carbene as an Efficient Catalyst Ligand for {{C–C}} Coupling Reactions}

test/fixtures/export/Capitalize all title-fields for language en #383.json
en      : [Alkanethiolate gold cluster molecules with core diameters from 1.5 to 5.2 nm]
biblatex: {Alkanethiolate Gold Cluster Molecules with Core Diameters from 1.5 to 5.2~{{nm}}}

test/fixtures/export/Capitalize all title-fields for language en #383.json
en      : [A stochastic model of TCP Reno congestion avoidance and control]
biblatex: {A Stochastic Model of {{TCP Reno}} Congestion Avoidance and Control}

test/fixtures/export/Capitalize all title-fields for language en #383.json
en      : [Effect of immobilization on catalytic characteristics of saturated Pd-N-heterocyclic carbenes in Mizoroki-Heck reactions]
biblatex: {Effect of Immobilization on Catalytic Characteristics of Saturated {{Pd-N-heterocyclic}} Carbenes in {{Mizoroki-Heck}} Reactions}

test/fixtures/export/Capitalize all title-fields for language en #383.json
fr-FR   : [Estimateur d'un défaut de fonctionnement d'un modulateur en quadrature et étage de modulation l'utilisant]
biblatex: {Estimateur d'un défaut de fonctionnement d'un modulateur en quadrature et étage de modulation l'utilisant}

test/fixtures/export/Capitalize all title-fields for language en #383.json
en      : [High-speed Digital-to-RF converter]
biblatex: {{{High-speed Digital-to-RF}} Converter}

test/fixtures/export/Capitalize all title-fields for language en #383.json
en      : [Pleistocene Homo sapiens from Middle Awash, Ethiopia]
biblatex: {Pleistocene \emph{{{Homo sapiens}}} from {{Middle Awash}}, {{Ethiopia}}}

test/fixtures/export/Capitalize all title-fields for language en #383.json
<none>  : [Some remarks on ’t Hooft’s S-matrix for black holes]
biblatex: {Some Remarks on {{’t Hooft’s}} {{S-matrix}} for Black Holes}

test/fixtures/export/Sorting and optional particle handling #411.json
pt      : [Catalogo dos livros, que se haõ de ler para a continuaçaõ do diccionario da lingua Portugueza: mandado publicar pela Academia Real das Sciencias de Lisboa]
biblatex: {Catalogo dos livros, que se haõ de ler para a continuaçaõ do diccionario da lingua Portugueza: mandado publicar pela Academia Real das Sciencias de Lisboa}

test/fixtures/export/Sorting and optional particle handling #411.json
<none>  : [In memoriam, na cidade]
biblatex: {In Memoriam, Na Cidade}

test/fixtures/export/(non-)dropping particle handling #313.json
<none>  : [(abbé d' Aubignac) (François Hédelin)]
biblatex: {{{(abbé d' Aubignac) (François Hédelin)}}}

test/fixtures/export/(non-)dropping particle handling #313.json
<none>  : [(Aubignac) (François Hédelin, abbé d')]
biblatex: {{{(Aubignac) (François Hédelin, abbé d')}}}

test/fixtures/export/(non-)dropping particle handling #313.json
en      : [Norm and Action. A Logical Enquiry]
biblatex: {Norm and {{Action}}. {{A Logical Enquiry}}}

test/fixtures/export/(non-)dropping particle handling #313.json
en      : [Reading HLA Hart's: The Concept of Law]
biblatex: {Reading {{HLA Hart}}'s: \emph{{{The Concept}} of {{Law}}}}

test/fixtures/export/(non-)dropping particle handling #313.json
<none>  : [Citations, Out of the Box]
biblatex: {Citations, {{Out}} of the {{Box}}}

test/fixtures/export/(non-)dropping particle handling #313.json
<none>  : ["I have a dream" : the quotations of Martin Luther King JR]
biblatex: {"{{I}} Have a Dream" : The Quotations of {{Martin Luther King JR}}}

test/fixtures/export/key migration.json
<none>  : [The physical volcanology of the 1600 eruption of Huaynaputina, southern Peru]
biblatex: {The Physical Volcanology of the 1600 Eruption of {{Huaynaputina}}, Southern {{Peru}}}

bibtex: Of course we want case folding for titles of English items when using bibtex, but we don’t want that for non-English items. Since bibtex, unlike biblatex, does not have anything like a langid field and no mechanism for making case conversion language-dependent, the easiest solution is to protect all titles etc. of non-English items, wholesale, by wrapping the complete title in curly braces, one pair being sufficient.
With very few specific exceptions, one pair of curly braces is sufficient for protecting against case conversion.
The exceptions are strings that start with a latex command:

\emph{Blah} as is inhibits case conversion,
{\emph{Blah}} enables case conversion, and
{{\emph{Blah}}} again inhibits case conversion.

This seems to be true for both bibtex and biblatex.
I tend to think that previously we considered 3., but not 2.; – and since 3. requires two pairs, I think you found it easier to use two pairs everywhere.
However, now I guess a better strategy would be to wrap, in a first step, all latex commands in one pair of braces, and in a second step, on top of that, wrap everything that needs to be protected (either because in Zotero it is inside ... or because in contains at least one uppercase character) against case conversion in a (possibly another) pair of braces.

Oh, right, I didn't get that: protect case-conversion-sensitive fields wholesale for Better BibTeX unless the language is English.
The second part, that staged solution is non-trivial to implement, since the generator would have to be context aware for chunks of text. If the current solution is adequate, that has my preference for pragmatic reasons.

Ok, both Better BibTeX and Better BibLaTeX export a Zotero title This is really, really good (both with an empty language field and with language en-US) to title = {This is really, {\emph{really}} good}, – so the number of braces looks good to allow style-dependent case conversion, and hence it seems you wouldn’t have to change the  current solution – but upon export this title should also have been converted to title case, i.e., title = {This Is Really, {\emph{Really}} Good},.

Wait, ugh, now I see case # 2. Jeez. I take it the same goes for \textsc{...}, \\textbf{...}, \\textsuperscript{...}, \textsubscript{...}``? So the proper solution is then to export ... to {\\emph{...}}, and protected text to {{....}}?
Currently, This is really, really good translates to {This Is Really, \emph{Really} Good}, but in my current understanding this should instead be {This Is Really, {\emph{Really}} Good}.

You can fiddle around online with my HTML(ish) to Bib(La)TeX converter here if you want. The latest changes that use {\emph{...}} have been included.

The titlecaser is straight from citeproc-js BTW, so it returns whatever it cooks up. I'm not universally happy with its results though:

How to derive "Ought" from "Is" doesn't titlecase derive
Bodies that matter on the discursive limits of "sex" title-cases of
The city of tomorrow and its {planning} doesn't titlecase planning
Everything from this list

I see the same effects for 1–3 when creating formatted bibliographies from Zotero (by right-clicking on a Zotero item, choosing “Create Bibliography from Item …”, then choosing one of the Chicago styles / “Bibliography” / “Copy to Clipboard”, and finally pasting into a word processor to see the result) – so all of these seem to be citeproc-js, not BBT bugs, most likely having something to do with the quotes in the vicinity …

I've added a simple (bordering on moronic) titlecaser as an option on the test page. The bug in citeproc is longstanding -- I assume it's a hard problem to take on, and not likely to be fixed anytime soon.

Just for the record – pandoc handles 1–3 perfectly well …

As far as I can tell, this is the pandoc titlecaser. I don't know any haskell, but it doesn't look all that different from what my simple titlecaser does.

There are also some issues with hyphenated compounds, and some differences between BBT (using biblatex and citeproc-js title caser export) and citeproc-js itself (in combination with a title-case style).
The Chicago Manual of Style, 16th edition, advises (8.159 Hyphenated compounds in headline-style titles):

Always capitalize the first element.

Capitalize any subsequent elements unless they are articles, prepositions, coordinating conjunctions (and, but, for, or, nor), or such modifiers as flat or sharp following musical key symbols.

If the first element is merely a prefix or combining form that could not stand by itself as a word (anti, pre, etc.), do not capitalize the second element unless it is a proper noun or proper adjective.

Capitalize the second element in a hyphenated spelled-out number (twenty-one or twenty-first, etc.) or hyphenated simple fraction (two-thirds in two-thirds majority). This departure from previous Chicago recommendations recognizes the functional equality of the numbers before and after the hyphen.

citeproc-js itself handles most of these correctly, though for 2.’s flat or sharp, and 3. it seems users need to intervene and insert  where required.
Now BBT (using the citeproc-js title caser) looks a little inconsistent:
Energy-Efficiency,  Multi-Core look good, but
Pre-harvest, Pd-N-heterocyclic, S-matrix, High-speed don’t (expected, and citeproc-js itself: Pre-Harvest, Pd-N-Heterocyclic, S-Matrix, High-Speed).
Also, best practice would suggest High-speed digital-to-RF converter (lowercase ‘d’) in Zotero.
As to (Liquid+liquid) equilibrium of {water+phenol+(1-butanol, or 2-butanol, or tert-butanol)} systems, I would have expected
({{Liquid}}+Liquid) Equilibrium of \{Water+Phenol+(1-Butanol, or 2-Butanol, or Tert-Butanol)\} Systems.
(To get the correct form, “tert-Butanol”, one would also have to italicise and protect the “tert” in Zotero:
(Liquid+liquid) equilibrium of {water+phenol+(1-butanol, or 2-butanol, or tert-butanol)} systems,
output:
({{Liquid}}+Liquid) Equilibrium of \{Water+Phenol+(1-Butanol, or 2-Butanol, or {{\emph{tert}}}-Butanol)\} Systems.)

I've changed the parser so a - is a word-breaker (it was a word-char before), and that gets me the output you describe.
In High-speed digital-to-RF converter, the citeproc titlecaser upper-cases Digital, so that's not of my doing.
Same goes for (Liquid+liquid) equilibrium of {water+phenol+(1-butanol, or 2-butanol, or tert-butanol)}, really.

In High-speed digital-to-RF converter, the citeproc titlecaser upper-cases Digital, so that's not of my doing.

What I meant is that the input format = Zotero title field content in this case should be High-speed digital-to-RF converter – expected output: High-Speed Digital-to-{{RF}} converter.

Same goes for (Liquid+liquid) equilibrium of {water+phenol+(1-butanol, or 2-butanol, or tert-butanol)}, really.

I know, citeproc-js bug, this time apparently in the vincinity of “+”.

What I meant is that the input format = Zotero title field content in this case should be High-speed digital-to-RF converter – expected output: High-Speed Digital-to-{{RF}} converter.

Right, check and done.
So is 8.157 from the CMoS the "algorithm" I would best follow for title casing? I suspect there's a million exceptions, but I could give it a go.

(ugh -- 3 - 6 would require rather fancy natural language processing, and those libraries are yooge. Candidates for future reference: https://github.com/josephmisiti/awesome-machine-learning#javascript-nlp)

So is 8.157 from the CMoS the "algorithm" I would best follow for title casing? I suspect there's a million exceptions, but I could give it a go.

No, really, I did not want to suggest that at all. (The CMoS reference was more intended to point out the “Capitalize any subsequent elements …” rule rather than its exceptions.)
I think the existing title casers (citeproc-js, and BBT, based on citeproc-js) work reasonably well – though of course the known bugs should be fixed.
With the existing title casers, users who need “The E-flat Concerto” or “Anti-intellectual Pursuits” in their formatted titlecase-style bibliographies have to input The E-flat concerto and Anti-intellectual pursuits in Zotero – a bit ugly, but I don’t think this comes up frequently enough to justify rewriting the title caser.

Fair enough. It'd be nice if all this could be hidden behind visual editing rather than hand-editing HTML codes, but that's a matter for another day.
So, is the current implementation good to go then?

Just to verify -- all of emph, textsc, textbf, textsuperscript and textsuperscript get encoded as {\<command>{...}} rather than \<command>{...}, correct? Or is emph somehow special?

And The Largest {{U}}.{{S}}. States has become The Largest {{U.S}}. States, is that OK? Easily changed (I just make an inner-period not a word char), but good to know.

Just to verify -- all of emph, textsc, textbf, textsuperscript and textsuperscript get encoded as {<command>{...}} rather than <command>{...}, correct?

Correct. (see https://www.sharelatex.com/project/57b33143430c01877dce1177)

Hold on: for English/BibTeX, Why Is Apple Launching a New Version of the iPod? ought to become {Why {{Is Apple Launching}} a {{New Version}} of the {{iPod}}?} yeah? So for BibLaTeX, titleCasing + casePreservation always coincide, but for BibTeX not?

So what are the rules again for BibTex for title-like fields? Is it:

If English, apply title case + case preservation
if not, double-brace the whole field

or

If English, apply case preservation
if not, double-brace the whole field

or

If English, do nothing
if not, double-brace the whole field

(I don't have access to that sharelatex project. Also, same for \enquote yeah?)

For BibTex it’s:

If English, apply title case + case preservation
if not, double-brace the whole field

AFAICT, for both BibLaTeX and BibTeX, if English, titleCasing + casePreservation always coincide. (Do you have an example where the two might differ?)

access to that sharelatex project

fixed

Nope, I have no examples, but I just got lost in the discussion, so I needed a recap. The current BibTeX algo is wrong for English, fixing that now.

… same for \enquote …?

Correct. (Again, see https://www.sharelatex.com/project/57b33143430c01877dce1177)

Aw yeah, most tests pass! A little tinkering, tomorrow should be all-green.

I’d change the example that started this thread from (Zotero title field)
Effects of open- and closed-system temperature changes on blood O2-binding characteristics of Atlantic bluefin tuna (Thunnus thynnus)
to
Effects of open- and closed-system temperature changes on blood O2-binding characteristics of Atlantic bluefin tuna (Thunnus thynnus)
No biologist would ever write (or want to have to read) Thunnus Thynnus rather than the correct and, case-wise, unchangeable Thunnus thynnus.

What about {{U}}.{{S}}. vs {{U.S}}.?

No preference. (I can’t even see any differences in kerning.)

In that case, {{U}}.{{S}} is easier to generate safely than {{U.S}}
Do single letters even need protection btw?

Do single letters even need protection btw?

Yes. See new example at: https://www.sharelatex.com/project/57b33143430c01877dce1177

Is type a field that should be subject to case conversion? BBT currently treats it that way, but it sounds odd to me.

Is type a field that should be subject to case conversion?

bibtex’s plain.bst (and possibly other styles, haven’t checked any further) does convert the case of a type field, so: yes.

Super thanks for your help @nickbart1980 .
For verification, this is what gets exported now and will serve as a regression test:
@article{brill_effects_2006,
  author = {Brill, R. W. and Bushnell, P. G.},
  date = {2006-09-23},
  doi = {10.1007/s10695-006-9104-7},
  issn = {0920-1742, 1573-5168},
  journaltitle = {Fish Physiology and Biochemistry},
  langid = {english},
  number = {4},
  pages = {283--294},
  shortjournal = {Fish Physiol Biochem},
  timestamp = {2015-02-24 12:14:36 +0100},
  title = {Effects of Open- and Closed-System Temperature Changes on Blood {{O}}{\textsubscript{2}}-Binding Characteristics of {{Atlantic}} Bluefin Tuna ({{{\emph{Thunnus thynnus}}}})},
  url = {http://link.springer.com/article/10.1007/s10695-006-9104-7},
  urldate = {2016-08-18},
  volume = {32}
}

All tests are one again green, so if the BibLaTeX above is OK, this issue is ready for release.

Problem: <…nocase…> (good) vs. <…nocase…> (bad)
biblatex: {Effects of Open- and Closed-System Temperature Changes on Blood {{O}}{\textsubscript{2}}-Binding Characteristics of {{Atlantic}} Bluefin Tuna ({{{\emph{Thunnus thynnus}}}})},
translated from ... Thunnus thynnus ... see here
is ok: my bibtex-sentencecase and biblatex-sentencecase tests (see here) render this as “Thunnus thynnus”.
But biblatex: {Effects of Open- and Closed-System Temperature Changes on Blood {{O}}{\textsubscript{2}}-Binding Characteristics of {{Atlantic}} Bluefin Tuna ({\emph{{{Thunnus thynnus}}}})}
translated from ... Thunnus thynnus ... see here
is not: the same bibtex-sentencecase and biblatex-sentencecase tests render this as “thunnus thynnus”. Arrrgh!
I have no clear idea how to deal with this:
Possibly transform
Thunnus thynnus
to
Thunnus thynnus
first?
But then we’d also have to transform
tasty Thunnus thynnus
to
tasty Thunnus thynnus.
Does that seem even remotely possible?

If you ask a software engineer "is it remotely possible", the answer is going to be "yes", unless it involves a logical contradiction (and even then, the software engineer will try anyhow).
Is it sensibly possible... for this particular case, yes, but a general transform of the markup to something semantically the same... I don't know. It's easy enough to detect in the internal representation that I have an i with a single child span.nocase and swap them. Breaking up and recombining is a whole different matter with freely nestable markup.
Another option perhaps is that I could see whether the span.nocase lives (somewhere) under an i and then spit out extra markup to make sure the case protection "takes"... if that's possible in a context-free way.
Is there really no other way beyond brace-balancing to tell Bib(La)TeX to back the &^*^#@ off from a particular chunk of text?

Is there really no other way beyond brace-balancing to tell Bib(La)TeX to back the &^*^#@ off from a particular chunk of text?

Nothing I’m aware of. Maybe consult TSE?

I guess... re-arranging the markup is going to be so fragile, I'd really, really rather not.

Assuming I've found a way to morph the markup so span.nocase nodes only occur at the "root" level, would that mean we could just use stuff like \emph{...} instead of {\emph{...}}?

Because I can currently turn
tasty Thunnus thynnus
into
tasty Thunnus thynnus
which in turn becomes
{\emph{Tasty }}{{{\emph{Thunnus thynnus}}}}
or \emph{Tasty }{{\emph{Thunnus thynnus}}} if we dispense of {\emph{...}}.
Is this what we're looking for? Because I think I have that. Wasn't as hard as I thought after all.

Uh, wait, the reshuffling breaks titlecasing. I need to think some more about this.

Hey, no, it was just the language guesser being thrown off. Uh, I think I have it?

Nice … except for {\emph{Foo}} in initial position – see https://github.com/plk/biblatex/issues/459

Oh you have got to be shitting me... yes, it's fixable, but it's a terrible hack. How does { \emph{Foo}} fare? I mean is it just if the first "content" is markup, I don't double brace, or is it really "If the field actually has \ as the first char"?

Seems to be the \ as the first char after the {:
title = "{ \emph{Foo}}" → “ Foo”;
title = "{\ \emph{Foo}}" → “ FOO”.

If I enter those into the MWE, all three versions I entered yield Foo (albeit one with a leading space).

Oh wait, the quotes.
This is nuts. With this:
@article{56a, author = {56a}, title = {{\emph{Foo}}}}
@article{56b, author = {56b}, title = {{\ \emph{Foo}}}}
@article{56c, author = {56c}, title = {{ \emph{Foo}}}}

I get
FOO
 FOO
 Foo

Which means "slash-command at pos 0" is not a deterministic rule for deciding whether I should brace or not.

Wait, what? "If there is a slash at the start of the title field, whatever follows it, don't plus-brace any slash commands" is the rule?
Oy.

The test page has been updated with the new behavior. Does this affect both BibTeX and BibLaTeX, or only BibLaTeX?

Oh wait no you said that, only BibLaTeX. Test page updated again.

BTW, for non-english, something like {Actes du 4\textsuperscript{ème} Congrès Français d'Acoustique} should always work, right? No need to wrap that \textsuperscript{...}, correct?
Uh, now that I think about it, stuff like textsuperscript{...} should probably be {\textsuperscript{...}}?

Correct. None of all this is relevant for non-English items.

OK. Just for verification, the combo of title casing and nocase-unwrapping can turn ostensibly simple markup into fairly gnarly-looking BibLaTeX

Also this. If that all looks OK to you, it looks like we're there.

All tests green.

Ok, I’m not seeing any unexpected behaviour any more either.

OK, so good to go then? @kallisons, happy with the current output?

Re this: Output is of course ok given this input, but best practice for Zotero would suggest this (lowercase “structure” and “argument”). Besides being the only way to get correct output from bibtex and biblatex in sentence-case styles, I’d maintain errors are much easier to spot that way.

OK, I've made that change and the tests are green again.
So, done? Apologies for the incessant call for confirmation, but this was a big change, code-wise.

Done? I think so, for now.

Al right, then I'm bundling this with two other issues and will put out a release. Thanks for your help, indispensable as always.

@nickbart1980, what is your opinion of the use of \mkbibquote{...} vs \enquote{...}? From what I can gather, mkbibquote does what enquote does in bibtex but allows for redefinition. Is mkbibquote available wherever enquote is?

mkbibquote seems to be available whenever biblatex is loaded, even if the csquotes package is not (biblatex v 3.5 manual, “4.10.4 Auxiliary Commands and Hooks”).

So I could always generate that instead of enquote? That would seem like an improvement.

If using biblatex, yes.


Create devcontainer.json

Hello,
Could you please provide more information about your PR?
The purpose is a bit unclear, at least for me 🙂


rpc: tweaked the block search test

Improved the BlockSearch test within the RPC to make sure it matches against a value if the block events are generated.
The previous version had a query that would never match and this way it is harder to test whether indexing was performed correctly.

PR checklist

[x ] Tests written/updated
[ ] Changelog entry added in .changelog (we use unclog to manage our changelog)
[ ] Updated relevant documentation (docs/ or spec/) and code comments

Should this be backported?

I added the backport labels, confirmed it works on all branches, but will need some tweaking for 0.34 as it has this match_events keyword. I'll take care of it.


ADD-USAT

Solicitud de adición a dominios a la Universidad Católica Santo Toribio de Mogrovejo.
Pagina WEB
http://www.usat.edu.pe/

@enichocordova First stage of verification passed, official domain is usat.edu.pe as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@enichocordova Thank you for your patience while waiting for a review and processing your request. Pull request merged.


git clone to local, open it with vscode and  will find that Cargo.lock has changed

git clone to local, open it with vscode and you will find that Cargo.lock has changed。
diff --git a/Cargo.lock b/Cargo.lock
index 5ddc1b3..fa86f11 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -1370,6 +1370,12 @@ dependencies = [
  "pin-project-lite",
 ]

+[[package]]
+name = "http-range-header"
+version = "0.4.0"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "3ce4ef31cda248bbdb6e6820603b82dfcd9e833db65a43e997a0ccec777d11fe"
+
 [[package]]
 name = "httparse"
 version = "1.8.0"
@@ -1815,6 +1821,16 @@ version = "0.3.17"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "6877bb514081ee2a7ff5ef9de3281f14a4dd4bceac4c09388074a6b5df8a139a"

+[[package]]
+name = "mime_guess"
+version = "2.0.4"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "4192263c238a5f0d0c6bfd21f336a313a4ce1c450542449ca191bb657b4642ef"
+dependencies = [
+ "mime",
+ "unicase",
+]
+
 [[package]]
 name = "minimal-lexical"
 version = "0.2.1"
@@ -3829,8 +3845,14 @@ dependencies = [
  "http",
  "http-body",
  "http-body-util",
+ "http-range-header",
+ "httpdate",
+ "mime",
+ "mime_guess",
+ "percent-encoding",
  "pin-project-lite",
  "tokio",
+ "tokio-util",
  "tower-layer",
  "tower-service",
  "tracing",
@@ -3991,6 +4013,15 @@ dependencies = [
  "unic-common",
 ]

+[[package]]
+name = "unicase"
+version = "2.7.0"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "f7d2d4dafb69621809a81864c9c1b864479e1235c0dd4e199924b9742439ed89"
+dependencies = [
+ "version_check",
+]
+
 [[package]]
 name = "unicode-bidi"
 version = "0.3.13"
~

Hi @fan-tastic-z can you tell us what you are trying to do?

Hi @fan-tastic-z can you tell us what you are trying to do?

I want to see the recent code change records locally, but after cloning the code，open it with vscode and you will find that Cargo.lock has changed。Is it because the changes to this file were not submitted when the code was submitted before?

@jondot i think we should delete all the Cargo.lock and put it in .gitignore

@jondot i think we should delete all the Cargo.lock and put it in .gitignore

yes

Thanks.
remove in this commig: https://github.com/loco-rs/loco/commit/487d3cff4d67d8f0400f6dc2a9d3099c7459a9a3


Javascript enabled in Webkit

Javascript is enabled, Java is enabled, and popups are allowed inside of the webkit interface.

This is be design.


Consider using relative URLs in index.html

Something like this. It makes it easier for folks serving this locally and from different paths.

Done, thanks for your improvements to the code!


🐞 [Bug]: Can't use add_worker in the same script as deploy k8s with Mycelium option is added

Is there an existing issue for this?

[X] I have searched the existing issues

which package/s did you face the problem with?
grid_client
What happened?
I can deploy a K8s master and worker with Mycelium, but it will fail if I add a worker in the same script with the add_worker function and then run them together.
Steps To Reproduce
If you want to try, you can use the k8s test file; just change all the Mycelium options to turn true and run it; it will fail.
which network/s did you face the problem on?
Dev
version
.
Twin ID/s
No response
Node ID/s
No response
Farm ID/s
No response
Contract ID/s
No response
Relevant screenshots/screen records

Relevant log output
ValidationError: Another mycelium seed is used for this network vh71o5bpbu9q34g on this 167

Work in Progress (WIP):
Checking myceliumSeeds and how script works

Work Completed:

Check if myceliumNetworkSeed.seed is existed.
Remove .skip from add worker test case.

A similar issue happens when adding a worker via the Dashboard

Blocked on 3680 as now I got the same error

faced this issue again on dashboard

it's blocked on https://github.com/threefoldtech/tfgrid-sdk-ts/issues/3509

the deployment works fine but the test keeps failing
may be we shall check the validation or assertions


this question proved confusing in testing so reworded it

Makes much better sense to me :+1:

Probably needs an accompanying  version number update in VERSION.txt


Revert aufs fine locks

Reverts 890b9db3280739cfa168e4787b7155c8f08ad6ae
Why? Layers are not being mounted properly.
Why didn't we see this before merge? CI is using vfs... I use vfs when running integration tests as well due to issues with many tests in dind running aufs-over-aufs.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "revert_aufs_fine_locks" git@github.com:cpuguy83/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

LGTM :sweat:

:cry:

due to issues with many tests in dind running aufs-over-aufs.

Possibly I don't understand, but if /var/lib/docker is marked a volume in the dind container, we wouldn't be running aufs-on-aufs?

but LGTM

Yes, but the daemon suite spins up data dirs elsewhere.

What if we made /tmp a volume, and have those all create a tmpdir and use that? IIRC, using vfs had a massive impact on the duration of the tests, so sounds like a win to me

Updated to not revert the extra log info in from the unmount command.

LGTM

The experimental is currently failing on #20543.


⚠ gorzdrav.org has degraded performance

In eaf7ec0, gorzdrav.org (https://gorzdrav.org) experienced degraded performance:

HTTP code: 200
Response time: 5223 ms

Resolved: gorzdrav.org performance has improved in d45b4ef.


fixed report path issue for TFS plugin

fixed report path issue for TFS plugin, code needs to be committed to Jenkins plugin for long term support.
CPE QCIM1J93134 How to configure Microsoft TFS 'Copy Publish Artifact' task, for API Testing results
JIRA ticket: JENKINS-44364
https://issues.jenkins-ci.org/projects/JENKINS/issues/JENKINS-44364
AGM defect number: 35681

Approved for test build

:x: Build hpe-application-automation-tools-plugin latest.70-jwfngbnl failed (commit https://github.com/hpsa/hp-application-automation-tools-plugin/commit/ee1c2f83d2 by @)


Add python 3.11 and 3.12 builds

Codecov Report

Merging #155 (e40569b) into main (c54133d) will decrease coverage by 40.99%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main     #155       +/-   ##
===========================================
- Coverage   75.50%   34.52%   -40.99%
===========================================
  Files          27       27
  Lines        1825     1825
===========================================
- Hits         1378      630      -748
- Misses        447     1195      +748

Flag
Coverage Δ

unittests
34.52% <ø> (-40.99%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 18 files with indirect coverage changes


Implementing multithreaded strategies

https://github.com/calumrussell/alator/issues/33 - refers to issue but this is unlikely to close this issue fully

The initial execution model of backtests was explicitly vertical: Strategy holds reference to Broker, Broker holds reference to Exchange, create shared DataSource/Clock structs, and then pass the Strategy to a SimContext that executes the loop through repeated calls to the top-most element Strategy (which then opens the call stack to Broker which then goes to Exchange).
This model works very effectively in a single-threaded context: clear distinction with shared components, no questions around message-passing between components (they are either shared or hierarchical), and lookahead bias can be removed because Broker is fully responsible for reconciling with Exchange (although the guards that exist within Broker/Exchange are complex).
This model, however, does not work in a multi-threaded context. Broker cannot control the flow of Exchange because there will be multiple strategies operating against it. And Broker itself ceases to become a general Broker for all strategies to execute against but must hold state for each strategy (for example, Broker tracks the cost basis of positions, this is something that may be used as an input for a strategy, but if there are multiple strategies with multiple positions then the cost basis ceases to make sense).
Therefore, implementing multithreaded strategies requires changing the execution model of backtests.

Exchange and Broker need to be fully separated. Responsibility for managing Exchange state must move up to SimContext. At this stage, it seems likely that Exchange will either need to be shared between Broker or that Brokers emit orders that are then passed to Exchange within SimContext main loop. Could use channels to communicate (would probably need broadcast/mpmc) completed orders from Exchange to Broker.
Broker renamed to something like Bookkeeper reflecting the fact that the main purpose is really to record changes to state, and provide calculations against that state to Strategy.
Strategy can run concurrently (i.e. generating new orders in response to price or external data) but the rest of the trade loop runs synchronously. Exchange could become multi-threaded but synchronous execution within the exchange ensures no lookahead bias (for example, a Strategy issuing an order that is executed instantaneously rather than on the next tick).
Clear separation between exchange and strategy code. The control flow code that guards against lookahead bias is effective but extremely confusing. With clear separation, we should know that it is impossible for strategy code to execute an order instantaneously. There is a reason for the current complexity - one of the big issues is actually not execution but how to handle things like cash shortages when you cannot liquidate positions immediately - but is some overlap in code between Broker and Exchange. Splitting these concerns will make it easier to reason about the system.
Communication between separate components, referred to in point 1. Once the components are separate, we need certain events to be communicated to strategy code: for example, settling cash against completed trades.

https://github.com/calumrussell/alator/pull/34/commits/8f8063b6d0aac0c05e0ee0be3c440ccd3c86d1da
This proved to be problematic due to Broker depending on Exchange for prices, this (not order passing) was the main difficulty with implementation.

Split corporate events away from prices. Binding these two was a decision made without thought but is causing an issue with how Broker is defined.
Look again at how prices move between Broker and Exchange. Creation of last_seen_quote cache on Exchange meant that Broker had to be only source and would resolve missing data. Would it be helpful to do a channel here?
Regression in perf (most probably) with changes to DataSource trait. There was no other option but to use Arc for V in HashMap but this seems to mean cloning Vec on get_quotes. Surely some way around this.

Also need to go back over Clock, this code was already quite loose but has turned into a mess with clients managing locks which shouldn't happen.
It feels like it will be possible to make the changes to Strategy from here but it may make sense to do a re-write for separate multi-threaded components if performance really is terrible (for the commit above, cargo bench is saying 13% improvement on full backtest...which makes no sense).

Tried to do limited rewrite but it was impossible due to structural changes required for the move from sync to async execution. Communication between exchange and broker is now all through channels.
Tests in exchange almost all had to be removed, so need to add back. Broker needs to be added back. Broker needs to be rewritten as Bookkeeper. Need to move the exchange into a separate package at some point.


opening files - issue - feature request

I think sometimes, if you don't change a file, and click on the other one which is in a different folder is pretty annoying. The file you have opened (looked for 3 minutes) just suddenly disappears.
1, It would be very handy, if the "Open editors" might not be sync with the opened files in the editor.
(so you haven't hundreds of files opened), but my file won't be disappeared.
2, The second thing is, it would be nice, if the "open editors" would be structured. (so if you opened more than one file from the same folder than it shows a tree list with the directory name - only the last directory - so not a whole structure) and show one file per folder, if you haven't changed the file,
but if you  have clicked again from the open editors, open the other file also.
It would be tricky, but very handy and nice feature.

This feature request will not be considered in the next 6-12 months roadmap and as such will be closed to keep the number of issues we have to maintain actionable. Thanks for understanding and happy coding!


USF-1132: Refactor nav tree for implementation guidance

This pull request (PR) refactors the left nav tree to provide a flatter structure for #73 based on stakeholder feedback.
Staging
https://commerce-docs.github.io/microsite-commerce-storefront/discovery
New

Old

PM approved structure. I'll create separate PRs to continue optimizing content according to the new structure.
That'll include consolidating pages and clarifying discovery for customers with existing Adobe Commerce storefronts (Luma, PWA Studio).


resin-cli: Usage of .local in the push command does not work

The usage of <short-uuid>.local in the push command does not work and results
in a error of the type:
Push failed. Error: Error while inspecting image local-app: Error: getaddrinfo ENOTFOUND

Instead using the IP address or just the <short-uuid> works as expected.
I have submitted a PR: #834 to fix this.

@pimterry Should this be closed too?

Good spot, thanks! (More details in #834, if anybody else hits this)


Add missing [Shift] in key binding

Shift was missing from these two key bindings. Minor oversight.

Docs Build status updates of commit b01d6a4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

TerminalDocs/selection.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Looks good. Thanks!


Lovelace - Utility

Here is a panel for two cupboards I use as a utility.

Originally posted by @jcallaghan in https://github.com/jcallaghan/home-assistant-config/issues/207#issuecomment-655783223

Vertical and horizontal stacks

cards:
  - cards:
      - entity: light.washing_machine_cupboard_light
        hold_action:
          action: more-info
        icon_height: 75px
        name: Washing Machine
        show_icon: true
        show_name: true
        tap_action:
          action: toggle
        type: button
      - entity: light.understairs_cupboard_light
        hold_action:
          action: more-info
        icon_height: 75px
        name: Understairs
        show_icon: true
        show_name: true
        tap_action:
          action: toggle
        type: button
    type: horizontal-stack
  - cards:
      - entities:
          - entity: binary_sensor.washing_machine_cupboard_motion
          - entity: sensor.washing_machine_cupboard_motion_lux
        show_name: false
        type: glance
      - entities:
          - entity: binary_sensor.understairs_cupboard_motion
          - entity: sensor.understairs_cupboard_motion_lux
        show_name: false
        type: glance
    type: horizontal-stack
  - cards:
      - detail: 2
        entity: sensor.washing_machine_cupboard_motion_temperature
        graph: line
        name: Washing Machine
        type: sensor
      - detail: 2
        entity: sensor.understairs_cupboard_motion_temperature
        graph: line
        name: Understairs
        type: sensor
    type: horizontal-stack
type: vertical-stack

Here is the same example just using two separate vertical stacks.

This is my Utility panel all up - this panel represents my utility cupboards.

I have a primary dashboard that presents each room in the house and also have a mirror of this but it is constructed so it includes all devices, automations, scenes and helpers which I can use to debug stuff as well as use when constructing new automation etc. The primary panel I try to keep as functional as possible but behind the scenes, there can be lots going on. Here is an example:


nothing appears

#80
when i open the web page nothing appears only the top bar dose but nothing loads
Console error
Access to XMLHttpRequest at 'https://api.sayobot.cn/beatmaplist?0=20&1=0&2=1&5=1' from origin 'https://osugame.online' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
VM264 addbeatmaplist.js:353
GET https://api.sayobot.cn/beatmaplist?0=20&1=0&2=1&5=1 net::ERR_FAILED
addBeatmapList @ VM264 addbeatmaplist.js:353
(anonymous) @ hot.html:86
Desktop (please complete the following information):

OS: chromebook Version 93.0.4577.107
Browser: chrome
Version: v1.4.3

Can't observe the issue from here. Not sure if it's an issue of api.sayobot.cn having inconsistent CORS settings across different countries..


Ingress support

Very basic ingress support. Let me know if you want any changes. Need to add all the ingress values into the README.md.
Example values:
ingress:
  enabled: true
  annotations:
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.certresolver: le
  hosts:
    - host: kubetail.mydomain.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - hosts:
        - kubetail.mydomain.com

Looks great! There's an error at L37 though:
$ helm template kubetail charts/kubetail
Error: parse error at (kubetail/templates/ingress.yaml:37): "-en"

I'm new to helm. Is it customary not to document the kubernetes yaml in the values.yaml file (e.g. ingress.annotations)? Makes sense, just checking.

@amorey can you verify now? I also added all ingress values to README.md.

Looks great! Merged into main so the new release should be available momentarily.


port sequence combinators to the new design

for most cases this is not too useful since we can just write a parser function in imperative style, but applying a tuple of parsers in order could still be interesting. The code is in src/sequence/macros.rs. To rewrite:

tuple
do_parse: is it necessary?

My two cents; I feel like keeping the number of macros/combinators to a minimum would be a good thing. One of the things that made it harder for me to get used to the library initially was the vast amount of macros that all looked very similar at a first glance. Though this might already be better if there's better documentation in 5.0.

I want to remove a few combinators, and I'll separate functions in more modules. A big issue with macros was that they are all at the top level, so we often have to look them up in alphabetical order. functions can have a more coherent organization.

the methods combinators and whitespace combinators will move out in other crates, I don't know yet about others

all the sequence combinators are now ported to functions. the tuple combinator stays in macro form, but there is a function version


feat: add some code formatter

What is the purpose of the change
EngineConn-Core defines the the abstractions and interfaces of the EngineConn core functions.
The Engine Service in Linkis 0.x is refactored, EngineConn will handle the engine connection
and session management.
Related issues/PRs
Related issues: #2340
Brief change log

add scalafmt, and add it to spotless,
add spotless pom formatter,
reorganize parent pomfile,
upgrade spotless-maven-plugin to 2.24.1, and add to validate phase
scala-maven-plugin to 4.7.1

Checklist

[x] I have read the Contributing Guidelines on pull requests.
[ ] I have explained the need for this PR and the problem it solves
[ ] I have explained the changes or the new features added to this PR
[ ] I have added tests corresponding to this change
[ ] I have updated the documentation to reflect this change
[ ] I have verified that this change is backward compatible (If not, please discuss on the Linkis mailing list first)
[ ] If this is a code change: I have written unit tests to fully verify the new behavior.

主要修改的就是parent pom文件， 其它大多数是自动格式化引起的

recommit to dev-1.3.0


Custom sysctl

Hi there!
Is there any way to rewrite some sysctl values? You're using /var, it's most prioritize variables.
I'm not sure how to make vars as "default", not mandatory, to be able change them in host/group vars

The sysctl vars aren't meant to be overwritten. If you really want to, you could either change the vars in the vars-file or try putting the whole sysctl.yml content into the defaults/main.yml and overwrite it then. Make sure to empty the vars/sysctl.yml before, or remove the first tasks in the tasks/sysctl.yml.
Also what variable do you want to overwrite?

Disable IPv4 traffic forwarding.
net.ipv4.ip_forward: 1
I'm using your role (and ssh also) for all my instances, including firewalls/gateways

I'm not sure yet, but possible there will be something else incompatible with ipvs, didn't finish testing yet

I'll see if I can put the sysctl-variables in the defaults-file, so it's overwriteable.

It would be great!
Thank you

I hesitate to change this, because if you want to overwrite a single hash in the sysctl dict like this:
---
- name: wrapper playbook for kitchen testing "ansible-os-hardening" with custom vars for testing
  hosts: localhost
  roles:
   - ansible-os-hardening
  vars:
    sysctl_config:
    # Disable IPv4 traffic forwarding.
      net.ipv4.ip_forward: 1

you'll overwrite the whole dict, no only the single hash, meaning only the net.ipv4.ip_forward will actually be used. Unless you change ansibles hash-behaviour to merge. But this is not the default and ansible does not recommend it.
Now I see multiple options here:

put the sysctl-dict in the defaults and hope that the users know that they have to use merge or they read the documentation stating this.
wait for ansible 2.0 before changing this and maybe use the new hash combining feature, but I don't know if this will work.
rewrite the dict to normal variables, but this makes the output of the run ugly. See also issue #18 in this context.
use something like this:

ip_forward: 0
sysctl_config:
  # Disable IPv4 traffic forwarding.
  net.ipv4.ip_forward: {{ip_forward}}

But that can become ugly, too, when we have to define every user-changeable/overwritable variable twice. If we only let the user change certain settings, this would still be fine, but where do you draw the line then?
Keep it the way it currently is and let the user handle it by e.g. creating multiple roles

Right now I prefer the first or last option. What do you think @chris-rock? Let the user overwrite dict variables and then possibly break the whole sysctl-dict or keep it the way it currently is and be less modifiable?

On alternate branch https://github.com/hardening-io/ansible-os-hardening/tree/mv_sysctl_to_defaults I moved the variables to the defaults and changed the docs. What do you guys think?

Hi Sebastian,
Good CAUTION section
From one point of view having the dict with sysctl for all installations is
a good thing, but from another dict vs separate_values - what is the reason
for that except beauty?
If all the values is separated (like os_auth_*, it's not a dict by some
reason) then user is able to change them separately and drawback is only
more tasks in playbook.
Did I miss something?
On Thursday, October 29, 2015, Sebastian Gumprich<EMAIL_ADDRESS>wrote:

On alternate branch
https://github.com/hardening-io/ansible-os-hardening/tree/mv_sysctl_to_defaults
I moved the variables to the defaults and changed the docs. What do you
guys think?
—
Reply to this email directly or view it on GitHub
https://github.com/hardening-io/ansible-os-hardening/issues/50#issuecomment-152247426
.

--
GOD! Save As!

Hi @fitz123,
So I read https://github.com/hardening-io/ansible-os-hardening/issues/18 again and the reasons for doing it the way it currently is were:

beauty

and:

The first way only executes one task and is probably faster. Also only one sysctl-reload has to happen [for all changes]

I still think theses are good reasons and I'd like to keep the dict that way.
So in my opinion there are only two possibilities left:

keep it the way it currently is
move the dict to the defaults-vars and let the user overwrite them on playbook-level.

Since the work for no. 2 is already done I'm in favor of this.
@fitz123, @chris-rock what do you think?
PS: os_auth_* is no dict because these variables are used in different templates and contexts.

+1
Simply moving the nested dict into defaults is a good compromise here. Adding an explanatory comment above the dict in defaults could be helpful, really folks using Ansible should understand how dicts are handled.
Using the new Ansible filter to combine dicts is a great idea, but would force users of the role to start using Ansible 2—and it's a bit early to make it a hard requirement.

Resolved via #67; OK to close.


Error: StaticInjectorError(AppModule)[popperDefaults]

I already installed ngx-popper in some projects but in this one I get this error:
core.js:15724 ERROR Error: Uncaught (in promise): Error: StaticInjectorError(AppModule)[popperDefaults]:    StaticInjectorError(Platform: core)[popperDefaults]:      NullInjectorError: No provider for popperDefaults!
Clearly I'm lost with this error, I don't know what's happening since there is no service to provide in the doc.
It's maybe a bug or I completely forgot to include something.

@Dunk14 I actually solved this in my<EMAIL_ADDRESS>no need for extra forRoot!
demo => https://tonysamperi.github.io/ngx-popperjs


nodePackages.node2nix: add wrongly removed patch back

Thanks for catching lilyinstarlight!
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

@ofborg build node2nix

😅 I must admit I was rushing the PR a bit since I was really time constrained. Fixed.


get universal model to generate nonzero growth in rhodo nutrient medium

@djinnome why this universal model needs to grow?

Because it is meant to be a superset of an organism-specific model. Thus if organism model grows, universal matrix must also grow


How to ignore dependency injection arguments?

Is there an easy way to make this work? Overloading breaks runtime DI, using IDbContextFactory<DataContext> ctx inside of HubInterface breaks Tapper.
[Hub]
public interface IInventoryHub
{
    Task<Shelf[]> GetShelves();
}

public class InventoryHub : Hub<IInventoryReceiver>
{
    public async Task<Shelf[]> GetShelves(IDbContextFactory<DataContext> ctx)
    {
        await using var db = await ctx.CreateDbContextAsync();
        var shelves = db.Shelves.ToArray();
        return shelves;
    }
}

Edit:
it is possible to use DI in constructor
public class InventoryHub(IDbContextFactory<DataContext> ctx) : Hub<IInventoryReceiver>, IInventoryHub

and it works, so not big deal

Currently, dependency injection using method parameters is not supported.


Add generated open graph images

Fixes

Fixes #553 by @zackkrida
Description

Creates an og_image lektor macro for generating the open graph image. All pages show their title, with a fallback to the text 'Open Source at CC' if for some reason a page doesn't have a title.
Additionally, posts will show the gravatar of their author and the author name. There's not a great way to detect if a user has a gravatar or not, so unfortunately users without will show the default gravatar, as opposed to showing no image, which would be preferable in this case.
Please review the macro and see if there's any way to clean up it's logic. Python + Lektor + Jinja templates aren't my forte. For example, I would've preferred to use a dict for the query params and build the url with urllib.urlencode, but I couldn't manage to import it correctly.
Examples
Open Source Projects Page

Blog Landing Page

Example Blog Post

Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the default branch of the repository (main or master).
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no
visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

(Also noting, the style of the og images can change and be improved over time, without needing any code changes here. So if there's any concerns about text styles, image placement, etc., consider making a separate issue on https://github.com/creativecommons/og-image-generator)

@Dhruvi16 and @dhruvkb, I finally have something I can tag you both on! Please review when you can; thank you!

Pinging you both again (@Dhruvi16 and @dhruvkb), but with some extra testing notes:

Run this PR locally, and visit a few pages. Check for the <meta property="og:image"> tag and view the url in the browser. Please check blog posts as well as pages.

Sorry @zackkrida, it's been a busy sprint at work. Will try to review as soon as I have a moment.

@dhruvkb you can take your time—this isn't urgent, just wanted to make sure it's on your radar at all. Thanks!

Just in case, you want to test them yourself, here are the dev tools:

Twitter
Facebook
LinkedIn

@dhruvkb thanks for testing thoroughly. The facebook issue is known but I'd like to prioritize fixing it. I created an issue here: https://github.com/creativecommons/og-image-generator/issues/18.

@zackkrida feel free to merge it if you think we can update the code for the other platforms later.


Task exception was never retrieved - freeze_support()

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 10
Modin installed from (source or binary): pip install modin[dask] in a conda env
Modin version: 0.70
Python version: 3.7
Exact command to reproduce: Change all my pandas import to a modin import in a working ETL/ML script

Describe the problem
Script is blocked with an error
Source code / logs
UserWarning: The Dask Engine for Modin is experimental.
UserWarning: The Dask Engine for Modin is experimental.
UserWarning: The Dask Engine for Modin is experimental.
UserWarning: The Dask Engine for Modin is experimental.
[...]

Then the same number of time this error
Traceback (most recent call last):
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\asyncio\tasks.py", line 630, in _wrap_awaitable
    return (yield from awaitable.__await__())
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\site-packages\distributed\nanny.py", line 243, in start
    response = await self.instantiate()
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\site-packages\distributed\nanny.py", line 326, in instantiate
    result = await self.process.start()
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\site-packages\distributed\nanny.py", line 514, in start
    await self.process.start()
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\site-packages\distributed\process.py", line 34, in _call_and_set_future
    res = func(*args, **kwargs)
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\site-packages\distributed\process.py", line 202, in _start
    process.start()
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\multiprocessing\process.py", line 112, in start
    self._popen = self._Popen(self)
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\multiprocessing\context.py", line 223, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\multiprocessing\context.py", line 322, in _Popen
    return Popen(process_obj)
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\multiprocessing\popen_spawn_win32.py", line 46, in __init__
    prep_data = spawn.get_preparation_data(process_obj._name)
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\multiprocessing\spawn.py", line 143, in get_preparation_data
    _check_not_importing_main()
  File "C:\Users\gfelot\.conda\envs\categorisation_incidents\lib\multiprocessing\spawn.py", line 136, in _check_not_importing_main
    is not going to be frozen to produce an executable.''')
RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
        in the main module:

            if __name__ == '__main__':
                freeze_support()
                ...

        The "freeze_support()" line can be omitted if the program
        is not going to be frozen to produce an executable.

@gfelot thanks for reporting! This is a duplicate of #843. There should be a fix in that issue. If you have further questions/comments feel free to add them in #843.


Add try_examples directive for adding interactivity to sphinx Examples sections

Reference issue
closes gh-105.
What does this implement/fix?
This PR adds the try_examples directive, which takes Examples sections like below

and generates notebooks based on them, providing a button to swap the example content in place with a notebook

Additional information
You can find this deployed for the SciPy documentation here, https://steppi.github.io/scipy/. I've managed to fix a lot of small bugs in notebook generation and this has finally got to the state where I haven't found any issues on that front in the SciPy docs.
For content under the .. try_examples:: directive, doctest blocks are turned into code cells and RST text blocks are turned into markdown cells. Both inline and block math is handled so that the math displays correctly in the notebooks, as seen above.
To avoid having to manually add the directive, I've created a global_enable_try_examples config option, which automatically inserts the directive within Examples sections during the autodoc-process-docstring phase. This requires the docstring to be in the format produced by numpydoc during this phase ( I think this is format is also produced by sphinx.ext.napoleon.) It will need to be clearly documented how to set things up so that global_enable_try_examples will work. At the moment I've only tested this with SciPy's documentation, which has NumPy style docstrings and used the following extensions
extensions = [
    'sphinx.ext.autodoc',
    'sphinx.ext.autosummary',
    'sphinx.ext.coverage',
    'sphinx.ext.mathjax',
    'sphinx.ext.intersphinx',
    'numpydoc',
    'sphinx_design',
    'scipyoptdoc',
    'doi_role',
    'matplotlib.sphinxext.plot_directive',
    'myst_nb',
    'jupyterlite_sphinx',
]

I've added handling for math with sphinx.ext.mathjax, worked around cruft added by matplotlib.sphinxext.plot_directive that shouldn't go into notebooks, and cleaned up the raw output for references produced by numpydoc so it looks nicer in the notebooks. Other extensions and workflows may cause issues, particularly if using global_enable_try_examples. Using the directive directly on a vanilla docstring should work fine.
For, now I've set the heights of the iframes for the generated notebooks to be the same as the heights of the rendered Examples content. This works pretty well in most cases, but looks bad for particularly short Examples sections. I plan to make this more configurable, but would appreciate feedback on the best way to do that. For now there are configuration options for the whether or not the toolbar should appear by default, the jupyterlite theme, and the css for relevant buttons. I think configuration should be more flexible.
I haven't documented the extension yet, but clear documentation will be very important.
@martinRenou I have one important question. At least for Firefox, I've found that my browser prompts me to select a kernel every time I open one of the generated notebooks, even though Pyodide is the only kernel installed. You can try that out here. I think this will be too annoying for users, so hope there is a way the kernel can be specified in advance.

Thanks @steppi!

At least for Firefox, I've found that my browser prompts me to select a kernel every time I open one of the generated notebooks, even though Pyodide is the only kernel installed. You can try that out here. I think this will be too annoying for users, so hope there is a way the kernel can be specified in advance.

Agree the popup can be quite annoying. Maybe it's an issue in JupyterLite (or JupyterLab), which is not able to pick the default (and only) kernel when available.
Looking at one of the example notebooks: https://raw.githubusercontent.com/steppi/scipy/gh-pages/lite/files/004e9741_32fd_4b41_9716_052cde466244.ipynb, it looks like the metadata field of the notebook is empty. But adding python or the Pyodide kernel to the notebook metadata may also help JupyterLite pick the correct kernel on startup.

Thanks so much @jtpio! Adding python to the notebook metadata worked.

https://steppi.github.io/scipy/ as been updated with the fix and now doesn't have the annoying pop up to select the kernel.
One piece of feedback I've received recently is that the button to try the examples should be at the top of the Examples section to make it more noticeable.
I noticed that when pressing the try examples button, you just get a blank white iframe for a second or two until the notebook loads. I think I need to add some kind of indication that the notebook is loading, like you do for the existing directives. I'll also work on adding documentation and more configurability.

That looks great! Thanks!

I'll also work on adding documentation and more configurability

Would you like to get a review already or should we wait for another iteration from your side?

That looks great! Thanks!

I'll also work on adding documentation and more configurability

Would you like to get a review already or should we wait for another iteration from your side?

Thanks! It would be great if you could give it a first pass, even if just a quick one, just to help save me from putting in extra work finishing things up along a path that shouldn’t have been taken, if something isn’t quite right.

You can find this deployed for the SciPy documentation here, https://steppi.github.io/scipy/

Following the link your provided, I cannot test this feature. Do you have a link to a particular page in the documentation where I can try it?

This works pretty well in most cases, but looks bad for particularly short Examples sections

Maybe an harcoded (or configurable) minimum size for the IFrame could improve this?

Following the link your provided, I cannot test this feature. Do you have a link to a particular page in the documentation where I can try it?

Sorry, here's an example page for the function dblquad. If you want to see more, these interactive docstrings are in the API reference section of the docs.

Maybe an harcoded (or configurable) minimum size for the IFrame could improve this?

Yeah, I think that's a good idea. I think we can make it configurable with a sane default.

Sorry, here's an example page for the function dblquad. If you want to see more, these interactive docstrings are in the API reference section of the docs.

Neat 👍🏽

This all look sensible to me.
I'm just afraid that manually parsing the rst like this would not scale very well and may be difficult to maintain. I wonder if we can use docutils's parsers or write our own parser inheriting from the base ones. Anyway, I don't think this should be a blocker to this PR for now. We may want to turn this comment into an issue once the PR is merged.

Yeah, that makes sense. Scalability seems surprisingly Ok, SciPy is probably among the top packages for amount of docstring content, and the impact on the already enormous doc build times wasn't terrible. 100% agree on this manual parsing being more difficult to maintain and just overall more brittle. I didn't know how to make it work with an existing parser so just kind of went for it with the manual approach. Thanks for not considering this a blocker, and good idea to make an issue.

SciPy is probably among the top packages for amount of docstring content, and the impact on the already enormous doc build times wasn't terrible

Yep that's very good!
One thing I'm wondering is how it would work for documentation that's written in Markdown using something like myst-parser. Can we expect this code to work in that case?
Happy to merge this as-is now and we can iterate on it :)


Fix memory leaks in open upwards page transition

Part of https://github.com/flutter/flutter/issues/141198
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] I followed the breaking change policy and added Data Driven Fixes where supported.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

cc @polina-c

@polina-c Is there something else you want me to do on this?

Its good. Will merge as soon as tree is red.
(sorry, i was out of office yesterday)


chore(NumberTheory/Fermat): fix theorem names

From LeanCamCombi
Co-authored-by: Yves Jäckle

Thanks!
bors merge


Synchronization

(It might be related with #5) I'm having some doubts about sync and it may be because this is just starting and I don't know much. :smile:
From README:

dat will provide a pluggable API for synchronization so that plugins can be written to export and import remote data efficiently from existing databases.

Should we define sync before, after or at the same time than defining transformations?
How can we datize a project which we don't own. This is probably going to be a common case considering N sources.
How should it behave for non versioning databases?
Considering pagination and no source versioning, how can we know old rows had had an update?
Considering no pagination and no source versioning, will it have to "download" the complete source thing to know what changed?
Either way, (off 3, 4 and 5) how will we define the "pluggability" of the API that dat will provide.

Most of this discussion was around previous versions of dat. Dat 1.0 is much better for syncing!


Added Chip stories

Closes #591

We could add tests for the focus of the icon when it has onClick.

Done.


Request: event for custom views to know if they are visible/hidden

I'm developing a plugin that adds a custom view to the right split. This custom view reacts to the currently active file in the root split and makes some expensive operations. I want to avoid triggering these operations when the custom view is not even visible (either because the right sidebar is collapsed, or another view is active in the split).
I asked this question on Discord, but looks like there is no reliable way to get this information.

You can easily do this by testing if your view's container is in the DOM - in Obsidian there is a helper function on an HTMLElement called isShown() and in a view you can do this by checking this.containerEl.isShown(). The function is directly mapped to check if it has an Element.offsetParent which is the browser's way of telling you if it's hooked up to be rendered.
If you need a way to detect when your element has been re-inserted/shown (so that you can re-start rendering again), we also have a helper function called onNodeInserted(callback). You'll want to make sure you only call this once in your view constructor so it does not get hooked up multiple times and cause multiple computations.

Thank you for the detailed explanation. isShown() works perfectly for my use case!


 Tornado released v6 on 1st March, which removes some deprecated APIs that we use. This caused things to crash.
Update Redis to 3.2.0.

We use Tornado?

Required-by: threadloop, opentracing-instrumentation, jaeger-client, flower


Allow multiple static resource controllers for CSI driver

This would potentially allow us to configure different settings
for different static controller.
cc @bertinatto @jsafrane

/test unit


docs: update topic and add okta intro

@moonming :

update blog topic
add an Okta introduction paragraph

@starsz please add some more personal introduction at line 7 if you would like to do so

Hi @liuxiran @juzhiyuan @iamayushdas ,
I just updated this blog in the following aspects:

update blog topic, added Okta in the topic.
added an introduction topic for Okta in the beginning of the blog.
updated Xinxin's personal introduction.

cc @starsz @Serendipity96 @moonming


Siddhi I/O site links are not added to the Github repos

The following GitHub repos do not have the web page links

[ ] https://github.com/siddhi-io/siddhi-io-http/ => https://siddhi-io.github.io/siddhi-io-http/
[ ] https://github.com/siddhi-io/siddhi-io-nats/ => https://siddhi-io.github.io/siddhi-io-nats/
[ ] https://github.com/siddhi-io/siddhi-io-kafka/ => https://siddhi-io.github.io/siddhi-io-kafka/
[ ] https://github.com/siddhi-io/siddhi-io-email/ => https://siddhi-io.github.io/siddhi-io-email/
[ ] https://github.com/siddhi-io/siddhi-io-cdc/ => https://siddhi-io.github.io/siddhi-io-cdc/
[ ] https://github.com/siddhi-io/siddhi-io-tcp/ => https://siddhi-io.github.io/siddhi-io-tcp/
[ ] https://github.com/siddhi-io/siddhi-io-googlepubsub/ => https://siddhi-io.github.io/siddhi-io-googlepubsub/
[ ] https://github.com/siddhi-io/siddhi-io-file/ => https://siddhi-io.github.io/siddhi-io-file/
[ ] https://github.com/siddhi-io/siddhi-io-jms/ => https://siddhi-io.github.io/siddhi-io-jms/
[ ] https://github.com/siddhi-io/siddhi-io-prometheus/ => https://siddhi-io.github.io/siddhi-io-prometheus/

Please update below as well.

[ ] https://github.com/siddhi-io/siddhi-map-json/ => https://siddhi-io.github.io/siddhi-map-json/

[ ] https://github.com/siddhi-io/siddhi-map-xml/ => https://siddhi-io.github.io/siddhi-map-xml/

[ ] https://github.com/siddhi-io/siddhi-map-text/ => https://siddhi-io.github.io/siddhi-map-text/

[ ] https://github.com/siddhi-io/siddhi-map-avro/ => https://siddhi-io.github.io/siddhi-map-avro/

[ ] https://github.com/siddhi-io/siddhi-map-keyvalue/ => https://siddhi-io.github.io/siddhi-map-keyvalue/

[ ] https://github.com/siddhi-io/siddhi-map-csv/ => https://siddhi-io.github.io/siddhi-map-csv/

[ ] https://github.com/siddhi-io/siddhi-map-binary/ => https://siddhi-io.github.io/siddhi-map-binary/

[ ] https://github.com/siddhi-io/siddhi-store-rdbms/ => https://siddhi-io.github.io/siddhi-store-rdbms/

[ ] https://github.com/siddhi-io/siddhi-store-mongodb/ => https://siddhi-io.github.io/siddhi-store-mongodb/

[ ] https://github.com/siddhi-io/siddhi-store-elasticsearch/ => https://siddhi-io.github.io/siddhi-store-elasticsearch/

[ ] https://github.com/siddhi-io/siddhi-store-redis/ => https://siddhi-io.github.io/siddhi-store-redis/

[ ] https://github.com/siddhi-io/siddhi-script-js/ => https://siddhi-io.github.io/siddhi-script-js/

Done


Can we connect ms sqlcdatabase with Label studio

Can we connect ms sql database with Label studio.
what are the databases can we connect with label studio

Hello, LS officially supports postgresql and sqlite.
Unofficial support - mysql, and sometimes it's tricky.


shortcut behavior unexpected in firefox

Shortcut focus problem
Steps to reproduce the issue

press cmd + k in firefox and macOS

What's the expected result?
cursor focus in scoutbar input field
What's the actual result?
cursor focus in firefox search box (built-in shortcut)
Additional details / screenshot

Hey @alanaudi
Good catch. Thanks for pointing this out. Great issues structure as well. I have reproduced this issue, and I think it has to do with me not intentionally disabling the browser defaults for the scoutKey method. I guess the CMD+K is an exception where we can just prevent the defaults for browsers.
The next patch should include a fix for this.
Great work man 🚀

hey @alanaudi , update your scoutbar to v1.1.8 for a cleaner version

@adenekan41  thank you for dealing with this issue so fast !
This is a great package for building command bar, nice work 👍


[Main page] Burger menu appears when changing resolution

Environment: Windows 10, Version 92.0.4515.107 (Official Build) (64-bit)
Reproducible: always,
Build found: last commit
Steps to reproduce

Go to https://speak-ukrainian.org.ua/dev/
Click three dots menu.
Click on 'More tool'
Click on 'Developer tools'
Start changing resolution.

Actual result
Burger menu appears on the header of the main page.
https://user-images.githubusercontent.com/87877499/128239634-c9bfa7ce-800f-42a4-8226-fc746083535a.mp4
Expected result
Burger menu doesn't appear when changing resolution.
User story and test case links
E.g.: "User story #

'Burger' menu appears at resolution 970×792