NTR: AJCC tumor grade value specification

The Ontology for Biobanking has requests from the NCI BBRB for tumor grades and stagings. This term request is for a class of tumor grade and the instances covered by the class. It is meant to be consistent with the discussion in https://github.com/obi-ontology/obi/issues/818 and a figure illustrating the class and instances was added there by Mark Miller. The parent class can be updated if new appropriate subclasses of categorical value specification are introduced (ordinal value specification, composite value specification).
class: histologic grade according to AJCC 7th edition
parent class: categorical value specification
definition: A categorical value specification that is a histologic grade assigned to a tumor slide specimen according to the American Joint Committee on Cancer (AJCC) 7th Edition grading system.
instance: G1: Well differentiated
type of: histologic grade according to AJCC 7th edition
definition: A histologic grade according to AJCC 7th edition indicating that the tumor cells and the organization of the tumor tissue appear close to normal.
definition source: https://www.cancer.gov/about-cancer/diagnosis-staging/prognosis/tumor-grade-fact-sheet
instance: G2: Moderately differentiated
type of: histologic grade according to AJCC 7th edition
definition: A histologic grade according to AJCC 7th edition indicating that the tumor cells are moderately differentiated and reflect an intermediate grade.
definition source: https://www.cancer.gov/about-cancer/diagnosis-staging/prognosis/tumor-grade-fact-sheet
instance: G3: Poorly differentiated
type of: histologic grade according to AJCC 7th edition
definition: A histologic grade according to AJCC 7th edition indicating that the tumor cells are poorly differentiated and do not look like normal cells and tissue.
definition source: https://www.cancer.gov/about-cancer/diagnosis-staging/prognosis/tumor-grade-fact-sheet
instance: G4: Undifferentiated
type of: histologic grade according to AJCC 7th edition
definition: A histologic grade according to AJCC 7th edition indicating that the tumor cells are undifferentiated and do not look like normal cells and tissue.
definition source: https://www.cancer.gov/about-cancer/diagnosis-staging/prognosis/tumor-grade-fact-sheet
instance: GX: Cannot be assessed
type of: histologic grade according to AJCC 7th edition
definition: A histologic grade according to AJCC 7th edition indicating that the grade cannot be assessed and is undetermined.
definition source: https://www.cancer.gov/about-cancer/diagnosis-staging/prognosis/tumor-grade-fact-sheet

The above schema allow for an instance "GX:Undifferentiated" etc. to be a 'type of' other versions as they come up, like "histologic grade according to AJCC 8th edition", right?  In this light, perhaps "definition" can be tweaked to just say when a categorical value was introduced instead, i.e. "A histologic grade introduced in AJCC 7th edition indicating that the grade cannot be assessed and is undetermined."

There may be an instance "G4: Undifferentiated" in "histologic grade according to AJCC 8th edition" but I think it would be a different instance from "G4: Undifferentiated" in "histologic grade according to AJCC 7th edition" and would be distinguishable by a different IRI despite the same label. As a result they are different data values but could be about the same thing.
I don't actually know when the values were introduced but suspect it was before the 7th edition so would not want to say that.

So to compare retrospectively datasets that have been ontologized as different versions of standards have been introduced would require an equivalency mapping table of instances across those standards.  The benefit is that there is no ambiguity, but the work involved is establishing the equivalency, and creating a simplified view on the data that can run queries.  Anyone tried this kind of approach out, visa vis ontology or traditional RDBMS?  It does sound burdensome, and I suspect most people would need some kind of software intermediary in order to cope with analysis of datasets coded in this way, and of course trained ontologist resources would need to be available for standards mapping.
Another vision is that there is only one "G4:Undifferentiated" that can be a member of different versions of a standard, indicating constancy of semantics over time.  The benefit in this approach is that it enables querying across datasets immediately as they all reference the same individual; and new categorical values can be added cumulatively across standards (with some complexity visa vis ordinal rankings as noted separately).  The drawback is in complexity around deprecating a categorical value that exists in one version but is done away with in a subsequent standard's version.  One would have to introduce one other piece of metadata - the date on which a certain categorical value was deprecated, and not use OWL's deprecated flagging mechanism.)  In this scenario one could mark a dataset as a whole as subscribing to a certain set of standards' versions, rather than each individual observation/datum, and have the version of a datum be inferred.

Ah, I made a slight mistake above - if each categorical value has explicit membership in one or more of a standard's versions, then no deprecation timestamp is needed.  However, there is a third vision where each categorical value is a member of an overall standard, and the value has a date of introduction, and a possible date of deprecation.  Separately, a list of standards versions exists, each with a date of introduction, and replacement.  Here no link need be made explicitly between a categorical value and a particular subclass or instance of a standard.  By having a dataset marked as subscribing to a given standard it should be inferable which categorical values pertain to it (and string and numeric ones for that matter).

This was discussed on Aug 21 call and revisited on Sept. 11 call. Result was that it is not an ordinal value specification as it include GX: Cannot be assessed. Will add as a categorical value specification as originally proposed.
With this pattern, I have additional classes and instances to add. See: BBRB value specifications
https://docs.google.com/spreadsheets/d/1mu2815JvvjPUstvXDyhN9_aG5T7kU1YZer7Zwsb7u-w/edit?usp=sharing

There is the measure itself, and then there are metadata states that pertain to the collection of the data.  For any likert scale question leaving answers blank would be communicated by a "blank" metadata state. So is the "GX: Cannot be assessed" meant to be a metadata state? In which case from an informatics perspective it should be excluded from the other choices which would remain ordinal as a set.

I, for one, (and I sense that I may not be the only one) am rather uncomfortable with capturing values such as "GX" ("Cannot be assessed") as results of a measurement process/experiment. If anything, arriving at the GX "value" signifies precisely the fact that, for whatever reason, the measurement process/experiment has been unsuccessful (histological specimen was not good enough, microscope was broken/badly calibrated, whatever), hence there was no measurement process in the first place--but merely an attempt at a measurement process. I agree, however, that one may need to make a note of this GX "value," though that should not happen as a value of some physical magnitude/quality, but as a "property" of the measurement attempt itself. I thus propose to design a class "assay attempt" around the assay class, thus having "assay/measurement process" as a proper subclass. The "assay" class would thus encompass only successful assays: Only those deserve to be deemed (genuine) measurement processes. And if we are hell bent on using the string "GX" itself in the ontology (as it can always be cooked up in the code by whoever designs the application that uses the ontology), simply make a subclass of "assay attempt" that does not overlap the "assay" class, and label that "GX" for "unsuccessful histological assay." My $.02.

I agree that treating "GX: cannot be assessed" as an instance of the "Histological Grade" class is awkward and is not a "histological grade", but rather a fact about the measurement attempt.  So top-of-page approach may work for some folks but won't engender automated statistical analysis and isn't a pure solution.  I like idea of having a generic "assay attempt" class, and of having a "unsuccessful assay" class to reference.  This metadata state could pave way for other possibilities too that at moment I don't know how to deal with, e.g. NCBI Biosample submissions require stating "missing" or "not collected" (see bottom of MIXS in many cases where free text or categorical input data is not available.

Here's a diagram of the lifespan of these categorical/ordinal variable specification items according to top-of-page scheme "Replace by edition", and something I had in mind "Replace or create on demand" as datasets are encoded over time. In 2nd schema, G1, G2, G3 etc are members of a general "AJCC histologic grade code" class; and particular annotations indicate which versions they are created or discontinued for.  Comments?

Sorry for being AWOL, have been grant writing. This subject of
'meta-values' came up before. We have seen different types (I am copying
this from an old thread):
"'not done', 'not performed', 'not determined' - information isn't here
because a measurement wasn't made
*'unknown'; 'not available' *- information isn't here because the person
entering it doesn't have it
*'not applicable' *- information for this instance is not meaningful e.g.
capturing a gender column for different samples and filling it out for
organism samples, but entering 'not applicable' for environmental samples.
*'none of the above' *- there is a correct value, but it does not fit in
the value specification scheme.
These types of list values are essentially 'meta-values'. I believe we
should represent them as such, and state that a database column holds
either a 'meta-value specification' or a 'value specification', the later
being what we are trying to capture in measurement data and those value
specifications. A 'meta-value specification' is not the output of an
experiment, but an ICE stating why that is not available and something else
is put there."
It sounds like there is support for this notion?
On Wed, Sep 27, 2017 at 4:29 AM, Damion Dooley<EMAIL_ADDRESS>wrote:

I agree that treating "GX: cannot be assessed" as an instance of the
"Histological Grade" class is awkward and is not a "histological grade",
but rather a fact about the measurement attempt. So top-of-page approach
may work for some folks but won't engender automated statistical analysis
and isn't a pure solution. I like idea of having a generic "assay attempt"
class, and of having a "unsuccessful assay" class to reference. This
metadata state could pave way for other possibilities too that at moment I
don't know how to deal with, e.g. NCBI Biosample submissions require
stating "missing" or "not collected" (see bottom of MIXS
http://gensc.org/mixs/ in many cases where free text or categorical
input data is not available.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/obi-ontology/obi/issues/856#issuecomment-332491746,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANN9IhdWg91Fmlfcr08TgxrPbhelTklyks5smjGAgaJpZM4O76qr
.

--
Bjoern Peters
Associate Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

Adopting this "meta-value specification" fix appears to me to be more of a cop-out than an actual attempt to analyze and capture the various issues (of various natures) that happen under this umbrella. Surely, if appeal to "meta-value" is solely meant to constitute a temporary fix for the sake of expediency, I'm all for it--that is, as long as we are committed to return to this issue in the near future and give it a permanent and final solution (however ominous that may sound). Otherwise, if not in a mad rush, I think it would be worth spending a bit of time to analyze things in detail: in this respect, capturing the distinction between assays and assay attempts looks to me to be a good start toward resolving "not performed"/"not determined"/"not available" and related issues--which, as you mentioned, are encountered very often in the world of assays.

I fail to see how this is a cop-out? I was very much trying to go for a
'more final solution', and primarily wanted to point out that there are
analogous scenarios other than 'assay attempts' that lead to reports of
'not applicable' or 'none of the above'. In all those cases they reported
side-by-side to actual value specifications, and in one way or another
indicate why not a normal value specification is given. In that sense they
are 'meta value specifications'. Happy to change the label to something
else. I think each of these cases can be modeled more carefully, and it is
interesting to do so.
On Wed, Sep 27, 2017 at 8:51 AM, Cristian Cocos<EMAIL_ADDRESS>wrote:

Adopting this "meta-value specification" fix appears to me to be more of a
cop-out than an actual attempt to analyze and capture the various issues
(of various natures) that happen under this umbrella. Surely, if appeal
to "meta-value" is solely meant to constitute a temporary fix for the
sake of expediency, I'm all for it--that is, as long as we are committed to
return to this issue in the near future and give it a permanent and final
solution (however ominous that may sound). Otherwise, if not in a mad rush,
I think it would be worth spending a bit of time to analyze things in
detail: in this respect, capturing the distinction between assays and assay
attempts looks to me to be a good start toward resolving "not
performed"/"not determined"/"not available" and related issues--which, as
you mentioned, are encountered very often in the world of assays.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/obi-ontology/obi/issues/856#issuecomment-332567418,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANN9IvDjYY646YUs7YFxrN1J0y3w8tUVks5smm74gaJpZM4O76qr
.

--
Bjoern Peters
Associate Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

Yes, there may be scenarios where the "assay attempt" fix does not apply, which is why I said that it constitutes merely a (good) start. I do not think we should even aim at capturing all these scenarios in one fell swoop. Coining yet another informational entity for this purpose seems to me to be just another way of avoiding to tackle things at the reality level, where things happen--after all, it seems plausible that you could (re)build OBI exclusively out of informational entities without ever having the need to represent the things that these informational entities are about. While attempting to solve this by appeal to more and more informational entities may be tempting from the point of view of expediency (which is certainly not something that one should scoff at), I think getting one's hands dirty with the things-that-informational-entities-are-(purportedly)-about will yield more benefits in the long run, however messy it may look at this point.

I understand your point, respectfully disagree, and think it should be
possible to compromise. In our modeling of entries in the IEDB, and in what
Chris is needing, we will need to deal with more than assay attempts being
reported. These reports are perfectly real entities. Creating a bucket for
such information content entities would mean that we will be able to fully
map our database entries to OBI values, and that would have immediate
practical benefit, even if most of those OBI entries would not be fully
satisfactorily defined in terms of relation to non-information content
entities. That can be noted in the curation status of those terms, and they
could be revised as we model them one-by-one.
Starting with assay-attempts is a good idea. Here is a start.
Possible scenarios how "GX: Cannot be assessed" can arise

an assay was executed in full according to protocol, and control
readouts indicated that the results can't be trusted (e.g. PHA stimulated
samples did not result in >20SFC per million input cells in an IFN-g
ELISPOT assay). I would say that this is a planned process, but not an
assay, as it did not generate the desired data item. .
an assay was attempted to be performed, but could not be completed
according to protocol (e.g. the building burned down). One can argue that
this is a process that has a part that was planned but overall failed.
an assay should have been performed, but wasn't. This is tricky, and I
think the most common scenario. If the surgeon does not provide the
pathologist with a tumor sample, the pathologist can't grade it. Much
harder to say what this is. I guess there is the larger planned process
(study design, or treatment plan) which if executed in full should have
included the assay but did not. I would argue that 'lack of process' is not
a process. But rather that whatever the evaluant was did not participate in
an assay.

So in all cases "GX: Cannot be assessed"

is an ICE
is about a physical tumor
is about the plan that the tumor should have been assessed
is about the failure of that plan to be executed properly

In the case of 1), it is the output of a 'assay attempt with controlled
failure' (a planned process). In the case of 2) or 3) it is the output of
someone making a determination that a deviation from the original plan
occurred.
Stopping here, having too much fun while I should be grant writing.
On Thu, Sep 28, 2017 at 7:25 AM, Cristian Cocos<EMAIL_ADDRESS>wrote:

Yes, there may be scenarios where the "assay attempt" fix does not apply,
which is why I said that it constitutes merely a (good) start. I do not
think we should even aim at capturing all these scenarios in one fell
swoop. Coining yet another informational entity for this purpose seems to
me to be just another way of avoiding to tackle things at the reality
level, where things happen--after all, it seems plausible that you could
(re)build OBI exclusively out of informational entities without ever having
the need to represent the things that these informational entities are
about. While attempting to solve this by appeal to more and more
informational entities may be tempting from the point of view of expediency
(which is certainly not something that one should scoff at), I think
getting one's hands dirty with the things-that-informational-entities-are-(purportedly)-about
will yield more benefits in the long run, however messy it may look at this
point.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/obi-ontology/obi/issues/856#issuecomment-332852928,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANN9Ijr8zmzdSgLrFl5npFcVWtTwUY23ks5sm6xAgaJpZM4O76qr
.

--
Bjoern Peters
Associate Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

Thanks for the interesting feedback. I agree that GX (and pTX, pNX, etc.) are not tumor stages/ grades in the same sense as G1, G2, etc. Therefore, to move ahead, I will not add these as instances to the stage and grade classes. However, as Bjoern correctly points out, they are needed and we need to figure out how to best capture them. And as Cristian points out, I think it useful to clarify what exactly GX is about.
So I asked a pathologist!
Assigning GX is rare and happens when there isn't enough tissue to make a call. The other "cannot be assessed" values (TX, NX, MX) are more common and occur when the timing isn't right to make a call because the tumor size isn't provided or other needed things (e.g., lymph nodes checked) haven't been done. He agreed that theses values are not about the tumor but about the process of grading the tumor and reflect that an attempt was made to make a call but could not be properly done at the time with what was provided. Time was spent making that call so it was more than just a plan. And the plan includes clearly defined instructions for not making a call. Therefore:
"GX: Cannot be assessed"

is an ICE
is about the attempt to assess a tumor (i.e. is about a planned process performed at time T)
is about the inability to output a grade for the tumor from the process with the given inputs.
So I'm thinking along the same lines as Bjoern but focusing on the planned process rather than the plan.

This is excellent Chris. So there is an 'assessment process', in which the
pathologist first determines if there is sufficient material and
information at hand. If so, he continues and performs a full tumor grading
assay. If not, then he terminates the process and records that given his
inputs, he can't give an accurate assessment and records "GX: Cannot be
assessed". This is a planned process, and part of the study design /
treatment plan. Kind of a wrapper around the actual assay process. Similar
to the 'control failure' example I had.
I do believe we can create a superclass: 'reason for lack of data item' =
def: An information content entity that provides an explanation why a data
item is not provided. Example: "cannot be assessed", "not applicable",
"unknown".
In which 'cannot be assessed' is the output of a planned process of
'determination if assay will provide reliable results".
I think we can expand this to other similar types of  'reason for lack of
data item' and write a paper about it. I would like title it 'defining
known unknowns'. Would love Christian Cocos to be heavily involved in this
if he is up for it :)

Bjoern

On Thu, Sep 28, 2017 at 2:47 PM, cstoeckert<EMAIL_ADDRESS>wrote:

Thanks for the interesting feedback. I agree that GX (and pTX, pNX, etc.)
are not tumor stages/ grades in the same sense as G1, G2, etc. Therefore,
to move ahead, I will not add these as instances to the stage and grade
classes. However, as Bjoern correctly points out, they are needed and we
need to figure out how to best capture them. And as Cristian points out, I
think it useful to clarify what exactly GX is about.
So I asked a pathologist!
Assigning GX is rare and happens when there isn't enough tissue to make a
call. The other "cannot be assessed" values (TX, NX, MX) are more common
and occur when the timing isn't right to make a call because the tumor size
isn't provided or other needed things (e.g., lymph nodes checked) haven't
been done. He agreed that theses values are not about the tumor but about
the process of grading the tumor and reflect that an attempt was made to
make a call but could not be properly done at the time with what was
provided. Time was spent making that call so it was more than just a plan.
And the plan includes clearly defined instructions for not making a call.
Therefore:
"GX: Cannot be assessed"

is an ICE
is about the attempt to assess a tumor (i.e. is about a planned
process performed at time T)
is about the inability to output a grade for the tumor from the
process with the given inputs.
So I'm thinking along the same lines as Bjoern but focusing on the
planned process rather than the plan.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/obi-ontology/obi/issues/856#issuecomment-332973193,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANN9IhGrEzgf4ACubaaoryA13hqIE1mHks5snBPjgaJpZM4O76qr
.

--
Bjoern Peters
Associate Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

My main concern is the hyperinflation/proliferation of ICEs (Information Content Entities?) to the detriment of non-ICEs. (I am also not a big fan of "about" and "aboutness," as one can make a convincing case that anything can be about everything, and that aboutness is awfully subjective. But I digress.) In my experience, modeling ICEs (aka "representational entities," that are purportedly about things) tends to monopolize ontology development efforts, such that the entities that the ICEs are purportedly about never (or seldomly) get modeled. Instead of being the driving force of ontology development, non-ICEs have been relegated to a mere afterthought; instead of modeling the ding an sich, ontologists end up focusing on the modeling of representations thereof. Non-representational reality thus takes a back seat to representations of reality (quite ironically, in an ontology purporting to primarily model the world of the noumenon). The convenient thing about this procedure is that in the world of ICEs anything goes (pretty much)--again, given that anything (and everything) can be claimed to be about anything (and everything). As such, no one could claim that positing yet another ICE is wrong. I certainly cannot bring any knock down arguments against the framework you just proposed. All I am asking at this point is that you understand my intervention as a plea to restore the natural order of things, namely attempt to represent non-ICEs before indulging in producing a rhapsody of ICEs. My feeling is that once we develop the world of non-ICEs to a satisfactory extent, there will be no need for ICEs, or, at least, the amount of ICEs required will be considerably smaller.

Thank you both, Chris and Bjoern, for the feedback. I will attempt to gather my thoughts and compare the frameworks you proposed. I will get back to you with my musings, as always.

Chris and Bjoern, here are two diagrams (https://goo.gl/Qt5kPK and https://goo.gl/CEvh4b) I whipped up in an attempt to illustrate our positions. None of them contain, at this point, any ICEs, although I maintain that they are both capable to capture the issue of tumor grading with room to spare. Both are generalizable to situations involving "known unknowns," to use Bjoern's term. Red arrows are rdf:subClassOf or rdf:subPropertyOf relations. "reveals" and "hasOutcome" are akin to what you know as "has_specified_output" (without the ICE requirement, that is). Indexing qualities with time looks to me to be necessary, though from what I remember, BFO does not do that; as such, I saw fit to represent the four tumor stages G1-G4 as (pairwise disjoint) classes. Should the requirement that qualities be time dependent be dropped, the four tumor stages can very well be captured as instances of the TumorStage class. The main difference, as you will notice, is the inclusion of an "AssessmentProcess" class in the second diagram (TumorStageAssay2), per your suggestion. As such, the major difference is that in TumorStageAssay2 the GX TGAA class emerges as a defined class, whereas in TumorStageAssay1 it is a primitive class. That seems to be the root of the difference between my initial proposal, and yours. In other words, there is not much of a difference between the two "positions." Either way should be fine with me, although I find simply accepting a GX TGAA class as a primitive to be the simpler solution, and more easily generalizable to other cases of "known unknowns." You will also notice that in the second diagram I captured the GX "ICE" as a simple string, as I see no reason to complicate the picture with yet another ICE when a simple string does the job very well. Surely enough, should the hasOutcome relation be replaced with has_specified_output, then the GX string will have to turn into an ICE.
Cheers,
C

This (https://goo.gl/gvEV4L) is the diagram that generalizes the issue of Tumor Stage Assay, as presented in today's OBI meeting. As discussed, adopting an "UnsuccessfulAssayAttempt" class has the advantage that it is non-committal vis-a-vis the reason the Assay Attempt failed, thus it is more likely to satisfy Bjoern's requirement that we strive to accommodate various scenarios: there are various reasons why assays can lead to "Cannot be assessed" (or related) results, hence it is more convenient to stay silent about these reasons instead of positing a reason that might not apply universally. Surely enough, assays that rely on histological samples can fail due to the bad quality of the sample, which is where Chris and Bjoern's proposal about separating an "assessment process" sub-process comes into the picture. This, again, happens for assays that rely on input samples, whereas I have striven to come up with a more general framework. With this being said, if the general solution happens to be to OBI members' liking, and should you guys happen to think that this is something that should be shared with the rest of the biomedical ontologies community, I can, of course, volunteer to start writing a paper (as suggested by Bjoern) to present both the general Unsuccessful/AssayAttempt mechanism, as well as the special case of assays-that-rely-on-samples and the associated Chris&Bjoern "assessment process." Just let me know, and I can get started anytime.
Otherwise, the second major issue regarding the above diagram that was discussed today was the issue of tying the Assay class to the Quality that the assay measures. As far as I can tell, a connection to this effect is missing from OBI at this point in time--though I think it was James (Overton) who mentioned similar attempts (in other ontologies?), attempts that I very much applaud. This, in my opinion, is an oversight that needs to be corrected in OBI at the highest level (namely Assay). In this respect, my proposal is to define a relation between the Assay class, and the Quality class, tentatively dubbed "reveals" or "exposes" (though I certainly am not a stickler for any of these labels).
The third major issue that made the object of discussion in relation to the diagram above was the issue of ICEs, though I will take a breather for now, as I think I have abused y'all's patience.

As promised, here are a few words about ICEs meant to clarify my intervention this past Monday. ICEs are entities characterized by the fact that they are "about" (or "represent," or "stand for") something. The paradigm case in philosophy is that of "mental representations" (aka "intensions," "senses" (Frege's "sinn,") etc.), and, indeed, all ICEs can be reduced one way or another to mental representations (or combinations thereof, LOT sentences etc.). As such, they are, indeed, part of reality--no question about that. What is less pleasant about these referential entities is that the mechanism that confers them "aboutness" is still heavily debated in contemporary philosophy; representing ICEs requires accounting for the "about" relation as well. The outcome, for our purposes, is that "about" is, at this point in time, a very subjective term: it is quite rare that two or more human subjects agree with respect to what most "representations" represent. Given that, ontologists who happen to be aware of the perils of the "aboutness" issue (i.e. mostly those with a philosophy background) have acquired a definite preference for avoiding referential entities unless absolutely necessary. Fortunately, in realist ontologies this preference is at a definite advantage due to the fact that realist ontologies tend to shun fiction and fictive entities, while referential entities that actually refer (to something real) can be dispensed with in favor of the (real) entities that they stand for, thus making appeal to ICEs unnecessary. Be that as it may, there are, indeed, situations in which referential entities, be they fictional or non-fictional, need to be accounted for. As I see it, there are two situations where including ICEs in an ontology is unavoidable:

ICEs that do not actually refer, such as results of measurements that can only be deemed as approximate (hence don't stand for anything real);
ICEs that need to be represented due to design requirements, such as needing to actually refer to some document or form (such as a CRF) that bears an identifier, has a date and an author, or needing to refer to some particular field in some form, also identified using an identifier.

Other than that, I am personally having trouble perceiving the inevitability of ICEs, to say nothing about accepting a deluge of ICEs (... which is what things seem to be heading toward in OBI). Again, given that all ICEs that successfully refer can be dispensed with in favor of their referent, there should be no excuse to prefer an ICE over whatever it is that it refers to.

Back to the issue of Xs (as in GX but the tumor grades also include pTX and and pNX).  The consensus is that these are not stages or grades which are about the tumor. Instead these are about the process of assessing whether a stage or grade can be determined. Building on Bjoern's proposal above:
'reason for lack of data item' = def: An information content entity that provides an explanation why a data item is not provided. Example of usage: "cannot be assessed", "not applicable", "unknown".
'cannot be assessed' = def: A reason for lack of data item' that is the negative output of 'determination if assay will provide reliable results'.
'determination if assay will provide reliable results' = A planned process that is used to assess whether an assay will provide reliable results based on the conditions or qualities of the inputs, devices, and other participants of the assay.
For the tumor pathology value specifications:
GX = def: A cannot be assessed histologic determination for tumor grade. Example of usage: AJCC 7th edition GX: cannot be assessed.
pTX = def: A cannot be assessed pathologic determination for primary tumor staging. Example of usage: AJCC 7th edition pTX: cannot be assessed.
pNX = def: A cannot be assessed pathologic determination of lymph nodes. Example of usage: AJCC 7th edition pNX: cannot be assessed.

A case where an assay process is generating data but some encapsulating system knows it is erroneous came to mind, so I offer mainly the last point below.  If I was an engineer asked to design a system for generating an assay, it would be a generic process class having:

a 'has output' or 'producesData' component that points to (has value) a single datum or multiplex assay array of data, the observation itself.
a 'has participant' or 'has input' component that includes the class or instance of thing being measured.
a 'has input' or 'has setting' for any experimental level(s) or settings of the assay machinery, if any.
a 'hasContextualData' component that points to datum(s) describing other pertinent components of reality (time, location etc.). This data (produced by other measurement systems external to the assay machinery itself) is coincident with the assay data.  (Some contextual datums might instead be treated as assay inputs).
a 'hasMetadata' component that provides a more general indication of success or failure that can be further refined (subclassed).  This component would contain datums that arise from sensors internal to the assay system, or the intervention of human judgement calls.

A "dumb" assay instance would always have a 'hasMetadata' some 'successful assay process' with no possibility of 'cannot be assessed'; slightly smarter assay could report 'hasMetadata' some 'failed assay process'; A real-time instance might report 'hasMetadata' some 'assay process underway'; and finally we get into subclasses of the above, e.g. 'hasMetadata' some  "cannot be assessed", "not applicable", "unknown", 'system malfunction', 'system malfunction - power outage', etc. subclasses. This anticipates modelling assay machinery IF desired.  Data analysts don't need that level of modelling obviously; but equipment manufacturers and lab quality control and maintenance people could really benefit from this in the ontology-driven Internet of Things IoT vision. I can draw up a diagram if desired.

Ideally, GX, pNX, and pTX should be represented as strings instead of entities. While reasons why we'd want them captured as entities can always be cooked up if one is sufficiently imaginative, I'd be inclined to argue that none of them are essential. Even better, the set {"GX", "pNX", "pTX"} should be represented as a user-defined datatype. And if it absolutely must be an ICE, we can make this datatype a subclass of ICE to make everyone happy. Should this proposal fail to elicit much enthusiasm, I'd argue that GX, pNX, and pTX should at the very least be captured as individuals as opposed to classes.
I suggest that the proposed 'determination if assay will provide reliable results' process be made part/subprocess of the assay itself.
My guess is that 'reason for lack of data item' is projected to be a subclass of ICE. What is not clear to me is what sort of critters "cannot be assessed", "not applicable", and "unknown" might be. Again, I, for one, would like to see 'reason for lack of data item' represented as a datatype: {"cannot be assessed", "not applicable", "unknown"}.

Its tough - whether one is creating a logical structure that can be repurposed or expanded, which requires a bit of a general systems anticipatory ("imaginative") guessing game in design, vs. the need of particular projects now, and not making guesses about usage that are at risk of being wrong.
I think a fundamental issue in this situation and others is how to use ontology to model process encapsulation in which underlying processes successfully generate their outputs, or fail for whatever reason, and need an overall process wrapper to capture this general behaviour.  A simple approach where some inputs and outputs can be defined with data types as @Aqua1ung suggests above allows states to be specified, and as a datatype, act as a categorical variable, and reused elsewhere I presume.  But no ability to annotate - define - the given states individually, and they could be criticized on the multilingual front.
Personally I'm looking for a solution in which output states of component part processes can be elevated and generalized to output states of the encapsulating process.

Thanks for raising these issues but I think they are of a more general nature (when to use ICEs, how to encapsulate assays, etc.) and can be part of an ongoing discussion. I will push ahead with adding the specific requested terms that are needed.
Chris


[LOC] Invalid link in an article

There is an invalid link redirecting to a non exisitng article
Repro steps:

Go to https://docs.microsoft.com/en-us/outlook/add-ins/manifests
Search for "Understanding Outlook Add-in permissions"
Click on the link

Actual results:
Link redirects to a non exising page
Expected results:
Link redirects to an existing page
GH article:
https://github.com/OfficeDev/outlook-dev-docs/blob/live/docs/add-ins/manifests.md

Thanks for raising this issue. However it seems to have been fixed since it's no longer repro-ing. Closing this.


Create tests for examples with custom stages

Description
This PR creates at least one test for each example containing custom stages.
This PR currently only covers those examples which do not require additional packages.
Part of #849.

Moves the bert vocabulary files to morpheus/data dir, no longer requiring them to be fetched from LFS and making them available to unittests.
Fixes type hints and remove a redundant method in examples/log_parsing/inference.py
Remove redundant copies of bert-base-cased-hash.txt and bert-base-uncased-hash.txt files, replacing them with symlinks to the files in the morpheus/data` dir fixes #850
Explicitly set encoding='UTF-8' in examples/log_parsing/postprocessing.py as a work-around for issue #859
Add py::kw_only to Python bindings for TensorMemory and sublasses to ensure parity with Python impls.
Set repr=False for the tensors field of TensorMemory avoids bug when printing due to the fact that we assign the value to self._tensors
Seed cupy's random number generator in manual_seed method.
Fix usage of reload_modules fixture, requesting a reload of multiple modules should be done with @pytest.mark.reload_modules([mod1, mod2]) not calling reload_modules twice.
New test data in tests/tests_data/log_parsing is based upon the first 5 rows of data from models/datasets/validation-data/log-parsing-validation-data-input.csv

Checklist

[x] I am familiar with the Contributing Guidelines.
[x] New or existing tests cover these changes.
[x] The documentation is up to date with these changes.

/merge


Cannot return public class with only internal constructors using MessagePack

If a SignalR hub has a method which returns a type which is public, but has only internal constructors, it fails silently, yielding no error messages on the server side nor on the client side. No exceptions are thrown. Nothing in the debug output window.
Consider the following classes:
    public class ApiLogin
    {
        internal ApiLogin(...)
        {
            ...
        }

        public byte[] PrivateDetailsCiphertext { get; set; }
    }

    public class ApiLoginWithToken : ApiLogin
    {
        internal ApiLoginWithToken(...) : base(...)
        {
            ...
        }

        public byte[] Token { get; set; }
    }

And the following hub method:
public ApiLoginWithToken LogIn(string username, string password) => new ApiLoginWithToken(...);
Fails silently.
To get it working, I had to add a couple of public constructors.
Assuming this has to do with reflection. Strictly speaking, the MessagePack component shouldn't have to know about constructors to serialize an existing instance. In any case, I would like to suggest that an error message should be displayed somewhere if something goes wrong :)
Microsoft.AspNetCore.SignalR.Protocols.MessagePack, version 1.0.4

Sadly this looks like a restriction of the library we're using. See https://github.com/neuecc/MessagePack-CSharp/issues/40
Workaround is to use public constructors, or use Json where private/internal constructors are supported.

If you have logging enabled on the server then you'll get an error log looking like:
fail: Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher[8]
      Failed to invoke hub method 'Send'.
System.IO.InvalidDataException: Error binding arguments. Make sure that the types of the provided values match the types of the hub method being invoked. ---> System.IO.InvalidDataException: Deserializing object of the `t` type for 'argument' failed. ---> MessagePack.Internal.MessagePackDynamicObjectResolverException: can't find public constructor. type:SignalRSamples.Hubs.Chat+t
   at MessagePack.FormatterResolverExtensions.GetFormatterWithVerify[T](IFormatterResolver resolver)
   at MessagePack.MessagePackSerializer.Deserialize[T](ArraySegment`1 bytes, IFormatterResolver resolver)
   at lambda_method(Closure , ArraySegment`1 , IFormatterResolver )
   at MessagePack.MessagePackSerializer.NonGeneric.Deserialize(Type type, ArraySegment`1 bytes, IFormatterResolver resolver)

And the client will get an error thrown from the invoke call: Error: Failed to invoke 'methodName' due to an error on the server.


Generated entity metadata extensions triggers SwiftLint error

Nitpick: Nice to see that // swiftlint:disable all is added to the top of the generated file, but the two lines above trigger a vertical_whitespace warning.
I can add this folder to the excluded in the .swiftlint.yml file, but would be even better if ObjectBox can avoid adding that extra line.

Thanks for the shout-out, I've fixed it for the next release.

The release with the fix is out now.


Decode API errors

APIs return errors as JSON objects, usually with an error code and a message. Retrofit2 that we use for making API calls doesn't deserialize these but they're available in the response.errorBody().
Add an error model and a method to deserialize errors so the message can be made visible to the user.
Refs:

https://docs.github.com/en/rest/overview/resources-in-the-rest-api#client-errors

I did this only for artifacts in 46b68b119fb13176d98d967723c28e04312c82d3


Can JOINS be performed on ElasticSearch using Crate ?

Our company wants to perform JOIN operation on the data in ElasticSearch, which isn't allowed in ElasticSearch. Can we achieve this using Crate ?

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/21366367-can-joins-be-performed-on-elasticsearch-using-crate?utm_campaign=plugin&utm_content=tracker%2F505659&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F505659&utm_medium=issues&utm_source=github).

+1

Crate does not support JOINs.
Its mentioned in the FAQ -  https://crate.io/docs/faq/
Q: Does Crate support JOINs?

Not yet. JOINs are on our roadmap and we try to do them the right way in usual quality and well performing.
For a lot of use cases there are other ways to achieve the same result as with JOINs. The best way to start is to take a look at the ARRAY and OBJECT data types to denormalise your data.

hi @sumanth232
Our latest testing release 0.53.0 has a first, basic support for INNER JOINs (see: https://crate.io/docs/en/latest/sql/joins.html) We're working on improving performance and adding more complete support for JOINs.
We're going to update the website accordingly!
Best,
Christian


fix: heatmap plot colorbar and internal refactoring

Overview
Description of the changes proposed in this pull request:

Fixed the colorbar aspect ratio in shap.plots.heatmap, see:

Internally, I've switched to an ax-based implementation instead of plt.imshow(), plt.barh() etc.; primarily so we don't have to do pl.gca() all over the place, and also the axes is needed to pass into plt.colorbar() to avoid warnings about   Unable to determine Axes to steal space for Colorbar. Using gca(), but will raise in the future. Either provide the *cax* argument to use as the Axes for the Colorbar, provide the *ax* argument to steal space from it, or add *mappable* to an Axes.

The keen eye might notice that in the baseline images above, the tick directions have swapped from "in" to "out" -> note that the tick directions being "in" in the original baseline image is just a result of pytest-mpl using the "classic" matplotlib style; anybody with a more recent matplotlib version should already have the tick directions being "out" even prior to this PR. I only made this explicit in-code so that the baseline images generated by pytest-mpl reflects what most users would get by default ("out" tick directions).
Render the f(x) text in MathTex rather than plain text to match with the force plots.
Added comments and grouped similar code (e.g. the tick/axes manipulation code) together for better code readability.

Checklist

Closes #xxxx
[X] All pre-commit checks pass.
[ ] Unit tests added (if fixing a bug or adding a new feature)
[ ] Added entry to CHANGELOG.md (if changes will affect users)

Failing tests are from pytorch mnist cnn, irrelevant to the changes in this PR. See #2960


Improve documentation on path format

The README does not mention which variables are replaced in the path format interpreted by this plugin. From reading the source code, I have determined this to be the following:

artist
albumartist
album
albumpath
filename
basename

As well as all functions provided by beets by default.
I was especially interested in filename and basename, because the readme wasn't clear enough (to me) on whether the matched files will be copied into a directory specfied in the paths setting or whether that will be the path for each individual file. Especially considering that the file extension is specifically not considered for the template and merely appended.
Also a mention of the default pattern would be useful. That should be $albumpath/$filename.

I second this. Is there any way to put the extra files inside of a custom made folder defined by inline and path? All the extra files land where the albumpath is, but it does not take insto consideration the full albumpath, just the first part of it.

I second this. Is there any way to put the extra files inside of a custom made folder defined by inline and path? All the extra files land where the albumpath is, but it does not take insto consideration the full albumpath, just the first part of it.

Been a while but +1 for this, this plugin does not respect full album paths so it's not possible to create subdirectories when using buckets

Trying this plugin for the first time, I also had to resort looking at the source code to figure things out. Specifically, I was interested in renaming cover art files and came up with this config:
patterns:
  cover: ['[cC]over.*', '[fF]older.*', '[fF]ront.*']
  my_extensions: ['*.pdf', '*.png', '*.jpg', '*.jpeg']
paths:
  cover: $albumpath/cover

it somehow works (I'm not sure how the globs in cover don't clash with those in my_extensions but on a quick test it looks fine), and it does rename for example Folder.jpg to cover.jpg, however I also wanted to change .jpeg extensions into just .jpg for cover files, ie I always want my covers to be called either cover.jpg or cover.png. Is there a way to achieve that?


Bug in the IR generated for __longlong_as_double

When the routine __longlong_as_double is used in kernel code, the IR generated for it implements the routine using the "sitofp" instruction instead of a "bitcast" instruction. We believe this is a bug.
Please use the provided testcase (at the end of this message) to see it. IR corresponding to the buggy routine is also provided
Re-run the testcase with "IMPLEMENT_WORKAROUND" defined to see the expected/correct functionality.
Ping me if you need more information.
Compile cmd -
/opt/rocm/hip/bin/hipcc -Wall src/double_check_longlong_as_double.cpp -o run_check.exe

Testcase -
// src/double_check_longlong_as_double.cpp
#include <stdio.h>

// hip header file
#include "hip/hip_runtime.h"
#include "hip/hip_fp16.h"

//#define IMPLEMENT_WORKAROUND

#define NUM (8)

using input_type_t = long long;
using output_type_t = double;

void print_values(input_type_t in, output_type_t out)
{
  printf ("%016llx : %f\n", in, out);
}

__global__ void gpuKernel(hipLaunchParm lp, output_type_t* out, input_type_t* in) {
    int x = hipBlockDim_x * hipBlockIdx_x + hipThreadIdx_x;
    int y = hipBlockDim_y * hipBlockIdx_y + hipThreadIdx_y;
    int idx = x + y;

#ifdef IMPLEMENT_WORKAROUND

    output_type_t* addr = reinterpret_cast<output_type_t*>(&in[idx]);
    out[idx] =  *addr;

#else

    out[idx] = __longlong_as_double(in[idx]);

#endif
}

int main() {

    hipDeviceProp_t devProp;
    hipGetDeviceProperties(&devProp, 0);

    std::cout << "Device name " << devProp.name << std::endl;

    // initialize the input data
    input_type_t* input = (input_type_t*) malloc (NUM * sizeof(input_type_t));
    input[0] = 0x0000000000000000ull;  // bit-pattern for +0.0
    input[1] = 0x3ff0000000000000ull;  // bit-pattern for 1.0
    input[2] = 0x4000000000000000ull;  // bit-pattern for 2.0
    input[3] = 0x4008000000000000ull;  // bit-pattern for 3.0
    input[4] = 0x4010000000000000ull;  // bit-pattern for 4.0
    input[5] = 0x4014000000000000ull;  // bit-pattern for 5.0
    input[6] = 0x7ff0000000000000ull;  // bit-pattern for +inf
    input[7] = 0x7ff8000000000000ull;  // bit-pattern for nan

    // allocate the memory on the device side
    input_type_t* inputOnGPU = nullptr;
    output_type_t* resultOnGPU = nullptr;
    hipMalloc((void**)&inputOnGPU, NUM * sizeof(input_type_t));
    hipMalloc((void**)&resultOnGPU, NUM * sizeof(output_type_t));

    // allocate memory on the host for the result
    output_type_t* result = (output_type_t*)malloc(NUM * sizeof(output_type_t));

    // Memory transfer from host to device
    hipMemcpy(inputOnGPU, input, NUM * sizeof(input_type_t), hipMemcpyHostToDevice);

    // Lauching kernel from host
    hipLaunchKernel(gpuKernel, dim3(1), dim3(NUM), 0, 0, resultOnGPU, inputOnGPU);

    // Memory transfer from device to host
    hipMemcpy(result, resultOnGPU, NUM * sizeof(output_type_t), hipMemcpyDeviceToHost);

    // free the resources on device side
    hipFree(inputOnGPU);
    hipFree(resultOnGPU);

    for (int i=0; i<NUM; i++) {
      print_values(input[i], result[i]);
    }

    // free the resources on host side
    free(input);
    free(result);

    return 0;
}

// IR for kernel
; Function Attrs: alwaysinline norecurse nounwind
define weak_odr amdgpu_kernel void @_Z9gpuKernelN8hip_impl17Empty_launch_parmEPdPx(%"struct.std::less" %lp.coerce, double* %out, i64* %in) #20 {
  %call = tail call i32 @hc_get_group_size(i32 0) #28
  %call2 = tail call i32 @hc_get_group_id(i32 0) #28
  %mul = mul i32 %call2, %call
  %call3 = tail call i32 @hc_get_workitem_id(i32 0) #28
  %call4 = tail call i32 @hc_get_group_size(i32 1) #28
  %call5 = tail call i32 @hc_get_group_id(i32 1) #28
  %mul6 = mul i32 %call5, %call4
  %call7 = tail call i32 @hc_get_workitem_id(i32 1) #28
  %add8 = add i32 %mul, %call3
  %add = add i32 %add8, %call7
  %add9 = add i32 %add, %mul6
  %idxprom = sext i32 %add9 to i64
  %arrayidx = getelementptr inbounds i64, i64* %in, i64 %idxprom
  %1 = load i64, i64* %arrayidx, align 8, !tbaa !2962
  %conv.i = sitofp i64 %1 to double
  %arrayidx12 = getelementptr inbounds double, double* %out, i64 %idxprom
  store double %conv.i, double* %arrayidx12, align 8, !tbaa !2943
  ret void
}

Can you post the full IR, just the function is incomplete

Nevermind, this is a library problem

@mangupta @jedwards-AMD this appears to be due to faulty packaging of libhip_device.a. The version we're shipping (and have shipped) appears to archive the old, broken versions of the conversion functions, which were present before https://github.com/ROCm-Developer-Tools/HIP/pull/267 was merged. Could you please look into why that is the case? Thank you.

Do you know what version of the hip_hcc package was installed? The fix for #267 was made in November of 2017.

@jithunnair-amd  is on 1.7.x, but this applies to 1.8.0 as well, we verified that last evening with @jlgreathouse.

I ran into this issue on ROCm 1.9.211 today. An atomicAdd(double* address, double value), such as the one in /opt/rocm/hip/include/hip/hcc_detail/hip_atomic.h, implemented with a CAS loop using __longlong_as_double, gives incorrect results. Replacing __longlong_as_double with a chained reinterpret_cast solves the problem.

Could someone please post an update of where things are with this issue?

Looks like this has been fixed and merged into master, so ROCm 2.0 should have the fix.
https://github.com/ROCm-Developer-Tools/HIP/pull/667


Sample and model creation

How to create a model in UVR ?
I mmean, say i have my own set of audio files and i want to create a model to be used. For exmaple, i have 100 audio files containing random noises and i want to create a model able to remove those noises from an audio file. How should it be done in UVR ?
Also, what type of model it will create ? I want to create both types, one in onnx and other for python models.

Same here. I plan to train a model with a specified instrument that I can use to extract it from an ensemble. Does MDX-net work? How can I use it? Thanks!

I am wondering this as well. I could've sworn that there used to be details on this repository on how to train models but now I can't find anything so that's probably a false memory. Would love to see some details regarding training new models for UVR, specifically MDX-Net models.


calc_angles & calc_angles_idx

I'll try and make some progress on this over the next week.

This needs to be reopened with our rewrite as we removed the angles setup.


Check the requirements to run on Python 3.5

I was trying to run Deep Belief networks on python 3.5 and TensorFlow on windows, but when a I run the example code of the DBN (run_dbn.py), I found an issue with the module cPickle, are you aware of that error? Are there more issues than prevents the current version to work on python 3.5?
thanks in advance
BR

I guess you installed this project using pip because this is fixed in the current version of the code in the repo.
Just clone the code and do a manual install or just update the code in utils.datasets yourself.

I just uploaded the latest version to pypi, it should be fixed now.


a test for more reliable themes

Just a note here, I turned off http caching for the index because that's where the issue was, we still have data caching and that's the slowest part of the query. Will watch Sentry to see perf scores.


Extending inliner

I would like to create a wrapper of this library with Reveal.js specific modifications, for example in lining Markdown files, but I'm not too sure where to start. Is there a recommended way to extend inliner with custom tasks?

Load it via require and go from there. The API is pretty raw, but you might be able to extend as you require. Certainly I know it's been used to modify how URLs are managed in one instance.


Dynamic object keys issue

I am unable to get dynamic object keys working. I am not sure if I am doing something wrong inside of flow or if there is different syntax for flow and this plugin.
type ObjectTypes = {
  exists: string;
  sometimesExists?: string;

  // If any other keys exist, they should follow this pattern:
  [field: string]: {
    some: number;
  };
};

const passes_flow1 = (): ObjectTypes => {
  return {
    exists: 'some string',
    other: {
      some: 123,
    },
  };
};

const passes_flow2 = (): ObjectTypes => {
  return {
    exists: 'some string',
  };
};

const fails_flow1 = (): ObjectTypes => {
  return {
    exists: 'some string',
    sometimesExists: 'other string',
    other: {
      some: 'should be a number',
    },
  };
};

console.log(passes_flow1());
console.log(passes_flow2());
console.log(fails_flow1());

https://github.com/chrisblossom/tcomb-objects : entry.js
If you run npm run build it will fail, but npm run flow works as expected.

Didn't know you can mix maps and records
type ObjectTypes = {
  exists: string;
  sometimesExists?: string;

  // If any other keys exist, they should follow this pattern:
  [field: string]: {
    some: number;
  };
};

Definitely this syntax is not supported

Thanks for the reply. Anyway I can work around it? I am unsure how to declare a dynamic object that is not static until created (with the above schema). Maybe I am "abusing" flow maps?


introduce JUnit tag "flaky", to exclude tests from running.

ExampleTest.testClientCreation fails without real reason, mark it flaky at the moment. permit this tag in engine-tests/build.gadle.kts to separate test runs for normal integration tests, and ones which are not stable on github, for currently unknown reasons. normally of course it would be better to fix these tests - but accepting pull requests is coupled on tests running through. now two commands instead of one run all integration tests:
gradle integrationTest
gradle integrationTestFlaky

please do not lightheartedly mark tests as flaky.

The delay manager test fails so rarely that I wouldn't mark that one flaky, but the ExampleTests fail more frequently, so let's mark those flaky. Amusingly the one already marked flaky didn't fail this time :sweat_smile:

did not experiment with it, just looking at the code of the pipeline: if a normal test fails, how would we see the cause?

i am understanding correct, we still see the cause of any failed integration test?

in the sense that test failures are still reported including stack trace etc.? yes
but they shouldn't fail the pipeline anymore.


Missing Parameter for -EnableLEDBAT

The change is listed right here.
https://docs.microsoft.com/en-us/powershell/sccm/1810-release-notes?view=sccm-ps
Thanks!

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

ID: 65b57301-88d5-bd35-aeb3-f1722a896298
Version Independent ID: 1c2a0d53-b4d4-961f-067a-b5e71a15ffc5
Content: Set-CMDistributionPoint - Configuration Manager
Content Source: sccm-ps/ConfigurationManager/Set-CMDistributionPoint.md
Product: configuration-manager
Technology: configmgr-other
GitHub Login: @aczechowski
Microsoft Alias: aaroncz

Thanks @AbfSailor for the feedback. This content is mostly auto generated from what's in the module, but what's currently published is out of date. I have a pending update to bring it up to the latest version.


getClusterStatus

This API returns Profile/ClusterProfile instances matching a cluster and the status of each feature.
This PR simply changes the return value by flattening it first as requested by UI.
This is an example of returned value:
{"profiles":[{"profileName":"deploy-kyverno","profileType":"ClusterProfile","featureID":"Helm","status":"Provisioned"},{"profileName":"deploy-resources","profileType":"ClusterProfile","featureID":"Resources","status":"Provisioned"},{"profileName":"nginx","profileType":"ClusterProfile","featureID":"Helm","status":"Provisioned"}],"totalResources":3}

Results are ordered by:

Profile Type (ClusterProfiles before Profiles)
Profile Name
Feature ID

everything looks great to me! thank you Gianluca


Bump jest from 25.2.7 to 27.3.1

Bumps jest from 25.2.7 to 27.3.1:

Release notes
Changelog
Commits

It also bumps a large number of sub-dependencies, closing one or two Dependabot and npm audit warnings.
This includes two major releases of Jest, versions 26 and 27.
The main breaking changes are dropping support for older versions of Node.
Jest 27 also changes the default rest runner, which we need to undo to keep backwards compatibility so some old tests keep running.

This looks great (16 npm audit vulnerabilities gone!).
Looks like our Node versions are unaffected as well.
Do we need an issue to update those tests?

Do we need an issue to update those tests?

Yeah I think that would be good, it can be low priority though. I feel like it could take ten minutes to fix, or ten days 😅


Fixed #32319 -- Added ES module support to ManifestStaticFilesStorage.

This PR adds support to HashedFilesMixin for ES modules.
It builds on from https://github.com/django/django/pull/13843, which was reverted in https://github.com/django/django/pull/15064 due to https://code.djangoproject.com/ticket/33253
This PR uses an updated version of the original regex and includes the tests from the first PR that attempted to fix the issue of 33253, https://github.com/django/django/pull/15058
The updated regex is based on the idea in this comment, that we can limit the regex to only match for relative urls as module specifiers.
This works with the higlight.js file but not the type definitions from this review, https://github.com/django/django/pull/15058#pullrequestreview-798503096. Since they are a feature of typescript and not javascript, I think that's a fair trade off.

I vote to drop highlight.pack.js alltogether.

OK, fancy doing that @blighj? Thanks.

@carltongibson That is done now.


fix(aws-lambda): handle event. isBase64Encoded

🔗 Linked issue
#1778
❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[x] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
When POSTing a body to an AWS Lambda function, either using a function URL or behind an API Gateway, the event.body may be base64 encoded ; when this is the case, event.isBase64Encoded is set to true.
In such cases, body transmitted to local Nitro call should be base64 decoded.
Resolves #1778
📝 Checklist

[x] I have linked an issue or discussion.
[] I have updated the documentation accordingly.

Thanks!

Thanks @pi0 for the merge, took me a while to find the root cause of my issues (with @sidebase/nuxt-auth) yesterday 😅


Update action.yml

use single quote instead
if password include special latter like '$'.double quote will extend it and cause auth error

Fixes issue

fixes #18
Describe the change

How to verify it

Changelog text

Please verify and check that the pull request fulfills the following requirements

[x] Tests have been added or not applicable
[x] Documentation has been added, updated, or not applicable
[x] Changes have been rebased to main
[x] Multiple commits to the same code have been squashed

This was resolved with #20.


Crash: The requested module lz-string does not provide an export named 'decompressFromBase64'

Describe the bug
When initialising a new project using pnpm create, the public URL stays blank and Chrome logs the error
Uncaught SyntaxError: The requested module '/node_modules/.pnpm/lz-string@1.5.0/node_modules/lz-string/libs/lz-string.js?v=6bd9ceb9' does not provide an export named 'decompressFromBase64' (at ShikiMagicMove.vue:5:10)

This is probably related to https://github.com/slidevjs/slidev/commit/e199010f0eba9d0fb7f177d2ebaf2d3537b3592b
To Reproduce
Steps to reproduce the behavior:

Create new project using pnpm create <name>
Open dev server on /

Desktop (please complete the following information):

OS: macOS
Browser: Chrome
Slidev version: v0.48.0-beta.16

One more comment: maybe the install guides should point to a stable version, as this was not a very good first user experience with the software :)

v0.48.0-beta.18 should fix it with https://github.com/slidevjs/slidev/commit/76ae95dabc6c062a4f55ed4c4b586eb0a8bc46e4
Thanks for reporting.
Having the beta version as the latest tag on npm is our intentional strategy to encourage trying and providing feedback. The beta status doesn't necessarily imply it's unstable, but more like a state we are not ready for everything (#1335) and that's why feedbacks are important to us. For the case of this issue, it's an unintentional regression that was introduced back in a few "stable" versions back but only surfaced in the recent change - anyway, thanks for reporting and the suggestions.


RBAC errors in the Kabanero operator log when applying the sample/default collection

The following RBAC errors are observed in the operator log when applying the default collection:
"error":"serviceaccounts \"appsody-sa\" is forbidden: User \"system:serviceaccount:kabanero:kabanero-operator\" cannot get serviceaccounts in the namespace \"kabanero\": no RBAC policy matched"

and
"error":"clusterrolebindings.rbac.authorization.k8s.io \"appsody-admin\" is forbidden: User \"system:serviceaccount:kabanero:kabanero-operator\" cannot get clusterrolebindings.rbac.authorization.k8s.io at the cluster scope: no RBAC policy matched"

Some consideration is needed as to how much authority the Kabanero operator service account should have, or whether someone should be pre-configuring some of these roles at the cluster scope so that the service account does not need cluster admin authority.

@smcclem and @kvijai82 and I worked thru a sample development kabanero pipeline today.  To get past the RBAC errors above we added the following permissions to the service account that the operator uses:
get,create,list serviceaccount, persistentvolume, clusterrolebinding
(the pipeline setup included a PV)
This got us most of the way there.  However the cluster role binding turned out to be trying to grant cluster-admin authority to the service account running the pipeline, and the Kabanero operator does not have cluster-admin authority and therefore cannot give cluster-admin authority.
We added cluster admin authority to the service account running the Kabanero operator:
oc adm policy add-cluster-role-to-user cluster-admin -z kabanero-operator

This got us past the last RBAC issue, however it's pretty heavy-handed and now the Kabanero operator has permission to do just about anything.  Some additional thought is needed here.

consider using RH buildah push instead of docker push to avoid elevated perms for PV

Yes, I did not use the script and therefore was not aware of the pseudo-requirement that the kabanero-operator service account has cluster admin privileges.  If this is expected at this point, then we should just change the role.yaml to have cluster admin privileges and be done with it.

So I think for 0.1.1 we should assume kabanero operator has cluster-admin, and we can either work to reduce that authority in the near term future or wait for requirements to reduce it.

I agree

script was moved here https://github.com/kabanero-io/kabanero-foundation/blob/master/scripts/install-kabanero-foundation.sh
release is updated.
KABANERO_BRANCH="${KABANERO_BRANCH:-0.1.0}"
script still has
oc adm policy add-cluster-role-to-user cluster-admin -z kabanero-operator -n ${namespace}
removing the  release-0.1 tag since Steve says we will look into the future.

I am removing the status red label since this is not targeted for a release and therefore the red label makes no sense.

The kabanero operator seems firmly entrenched in "cluster admin" mode right now, so I'm going to close this issue and we can re-open it when having cluster admin authority becomes a problem.


bug: java.lang extention not working with neovim 0.9.1

Did you check docs and existing issues?

[X] I have read all the LazyVim docs
[X] I have searched the existing issues of LazyVim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
0.9.1
Operating system/version
Manjaro Linux
Describe the bug
See:
https://github.com/LazyVim/LazyVim/issues/1207
neovim 0.9.1 does not support the vim.fs.joinpath function, but this function is used in extension java.lang
"-configuration",
vim.fs.joinpath(jdtls_cache_dir, "config"),
"-data",
vim.fs.joinpath(jdtls_cache_dir, "workspace"),
Steps To Reproduce
https://github.com/LazyVim/LazyVim/issues/1207
Expected Behavior
java.lang extention working with neovim >= 0.8.0
Repro
No response

Didn't you already post an issue about this and was fixed?


Bug: 'Offline mode' unknown authors

Description of Problem or Question
Problem: offline mode's sorting by author doesn't work.
Scenario 1:

Create a new scenario in the editor and fill in 'Authors' and 'Single text line for Authors' fields. Save changes.

Go to SE and switch to Offline mode.
Open Sort menu and select Author.
Although you've written all the authors' fields, SE will still show 'Unknown authors' message at the top.

Scenario 2:

Go to SE online mode.
Sort by Author Asceding.
Find Miss Fernwood and EtiCarasoft's scenario (it should be the first one, the scenario has a valid author) and download it.

Go Offline.
Sort by Author.
The scenario is seen as if it didn't have an author field filled in although it has.

Valkyrie Version
valkyrie-windows-2.2.00b

Thanks for the all the details.
It's now fixed.
I've also limited max length so it fits the grey line.

@BenRQ, it hasn't been fixed. The quest.authors_short part :).

Yes indeed, don't know how I missed that :(
It's fixed now.


Guidelines for mmol users

Awesome app, thanks.
Could you add guideline options to suit mmol users, I'd like guidelines at 18, others may like 36.

Great idea, thanks! I just implemented this in https://github.com/mddub/urchin-cgm/commit/970074.


Enhance! how to display image in the center of the QR code.

Thanks for your great work.
I have wrote a feature of display image in the center of the QR code.
Could I send a PR to you? Or would you accept the feature of mentioned above?

Is it working ? I am trying to center QR code.


Cannot find saves in archive with arabic letters (props other special characters) in folder names

Do the /raw_folder_decrypt or any command with a save_files option with this archive,  and the bot will not be able to find saves in it, will get and error
Invalid archive after downloading it https://cdn.discordapp.com/attachments/1147840126106488872/1277317817276043375/arabic_folder_names_enc_save.zip?ex=66ccba6b&is=66cb68eb&hm=6a28d8d6d36ac32d155ba814c600a1401ec037d67e9559e5447be2bffe2f74b3&, error when unpacking Exception: did not find ___ ___ _____\CUSA09171\SAVESERVICE-LINE-0-2Slot in the thing

this is an issue with the 7zip cli tool, rendering arabic letters as underscores, which are useless as it cannot extract with such thing

fixed in https://github.com/Zhaxxy/eZwizard3-bot/commit/a374424b98873f840d27381a86fe63d8c188c060


Create rcrestore command

@geekgonecrazy excellent point on locking the service prior to restoring. I completely overlooked that. Would you be able to draft a quick example? I've never dealt with PID files.

@elespike  request to change prime back to snap for now, as many of us have older builders.  Thx

@elespike  I'll make some snap stability fixes on the base, so you might see a conflict - just a heads-up.


Unicode characters

For some reason there is issues with unicode characters. Ex. Æ L Å.
My Røde profile therefor needs to be called Rode to work.
Most likely a encoding difference between Touch Portal and GoXLR.
Should be a simple fix.

This seems to be a TouchPortal issue. When decoded æøå is replaced with ???.
I have tried to decode using all types of encoders, but this seems to be broken in TouchPortal before transit.

This seems to be a TouchPortal issue. When decoded æøå is replaced with ???.
I have tried to decode using all types of encoders, but this seems to be broken in TouchPortal before transit.

This is fixed in the TouchPortalSDK branch, that targets the 2.3 version of TouchPortal.
Now there is another issue with TP 2.3, that makes the singles profiles not work. Waiting for a fix (or I need to modify the entry.tp file a little).

Released 0.6


Change the tree parsing logic to avoid copying bytes

Changes:

While parsing heads, do not create a reference and then immediately dereference them.
Instead of using the take and clone methods while parsing the decompressed bytes of a tree object, we simply find the respective starting and ending offsets and pass a reference to that slice of the array to the slice_to_hex function.
Use position method for an iterator instead of chaining find and map when we are only concerned with the index.

Hi, I appreciate that you wish to improve git-dumper but this change doesn't really add much value. It essentially removes 1 heap allocation in an application that is network-bound and applies some minor code quality improvements. I consider git-dumper functionally done, so changes like this don't measurably improve the app and just increase maintenance cost on my end.
Feel free to continue hacking on your fork, though! git-dumper is permissively licensed and you're free to do whatever you want with the source code. If you want you can rewrite the entire thing but I don't currently have the time or motivation to review minor changes for PR.


icons not showing until zoomed in

[x ] bug report -> please search issues before submitting
[ ] feature request
[x ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

When you have a map that has multiple points it only renders some of the icons and then the missing ones will show when you start to zoom in??
We are using the standard example for points in a route
var sPoint = new atlas.data.Feature(new atlas.data.Point([dataHere]), {
      title: 'Im the title ',
        icon: 'pin-blue',
        allowOverlap: 1
    });

In the icon options, try setting the allowOverlap and ignorePlacement options to false.

This issue has not been solved as allowOverlap and ignorePlacement set to false make the problem worse. I will show you in images below with false has icon 2 and 3 missing until zoomed.

Set those values to true. Not sure why I said false before, that's the default.

It could also be that the lineSpacing value is too big and when zoomed out only one arrow appears and it is behind another icon.


Check ECC functionality works

Check ECC reading works

Broken down in:

https://github.com/NebraLtd/hm-diag/issues/317
https://github.com/NebraLtd/hm-diag/issues/319


feat(Link): add secondary link color

Ref FEP-1446

@anakreon could you please add getLinkStyle docs in here https://github.com/securityscorecard/design-system/blob/main/src/utils/helpers.stories.mdx

@anakreon could you please add getLinkStyle docs in here https://github.com/securityscorecard/design-system/blob/main/src/utils/helpers.stories.mdx

Yeah, I'm thinking if it makes sense to include these two in the 'utils/helper' file... They seem quite specific to link / button 🤷♂. But i suppose we can clean that later if it's cluttered


check-ttf.py: fullname name length

Hello @felipesanches and @davelab6,
I see we're checking if the fullname is under 64 characters. I thought the limit was 32, regardless of field type?
Also, hope you had a cracking xmas and NYE

As an atheist I do not celebrate christmas. But I do drink the wine and eat the good food! It is also a great opportunity to meet all of the family :-)
Regarding the max allowed length for fullname, I'm not sure right now. I'll take a look at this again once I get back to work next Monday Jan 9th.
cheers!

Felipe, what about https://stallman.org/grav-mass.html ? :)  32 sounds more
likely, but would be good to check the MSFT OpenType specification on
this... I took a quick look at
https://www.microsoft.com/typography/otspec/name.htm but couldn't quickly
find an answer to this.

I was not able to find a definitive answer in the spec either.
I remember this being an issue in the past and I'm also guessing 32 is the max.

Seems easy to empirically verify
On Jan 4, 2017 10:13 AM, "Marc Foley"<EMAIL_ADDRESS>wrote:

I was not able to find a definitive answer in the spec either.
I remember this being an issue in the past and I'm also guessing 32 is the
max.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/googlefonts/fontbakery/issues/1190#issuecomment-270337517,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP9y3iA8zA5qnwPOaripeje_uQwQqUTks5rO3C_gaJpZM4LZo0g
.

Alright, @anthrotype pointed me towards the AFDKO, MakeOTFUserGuide.pdf documentation. You have to download the afdko to get it. It states, pg 9:

Note on length restrictions
Because of limitations in operating systems and common applications, it is recommended that none of these keys contain names longer than 31 characters.  Thiis results in menu names for legacy environments being 31 characters or less. The OpenType menu name (used in Adobe InDesign® and future Adobe applications) may be thought of as the combination of the f= and s= keys. Since each of these can be up to 31 characters, the OpenType menu name can be up to 62 characters.

This all sounds rather legacy to me. I'll do some testing in win7 Notepad with fontnames over 31 and 62 chars long. This should end the rumours.

Fullname: 31+ chars & font name < 32 chars:
I tested EncodeSansSemiCondensed-ExtraBold.ttf.
Font Name: 11 characters
Full name: 35 characters

The font menu names are behaving as they should.
Fullname: 62+ chars & font name > 31 chars:
Had to make a custom font. Font name 'The Quick Brown Fox Jumps Over The Lazy Dog'.
Font Name: 43 characters
Fullname: 67 characters

Oh dear, The name gets cut off at 31 characters long, 'The Quick Brown Dox Jumps Over '.
What about OS X?

No issues.
Ok, does the NAME table not accept certain fields over 31 characters?
Generating the fonts doesn't chop any fields down to 31 chars. This is an MS specific issue.

screenshots from OT Master
It looks like Fontbakery is correct. Postscript name and Fullname can be over 31 characters. Font name and style fields should be under 31.
Hope this all makes things clearer.

Closing this since our implementation is good.


Added org.eclipse.jetty.toolchain:jetty-jakarta-servlet-api to JavaxServletApiRule

For that one I'm not really sure whether the behavior is the desired one.
The org.eclipse.jetty.toolchain:jetty-jakarta-servlet-api dependency seems to be a bundle that contains both the javax.servlet:servlet-api, jakarta.servlet:jakarta.servlet-api, additional module-info.java and xml files.

I can't see any javax classes in https://repo1.maven.org/maven2/org/eclipse/jetty/toolchain/jetty-jakarta-servlet-api/5.0.0/jetty-jakarta-servlet-api-5.0.0.jar
But the jakarta variant is in there.
In my mind, this has to move to JakartaServletApiRule, or do I miss something @DreierF?
If not, would you mind updating this PR? If you rebase main, the samples/sample-all test will now tell you if there are duplicated classes when you add a new dependency (and the rules aren't right yet).

Thanks for taking a look!
 I was mislead by the fact that the jar contains some non-class files in the javax folder, but it actually only contains jakarta classes.
I moved the artifact to JakartaServletApiRule and rebased on lastest main.


completed examples : Paris Walters

Hi Paris!
We don't want to remove/rename the example file, can you please create a new one with your name?


Empty table header found in the 'Your locked pages' dashboard section

Issue Summary
Initially reported by @albinazs as part of WCAG 2.2 AAA* audit of the Wagtail admin – Nov 2023.
We seem to be using an empty table header and table cells for spacing, to align this report with others on the page. That’s fine, but the column should then be hidden from screen reader users so they don’t hear “blank” when navigating the table (it’s confusing and makes it harder to navigate the table). This is likely a failure of 1.3.1 Info and Relationships.
Steps to Reproduce
See demo: Your locked pages section
See https://github.com/wagtail/wagtail/blob/main/wagtail/admin/templates/wagtailadmin/home/locked_pages.html#L59, and the corresponding 	.
Working on this

Anyone can contribute to this. This should be a simple template change. Make sure you know how to test this with a screen reader. View our contributing guidelines, add a comment to the issue once you’re ready to start.

@thibaudcolas
hi, can i work on this?

I guess without changing much, just adding "aria-hidden=true" attribute to  might work, please tell @thibaudcolas or should I approach some other method.

@GetRohitansh give that a go, load up a screen reader and check, sounds like a good idea.
Another approach can be role="presentation"
see https://www.a11ytips.dev/docs/roles-vs-presentation/

@GetRohitansh  as per comment on #11465
There are another bunch of 	 in Wagtail, some in templates and some in other generated code.
Feel free to raise a new PR that cleans these up also, remember to create a new branch for this work and read the contributors guide first though :)
As for the 	, it appears that some are in JavaScript, if updating these be sure to update the Jest snapshots (npm run test:unit -- -u) but also ensure that the JS code does not 'fill these in' with titles somehow first.
Here's the files

https://github.com/wagtail/wagtail/blob/c99c74cc7e5f7d534fecb6ab0be5a9c7c4da682a/client/src/entrypoints/contrib/typed_table_block/typed_table_block.js#L79
https://github.com/wagtail/wagtail/blob/c99c74cc7e5f7d534fecb6ab0be5a9c7c4da682a/wagtail/admin/templates/wagtailadmin/permissions/includes/collection_member_permissions_formset.html#L29
https://github.com/wagtail/wagtail/blob/c99c74cc7e5f7d534fecb6ab0be5a9c7c4da682a/wagtail/admin/templates/wagtailadmin/workflows/includes/workflow_pages_formset.html#L20
https://github.com/wagtail/wagtail/blob/c99c74cc7e5f7d534fecb6ab0be5a9c7c4da682a/wagtail/admin/ui/tables/pages.py#L75
https://github.com/wagtail/wagtail/blob/c99c74cc7e5f7d534fecb6ab0be5a9c7c4da682a/wagtail/users/templates/wagtailusers/groups/includes/formatted_permissions.html#L123
https://github.com/wagtail/wagtail/blob/c99c74cc7e5f7d534fecb6ab0be5a9c7c4da682a/wagtail/users/templates/wagtailusers/groups/includes/page_permissions_formset.html#L28

wagtail/admin/static_src/wagtailadmin/js/vendor/jquery.datetimepicker.js (ignore this file, it's going to be removed in the near future)


Support generic sidecar for both services and database creation/update jobs

Discussed in https://github.com/alexandrevilain/temporal-operator/discussions/599

Originally posted by djMax January  3, 2024
We are running in GCP (GKE) using a CloudSQL postgres instance. I have added the cloudsql sidecare to the deployment overrides, but it seems like the operator spins up a bunch of jobs first, and those jobs do not inherit the sidecar options. Is it possible to use the operator to deploy in a GCP CloudSQL environment?

So I did get this working in the temporal helm chart and here are my notes if they are helpful. The sidecar is pretty straightforward, BUT:

Most use cases will want the jobs/pods to run with a specific serviceAccount so that the proxy can handle auth
Most use cases will not require a password for the db (since it's localhost) and so it's a waste to create secrets for fake passwords (so this should allow some dummy password)
All services need to wait for the proxy to be ready. I had to modify the temporal docker container commands to versions of this:

          command: ["/bin/sh", "-c"]
          args:
            - |
              until nc -z localhost 5432; do
                echo "Waiting for PostgreSQL to be available on port 5432..."
                sleep 1
              done
              sleep 1
              echo "PostgreSQL is up and running on port 5432!"
              temporal-sql-tool setup-schema -v 0.0

or
          command: ["/bin/sh", "-c"]
          args: ["sleep 5; /etc/temporal/entrypoint.sh autosetup"]

Thanks for the valuable insights.
Are you interested on contributing to add this feature on the operator ?

If I can help I certainly will, but I will say operators have always confused me and this one is big enough to be no exception. But if you point me I can chase.

@djMax for sure I can help you with your first contribution on an operator :)

Closing as sidecars are now available in the API.


[Change Request] codeunit 1013 "Job Jnl.-Post Batch" - GuiAllowed

Hello, can you please add the GuiAllowed condition to the local procedure UpdateAndDeleteLines() in codeunit 1013 "Job Jnl.-Post Batch"?
local procedure UpdateAndDeleteLines()
var
    IsHandled: Boolean;
begin
    OnBeforeUpdateAndDeleteLines(JobJnlLine);

    with JobJnlLine do begin
        if JobRegNo <> 0 then
            if JobJnlTemplate.Recurring then begin
                // Recurring journal
                LineCount := 0;
                JobJnlLine2.CopyFilters(JobJnlLine);
                JobJnlLine2.Find('-');
                repeat
                    LineCount := LineCount + 1;
                    if GuiAllowed then begin
                        Window.Update(5, LineCount);
                        Window.Update(6, Round(LineCount / NoOfRecords * 10000, 1));
                    end;
                    if JobJnlLine2."Posting Date" <> 0D then
                        JobJnlLine2.Validate("Posting Date", CalcDate(JobJnlLine2."Recurring Frequency", JobJnlLine2."Posting Date"));
                    if (JobJnlLine2."Recurring Method" = JobJnlLine2."Recurring Method"::Variable) and
                       (JobJnlLine2."No." <> '')
                    then

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 13340.

@JesperSchulz is there any chance to get this into BC23.3?
I can only see those changes for BC24.0.
Our customer has the request to post some Job Journals via Job Queue, but this is currently not possible.

Sure :) Special favor coming right up! I'll push it to 23.x now.

Could you include the related issue https://github.com/microsoft/ALAppExtensions/issues/24515 there, too?

Availability update: We will publish a fix for this issue in the next update for release 23.
Build ID to track: 14861.


Add support for exposing service ports on run

This stems from a need for a step run in a container to have a port exposed that can be connected to from an external testing service whilst it is running.
By default docker compose run does not create the service ports so this adds a configuration to optionally to add the --service-ports option which enables the service ports and maps them to the host.
The default run configuration is not affected.

@toote Thanks for the quick review. Updated as suggested.


[Event Request] Codeunit 392 Reminder-Make - OnBeforeCustLedgEntryOnHold

Hi, would it be possible to get an event OnBeforeCustLedgEntryOnHold in codeunit 392, procedure FindAndMarkReminderCandidates, like this :

repeat
           FilterCustLedgEntries(ReminderLevel);
           if CustLedgEntry.FindSet then
               repeat
                   if CustLedgEntry."On Hold" = '' then begin
                       IsHandled := false;
                       OnBeforeCustLedgEntryOnHold(CustLedgEntry,IsHandled);
                       if not IsHandled then begin

 [IntegrationEvent(false, false)]
    local procedure OnBeforeCustLedgEntryOnHold(var CustLedgEntry: Record "Cust. Ledger Entry"; var IsHandled: Boolean)
    begin
    end;

?
Thanks

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Added entries for sx and sxdg in template substitution cost

Summary
Fixes #7585.
Added entries for sx and sxdg in template substitution cost
Details and comments
In TemplateSubstitution class (used for TemplateOptimization transpiler pass feature), subcircuits are compared for cost. Although it is also possible to specify a user defined cost mapping per gate, the default cost dictionary did not have entries for 'sx' and 'sxdg' gates. This led to an exception when the input circuit contained these gates. In this PR, this has been fixed by adding these keys in the default cost dictionary with the value 1 for each. This is in line with the current implementation which assigns a hardcoded default value of quantum cost.
Also added a testcase.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 83.157%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
51910

Relevant Lines:
62424

💛  - Coveralls

hi @dhruvbhq are you still working on this?

Thanks for letting us know @dhruvbhq, I'll close this PR but if you would like to come back to it at a later date just let us know and we can reopen it 😄


Delay in burst duration

@ajbalogh
"delay" field is missing in "burst" duration.
Also, for rest of the choices (fixed_packets, fixed_seconds, continuous and burst) for the field of "gap", don't we have to mention the gap unit?

        gap:
          description: >-
            The minimum gap between packets expressed as bytes.
          type: integer
          default: 12