Implement selective optimization levels on a per-dependency basis.

Inside the dependencies.foo section, you may now specify a minimum
optimization level to be applied to this dependency. If multiple such
optimization levels are supplied, Cargo chooses the highest one.
This will probably need to go through an RFC before landing.
Addresses #1359.
r? @alexcrichton -- would be interested to hear design thoughts

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thanks for the PR @pcwalton! I talked about something like this in the past with @wycats and the conclusion we've reached is that the specification here is probably best done at the top level, not in the dependencies themselves. In general it seems best if you have complete control over how your dependencies are built rather than having a transitive dependency deciding how it's compiled. One example of this is that the logic for "pick the highest level" isn't always correct as there may be some dependencies you want to force to a lower optimization level.
This issue about configuring dependencies from the top-level definitely comes up quite a bit (https://github.com/rust-lang/cargo/issues/1359, https://github.com/rust-lang/cargo/issues/629, https://github.com/rust-lang/cargo/issues/942), and it's probably best to enable solving all of these in basically one fell swoop. Along those lines I think that we'll want to implement something along the lines of:
[dependencies-config]
foo = { profile = "release" }
"bar:0.1.4" = { override = "path/to/override" }
"crates.io/foo" = { crate-type = [ ... ] }

This allows you to:

At the top level have control over how each dependency is compiled
Reference existing profiles to leverage all the other options in profiles
Specify any arbitrary package in the dependency graph unambiguously

Some of these details I think still need to be bike-shedded and this may warrant an RFC as well as it's a somewhat substantial change.

OK, I'll work on this ASAP. I am blocked on this so there is no other option.

:umbrella: The latest upstream changes (presumably #1848) made this pull request unmergeable. Please resolve the merge conflicts.

This has been inactive for awhile (and I think Servo is working for now), so I'm going to close this in favor of issue like https://github.com/rust-lang/cargo/issues/942 which should provide a nice vector for us to implement this.


Refactored code structure to be more centeralized

Local testing checks out, merging

Refactoring in PR #7:
Common functions are now in:

base.js: core tetris functions (piece movement, queue, etc.)
io.js: import/export functions
tetrio.js: functions from tetrio's source code
utils.js: tools, utilities, and any other extra function

callback() is now in base.js and takes arguments
Different arguments alter its behavior, for example changing its game mode
Having one single core function file and callback() makes it easy to change things and have it be across all modes
game() is the main game function now
In each gamemode's file, game() is defined as an instance of callback() with arguments to specify which gamemode callback() should behave as


Update Manufacturer in H400_H350.ppd file

The Manufacturer in the H400_H350.ppd file is listed as HP.  Should this be CUSTOM to match all the other PPD files?
Also, HP shows up in the 1284DeviceID field and in the ModelName field.  In the other PPD files the ModelName does not include the manufacturer - I don't know if this one should be different or not.

This printer model was developed by Custom in partnership with HP.  It's correct that the Manufacturer in this case is HP.

This printer model was developed by Custom in partnership with HP. It's correct that the Manufacturer in this case is HP.


Info.plist does not need to be part of compiled output

This addresses issue #25 and prevents Info.plist from being produced by both the copy and the build steps.

@janpio can this be merged please? This change seems to be working fine for me, I'm currently using a local copy of brownoxford:bugfix/25 and manually fixing #22.

Can you maybe answer my question?
https://github.com/fastlane-community/fastlane-plugin-cordova_screenshots/issues/25#issuecomment-568201538


Code

Will you be posting any of your Code that you run on the Hackbat have the parts coming very interesting.

He said he has provided this as a hardware project only.

Totally understand would make it easier to see how and what he did to test that it actually works.


Chapters fail to print using custom CSL style

Hello, I am trying to format a bibliography in typst.
Consider the following biblatex reference:
@incollection{c.r2015,
  title = {The cartography of syntactic structures},
  booktitle = {The {{Oxford}} handbook of linguistic analysis},
  author = {Cinque, Guglielmo and Rizzi, Luigi},
  editor = {Heine, Bernd and Narrog, Heiko},
  date = {2015},
  series = {Oxford handbooks in linguistics},
  edition = {Second edition},
  pages = {51--65},
  publisher = {Oxford University Press},
  location = {New York, NY},
  isbn = {978-0-19-967707-8},
  langid = {english},
  language = {English},
  annotation = {OCLC: ocn908566410}
}

And the following CSL:
<?xml version="1.0" encoding="utf-8"?>
<style class="in-text" version="1.0" and="symbol" et-al-min="5" et-al-use-first="1" initialize="false" initialize-with="" name-as-sort-order="first" demote-non-dropping-particle="never" xmlns="http://purl.org/net/xbiblio/csl">
  <info>
    <title>foobar</title>
    <id>http://www.zotero.org/styles/apa</id>
    <author>
      <name>AMPrice</name>
    </author>
    <updated>2024-03-30T23:11:28+00:00</updated>
    <rights license="http://creativecommons.org/licenses/by-sa/3.0/">This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License</rights>
  </info>
  <locale xml:lang="en">
    <terms>
      <term name="editor">
        <single>ed.</single>
        <multiple>eds.</multiple>
      </term>
      <term name="translator">
        <single>trans.</single>
        <multiple>trans.</multiple>
      </term>
    </terms>
  </locale>
  <citation et-al-min="3" et-al-use-first="1" disambiguate-add-year-suffix="true" disambiguate-add-names="true" disambiguate-add-givenname="true" collapse="year" givenname-disambiguation-rule="primary-name-with-initials">
    <layout delimiter="; " prefix="(" suffix=")">
      <group>
        <names variable="author" delimiter=", "/>
      </group>
    </layout>
  </citation>
  <bibliography hanging-indent="true" name-as-sort-order="first" et-al-min="21" et-al-use-first="19" entry-spacing="0" line-spacing="1" and="text" initialize-with=" ">
    <layout>
      <group>
        <choose>
        <if type="chapter" match="any">
            <text value="foofoo"/>
            <names variable="author" delimiter=", " suffix=". ">
              <name/>
            </names>
            <text variable="title"/>
          </if>
        </choose>
      </group>
    </layout>
  </bibliography>
</style>

This will print a blank line:
$ ~/.cargo/bin/hayagriva foo.yaml cite --key c.r2015 --csl new.csl

Its type inside hayagriva (after conversion from a .bib file) is given as anthos, and the parent reference has the type anthology (not sure this is what I would call it, but whatever).
I can get it to print using the CSL by eg. within the CSL, calling all reference types, matching for references that have titles, etc. But I cannot call it by type="chapter", while this should be possible, and such works using other tools that use CSL.
Not sure if this is a bug, or if I am making a mistake. Thank you for any help & let me know what further info I can provide.

OK, I don't know if this is a preferred solution but I tracked down the issue. Anthos isn't given the CSL type for chapter, as I suspected. Still not sure I really understand 'what' is happening there, I don't know rust (although I wish to learn) and I am a relative beginner at all things code.
A fix, whether hacky or not, is to simply use the selector to make the anthos type a chapter type. See the commit here: https://github.com/ashprice/hayagriva/commit/49d88b2d37d1e9b72e115bd675ccaaf87bee4101
diff --git a/src/csl/taxonomy.rs b/src/csl/taxonomy.rs
index c691ed3..e3108b7 100644
--- a/src/csl/taxonomy.rs
+++ b/src/csl/taxonomy.rs
@@ -564,7 +564,8 @@ impl EntryLike for Entry {
                 !(is_periodical || is_collection)
             }
             Kind::Chapter => {
-                select!(Chapter > (Book | Anthology | Proceedings)).matches(self)
+                select!((Chapter | Anthos) > (Book | Anthology | Proceedings))
+                    .matches(self)
             }
             Kind::Entry | Kind::EntryDictionary | Kind::EntryEncyclopedia => {
                 if kind == Kind::EntryDictionary {

I can make this into a PR, but I am not sure that this is the preferred way to deal with this. FWIW, we are dealing here with a regular book that contains a series of chapters with different authors, I am not quite sure I would call that an anthology to begin with, but I am guessing that the type exists to differentiate it from chapters with the same authors...

@ashprice  Have you tried changing @incollection to @InBook (which worked for me)? I had the same problem with using @InCollection for custom Chicago CSL, and @inBook is probably what Hayagriva considers incollection in its own language.
@InBook{cr2015,   title = {The cartography of syntactic structures},   booktitle = {The {{Oxford}} handbook of linguistic analysis},   author = {Cinque, Guglielmo and Rizzi, Luigi},   editor = {Heine, Bernd and Narrog, Heiko},   date = {2015},   series = {Oxford handbooks in linguistics},   edition = {Second edition},   pages = {51--65},   publisher = {Oxford University Press},   location = {New York, NY},   isbn = {978-0-19-967707-8},   langid = {english},   language = {English}, }

@jaylangford Yeah, that was a provisionary aid on my part. Still, @incollection is somehow treated as an @anthos when converted by Hayagriva from biblatex:

Concerning the @inbook’s conversion:

Strangely, the point is that @incollection from biblatex is not recognized by Hayagriva as a chapter.

@ironupiwada I believe the relevant code for identifying incollection as an Anthos entry with an Anthology parent is here;
            { tex::EntryType::InCollection, EntryType::Anthos, Some(EntryType::Anthology), true },

If I understand it correctly, it just treats all inCollection BibTex entries as Anthos. Then, it fails to match as a Chapter when being converted to CSL because of this line (the one that @ashprice referred to earlier in their commit):
            Kind::Chapter => {
                select!(Chapter > (Book | Anthology | Proceedings)).matches(self)
            }


Applying multiple named abberations

Hi, thank you for writing this great package!
I'm trying to apply multiple named aberrations to a PSF, but it seems like only the last aberration is applied.
    model_kwargs = dict(
        wl=525, na=1.27, ni=1.33, res=70, size=32, zrange=32, vec_corr="none", condition="none",
    )
    model = HanserPSF(**model_kwargs)
    model = apply_named_aberration('oblique astigmatism', 1)
    model = apply_named_aberration('piston', 0)

For example, the PSF generated from this code block is equivalent to an un-abberated PSF.
Is this expected behaviour?
If not, is it possible to merge the mcoefs for various named abberations to produce a PSF aberrated using multiple Zernike polynomials?

I don't think that code actually runs: can you supply a minimal working example with plotting?
model_kwargs = dict(
    wl=525, na=1.27, ni=1.33, res=70, size=32, zrange=32, vec_corr="none", condition="none",
)
model = HanserPSF(**model_kwargs)
model = apply_named_aberration('oblique astigmatism', 1)
model = apply_named_aberration('piston', 0)

gives
TypeError                                 Traceback (most recent call last)
<ipython-input-2-d4529ddce059> in <module>
      3 )
      4 model = HanserPSF(**model_kwargs)
----> 5 model = apply_named_aberration('oblique astigmatism', 1)
      6 model = apply_named_aberration('piston', 0)

TypeError: apply_named_aberration() missing 1 required positional argument: 'magnitude'

You can't apply apply_named_aberration more than once, it will overwrite any previously applied aberrations.
If you want to use more than one aberration see apply_aberration:
https://github.com/david-hoffman/pyOTF/blob/5cb240897dd3ff1e4bb17de5cf894fff79a2f961/pyotf/otf.py#L527-L539
If you think updating apply_named_aberration to accept multiple aberrations please open another issue.

Oop sorry about, here is a better example with layers plotted
import numpy as np
from skimage import img_as_ubyte
import matplotlib.pyplot as plt

from data.pyOTF.pyotf.otf import apply_named_aberration, HanserPSF

model_kwargs = dict(
    wl=525, na=1.27, ni=1.33, res=70, size=32, zsize=32, vec_corr="none", condition="none",
)
model = HanserPSF(**model_kwargs)
psf1 = apply_named_aberration(model, 'oblique astigmatism', 1)
psf2 = apply_named_aberration(psf1, 'piston', 0)

sub_psf = np.concatenate((psf1.PSFi, psf2.PSFi), axis=2)

axial_psf = np.concatenate(sub_psf[slice(5, sub_psf.shape[0]-5, 3)], axis=0)
axial_psf = axial_psf / axial_psf.max()
plt.imshow(axial_psf)
plt.show()

I think I've solved the issue though;

Convert each named aberration to an array of pcoefs
Sum arrays of Pcoefs to obtain coefficients containing multiple abberations
Apply as un-named abberation to PSF

I'd be happy to open a pull request if you think this may be useful to share?

Sure, go for it.

On Feb 21, 2021, at 00:44, Miguel Boland<EMAIL_ADDRESS>wrote:

Oop sorry about, here is a better example with layers plotted
import numpy as np
from skimage import img_as_ubyte
import matplotlib.pyplot as plt
from data.pyOTF.pyotf.otf import apply_named_aberration, HanserPSF
model_kwargs = dict(
wl=525, na=1.27, ni=1.33, res=70, size=32, zsize=32, vec_corr="none", condition="none",
)
model = HanserPSF(**model_kwargs)
psf1 = apply_named_aberration(model, 'oblique astigmatism', 1)
psf2 = apply_named_aberration(psf1, 'piston', 0)
sub_psf = np.concatenate((psf1.PSFi, psf2.PSFi), axis=2)
axial_psf = np.concatenate(sub_psf[slice(5, sub_psf.shape[0]-5, 3)], axis=0)
axial_psf = axial_psf / axial_psf.max()
plt.imshow(axial_psf)
plt.show()
I think I've solved the issue though;
Convert each named aberration to an array of pcoefs
Sum arrays of Pcoefs to obtain coefficients containing multiple abberations
Apply as un-named abberation to PSF
I'd be happy to open a pull request if you think this may be useful to share?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

@mb1069 one extra thing to note, piston is just a constant offset so has no effect on the PSF when applied to the phase.


[BUG] - Getting error whil building using vite-ssg

Version
@vueup/vue-quill version [e.g. 1.0.0-beta.7]
Describe the bug
I'm using vite-ssg for server side building of app. When I tried to build the project, quill is throwing this error
ReferenceError: document is not defined
    at Object.<anonymous> (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:7661:12)
    at __webpack_require__ (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:36:30)
    at Object.<anonymous> (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:1030:1)
    at __webpack_require__ (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:36:30)
    at Object.<anonymous> (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:5655:14)
    at __webpack_require__ (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:36:30)
    at Object.<anonymous> (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:10045:13)
    at __webpack_require__ (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:36:30)
    at Object.<anonymous> (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:11557:18)
    at __webpack_require__ (/web/node_modules/.pnpm/quill@1.3.7/node_modules/quill/dist/quill.js:36:30)
 ELIFECYCLE  Command failed with exit code 1.
 ELIFECYCLE  Command failed with exit code 1.

Please suggest some ways to fix this issue

same issue

Any update on this one??

You can try async component with cleint only tag. Seems to be working this way

You can use defineAsyncComponent
import { defineAsyncComponent } from 'vue'
import Loading from './components/Loading.vue'

const QuillEditor = defineAsyncComponent({
  loader: () =>
    import('@vueup/vue-quill').then((VueQuill) => VueQuill.QuillEditor),
  loadingComponent: Loading,
})


Instruction New Coverage: 38.96%
Line New Coverage: 44.38%
Method New Coverage: 63.64%

org.pentaho.di.trans.steps.sftpput.SFTPPutData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.sftpput.SFTPPutMeta

Branch New Coverage: 14.29%
Complexity New Coverage: 80.00%
Instruction New Coverage: 80.91%
Line New Coverage: 80.00%
Method New Coverage: 89.66%

org.pentaho.di.trans.steps.simplemapping.RowDataInputMapper

Branch New Coverage: 33.33%
Complexity New Coverage: 50.00%
Instruction New Coverage: 71.19%
Line New Coverage: 75.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.simplemapping.RowOutputDataMapper

Complexity New Coverage: 12.50%
Instruction New Coverage: 17.44%
Line New Coverage: 27.27%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.simplemapping.SimpleMapping

Branch New Coverage: 26.79%
Complexity New Coverage: 32.56%
Instruction New Coverage: 39.74%
Line New Coverage: 41.73%
Method New Coverage: 53.33%

org.pentaho.di.trans.steps.simplemapping.SimpleMapping.new PutRowInterface() {...}

Complexity New Coverage: 50.00%
Instruction New Coverage: 50.00%
Line New Coverage: 33.33%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.simplemapping.SimpleMappingData

Complexity New Coverage: 33.33%
Instruction New Coverage: 82.05%
Line New Coverage: 78.57%
Method New Coverage: 33.33%

org.pentaho.di.trans.steps.simplemapping.SimpleMappingMeta

Branch New Coverage: 14.86%
Complexity New Coverage: 18.42%
Instruction New Coverage: 40.52%
Line New Coverage: 38.36%
Method New Coverage: 35.90%

org.pentaho.di.trans.steps.singlethreader.SingleThreader

Complexity New Coverage: 4.08%
Instruction New Coverage: 1.46%
Line New Coverage: 2.04%
Method New Coverage: 13.33%

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta

Branch New Coverage: 33.93%
Complexity New Coverage: 37.50%
Instruction New Coverage: 61.67%
Line New Coverage: 61.39%
Method New Coverage: 52.27%

org.pentaho.di.trans.steps.socketreader.SocketReaderMeta

Complexity New Coverage: 66.67%
Instruction New Coverage: 63.76%
Line New Coverage: 64.52%
Method New Coverage: 76.19%

org.pentaho.di.trans.steps.socketwriter.SocketWriterMeta

Complexity New Coverage: 66.67%
Instruction New Coverage: 63.10%
Line New Coverage: 63.49%
Method New Coverage: 76.19%

org.pentaho.di.trans.steps.sort.SortRowsMeta

Branch New Coverage: 22.06%
Complexity New Coverage: 54.32%
Instruction New Coverage: 62.54%
Line New Coverage: 62.60%
Method New Coverage: 82.98%

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Branch New Coverage: 30.56%
Complexity New Coverage: 47.37%
Instruction New Coverage: 49.40%
Line New Coverage: 49.12%
Method New Coverage: 70.00%

org.pentaho.di.trans.steps.splitfieldtorows.SplitFieldToRows

Branch New Coverage: 5.26%
Complexity New Coverage: 12.50%
Instruction New Coverage: 13.99%
Line New Coverage: 16.44%
Method New Coverage: 60.00%

org.pentaho.di.trans.steps.splitfieldtorows.SplitFieldToRowsData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.splitfieldtorows.SplitFieldToRowsMeta

Complexity New Coverage: 61.76%
Instruction New Coverage: 49.51%
Line New Coverage: 48.82%
Method New Coverage: 80.77%

org.pentaho.di.trans.steps.sql.ExecSQLMeta

Branch New Coverage: 42.31%
Complexity New Coverage: 70.37%
Instruction New Coverage: 62.94%
Line New Coverage: 63.64%
Method New Coverage: 82.93%

org.pentaho.di.trans.steps.sqlfileoutput.SQLFileOutputMeta

Branch New Coverage: 3.41%
Complexity New Coverage: 45.00%
Instruction New Coverage: 46.33%
Line New Coverage: 43.02%
Method New Coverage: 80.36%

org.pentaho.di.trans.steps.ssh.SSHMeta

Complexity New Coverage: 73.68%
Instruction New Coverage: 64.50%
Line New Coverage: 65.02%
Method New Coverage: 84.00%

org.pentaho.di.trans.steps.stepmeta.StepMetastructureMeta

Complexity New Coverage: 66.67%
Instruction New Coverage: 32.35%
Line New Coverage: 37.33%
Method New Coverage: 70.59%

org.pentaho.di.trans.steps.stepsmetrics.StepsMetricsMeta

Branch New Coverage: 27.08%
Complexity New Coverage: 60.00%
Instruction New Coverage: 60.57%
Line New Coverage: 55.27%
Method New Coverage: 82.93%

org.pentaho.di.trans.steps.streamlookup.StreamLookup

Branch New Coverage: 53.54%
Complexity New Coverage: 38.16%
Instruction New Coverage: 56.15%
Line New Coverage: 56.33%
Method New Coverage: 90.00%

org.pentaho.di.trans.steps.streamlookup.StreamLookupData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.streamlookup.StreamLookupData.new Comparator() {...}

Complexity New Coverage: 50.00%
Instruction New Coverage: 27.27%
Line New Coverage: 25.00%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.streamlookup.StreamLookupMeta

Branch New Coverage: 41.86%
Complexity New Coverage: 53.66%
Instruction New Coverage: 61.23%
Line New Coverage: 63.00%
Method New Coverage: 84.62%

org.pentaho.di.trans.steps.stringcut.StringCutMeta

Branch New Coverage: 20.00%
Complexity New Coverage: 48.84%
Instruction New Coverage: 49.65%
Line New Coverage: 48.23%
Method New Coverage: 73.91%

org.pentaho.di.trans.steps.stringoperations.StringOperations

Branch New Coverage: 51.65%
Complexity New Coverage: 31.15%
Instruction New Coverage: 73.82%
Line New Coverage: 58.75%
Method New Coverage: 85.71%

org.pentaho.di.trans.steps.stringoperations.StringOperationsMeta

Branch New Coverage: 28.57%
Complexity New Coverage: 35.58%
Instruction New Coverage: 66.43%
Line New Coverage: 58.88%
Method New Coverage: 70.77%

org.pentaho.di.trans.steps.switchcase.KeyToRowSetMap

Branch New Coverage: 100.00%
Complexity New Coverage: 44.44%
Instruction New Coverage: 60.66%
Line New Coverage: 58.82%
Method New Coverage: 37.50%

org.pentaho.di.trans.steps.switchcase.SwitchCase

Branch New Coverage: 68.42%
Complexity New Coverage: 54.17%
Instruction New Coverage: 65.71%
Line New Coverage: 73.68%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.switchcase.SwitchCaseData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.switchcase.SwitchCaseMeta

Branch New Coverage: 46.30%
Complexity New Coverage: 57.81%
Instruction New Coverage: 68.17%
Line New Coverage: 67.20%
Method New Coverage: 75.68%

org.pentaho.di.trans.steps.switchcase.SwitchCaseTarget

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.symmetriccrypto.secretkeygenerator.SecretKeyGeneratorMeta

Branch New Coverage: 30.77%
Complexity New Coverage: 65.91%
Instruction New Coverage: 64.88%
Line New Coverage: 61.78%
Method New Coverage: 80.65%

org.pentaho.di.trans.steps.symmetriccrypto.symmetriccryptotrans.SymmetricCryptoTransMeta

Branch New Coverage: 16.67%
Complexity New Coverage: 55.56%
Instruction New Coverage: 68.35%
Line New Coverage: 63.87%
Method New Coverage: 76.92%

org.pentaho.di.trans.steps.synchronizeaftermerge.SynchronizeAfterMergeMeta

Branch New Coverage: 21.18%
Complexity New Coverage: 45.89%
Instruction New Coverage: 45.77%
Line New Coverage: 48.47%
Method New Coverage: 88.52%

org.pentaho.di.trans.steps.syslog.SyslogMessage

Branch New Coverage: 36.67%
Complexity New Coverage: 28.57%
Instruction New Coverage: 54.89%
Line New Coverage: 57.14%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.syslog.SyslogMessageData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.syslog.SyslogMessageMeta

Complexity New Coverage: 72.73%
Instruction New Coverage: 67.18%
Line New Coverage: 65.14%
Method New Coverage: 77.42%

org.pentaho.di.trans.steps.systemdata.SystemData

Branch New Coverage: 9.33%
Complexity New Coverage: 4.88%
Instruction New Coverage: 7.98%
Line New Coverage: 6.51%
Method New Coverage: 80.00%

org.pentaho.di.trans.steps.systemdata.SystemData.new Object() {...}

Complexity New Coverage: 100.00%
Instruction New Coverage: 85.82%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.systemdata.SystemDataData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.systemdata.SystemDataMeta

Branch New Coverage: 44.90%
Complexity New Coverage: 48.98%
Instruction New Coverage: 59.32%
Line New Coverage: 58.54%
Method New Coverage: 73.91%

org.pentaho.di.trans.steps.systemdata.SystemDataMeta.new Object() {...}

Complexity New Coverage: 100.00%
Instruction New Coverage: 85.82%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.systemdata.SystemDataTypes

Branch New Coverage: 100.00%
Complexity New Coverage: 87.50%
Instruction New Coverage: 99.59%
Line New Coverage: 100.00%
Method New Coverage: 85.71%

org.pentaho.di.trans.steps.tableagilemart.AgileMartUtil

Complexity New Coverage: 9.09%
Instruction New Coverage: 1.74%
Line New Coverage: 2.63%
Method New Coverage: 33.33%

org.pentaho.di.trans.steps.tablecompare.TableCompareMeta

Branch New Coverage: 21.43%
Complexity New Coverage: 69.84%
Instruction New Coverage: 67.14%
Line New Coverage: 68.61%
Method New Coverage: 87.76%

org.pentaho.di.trans.steps.tableexists.TableExistsMeta

Branch New Coverage: 18.75%
Complexity New Coverage: 54.84%
Instruction New Coverage: 49.09%
Line New Coverage: 50.00%
Method New Coverage: 73.91%

org.pentaho.di.trans.steps.tableinput.TableInputMeta

Branch New Coverage: 25.71%
Complexity New Coverage: 41.43%
Instruction New Coverage: 45.54%
Line New Coverage: 46.93%
Method New Coverage: 68.57%

org.pentaho.di.trans.steps.tableoutput.TableOutput

Branch New Coverage: 16.83%
Complexity New Coverage: 11.11%
Instruction New Coverage: 15.46%
Line New Coverage: 21.47%
Method New Coverage: 53.85%

org.pentaho.di.trans.steps.tableoutput.TableOutputData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.tableoutput.TableOutputMeta

Branch New Coverage: 27.27%
Complexity New Coverage: 53.28%
Instruction New Coverage: 51.92%
Line New Coverage: 51.11%
Method New Coverage: 79.10%

org.pentaho.di.trans.steps.textfileinput.EncodingType

Branch New Coverage: 75.76%
Complexity New Coverage: 66.67%
Instruction New Coverage: 76.50%
Line New Coverage: 75.00%
Method New Coverage: 69.23%

org.pentaho.di.trans.steps.textfileinput.TextFileFilter

Complexity New Coverage: 90.91%
Instruction New Coverage: 66.67%
Line New Coverage: 66.67%
Method New Coverage: 90.91%

org.pentaho.di.trans.steps.textfileinput.TextFileFilterProcessor

Branch New Coverage: 13.16%
Complexity New Coverage: 9.09%
Instruction New Coverage: 27.69%
Line New Coverage: 33.33%
Method New Coverage: 66.67%

org.pentaho.di.trans.steps.textfileinput.TextFileInput

Branch New Coverage: 30.93%
Complexity New Coverage: 16.25%
Instruction New Coverage: 35.78%
Line New Coverage: 40.97%
Method New Coverage: 69.57%

org.pentaho.di.trans.steps.textfileinput.TextFileInputData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.textfileinput.TextFileInputField

Complexity New Coverage: 26.61%
Instruction New Coverage: 23.06%
Line New Coverage: 25.10%
Method New Coverage: 67.35%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch New Coverage: 37.89%
Complexity New Coverage: 59.76%
Instruction New Coverage: 77.68%
Line New Coverage: 74.66%
Method New Coverage: 85.26%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaInjection

Branch New Coverage: 50.00%
Complexity New Coverage: 54.63%
Instruction New Coverage: 62.29%
Line New Coverage: 61.21%
Method New Coverage: 80.00%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaInjection.Entry

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaInjection.new Object() {...}

Complexity New Coverage: 100.00%
Instruction New Coverage: 85.84%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.textfileinput.TextFileLine

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.textfileoutput.TextFileField

Complexity New Coverage: 87.10%
Instruction New Coverage: 81.25%
Line New Coverage: 86.89%
Method New Coverage: 87.10%

org.pentaho.di.trans.steps.textfileoutput.TextFileOutput

Branch New Coverage: 46.10%
Complexity New Coverage: 29.87%
Instruction New Coverage: 51.63%
Line New Coverage: 54.73%
Method New Coverage: 88.46%

org.pentaho.di.trans.steps.textfileoutput.TextFileOutputData

Complexity New Coverage: 50.00%
Instruction New Coverage: 95.52%
Line New Coverage: 94.12%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.textfileoutput.TextFileOutputMeta

Branch New Coverage: 21.88%
Complexity New Coverage: 51.28%
Instruction New Coverage: 66.50%
Line New Coverage: 62.55%
Method New Coverage: 81.52%

org.pentaho.di.trans.steps.transexecutor.TransExecutor

Branch New Coverage: 58.77%
Complexity New Coverage: 42.11%
Instruction New Coverage: 66.39%
Line New Coverage: 68.95%
Method New Coverage: 68.42%

org.pentaho.di.trans.steps.transexecutor.TransExecutorData

Complexity New Coverage: 78.26%
Instruction New Coverage: 77.50%
Line New Coverage: 77.14%
Method New Coverage: 78.26%

org.pentaho.di.trans.steps.transexecutor.TransExecutorMeta

Branch New Coverage: 51.61%
Complexity New Coverage: 56.95%
Instruction New Coverage: 79.10%
Line New Coverage: 74.66%
Method New Coverage: 69.90%

org.pentaho.di.trans.steps.transexecutor.TransExecutorParameters

Branch New Coverage: 50.00%
Complexity New Coverage: 73.68%
Instruction New Coverage: 55.85%
Line New Coverage: 71.64%
Method New Coverage: 93.33%

org.pentaho.di.trans.steps.TransStepUtil

Branch New Coverage: 50.00%
Complexity New Coverage: 33.33%
Instruction New Coverage: 70.00%
Line New Coverage: 71.43%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Branch New Coverage: 45.00%
Complexity New Coverage: 67.57%
Instruction New Coverage: 69.65%
Line New Coverage: 67.83%
Method New Coverage: 77.78%

org.pentaho.di.trans.steps.uniquerowsbyhashset.UniqueRowsByHashSetMeta

Branch New Coverage: 66.67%
Complexity New Coverage: 72.41%
Instruction New Coverage: 71.50%
Line New Coverage: 71.26%
Method New Coverage: 73.91%

org.pentaho.di.trans.steps.univariatestats.FieldIndex

Branch New Coverage: 95.00%
Complexity New Coverage: 91.67%
Instruction New Coverage: 97.54%
Line New Coverage: 98.46%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.univariatestats.UnivariateStats

Complexity New Coverage: 3.70%
Instruction New Coverage: 1.81%
Line New Coverage: 2.41%
Method New Coverage: 25.00%

org.pentaho.di.trans.steps.univariatestats.UnivariateStatsData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.univariatestats.UnivariateStatsMeta

Branch New Coverage: 83.33%
Complexity New Coverage: 79.49%
Instruction New Coverage: 93.79%
Line New Coverage: 91.75%
Method New Coverage: 83.33%

org.pentaho.di.trans.steps.univariatestats.UnivariateStatsMetaFunction

Branch New Coverage: 89.47%
Complexity New Coverage: 89.13%
Instruction New Coverage: 90.38%
Line New Coverage: 95.14%
Method New Coverage: 96.30%

org.pentaho.di.trans.steps.update.Update

Branch New Coverage: 17.31%
Complexity New Coverage: 10.47%
Instruction New Coverage: 15.53%
Line New Coverage: 22.11%
Method New Coverage: 62.50%

org.pentaho.di.trans.steps.update.UpdateData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.update.UpdateMeta

Branch New Coverage: 29.41%
Complexity New Coverage: 42.86%
Instruction New Coverage: 52.91%
Line New Coverage: 50.37%
Method New Coverage: 80.39%

org.pentaho.di.trans.steps.userdefinedjavaclass.StepDefinition

Branch New Coverage: 50.00%
Complexity New Coverage: 50.00%
Instruction New Coverage: 53.33%
Line New Coverage: 56.25%
Method New Coverage: 66.67%

org.pentaho.di.trans.steps.userdefinedjavaclass.TransformClassBase

Branch New Coverage: 5.00%
Complexity New Coverage: 2.08%
Instruction New Coverage: 4.38%
Line New Coverage: 2.69%
Method New Coverage: 1.77%

org.pentaho.di.trans.steps.userdefinedjavaclass.UserDefinedJavaClassDef

Branch New Coverage: 50.00%
Complexity New Coverage: 46.67%
Instruction New Coverage: 71.95%
Line New Coverage: 60.00%
Method New Coverage: 53.85%

org.pentaho.di.trans.steps.userdefinedjavaclass.UserDefinedJavaClassDef.ClassType

Complexity New Coverage: 50.00%
Instruction New Coverage: 76.32%
Line New Coverage: 100.00%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.userdefinedjavaclass.UserDefinedJavaClassMeta

Branch New Coverage: 14.29%
Complexity New Coverage: 15.73%
Instruction New Coverage: 11.56%
Line New Coverage: 14.52%
Method New Coverage: 30.30%

org.pentaho.di.trans.steps.validator.KettleValidatorException

Complexity New Coverage: 16.67%
Instruction New Coverage: 60.43%
Line New Coverage: 30.43%
Method New Coverage: 20.00%

org.pentaho.di.trans.steps.validator.Validation

Branch New Coverage: 59.09%
Complexity New Coverage: 86.49%
Instruction New Coverage: 95.92%
Line New Coverage: 94.17%
Method New Coverage: 95.24%

org.pentaho.di.trans.steps.validator.Validation.DataTypeConverter

Complexity New Coverage: 50.00%
Instruction New Coverage: 50.00%
Line New Coverage: 50.00%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.validator.Validator

Branch New Coverage: 9.35%
Complexity New Coverage: 8.55%
Instruction New Coverage: 28.49%
Line New Coverage: 24.42%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.validator.ValidatorData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.validator.ValidatorMeta

Branch New Coverage: 47.06%
Complexity New Coverage: 55.56%
Instruction New Coverage: 61.67%
Line New Coverage: 62.61%
Method New Coverage: 64.29%

org.pentaho.di.trans.steps.valuemapper.ValueMapperMeta

Branch New Coverage: 31.58%
Complexity New Coverage: 57.78%
Instruction New Coverage: 59.32%
Line New Coverage: 61.11%
Method New Coverage: 80.77%

org.pentaho.di.trans.steps.webserviceavailable.WebServiceAvailableMeta

Complexity New Coverage: 61.54%
Instruction New Coverage: 48.56%
Line New Coverage: 51.19%
Method New Coverage: 72.73%

org.pentaho.di.trans.steps.webservices.WebService

Complexity New Coverage: 1.72%
Instruction New Coverage: 1.95%
Line New Coverage: 2.17%
Method New Coverage: 15.79%

org.pentaho.di.trans.steps.webservices.WebServiceField

Complexity New Coverage: 69.23%
Instruction New Coverage: 60.38%
Line New Coverage: 70.59%
Method New Coverage: 81.82%

org.pentaho.di.trans.steps.webservices.WebServiceMeta

Branch New Coverage: 67.86%
Complexity New Coverage: 77.38%
Instruction New Coverage: 94.93%
Line New Coverage: 92.67%
Method New Coverage: 89.29%

org.pentaho.di.trans.steps.webservices.wsdl.XsdType

Branch New Coverage: 58.33%
Complexity New Coverage: 26.67%
Instruction New Coverage: 81.02%
Line New Coverage: 65.38%
Method New Coverage: 66.67%

org.pentaho.di.trans.steps.writetolog.WriteToLog

Branch New Coverage: 44.44%
Complexity New Coverage: 33.33%
Instruction New Coverage: 67.42%
Line New Coverage: 67.14%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.writetolog.WriteToLog.new Object() {...}

Complexity New Coverage: 100.00%
Instruction New Coverage: 87.04%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.writetolog.WriteToLogData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.writetolog.WriteToLogMeta

Branch New Coverage: 37.50%
Complexity New Coverage: 62.50%
Instruction New Coverage: 64.20%
Line New Coverage: 61.84%
Method New Coverage: 89.29%

org.pentaho.di.trans.steps.xbaseinput.XBase

Branch New Coverage: 34.78%
Complexity New Coverage: 30.00%
Instruction New Coverage: 34.40%
Line New Coverage: 45.83%
Method New Coverage: 58.33%

org.pentaho.di.trans.steps.xbaseinput.XBaseInput

Branch New Coverage: 35.42%
Complexity New Coverage: 25.81%
Instruction New Coverage: 46.40%
Line New Coverage: 43.52%
Method New Coverage: 71.43%

org.pentaho.di.trans.steps.xbaseinput.XBaseInputData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.xbaseinput.XBaseInputMeta

Branch New Coverage: 15.22%
Complexity New Coverage: 48.48%
Instruction New Coverage: 55.49%
Line New Coverage: 57.67%
Method New Coverage: 72.09%

org.pentaho.di.trans.steps.yamlinput.YamlInputField

Branch New Coverage: 30.00%
Complexity New Coverage: 67.44%
Instruction New Coverage: 86.62%
Line New Coverage: 83.33%
Method New Coverage: 84.85%

org.pentaho.di.trans.steps.yamlinput.YamlInputMeta

Branch New Coverage: 36.76%
Complexity New Coverage: 63.33%
Instruction New Coverage: 67.26%
Line New Coverage: 63.58%
Method New Coverage: 82.14%

org.pentaho.di.trans.steps.zipfile.ZipFile

Complexity New Coverage: 2.44%
Instruction New Coverage: .94%
Line New Coverage: 1.28%
Method New Coverage: 22.22%

org.pentaho.di.trans.steps.zipfile.ZipFileData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.steps.zipfile.ZipFileMeta

Branch New Coverage: 87.50%
Complexity New Coverage: 93.62%
Instruction New Coverage: 93.02%
Line New Coverage: 94.16%
Method New Coverage: 100.00%

org.pentaho.di.trans.StepWithMappingMeta

Branch New Coverage: 30.00%
Complexity New Coverage: 60.00%
Instruction New Coverage: 36.93%
Line New Coverage: 53.95%
Method New Coverage: 92.86%

org.pentaho.di.trans.StepWithMappingMeta.new Object() {...}

Complexity New Coverage: 100.00%
Instruction New Coverage: 88.46%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.SubtransExecutor

Branch New Coverage: 33.33%
Complexity New Coverage: 54.55%
Instruction New Coverage: 65.70%
Line New Coverage: 73.08%
Method New Coverage: 100.00%

org.pentaho.di.trans.Trans

Branch New Coverage: 25.46%
Complexity New Coverage: 26.31%
Instruction New Coverage: 29.49%
Line New Coverage: 33.48%
Method New Coverage: 50.45%

org.pentaho.di.trans.Trans.BitMaskStatus

Complexity New Coverage: 50.00%
Instruction New Coverage: 89.66%
Line New Coverage: 100.00%
Method New Coverage: 50.00%

org.pentaho.di.trans.Trans.new Object() {...}

Complexity New Coverage: 100.00%
Instruction New Coverage: 88.46%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.Trans.new StepAdapter() {...}

Complexity New Coverage: 100.00%
Instruction New Coverage: 73.08%
Line New Coverage: 66.67%
Method New Coverage: 100.00%

org.pentaho.di.trans.Trans.new StepListener() {...}

Branch New Coverage: 37.50%
Complexity New Coverage: 42.86%
Instruction New Coverage: 31.16%
Line New Coverage: 44.00%
Method New Coverage: 66.67%

org.pentaho.di.trans.Trans.new ThreadFactory() {...}

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.TransAdapter

Complexity New Coverage: 50.00%
Instruction New Coverage: 66.67%
Line New Coverage: 50.00%
Method New Coverage: 50.00%

org.pentaho.di.trans.TransConfiguration

Complexity New Coverage: 25.00%
Instruction New Coverage: 12.90%
Line New Coverage: 20.00%
Method New Coverage: 25.00%

org.pentaho.di.trans.TransExecutionConfiguration

Branch New Coverage: 22.09%
Complexity New Coverage: 12.73%
Instruction New Coverage: 43.05%
Line New Coverage: 39.57%
Method New Coverage: 16.42%

org.pentaho.di.trans.TransHopMeta

Branch New Coverage: 62.50%
Complexity New Coverage: 57.14%
Instruction New Coverage: 80.07%
Line New Coverage: 80.36%
Method New Coverage: 81.25%

org.pentaho.di.trans.TransMeta

Branch New Coverage: 27.26%
Complexity New Coverage: 21.23%
Instruction New Coverage: 35.90%
Line New Coverage: 37.18%
Method New Coverage: 37.59%

org.pentaho.di.trans.TransMeta.TransformationType

Branch New Coverage: 50.00%
Complexity New Coverage: 50.00%
Instruction New Coverage: 75.40%
Line New Coverage: 76.19%
Method New Coverage: 62.50%

org.pentaho.di.trans.TransMetaFactoryImpl

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.trans.TransSupplier

Branch New Coverage: 75.00%
Complexity New Coverage: 46.15%
Instruction New Coverage: 69.23%
Line New Coverage: 75.00%
Method New Coverage: 44.44%

org.pentaho.di.www.AllocateServerSocketServlet

Branch New Coverage: 50.00%
Complexity New Coverage: 18.18%
Instruction New Coverage: 84.53%
Line New Coverage: 79.25%
Method New Coverage: 33.33%

org.pentaho.di.www.BaseCartePlugin

Branch New Coverage: 50.00%
Complexity New Coverage: 70.00%
Instruction New Coverage: 86.11%
Line New Coverage: 92.86%
Method New Coverage: 100.00%

org.pentaho.di.www.BaseCartePlugin.CarteRequestImpl

Branch New Coverage: 100.00%
Complexity New Coverage: 90.00%
Instruction New Coverage: 95.83%
Line New Coverage: 95.00%
Method New Coverage: 87.50%

org.pentaho.di.www.BaseCartePlugin.CarteRequestImpl.new CarteRequestHandler.CarteResponse() {...}

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.www.BaseHttpServlet

Branch New Coverage: 37.50%
Complexity New Coverage: 30.30%
Instruction New Coverage: 36.84%
Line New Coverage: 35.00%
Method New Coverage: 34.48%

org.pentaho.di.www.BodyHttpServlet

Branch New Coverage: 33.33%
Complexity New Coverage: 17.65%
Instruction New Coverage: 30.69%
Line New Coverage: 34.69%
Method New Coverage: 37.50%

org.pentaho.di.www.CarteObjectEntry

Branch New Coverage: 33.33%
Complexity New Coverage: 38.46%
Instruction New Coverage: 48.57%
Line New Coverage: 45.83%
Method New Coverage: 50.00%

org.pentaho.di.www.CleanupTransServlet

Branch New Coverage: 50.00%
Complexity New Coverage: 25.00%
Instruction New Coverage: 70.54%
Line New Coverage: 68.35%
Method New Coverage: 42.86%

org.pentaho.di.www.DefaultWebServerShutdownHandler

Complexity New Coverage: 50.00%
Instruction New Coverage: 75.00%
Line New Coverage: 50.00%
Method New Coverage: 50.00%

org.pentaho.di.www.GetJobStatusServlet

Branch New Coverage: 54.17%
Complexity New Coverage: 26.32%
Instruction New Coverage: 73.68%
Line New Coverage: 69.12%
Method New Coverage: 42.86%

org.pentaho.di.www.GetPropertiesServlet

Branch New Coverage: 50.00%
Complexity New Coverage: 80.00%
Instruction New Coverage: 90.24%
Line New Coverage: 92.31%
Method New Coverage: 100.00%

org.pentaho.di.www.GetRootServlet

Branch New Coverage: 33.33%
Complexity New Coverage: 33.33%
Instruction New Coverage: 13.53%
Line New Coverage: 20.69%
Method New Coverage: 50.00%

org.pentaho.di.www.GetStatusServlet

Branch New Coverage: 16.67%
Complexity New Coverage: 9.38%
Instruction New Coverage: 27.73%
Line New Coverage: 28.35%
Method New Coverage: 37.50%

org.pentaho.di.www.GetStatusServlet.new Comparator() {...}

Complexity New Coverage: 20.00%
Instruction New Coverage: 15.00%
Line New Coverage: 10.00%
Method New Coverage: 50.00%

org.pentaho.di.www.GetTransStatusServlet

Branch New Coverage: 29.17%
Complexity New Coverage: 12.90%
Instruction New Coverage: 68.83%
Line New Coverage: 64.86%
Method New Coverage: 42.86%

org.pentaho.di.www.JobMap

Branch New Coverage: 37.50%
Complexity New Coverage: 45.45%
Instruction New Coverage: 54.00%
Line New Coverage: 48.89%
Method New Coverage: 57.14%

org.pentaho.di.www.ListServerSocketServlet

Branch New Coverage: 31.25%
Complexity New Coverage: 14.29%
Instruction New Coverage: 50.36%
Line New Coverage: 52.27%
Method New Coverage: 33.33%

org.pentaho.di.www.PauseTransServlet

Branch New Coverage: 45.83%
Complexity New Coverage: 21.05%
Instruction New Coverage: 67.98%
Line New Coverage: 64.38%
Method New Coverage: 42.86%

org.pentaho.di.www.PrepareExecutionTransServlet

Branch New Coverage: 42.31%
Complexity New Coverage: 20.00%
Instruction New Coverage: 54.58%
Line New Coverage: 59.38%
Method New Coverage: 42.86%

org.pentaho.di.www.RemoveJobServlet

Branch New Coverage: 50.00%
Complexity New Coverage: 25.00%
Instruction New Coverage: 71.53%
Line New Coverage: 68.85%
Method New Coverage: 42.86%

org.pentaho.di.www.RemoveTransServlet

Branch New Coverage: 50.00%
Complexity New Coverage: 25.00%
Instruction New Coverage: 71.81%
Line New Coverage: 68.85%
Method New Coverage: 42.86%

org.pentaho.di.www.RunTransServlet

Branch New Coverage: 50.00%
Complexity New Coverage: 36.36%
Instruction New Coverage: 65.36%
Line New Coverage: 71.59%
Method New Coverage: 54.55%

org.pentaho.di.www.SlaveServerConfig

Branch New Coverage: 24.14%
Complexity New Coverage: 13.16%
Instruction New Coverage: 11.76%
Line New Coverage: 12.18%
Method New Coverage: 6.38%

org.pentaho.di.www.SlaveServerJobStatus

Branch New Coverage: 25.00%
Complexity New Coverage: 67.74%
Instruction New Coverage: 74.93%
Line New Coverage: 79.52%
Method New Coverage: 84.00%

org.pentaho.di.www.SlaveServerTransStatus

Branch New Coverage: 13.89%
Complexity New Coverage: 46.00%
Instruction New Coverage: 54.56%
Line New Coverage: 60.00%
Method New Coverage: 71.88%

org.pentaho.di.www.SniffStepServlet

Branch New Coverage: 34.00%
Complexity New Coverage: 15.62%
Instruction New Coverage: 49.36%
Line New Coverage: 52.80%
Method New Coverage: 42.86%

org.pentaho.di.www.SniffStepServlet.MetaAndData

Complexity New Coverage: 100.00%
Instruction New Coverage: 100.00%
Line New Coverage: 100.00%
Method New Coverage: 100.00%

org.pentaho.di.www.SniffStepServlet.new RowListener() {...}

Complexity New Coverage: 12.50%
Instruction New Coverage: 29.51%
Line New Coverage: 10.00%
Method New Coverage: 25.00%

org.pentaho.di.www.SocketPortAllocation

Complexity New Coverage: 42.86%
Instruction New Coverage: 50.00%
Line New Coverage: 47.17%
Method New Coverage: 48.00%

org.pentaho.di.www.StartExecutionTransServlet

Branch New Coverage: 42.31%
Complexity New Coverage: 23.81%
Instruction New Coverage: 58.42%
Line New Coverage: 60.49%
Method New Coverage: 50.00%

org.pentaho.di.www.StartJobServlet

Branch New Coverage: 34.38%
Complexity New Coverage: 20.83%
Instruction New Coverage: 52.91%
Line New Coverage: 53.93%
Method New Coverage: 50.00%

org.pentaho.di.www.StartTransServlet

Branch New Coverage: 45.83%
Complexity New Coverage: 25.00%
Instruction New Coverage: 69.19%
Line New Coverage: 67.90%
Method New Coverage: 50.00%

org.pentaho.di.www.StopJobServlet

Branch New Coverage: 45.45%
Complexity New Coverage: 22.22%
Instruction New Coverage: 68.03%
Line New Coverage: 65.22%
Method New Coverage: 42.86%

org.pentaho.di.www.StopTransServlet

Branch New Coverage: 45.45%
Complexity New Coverage: 22.22%
Instruction New Coverage: 68.86%
Line New Coverage: 65.22%
Method New Coverage: 42.86%

org.pentaho.di.www.TransformationMap

Branch New Coverage: 50.00%
Complexity New Coverage: 27.69%
Instruction New Coverage: 46.87%
Line New Coverage: 51.54%
Method New Coverage: 28.57%

org.pentaho.di.www.WebServer

Branch New Coverage: 44.44%
Complexity New Coverage: 27.78%
Instruction New Coverage: 64.54%
Line New Coverage: 61.54%
Method New Coverage: 36.11%

org.pentaho.di.www.WebServer.new TimerTask() {...}

Complexity New Coverage: 33.33%
Instruction New Coverage: 13.64%
Line New Coverage: 8.33%
Method New Coverage: 50.00%

org.pentaho.di.www.WebServerShutdownHook

Branch New Coverage: 50.00%
Complexity New Coverage: 60.00%
Instruction New Coverage: 58.33%
Line New Coverage: 58.33%
Method New Coverage: 75.00%

org.pentaho.di.trans.steps.googleanalytics.GaInputStepMeta

Branch Change: -1.85%:small_red_triangle_down:
Complexity Change: -1.06%:small_red_triangle_down:

org.pentaho.di.ui.repository.pur.repositoryexplorer.model.UISecurityRole

Branch Change:  + 1.79%
Complexity Change:  + 1.54%
Instruction Change:  + .16%
Line Change:  + .58%

org.pentaho.di.trans.steps.salesforceinsert.SalesforceInsertMeta

Instruction Change: -.15%:small_red_triangle_down:


fix(env-docs): removed auth variables and improved docs

Removed nextauth variables
Changed default values on env.example
Added video tutorial

I think some of the env parts overlapped with this PR: #163
How do you think about combining the content of this 2 PR?

I agree, this branch is more updated so will add the contents of #163 to this one

Added and improved https://github.com/privacy-scaling-explorations/maci-rpgf/pull/163


Login Form template not found

This link is dead:
http://codepen.io/chalarangelo/pen/xGmWrVv/
Found here:
http://minicss.org/templates

Thanks for reporting this! Unfortunately, I'm on vacation until the 15th of August with limited access to a computer, but I'll see what I can do as soon as I get a chance!


Document data resources

Perhaps start as a google doc to keep list of where things come from and provide user-level and technical documentation.

Duplicate of (or at least merge-able with) #20


vulkan-validation-layers: <IP_ADDRESS> -> <IP_ADDRESS>

This requires knock-on upgrades for glslang and spirv-tools.
I have also made the validation layers easier to use:

library files identified by layer definitions now use absolute paths
a VK_LAYER_PATH environment variable is set

Previously, one would have to modify LD_LIBRARY_PATH or install the
derivation in a known location for vulkan-loader to find relevant
files. These changes make using validation layers in a nix-shell work automatically.
Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

I had thought @Ralith would be tagged automatically, but in any case they are the listed maintainer for these derivations so I hope they can take a look at these changes.

Regarding the version, I just wanted to bring it in line with the other vulkan pieces in nixpkgs to avoid bundling too many changes into one PR. I thought a version bump on all the pieces could follow this one.

Best squash before merging.

Squashed

I'm not sure how to advance this as it was intended primarily as a usability improvement since I had trouble making the existing packaging work. There is a reasonable argument that this constellation of packages -- vulkan-loader, vulkan-headers, glslang, spirv-tools, spirv-headers, and probably others -- should be reconsidered given the way upstream cuts releases. Namely, upstream effectively treats everything as a submodule, but doesn't use the native git mechanisms for doing so.
It might make sense, then, for nixpkgs to move dependencies into the packages that require them (either as let bindings or separate .nix files in, e.g., the vulkan-validation-layers directory) rather than placing particular revisions into the nixpkgs name space. We would probably want to take care that things like vulkan-headers and vulkan-loader not exist at multiple distinct revisions across nixpkgs, but we can hope that the relevant known_good.json won't demand that.
I'm not going to make a sweeping change as I don't know if there is a broader willingness to do so, and everything other than the validation layers was already working fine. But it seems that this PR is stuck on the derivation naming objection until someone does the necessary refactoring.
I'll try to find a home for the usability changes on NUR or somewhere so anyone else wanting to use the validation layers can have an easier time.

I don't think this (or other version/usability updates) should be blocked on orthogonal organizational questions. I think this should be reopened and merged as-is.

Agreed. I was suggesting a simple cosmetic change and it ended up being way more of a can of worms than a realise. @acowley if you want to reopen I'm happy to merge.

Okay, great! I think you’re actually right that this is a lurking problem. I wonder if we should nudge upstream to depend on tagged releases.

I think the right way to go forward in the future is to switch the exposed packages of glslang and spirv-tools to use the release tags they seem to have finally started making (even shaderc has one now!), then use overrides or local definitions as needed in vulkan-* and shaderc. Might be best to pursue that in a separate PR, though.

@GrahamcOfBorg build vulkan-validation-layers

Okay, great! I think you’re actually right that this is a lurking problem. I wonder if we should nudge upstream to depend on tagged releases.

I think the right way to go forward in the future is to switch the exposed packages of glslang and spirv-tools to use the release tags they seem to have finally started making (even shaderc has one now!), then use overrides or local definitions as needed in vulkan-* and shaderc.

Vith of these sound like very good ideas, and I strongly encourage both of you to follow up on them. We shouldn’t have packages pinned to a specific git commit in nixpkgs just because that’s what one dependent package wants. For now, I don’t think that updates should be blocked on that, but it really should be fixed sooner rather than later — if other things start to depend on those packages, them being at arbitrary commits could start to cause problems.


1.16.x 1.0.0: 6.1 - Java 9+ compatibility

If possible, should make the mod/plugin compatible with newer versions of Java in the 1.13+ release. Should theoretically be possible to compile with a newer version while keeping 8 as the target version. Gradle needs to be updated to do this.

Thanks for the feedback, will definitely take a look at this for 1.13+.

Should be fixed with 0.0.5 :)


Temporarily shut off access to MDI until after the 1.1.1 release.

Description:

This issue is just to be certain that and access to MDI is not available to users in the 1.1.1 release (because the code for it is far from complete).

I switched the wxWidgets build back to 3.2 (from 3.3) and even with INTERNAL_TESTING still turned on, I couldn't find a way to insert a MDI form (Insert Widget couldn't find it, and it's not on the main tool panel).


We should disable/remove all places in the code where we request info from Cantus Index

Planning on embarking on this task today.
As I go, I'll compile a list here of features I've properly disabled, so we can re-enable them once we're storing info on Cantus IDs in our own database.
These features should be gracefully disabled for the time being, and they'll need to be significantly reworked anyways when we implement our improved/sustainable solution.

[ ] Century Detail View
[ ] Chant Detail View
[ ] Chant List View
[ ] Chant By Cantus ID View
[ ] Chant Search View
[ ] Melody Search View
[ ] Chant Search MS View
[ ] Chant Create View
[ ] Chant Delete View
[ ] CI Search View
[ ] Chant Index View
[ ] Source Edit Chants View
[ ] Chant Edit Syllabification View

Things removed:

Chant Detail view

within get_context_data, remove calculation of concordances
earlier in the file, remove CANTUS_NETWORK_DATABASES dictionary
earlier in the file, remove make_concordances_database_summary function


Metric/big number widget tooltip for actual value

Sometimes I want to get access to the actual value in the metric widget and the condensed version makes it tricky. Would be nice to display it on hover in a tooltip or something.

@johnsheehan I updated the widget markup in v3.2 to display the full value with a title attribute, so if you hover briefly it'll appear. This little hack isn't ideal, but it works for now. We should really look into new viz types for metric displays.
https://github.com/keen/keen-js/blob/master/CHANGELOG.md#3.2.0


fix tleap parameterizing and am1bcc api

Description
fixes TLeap/GAFF forcefield, include:

incorrect charges.txt format
incorrect indentation leading to incorrect molecule number in assign parameter step after build coordinates
incorrect quit command and error log parsing when running tleap
outdated compute_am1bcc_charges interface to openff-toolkit

fix outdated api to assign_partial_charges(partial_charge_method="am1bcc")
I closed the previous PR #478, and this PR includes necessary changes for the TLeap backend to work properly.
Other modifications in #478 are either reverted or will be handled by #479 .
Todos
None
Questions
None
Status

[x] Ready to go

Thanks for your continued patience and contributions!
The Molecule.compute_partial_charges_am1bcc changes are an immediate approval. I'll need to read over some code to understand the tleap changes; this code is covered in some capacity by unit tests, so I'm n
This is also a good time to disclose that I'm not the original developer of this package. It takes me longer than typical to review PRs here since I often have to understand code I'm not so familiar with, but I am making an effort. If it looks like I'm figuring out some details on the fly - well, it's because I mostly am 🙂

the tleap backend requires two fixes:

the charges file format is not proper so when antechamber reads the partial charges it misreads this charges then throw all kinds of warnings such as total partial charge is not integral, and so on
the tleap backend parameterizes one molecule correctly, but the step where each molecule is added to the system, the loop body is mis-indented so only one molecule is added to the openmm system. then the following steps fail because the coordinate pdb file atom number does not match the actual atom number in the openmm system

Thanks again for the contribution, it's merged as part of #489. I was overthinking earlier and because I'm not a heavy Amber user, I wasn't sure how to start reasoning through the changes.


Cli fix

What type of PR is this?

Which issue does this PR fix:
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs from IPAMD/CNI showing the issue:
Testing done on this change:

Automation added to e2e:

Will this break upgrades or downgrades. Has updating a running cluster been tested?:
Does this change require updates to the CNI daemonset config files to work?:

Does this PR introduce any user-facing change?:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@roxanaN what bug is this PR fixing?

@roxanaN what bug is this PR fixing?
The issue is that zot cli should not download manifests when listing images:
https://github.com/project-zot/zot/issues/222


How can i change channel or increment volume?

Hi, my Samsung TV turns off when i ask Siri but it can't change the channel or volume.
It appears like a switch in Home app.
Thanks!

Hi, the iOS Home app does not support these characteristics itself (as described here #7). You can e.g. use the Homekit Catalog Sample App to set up scenes for them and then use these scenes in the actual home app as well.
Hope this helps you.


Expression with sum, difference, product and quotient

Implement expression functionality for these 4 basic operators

Sum and difference done


Update metamask.mdx

public node url is not available anymore. found this issue at eth global bankok.
To reflect the latest url based on https://dev.rootstock.io/developers/rpc-api/rootstock/methods/

The pictures in this file should probably need to be updated as well.


Compile seems to not include tkdnd package needed for tkinterdnd2

Nutika version:

0.7.7
Commercial: None
Python: 3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 23:13:41) [MSC v.1929 64 bit (AMD64)]
Flavor: Unknown
Executable: C:\Users\Steven\AppData\Local\Programs\Python\Python310\python.exe
OS: Windows
Arch: x86_64
WindowsRelease: 10

nuitka and tkinterdnd2 were installed through pip install, on pip 22.1.

Target  Test.py:
from tkinterdnd2 import *

ws = TkinterDnD.Tk()

ws.mainloop()

Commands used:
   python -m nuitka --follow-imports --standalone --enable-plugin=tk-inter Test.py
   python -m nuitka --follow-imports --onefile --enable-plugin=tk-inter Test.py

Compiling seems to work fine but when the .exe is opened it produces the following error:
Traceback (most recent call last):
  File "C:\Users\Steven\AppData\Local\Temp\ONEFIL~1\tkinterdnd2\TkinterDnD.py", line 53, in _require
_tkinter.TclError: can't find package tkdnd

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Steven\AppData\Local\Temp\ONEFIL~1\Test.py", line 4, in <module>
    ws = TkinterDnD.Tk()
  File "C:\Users\Steven\AppData\Local\Temp\ONEFIL~1\tkinterdnd2\TkinterDnD.py", line 285, in __init__
  File "C:\Users\Steven\AppData\Local\Temp\ONEFIL~1\tkinterdnd2\TkinterDnD.py", line 55, in _require
RuntimeError: Unable to load tkdnd library.

This issue only happens when --standalone or --onefile is used, running a compile without them works completely fine and starts the .exe as intended.
I'm not quite sure why this error occurs, any insights on it would be welcome.

Accelerated mode loads installed modules, so anything not compiled will still be found.

This is on the factory branch.
I made several changes. First off, I made a change to anti-bloat configuration that in case of missing tkinter plugin will give a runtime error message that is more informative. More of these changes will come for plugins that need to be decided by the user.
Then, plugins now can provide package data, in this case, the path of the data needed is OS dependent, but this allows the tk-inter plugin to add package data for tkinterdnd2, but to also filter it for the OS directory. This ability should come in handy, e.g. when we enhance command line --include-package-data to allow for patterns of what should be included.
And then the DLL needed per platform is also added. This is still a bit manual, one day we should have an easy way to include DLLs of the current platform from the package listing.
With this, it works though, and tk-inter support has become nicer too.

Check it out from here: https://nuitka.net/doc/factory.html

Hello Kay, thank you for the quick response and fix for the issue, I've tested around with it for a little bit and it seems to work wonderfully so far!

Part of the current pre-release on develop branch.

Part of 0.8 release that I just made.


Option to pick a local mirror for Docker binaries

Those among us doomed to deal with corporate proxies mgith be able to download binaries to a local mirror or use something like Artifactory.
Suggestion: "dvm" would accept a MIRROR_URL environment variable that points to another place where the Docker binaries were previously downloaded.

I'd like to see this environment variable prefixed with DVM_

Thanks for the PR!

Thank you for implementing this change! I just publish dvm 0.5.0, run dvm upgrade to get it. Afterwards you can use DVM_MIRROR_URL or dvm install --mirror-url http://mymirror/builds to specify an alternate download location.


Support git submodules

It would be great if a flag was added or set to default that would pull git submodules when installing a filter

I think it should by default try to fetch submodules.
Seems like here we should add --recurse-submodules --j8 flags
https://github.com/Bedrock-OSS/regolith/blob/main/regolith/filter_remote.go#L438
And here should be another git command git submodule update --init --recursive
https://github.com/Bedrock-OSS/regolith/blob/main/regolith/filter_remote.go#L486


add build step for linux

see https://github.com/joshwcomeau/guppy/issues/45#issuecomment-405089554

Looks great! Thanks :)


Stackup.get_layout_thickness() should be a property

Description of the feature
Methods that only return a value should be properties. In this case without a setter.
@property
def layout_thickness(self):
   return self.get_layout_thickness()

The get_layout_thickness() method should then be moved to a hidden method and later deprecated.
Steps for implementing the feature
Use the @property decorator.
Useful links and references
https://www.freecodecamp.org/news/python-property-decorator/

@dcrawforAtAnsys done


Dev workflow changes

What changes were proposed in this pull request?
Added lines to documentation to have the contributor check to see if they have yarn and node installed correctly.

How was this pull request tested?
Reviewed the page after make docs

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 Apache License 2.0; 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.

Sounds fair, Make should be included as a required utility, maybe include a small non-support disclaimer for windows and only include link for installation in *nix environments

@salonee13 - you're probably busy making changes to the community repository. Let us know if you are unable to get to this before semester end and we can merge as is.


Defect: co_broadcast derived type with allocatable components

[x] I am reporting a bug others will be able to reproduce and not asking a question or requesting a new feature.

System information including:

OpenCoarrays Version: OpenCoarrays Coarray Fortran Compiler Wrapper (caf version 2.9.2)
Fortran Compiler: GNU Fortran (Homebrew GCC 10.2.0_2) 10.2.0
C compiler used for building lib: unknown
Installation method: homebrew
All flags & options passed to the installer
Output of uname -a: Darwin Brads-MBP.lan 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec  2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 x86_64
MPI library being used: openmp ?
Machine architecture and number of physical cores: Intel x86-64, 8 cores
Version of CMake: N/A

To help us debug your issue please explain:
What you were trying to do (and why)
Attempting to use co_broadcast with a derived type.
What happened (include command output, screenshots, logs, etc.)
Not all components are copied correctly.
What you expected to happen
All components should be broadcast to all images.
Step-by-step reproduction instructions to reproduce the error/bug
A minimal reproducer that might serve as a regression test is below:
  implicit none

  type foo_t
    integer i
    integer, allocatable :: j
  end type

  type(foo_t) foo
  integer, parameter :: source_image = 1

  if (this_image() == source_image)  then
    foo = foo_t(2,3)
  else
    allocate(foo%j)
  end if
  call co_broadcast(foo, source_image)

  if ((foo%i /= 2) .or. (foo%j /= 3))  error stop "Test failed."
  sync all
  print *, "Test passed."

end

With 11.2.0, the above code prints, "Test failed."

As @everythingfunctional has pointed out offline, the issue here appears to be mixing a non-allocatable component with an allocatable component.  We currently have two orthogonal tests:

allocatable-component co_broadcast unit test.f90, where all components are allocatable, and
co_broadcast_derived_type.f90, where no components are allocatable.

To expose this, we probably just need a simple test with both an allocatable component and a non-allocatable component.

@rouson @everythingfunctional: It looks like this issue is not yet fixed.  Are there plans to fix it in the near future?
As you know, there are possible workarounds, but it would be nice to be able to use intrinsic co_broadcast rather than create custom broadcast procedures to work around the issue.

@praynaud I'll reopen it and investigate how to turn off the bot that closed this issue.  I'll contact you to discuss the status and plan for a fix.

The original reproducer is as follows:
module foo_m
    implicit none

    type :: foo_t
        integer :: i
        integer, allocatable :: j(:)
    contains
        procedure :: broadcast
    end type
contains
    subroutine broadcast(self, source_image)
        class(foo_t), intent(inout) :: self
        integer, intent(in) :: source_image

        type(foo_t) :: message
        integer :: size_j

        associate(me => this_image())
            if (me == source_image) then
                size_j = size(self%j)
            end if

            call co_broadcast(size_j, source_image)

            if (me == source_image) then
                message%i = self%i
                message%j = self%j
            else
                allocate(message%j(size_j))
            end if

            call co_broadcast(message, source_image)

            if (me /= source_image) then
                self%i = message%i
                self%j = message%j
            end if
        end associate
    end subroutine
end module

program main
    use foo_m, only: foo_t

    implicit none

    type(foo_t) :: foo

    associate(me => this_image())
        if (me == 1) then
            foo = foo_t(100, [1,2])
        end if
        call foo%broadcast(1)

        print *, "foo%i = ", foo%i, ", foo%j = ", foo%j, "on image: ", me
    end associate
end program

and the corresponding output:
[Brads-MBP:~/tmp/co_broadcast] caf co_broadcast_derived_type.f90
[Brads-MBP:~/tmp/co_broadcast] cafrun -n 2 a.out
 foo%i =          100 , foo%j =            1           2 on image:            1
 foo%i =            0 , foo%j =            1           2 on image:            2

Test case at: https://github.com/sourceryinstitute/OpenCoarrays/pull/new/issue-727-co-broadcast-on-mixed-derived-type
Unfortunately this is a compiler bug and can not be fixed in the library itself.

@rouson Is the next step then to submit a compiler bug to gfortran?

@praynaud done: see gfortran bug report 103970
@vehre please let us know whether you can work on the compiler fix.

That would allow me to submit a patch. Doing the PR and patch myself always
feels Abit odd. So when you can file it, I can provide the patch.

@vehre see PR 103970

Well, the patch is nearly done. I just have to do a testcase for the
fortran patch or it won't get accepted.

The patch is available at: https://gcc.gnu.org/pipermail/fortran/2022-January/057459.html


The generated source dir for apt and kapt is different?

for example,An android project with the variant(Flavor1 + Debug)
kapt
The generate source files will be put into "build/generated/source/kapt/flavor1Debug"
apt
The generate source files will be put into "build/generated/source/apt/flavor1/debug"
what i mean is that "flavor1Debug" and "flavor1/debug" is so much different, why?

https://discuss.kotlinlang.org/t/the-generated-source-dir-for-apt-and-kapt-is-different/2479


[SPARK-35734][SQL] Format day-time intervals using type fields

What changes were proposed in this pull request?

This PR add a feature which formats day-time interval to strings using the start and end fields of DayTimeIntervalType.
Why are the changes needed?

Currently, they are ignored, and any DayTimeIntervalType is formatted as INTERVAL DAY TO SECOND.
Does this PR introduce any user-facing change?

Yes. The format of day-time intervals is determined the start and end fields.
How was this patch tested?

New test.

cc: @MaxGekk

Test build #139736 has started for PR 32891 at commit cc76b12.

Test build #139736 has finished for PR 32891 at commit cc76b12.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44261/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/139736/

Test build #139737 has started for PR 32891 at commit 557acd4.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44262/

Test build #139738 has started for PR 32891 at commit 89a36e9.

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44261/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/44261/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44262/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44263/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/44262/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44263/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/44263/

Test build #139737 has finished for PR 32891 at commit 557acd4.

This patch fails PySpark pip packaging tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/139737/

Test build #139738 has finished for PR 32891 at commit 89a36e9.

This patch fails PySpark pip packaging tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/139738/

+1, LGTM. Merging to master.
Thank you, @sarutak .


Make configurable if AbstractAssert#equals throws an exception

Check List:

Fixes #1128
Unit tests : YES
Javadoc with a code example (API only) : NO

Done

Thanks @guenhter.


Add aqara lock support

Signed-off-by: SchumyHao<EMAIL_ADDRESS>Description:
Add aqara lock support
Related issue (if applicable): fixes #
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

Hello @SchumyHao,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

35c0466414c149ce9b894b205359e8ee3aba3cb1 - This commit has something that looks like an email address (bob-hjl@126.com). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

Hi @SchumyHao,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

Plesse fix the lint errors. I'm very happy with your approach!

I've release PyXiaomiGateway 0.9.2. Please update the requirements!

Hi @syssi
I have update the requirement.
Thank you for your review.

requirements_all.txt is not up to date
Please run script/gen_requirements_all.py

Please update (PyXiaomiGateway=0.9.3) or rebase the PR. Thanks in advance! :-)

Could you add some docs?

OK, I'll do this job.
I have forked https://github.com/SchumyHao/home-assistant.github.io I'll create a PR later.

I added some basic docs: https://github.com/home-assistant/home-assistant.github.io/pull/5387

I'm not sure what should I do in next step?
@syssi  Can you show me what should I do to push this PR merged?

Thank you @syssi. Please let me know if I need do something more.


schema: fix broken icons link

Update the icons map link to point to the icons.go file in the pixlet repository that is the current location for this validation map.

I have read the CLA Document and I hereby sign the CLA


Change GitHub organization

...from rubocop-rspec to rubocop-hq
This PR should also be used to test all the webhooks etc.

I think I found the right button to click for Circle CI to work again.

also mentioned in CONTRIBUTING and PULL_REQUEST_TEMPLATE

Thanks for notifying. Somehow I cannot make ag search in the .github folder :-/
I updated the PR.

I think I found the right button to click for Circle CI to work again.

CodeClimate, too.

CircleCi and CodeClimate should be set up now. In this PR I have changed all references to github.com/rubocop-rspec to github.com/rubocop-hq, and badges etc. are updated. CircleCI has a CC_TEST_REPORTER_ID ENV variable, which has been changed as well.


Add support for tuc

Fixes #2613
Changes proposed:

[x] Add
[ ] Delete
[ ] Fix
[ ] Prepare

The icon need some changes as the margins are not present.

I edited the svg manually, to "match" other icons. This is originally exported svg from illustrator https://raw.githubusercontent.com/MortalFlesh/tuc-console/master/docs/assets/tuc-logo-32.svg is it better?
I'm not that familiar with svg, so could you add more info about whats wrong, please?
Thank you

@MortalFlesh Please take a look at https://github.com/vscode-icons/vscode-icons/wiki/Contributing
TLDR; the icon has the correct size (32x32px) but lacking the margins on every side (2px per side).

Hello @KingDarBoja
thanks for clarification - I missed it before.
Is it correct now?

And I can't see why those security checks fail.

I have no idea what happened but looks like the PR got closed and master branch (of MortalFlesh repo) got reset?

Well I have no idea either, I didn't do anything about it..
Thanks for reopening the PR by yourself.


Uninstall 04 | Remove unnecessary inactive delete modal areas

Remove unnecessary inactive delete modal areas since all of these are handled now in the Uninstall modal.
Related to #2402
Checklist

[ ] Did you add a JIRA issue in a commit message or as part of the branch name?
[ ] Did you add new unit tests?
[ ] Did you add new integration tests?
[ ] If this is a regression, did you write a test to catch this in the future?

https://media.giphy.com/media/l3q2FZFDqFmK8fkuA/giphy.gif

@bstavroulakis I hope you don't mind but I rebased this for you because I merged 03 and it caused build errors on this PR due to the change in package dependencies in 03. @weblancaster can you please add your review again since it was dismissed?

@MatApple Good idea! I rebased 05 Uninstall as well.
@weblancaster One tick again since we rebased so we can merge :)


Get project setup on everyone's machine

Kendra out with Covid, project is setup on everyone's machine except for hers.


Camera uses Watcher to manage matrix regeneration

This pull request updates the Camera to use Watcher to ensure that all transformations to the viewport and camera are reflected by regenerating the underlying view and projection matrices.

This just feels cleaner.


'Advanced' Button Generator options

Add a new 'Advanced' button next to 'Reset' that expands the form to cover all of the other options available.
Up to you if you want to have the button be a toggle between 'Advanced' and 'Simple' or if it's just one way that requires a refresh to get back to the current 'Simple' form options.

We really do want random-satoshis to be in there (either in simple or advanced) since there will certainly be people who want to turn it off but won't see the option.

I think 'Widget' (toggle) should be on the 'Simple' side.

I had a chat


Update README image of classroom roster

Notes

Screenshot of classroom roster page in README is out of date.
This fixes #1271.

🚢


fix: ci changes

:tada: This PR is included in version 3.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


1.18 forge and fabric

Could you port this mod to Minecraft 1.18.1 both forge and fabric?

would be great

Yes! I am working on it now :)


[Mobile] Context menu stay visible after Paste action

Is there an existing issue for this?

[X] I have searched the existing issues

Flutter Quill version
10.1.10
Steps to reproduce

Enter text
Copy text
Try to Paste
Try to enter new text
Try to Paste

Expected results
Context menu is hidden after each Copy/Paste action
Actual results
Context menu is visible
Code sample
Code sample
[Paste your code here]

Additional Context

Screenshots / Video demonstration

Logs
[Paste your logs here]

Ok with version 9.5.23, so relates to https://github.com/singerdmx/flutter-quill/pull/2026

I'll take a look about it. Thanks for create the issue

Reopened since the fix #2116 removed in #2128


[demo-app] Add ability to cause an ANR (application not responding)

Much like the ability to crash the application, we want to be able to manually/intentionally trigger an ANR. We should build this capability into the demo application.
Relates to the questions in #496.

@breedx-splk Can you please assign this to me? i can give it a try and add the ANR simulation code to the main activity and Implement the ANR Logic to it and you review. Also the repo Readme.md file shows some of the features included in the demo app already includes the ANR feature , does that mean we just have to modify an already implemented ANR feature? if so where can i find the file to work on. Thank You

@Victorsesan thank you so much to offering to work on this, but another contributor @magda-woj explained on the weekly SIG meeting today that the code is written and a PR will be submitted right after #627 is merged.
The help is definitely welcome, so please feel free to look into other issues or just directly submit a PR for something else without being assigned (it's not required). Thanks again.


Add option for custom validator for Path params.

Nowadays, the only supported validation for Path params are the given ones (le, ge, etc).
I think there are many use cases where we want to sanitize and validate input of Path parameters that is "smarter" than the given options.
I will add documentation once I get approval of concept :)

@tiangolo I hope things are going well, hopefully you can check this out :)

@aviramha Any chance you can add this feature for query parameters too, Currently query parameters have similar validation options as path parameters and they should be similar to setup in Pydantic I think.
@tiangolo Please consider this merge request, having custom validators would be a nice feature when one is doing more complex validations.

@M-e-r-c-u-r-y Yes I can add but I'd like initial approval of current implementation before adding it to any more places :)

Thanks @aviramha! :nerd_face:
I think this would make sense at the Pydantic level, Field() could take a validator directly, right?
Then that functionality would only be inherited here instead of extended.
That would probably need to wait for Pydantic v2 or be part of it, as I guess no new PRs will be accepted for v1.
What do you think?

Sorry for the long delay! 🙈  I wanted to personally address each issue and they piled up through time, but now I'm checking each one in order.

Hi @tiangolo
I have pretty much lost the context and can't really answer correctly as I'm not following nor using FastAPI in the last few months (just not using Python, still love FastAPI :))

Thanks for coming back! And yep, makes sense.
I'll close this one then. Thanks! 🍰


LiteCommands does not support multiple arguments

As shown above. While using LiteCommands to configure commands, Correct usage shows only first argument, not the second one.

 As shown above. While using LiteCommands to configure commands, Correct usage shows only first argument, not the second one.

Can you send me the code?

 As shown above. While using LiteCommands to configure commands, Correct usage shows only first argument, not the second one.

Can you send me the code?

all eternalcore commands

 As shown above. While using LiteCommands to configure commands, Correct usage shows only first argument, not the second one.

Can you send me the code?

yes. no problem.
code here: https://github.com/EternalCodeTeam/EternalCore/blob/litecommands-3.0.0/eternalcore-core%2Fsrc%2Fmain%2Fjava%2Fcom%2Feternalcode%2Fcore%2Ffeature%2Fessentials%2Fmob%2FButcherCommand.java


Fix typo in CHANGELOG.md

Summary
I fixed a typo in the changelog file.
Short checklist

[X] Did you run bundle exec rubocop -a to fix linter issues?
[X] If relevant, did you create a test?
[X] Did you confirm that the RSpec tests pass?
[X] If you are fixing a bug or introducing a new feature, did you add a CHANGELOG entry?

Other Information
If there's anything else that's important and relevant to your pull
request, mention that information here.
If you are updating any of the CHANGELOG files or are asked to update the
CHANGELOG files by reviewers, please add the CHANGELOG entry at the top of the file where indicated.
Thanks for helping improve Capistrano!

Good catch. Thanks! 🙇


would like to be able to get nfs connection count per node if possible

We already have CIFS connection counts. I'm going to be asked about NFS connection counts at some point. I'm trying to build some Grafana screens for our monitoring reporting people.  FWIW everything so far is outstanding with Harvest 2.0 and then the new nabox3 layered on top.
Thank you for your time

Good point. Or would it be possible active nfs connections per volume/lif like „nfs connected clients show“ ?


Inspect metadata instead of serializing it

Hi and thank you for this amazing library 👋
I've recently started using disco log in one of my projects and, as it often goes, one of the very first struggles is metadata. In particular, metadata is usually serialized to json and as we all know not every Elixir term is serializable.
But with the way it's implemented in DiscoLog, I don't think it has to be serialized to json? It attaches metadata as a file attachment, and it can very well use inspect/2 and put it into .ex file instead of .json. Discord will even properly apply code highlighting to it:

WDYT?

This is the commit when I started using a custom encoder because some Terms where crashing my handler
https://github.com/mrdotb/disco-log/commit/48d859b9ff4ebaccd831b28630a33ddb94c0c45a
When sending metadata the data is passed as a file so you are right the custom encoder is probably not necessary here.
Could you amend your commit to put feat:  in front.

Thanks for the contribution :+1:

I release the 0.6.0 with your pr and a bit of chores
If you can put a good word on the elixir forum topic
https://elixirforum.com/t/discolog-use-discord-as-a-logging-service-and-error-tracking-solution/65730/5


"/components/jquery/jquery.js does not exist", assetic:dump with components errors

Hello,
I have a problem with the "php app/console assetic:dump" command :
The source file "/home/me/public_html/client/app/../web/components/jquery/jquery.js" does not exist.

But in "vendor/components/jquery" the "jquery.js" file exist...
Any idea ?
Thanks.

having this issue...  The source file "/app/../web/./vendor/jquery/jquery/jquery-1.11.2.js" does not exist.

Try cache clear before assetic:dump


Bug: Player changes after invalid move

When a player wants to execute a move which is deemed invalid:

the message invalid will be display and
no token is placed on the board.

Bug: But the current player changes/switches even though the player has not made a move or passed.
Fix: Player should be asked again to execute a move. Current player doesn't change after an invalid move.

I was not able to recreate your situation but found another one:

start a new game
place one black and one white stone according to the image below

Now it's blacks turn again. Try to place the stone in the upper right corner, the move is valid but no stone gets added to the board. The function place_stone returns true even though the variable is_valid is False and no stone was added to the board. Thus, the move is considered as finished, the message Nice Move! is displayed, and it's the next players turn.


docs: rename to cli

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


NO TEXTURE

When i hold or have in my inventory a air baloon there is no texture (pink and black) help?

Balloon textures work fine with vanilla resource pack, but upon using a resource pack, the balloon textures change to the pink and black 'texture missing' graphic.

I don't have any texture pack and I'm in 1.12

https://github.com/elytra/DavincisVessels/blob/1.12/CONTRIBUTING.MD


Progressively enhanced tabs

It looks and works ok to me but @scottaubrey may want to have a few words about the nesting :-)

@E-Kemp - are you happy to close this PR now?


Regenerate sdk code for resource-2019-10 and subscription-2019-11

Last sdk code was generated by autorest V3 (3.0.6187), which has some issues like creating long unexpected property name like Componentssgqdofschemasidentitypropertiesuserassignedidentitiesadditionalproperties.
So using autorest V2 (2.0.4413) to re-generate C# code for resource-2019-10 and subscription-2019-11.

@erich-wang, @isra-fel, Could anyone please take a look of this small pr? Many thanks


Fix Storage GZIP test

Update test to set GZIP encoding to BINARY. This looks to be causing a failure on the new Kokoro builds.
[fixes #2276]

I don't understand why the build is failing. I can't get it to fail locally.


Connection

I have installed on raspberry pi, it's ok when i am connecting to sqlite, but when i am trying to connect to sql server, it gives this error,
Login error: read tcp <local_ip>:<any_local_port> -> <server_ip>:1433: read: connection reset by peer
It happens the same when i connect from ubuntu 18.04
The command was
./usql mssql://dbUser:dbPassword@server_IP:1433/DbName
i use dbeaver to manage all my databases and i am able to connect from ubuntu 18.04 to windows7 sql sever

I test it with postgres and it's ok, the only problem is with mssql, i really like this tool

I am facing the same problem. SQL server version 2008, any news?

@calebeaires + @jimmyegd I don't have Windows 7 + SQL Server 2008 to test this with. I really would need more help from you to debug and figure out the issue. usql simply uses this package for its connection. If one of you could try testing that driver with a minimal Go application and reporting back the error, I'd be able to fix it. For what it's worth, I just tested this against SQL Server Express 2019 on Linux (using Microsoft's published Docker image) and it worked fine without any connection issues.
Additionally, its worth mentioning that I'm using this from the command-line on Linux. I'm guessing you're using usql from Windows. As such, it could be related to something else entirely that I'm not aware of.

I just fix the issue using this: encrypt=disable
usql --csv  mssql://user:password@my_ip:1433/database?encrypt=disable