Issue Importing Walletconnect.Nethereum and Unity

I added Walletconnect.Nethereum folder to my Unity project.
I also imported all of the DLLs from https://github.com/Nethereum/Unity3dSimpleSampleNet461
But I keep getting this error and I don't know how to fix it:
Assets\WalletConnectUnity\WalletConnectSharp.NEthereum\WalletConnectNEthereumExtensions.cs(56,21):
error CS0012: The type 'JsonSerializerSettings' is defined in an assembly that is not referenced.
You must add a reference to assembly 'Newtonsoft.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'.

Any help in resolving this is kindly appreciated

Hi was this resolved?

closed due to v1 depreciation


agent: add flag to enable internal traffic policy

/test

/test

/test

/test

rebased on main to resolve conflicts


graces behind notes

Sorry to bring grace notes up again, but I think the values acc , unacc, and unknown are semantically not sufficiant as you cannot mark them as a "Nachschlag", i.e.

A grace note which takes its value from that of the note preceding it.

So these are Nachschlag?:

They could be considered a sub-category of unaccented grace notes...
For example, if they are not at the end of a measure, they behave exactly like unaccenteded grace notes:

An advantage to labeling them as Nachschlag would be that re-barring the music would place the grace notes on the correct side of a barline (before it for Nachschlag, and after for other grace notes).  But that probably will not happen very often in MEI.  In SCORE this is a problem, and Nachschlag must have a local barline on the staff to prevent them from crossing over a system barline.
Here are the two possibilities for converting the above example to 2/4:

The first one assumes the grace notes are attached to the next note, and the second example assumes that they are attached to the previous note.
Labeling Nachschlag might also be of use for grace-note kerning.  Nachschlag should always be kerned, but unaccented grace notes can sometimes be un-kerned.

@rettinghaus, by definition in MEI the time for unaccented grace notes is always stolen from the preceding note.  In essence, they're all Nachschlagen.  :-)

@craigsapp, I remember you talking about kerning somewhere, but could you run through what you mean by that term again please, esp. with respect to grace notes?

Here it is:
https://github.com/rism-ch/verovio/issues/255

@pe-ro well, yes and no. Seen from timing they are sort of identical. But semantically unaccented grace notes belog to the following note, whereas a Nachschlag belongs to the preceding note.
The visual difference is shown above by @craigsapp. Performance is indeed (mostly) identical.
LilyPond follows the semantic path (for kerning) and assigns notes defined as \grace to the following note. To get the correct Nachschlag-rendering you have to use \afterGrace.
(\acciaccatura and \appoggiatura is also available in LilyPond.)
NB: in #368 we came to the conclusion that unaccented grace notes usually are those with a slash.

I get the "belongs to" relationship, but should each note in the 2-note figure be associated with the principal note?  Or do both notes form a single Nachschlag that has that relationship?

Both notes form a single Nachschlag.
What would be the difference in encoding?

The Nachschlag would usually be a group of grace notes.  But probably not worth the effort to have an independent grouping element since it would most always be a beamed pair of grace notes, or to explicitly have a grouping mechanism to link it to the preceding real note, since the sequencing of data in the layer should be sufficient.
It would not be possible to have a Nachschlag after an accented or unaccented grace note, so they would all have to be adjacent to each other in any case, immediately following a real note, and they must occur before any "acc" or "unacc" grace notes which would be attached to the next real note.
It could be treated as another label for @grace which could be applied to either a note, chord, or beam.  The label should contain unacc and then either have a dash or a space after which the Nachschlag qualifier would be given, such as unacc-after, unacc-ns, unacc-post, etc.

Values for @grace of "unacc" and "unacc-after" will work, but since they will apply only to the note itself, there should be a Schematron rule that says if one grace under a beam is marked as "unacc-after", then all the notes under that beam must carry the same value.
The only way around this (admittedly) somewhat clunky solution is to create a grace note grouping mechanism more specific than <beam>.  <grupetto> perhaps?

All grace notes within a beam must be the same type; otherwise, they would/should not be beamed together.  So it may be best to put the @grace on the beam, and ignore or mark as an error any @grace on individual notes within the beam.
Here is an example of a Nachschlage group followed by and unaccented grace note:

The following two measures show how it might be split across a measure boundary.
One advantage of marking as a Nachschlage is that the second Nachshalge in m2 looks correct, while the one in the first measure does not since there is no space after the trill note. I.e., the Nachschlage marking on the grace notes could ensure at least a small gap to the previous note to indicate the duration of the real note.

Would these grace notes be categorized as Nachschlage?

(Chopin mazurka in C# minor, op. 30, no. 4)
And how should they be encoded, particularly in attaching the grace note beam to a regular note?

So it may be best to put the @grace on the beam, and ignore or mark as an error any @grace on individual notes within the beam.

That's sort of what I'm suggesting with <grupetto>, which indicates that all its children are grace notes.
If @grace were added to <beam>, should it take the current values: "acc", "unacc", and "unknown"?
Chopin?  Chopin, really?  Damn, I'm learning to like Chopin less and less.  🤕
According to your earlier statement --

All grace notes within a beam must be the same type; otherwise, they would/should not be beamed together.

Mr. Chopin shouldn't beam the big notes and the little notes together.  But, nevertheless, he has.  I think he was just trying to mess us up.
Seriously, putting aside completely the fact that there are too many notes in the right hand, the best encoding strategy I can come up with off the top of my head is to assume there are 2 layers here (supported by the fact that the big notes have a down stem) and mark the small notes as simply being small, not grace notes.  Something like the following, although I've not been entirely accurate about which notes are in which layer --
<measure xmlns="http://www.music-encoding.org/ns/mei">
  <staff>
    <layer>
      <beam>
        <note dur="8" stem.dir="up"/>
        <chord dur="8" stem.dir="up" fontsize="small"/>
        <note dur="8" stem.dir="up" fontsize="small"/>
        <chord dur="8" stem.dir="up" fontsize="small"/>
      </beam>
      <note dur="8" stem.dir="down" fontsize="normal"/>
      <rest dur="8"/>
      <rest dur="8"/>
      <chord dur="8" stem.dir="down">
        <note/>
        <note/>
      </chord>
    </layer>
    <layer>
      <note dur="4"/>
    </layer>
  </staff>
  <staff>
    <layer>
      <note dur="4"/>
      <chord dur="8">
        <note/>
        <note/>
        <note/>
      </chord>
      <rest dur="8"/>
      <rest dur="4"/>
    </layer>
  </staff>
</measure>

Incidentally, at least one of the first notes in the right hand should be marked using @sameas to make sure the note head only gets rendered once.

Chopin? Chopin, really? Damn, I'm learning to like Chopin less and less.

Just wait until I eventually get to nocturnes:

Here is a single-note Nachschlage:

A Nachschlag normally ends an ornament. So definitely no Nachschlag for
Chopin! I wouldn't call them grace notes at all, but more like  "flitting
notes". Or just simply "small notes".
As a Nachschlag is basically part of an ornament, one could encode those as
children of trill or mordent, but that would be somewhat ugly.
Am 22.02.2017 11:19 nachm. schrieb "pe-ro"<EMAIL_ADDRESS>
Incidentally, at least one of the first notes in the right hand should be
marked using @sameas to make sure the note head only gets rendered once.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/music-encoding/music-encoding/issues/407#issuecomment-281823396,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHVkh3wfXaF5vRcDI702wenpZDZO6iJSks5rfLRhgaJpZM4MIaVC
.

Incidentally, at least one of the first notes in the right hand should be marked using @sameas to make sure the note head only gets rendered once.

That will be useful to keep in mind.  When verovio does layer collision avoidance, I can submit a bug report to have it respect @sameas markers (currently all shared notes in layers are done in @sameas style).

Seriously, putting aside completely the fact that there are too many notes in the right hand, the best encoding strategy I can come up with off the top of my head is to assume there are 2 layers here (supported by the fact that the big notes have a down stem) and mark the small notes as simply being small, not grace notes. Something like the following, although I've not been entirely accurate about which notes are in which layer --

Encoding as "small notes" in a second layer should be acceptable, with the assumption that they all have the same (tuplet) duration without showing a tuplet number, and having only a single beam line.
A tricky aspect is that the shared note between the layers has an accidental.  In this sort of case (small notes sharing a notehead with a regular note), any accidental before the note should be displayed in regular size.

@rettinghaus, over in #406 I called these "quasi-improvisational" notes.
In @craigsapp's last 2 examples (m. 1 of "Here is a single-note Nachschlage" and m. 2 of "Arpeggiation grace notes -maybe to indicate a slow arpeggio"), there is a trill preceding the grace notes. I know the term normally applies to earlier music, but I'd say that Chopin was "extending" the meaning of "Nachschlag".   We probably don't want to encourage encoders to label them that way, but I don't think we can keep anyone from doing it.

A tricky aspect is that the shared note between the layers has an accidental. In this sort of case (small notes sharing a notehead with a regular note), any accidental before the note should be displayed in regular size.

Big notes are always throwing their weight around. 😀

That will be useful to keep in mind. When verovio does layer collision avoidance, I can submit a bug report to have it respect @sameas markers (currently all shared notes in layers are done in @sameas style).

The opposite approach, however, is just as good.  That is, treat all notes shared by the layers as the same note head and require an offset of some kind to move one note (very rarely both notes) when necessary.  I'd say Verovio should accommodate both approaches.

Here is an example of typesetting the first Chopin sample from above in SCORE:

chopin-mazurka-30-4.txt
I was able to encode the small notes as grace notes, so not too unusual for SCORE :-).  The only complication is that SCORE wants to left-justify the overlapped regular/grace notes, so I had to give the grace notes a horizontal offset to simulate right-justification on the shared notehead.

I was able to encode the small notes as grace notes, so not too unusual for SCORE :-). The only complication is that SCORE wants to left-justify the overlapped regular/grace notes, so I had to give the grace notes a horizontal offset to simulate right-justification on the shared notehead.

Yes, this is the hack we could try to avoid. I agree with Perry that we could encode them as a second layer with small notes. However, the additional issue here is that the duration should be adjusted, either with @dur or with an tuplet, which is certainly possible and fairly easy.
Alternatively, we could try to think of a way to say that the first grace note has to be on the time stamp of the previous note. Something like:
<staff>
    <layer>
        <note dur="4" stem.dir="down"/>
        <beam>
            <note dur="8" stem.dir="up" grace="acc" tstamp="1.0"/>
            <chord dur="8" stem.dir="up" grace="acc"/>
            <chord dur="8" stem.dir="up" grace="acc"/>
            <chord dur="8" stem.dir="up" grace="acc"/>
        </beam>
        <note dur="8" stem.dir="down"/>
        <rest dur="8"/>
        <rest dur="8"/>
        <chord dur="8" stem.dir="down">
            <note/>
            <note/>
        </chord>
    </layer>
</staff>

If I understand correctly, the use of @sameas would give something like:
<staff>
    <layer>
        <note dur="4" stem.dir="down" xml:id="n1"/>
        <beam>
            <note sameas="#n1" stem.dir="up" grace="acc"/>
            <chord dur="8" stem.dir="up" grace="acc"/>
            <chord dur="8" stem.dir="up" grace="acc"/>
            <chord dur="8" stem.dir="up" grace="acc"/>
        </beam>
        <note dur="8" stem.dir="down"/>
        <rest dur="8"/>
        <rest dur="8"/>
        <chord dur="8" stem.dir="down">
            <note/>
            <note/>
        </chord>
    </layer>
</staff>

Alternatively, we could try to think of a way to say that the first grace note has to be on the time stamp of the previous note. Something like...

That is an interesting possibility, and is close to how I did it in SCORE.  SCORE uses horizontal position in a manner similar to @tstamp in MEI.  If two notes on a staff have the same horizontal position, they also have the same tstamp in score (with a separate parameter allowing for an additional horizontal offset if they are not visually supposed to be at the same horizontal position, such as chords containing seconds).

Here is the 2nd layer method of encoding the Chopin example in SCORE:

chop2.txt
It is OK, but I notice a minor problem: the grace notes are spaced as sixteenth notes in the first group, and as 32nds in the second group, so the spacing in the two groups are different.  There would be greater problems if there were other notes in bottom staff occurring in the same beat (they would be falsely aligned with grace notes, possibly making the spacing inside the grace note group uneven).
Compare to the gracenote encoding (notice that the first grace note group is more compact):

Alternatively, we could try to think of a way to say that the first grace note has to be on the time stamp of the previous note.

That looks suspiciously like <backup/> to me.  😀  But I'm not opposed to the approach as long as @sameas is treated consistently; that is, saying something is "the same as" something else gives it the same time stamp, and as long as encoding as multiple layers also still works.

Why did you put @tstamp on note then ;-) ?

SCORE input is done in a similar manner to <layer>, with only one layer being added at a time (and no backup).  In SCORE I cannot add all notes in one pass for this example (as grace notes or as small notes).  For the grace-note encoding method, I added all notes to a single layer except for the shared A4 grace notes, and then I added the A4s graphically (equal to assigning a tstamp or sameas to them).
Backup would be good to avoid, but this is a quasi backup, so not quite a backup.  More of a freezing of the timeline, functioning similar to a chord/chordSpan.  I think @sameas is a good method: using @tstamp implies that you can use any timestamp value (making it a true backup/forward). @sameas has a similar problem, but feels more restricted

More as a confirmation of its time location, i.e., so it wouldn't have to be calculated any time you wanted to know when the note occurs.  It only occurred to me later that an event could be "time shifted" by altering the value of @tstamp, so it still feels a little kludgey.  Encoding the events in a measure backwards, recording the last note first, then penultimate note, and so on, and then using @tstamp to put them in chronological order is permissible, but it just feels a little weird.
In any case, because @tstamp is available I don't think we can disallow such behavior.  We just need to make sure it's used responsibly.

No comments on my <grupetto> suggestion?  I think this would be an easy way to distinguish beamed grace notes from others.  Then any special needs for grupetto, such as kerning, discussed in https://github.com/rism-ch/verovio/issues/255, and marking the group as a Nachschlag, could be met by adding appropriate attributes.  I think it's time to split <beam> into <beam> for regular notes and <grupetto> for grace notes.

I don't have a problem with that.  So a current beam containing grace notes would become a grupetto?  An advantage as you mention is being able to mark the function of grace notes at the grupetto level rather than the note/chord level.
Gruppetto might be the preferred spelling: https://en.wiktionary.org/wiki/gruppetto
A potential problem is that you are somewhat redefining gruppetto from the musical sense.  A Gruppetto is a group of notes which form an ornament, rather than a sequence of grace notes that are beamed together.  These two functions mostly coincide, but not exactly.

So a current beam containing grace notes would become a grupetto?

Exactly.

you are somewhat redefining gruppetto from the musical sense.

I'm not married to the name.  Got other suggestions?

gbeam might be good if it has the exact meaning of a beamed set of grace notes. beam would still be used for "small notes" and "cue notes", of course, which posses non-zero score durations.

Or beamgr?

No problem with beamgr, but gbeam is easier to say.

BEAM-grr, kinda like Beemer with a guh. :-)

😈

Why beamgr? For me it totally looks like graceGrp!

Good call.  In that case, there doesn't necessarily have to be a rendered beam.

Good call. In that case, there doesn't necessarily have to be a rendered beam.

Yes, the main thing is if the grouping is tied to a beaming of the contained notes or not.   In most cases they would be beamed, so allowing them to not be beamed would add mostly unnecessary verbosity: (<graceGrp><beam>...</beam></graceGrp>).  In other words graceGrp interacts interacts with beam in the same way that tuplet does.
Here are two examples to think about (wether they are to be grouped without beaming).   The first is an unbeamed gruppetto, and the second are a sequence of grace notes which all do not share a single beam (but these are probably two separate groups anyway):

If the grace note grouping element is supposed to mean that all notes in the group are to be beamed together, then something with "beam" in the element name would be best; otherwise using "group" in the name would be better.

Here's a possible approach to <graceGrp> --
<classSpec ident="att.graceGrp.anl" module="MEI.cmn" type="atts" mode="add">
  <desc>Analytical domain attributes.</desc>
  <classes>
    <memberOf key="att.common.anl"/>
  </classes>
</classSpec>
<classSpec ident="att.graceGrp.ges" module="MEI.cmn" type="atts" mode="add">
  <desc>Gestural domain attributes.</desc>
  <classes>
    <memberOf key="att.graced"/>
  </classes>
</classSpec>
<classSpec ident="att.graceGrp.log" module="MEI.cmn" type="atts" mode="add">
  <desc>Logical domain attributes.</desc>
  <classes>
    <memberOf key="att.event"/>
    <memberOf key="att.beamedWith"/>
  </classes>
  <attList>
    <attDef ident="attach" usage="opt">
      <desc>Records whether the grace note group is attached to the preceding or following
        event. The usual name for the former is "Nachschlag".</desc>
      <valList type="closed">
        <valItem ident="pre">
          <desc>Attached to the preceding event.</desc>
        </valItem>
        <valItem ident="post">
          <desc>Attached to the following event.</desc>
        </valItem>
      </valList>
    </attDef>
  </attList>
</classSpec>
<classSpec ident="att.graceGrp.vis" module="MEI.cmn" type="atts" mode="add">
  <desc>Visual domain attributes.</desc>
  <classes>
    <memberOf key="att.color"/>
    <memberOf key="att.beamRend"/>
  </classes>
  <attList>
    <attDef ident="beam" usage="opt">
      <desc>Indicates if the group is beamed.</desc>
      <datatype>
        <rng:ref name="data.BOOLEAN"/>
      </datatype>
    </attDef>
    <attDef ident="beam.slash" usage="opt">
      <desc>Indicates if the beam carries a diagonal slash.</desc>
      <datatype>
        <rng:ref name="data.BOOLEAN"/>
      </datatype>
    </attDef>
  </attList>
</classSpec>
<elementSpec ident="graceGrp" module="MEI.cmn" mode="add">
  <desc>A container for a sequence of grace notes.</desc>
  <classes>
    <memberOf key="att.common"/>
    <memberOf key="att.facsimile"/>
    <memberOf key="att.graceGrp.log"/>
    <memberOf key="att.graceGrp.vis"/>
    <memberOf key="att.graceGrp.ges"/>
    <memberOf key="att.graceGrp.anl"/>
    <memberOf key="model.eventLike.cmn"/>
  </classes>
  <content>
    <rng:zeroOrMore>
      <rng:choice>
        <rng:ref name="model.eventLike"/>
        <rng:ref name="model.appLike"/>
        <rng:ref name="model.editLike"/>
        <rng:ref name="model.transcriptionLike"/>
      </rng:choice>
    </rng:zeroOrMore>
  </content>
  <constraintSpec ident="When_not_copyof_graceGrp_content" scheme="isoschematron">
    <constraint>
      <sch:rule context="mei:graceGrp[not(@copyof)]">
        <sch:assert
          test="count(descendant::*[local-name()='note' or local-name()='rest' or
          local-name()='chord' or local-name()='space']) > 1"
          >A graceGrp without a copyof attribute must have at least 2 note, rest, chord, or
          space descendants.</sch:assert>
      </sch:rule>
    </constraint>
  </constraintSpec>
  <constraintSpec ident="When_graced" scheme="isoschematron">
    <constraint>
      <sch:rule context="mei:graceGrp[@grace]">
        <sch:assert test="not(descendant::mei:*[@grace])">The grace attribute is not allowed
          on descendants of a graceGrp with a grace attribute.</sch:assert>
      </sch:rule>
    </constraint>
  </constraintSpec>
</elementSpec>

This will validate
<graceGrp beam="true" grace="unacc" attach="pre" label="Nachschlag">
  <note/>
  <note/>
</graceGrp>

The <note> descendants of <graceGrp> are prevented from having @grace themselves by the Schematron provided.  Like <beam>, <graceGrp> must also have at least 2 event children.
This change doesn't prevent the following, currently-allowed markup --
<beam label="beamedGraceNotes">
  <note grace="unacc"/>
  <note grace="unacc"/>
</beam>

Schematron could be added, however, to disallow a beam with only grace note children.  Of course, that will break compatibility.  I don't see that as a huge problem, though, since the upgrade XSLT can turn all of these into <graceGrp> elements.
Since <graceGrp> is a member of model.eventLike.cmn, it can occur anywhere other notes, chords, rests, beams, etc. can occur.  In other words, anywhere where <beam> can currently happen.
Thoughts?

That looks good.  Are beams allowed inside of graceGrp?:
<graceGrp grace="unacc" attach="pre" label="Nachschlag">
  <note/>
  <beam>
      <note/>
      <note/>
  </beam>
</graceGrp>

In other words is graceGrp for an arbitrary sequence of grace notes with the same function or more of a replacement for a beamed sequence of grace notes?

Are beams allowed inside of graceGrp?

Yes, that's possible, but
<graceGrp grace="unacc" attach="pre" label="Nachschlag" beam="false">
  <note/>
  <graceGrp beam="true">
    <note/>
    <note/>
  </graceGrp>
</graceGrp>

is an alternative as long as @beam is available.
One might also see other configurations, such as --
<graceGrp grace="unacc" attach="pre" label="Nachschlag" beam="true">
  <note/>
  <note/>
</graceGrp>
<note grace="unacc" label="non-Nachschlag"/>

depending on the "Nachschlag-iness" of the preceding/following note(s).
Also, at present a <graceGrp> containing nothing but a <beam> is allowed --
<graceGrp grace="unacc" attach="pre" label="Nachschlag">
  <beam>
    <note/>
    <beam>
      <note/>
      <note/>
    </beam>
  </beam>
</graceGrp>

The question of whether to treat the beam as a first-class object (i.e., using <beam> instead of @beam) raises many difficult questions, just as it does with <tuplet>.  In fact, it makes me doubt whether <graceGrp> is a good idea after all. 🙁

graceGrp@beam versus graceGrp/beam would behave similar to note@accid and note/accid.  When no special attributes are needed for the beaming of the grace notes, then graceGrp@accid can be used.  For unusual cases with beam attributes, graceGrp/beam can be used.

I like it.
What if you really can't tell if it's "attached" to the previous or following note? Just don't set the attribute? Or would it be wiser to have @attach="unknown" (analogous to @grace)?

The question of whether to treat the beam as a first-class object (i.e., using <beam> instead of @beam) raises many difficult questions, just as it does with <tuplet>. In fact, it makes me doubt whether <graceGrp> is a good idea after all.

I think graceGrp is a good idea, but I would not add a @beam to is. That is I would expect this:
<graceGrp grace="unacc" attach="pre" label="Nachschlag">
    <beam>
        <note/>
        <chord>
            <note/>
            <note/>
        </chord>
    </beam>
</graceGrp>

I know that we should not model the encoding for facilitating processing, but when the encoding becomes cumbersome maybe this means that there is something not so great with the encoding... For example, if I have this:
  <beam>
    <tuplet>
        <note grace="unacc">
            <accid/>
            <artic/>
        </note>
        <chord grace="unacc">
            <artic/>
            <note>
                <accid/>
            </note>
            <note/>
        </chord
    </tuplet>
  </beam>

There is an awful lot to query around to know for example is the <artic> or the <accid> is part of a grace group. Plus this is quite error prone because we can easily have a missing @grace

OK, no grace/@beam. Beaming will have to be done with graceGrp/beam.  However, I've added beam/@slash for those cases (usually associated with grace notes, but not always) where there's a diagonal slash through the beam (not the note stems).  For example,
<graceGrp grace="unacc" attach="post" grace.time="10%">
  <beam slash="true">
    <note dur="16"/>
    <note dur="16"/>
    <note dur="16"/>
  </beam>
</graceGrp>
<note dur="2" dots="1"/>

Also, as @rettinghaus has requested, @attach can have the value unknown.
Next questions:

Should <graceGrp> be allowed to nest?
Since they might contain redundant or contradictory info, should @grace, @grace.time, and perhaps even @stem.mod be disallowed (via Schematron) on note descendants of <graceGrp>?

I have a bit of uneasiness about adding <graceGrp>.  I just don't feel it's quite "ripe" enough yet.  Any objections to tabling it for now?

I don't have a problem with that.

I like it and I think it fills an important gap. But we can wait if you think we need to.

@lpugin: Actually, you've provided the vote of confidence I was looking for, so I'll put it in. 😀
But, should it be removed for MEI Basic?


You wrote code that looks like this:
cy.step("Access admin page")
A child command must be chained after a parent because it operates on a previous subject.
For example - if we were issuing the child command click...
cy
.get('button') // parent command must come first
.click()       // then child command comes second
Test steps were:
--- Start ---
##########################################################
New Test
Version cypress: 12.7.0

Also happening to me. Although it worked fine before adding cypress-allure to my dev dependencies

I faced same issue!
and according to repo's example till now not specify which one is need chainable as a parent and child command.
Need brief example as I believe that adding examples that showcase the plugin's capabilities with a variety of URLs and devices would greatly improve its usability and help users better understand how to incorporate it into their testing workflows.

I wasn’t able to replicate this issue. a reproducible repository would help a lot here. the thing I find odd in tall the information you provided is that it points to expect rather than to cy.section() it’s also odd that from the screenshot, both cy.step() and cy.section() were clearly executed (you can see them in timeline).
I think this might be some conflict between the plugin and some other plugin (?) but really hard to say.
investigating. any help appreciated

I tried replicating with allure report plugin, no luck there either

I tried replicating with allure report plugin, no luck there either

Sorry for the late response, but this happened again on another repo last week. Unfortunately I can't share the repo because it's a private one. But everything was working fine until installing allure plugin... Can you try to install the allure plugin and change a couple of default allure envs on the cypress config file? Like allure path and some of other boolean options to true


Link to "Allowing Partially Trusted Callers" article is incorrect

The link to the article "Allowing Partially Trusted Callers" takes you to a Chinese language page about analysis services instead of "Allowing Partially Trusted Callers"
The page is https://docs.microsoft.com/zh-tw/sql/database-engine/query-options-pages-f1-help?view=sql-server-2014
with the heading "查詢選項頁面 F1 說明" or  "Query option page F1 Description"

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

ID: 40d77088-b157-852e-8394-fc2419916a09
Version Independent ID: 0b1dd4dd-242b-1a62-cf6b-dda7c8b8fa68
Content: CLR Integration Security - SQL Server
Content Source: docs/relational-databases/clr-integration/security/clr-integration-security.md
Product: sql
Technology: clr
GitHub Login: @rothja
Microsoft Alias: jroth

I think this is the correct link https://docs.microsoft.com/en-us/sql/database-engine/dev-guide/allowing-partially-trusted-callers?view=sql-server-2014

@turimbar1 thanks for bringing this to our attention! I believe you are correct on the link. I have updated the document. You should see it tomorrow. Please let me know if you need anything further, or if I can proceed with closing out this Git Issue. Thanks!

#9796

@turimbar1
Please let me know if you need anything further. I will proceed with closing out this Git Issue. Thanks!


Fix typo

Fix spelling of "package" on getting started page

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/index.md
:white_check_mark:Succeeded

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

Thanks! I'd just noticed that one too. :)


Feature: toggle sidebars/FS when activated

Stille has been a great addition to my academic writing. Thanks!
As a new feature, please add "fullscreen" and "sidebars collapse"
With this feature, Stille goes into a true-focus mode, highlighting the current line of text and clearing obsidian's view as much as possible.
Toggling Still mode off should return window sizing, left sidebar, and right sidebar to their original state.
These two options would save three steps at the start and at the end of a heavy editing session:  (hide left sidebar, hide right sidebar, full-screen)

Hey @ke0pci thanks for the suggestion! I like this idea, but I'm not sure if I'd bake this into Stille itself. I might write a separate plugin to handle just this. I like to create very minimal, single scoped plugins.
I'll let you know if I find some cycles to create such a plugin.
Thanks for using Stille and I'm glad it's helping you with your writing :)

@ke0pci search for "Soomda" in the plugin directory. I released a plugin that does this https://github.com/michaellee/soomda


Set up kg-ontoml to call NEAT to train classifiers and get metrics (AUC, precision, recall)

Per our conversation today with @guojing @caufieldjh in the OntoML meeting, we'd like to set up kg-ontoml to call NEAT and train classifiers (logistic regression, random forest, and MLP).
For each graph we want to do the learning task on, we will write a NEAT.yaml and also upload an embedding file, and the existing kg-hug-scheduler will train three classifiers (logistic regression, random forest and MLP with some layers that will not change across experiments, and emit some metrics like validatoin AUC, precision, recall, etc. The NEAT.yaml should basically not have a graph block, should have an embedding block with a pointer to a file that already exists, and a classifier block that is basically like this:
classifier:
  edge_method: Average # one of EdgeTransformer.methods: Hadamard, Sum, Average, L1, AbsoluteL1, L2, or alternatively a lambda
  classifiers:  # a list of classifiers to be trained
    - type: neural network
      model:
        outfile: "model_mlp_test_yaml.h5"
        classifier_history_file_name: "mlp_classifier_history.json"
        type: tensorflow.keras.models.Sequential
        layers:
          - type: tensorflow.keras.layers.Input
            parameters:
              shape: 868   # must match embedding_size up above
          - type: tensorflow.keras.layers.Dense
            parameters:
              units: 128
              activation: relu
          - type: tensorflow.keras.layers.Dense
            parameters:
              units: 32
              activation: relu
              # TODO: fix this:
              # activity_regularizer: tensorflow.keras.regularizers.l1_l2(l1=1e-5, l2=1e-4)
          - type: tensorflow.keras.layers.Dropout
            parameters:
              rate: 0.5
          - type: tensorflow.keras.layers.Dense
            parameters:
              units: 16
              activation: relu
          - type: tensorflow.keras.layers.Dense
            parameters:
              units: 1
              activation: sigmoid
      model_compile:
        loss: binary_crossentropy
        optimizer: nadam
        metrics:  # these can be tensorflow objects or a string that tensorflow understands, e.g. 'accuracy'
          - type: tensorflow.keras.metrics.AUC
            parameters:
              curve: PR
              name: auprc
          - type: tensorflow.keras.metrics.AUC
            parameters:
              curve: ROC
              name: auroc
          - type: tensorflow.keras.metrics.Recall
            parameters:
              name: Recall
          - type: tensorflow.keras.metrics.Precision
            parameters:
              name: Precision
          - type: accuracy
      model_fit:
        parameters:
          batch_size: 4096
          epochs: 5  # typically much higher
          callbacks:
            - type: tensorflow.keras.callbacks.EarlyStopping
              parameters:
                monitor: val_loss
                patience: 5
                min_delta: 0.001  # min improvement to be considered progress
            - type: tensorflow.keras.callbacks.ReduceLROnPlateau
    - type: Decision Tree
      model:
        outfile: "model_decision_tree_test_yaml.h5"
        type: sklearn.tree.DecisionTreeClassifier
        parameters:
          max_depth: 30
          random_state: 42
    - type: Random Forest
      model:
        outfile: "model_random_forest_test_yaml.h5"
        type: sklearn.ensemble.RandomForestClassifier
        parameters:
          n_estimators: 500
          max_depth: 30
          n_jobs: 8  # cpu count
          random_state: 42
    - type: Logistic Regression
      model:
        outfile: "model_lr_test_yaml.h5"
        type: sklearn.linear_model.LogisticRegression
        parameters:
          random_state: 42
          max_iter: 1000

Guojing also has a GNN set up that will likely do well on this learning task. For this, he will also produce embeddings, which we can run through the above NEAT pipeline to assess how it does with the HP-MP task. (Guojing will also investigate using the GNN directly on this HP-MP task, without making embeddings, but this won't be a part of the feature described in this ticket.)

See also #5

For purposes of uploading an embedding, this may mean enabling embedding_file_name to be a URL much like with the graph, so NEAT can move it from S3 -> gcloud

Will probably need to take care of this too:
https://github.com/Knowledge-Graph-Hub/NEAT/issues/43

Blocked until https://github.com/Knowledge-Graph-Hub/NEAT/issues/64 is resolved - can provide graph and dummy pos/neg graphs but this appears to lead to other errors.


Export base controller type struct. - [closed]

In GitLab by @wknet123 on May 25, 2018, 07:00
Merges updatek8s18 -> updatek8s18

In GitLab by @wknet123 on Nov 13, 2019, 11:02
closed


Fixed text color issue with Android

Small PR to fix an issue on Android with text color. You can see the difference before and after the patch.
I added a white background to fix it.
I hope it helps.

Sample pdf: https://css4.pub/2017/newsletter/drylab.pdf

How can we ensure that the pages are always white?

Maybe I'm wrong but I think it occurs when page background is transparent. So we set it at white. But if page already has a background, it overrides our default white background no ?
I tested with a PowerPoint presentation transformed as PDF with white background for first page and black background for last page and it works.
In fact, I don't know why sometime text is faded. For my test, I did not see any color issue for text when I enabled or disabled this patch.
But it occurs on some pdf and I don't know why.

Please try to add bitmap.eraseColor(Color.WHITE); immediately after creating the bitmap, and remove the Canvas.

Thanks it works like my previous patch.
Do you want I update my PR to include this code ?

@douglasjunior I updated my code with your request.


Start menu apps and weather notification not removed

Prerequisites

[ ] Verify that this is not a Windows issue;
[ ] Refer to the Before running.
[ ] Refer to the How to use.
[ ] If you issue concerns the Wrapper, please mention @BenchTweakGaming in issue

Steps to reproduce
I just ran the script in a fresh install and noticed the Start Menu apps and weather notification on the taskbar are not being removed.

I know about the bug with weather notification. But regarding Start icons, they are just icons, not installed apps. You may use the function to unpin them all.

This is strange but today I cannot catch the bug with the weather notification. The fucntion (that is very primitive) now always works...


Error ssh, Connection timed out

Hello, I was working on the 'Distribute the Client and Server Certificates' section of Chapter 04 when I encountered this error

Previously, I was able to SSH into the instances. Can you explain why this is happening and how to fix the error?

Ensure the instances worker-0 and worker-1 exist and are reachable from your current environment first.
Check that the SSH server on the remote host is running and accepting connections on port 22. You can run the command ssh -T <IP_ADDRESS> from your local machine or ssh -T <IP_ADDRESS>.

Ensure the instances worker-0 and worker-1 exist and are reachable from your current environment first.
Check that the SSH server on the remote host is running and accepting connections on port 22. You can run the command ssh -T <IP_ADDRESS> from your local machine or ssh -T <IP_ADDRESS>.

Thanks for your answer, i was able to ssh without changing anything.  I think this error is only transitory.


ERROR: Z-Wave integration not found

Environment

OS: HassOS
Type of system that HA is running on: HA Blue
Home Assistant version: 2021.10.4
Hassio: OS 6.5
Component version: 0.0.74
Z-Wave integration name: zwavejs2mqtt 0.27.0
Lock make and model:
Kwikset 888 & 910

Logs
Seeing this error persistently in my core logs
ERROR (MainThread) [custom_components.keymaster.binary_sensor] Z-Wave integration not found
I'm using quite a few Z-Wave devices that are working just fine, and I don't seem to be having any issues directly with Keymaster, but this error message persists.
edit - the issue template didn't populate the first time, my bad. I went through creating a new issue to get the template.

It does persist, looks like it's happening multiple times per minute (a sample from my logs):
2021-10-29 14:00:59 ERROR (MainThread) [custom_components.keymaster.binary_sensor] Z-Wave integration not found
2021-10-29 14:03:59 ERROR (MainThread) [custom_components.keymaster.binary_sensor] Z-Wave integration not found
2021-10-29 14:03:59 ERROR (MainThread) [custom_components.keymaster.binary_sensor] Z-Wave integration not found
2021-10-29 14:03:59 ERROR (MainThread) [custom_components.keymaster.binary_sensor] Z-Wave integration not found
2021-10-29 14:06:59 ERROR (MainThread) [custom_components.keymaster.binary_sensor] Z-Wave integration not found
2021-10-29 14:06:59 ERROR (MainThread) [custom_components.keymaster.binary_sensor] Z-Wave integration not found
2021-10-29 14:06:59 ERROR (MainThread) [custom_components.keymaster.binary_sensor] Z-Wave integration not found

What does your binary_sensor.<doorname>_network sensor say on or off?

It's reading unavailable, with these state attributes (from the dev tools):
restored: true
supported_features: 0
device_class: connectivity
friendly_name: 'frontdoor: Network'

The lock & entities are responsive to commands / from the dashboard...

Unavailable status means the network isn't detected.
Are you using the zwavejs integration or using mqtt with discovery?

Thanks for following up, I am using mqtt with discovery.

That method isn't supported.

Well that would explain it. I must have missed that when I migrated to zwave js. I'll close the ticket.


Reference error on basic implementation

I used the documentation to do a simple test to test the current path. I've generate the file using the cli and import the page into my acceptance test. Every time I run the test they say that visit is undefined.
// tests/pages/projects.js
import {
  create,
  visitable
} from 'ember-cli-page-object';
export default create({
  visit: visitable('/projects')
});
// tests/acceptance/projects-test.js
import { test } from 'qunit';
import page from 'log-book/tests/pages/projects';
test('Visit projects', function(assert) {
 page
   .visit();
  andThen(function() {
    assert.equal(currentURL(), '/projects');
   });
});
anyone know why i got this issue

@vigpatrick that's strange. What ember, ember-cli and ember-cli-page-object versions are you using?
I've created a quick example on ember-twiddle and seems to be working fine: https://ember-twiddle.com/458b0ed1f5e7554bd95e7e91cad895f6?openFiles=tests.acceptance.hello-test.js%2C&route=%2Fhello
Can you try to create a test like the example? and see if it fails. You can also upload the application that has the issue to github so we can take a look.

Finally i used your example and it work. I guess i forgot the moduleForAcceptance and my test was not lauched properly.
Thank you even though it was a beginner problem.

@vigpatrick no problem, glad you make it work!
Let us know if you have any question, we're here to help 😃


Error Compiling

Sorry if this is the completly wrong way of addressing this (if so, let me know!)
But I cant seem to make the compile, it throws a bunch of errors, starting with
    error: unknown type name ‘pcap_t’
    3 | static pcap_t *handle;
      |        ^~~~~~

I have installed pcap using the package manager (dnf on fedora 32)
error.log

Managed to fix it by simply rebuilding everything from scratch. sorry for this.


Hide "highlight" legend in all charts

Add a legend to the instructions instead.

Test Notes: Confirm that no legends show in any bar charts - especially after clicking a bar to initiate highlights (legend should still be present in dot plot). Confirm that a 'pseudo-legend' is present in the controls description when highlights are present ("Highlighted" should have an orange background")

Pass
Testing using commit: bfdab685c4b8e09e4d10738b0e58ce3b009e4a8c


Fix site size validation on shapefile upload

We were setting the SRID on the geometries we got back from GeoTools' shapefile
parser, but we weren't setting it in such a way that Geometry.getEnvelope()
would return a geometry with the same SRID.
This was causing the maximum envelope size validation check to bomb out with
actual shapefiles, though it worked with the programmatically-constructed
"shapefiles" in our unit tests since they don't go through the parser.

#1914  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @sgrimm and the rest of your teammates on  Graphite


Fixes #421 Organize Fate Operations

clean up tableOps directory to be organized by Fate operation.

@cjmctague At first glance, this looks great!  I am going to checkout your branch and take a closer look today.

OK looks good, I will merge.

Actually, @cjmctague do you mind resolving the conflict with CleanUp.java?  Looks like recent changes caused a conflict.

I also fired off a Jenkins build which will run all the tests to make sure everything is cool. https://jenkins.revelc.net/job/Accumulo-PR/84/

@milleruntime Rebased and squashed into one commit.

The PR jenkins build looks good.  I reran the Travis Hadoop 2 build but it is still dying halfway through.  I don't believe this is related to these changes so I will merge.


Error in compile: Assertion `0' failed.

Hi again!
First of all, I'm still learning pony, so probably the capabilities and other things of my code will be wrong... Sorry if that happens XD
I'm learning pony while writing some project to learn (json parser-decode in pure pony), and when I pulled today and try to compile.. It failed. After half hour trying to find where it was and simplify to a small snippet, here it is.
First, the code that fails, you need two files, one declaring some class, and other with the main calling it.

test.pony

class TestT
  let value: Array[F64]

  new create(value': Array[F64] = Array[F64]) =>
    value = value'

  fun apply(): this -> Array[F64] =>
    value

  fun ref add(x: TestT): TestT =>
    let newarray = TestT
    for v in values() do
      newarray.push(v)
    end
    for v2 in x.values() do
      newarray.push(v2)
    end
    newarray

  fun ref push(a: F64): TestT =>
    value.push(a)
    this

  fun values(): ArrayValues[F64, this->Array[F64]]^=>
    value.values()

  fun string(fmt: FormatDefault = FormatDefault, prefix: NumberPrefix = PrefixDefault, prec: U64 = 1, width: U64 = 0, align: Align = AlignRight, fill: U32 = ' '): String iso^ =>
    """ Just to print pretty """
    var res = "["
    for i in value.values() do
      res = res + i.string() + ","
    end
    if res.size() > 1 then
      res = res.cut(-1, -1)
    end
    res = res + "]"
    res.string()

main.pony

actor Main
  var _env: Env

  fun print(data: Bytes) => _env.out.print(data)

  new create(env: Env) =>
    _env = env
    let v1 = TestT([1])
    let v2 = TestT([2])
    let v3: TestT = v1 + v2
    print("V1: " + v1.string())
    print("V2: " + v2.string())
    print("Sum: " + v3.string())
    v1.push(3)
    v2.push(4)
    print("V1 after push: " + v1.string())
    print("V2 after push: " + v2.string())
    print("Sum after push: " + v3.string())

Trying to compile this, raises the following error:
$ ponyc
Building . -> /home/rock/Git/rock-site/static/RandomThings/Pony/testbug
Building builtin -> /home/rock/Git/ponyc/packages/builtin
Generating
ponyc: src/libponyc/reach/reach.c:555: reachable_method: Assertion `0' failed.
[1]    1832 abort (core dumped)  ~/Git/ponyc/build/debug/ponyc

The weird thing is that if you write the main inside the same file, it compiles and executes with the expected behaviour.

main.pony

class TestT
[...]  ( Like before)

actor Main
[...] (Like before)

The compile and output:

$ ponyc
Building . -> /home/rock/Git/rock-site/static/RandomThings/Pony/testbug
Building builtin -> /home/rock/Git/ponyc/packages/builtin
Generating
Optimising
Writing ./testbug.o
Linking ./testbug
$ ./testbug
V1: [1]
V2: [2]
Sum: [1,2]
V1 after push: [1,3]
V2 after push: [2,4]
Sum after push: [1,2]

When trying to figure out what was the reason, I founded that in the add function, if instead of copy the first values using the values function, I create the new TestT passing the array to the constructor, it don't fail at compile time, but the behaviour is not what expected (because it's not a copy of the values, it's a pointer to the same array, I guess):

test.pony

class TestT
[...]
  fun ref add(x: TestT): TestT =>
    let newarray = TestT(value)
    for v2 in x.values() do
      newarray.push(v2)
    end
    newarray
[...]

main.pony: (Like before)

Compile and execution:

$ ponyc
Building . -> /home/rock/Git/rock-site/static/RandomThings/Pony/testbug
Building builtin -> /home/rock/Git/ponyc/packages/builtin
Generating
Optimising
Writing ./testbug.o
Linking ./testbug
$ ./testbug
V1: [1,2]
V2: [2]
Sum: [1,2]
V1 after push: [1,2,3]
V2 after push: [2,4]
Sum after push: [1,2,3]

If this is an error because something wrong I'm doing, let me know, I'm still learning :smile:
Thanks!!

I'm unable to reproduce this with HEAD (it works whether in one file or two, and produces the right output either way).
Can you try again with the latest? It's possible that we "accidentally" fixed this recently!

I'm trying in my work computer, Ubuntu 15.04 with versions:
gcc: 4.9.2 (I don't know how to install 5.1 in ubuntu)
clang: 3.6.1
llvm: 3.6.1
GLIBCXX: 3.4.20 (I don't know too how to upgrade it to 3.4.21)
I have the same error, with different files fails at compile, in the same file works...

Can you paste the output of ponyc --version please?

$ ponyc --version
0.1.5-129-g3c05822

Ok, I've reproduced the problem, thanks! Working on a solution now.

Thanks! :smile:

Can you try again with HEAD? I've pushed a possible fix.

Yeah! Now works! ^^
Really thanks! :smile:

Phew, glad to hear it!


Interceptor not correctly applying to synthetic methods?

I'm seeing an odd case specifically with the 5.0.1 update under java 1.8, which is where I have an annotated method in an abstract method, and where a synthetic method is created by the Java compiler in the concrete class, the method interceptor does not appear to fire.
For now I'm working around it by introducing a layer of indirection, so that the annotation is always on a concrete method

Could you provide a test/example project that demonstrates the issue?

I've built an example reproduction here:
https://gist.github.com/petergeneric/c0b008510299c62fb46f9bd65629d82b
N.B. I've also reproduced it under newer Java versions, so I don't think it's 1.8-specific

Thanks - I suspect there's a missing condition when we're attempting to disambiguate the method hierarchy, specifically around detecting bridged return types when the method name and arguments are an exact match.
Note if you change MyInterface to have the same generic return signature as SomeAbstractClass the issue doesn't happen:
public interface MyInterface<DTO>
{
	DTO doSomething(int i);
	DTO doSomethingWorkaround(int i);
}

I'll add this example to MethodInterceptionTest and sort out a fix.

google#1530


Add more Application Support

Added application support for AcrobatPro, MS Word, MS Powerpoint, and MS
OneNote (Branched off latest version of master).

Looks good, thanks!


Exporting to bibtex with unicode as plain-text latex commands doesn't convert U+2040

Report ID: CRR4MW4Z-euc
Exporter used: BibTeX
Expected behavior: Tretʹi︠a︡kov is converted to Tret'\t{ia}kov
Actual behavior: Tret'i︠a︡kov is converted to Tret'i︠a︡kov

Can you right-click a reference that has this and send a new debug log? That will give me a test case.

Your postscript isn't javascript BTW.

No I mean in the BBT settings for postscript you've entered
<script>
@techreport{ISO3780,
type = {Standard},
key = {ISO 3780:2009},
month = oct,
year = {2009},
title = {{Road Vehicles -- Vehicle Identification Number ({VIN}) -- Content and Structure}},
volume = {2009},
address = {Geneva, CH},
institution = {International Organization for Standardization}
}
</script>

where BBT expects there to be javascript code.
The sample you submitted doesn't have \u2040, it has \u0069\ufe20\u0061\ufe21.

:robot: this is your friendly neighborhood build bot announcing test build <IP_ADDRESS>90 ("fixes #1265")
Install in Zotero by downloading test build <IP_ADDRESS>90, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".

Can you try 4590?

Thanks for the confirmation -- only I can close issues, I need the reminder to include them in a new release.


[FEA] Support / expose "labeled" filtered search

Filtered search for a more general type of label data is needed for many use cases. Typically, this takes the form of a vector of integers for every vector in the dataset and query. The general predicate function approach implemented in search_with_filter can be used for this, but is not currently exposed in the header for CAGRA. As a work-around, the source file with "search_with_filtering" can be included directly, but this greatly increases compile time and is not ideal.
If it is simpler or more performant, another option is a less general "labeled" search option where a specific format of label data can be provided to perform filtered search this way. Something like this could satisfy most use cases and may be preferable to a completely general predicate function.

As of version 24.10, the search_with_filter function has been replaced with an overload on the search function that you can see here. The source file doesn't need to be included directly.

Does this new overloaded search function also work with an arbitrary predicate-based filter? I was under the impression the new overloaded version only supported bitset and bitmap filters.

It support only bitset or bitmap, depending on the index. Predicate-based filtering is still being worked on.


Add preliminary Cobertura support

Partially addresses #5

Pull Request Test Coverage Report for Build 0

0 of 0 (NaN%) changed or added relevant lines in 0 files are covered.
11 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-11.8%) to 68.347%

Files with Coverage Reduction
New Missed Lines
%

/src/coverlet.core/Reporters/JsonReporter.cs
2
66.67%

/src/coverlet.core/Reporters/LcovReporter.cs
2
83.33%

/src/coverlet.core/Reporters/OpenCoverReporter.cs
7
92.77%

Totals

Change from base Build #54:
-11.8%

Covered Lines:
339

Relevant Lines:
496

💛  - Coveralls

oh wow i was just looking for this feature 😄

:shipit: !!!

Cobertura support completed in https://github.com/tonerdo/coverlet/commit/a93841099508043fdeaa5a4848fadb34c7a76497


BME280 doesn't work

Hi I get this error message when using a BME280 sensor.
Log:

host.raspberrypi
2019-03-29 19:49:16.326
error
instance system.adapter.i2c.0 terminated with code 0 (OK)

Caught
2019-03-29 19:49:16.326
error
by controller[0]: at Decoder. (/opt/iobroker/node_modules/component-bind/index.js:21:15) errno: 121, code: '', syscall: 'writeByteSync' }

Caught
2019-03-29 19:49:16.326
error
by controller[0]: at Manager.ondecoded (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/manager.js:345:8)

Caught
2019-03-29 19:49:16.326
error
by controller[0]: at Manager.Emitter.emit (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/component-emitter/index.js:133:20)

Caught
2019-03-29 19:49:16.326
error
by controller[0]: at Manager. (/opt/iobroker/node_modules/component-bind/index.js:21:15)

Caught
2019-03-29 19:49:16.326
error
by controller[0]: at Socket.onpacket (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/socket.js:244:12)

Caught
2019-03-29 19:49:16.325
error
by controller[0]: at Socket.onack (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/socket.js:319:9)

Caught
2019-03-29 19:49:16.325
error
by controller[0]: at Socket. (/opt/iobroker/node_modules/iobroker.i2c/devices/BME280.js:184:37)

Caught
2019-03-29 19:49:16.325
error
by controller[0]: at /opt/iobroker/node_modules/iobroker.i2c/devices/BME280.js:95:34

Caught
2019-03-29 19:49:16.325
error
by controller[0]: at BME280.checkChipId (/opt/iobroker/node_modules/iobroker.i2c/devices/BME280.js:192:25)

Caught
2019-03-29 19:49:16.325
error
by controller[0]: at Bus.writeByteSync (/opt/iobroker/node_modules/iobroker.i2c/node_modules/i2c-bus/i2c-bus.js:257:7)

Caught
2019-03-29 19:49:16.324
error
by controller[0]: { Error: , Remote I/O error

It looks like the BME280 was connected correctly when you added it in ioBroker, but later you disconnected it (or changed its address). Please verify you can still detect the BME280 properly:

Remove it in the adapter configuration
Try to search again, if you find it, it should work again

After I switched my jumper wires one by one I found out that one of them doesn't work properly. Now everything works as it should. Thank you.


[IDK] Cleaning the code from useless variables

Mr. Beast

TOP 3 most useless things on the planet.

First place:
amount: 1

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl: PuroSlavKing

fix: Fixed now the code is not polluted with useless "amount: 1"

this is a no cl no fun moment


feat: Propagate managed node group labels and taints to ASG as tags

Description
Propagate managed node group labels and taints to ASG as tags with configurable prefixes.
Motivation and Context
This is super relevant usage with cluster-autoscaler, when scaling from zero. Should address following issues #2448, #2128 and #1558.
Breaking Changes
I have disabled this feature by default, so we wont have any propagation of labels nor taints unless specified explicit.
How Has This Been Tested?

[x] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[x] I have tested and validated these changes using one or more of the provided examples/* projects
[x] I have executed pre-commit run -a on my pull request

I had a lot of issues actually getting example for eks-managed-node-groups to work, but finally managed.
I've tested this by changing examples/eks-manage-node-group. I've tested the following settings and changes:

Applied with default settings an saw no new added tags on ASG's
Added new node groups and saw labels and taints being propagated with the correct applied prefix
Disabled label and taint propagation on existing node group and saw tags being removed

Thanks to you guys for the effort and a great module and thanks to @abstrask for helping out.

I am getting
│ Error: error waiting for EKS Node Group (ex-eks-managed-node-group:complete-eks-mng-20230208163733128000000043) to create: unexpected state 'CREATE_FAILED', wanted target 'ACTIVE'. last error: 2 errors occurred: on the example with these changes

If examples actually worked out of the box, which it didn't, it would probably be easier to contribute. Instead of not looking at the actually contribution, could we discuss if the approach is viable and different from what you previously tried, since you haven't commented on it yet ✌ Where to go from here, any hints

I'm sorry but you lost me - are you saying the example on main today does not work or you are looking for hints on making your solution work, something else?

Both

Yeah examples/eks_managed_node_group/ is broken alright.
So reverting back my commits and running on commit id 4b7fe4637a048a52422ee04d6146136f48900695 I initially get this error related to subnets and IPv6:
Error: setting EC2 Subnet (subnet-0e66ca5dcc8d25e73) AssignIpv6AddressOnCreation: InvalidParameterValue: Invalid value 'true' for assign-ipv6-address-on-creation. Cannot set assign-ipv6-address-on-creation to true unless the subnet (subnet-0e66ca5dcc8d25e73) has an IPv6 CIDR block associated with it. │       status code: 400, request id: 35801c5c-747b-45bf-88e5-168c3546df1c │ │   with module.vpc.aws_subnet.intra[0], │   on .terraform/modules/vpc/main.tf line 569, in resource "aws_subnet" "intra": │  569: resource "aws_subnet" "intra" {
Fixing this by adding intra_subnet_ipv6_prefixes = [6, 7, 8] to vpc module fixes the issue.
Then running into this error:
Error: "block_device_mappings.0.ebs.0.kms_key_id" (2fcb3f5e-d474-4820-8dc1-ac6a5b283d39) is an invalid ARN: arn: invalid prefix │ │   with module.eks.module.eks_managed_node_group["complete"].aws_launch_template.this[0], │   on ../../modules/eks-managed-node-group/main.tf line 36, in resource "aws_launch_template" "this": │   36: resource "aws_launch_template" "this" {
Fixing it by changing kms_key_id = module.ebs_kms_key.key_id to kms_key_id = module.ebs_kms_key.key_arn
Then running into conflicting CIDR for subnets because a previous failed run:
Error: creating EC2 Subnet: InvalidSubnet.Conflict: The CIDR '<IP_ADDRESS>/24' conflicts with another subnet │       status code: 400, request id: 71d6e4cb-38d3-449e-b94a-3f4e7e180921 │ │   with module.vpc.aws_subnet.intra[1], │   on .terraform/modules/vpc/main.tf line 569, in resource "aws_subnet" "intra": │  569: resource "aws_subnet" "intra" {
Fixing it by deleting the conflicting subnets via management console.
And I haven't event gotten close to spawning a cluster yet, nor tested my change.

I think fixing that last error is completely out of scope and asking too much for a fix that just adds tags to asg's. I would suggest commenting out the complete = {...} node group section since it is broken in master i.e. 4b7fe4637a048a52422ee04d6146136f48900695 and then have someone else fix that for a later time.

Error: setting EC2 Subnet (subnet-0e66ca5dcc8d25e73) AssignIpv6AddressOnCreation: InvalidParameterValue: Invalid value 'true' for assign-ipv6-address-on-creation. Cannot set assign-ipv6-address-on-creation to true unless the subnet (subnet-0e66ca5dcc8d25e73) has an IPv6 CIDR block associated with it. │ status code: 400, request id: 35801c5c-747b-45bf-88e5-168c3546df1c │ │ with module.vpc.aws_subnet.intra[0], │ on .terraform/modules/vpc/main.tf line 569, in resource "aws_subnet" "intra": │ 569: resource "aws_subnet" "intra" {
Fixing this by adding intra_subnet_ipv6_prefixes = [6, 7, 8] to vpc module fixes the issue.

I suspect this problem was with the example was introduced with release 3.16.0 of the VPC module, which introduces a lot of changes regarding IPv6.
The version constraint on the VPC module referenced in the example allows for minor version upgrades. Is this intentional or should it be more specific and only allow patch upgrades?
As for the problem with kms_key_id, I think it stems from the fact that the input in the ebs block to aws_launch_template resource expects the ARN of the KMS key and not the ID, as the name suggests.
Changing the reference to the KMS key ARN, as @wcarlsen suggested, seems to fix it.
I haven't dived into the subnet conflict issue 🤷.

thanks for the call out - not sure why some of those examples stopped working but I have just updated to ensure they are functioning as intended

Just did another from scratch apply on the example pulling in your fixes and the asg tagging propagation still works as intended.

So @bryantbiggs any chance you had the time to look at the actual changes intended by this PR  (node group taint and label propagation to asg) or is stuck because of something else I'm missing?

Just wanted to add that my team and I are quite happy with having implemented automatic propagation of node group labels and taints as tags for the ASGs, when using cluster-autoscaler. This propagation can both be implemented outside the module as show in this issue #2448. But it can also be implemented from inside the module as well as shown with this PR, even though I think it is mostly an AWS responsibility, since we never really configure the ASGs. I hope I can convince someone to have a second look at this PR and give it an actual chance.

I fully respect the explicit choice not to include an ASG tagging feature into the module. Once that is out of the way it is not like this topic is not showing up multiple times in the this projects issues and the statement made here (https://github.com/terraform-aws-modules/terraform-aws-eks/issues/2448#issuecomment-1420977558) about this not being possible, from the module perspective, is simply not true.


API calls need to return page/limit/page_no metadata with each response

Originally reported by: lisa ballard (Bitbucket: basilleaf, GitHub: basilleaf)

when a large result is returned there should be a field that describes the total result count, current limit, and page. This is common in json APIs around the web and now I see why it is so helpful..
Here is background on how this came up:
Begin forwarded message:
On May 22, 2015, at 12:01 PM, Michael Aye wrote:
Hi Lisa,
how are you?
I am noticing an upper limit of 100 results for the API requests?
This one for example delivers 2261 results on the website, but the API keeps telling me 100:
'http://pds-rings-tools.seti.org/opus/api/files.json?instrumentid=Cassini+ISS&target=S+RINGS&projectedradialresolution1=0.5&projectedradialresolution2=2'
Did you have a limit put in for testing?
Michael
From: Lisa Ballard<EMAIL_ADDRESS>Date: May 22, 2015 at 12:30:40 PM PDT
To: Michael Aye <>
Hi Michael!
You can control how many results are returned by setting the limit variable in the url, so for example here at the end of the url I’ve added ‘&limit=3000' to assure we get all results for this particular search:
http://pds-rings-tools.seti.org/opus/api/files.json?instrumentid=Cassini+ISS&target=S+RINGS&projectedradialresolution1=0.5&projectedradialresolution2=2&limit=3000
The API only returns 100 results at a time, ‘pages’ if you will. You can navigate the pages by setting the page variable in the url, like here I’ve added page=5 at the end.
http://pds-rings-tools.seti.org/opus/api/files.json?instrumentid=Cassini+ISS&target=S+RINGS&projectedradialresolution1=0.5&projectedradialresolution2=2&page=5
This behavior is actually by design, as some large results will spin for awhile to serve thousands of results.. but I think since you asked it could be made clearer what is happening in the response itself. For example there could be another variable besides ‘data’ that tells you things like what page you are on, what the current limit is set to, and what the total result count is.. so I’m going to add this to our issue tracker for a future improvement.
hope this helps!
-lisa

Bitbucket: https://bitbucket.org/ringsnode/opus2/issue/156

This is done for dataimages.json but needs to be ported to data.json and images.json


Show deprecation notice in kured output

would be better if these warnings were in yellow text

Addon does not provide good interface for handling colors (pastel?).


Page Specifc JS based on atomic elements (Prototype 2)

In this concept, atomic elements will define their associated JS which will be rendered on page load.
Testing

create a demo page with Expandable/Expandable Group elements.

Reviews
@rosskarchner
@anselmbradford

I understand this approach but why not go with the approach as mentioned here : https://github.com/torchbox/wagtail/issues/1143#issuecomment-88828696

In my imagination, the "magic" happened at render time, not when the the page was saved... that's not a knock against it, it's trading some simplicity for something that should in theory perform better.

:+1:  @sebworks-- I think the ideal solution would re-purpose the conventions around form asset inclusion  (ie, support the inner Media class OR the media property)

@sebworks @rosskarchner alright took a look at that link, so i've made some refactoring so we use the Media class, contained the getting of the children streamfields within their parent model (cleaner) and the page JS logic is fired render time.

@anselmbradford So i expected the error i posted (above in description) would disappear once i had expendables on the page. Could you look into why i'm getting those javascript errors?

@kave Yea, I'll check in the AM.

@kave I tried adding an expandable and an expandablegroup to a demo page, saved, and previewed but I don't see anything in the js console. Any ideas?

Spoke to ans offline and found the problem. Current code is good to go

:+1:  @anselmbradford are you comfortable with this approach, over what was done in #1200?

@kave thanks. Looks good to me

Just minor question :+1:


Get rid of protobuf-config/agent-config checked in the repo

for now we should use submodules to make sure we don't have to versions of it.

This is in feature/ticket146 PR.


mock-8 raw data needs to be converted to fastq

they're currently in single-line formats.
@shiffer1 and @wmercurio are going to take a crack at this.

All barcode and sequence files have been reformatted and we have fastqs for everything but the mock10 rev seqs. That gzipped file is corrupted and we need a new one. As soon as that file is found the formatting can be updated. All the files are being held on the monsoon server at NAU under the control of @shiffer1.

The raw data have been updated to correct this issue, and new links are now available in dataset-metadata.tsv. Thank you, @shiffer1 for resolving this issue!


Display “Illegal instruction (core dumped)” when running

Hi,
I building the code with GCC7 and TBB, and ran on Intel(R) Xeon(R) CPU,but it report an error with "Illegal instruction (core dumped)"， what is the reason and how to solve it?

Looking forward to your reply.
Great work by the way.
Cheers,

Hi,
Does your CPU has the support for AVX512? Could you copy the output of lscpu command?
Best


CNDB-8764: add schema_type table parameter

Motivation:
see https://github.com/riptano/cndb/issues/8764
Summary:
add a new table parameter "schema_type", the value can be NULL, 'table' and 'collection'm when it is null it is assumed to be 'table'.
This parameter is not used by Cassandra but it  will be used by CNDB in order to distinguish a regular CQL table from a table that is backing a Stargate Data API Collection

One problem, that is under discussion on slack, is with this patch it is not possible to perform a smooth rolling upgrade (and also rollback), because the previous version doesn't handle the new schema_type parameter.

because the previous version doesn't handle the new schema_type parameter.

But isn't it a problem only if you create new tables after upgrading which would set the schema_type?

Yes, you're right. And I also noticed it was even worse than I thought. The schema_type column is added to the system schema and then going back to the old version causes a crash at startup with corrupted something exception.
It would be nice if we could solve this problem for all new properties maybe? Like if there is downgrade, maybe ignore unknown properties?


"Implement missing members" generates trait name instead of associated types if these have the same name

In this code:
pub trait Foo {}

pub trait Types {
    // Associated type with the same as a trait in the scope.
    type Foo;
}

pub trait Behavior<T: Types> {
    // Using associated type as a parameter.
    fn reproduce(&self, foo: T::Foo);
}

pub struct Impl;

impl<T: Types> Behavior<T> for Impl {}

when I use "implement missing members" assist on the last line, this gets generated:
impl<T: Types> Behavior<T> for Impl {
    fn reproduce(&self, foo: Foo) {
        todo!()
    }
}

That is, the trait Foo is used in place where T::Foo should be used.
Interestingly, the assist "implement the missing item: fn reproduce(..." generates this (after formatting):
impl<T: Types> Behavior<T> for Impl {
    fn reproduce(&self, _: <T as Types>::Foo) {
        todo!()
    }
}

which is correct, although I would prefer using T::Foo directly, because it is valid in the trait definition, but I may be unaware of cases where the this short version would break.

rust-analyzer version: 7f28b4975 2021-12-18 nightly
rustc version: rustc 1.57.0 (f1edd0429 2021-11-29)

I am not familiar with RA codebase and don't know all the concepts, but this is what I was able to find:
Conversion from ast::Path to hir_def::Path here discards T:: from T::Foo. This is because after pushing segment Foo, it breaks the loop here, so T is not added. This fact causes speculative_resolve to return the Foo trait definition (because it is found in the scope) and then T::Foo is replaced by Foo in this branch.
I hope my findings are not misleading.
If someone points to the real culprit here and gives me some advice how to proceed, I can continue working on a fix, or at least give it a try.

Conversion from ast::Path to hir_def::Path here discards T:: from T::Foo.

Are you sure about this? If I see this right we push foo, then get T from the qualifier call and work with that in the next loop iteration. It would surprise me if it didn't. I can take a look at the cause tomorrow and give more info on this.

I am using dbg! macro for debugging this and this is an output that relates to transforming T::Foo:
[crates/ide_db/src/path_transform.rs:143] &path = Path {
    syntax<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>"T"
<EMAIL_ADDRESS>"::"
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>"Foo"
    ,
}
[crates/hir_def/src/path/lower.rs:29] &path = Path {
    syntax<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>"T"
<EMAIL_ADDRESS>"::"
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>"Foo"
    ,
}
[crates/hir_def/src/path/lower.rs:31] &segment = PathSegment {
    syntax<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>"Foo"
    ,
}
[crates/hir_def/src/path/lower.rs:113] qualifier(&path) = None
[crates/hir_def/src/path/lower.rs:139] &segments = [
    Name(
        Text(
            "Foo",
        ),
    ),
]

lower.rs:29] &path, lower.rs:31] &segment and lower.rs:113] qualifier(&path) are from inside the loop, lower.rs:139] &segments shows returned segments from lower_path.
But since you found this behavior surprising, I focused on the qualifier function. I think the problem is that Path::qualifier returns Path, whereas the T part is yet encapsulated under PathType. If I add Path::path_type(&self) -> Option<PathType> method and change the qualifier function to this:
 fn qualifier(path: &ast::Path) -> Option<ast::Path> {
     if let Some(q) = path.qualifier() {
         return Some(q);
+    } else if let Some(q) = path.path_type().and_then(|pt| pt.path()) {
+        return Some(q);
+    }
     // FIXME: this bottom up traversal is not too precise.
     // Should we handle do a top-down analysis, recording results?
     let use_tree_list = path.syntax().ancestors().find_map(ast::UseTreeList::cast)?;
     let use_tree = use_tree_list.parent_use_tree();
     use_tree.path()
 }

the test case passes and no other existing test fails.

that syntax tree looks ... wrong? That should definitely be
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>"T"
<EMAIL_ADDRESS>"::"
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>"Foo"

so I assume something is constructed the ast somewhere manually(not from parsing as that definitely parses correctly), but incorrectly.

Ok, then changing the following line:
ted::replace(path.syntax(), subst.clone_subtree().clone_for_update().syntax())

to
if let ast::Type::PathType(path_type) = subst {
    ted::replace(
        path.syntax(),
        path_type.path()?.clone_subtree().clone_for_update().syntax(),
    );
} else {
    ted::replace(
        path.syntax(),
        subst.clone_subtree().clone_for_update().syntax(),
    );
};

does the job too.
This code is responsible for substituting original generic type with either concrete type (like u32) or differently named generic type (e.g., U instead of T). Since it substitutes types, it introduced PathType into the path in this case, making that wrong tree.
However, thinking about this substitution more, I came up with an example unrelated to this issue where it generates code that does not compile due to ambiguity of associated type:
pub trait Types {
    type Foo;
}

pub trait Types2 {
    type Foo;
}

impl Types for u32 {
    type Foo = bool;
}

impl Types2 for u32 {
    type Foo = String;
}

pub trait Behavior<T: Types> {
    fn reproduce(&self, foo: T::Foo);
}

pub struct Impl;

impl Behavior<u32> for Impl {
    //                 Types::Foo or Types2::Foo?
    //                            v
    fn reproduce(&self, foo: u32::Foo) {
        todo!()
    }
}

so maybe it make sense to think about it more and fix other potential issues as well.

Ah ye that transform is certainly wrong. I think the proper fix for it is actually
if let Some(path_type) = path.parent().and_then(ast::TypePath::cast) {
    ted::replace(
        path_type.syntax(),
        subst.clone_subtree().clone_for_update().syntax(),
    );
} else {
    ted::replace(
        path.syntax(),
        subst.clone_subtree().clone_for_update().syntax(),
    );
};

as we don't want to wrap other types in PathType nodes either.
Fixing the other issue certainly would make sense as well

Thanks, I will open a PR soon with the fix and will see if I am able to do something about the other issue too.

I came across the same bug today and wrote a small repro before finding that it's already been reported and potentially fixed, so going to pile on here :)
trait Bar {
    type Key;
}

trait Foo: Bar {
    fn do_something(key: <Self as Bar>::Key);
}

struct Foobar;

impl Bar for Foobar {
    type Key = u32;
}

//
// Use "Implement missing members" on an empty `impl Foo for Foobar {}`:
//
impl Foo for Foobar {
    /// What "Implement missing members" generates:
    fn do_something(key: Bar::Key) {
        todo!()
    }

    /// What it should generate:
    fn do_something(key: <Self as Bar>::Key) {
        todo!()
    }
}

In this case, the long-form is needed to disambiguate the type on Bar. It could also use <Foobar as Bar>::Key.


Use Monte Carlo sampling for validation and test accuracy

Average across multiple runs, and/or add ability to make model deterministic (not mentioned in paper tho)

added in #43


Short links in collaborative docs

I have been asked a few times how to make a link in a collaborative doc in such a way that the whole url is displayed. Similar to an HTML  tag or markdown link
Can this reasonably be added?

It's possible we could pull something like https://www.npmjs.com/package/ep_linkify in. Though it's not markdown syntax, I'm surprised it's a syntax at all and not a toolbar icon to highlight and make something a link.

This seems to only make links to other etherpad docs, which, while it's
useful, appears like a halfway thing as external links are likely to be as
common.
On 22 December 2015 at 11:23, Branden Visser<EMAIL_ADDRESS>wrote:

It's possible we could pull something like
https://www.npmjs.com/package/ep_linkify in. Though it's not markdown
syntax, I'm surprised it's a syntax at all and not a toolbar icon to
highlight and make something a link.
—
Reply to this email directly or view it on GitHub
https://github.com/oaeproject/Hilary/issues/1272#issuecomment-166587935.

I'm going to add this to the design feedback and functional priorities list to ensure that we keep track of this.


Implement ToConstraintField for AffineCurve

This PR implements ToConstraintField for AffineCurve, which is to facilitate implementations of recursive proofs. To do so, ToConstraintField is now implemented for all fields, in which a field can be represented by the field's BaseRepresentationField, defined as follows:

Fp320, Fp384, ...  -> Themselves
Cubic of field X     -> X's BaseRepresentationField
Quad of field X      -> X's BaseRepresentationField

A few repetitions of requirements are used to make the Rust compiler happy.
This PR has been used (and tested) in the ongoing implementation of Marlin's constraints.
Looking for initial feedback.

Ah, the original repo has been tainted.
So I guess it is better for me to apply this to the refactored version instead. Closed for now.


follow-on to removal of jcr.Session from kernel-api

Addresses: https://jira.duraspace.org/browse/FCREPO-1868
Depends on https://github.com/fcrepo4/fcrepo4/pull/1123

👍


Small touch: lower evalMap to foreach

Slightly lighter.
Potentially, we could pass down the queue to next to even reduce the type of the stream...

OBE

@mpilquist OBE?


update to react-router 6

UCP https://github.com/pingcap-incubator/tidb-dashboard/issues/249
Update to react-router6
Signed-off-by: Fullstop000<EMAIL_ADDRESS>

hi @Fullstop000 , thanks for your contribution, I will test and review soon.

Hi @Fullstop000 , after my test,  it have some errors, statements / diagnose / search logs / profile pages can't show normally, they are all empty, and the console output following errors:
Uncaught Error: Route(...): Nothing was returned from render. This usually means a return statement is missing. Or, to render nothing, return null.

Got something pained after upgrading to react-router v6

Got something pained after upgrading to react-router v6

yep, that's a problem, we need to have a look.

And I got this warning only when unmount AppStatement

And I got this warning only when unmount AppStatement

I will have a look today.

There is some discussion in https://github.com/facebook/react/issues/18178 , I tried to upgrade the  react to 16.13.1 , it doesn't dismiss the warning.
It should be caused by the new version react-router, above warning doesn't happen for react-router v5, someone has already reported in https://github.com/ReactTraining/react-router/issues/7199 as well.
So I think let's wait a few days more to see whether react-router will fix it, if it doesn't, we can merge it first and upgrade it in the future.

So I think let's wait a few days more to see whether react-router will fix it, if it doesn't, we can merge it first and upgrade it in the future.

Sounds reasonable :)

hi  @Fullstop000 , react-router fixed above warning in https://github.com/ReactTraining/react-router/releases/tag/v6.0.0-alpha.3 , you can have a try, but unfortunately they removed <Redirect/> component as well which we used, not sure whether it is easy to migrate, if it doesn't, I suggest let update react-router v6 until it is stable, @breeswish , how do you think about it?

Maybe using a history API instead <Redirect/> ? I'll have a try later today.

@baurine I'm fine with both. This task is not ergant.

@baurine The second warning has been fixed and the first warning only shows on the initial render.


Package tag per package

I would love to have tags for each package so you can list all the releases of a specific package
Trying to find all the releases is time consuming since GitHub only shows 10 releases per page and there are so many packages in this repo
Today packages are tagged with the package name + the package version

Hi @estensen
As you say, we tag with the format "package_version", for example "azure-keyvault_4.1.0" so I'm not sure you would want different? Could you give an actual example?
Thank you,

If you could tag with azure-keyvault in addition to azure-keyvault_4.1.0 it would be possible to list all versions of azure-keyvault instead of manually going through the list to find all the versions.

I think we are tagging the way you are requesting but github UI doesn't do a great job in showing tags, but you can do it from the command line:
> git tag -l azure-keyvault_*
azure-keyvault_0.2.0
azure-keyvault_0.3.0
azure-keyvault_0.3.1
azure-keyvault_0.3.2
azure-keyvault_0.3.3
azure-keyvault_0.3.4
azure-keyvault_0.3.5
azure-keyvault_0.3.6
azure-keyvault_0.3.7
azure-keyvault_1.0.0
azure-keyvault_1.0.0a1
azure-keyvault_1.0.0a2
azure-keyvault_1.0.0b1
azure-keyvault_1.1.0
azure-keyvault_4.0.0
azure-keyvault_4.1.0
azure-keyvault_prior-to-deletion

Reading your request again I think you were asking if we could also add a tag called "azure-keyvault" to all the releases, however that will not work as git tags can only point to a single sha. However with the command line you can list all the package version tags in the manor I suggested.

aha, didn't know that tags have to be unique
But back to the problem. Updating a package I have to find the changelog of al the packages between the version I'm updating from and to the version I'm updating to. It seems cumbersome to download the repo to use the command line. How would you go about doing this?

Isn't the change log on pypi.org enough for you to find the information? https://pypi.org/project/azure-keyvault/

Thanks! It works for manually checking, but not for Dependabot. Upgrading azure-cosmos from 3.1.2 to 4.0.0 it does not list the changes in the beta versions in between:

Not sure if this is a problem with Dependabot or the way the release notes are created.

Not sure either as the dependabot doesn't clearly identify how they are supposed to be structured. If we are down to just figuring out dependabot again lets close this issue and continue that conversation at https://github.com/Azure/azure-sdk-for-python/issues/10595.

sure!


Factory tests are wrong

When I changed newTokenAddr to 0x0002, the test still passed.
These tests should be broken up, and also test for invalid verifications.
Also, the actual tests are not as thorough as the description.

This test is working. Unclear what I was talking about.


Allow symbols to be actionTypes

So you can do,
// actionTypes.js
export const MY_ACTION = Symbol();

I'm not sure I'm going to support this because symbols are not serializable AFAIK.
See also #4.

I'm closing for now (see reasons in #4) but may revisit later.
Need to understand our tooling story (#7) first.
Thanks for the PR though!


Allow a means to determine if the server has been successfully initialized

It would be helpful for there to be a handler function that one can run right when the server has successfully began that can be used for various purposes e.g. printing a log that the server has been successfully initialized or even informing other services that the server is ready to accept requests.
// Build server
        let server = Server::builder(HyperAcceptor {
            acceptor: Box::pin(incoming_tls_stream),
        }).serve(service);

        // Run the future, keep going until an error occurs.
        println!("[https-server]: Starting to serve on https://{}.", config.fqdn);

        server
            .await
            .map(|v| {
                println!("STARTED SERVER!"); // This never executes unfortunately
            })
            .map_err(|e| {
                eprintln!("[https-server]: error: {:?}", e);
            })
            .unwrap();

The server future doesn't finish when the server is started. You can print your message just before awaiting it (or spawning it in a task, etc).

@seanmonstar thanks for the response. I see what you mean.
Is there a way to know when the server has fully initialized such that subsequent dependent actions can be taken e.g. kickoff a job, write logs, inform a local client that the server can now begin receiving requests etc?

Once you've "built" the server, everything is ready at that point (I guess unless some custom acceptor internally will still delay accepting for some reason, but we can't know that). The only caveat is that if you do something else before awaiting the server future, since it's not being polled it cannot accept connections.


Roll engine 77c3512ec85e..97df087ee678 (7 commits)

git@github.com:flutter/engine.git/compare/77c3512ec85e...97df087ee678
git log 77c3512ec85e..97df087ee678 --no-merges --oneline
2019-11-14<EMAIL_ADDRESS>[fuchsia] Package flutter_frontend_server snapshot for fuchsia (flutter/engine#13865)
2019-11-14<EMAIL_ADDRESS>Guard against orphaned semantic objects from referencing dead accessibility bridge on iOS (flutter/engine#13857)
2019-11-14<EMAIL_ADDRESS>Fix test to account for pixel ratio transformations being framework responsibility. (flutter/engine#13850)
2019-11-14<EMAIL_ADDRESS>RendererContextSwitch guard flutter's gl context rework. (flutter/engine#13812)
2019-11-14<EMAIL_ADDRESS>Roll src/third_party/skia d860a78fd60c..e57ca4931952 (44 commits) (flutter/engine#13862)
2019-11-14<EMAIL_ADDRESS>Roll fuchsia/sdk/core/mac-amd64 from 7XOyl... to VMTIz... (flutter/engine#13861)
2019-11-14<EMAIL_ADDRESS>Roll src/third_party/dart dc35290111..dc808f3fcb (5 commits) (flutter/engine#13859)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/4595327084003328 , https://cirrus-ci.com/task/4947170804891648 , https://cirrus-ci.com/task/5721226990845952

Commit queue failed; closing this roll.


Feature Request: option to exit warp mode on a click

It'd be useful to exit warp mode after a click, not just with the 'exit' key. This is how keyboardio works.
Might be nice to make the exit keysym configurable as well

Done. The key after the third mouse button (passed to -k) is now interpreted as a close key. You can make this the same as button 1 to achieve the effect you want.

This is now the default behaviour. A small timeout is used to facilitate double/triple clicking.


Update layers/meta-balena digest to c3560cf

This PR contains the following updates:

Package
Update
Change

layers/meta-balena
digest
e7ea08b -> c3560cf

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Can one of the admins verify this patch?


Add support for Python 3.5

I'd like this for https://github.com/dmtucker/keysmith/pull/26

Thank you for your contributions to both pytest-codostyle and pytest-docstyle.


Directly search the internet

Hello,
Its great to see the new form of dmenu with added plugins. I really apreciate your work and I have been using it for my day to day life.
I was wonder if it is possible to directly search the internet with keybind. Currently, I have to run dmenu_extended_run and choose the third option with down key(which is far away) , select google and then search .. It will be nice if we can search directly with keybind like:
$ dmenu_extended_run --search google
Well, it will be really nice if you add the search result too in list format.
Thanking You
Subash

I had a similar issue and came up with a workaround:

Install the Internet Search Plugin and set Google to be your default web search(if I remember correctly, it already is)
In a text editor, open ~/.config/dmenu-extended/plugins/plugin_internetSearch.py
Edit the line that says title='Internet Search: ' right after class extension to say title= 'g: ' [The g for me stands for google]
Open dmenu_extended_run and rebuild the cache.
Now when you open up dmenu_extended_run the "g: " should be the first option.  Which means you can simply open up dmenu extended, and hit tab to begin searching.

Hope this helps.

Hi there,
I've updated dmenu_extended to give the functionality you're looking for (hopefully).
Once you've updated your dmenu_extended, refer to the README.md under the section "Advanced keybinds" for usage instructions.
Thanks Nabsiddqui, that is a nice workaround.
Let me know if you face any issues with the plugin or dmenu_extended.

Thanks guys.. It works.

Great.


Add procedure to clean up stack overflow table

Partly addresses #134.
Add a procedure to stdlib to remove elements in the stack overflow table to clean up at the end of program completion.
It's kept separate for now and not added to the assembler to include to all programs as suggested by @bobbinth.

@bobbinth Should the procedure be kept separate for now as you suggested or should it be added to the assembler? I'd imagine this adds a lot of unnecessary overhead?

Thank you so much for the review @bobbinth. Made suggested changes.


[Docs][Tree] Include multi-selection example without keyboard interaction

Added in https://github.com/trendmicro-frontend/tonic-ui/pull/845


#401 add tests

close #401

[Current coverage][cc-pull] is 46.53%

Merging [#407][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #407   diff @@
==========================================
  Files           127        127
  Lines          2938       2938
  Methods           0          0
  Messages          0          0
  Branches        242        242
==========================================
  Hits           1367       1367
  Misses         1510       1510
  Partials         61         61

[][cc-pull]

Powered by Codecov. Last updated by f7c6deb
[cc-base-branch]: https://codecov.io/gh/zalando-stups/fullstop/branch/master?src=pr
[cc-pull]: https://codecov.io/gh/zalando-stups/fullstop/pull/407?src=pr

:+1:


Author info problem

https://github.com/mit-cml/appinventor-sources/blob/4467771cdc862ac680b7fec5f1fc8ea25ae6182a/appinventor/components/src/com/google/appinventor/components/runtime/Deleteable.java#L13

May be interested by @mark-friedman


force utf-8 encoding when calling poetry to allow tox to parse logs

Solves to #7

Thanks!

0.4.1 with your fix released.

Thanks for merging :)


Replaced ydb.Connection interface to struct ydb.Connection

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Other information

Codecov Report
Base: 62.82% // Head: 44.79% // Decreases project coverage by -18.03% :warning:

Coverage data is based on head (2f228bf) compared to base (855add8).
Patch coverage: 15.27% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff             @@
##           master     #587       +/-   ##
===========================================
- Coverage   62.82%   44.79%   -18.03%
===========================================
  Files         222      144       -78
  Lines       21770    15581     -6189
===========================================
- Hits        13676     6980     -6696
- Misses       7408     8269      +861
+ Partials      686      332      -354

Flag
Coverage Δ

1.16.x
?

1.19.x
44.79% <15.27%> (-17.77%)
:arrow_down:

1.20.x
?

insecure
?

integration
?

macOS-latest
?

secure
?

ubuntu-latest
44.79% <15.27%> (-18.01%)
:arrow_down:

unit
44.79% <15.27%> (-0.03%)
:arrow_down:

windows-latest
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


GP series sum  and Ap series sum Java Programs-Shashank

Why:
Closes #4980
Java Program for sum of GP series by Shashank
Closes  #4368
Java Program for sum of AP series by Shashank

@shashankgurunaga1 Please add the correct issue id for GP series sum in Java

I have made the changes .Can you look into it ? @anandfresh


fix: auto-import machines correctly during dev

🔗 Linked issue
Solves #9

📖 Updated documentation

📚 Description

Thanks for the help @danielroe ❤


Why does UnitOrHeroDefinition.setNormalAbilities() use string rather int as parameter?

Current:
setNormalAbilities("AInv")
How it should be:
setNormalAbilities('AInv')
or
setNormalAbilities(AbilityIds.inventory)
should not?

No, it should not, since you can specify multiple ids. In the object editor you will see the same string "A000,A001,A002" for a list of spells, buildings constructed, units sold, etc.
In wurst to wrap this nicely you should use commaList like so:
`setNormalAbilities(commaList(AbilityIds.inventory, AbilityIds.cripple, AbilityIds.frostArmor))