OWL/TTL ontology containing child nodes with multiple parent nodes defined via owl:intersectionOf are not working

I stumbled across this issue when working with the Snomed CT ontology (in OWL) and searching for specific terms (e.g. Trastuzumab). They are not present in the ontology parsed by BioCypher.
Debugging Biocypher's ontology parsing process:

In the rdf graph there are around 390000 concepts.
The parsed networkx graph only contains 67133 nodes/concepts.

Why are so many concepts missing in the parsed ontology?
-> Whenever a concept has multiple parent nodes it is not added to the networkx graph.
Example: The following example OWL class is not in the parsed ontology (and has multiple parent nodes defined in owl:intersectionOf):
    <owl:Class rdf:about="http://snomed.info/id/771358001">
        <rdfs:subClassOf>
            <owl:Class>
                <owl:intersectionOf rdf:parseType="Collection">
                    <rdf:Description rdf:about="http://snomed.info/id/120575009"/>
                    <rdf:Description rdf:about="http://snomed.info/id/38033009"/>
                </owl:intersectionOf>
            </owl:Class>
        </rdfs:subClassOf>
        <rdfs:label xml:lang="en">Amputation stump of lower limb (body structure)</rdfs:label>
        <skos:prefLabel xml:lang="en">Amputation stump of lower limb</skos:prefLabel>
    </owl:Class>

In ttl it would be defined like this:
###  http://snomed.info/id/771358001
<http://snomed.info/id/771358001> rdf:type owl:Class ;
                                  rdfs:subClassOf [ owl:intersectionOf ( <http://snomed.info/id/120575009>
                                                                         <http://snomed.info/id/38033009>
                                                                       ) ;
                                                    rdf:type owl:Class
                                                  ] ;
                                  rdfs:label "Amputation stump of lower limb (body structure)"@en ;
                                  skos:prefLabel "Amputation stump of lower limb"@en .

To understand the issue I have created a toy example.

ontology.ttl -> working as expected
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix grddl: <http://www.w3.org/2003/g/data-view#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.w3.org/2002/07/owl> a owl:Ontology ;
     dc:title "The OWL 2 Schema vocabulary (OWL 2)" ;
     rdfs:comment """
  This ontology partially describes the built-in classes and
  properties that together form the basis of the RDF/XML syntax of OWL 2.
  The content of this ontology is based on Tables 6.1 and 6.2
  in Section 6.4 of the OWL 2 RDF-Based Semantics specification,
  available at http://www.w3.org/TR/owl2-rdf-based-semantics/.
  Please note that those tables do not include the different annotations
  (labels, comments and rdfs:isDefinedBy links) used in this file.
  Also note that the descriptions provided in this ontology do not
  provide a complete and correct formal description of either the syntax
  or the semantics of the introduced terms (please see the OWL 2
  recommendations for the complete and normative specifications).
  Furthermore, the information provided by this ontology may be
  misleading if not used with care. This ontology SHOULD NOT be imported
  into OWL ontologies. Importing this file into an OWL 2 DL ontology
  will cause it to become an OWL 2 Full ontology and may have other,
  unexpected, consequences.
   """ ;
     rdfs:isDefinedBy
          <http://www.w3.org/TR/owl2-mapping-to-rdf/>,
          <http://www.w3.org/TR/owl2-rdf-based-semantics/>,
          <http://www.w3.org/TR/owl2-syntax/> ;
     rdfs:seeAlso   <http://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-classes>,
                    <http://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-properties> ;
     owl:imports <http://www.w3.org/2000/01/rdf-schema> ;
     owl:versionIRI <http://www.w3.org/2002/07/owl> ;
     owl:versionInfo "$Date: 2009/11/15 10:54:12 $" ;
     grddl:namespaceTransformation <http://dev.w3.org/cvsweb/2009/owl-grddl/owx2rdf.xsl> .

owl:Class a rdfs:Class ;
     rdfs:label "Class" ;
     rdfs:comment "The class of OWL classes." ;
     rdfs:isDefinedBy <http://www.w3.org/2002/07/owl#> ;
     rdfs:subClassOf rdfs:Class .

owl:Root a owl:Class ;
     rdfs:label "Root" ;
     rdfs:comment "The class of OWL individuals." ;
     rdfs:isDefinedBy <http://www.w3.org/2002/07/owl#> .

owl:Level1A a owl:Class ;
     rdfs:label "Level1A" ;
     rdfs:subClassOf owl:Root ;
     rdfs:comment "Level1A." .

owl:Level1B a owl:Class ;
     rdfs:label "Level1B" ;
     rdfs:subClassOf owl:Root ;
     rdfs:comment "Level1B." .

owl:Level2A a owl:Class ;
     rdfs:label "Level2A" ;
     rdfs:subClassOf owl:Level1A ;
     rdfs:comment "Level2A." .

owl:Level2B a owl:Class ;
     rdfs:label "Level2B" ;
     rdfs:subClassOf owl:Level1A ;
     rdfs:comment "Level2B." .

owl:Level2C a owl:Class ;
     rdfs:label "Level2C" ;
     rdfs:subClassOf owl:Level1B ;
     rdfs:comment "Level2C." .

owl:Child a owl:Class ;
     rdfs:label "Child" ;
     rdfs:subClassOf owl:Level2A, owl:Level2B, owl:Level2C ;
     rdfs:comment "Child." .

ontology.ttl
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix grddl: <http://www.w3.org/2003/g/data-view#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.w3.org/2002/07/owl> a owl:Ontology ;
     dc:title "The OWL 2 Schema vocabulary (OWL 2)" ;
     rdfs:comment """
  This ontology partially describes the built-in classes and
  properties that together form the basis of the RDF/XML syntax of OWL 2.
  The content of this ontology is based on Tables 6.1 and 6.2
  in Section 6.4 of the OWL 2 RDF-Based Semantics specification,
  available at http://www.w3.org/TR/owl2-rdf-based-semantics/.
  Please note that those tables do not include the different annotations
  (labels, comments and rdfs:isDefinedBy links) used in this file.
  Also note that the descriptions provided in this ontology do not
  provide a complete and correct formal description of either the syntax
  or the semantics of the introduced terms (please see the OWL 2
  recommendations for the complete and normative specifications).
  Furthermore, the information provided by this ontology may be
  misleading if not used with care. This ontology SHOULD NOT be imported
  into OWL ontologies. Importing this file into an OWL 2 DL ontology
  will cause it to become an OWL 2 Full ontology and may have other,
  unexpected, consequences.
   """ ;
     rdfs:isDefinedBy
          <http://www.w3.org/TR/owl2-mapping-to-rdf/>,
          <http://www.w3.org/TR/owl2-rdf-based-semantics/>,
          <http://www.w3.org/TR/owl2-syntax/> ;
     rdfs:seeAlso   <http://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-classes>,
                    <http://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-properties> ;
     owl:imports <http://www.w3.org/2000/01/rdf-schema> ;
     owl:versionIRI <http://www.w3.org/2002/07/owl> ;
     owl:versionInfo "$Date: 2009/11/15 10:54:12 $" ;
     grddl:namespaceTransformation <http://dev.w3.org/cvsweb/2009/owl-grddl/owx2rdf.xsl> .

owl:Class a rdfs:Class ;
     rdfs:label "Class" ;
     rdfs:comment "The class of OWL classes." ;
     rdfs:isDefinedBy <http://www.w3.org/2002/07/owl#> ;
     rdfs:subClassOf rdfs:Class .

owl:Root a owl:Class ;
     rdfs:label "Root" ;
     rdfs:comment "The class of OWL individuals." ;
     rdfs:isDefinedBy <http://www.w3.org/2002/07/owl#> .

owl:Level1A a owl:Class ;
     rdfs:label "Level1A" ;
     rdfs:subClassOf owl:Root ;
     rdfs:comment "Level1A." .

owl:Level1B a owl:Class ;
     rdfs:label "Level1B" ;
     rdfs:subClassOf owl:Root ;
     rdfs:comment "Level1B." .

owl:Level2A a owl:Class ;
     rdfs:label "Level2A" ;
     rdfs:subClassOf owl:Level1A ;
     rdfs:comment "Level2A." .

owl:Level2B a owl:Class ;
     rdfs:label "Level2B" ;
     rdfs:subClassOf owl:Level1A ;
     rdfs:comment "Level2B." .

owl:Level2C a owl:Class ;
     rdfs:label "Level2C" ;
     rdfs:subClassOf owl:Level1B ;
     rdfs:comment "Level2C." .

owl:Child a owl:Class ;
     rdfs:label "Child" ;
     rdfs:subClassOf [ owl:intersectionOf ( owl:Level2A
                                             owl:Level2B
                                             owl:Level2C
                                        );
                                        rdf:type owl:Class
                                        ] ;
     rdfs:comment "Child." .

ontology.owl
<rdf:RDF xmlns="http://www.w3.org/2002/07/owl#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xmlns:owl="http://www.w3.org/2002/07/owl#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:grddl="http://www.w3.org/2003/g/data-view#"
         xmlns:xml="http://www.w3.org/XML/1998/namespace"
         xmlns:xsd="http://www.w3.org/2001/XMLSchema#">

  <owl:Ontology rdf:about="http://www.w3.org/2002/07/owl">
    <dc:title>The OWL 2 Schema vocabulary (OWL 2)</dc:title>
    <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
      This ontology partially describes the built-in classes and properties that together form the basis of the RDF/XML syntax of OWL 2. The content of this ontology is based on Tables 6.1 and 6.2 in Section 6.4 of the OWL 2 RDF-Based Semantics specification, available at http://www.w3.org/TR/owl2-rdf-based-semantics/. Please note that those tables do not include the different annotations (labels, comments and rdfs:isDefinedBy links) used in this file. Also note that the descriptions provided in this ontology do not provide a complete and correct formal description of either the syntax or the semantics of the introduced terms (please see the OWL 2 recommendations for the complete and normative specifications). Furthermore, the information provided by this ontology may be misleading if not used with care. This ontology SHOULD NOT be imported into OWL ontologies. Importing this file into an OWL 2 DL ontology will cause it to become an OWL 2 Full ontology and may have other, unexpected, consequences.
    </rdfs:comment>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/TR/owl2-mapping-to-rdf/"/>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/TR/owl2-rdf-based-semantics/"/>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/TR/owl2-syntax/"/>
    <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-classes"/>
    <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/owl2-rdf-based-semantics/#table-axiomatic-properties"/>
    <owl:imports rdf:resource="http://www.w3.org/2000/01/rdf-schema"/>
    <owl:versionIRI rdf:resource="http://www.w3.org/2002/07/owl"/>
    <owl:versionInfo>$Date: 2009/11/15 10:54:12 $</owl:versionInfo>
    <grddl:namespaceTransformation rdf:resource="http://dev.w3.org/cvsweb/2009/owl-grddl/owx2rdf.xsl"/>
  </owl:Ontology>

  <owl:Class rdf:about="#Class">
    <rdfs:label>Class</rdfs:label>
    <rdfs:comment>The class of OWL classes.</rdfs:comment>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/2002/07/owl#"/>
    <rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  </owl:Class>

  <owl:Class rdf:about="#Root">
    <rdfs:label>Root</rdfs:label>
    <rdfs:comment>The class of OWL individuals.</rdfs:comment>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/2002/07/owl#"/>
  </owl:Class>

  <owl:Class rdf:about="#Level1A">
    <rdfs:label>Level1A</rdfs:label>
    <rdfs:subClassOf rdf:resource="#Root"/>
    <rdfs:comment>Level1A.</rdfs:comment>
  </owl:Class>

  <owl:Class rdf:about="#Level1B">
    <rdfs:label>Level1B</rdfs:label>
    <rdfs:subClassOf rdf:resource="#Root"/>
    <rdfs:comment>Level1B.</rdfs:comment>
  </owl:Class>

  <owl:Class rdf:about="#Level2A">
    <rdfs:label>Level2A</rdfs:label>
    <rdfs:subClassOf rdf:resource="#Level1A"/>
    <rdfs:comment>Level2A.</rdfs:comment>
  </owl:Class>

  <owl:Class rdf:about="#Level2B">
    <rdfs:label>Level2B</rdfs:label>
    <rdfs:subClassOf rdf:resource="#Level1A"/>
    <rdfs:comment>Level2B.</rdfs:comment>
  </owl:Class>

  <owl:Class rdf:about="#Level2C">
    <rdfs:label>Level2C</rdfs:label>
    <rdfs:subClassOf rdf:resource="#Level1B"/>
    <rdfs:comment>Level2C.</rdfs:comment>
  </owl:Class>

  <owl:Class rdf:about="#Child">
    <rdfs:label>Child</rdfs:label>
    <rdfs:subClassOf>
      <owl:Class>
        <owl:intersectionOf rdf:parseType="Collection">
          <rdf:Description rdf:about="#Level2A"/>
          <rdf:Description rdf:about="#Level2B"/>
          <rdf:Description rdf:about="#Level2C"/>
        </owl:intersectionOf>
      </owl:Class>
    </rdfs:subClassOf>
    <rdfs:comment>Child.</rdfs:comment>
  </owl:Class>

</rdf:RDF>

run_bc.py
from biocypher import BioCypher

bc = BioCypher(
    biocypher_config_path="./debug.yaml",
)

bc.show_ontology_structure(full=True)

debug.yaml
biocypher:
  offline: true
  debug: true

  head_ontology:
    url: ./ontology.<ttl|owl>
    root_node: Root

neo4j:
  delimiter: '\t'
  array_delimiter: '|'
  skip_duplicate_nodes: true
  skip_bad_relationships: true

For both ontologies (OWL, TTL) this fails and the Child node is not part of the parsed ontology:
TTL:

OWL:

If the multiple parent nodes are defined without intersectionOf this works as expected.

I am currently trying to understand how to adapt the code here to handle this. Any advice on this? Thanks in advance!

Thanks for the fast response!
The goal for my use case would be to have all concepts of the underlying ontology also in the parsed ontology.
My use case: Grounding ontology to insert data
-> We can neglect the fact, that there are multiple parent nodes, if the child node is at least once part of the parsed ontology (e.g. take the first of the intersectionOf list).
Would that be an option? This makes this use case possible and does not blow up the NetworkX objects in the backend.
And for use cases doing inference on the full ontology one can proceed as you describe and load the ontology as data input.

Sure, but that would have to be transparently documented, otherwise could lead to similarly unexpected outcomes as the current state.

Yes, this would then need a proper documentation (because it is not the intuitively expected state).
Thus it would probably be better to go with the solution you described above and duplicate the concept and insert it multiple times (this seems to be more intuitive).
If this is alright, I will prepare a PR for it.

Sure, thanks :)


ARTEMIS-4451: fix non-SASL AMQP connection + resource audit logging

Ensure the eligibility check done can succeed with the audit logging enabled, allowing non-SASL connections if broker config allows (rather than erroneously failing and indicating SASL is required when it shouldnt be).

Nice unit test additions


Explain the basis for last sync version selection in comment

This issue tracks the fix to address the code review comment in #226.
Please add info about why this is done to the comment - we want to be able to know why unintuitive stuff like this was done without having to dig up the design doc for everything.
Originally posted by @Charles-Gagnon in https://github.com/Azure/azure-functions-sql-extension/pull/226#discussion_r931507585

Read up on this in the design doc and this is what I understand for the decision of new last sync version.

Since the batch of changes are acquired in ascending order. With multiple version numbers in the batch, the other changes with version numbers that are below the highest version number should either be already processed or being leased by other workers, which is why last sync version is updated to second highest version number.
In the query where the last sync version is actually updated in the GlobalState Table it checks if there are any unprocessed changes with version numbers lower than new last sync version. If there are none, every change with version number <= new last sync version is cleared from the Leases Table.
It is ensured that a worker lagging behind won't update the last sync version to a lower version due to condition of updating only when @current_last_sync_version < {newLastSyncVersion}.

Was trying to think of scenarios where this might fail, but seems good enough to me.
Will create a PR adding comments for it.


Unable to Union different QDM Types

Several eCQMs published in 2015 and 2016 have used "union" to group events that are of different types (CMS 100 v5, CMS 102 v5, CMS 107 v5, etc.). However, something like the following is causing an error to be thrown in the CQL-to-ELM validation:
define "Interventions":
["Intervention, Order"] union ["Intervention, Performed"]
The following error is being thrown:
Could not resolve call to operator Union with signature (list<QDM.InterventionOrder>,list<QDM.InterventionPerformed>).
Is this by design, or is this an issue in the current code?

I believe that this is by design, in order to ensure type safety.  If you look at the signature for union in the appendix of the specification, you'll see:
union(left List<T>, right List<T>) List<T>

The arguments as well as the return are all lists of T -- meaning that the contained objects must have the same type.
It's probably worth looking at the measure to see if creating a union of these different types really is the best approach.  It may be that CQL provides a better path to achieve what the measure needs.  That's the first thing I'd do.
If that isn't possible, or if creating a union like this is really best, then you may be able to union these together by casting the list elements to QDM.QDMBaseType first.  I can't remember if you can cast a whole list at once, or if you'd have to use a query to transform the list into a list of casted objects.  Either way, you'd end up unioning two lists of QDM.QDMBaseType, resulting in a list of QDM.QDMBaseType.

Thanks Chris. I'll try both approaches. Ultimately, I think the Measure Stewards are going to need to know this for their measures. It might be a good thing to send to @brynrhodes for one of the Cooking With CQL trainings. Bryn, what do you think?

Yep, this would be a great example for inclusion in a measure training, I'll add it to my list. As far as casting, there isn't a list-based cast, you'd have to do a query and return the resulting type. Another option is to shape each operand so that they both contain the same columns, then you wouldn't need to cast. Am I okay to close this issue?

Yes.

Bryn Rhodes<EMAIL_ADDRESS>8/15/2016 1:44 PM >>>

Yep, this would be a great example for inclusion in a measure training, I'll add it to my list. As far as casting, there isn't a list-based cast, you'd have to do a query and return the resulting type. Another option is to shape each operand so that they both contain the same columns, then you wouldn't need to cast. Am I okay to close this issue?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/cqframework/clinical_quality_language","title":"cqframework/clinical_quality_language","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/cqframework/clinical_quality_language"}},"updates":{"snippets":[{"icon":"PERSON","message":"@brynrhodes in #60: Yep, this would be a great example for inclusion in a measure training, I'll add it to my list. As far as casting, there isn't a list-based cast, you'd have to do a query and return the resulting type. Another option is to shape each operand so that they both contain the same columns, then you wouldn't need to cast. Am I okay to close this issue?"}],"action":{"name":"View Issue","url":"https://github.com/cqframework/clinical_quality_language/issues/60#issuecomment-239890653"}}}

Sorry for just responding. You can close this issue.


Fix Tashelhyt video URL

https://languagemap.nyc/Explore/Language/Tashelhyt
something's wrong with that one's URL, throwing several Sentry errors

Maybe was just missing a www in the link, seems fine now


Update and Create Return Uncontextualized Page object

The update and create functions return Page object. But the returned object is uncontexualized. This can cause problem, because it will result in having page.tuples and reference.columns to not be in-sync.

I didn't consider this before. This should be trivial to fix and it currently only affects the resultset view of recordedit when the user creates/updates 2 or more entities. In other cases we redirect to record page which contextualizes properly before showing the data.
One thing to think about is what context should these references be in after create/update returns? I imagine we want it to be in the detailed context or compact. Those contexts are used for record and recordset respectively. The resultset view is more similar to recordset, but maybe we want to introduce a new context.

I actually found this problem when I was changing the multi edit result page.
We are using the returned page to show which tuples are updated. Currently we are using compact context for that page. It make sense for it to be compact, because we are showing the compact view. But then again, you might have changed something and in the result page that column might not be visible (by having different visible columns for entry/edit and compact). That's why I think having a new context might make more sense.

I talked to @hongsudt about this a few minutes ago while asking her about other tasks, and she said to keep it relative to the context that the data was manipulated in. If it was create, contextualize to entry/create, and entry/edit for edit.
This way the user will see only the columns that they added values for or updated values for.

After discussing it with @hongsudt and @jrchudy, we decide to use compact context for both of them for now. We might need to introduce a new context in the future.


InterruptedException at com.firebase.ui.firestore.paging.FirestorePagingSource.lambda$loadSingle$0(FirestorePagingSource.java)

Hi! I hope I'm in the right place. I've posted my problem on stackoverflow but I'm wondering if there is a problem with the library or not. It might be my code, but it started to happen after updating to the latest FirebaseUI-Android.
Describe your environment

Android device: 11 different Samsungs,
motorola edge 20 pro, Lenovo TAB 2 A10-30
Android OS version: 11, 10, 6.0.1
Google Play Services version: com.google.android.gms:play-services-base:17.6.0
Firebase/Play Services SDK version: com.google.firebase:firebase-firestore:23.0.4com.firebaseui:firebase-ui-firestore:8.0.0
FirebaseUI version: com.firebaseui:firebase-ui-firestore:8.0.0

Step 3: Describe the problem:
I've posted my problem on stackoverflow.
Steps to reproduce:
I'm having lots of trouble reproducing the issue. It only happens to about 2 of 100 users and I don't know how to trigger a InterruptedException. Can't read in the documentation if and where I should catch it.
Observed Results:
I've posted all logs on stackoverflow
Also, if I skip the .setLifecycleOwner(mainActivity) (which says it's optional) the app crash with:
Attempt to invoke interface method 'androidx.lifecycle.Lifecycle androidx.lifecycle.LifecycleOwner.getLifecycle()' on a null object reference com.firebase.ui.firestore.paging.FirestorePagingOptions$Builder.setQuery (FirestorePagingOptions.java:168).
Expected Results:
Expected the code not to crash, worked fine before updating FirebaseUI-Android.

Did you get a fix for this?

In the further reading, I found an example of an error handler. Not sure if we are expected to use this or if they will fix the InterruptedException in the future. Any how, I implemented it and I'm not receiving any crash reports on this matter any more.

If one decides to add a non-empty global error consumer, here is an example that manages the typical undeliverable exceptions based on whether they represent a likely bug or an ignorable application/network state:

RxJavaPlugins.setErrorHandler(e -> {
    if (e instanceof UndeliverableException) {
        e = e.getCause();
    }
    if ((e instanceof IOException) || (e instanceof SocketException)) {
        // fine, irrelevant network problem or API that throws on cancellation
        return;
    }
    if (e instanceof InterruptedException) {
        // fine, some blocking code was interrupted by a dispose call
        return;
    }
    if ((e instanceof NullPointerException) || (e instanceof IllegalArgumentException)) {
        // that's likely a bug in the application
        Thread.currentThread().getUncaughtExceptionHandler()
            .handleException(Thread.currentThread(), e);
        return;
    }
    if (e instanceof IllegalStateException) {
        // that's a bug in RxJava or in a custom operator
        Thread.currentThread().getUncaughtExceptionHandler()
            .handleException(Thread.currentThread(), e);
        return;
    }
    Log.warning("Undeliverable exception received, not sure what to do", e);
});

Where exactly you added this code?

Just make sure the function is called before initializing the adapter. I made a service using Dagger, that calls this function, which I injected into the activity where the adapter is set up.


cmd/vet: warn on using integer format to print pointer in Printf

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go1.9rc2 linux/amd64
What operating system and processor architecture are you using (go env)?
GOHOSTARCH="amd64"
GOHOSTOS="linux"
What did you do?
https://play.golang.org/p/k89vjAT5Kt
package main
import (
"fmt"
)
func main() {
i := 37
p := &i
fmt.Printf("Why: %d", p)
}
What did you expect to see?
I expected to see some sort of error / warning about the implicit conversion of a pointer type into an integer format verb %d. I expected the computer to help me catch the mistake of not derefrencing p to get the expected integer.
What did you see instead?
No error or warning, and the output contains the address of the pointer printed in base10.

Looking at the the docs this seems like a bug in fmt.

We can't change fmt, but we could change cmd/vet.

CC @robpike

We can't change fmt, but we could change cmd/vet.

Even when the behavior is not supported by the documentation?

If the behavior is deemed correct, can the documentation be adjusted to account for it?

In some cases we can adjust the doc, but in a case like this I personally think that the chances of breaking a currently working program are too high.

Sorry, I mean in some cases we can adjust the code (but I think this case is too risky).
We can always adjust the doc, and, yes, we should do so.

I can't find it now but I seem to remember this was an actual change that went in at some point, and that the docs need to catch up to the change. I might just be confused though.

According to the documentation, section 'Format errors', passing a pointer to the %d verb is the case of invalid argument, %d is documented to accept only integers - and it should produce %!d(pointer=0xdeafbeef) per docs.
Can someone please explain to me why adjusting the docs instead of fixing the bug is considered? IMO
it breaks the Go 1 compatibility promise, while fixing the bug does not, by definition.
Also, for the %d verb to accept pointers looks to me like a C-ism and the OP readily demostrates why it's good that Go avoids them.

AFAICT %d has been supported for pointers since go1.0:
https://github.com/golang/go/blob/release-branch.go1/src/pkg/fmt/print.go#L589
@robike maybe this is the change you were searching for:
fmt: honor integer radix formats (%d etc.) for pointers
https://codereview.appspot.com/6441152
https://github.com/golang/go/issues/3936
this changed the behavior of %d on pointers for go1.1 but did not introduce the %d support for pointers.

Thanks for the link. It makes clear that supporting %d and other verbs for pointers is intentional. IIUC now, it's undocumented behavior since Go 1. Programs relying on undocumented behavior are not protected by the Go 1 compatibility promise.

@martisch Yes, that's the one I was thinking of. I agree it's a documentation issue at this point.


getCameraBitmap() null

The following:-
@Override
    public void onActivityResult(int requestCode, int resultCode, Intent data) {
        super.onActivityResult(requestCode, resultCode, data);

        if (requestCode == Camera.REQUEST_TAKE_PHOTO) {

            Bitmap bm = camera.getCameraBitmap(); // <-- Causes null exception

           }
    }

Results in the following error:-
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'android.graphics.Bitmap com.mindorks.paracamera.Camera.getCameraBitmap()' on a null object reference
Library: com.mindorks:paracamera:0.2.2
API: 23
Note: Image is displayed in gallery. getCameraBitmapPath() does return a valid file path

@caphson
Have you build the camera and retained the reference in the global class variable?


Add support for icu_collation_keyword field type

Description
This PR adds support for the icu_collation_keyword field type.
Currently, if you have this common plugin enabled, and on an index mapping it will cause an error Missing Required Property Builder.<variant kind> when using getting templates or mappings.
Issues Resolved
https://github.com/opensearch-project/opensearch-java/issues/721
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Thank you @Bfindlay !


feat(emulator): bump from version 1.5.0 to 1.5.9

Same change as done in Sage here: https://github.com/einride/sage/pull/461
The emulator now supports ON DELETE CASCADE. This is needed when bumping cloud.google.com/go/spanner to v1.48.0 or beyond as it now automatically inserts the default ON DEFAULT NO ACTION clause (see https://github.com/googleapis/google-cloud-go/pull/8296).
Include the dependabot PR #470 that bumps spanner library to 1.49.0 while at it.

Codecov Report

Merging #471 (72d3a37) into master (762bfd8) will decrease coverage by 1.94%.
Report is 172 commits behind head on master.
The diff coverage is 25.18%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@            Coverage Diff             @@
##           master     #471      +/-   ##
==========================================
- Coverage   44.66%   42.73%   -1.94%
==========================================
  Files          21       20       -1
  Lines        4267     4563     +296
==========================================
+ Hits         1906     1950      +44
- Misses       2249     2504     +255
+ Partials      112      109       -3

Files Changed
Coverage Δ

internal/examples/freightdb/descriptor_gen.go
0.00% <0.00%> (ø)

internal/examples/musicdb/descriptor_gen.go
5.55% <0.00%> (-1.47%)
:arrow_down:

spanddl/table.go
29.46% <0.00%> (ø)

internal/examples/musicdb/database_gen.go
17.20% <6.29%> (-3.57%)
:arrow_down:

internal/examples/freightdb/database_gen.go
23.28% <41.37%> (+0.07%)
:arrow_up:

internal/codegen/databasecodegen/common.go
100.00% <100.00%> (ø)

...nternal/codegen/databasecodegen/readtransaction.go
100.00% <100.00%> (ø)


Different behaviour running the application as a Windows Service

Running the example inside a Windows Service the synchronization doesn't seem to work, here's the output:
DownloadDocsMainPageAsync: About to start downloading.
Main: Launched downloading.
and that's it.
(the await operator has a different behaviour in this case)

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

ID: 07164632-3cf8-864e-cd1e-485b73ed95a0
Version Independent ID: 67bfb75a-8dd8-ecf3-ce15-2a531833e8b5
Content: await operator - asynchronously wait for a task to complete
Content Source: docs/csharp/language-reference/operators/await.md
Product: dotnet-csharp
Technology: csharp-language-reference
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Hi @Gix65
Can you post a snippet from the service? I'm not sure what's causing the difference.

Hi,
I just added the class

public static class AwaitOperator    {        public static async Task
Main()        {            Task downloading =
DownloadDocsMainPageAsync();            Log.traceAlways($"{nameof(Main)}:
Launched downloading.", ref ReadMyParameters.parametri);            int
bytesLoaded = await downloading;
Log.traceAlways($"{nameof(Main)}: Downloaded {bytesLoaded} bytes.", ref
ReadMyParameters.parametri);        }        private static async Task
DownloadDocsMainPageAsync()        {
Log.traceAlways($"{nameof(DownloadDocsMainPageAsync)}: About to start
downloading.", ref ReadMyParameters.parametri);            var client = new
HttpClient();            byte[] content = await
client.GetByteArrayAsync("https://docs.microsoft.com/en-us/
https://docs.microsoft.com/en-us/");
Log.traceAlways($"{nameof(DownloadDocsMainPageAsync)}: Finished
downloading.", ref ReadMyParameters.parametri);            return
content.Length;        }    }*

to my Windows service project (Log.traceAlways() simply writes a row in a
log file), added the call to Main() into the InitInstance() method:

   public void InitInstance() {*

-- some stuff
AwaitOperator.Main();
--some other stuff
}
started the service and the result in the log file was only:
002 09/12/2022 09:36:51.268  - DownloadDocsMainPageAsync: About to start
downloading.
003 09/12/2022 09:36:51.289  - Main: Launched downloading.
It seems that the await operator doesn't "wait" at all.
Making the call elsewhere in the code gives the same result
Il giorno gio 8 dic 2022 alle ore 15:54 Bill Wagner <
@.***> ha scritto:

Hi @Gix65 https://github.com/Gix65
Can you post a snippet from the service? I'm not sure what's causing the
difference.
—
Reply to this email directly, view it on GitHub
https://github.com/dotnet/docs/issues/32944#issuecomment-1342855812, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/A4T7FQG2APEXQJL6DUJBHLLWMHZBFANCNFSM6AAAAAASXJ22D4
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thanks for adding that @Gix65
In this instance, you need to make sure to wait (synchronously) for the Asynchronous work to finish.  Your InitInstance method should look like this:
public void InitInstance()
{
    // *-- some stuff*
    AwaitOperator.Main().GetAwaiter().GetResult();
    // *--some other stuff*
}

You can read more about how this works here


Demo site is not working

Hi,
it seems like most of the providers do not work anymore. I have tried, Google (redirect_uri_mismatch), Facebook, Github.

Yeah, I need to update all Redirect URIs now that Satellizer is hosted on OpenShift instead of Heroku.

Any update on this? Thanks :)

All demos (except possibly Twitch) should be working now on https://satellizer-sahat.rhcloud.com.


[GURPS 4E] 2.9.11

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description

Shotgun Damage Tool. Changed the title, added some additional tooltips, and moved the DR multiplier note next to the damage roll.
Spell Roll Chat Log. Streamlined some of the content so spells take up a little less space.
List of minor changes: roll results notes font size changed from 13px to 12px.
Moved the custom success/fail messages for spells just below the roll result in chat dialog.
Fixed bug where repeating languages were not calculating correctly.

Character Sheet Info Roll20 Internal Use only.


nixos/nextcloud: disable output buffering

Description of changes
The Nextcloud admin guide says that output buffering must be turned off or otherwise PHP will return memory-related errors 1. As the default value for this PHP setting is 4096 and thus enabled the Nextcloud setup is thus misconfigured by default. This misconfiguration will be shown in the "Security & setup warnings" dialog for the administrator.
Fix this misconfiguration by setting "output_buffering=0" by default.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Thank you! I haven't had the time to take a look, but I've also seen the warning in the admin panel.
Will try to review it later today :)

Someone has an idea why this only popped up now? The php.ini file didn't change for a long time and the nextcloud check was only refactored in 28 and the condition very similar to 27.


assignment_03 python and JSON file

Checklist

[x] Paste a screenshot of the solution whenever possible (ctrl+v or cmd+v directly on this textbox works)
[x] Add optional notes/remarks to be taken into account for evaluating the submission

assignment_03 with both python and JSON file


GoogleStorageDriver does not handle service account HMAC credentials

Hello,
GoogleStorageDriver may use S3-compatibility layer credentials to connect to GCS. There are at least two ways to generate such credentials:

As User Account HMAC keys. This is inconvenient for services configuration because it ties access to the existence of a user account.
As Service Account HMAC keys. These should be used for long running services.

Unfortunately, GoogleStorageDriver does not identify the second type correctly. The problematic code is here:
https://github.com/apache/libcloud/blob/trunk/libcloud/common/google.py#L615
It checks the identifier starts with "GOOG" which is true in my case, but my identifier is 61 characters long, way above the 30 characters check.
Callers may force the driver to identify the credentials as GCS_S3, but it requires some digging in the class hierarchy. You need to:

Override _ex_connection_class_kwargs to return {"auth_type": "GCS_S3"}, to pass it to connectionCls. But this is not enough.
Pass auth_type="GCS_S3" to GoogleStorageDriver so that jsonConnectionCls is correctly instantiate.

I find the need for both fix a little weird, I would have expected the first one to be enough, but I do not know libcloud internals to have a relevant opinion.
I would just drop the max length check.
Thanks.

The key length was set to 20 in 2015 and bumped to 20-30 in 2018. I agree that dropping the length check altogether would be nice.
cc @crunk1 @MonsieurV @vdloo

Yep, I also agree on dropping the length.
It made sense when we had a unique length for the keys - to ensure we were getting the right key format. Now that Google keeps updating the key length, it won't be maintainable as it. Checking the key prefix should be enough.

@MonsieurV Yeah, a PR with that change (+ tests) would be great.

@MonsieurV and if you get a chance to work it in the next couple of days, I'll also try to include in the upcoming v3.0.0 release.

@Kami should be good :)

This issue can now be closed. Thanks!

Resolved via #1440.
Thanks again to everyone involved :+1:


Advised to change KGP-added testSuiteNameApi dependency on kotlin-stdlib to testSuiteNameImplementation with JVM Test Suite Plugin

Build scan link
https://scans.gradle.com/s/dbkbjeg4dv4og/
Plugin version
1.27.0
Gradle version
8.5
JDK version
<IP_ADDRESS>
(Optional) Kotlin and Kotlin Gradle Plugin (KGP) version
1.9.21
(Optional) Android Gradle Plugin (AGP) version
N/A
(Optional) reason output for bugs relating to incorrect advice
PS C:\Dev\Repos\SDKotlin\sd-kotlin-talks> .\gradlew :di-with-koin:reason --id org.jetbrains.kotlin:kotlin-stdlib
Configuration on demand is an incubating feature.
Calculating task graph as no cached configuration is available for tasks: :di-with-koin:reason --id org.jetbrains.kotlin:kotlin-stdlib
Type-safe project accessors is an incubating feature.

> Configure project :di-with-koin
w: ATTENTION: 'kotlin.experimental.tryK2' is an experimental option enabled in the project for trying out the new Kotlin K2 compiler only.
Please refrain from using it in production code and provide feedback to the Kotlin team for any issues encountered via https://kotl.in/issue

> Task :di-with-koin:compileIntegrationTestKotlin
w: Language version 2.0 is experimental, there are no backwards compatibility guarantees for new language and library features

> Task :di-with-koin:compileTestKotlin
w: Language version 2.0 is experimental, there are no backwards compatibility guarantees for new language and library features

> Task :di-with-koin:reason

----------------------------------------
You asked about the dependency 'org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21'.
There is no advice regarding this dependency.
----------------------------------------

Shortest path from :di-with-koin to org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21 for integrationTestCompileClasspath:
:di-with-koin
\--- io.insert-koin:koin-core-jvm:3.5.0
      \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21

Shortest path from :di-with-koin to org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21 for integrationTestRuntimeClasspath:
:di-with-koin
\--- io.insert-koin:koin-core-jvm:3.5.0
      \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21

Shortest path from :di-with-koin to org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21 for compileClasspath:
:di-with-koin
\--- io.insert-koin:koin-core-jvm:3.5.0
      \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21

Shortest path from :di-with-koin to org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21 for runtimeClasspath:
:di-with-koin
\--- io.insert-koin:koin-core-jvm:3.5.0
      \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21

Shortest path from :di-with-koin to org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21 for testCompileClasspath:
:di-with-koin
\--- io.insert-koin:koin-core-jvm:3.5.0
      \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21

Shortest path from :di-with-koin to org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21 for testRuntimeClasspath:
:di-with-koin
\--- io.insert-koin:koin-core-jvm:3.5.0
      \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.9.21

Source: main
------------
(no usages)

Source: test
------------
(no usages)

Source: integrationTest
-----------------------
(no usages)

##### 'kotlin.experimental.tryK2' results #####
:di-with-koin:compileIntegrationTestKotlin: 2.0 language version
:di-with-koin:compileTestKotlin: 2.0 language version
##### 100% (2/2) tasks have been compiled with Kotlin 2.0 #####

BUILD SUCCESSFUL

Describe the bug
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':buildHealth'.
> Advice for :di-with-koin
  Existing dependencies which should be modified to be as indicated:
    integrationTestImplementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.21") (was integrationTestApi)

To Reproduce
Steps to reproduce the behavior:

gradlew buildHealth on https://github.com/sdkotlin/sd-kotlin-talks/tree/a7571fc464831fc23124e52cd8ce0fc445339326.

Expected behavior
No advice for org.jetbrains.kotlin:kotlin-stdlib
Additional context

#1026
https://youtrack.jetbrains.com/issue/KT-63285/KGP-Deprecate-and-remove-testApi-configuration
https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html

Just an update, I retested with 1.30.0 and KGP 1.9.22, and the issue still presents.
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':buildHealth'.
> Advice for :di-with-koin
  Existing dependencies which should be modified to be as indicated:
    integrationTestImplementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.22") (was integrationTestApi)

Given this and prior issues, I'm stuck on 1.22.0 pending a fix here or upstream (KT-63285).

Some additional findings and developments...
One thing I forgot to mention before is that staying on 1.22.0 has kept us stuck on Kotlin 1.9.0, as we'd seem to hit an incarnation of #884 if we tried to upgrade Kotlin to any newer version. This is with Gradle 8.5, DAGP 1.22.0, and Kotlin 1.9.23:
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':mymodule:mysubmodule:synthesizeDependenciesTest'.
> A failure occurred while executing com.autonomousapps.tasks.SynthesizeDependenciesTask$SynthesizeDependenciesWorkAction
   > C:\Dev\Repos\myproject\mymodule\mysubmodule\build\reports\dependency-analysis\test\dependencies\() -> kotlin.Any?.json (The filename, directory name, or volume label syntax is incorrect)

Now, after some build changes to associate my test suite and test fixtures compilations (so Kotlin internal elements in the test fixtures can be accessed from the various test suites in the same Gradle module), I'm suddenly hitting something similar with version 1.22.0, even with Kotlin 1.9.0 (still Gradle 8.5):
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':myothermodule:synthesizeDependenciesTest'.
> A failure occurred while executing com.autonomousapps.tasks.SynthesizeDependenciesTask$SynthesizeDependenciesWorkAction
   > C:\Dev\Repos\myproject\myothermodule\build\reports\dependency-analysis\test\dependencies\() -> java.io.File?.json (The filename, directory name, or volume label syntax is incorrect)

So it looks like I can't stay on version 1.22.0 after all.
At this point it seems like my best remaining option is to upgrade to 1.30.0, which allows me to upgrade Kotlin, but then switch from onIncorrectConfiguration { severity("fail") } to onIncorrectConfiguration { severity("warn") }.
This is a shame, as we'll surely not stay on top of incorrect configurations as well if we're not failing our CI build on them, particularly with them obscured by what is currently 180 testSuiteApi-related warnings.
It looks like KT-63285 keeps getting bumped to later versions—first 2.0.0-Beta3 → 2.0.0-Beta4, then  2.0.0-Beta4 → 2.0.0-Beta5, now 2.0.0-Beta5 → <IP_ADDRESS>.0-Beta5 → <IP_ADDRESS>.0-Beta5 → 2.0.20—so I'm not sure when we'll be able to count on that for a solution.

To see if it would be possible to keep onIncorrectConfiguration { severity("fail") } set for my build by ignoring test analysis, I tried setting systemProp.dependency.analysis.test.analysis=false in my 'gradle.properties' per the FAQ. I'm still getting used transitive dependencies and incorrect configuration advice for all my custom test suites. Version 1.30.0, Gradle 8.5.

I think you should use the latest version of DAGP, along with one of two options:

Manually exclude the stdlib using exclude(/* coordinates */) (there's no need to downgrade from fail -> warn)
Tell KGP to stop adding the stdlib by default. (code snippet below)

# gradle.properties
kotlin.stdlib.default.dependency=false

In my opinion, DAGP is providing correct advice. The problem is that the advice often conflicts with the default behavior of KGP. I'm not inclined to add special handling for KGP / the Kotlin stdlib.
I'm going to close this issue.

Long-overdue verification follow up: Over time I confused #1026 and this issue. Once I updated to the latest DAGP version, added the stdlib exclude suggested above, and added ABI exclusions for my custom JVM Test Suite Plugin source sets per #1026, then I got to green with buildHealth. Thanks!
Now I'm trying to update my work project with that same configuration from Kotlin 1.9.25 to 2.0.20-RC2, and with no other changes I'm getting a slew of incorrect configuration warnings again. Unfortunately, it doesn't seem to reproduce in my toy project. I'll file a new issue if I can't figure out what's going on.

Possible partial #1026 regression with Kotlin 2.0.20-RC issue filed: #1239.


bump the grpc-js version and increase message sizes

Closes #1458. Since I've run into #1458 once again, I did a search through grpc-node. This PR:

[x] bumps the version of grpc-js, though this did not solve the issue directly
[x] bumps grpc.max_receive_message_length and grpc.max_send_message_length to 1G. It's a lot, but as discussed in #1458, the Apalache integration may return a very large JSON file. I believe a proper solution would be to figure out, why this JSON result is required, and figure out compression in GRPC.
[x] Entries added to the respective CHANGELOG.md for any new functionality

Hi Igor! Last time I had to increase the message size, I had to do it in Apalache's side (see https://github.com/apalache-mc/apalache/pull/2847/files). Does this work without changing Apalache?

Hi Igor! Last time I had to increase the message size, I had to do it in Apalache's side (see https://github.com/apalache-mc/apalache/pull/2847/files). Does this work without changing Apalache?

Yes, it worked for me. If it breaks on sending messages, we can also bump it in Apalache

Ok then! I guess, if we end up needing to bump Apalache, we can revert this one. But if it is working for you, then it should not be necessary 😄

I think you have to merge this PR, I don't have any buttons to click

Right! Sorry. Merging now.


How does correlation work from a Http Trigger to a service bus trigger

Hey, we're having trouble with getting correlation working between a http trigger and a service bus and had some questions.
Within the same function app, we have a http trigger that puts a message onto the queue and a service bus trigger that consumes the message. The logs from each of the functions are separate, in their own operation. But we were hoping app insights would correlate the two. The dependency of the service bus is also not showing up on the app insights application map.
After the service bus trigger has processed the message, it is added to a second queue, a timer trigger consumes multiple messages from the second queue. Is there a way we can correlate the logs from the individual messages from the timer trigger to the original http trigger?
We have tried wrapping the two functions in a context propagating http and service bus trigger. We have also tried setting the correlationId of the service bus message to the operationId of the first function (http function). Neither has helped correlate the two logs.
sender http trigger:
await this.queue.send({
	body: {
		...queueRecord,
		operationId: getOperationId(context)
	}
	correlationId: getOperationId(context),
});

Are we missing anything here? how does a service bus message handle correlation internally and why don't they show up in app insights map? Thanks @markwolff

Automatic Service Bus (and Functions) integration isn't something that is supported right now, and so it will need to be done manually.
https://github.com/microsoft/ApplicationInsights-node.js#azure-functions
You can use this SDK's startOperation fn to start an AI context from your Function, and then you will need to inject/extract the trace context to/from the body of your messages

@MohammedFoysal let us know if you still have issues with this after adding code Mark shared


Update scroll-bar look and feel in API Docs

Purpose

This PR will update the look and feel of the scroll-bar in API Docs

Check List

[ ] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@58cb4c1). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master   #17193   +/-   ##
=========================================
  Coverage          ?   14.32%
=========================================
  Files             ?       51
  Lines             ?     1578
  Branches          ?      255
=========================================
  Hits              ?      226
  Misses            ?     1339
  Partials          ?       13

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 58cb4c1...c66d285. Read the comment docs.


Header as a HDF5 compound datatype

HDF5 has the capability to create a HDF5 compound dataset, which is analogous to a C struct.
https://portal.hdfgroup.org/display/HDF5/Datatype+Basics#DatatypeBasics-compound
https://api.h5py.org/h5t.html#compound-types
It may be possible to also construct this from a NumPy record. I suspect it may be easier to use the low-level API from the CSV files that you created.

h5py then provides the ability to read individual fields directly.
https://docs.h5py.org/en/stable/high/dataset.html?highlight=compound#reading-writing-data

Presumably this would end up very close to Davis' approach here? https://github.com/janelia-cosem/fibsem-tools/blob/f4bedbfc4ff81ec1b83282908ba6702baf98c734/src/fibsem_tools/io/fibsem.py#L81

I was thinking of this as a way to encode the jeiss-convert tsv files as a datatype in HDF5 itself. In the worse case scenario, one could always use H5Dread to just read the bytes giving uint8 as the memory type, which is the status quo.
Many packages support compound datatypes. Perhaps the most common use of compound datatype is complex numbers.
Java: https://bitbucket.hdfgroup.org/pages/HDFFV/hdf5doc/master/browse/html/javadoc/index.html?hdf/hdf5lib/H5.html
MATLAB: https://www.mathworks.com/help/matlab/import_export/import-hdf5-files.html
Julia: https://juliaio.github.io/HDF5.jl/stable/#Supported-data-types

JHDF5 which is currently used by the Java tools BigDataViewer and SciJava (FIJI, etc.) has a compound datatype reader here:
https://svnsis.ethz.ch/doc/hdf5/hdf5-19.04/ch/systemsx/cisd/hdf5/IHDF5CompoundReader.html

@clbarnes , let me know if you have time to chat for a few minutes. One concern about embracing HDF5 for this is that we're not sure if this works for everyone at Cambridge. Albert in particular seemed to prefer text based attributes via JSON or similar.

I actually have a fork which writes to zarr, which is exactly that - a JSON file for the metadata, plus a npy-esque binary dump (which can be chunked). Zarr is getting a lot of attention but the spec is anticipated to change some time soon, in a way which will make it less convenient for this sort of thing.
I'm flexible for the rest of the week if we can figure out time differences! I'm in BST.

Yes, I participated in the discussion on the Zarr shard specification that should be part of v3:
https://github.com/zarr-developers/zarr-python/pull/876#issuecomment-985831774
It looks like a HDF5 file with an extra linear dataset could also be a Zarr shard.
Extracting that indexing from HDF5 should be quite fast if we use H5Dchunk_iter currently in HDF5 1.13 or or the h5ls command line utility:
https://docs.hdfgroup.org/hdf5/develop/group___h5_d.html#gac482c2386aa3aea4c44730a627a7adb8
Another extreme is https://github.com/HDFGroup/hdf5-json
Nonetheless, once we have the data in one standard format, I do not mind investing in tooling to move between standard formats or using something like kerchunk. The best part is that tooling may already exist.

My Friday morning / your Friday afternoon is the easiest match. I just sent an invite for a Zoom at 9 am EST / 2 pm BST to your cam.ac.uk address. Let me know if that works. Later that day also works.

I have an implementation of this with a convenient Mapping wrapper, which round-trips correctly through bytes. What I'm trying to figure out now is where it fits with the rest of program as it currently stands - if the header is written into the HDF5 as this compound dtype array, do we still want to encode the same metadata as attributes, which is the more HDF5-y way to do it? That duplication concerns me a bit. If not, then we've made the attributes a bit more awkward to access. Is having today's header encoded byte-for-byte in the HDF5 file a goal in its own right?
It also gets more complicated to add the zarr/n5 implementations, which don't support compound dtypes (to my knowledge). In these cases, you'd need to serialise the metadata as attributes anyway (which, again, is more convenient for downstream users anyway). I'm not entirely convinced zarr/n5 support is a good way to go anyway - keeping everything contained in the same file and having a single supported workflow from proprietary to open format is of benefit, and given that these files will almost certainly require post-processing, downstream users can write to other formats at that stage if they want.

Is having today's header encoded byte-for-byte in the HDF5 file a goal in its own right?

This was a stated goal of the last round to help ensure round trip durability. Originally it was just going to be an opaque datatype or byte stream, but I realized that we may be able to do better with the compound datatype. We do not want to depend on someone bumping the version number or the accuracy of the reader's table of offsets and types in order to preserve the header.
One option might be to save the 1 KB header as a separate file for reference. For Zarr this might just be an opaque block of bytes. N5 has N5-HDF5 backend that may be able to take advantage of the compound datatype.

My current implementation does store the raw header as well as the exploded metadata values, without using the compound dtype. For HDF5, there is a u8 attribute "_header" (as well as "_footer"); for the N5 and Zarr implementations in the PR, these are hex-encoded strings (open to using base64 as well). The tests round trip from the exploded values, rather than relying on the byte dump.
The compound dtype is just calculated from the table of offsets and dtypes so isn't any more robust in that respect. I don't think there's a better way to do that which doesn't just duplicate the information and introduce a new source of error. The reader doesn't need to explicitly state the version as it's read from the metadata, and (in my implementation anyway) will fail if the version's spec isn't known.


Expand numerous _cargo compdef options

This pull request fixes two distinct issues with the _cargo compdef:

Tab-completion should supply --color= options (none, auto, and always)
Updates the deprecated "command scope flags" which now have a single, unambiguous representative variable which provides the appropriate exclusivity between options.

r? @wycats
(rust_highfive has picked a reviewer for you, use r? to override)

r? @alexcrichton

@bors: r+ a0d687c1ef1b61a5caaa6015260bb61e76f050a2
Thanks!

:hourglass: Testing commit a0d687c with merge 1e97e2d...

:sunny: Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64


Hooks aren't called each time with retrying

Summary.
Hooks aren't called on each retry, only at the end of retrying
requests==2.18.4
requests-oauthlib==0.8.0
Is this intended functionality, how do I get a hook called on each retry? Here is my code
retries = Retry(total=2,
                backoff_factor=0.1,
                status_forcelist=[404],
                raise_on_status=False
                )

self.gbdx_connection.mount(self.root_url, HTTPAdapter(max_retries=retries))

self.gbdx_connection.hooks['response'].append(refresh_token)

Using the Retry object means you're interacting with urllib3. Hooks are handled only in Requests. There's no plan to make hooks fire on retries inside of urllib3 when urllib3 doesn't have the concept of hooks.

@sigmavirus24 doh that makes sense


[Bug] Unable to create a connection successfully if a graph databases contains only vertices and no edges

Community Note

Please use a 👍 reaction to provide a +1/vote. This helps the community and maintainers prioritize this request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Describe the bug
Tested this with Neptune db. I created vertices on the db with no edges in gremlin format. Then trying to create connection from graph-explorer, the connection was not successful. Misleading error gives as unable to connect with database but while debugging the backend error is:
{
code: 'MalformedQueryException',
detailedMessage: "Failed to interpret Gremlin query: Query parsing failed at line 1, character position at 14, error message : no viable alternative at input 'g.E().project()'",
requestId: '3b949d91-2969-4602-9aee-ec1d6e363eed'
}

Expected behavior
There should be a clear error from the UI as to what is happening. Also this should not fail a connection as nodes can still be displayed without edges on Graph Explorer.
Currently errors like above are not logged visibly in the proxy code. Hence needs debugging to find the actual errors. I would recommend checking the response code and log the errors on the console.

Just a comment that g.E().project() is not valid Gremlin either. The Graph Explorer  code should check the edge count and if it is zero not try to enumerate the edges. We also need to look at why invalid Gremlin is being generated by the Explorer in this case. It's quite possible that the lack of edges not being caught is the root cause.

I attempted to reproduce this issue, but could not.
I also looked at the code and it seems like there are protections against this happening.
https://github.com/aws/graph-explorer/blob/c8bb106ffae6c75893f02520f3cd4cce87ab2349/packages/graph-explorer/src/connector/gremlin/queries/fetchSchema.ts#L183-L185
This must've been an issue from long enough ago where there sync process could somehow reach this state. But from what I can see, this bug has been fixed.


‘#x’ hex format

Please consider supporting the ‘#x’ hex format.
E. g.:
    addr EQU #1234 ; = 4660 dec
    ld a, #FF      ; =  255 dec

The ‘#’ character is a valid prefix for hexadecimal numbers in SjASMPlus and some other Z80 assembly dialects.
SjASMPlus docs. Numeric constants

I really like how you handle #1234, because it means decimal 1234 for my usecase. #$1234 will be interpreted as HEX for my usecase (ca65).


fix: update golang to 1.19

update golang to 1.19 to allow for easier recompile using boringcrypto added to main in 1.19. Also moved from alpine to just regular golang to standardize between capsule and capsule-proxy.

LGTM @slimm609 but I wouldn't define this as a fix, rather, deps as a semantic commit subject.
The GH changes could be marked as chore(github).
Once amended commit messages, ready to get it merged.

rebased and amended into multiple

@prometherion this should be good now


#509 Hartshorn Web MVC API and default FreeMarker implementation

Fixes #509
Motivation
With the earlier introduction of Hartshorn Web which added support for RESTful API controllers, the next obvious step would be Model-View-Controller, or simply MVC, support.
MVC design has three main entry points, which as suggested by the name are the model, the view, and the controller.

The model is the domain object that represents your data
The view is the web page presenting your application to the user
The controller is the service controlling your page (e.g. populating views for specific states)

The idea for MVC controllers is similar to that of REST controllers, with one main exception; they do not serve the content directly, and instead only populate. The content they populate is based on a template, or ViewTemplate specifically which is populated using a ViewModel:
@MvcController
public class HelloWorldController {

    @HttpGet("/hello")
    public ViewTemplate helloWorld(ViewModel model) {
        model.attribute("name", "User");
        return new StringViewTemplate("
Hello ${name}!
");
    }
}

The endpoints are defined in the same way REST endpoints are defined, with the same support for header and request parameters. The method should always return a ViewTemplate which indicates where the view is located. Finally, the ViewModel represents the model of the page, where each attribute can carry primitives and POJOs/entities which can be displayed on the actual view.
I have added a default implementation using FreeMarker, which shows the power of the API as only a single class is required to implement FreeMarker support. Support for Thymeleaf is scheduled at a later time.
Type of change

[x] New module

How Has This Been Tested?

[x] Integration testing (modern web browsers)

Checklist:

[x] I have performed a self-review of my own code
[x] New and existing unit tests pass locally with my changes

DS Analysis issues were resolved in #515


Added "innr" brand, 2 only-brightness models

but please check carefully before merge - probably I've outdated fork and I've done some stupid things trying to ressolve situation, so I'm not sure is it safe to merge.

I have added validation for the lut files. In the latest version every csv file must have a header. See the readme or check one of the other brightness files.
Could you resolve that please?
I'll will check the changes before merging and squash/rebase commits so we don't het tons of commits in the master branch.

New files have header, and they are tested in working installation, so they should pass this check
but I'm worried that the merge won't repeat my mistakes ouside "innr" folder.

I Will have a look into this tomorrow.

BTW
I've bought Shelly plug S and it will be delivered in a week or two, so I will try to use script to measure some white spectrum bulbs and some color bulb/lamps models.

Yes, it's a big messy because you did not pull upstream changes first, and you commited the old readme and old versions of two hue light bulbs.
Looks like you are using the github site editor and upload function to create your commits.
Better would be to download a git GUI on your machine. Then you can make the changes, review them, add them to be commited and than commit everything in a single commit. I am using the git command Line, but when you are not proficiant yet with git a gui would be easier.
I would suggest for easy resolving the following steps.

first copy the innr directory to a backup location.
Remove the fork and create a new one (this way your are synced with upstream, my repo). This can be done on the github site
Next download a git GUI. Clone your fork using the gui (now you have your fork on your local machine).
Create a new branch.
Copy the innr directory back to your local fork directory.
Stage the new innr files and create a new commit.
Push your changes.
now you can make a new pull request using the github site.

BTW
I've bought Shelly plug S and it will be delivered in a week or two, so I will try to use script to measure some white spectrum bulbs and some color bulb/lamps models.

Cool! let me know if you got it working or you need any help.

Btw the validation errors are for LWB010 and LWB004. That's because your commit contains the old versions of these files which did not contain the headers yet. This can be resolved using the procedure I described above. Your new files pass the validation.

Corrected in new PR.


index not being passed to child element accessors

Not sure if this is a bug or expected behavior, but when I run the following code it prints out 0 for each index (CodePen):
var p = d3_selection.select("body").selectAll(".parent").data([0, 1]);

var enter = p.enter().append("div").attr("class", "parent")
enter.append("div").attr("class", "child");

p = p.merge(enter);

p.selectAll(".child").style("color", function(d, i) {
    console.log(d, i);
    return "red";
});

I'm assuming that's because each child element is the first index inside of their respective parents? Is there a way to get the index of the original data array?

I'm assuming that's because each child element is the first index inside of their respective parents?

Yes, this is expected. See How Selections Work and Nested Selections.
If there’s only one child for each parent, the simplest way to preserve the child index (and to propagate the data from the parent to the child) is to use selection.select rather than selection.selectAll.
p.select(".child").style("color", function(d, i) {
  console.log("child data and index", d, i);
  return "red";
});

If there are multiple children for each parent, one option is to add the parent’s index to the children’s data (which is basically what you are already doing with d instead of i). Or you can use selection.each to create a context where you can access both the parent’s data and index, and the child’s data and index, simultaneously:
p.each(function(p, j) {
  d3_selection.select(this).selectAll(".child").style("color", function(d, i) {
    console.log("parent data and index", d, i);
    console.log("child data and index", d, i);
    return "red";
  });
});

Of course, selection.select is the simplest option for 1-to-1 relationships between parent and child.

Thanks for the thorough response!


Notify when changing the type to/from building

Hello
I've noticed that in 3.1 the next behavior: if we have a building and want to add tag for a whole building (for example, add tourism=hotel) with upper menu (where we can change tag), building tag will be overwritten. On the earlier versions, the app only added tag (building=yes AND tourism=hotel). Maybe I missed something or don't know, but it's confusing

Yeah, you write it yourself: "where we can change tag". Change from the current object type to something else. In your case, from a building to a hotel.
I agree that's not idea. In case of buildings, I maybe should split their treatment from amenities they host.

Maybe, to add a pop-up in this type of changing? Because there are only ways to add manually or to add as a node for exact this case
Also, I didn't expect such changes in a minor version

Okay this notification would be useful I think. There are those options when changing the type:

Proceed with changing the type (is there a real world use case for this?..).
Add the type to the building instead (may lead to issues?).
Add a node to the building center instead.
Cancel changing type.

Changing the building type on amenity type, for example, is such a niche case. Maybe to suggest "Tag will be applied for the whole building. Are you sure?"

Another option came up: see #644 for an easier way of adding an amenity to a building or an address node.

Note: there are no building presets in the app, so the issue applies only to building→amenity transition.

Decided to simply forbid changing building to another type (already in 4.0), and to use #644 for a process of adding amenity tags to a building.


Add a blog post about ebpf internals

A blog post covering the basics of eBPF internals as well as code samples in Go on how to build and load a minimal eBPF program into the kernel.

Thanks for adding tutorial about ebpf.
But i think there are not need to delete original post.

But i think there are not need to delete original post.

Sorry, I'm not sure what did you mean.

Emm,in my view you delete [Extending extended BPF] string also.I am not sure about this maybe broswer issue.sorry about confusion.

This is what github's diff reflects:

Also, if you navigate to the fork of this repo with the changed added, all looks good to me:
https://github.com/rabbitstack/awesome-ebpf

Got it.
Thanks again.

@yuzibo good to merge?

Sorry for late reply.
I have no permission to merge the RP.
But i think we can @zoidbergwill

no worries. Let's wait for @zoidbergwill

👍 for merging this :)

Looks good to me. Thanks for your contribution. :+1:


How do you compute hash of user data?

Hi,
From the solidity code kyc.sol, I can see that inside struct 'Customer' user information is stored as a hash.  But I cannot see piece of logic wherein this hash is computed and then stored to this struct. Can you please help to highlight the relevant piece of code which performs this action?
Best Regards

For the trial run, we had passed the complete user information as a single string as of now. But we can also use the RSA encryption protocol provided in the file RSA_JS by calling the encryption function (see PS) from this file. Since the trial run had smaller strings to store, to avoid complications, we had removed the RSA encryption part.
PS: Refer to RSAEncrypt() in this file.


Upgraded dragen workflows to use multiqc v1.13dev

To do list:

[x] Merge #80
[x] Merge #82
[x] Merge main into this branch
[x] Update project.yaml, workflow.yaml for each workflow changes
[x] Run tests against each workflow and ensure multiqc output looks good.

Testing the following multiqc outputs:
WGS QC Pipeline test
Workflow ID
wfr.ee6d043bda174080b79b32a515715feb
Subject ID
SBJ00910
TN Multiqc 1.13 Test
Workflow ID

wfr.3948f397e6c047a59cabc1a6d9d0f16f

Subject ID
SBJ00915
TO Multiqc 1.13 Test
This workflow is identical to above but with the 'fastq_list_rows' attribute removed
Workflow ID

wfr.178ac135dd1f418ca17d58cdf8a371bc

SubjectID
SBJ00915

Now ready to review

@alexiswl - can you also test Dragen-transcrpitome workflow again the new tool definition (v1.12)?

Running under wfr.9bb5c7d51bfd4f39bba2e01ff4f35448

Yep workflow succeeded and multiqc output is all good


docs: fix and lint-info

you don't need to run npm run build before npm test since npm test lints, builds, and then tests whole app.
added npm run lint-info command which runs tslint

@nicojs done :)

Ok, I'll close this issue and create a new PR for this.


Theano with CUDA support broken

Issue description
Theano with CUDA support is broken:

the dependency pkgs.linuxPackages.nvidia_x11 is missing from Theano and libgpuarray which results in Missing libcuda.so error when importing Theano in Python (see below)
The wrapped g++ which is used by Theano at runtime is not including/linking the necessary libraries which results in errors when you try to run a Theano model

Steps to reproduce
NOTE: To be able to reproduce you need a machine with a NVIDIA GPU. To install the necessary kernel driver on Nixos make sure you have
services.xserver.videoDrivers = [ "nvidia" ];
nixpkgs.config.allowUnfree = true;

in your configuration.nix.
Create a shell.nix
with import <nixpkgs> {}; (python36.withPackages (ps: [(ps.Theano.override { cudaSupport=true; cudnnSupport = true;})])).env

Start a nix-shell from it: $ nix-shell
[nix-shell] $
[nix-shell] $ THEANO_FLAGS='device=cuda,floatX=float32,device=cuda,force_device=True' python3 -c 'import theano'

ERROR (theano.gpuarray): Could not initialize pygpu, support disabled
Traceback (most recent call last):
  File "/nix/store/vlxn4qd6s99i30p1l4phnvc1kcj7clyc-python3-3.6.4-env/lib/python3.6/site-packages/theano/gpuarray/__init__.py", line 227, in <module>
    use(config.device)
  File "/nix/store/vlxn4qd6s99i30p1l4phnvc1kcj7clyc-python3-3.6.4-env/lib/python3.6/site-packages/theano/gpuarray/__init__.py", line 214, in use
    init_dev(device, preallocate=preallocate)
  File "/nix/store/vlxn4qd6s99i30p1l4phnvc1kcj7clyc-python3-3.6.4-env/lib/python3.6/site-packages/theano/gpuarray/__init__.py", line 99, in init_dev
    **args)
  File "pygpu/gpuarray.pyx", line 651, in pygpu.gpuarray.init
  File "pygpu/gpuarray.pyx", line 587, in pygpu.gpuarray.pygpu_init
pygpu.gpuarray.GpuArrayException: b'Could not load "libcuda.so": libcuda.so: cannot open shared object file: No such file or directory'

Technical details

system: "x86_64-linux"
host os: Linux 4.14.32, NixOS, 18.03pre131740.09bca91e3b5 (Impala)
multi-user?: no
sandbox: yes
version: nix-env (Nix) 2.0
channels(root): "nixos-18.03.131953.cc95cbed4a2"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

Build succeeds on nixpkgs-unstable: https://hercules-ci.com/accounts/github/SomeoneSerge/derivations/%2Fnix%2Fstore%2F13vzma3n1ahn2kvfpbgaxz3ra89p09bs-python3.10-Theano-1.0.5.drv?via-job=5db289ae-240a-40c3-95c3-9eb0566ce090
And on nixos-21.11: https://hercules-ci.com/accounts/github/SomeoneSerge/derivations/%2Fnix%2Fstore%2F7sjwh11r3ig3qsvwqnhvss6vbnp6davi-python3.9-Theano-1.0.5.drv?via-job=8d5ec5c1-0777-48a0-8dff-18df056b0909
Except for python 3.10: https://hercules-ci.com/accounts/github/SomeoneSerge/derivations/%2Fnix%2Fstore%2Fp4wc82jckm5zxvbakqwb2imq16xvcp04-python3.10-Theano-1.0.5.drv?via-job=8d5ec5c1-0777-48a0-8dff-18df056b0909


Handle missing set children more gracefully

See https://tex.stackexchange.com/q/458426/35864
Consider the following MWE
\documentclass{article}
\usepackage{biblatex}
\addbibresource{biblatex-examples.bib}

\begin{document}
\begin{refsection}
  \defbibentryset{test}{nonexistent-key}
  \printbibliography[heading=none]
\end{refsection}
\textcite{sigfridsson}
\end{document}

With an obviously undefined test entry child.
Biber produces the output
INFO - This is Biber 2.12 (beta)
INFO - Logfile is 'kskjhkshjshsksjs.blg'
INFO - Reading 'kskjhkshjshsksjs.bcf'
INFO - Found 0 citekeys in bib section 0
INFO - Found 1 citekeys in bib section 1
INFO - Found 1 citekeys in bib section 0
INFO - Processing section 0
INFO - Looking for bibtex format file 'biblatex-examples.bib' for section 0
INFO - LaTeX decoding ...
INFO - Found BibTeX data source 'C:/Program Files/MiKTeX 2.9/bibtex/bib/biblatex/biblatex-examples.bib'
INFO - Overriding locale 'en-US' defaults 'normalization = NFD' with 'normalization = prenormalized'
INFO - Overriding locale 'en-US' defaults 'variable = shifted' with 'variable = non-ignorable'
INFO - Sorting list 'nty/global//global/global' of type 'entry' with template 'nty' and locale 'en-US'
INFO - No sort tailoring available for locale 'en-US'
INFO - Processing section 1
Use of uninitialized value $alias in hash element at C:\Users\Moritz\AppData\Local\Temp\par-4d6f7269747a\cache-b48fe7ad8eda7c6732ebfb7751532fa7c1d79c99\inc\lib/Biber/Section.pm line 525.
Use of uninitialized value $citekey in hash element at C:\Users\Moritz\AppData\Local\Temp\par-4d6f7269747a\cache-b48fe7ad8eda7c6732ebfb7751532fa7c1d79c99\inc\lib/Biber/Entries.pm line 57.
Can't call method "datafields" on an undefined value at C:\Users\Moritz\AppData\Local\Temp\par-4d6f7269747a\cache-b48fe7ad8eda7c6732ebfb7751532fa7c1d79c99\inc\lib/Biber/Entry.pm line 534.
WARN - I didn't find a database entry for dynamic set member 'nonexistent-key' - ignoring (section 1)

and aborts compilation. The relevant messages don't appear in the .blg file, though. The .bbl is completely empty.
Would it be possible to have Biber handle undefined set children slightly more gracefully? After all one missing entry usually does not stop processing of the entire file.

This was a bug when a dynamic set had non-existent keys removed so that it was completely empty after datasource fetching (adding a good key to the set in the example has no error). Fixed in 2.13 DEV.

Much better with 2.13. Thank you very much.


Fix some links in FranklinDemo

Some links in FranklinDemo were pointing to the archived FranklinFAQ, so I fixed them to point to the correct destinations.

thanks!


RichTextLabel auto-inserts newlines when changing text alignment.

Godot version:
Godot 3.1 alpha 1 - 2 (both)
Issue description:
As mentioned in #23395, when one has text that is justified left and then they add more text that is justified right, the RichTextLabel inserts a newline rather than allowing the text to exist as two columns side-by-side. This is obstructing the implementation of a cleaner UI within the Editor.
Steps to reproduce:
extends RichTextLabel

func _ready():
    push_align(RichTextLabel.ALIGN_LEFT)
    add_text("hello")
    add_text(" world")
    push_align(RichTextLabel.ALIGN_RIGHT)
    add_text("testing")

"testing" appears on a line of its own while "hello world" appears on the same line. Haven't inserted any newlines manually yet.

Still valid in 3.2.4 beta2

Push align no longer exists.


Set a default timeout on sendMessage functions

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

30ms is too short for a http request.


MuP Coord Check not Working with Electra Style Model

I'm trying to use an Electra-Style model with µP but am not able to get a the coord plots to work correctly. Currently, I have Readout layers on both the Discriminator and Generator.
Creating coord checks for the Discriminator and Generator alone seem to work, but when combined the µP plot does not seem as expected.
Generator coord checks:

Discriminator coord checks:

Electra Model coord checks:

Will µP not work for "multi-task" losses like here where the overall loss is a weighted sum of mlm_loss and disc_loss?

Can you clarify how you are combining the generator and discriminator to
get the 3rd set of plots?
On Sun, Nov 6, 2022, 7:15 PM Zach Nussbaum @.***> wrote:

I'm trying to use an Electra-Style model
https://github.com/lucidrains/electra-pytorch with µP but am not able
to get a the coord plots to work correctly. Currently, I have Readout
layers on both the Discriminator and Generator.
Creating coord checks for the Discriminator and Generator alone seem to
work, but when combined the µP plot does not seem as expected.
Generator coord checks:
[image: μp_electra_generator_adam_lr0 001_nseeds5_coord]
https://user-images.githubusercontent.com/33707069/200189965-5985e986-4676-46fa-9d1a-79ced3e862b1.jpg
[image: sp_electra_generator_adam_lr0 001_nseeds5_coord]
https://user-images.githubusercontent.com/33707069/200189966-3de13deb-84be-42aa-aa6a-7c60dcec5158.jpg
Discriminator coord checks:
[image: μp_electra_adam_lr0 001_nseeds5_coord]
https://user-images.githubusercontent.com/33707069/200189979-e6050c63-2dfb-4b51-965c-e23ce451e6bf.jpg
[image: sp_electra_adam_lr0 001_nseeds5_coord]
https://user-images.githubusercontent.com/33707069/200189980-31967b38-f2dd-4545-9954-43552b7c9168.jpg
Electra Model coord checks:
[image: sp_electra_model_adam_lr0 001_nseeds5_coord]
https://user-images.githubusercontent.com/33707069/200190367-03c6f84a-b336-4fc9-8441-17b59d56eff4.jpg
[image: μp_electra_model_adam_lr0 001_nseeds5_coord]
https://user-images.githubusercontent.com/33707069/200190369-7fb44d98-b0eb-4421-87e9-e175dbbe57cf.jpg
Will µP not work for "multi-task" losses like here where the overall loss
is a weighted sum of mlm_loss and disc_loss?
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/mup/issues/27, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMWHHM3NAX233NYF2SNVMQDWG7YVLANCNFSM6AAAAAARYR6MVQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Similar to this, we use the logits from the Generator to sample/replace tokens for the input to the Discriminator. The Discriminator tries to predict which tokens have been replaced

Can you tell me which layers in the 3rd set of plots are seeing exploding
values (already at initialization)?
On Sun, Nov 6, 2022, 7:46 PM Zach Nussbaum @.***> wrote:

Similar to this
https://github.com/lucidrains/electra-pytorch/blob/master/electra_pytorch/electra_pytorch.py#L190-L218,
we use the logits from the Generator to sample/replace tokens for the
input to the Discriminator. The Discriminator tries to predict which
tokens have been replaced
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/mup/issues/27#issuecomment-1304878254, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AMWHHM3343NEEURILYNSTBDWG74KFANCNFSM6AAAAAARYR6MVQ
.
You are receiving this because you commented.Message ID:
@.***>

It looks like the attention layers such as
discriminator.electra.encoder.layer.0.attention.output.dense, discriminator.electra.encoder.layer.0.attention.output.dropout,
discriminator.electra.encoder.layer.0.attention.self.key,
discriminator.electra.encoder.layer.0.attention.self.query
discriminator.electra.encoder.layer.0.attention.self.value,
This seems to be present in the generator layers too. However it seems a bit odd to me that the individual layers seem to blow up but the full layer seems to be constant?
https://docs.google.com/spreadsheets/d/1vd_cVkNAbr0jSLax_IrH4sjjIcanxfOXar6cbYVS3DE/edit?usp=sharing

That's strange because at least the generator should behave the same at
initialization whether you combine it with the discriminator or not,
because the computation it does is exactly the same? Can you clarify what
data is fed in when you combine and when you don't?
On Sun, Nov 6, 2022, 8:28 PM Zach Nussbaum @.***> wrote:

It looks like the attention layers such as
discriminator.electra.encoder.layer.0.attention.output.dense,
discriminator.electra.encoder.layer.0.attention.output.dropout,
discriminator.electra.encoder.layer.0.attention.self.key,
discriminator.electra.encoder.layer.0.attention.self.query
discriminator.electra.encoder.layer.0.attention.self.value,
This seems to be present in the generator layers too. However it seems a
bit odd to me that the individual layers seem to blow up but the full layer
seems to be constant?
https://docs.google.com/spreadsheets/d/1vd_cVkNAbr0jSLax_IrH4sjjIcanxfOXar6cbYVS3DE/edit?usp=sharing
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/mup/issues/27#issuecomment-1304886868, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AMWHHM5ZP22LJ66HMPRRUB3WHABEJANCNFSM6AAAAAARYR6MVQ
.
You are receiving this because you commented.Message ID:
@.***>

I’m using the same data AFAICT. The only difference may be some randomness due to shuffling

@thegregyang sorry for the previous brief comment, I updated with some (hopefully) more useful info

Ok I found the bug in my code! I was doing the _init_weights before set_base_shapes and came across a comment saying that it's needed to be called after set_base_shapes. Thanks for the help pointing me in the right direction 😄 @thegregyang


getModalizer backward incompatibility issue

Our product is micro-frontend alike architecture, there's a host UI project and several guest UI projects that are all built and shipped differently, and all the dependencies are not shared. We discovered an issue during the upgrade of FluentUI v9, which is caused by different versions of tabster in host UI side and guest UI side.
A minimal repro could be found here: https://github.com/KagamiChan/multiple-fluentui-repro
I'm not using codesandbox because I need to use yarn resolutions to lock tabster version, please let me know if you prefer a codesandbox example.
tabster versions:
Host UI: 4.2.0
Guest UI: 4.6.0
main difference for this issue: tabster 4.3.0 introduces queue for initialization: #262
Steps to repro:

click the button to mount guest UI
error throws like below

what happened:

host UI is mounted, and tabster core (v4.2.0) is initialized, while modalizer is not
guest UI trying to mount, FluentUI tries to initialize modalizer, the getModalizer function and ModalizerAPI class is from guest UI (v4.6.0) so it calls tabster isntance's queueInit function
tabster instance is initialized by host UI (v4.2.0) and does not have queueInit function, the exception throws

This issue is blocking us from the Fluent UI upgrade because we have to upgrade host UI everywhere but that would be difficult (our product is not served on web but is embedded), could you please help take a look and help us unblock?

May you please clarify which Fluent version are you using?

If I understand things correctly, you want to use two versions simultaneously with the core of one version and the parts from another version. That wouldn't and shouldn't work. From the public API perspective Tabster should be compatible between the major versions. So, you should add a resolution to 4.6.0 from the host side first. There should be just one copy of Tabster in the bundle.

@KagamiChan it is not about the less popular pattern.
If you have a library that provides, let's say, class A and class B. You cannot mix instances class A from one version and class B from another version together. Even from the JavaScript perspective, instanceof (new A.v1) will never equal to instanceof (new A.v2) — they physically have different constructor. And they see different closures, different library-level global variables and so on.
And nobody will guarantee the compatibility of the private internal APIs between the versions. They are internal and private. Things will get even worse between the major versions where nobody will guarantee even the public API compatibility.
So, if the system uses A.v1 and B.v2 together at the same time, it's not a pattern issue, it is a system's design flaw. The fact that this is the first issue of that type you have encountered is likely just a sheer amount of luck. If you couldn't isolate things using iframes for some reason, your system should fundamentally address that flaw somehow differently. For example, you can try to avoid bundling the component library (and relative deps) inside both Host and Guest and use it as a separate dependency that is imported by Host and Guest at runtime from the same location. Or something else. The system shouldn't allow mixing parts of external deps from different versions in the same runtime.

Would it be helpful if tabster instance is more self-contained? for example, instead of calling an utility function getModalizer(tabster), could it be tabster.getModalizer()?
Thanks for you suggestion, but I'm afraid this often works well on web apps but not in our product's case. For us, host A and guest B are released separately and in parallel, and it depends on clients to check and download updates, adding up that there're multiple channels to release our projects to. This creates a dependency for B on A's version.
Well I understand that tabster might have to be a singleton for its design purpose, and while I need to discuss more within our team on your suggested solution, I'm planning to do a quick mitigation to patch the old tabster instances:
export const renderGuestUI = (root: HTMLElement) => {
  const tabster = getTabster(window);
  if (compare((tabster as any).core._version ?? '9.9.9', '4.3.0', '<')) {
    (tabster as any).core.queueInit = (callback: () => void) => setTimeout(callback, 0);
    (tabster as any).core.drainInitQueue = () => {};
    (tabster as any).core._dummyObserver.updatePositions = () => {};
  }
  ReactDOM.render(<App />, root);
};

This does not intend to fix the missing functionality, and something might not work properly. All its purpose is to prevent crashing the UI before the new version of host reaches the client side.

tabster.getModalizer means that it is not treeshakable and the modalizer code will get into the bundle regardless of being not used.
A better way to mitigate would be to create getModalizer(getTabster()) from your host side. That way the instance will be created already and when the guest will be calling getModalizer(), the instance created by the host will be reused.
But again, it seems to me that your system's design is asking for trouble and should be addressed from that point of view.


Add JSON schema for projects

(needs https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml in vscode)

bump