Distinguish experimental structures from theoretical

As suggested by @BobHanson, there should be standard means to distinguish between experimental and theoretical structures. This could be a property with boolean/enum values. I would suggest "MUST" level of support (maybe even for queries), as I believe this bit of information should always be available.

Could we get away with defining a new enum value in structure_features for this?

Could we get away with defining a new enum value in structure_features for this?

Sounds good to me. Should it be theoretical for theoretical structures? Or rather experimental for experimental ones? Which is more natural? For me it is theoretical, but I come from experimental background, hence my bias :smile:

I think we will need to have both theoretical and experimental. That way we can implicitly also have the case where it is undefined, which may be useful for old entries for which it was not recorded whether it is a theoretical or experimental structure, or simply for databases that have not been updated.
What you are proposing does stretch the meaning of the structure_features field, which is defined as: A list of strings that flag which special features are used by the structure.
Perhaps this is also a good moment to think about how we want to include more detailed information about how the structure was generated. Especially information that would be interesting for generating structures. X-ray scattering or neutron scattering, ab initio calculations. The software package that was used. etc.

Reading @JPBergsma and @BobHanson responses I am now leaning towards separate property. It could actually provide more information about the origin of a structure. In the COD, we have a CIF data item _cod_struct_determination_method with the following possible values: single crystal, powder diffraction and theoretical. Maybe something similar could be introduced into OPTIMADE.

This sounds great to me. But can you have theoretical PD? Re there two concepts here?
data[i].nature: {"experimental"|"theoretical"}
data[i].method: {"single crystal diffraction"|"powder diffraction"}

This sounds great to me. But can you have theoretical PD? Re there two concepts here?
data[i].nature: {"experimental"|"theoretical"} data[i].method: {"single crystal diffraction"|"powder diffraction"}

Right. Then these should be separate properties.

How should we name such a property? Some suggestions:

nature
origin
determination_method.

Personally, nature does not sound immediately clear to me, origin might also be quite ambiguous.

Personally, nature does not sound immediately clear to me, origin might also be quite ambiguous.

Yes, I also would not know a good name for this distinction. From the suggestions above I found determination_method the clearest. But perhaps we can also name it simply experimental_or_theoretical .

experimental_method?
On Wed, Jun 1, 2022 at 6:14 PM Johan Bergsma @.***>
wrote:

Personally, nature does not sound immediately clear to me, origin might
also be quite ambiguous.
Yes, I also would not know a good name for this distinction. From the
suggestions above I found determination_method the clearest. But perhaps
we can also name it simply experimental_or_theoretical .
—
Reply to this email directly, view it on GitHub
https://github.com/Materials-Consortia/OPTIMADE/issues/406#issuecomment-1143812327,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEHNCW5BWGG7JETSFPHBJBDVM6D7LANCNFSM5XMWYTBA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
We stand on the homelands of the Wahpekute Band of the Dakota Nation. We
honor with gratitude the people who have stewarded the land throughout the
generations and their ongoing contributions to this region. We acknowledge
the ongoing injustices that we have committed against the Dakota Nation,
and we wish to interrupt this legacy, beginning with acts of healing and
honest storytelling about this place.

@JPBergsma: experimental_or_theoretical will need renaming should more enumerator values be introduced (i.e., mixed or something else).
@BobHanson: "experimental_method": "experimental" sounds slightly wonky to me.

Ah, right. This was in reference to
experimental_method: {single crystal diffraction | powder diffraction|...}
investigation_type: {experimental | theoretical}
brainstorming...

Following the discussion with @sauliusg I can also point out many edge cases where the experimental or theoretical nature is not immediately clear. An example is de-novo crystal structure refinement, see [1], [2], and many more.

not voting for "computational experiment". I understand the desire to
consider computational approaches "experiments" but I think this is not
well understood.
On Fri, Jun 3, 2022 at 2:54 PM Evgeny Blokhin @.***>
wrote:

cf. computational experiments vs. experimental modeling
—
Reply to this email directly, view it on GitHub
https://github.com/Materials-Consortia/OPTIMADE/issues/406#issuecomment-1145934888,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEHNCW4SIE52SO7NPZNI6XLVNH6BXANCNFSM5XMWYTBA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
We stand on the homelands of the Wahpekute Band of the Dakota Nation. We
honor with gratitude the people who have stewarded the land throughout the
generations and their ongoing contributions to this region. We acknowledge
the ongoing injustices that we have committed against the Dakota Nation,
and we wish to interrupt this legacy, beginning with acts of healing and
honest storytelling about this place.

experimental_or_theoretical will need renaming should more enumerator values be introduced (i.e., mixed or something else).

Yes, you are right, that is not convenient.
How about method_class or method_category ? That allows another field named method that holds a more specific term for the procedure used to generate the data.

Indeed, there is a whole spectrum of methods ranging from purely experimental (can we actually get coordinates without any theoretical assumptions?) to purely theoretical. We probably would need a separate ontology just to identify where a structure sits in that spectrum.

But for our purposes suggest not reinventing the wheel or overcomplicating.
Go with the ICSD conception here. Keep it simple. Maybe allow for some
ambiguous third category but don't insist that every conceivable possibly
is covered.
On Mon, Jun 6, 2022, 2:03 PM Andrius Merkys @.***>
wrote:

Indeed, there is a whole spectrum of methods ranging from purely
experimental (can we actually get coordinates without any theoretical
assumptions?) to purely theoretical. We probably would need a separate
ontology just to identify where a structure sits in that spectrum.
—
Reply to this email directly, view it on GitHub
https://github.com/Materials-Consortia/OPTIMADE/issues/406#issuecomment-1147373570,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEHNCW4I4HLX22N2WPIEFZTVNXSKJANCNFSM5XMWYTBA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I understand the desire to add something ASAP to help distinguish experimental and theoretical structural data. However, I'd suggest to be careful to not over-design this interface, since it is debatable if this info even belongs in this endpoint. Going forward, we won't be able to stuff all possible experimental and theoretical details related to a structure into the structure endpoint and, at least for theoretical structures, I believe our consensus is that things like "which method", etc., belongs in the calculations endpoint with relationships to "input" and "output" structures.
Hence, I suggest this to just be a simple boolean field: experimental that is defined to be True if, and only if, the structural data, including the atomic coordinates, represented by the structure have been obtained more or less directly out of an experiment and thus the crystal structure reasonably can be understood to have been observed in nature.
The alternative, False, just means that the structure has been obtained some other way. E.g., hypothetical structures through substitutions (perhaps including DFT relaxations, etc., but not necessarily), structure prediction algorithms, just random initialization, etc. No guarantees that these structures "make sense".
(Or is there a very strong desire to also distinguish theoretical structures that the database strongly believes are at, or very close, to the convex hull of stability? This, I believe, is the ICSD criterion for inclusion.)

Unfortunately it starts to be complicated here. Imagine we took an experimental structure and relax it fully with the DFT, ending up with the different cell, symmetry, atomic positions, etc. Is the structure still experimental?

@blokhin

Unfortunately it starts to be complicated here. Imagine we took an experimental structure and relax it fully with the DFT, ending up with the different cell, symmetry, atomic positions, etc. Is the structure still experimental?

It was my intent to mostly avoid this complexity by a single stringent definition separating everything into "directly from experiment" vs. other. My definition above was meant to say that your example is not an experimental structure.

Following the discussion with @sauliusg I can also point out many edge cases where the experimental or theoretical nature is not immediately clear. An example is de-novo crystal structure refinement, see [1], [2], and many more.

I think my suggestion was for actual vs hypothetical which maybe makes this slightly clearer (though shifts the vagueness elsewhere, e.g. whether a DFT database that simply took experimental structures and calculated band gaps without relaxing should report itself as hypothetical or actual).
The two relevant axes for filtering seem to me to be whether something has actually been made, and whether the structure is simply the result of minimising or sampling of a Hamiltonian

Sorry -- that ICSD paper reference:
https://journals.iucr.org/j/issues/2019/05/00/in5024/index.html and
supporting information
Noting that there is a discussion of this in matsci.org
https://matsci.org/t/how-is-the-theoretical-tag-determined/3527
So perhaps the boolean "theoretical" is appropriate (matching ICSD). But
this post does point out the same issue -- that it is not always possible
to distinguish. I think one would just have to trust repositories to do
their best job here. AFLOW could distinguish (perhaps?) between their ICSD
entries (which are presumably NOT theoretical) from their calculations. @
@.*** (Cormac)
I do feel strongly that there MUST be some sort of flag regarding this.
Serving up purely calculated structures is not the same as delivering x-ray
crystallographic results. This is a widespread, growing issue throughout
the data world. My recommendation: keep it simple.
Bob

Having read the discussion, I tend to agree with those of you favoring single boolean flag. The question now is where to draw the line. However, neither ICSD paper nor related discussion on matsci.org does provide clear criteria (thanks @BobHanson for links, though). @vaitkus, maybe IUCr has put up any criteria?
I am a bit skeptical regarding the structures relationships with calculations though. In TCOD we have theoretically calculated structures from journal publications, but usually machine-readable metadata related to actual calculations is scarce (but reported in human-readable publications). Thus if calculations entries become mandatory for theoretical structures, we would not be able to return much meaningful data in them.

@merkys, as far as I know, the IUCr does not have any such criteria.
However, the ICSD paper lists three types of subclasses of theoretical structures:

Predicted (non-existing) crystal structure.
Optimized (existing) crystal structure.
Combination of theoretical and experimental structure.

Based on this, I would say that according to them anything that is not purely experimental is classified as theoretical.

@merkys

I am a bit skeptical regarding the structures relationships with calculations though. In TCOD we have theoretically calculated structures from journal publications, but usually machine-readable metadata related to actual calculations is scarce (but reported in human-readable publications). Thus if calculations entries become mandatory for theoretical structures, we would not be able to return much meaningful data in them.

I don't think anyone proposed to make them mandatory for theoretical entries? Just that if you have data or metadata related to the calculation itself for, say, a calculation that started from one structure, and resulted into a couple of output structures, that data would better belong under the calculations endpoint than being stored alongside the structures. For example, if you want to provide details on cutoffs, k-point grids, DFT functionals, etc.

I don't think anyone proposed to make them mandatory for theoretical entries?

No. I mistakenly assumed this was the suggested solution for telling experimental structures from theoretical.

Just that if you have data or metadata related to the calculation itself for, say, a calculation that started from one structure, and resulted into a couple of output structures, that data would better belong under the calculations endpoint than being stored alongside the structures. For example, if you want to provide details on cutoffs, k-point grids, DFT functionals, etc.

Agree.

Q1: Are theoretical and experimental the correct two options?
I suggest yes:
There is a paper from ICSD: Recent developments in the Inorganic Crystal
Structure Database: theoretical crystal structure data and related features
http://scripts.iucr.org/cgi-bin/paper?in5024, where, for example, we see:
In order to be included in the ICSD, a theoretical structure has to be
fully characterized, the atomic coordinates determined and the composition
fully specified, similarly to* experimental structures*.
Table 1
Comparison of databases containing experimental and/or theoretical crystal
structures
(14 uses of "experimental structure")
(26 uses of "theoretical structure")
So, I argue, these are the terms to use.
As for
xxx_yyy = { experimental | theoretical }
I suggest NOT using "structure_type" as that actually means something
different.
Maybe "determination_type"
"experimentally determined structure"  Google 20,000 hits.
admittedly,
"theoretically determined crystal structure" has only 3 hits. So many that
is a bit of a problem.
Next idea?

Revisiting this ahead of today's meeting... we are currently very open to (and in fact should be encouraging!) huge databases of ML structures (not even necessarily ab initio/MM refined) suddenly swamping out all of our multi-provider queries.
I still think the lowest friction way of adding this would be with specific structure_feature tags that could be eventually be promoted to standalone properties (in say, v2...). Some concepts that we've discussed that could be added as tags:

experimental: atomic coordinates arise directly from an experimental technique
asdfasdfsaf/computed?: calculation models a known experimental structure (somehow the opposite of hypothetical, which should be the default, but cannot think of a good name)
~stable: a database-local assessment of thermodynamic stability -- strictly I would say this should be the exact structures that form the convex hull that other structures are assessed against (bundling this in here feels like cheating but we are really making no progress on getting people to add their stability data to OPTIMADE when they have it).~ (I still want this but we can discuss in another issue)

This would render our default structure with structure_features = [] as purely hypothetical, "unstable" and not experimentally derived.
Potential nasty side effects:

databases that do not control what gets put into them (very roughly speaking), e.g., NOMAD, MaterialsCloud etc. would be "stuck" at this default level without extra work (e.g., structure matching, a la NOMAD encylopedia).
additional work needed by those who do serve data that goes beyond the "default" above, e.g., every COD entry gets set to experimental, every MP entry that has an associated ICSD code becomes computed (or whatever).
we slightly trample on the current definition of structure_features which is purely an implementation detail of: which exotic OPTIMADE features does this structure require to be conveyed through the OPTIMADE structure type. This definition would have to be significantly broadened to accommodate the above, though personally I think the field name is vague enough that this wouldn't be too much of a headache.

I really think that this is the biggest added-value change we could make to OPTIMADE right now, and its something we need to do if we want to scale out to new databases beyond our existing community

Thanks for reviving this issue. Admittedly, structure_features approach has its appeal, but side effects seem way too serious to me. Having a property taking values experimental or theoretical with "do not assume anything" as a default has less drawbacks (I think). Then there is the whole spectrum in between, but I do not think we can tackle them anytime soon.

I agree with that we should rush this feature.
I'd rather not place it in structure_features, since the idea was that if a client sees anything in there that it doesn't recognize, it should not assume it understand how to represent the structure. This info is not that. But, why not just under a new name?
We can do a list the same way as  structure_features works, e.g., structure_classes, structure_types, structure_tags? On the other hand, experiment vs computed (refined, processed?) seems mutually exclusive, so isn't it better to just represent this info as a single string? We define what we have now, but remain open to additional strings in the future.
So, here is a concrete proposal:

Field name: structure_origin is a string that SHOULD take one of the following values:

experimental [as defined by @ml-evs] all the structural information (coordinates, elements, assemblies, etc.) is a direct and unmodified representation of the outcome of an experimental technique for structure determination.
processed: the structural information originates from experimental data, but has been further processed in such a way that the resulting structure still is recognizable as the experimental one it was based on. For example, structures that have undergone relaxation using ab-inito calculations with the experimental structure as the starting point are meant to be placed in this category. Structures that have substituted one or more elements (but otherwise kept the experimental coordinates the same) are not meant to be in this category. Ultimately there is a level of subjectivity in this definition which is to be decided by the database provider.
predicted: the structural information has no direct connection to the outcome of an experimental technique on an existing material, but has undergone theoretical processing that motivates the database provider to suggest it as a candidate for a synthesizable structure. This category is intended for, e.g., theoretically invented structures relaxed using ab-inito calculations and found to end up close to the convex hull of stability, or structures generated out of an AI model demonstrated to have a reasonable predictive power. This category definition has a rather high level of subjectivity which has to be decided by the database provider.
hypothetical: the structure comes with no guarantee of having any relationship to structures existing in nature. This category is encouraged for, e.g., randomly placed atoms used as a starting point for further processing or the outcomes of AI models for which the predictive power is not deemed sufficient for predicted.

If the field is missing or equal to an empty string or null, it means no guarantees are given with respect to the origin of the structure (which can be interpreted as similar to hypothetical).
Database-specific strings using a database provider prefix (e.g., _exmpl_experimental_at_extreme_pressure  MAY be used but are strongly discouraged.

However, writing the above up, I realize that some kind of info on whether the above classification refers to structures existing at NTP or other conditions would also be useful here. If the reason you want this is because you want to filter on "reasonable structures" to use for your AI model, I'm not sure you want to include someones database of 1M structures relaxed to the convex hull but at one billion bar and 10000 K.

I agree with @rartino's proposal, but would change the following:

If the field is missing or equal to an empty string or null, it means no guarantees are given with respect to the origin of the structure (which can be interpreted as similar to hypothetical).

into the following:

If the field is missing or equal to an empty string or null, it means no guarantees are given with respect to the origin of the structure.

Some structures in the COD have so little accompanying metadata that no one can really tell to which class such structures belong. I think "do not assume anything" is a reasonable default value.

I think we should see this point as part of the larger issue, that we have not standardized anything yet about the methods used to generate the structure. So I think we should think about how we want to include such information in general. (We do not need to discuss which properties should be included. That could be addressed in a later issue.)

Thanks @rartino @sauliusg @merkys and @JPBergsma for the extended discussion after today's meeting. I will try my best to summarize the issues with adding this and the options we discussed.

We add this field as a new property, say structure_origin that follows an enum of some TBD tags experimental, predicted etc. and make queries on it mandatory with a default value of unknown.

The concept of this field has broad support, modulo implementation details.
Adding this field in this way would mean that no v1.1 field could support these queries without updating to 1.2 (due to the specific way unknown fields are meant to be handled), hence delaying the usefulness of this field.

We overload the structure_features field an extend its definition to include non-overlapping tags, the omission of which (the default) would indicate unknown structure source.

This is admittedly bad API design for many reasons, and would need a change in the definition of the structure features field that may break it for future use cases. The question would be whether it is worth sacrificing our design to pragmatically enable these queries to both v1.1 and v1.2 implementations, from the second v1.2 is released.

We add explicit support for filtering on properties_that_might_not_be_in_this_version via a prefix, say _future_ or _optimade_next or _optimade_v1.2 that means that the field from 1) can still be sent to v1.1 URLs and receive a sensible default response (null)

This introduces some complexity to both users and implementers: users have to know to use this weird additional syntax when querying what otherwise appears to be a normal OPTIMADE property and v1.2 implementations have to know to strip this prefix from the field and check if it is known to them.
A client with full support for version negotiation could get around this anyway, though no generic multi-provider, multi-version client exists yet that knows which fields are allowed between different versions (afaik).

We finally disentangle prefixes from providers and serve an OPTIMADE-consortia namespace that provides this property, in a slight modification to 3).

In this way, it remains possible to query v1.1 implementations with this field, but it becomes hard for it to re-enter into the proper specification.
This would require significant coordination effort for setting up a namespace, best practices etc. and words to that effect in the specification, HOWEVER this is absolutely something we will want to do in the case of other properties, so this effort won't be "wasted".
In fact, this could become the "proper" mechanism for adding new fields between minor versions of OPTIMADE. The prefix could become _optimade_2.0 and the assurance could be made that any fields in the _optimade_2.0 prefix will be added at the next version, so supporting them "early" is not wasted effort. (This was not discussed but came to me whilst writing this up). I don't know how hard a requirement we would want to make this on ourselves -- it should be treated in the same way we would treat removing/changing a field between major versions (i.e., we're allowed to, but good design would suggest that we keep some similarity at least).
The backwards-compatible queries leading to the right answers nature of this query only works if the default value of the field carries some semantic information. If we standardized e.g., band gap in this optimade_2.0 prefix (not that we ever would), then a query for _optimade_2.0_bandgap > 0 will return anything with a null band gap in a non-supporting databases, because we want structure_origin = null to mean something, this could be a useful mechanism.

I hope that adequately summarizes our discussion. I am personally leaning towards 4 and would be happy to help set this up.

Having read @ml-evs proposal, option 1 still sounds the most elegant to me. I get that a new specification version (or an RC) has to be released and implemented to support such structure_origin property, but I would argue that so would the rest of the options.
According to the specification, implementations can serve preview (or RC) versions of OPTIMADE:

API versions that are published with a suffix, e.g., :val:-rc<number> to indicate a release candidate version, SHOULD be served on versioned base URLs without this suffix.

So once structure_origin reaches RC, clients may immediately start querying /v1.2 with this new feature. If implementations return HTTP error 553 Version Not Supported, a client drops the structure_origin and fallbacks to /v1.1 or /v1.

After thinking a bit more on this since that discussion: I sympathize with what @ml-evs wants to do by introducing this feature without having older servers return errors, and going forward the situation with forwards-compatibility needs to be improved. However, for this one change, I still come down on the side that we should be able to accept the breakage:

We still don't have that many separate servers implementing OPTIMADE in production yet.
The primary use case we are trying to address here is: "Give me all structures that "make sense"; exclude arbitrary made-up structures, intermediate steps, etc."
For this use case, if you send a structure_origin = ... query to 10 servers and 5 of them return an error, you can just re-send the same query to the 5 that recognize structure_origin and get the data you would have received with @ml-evs's approach (2).
Now, the user can stop here (with the same results as in @ml-evs (2)), but will probably find it to be better to go through the databases giving errors and make a manual decision on the database level about whether to include their structures or not. (For example, the user probably still wants to include all structures from COD, given how their database is created from primarily experimental structures, even if this provider do not yet implement structure_origin).

Now, for the general issue: going forward, I think the most direct solution would be to just demote the error for unrecognized properties without prefixes into a mandatory warning. How about the following changes to section 3.9?:

3.9   Handling unknown property names
When an implementation receives a request with a query filter that refers to an unknown property name it is handled differently depending on the database-specific prefix:

If the property name has no database-specific prefix, or if it has the database-specific prefix that belongs to the implementation itself, a warning MUST be returned with a message indicating the offending property name.
If the property name has a database-specific prefix that does not belong to the implementation itself, it The implementation MUST NOT treat this as an error, but rather MUST evaluate the query with the property treated as unknown, i.e., comparisons are evaluated as if the property has the value null.

If the property does not have a database-specific prefix the implementation MUST issue a warning about the unrecognized property name.
Furthermore, If the property has a database-specific prefix that the implementation does not recognize the prefix at all, it SHOULD return a warning that indicates that the property has been handled as unknown.
On the other hand, If the property has a recognized prefix, the prefix is recognized, i.e., as belonging to a known database provider, the implementation SHOULD NOT issue a warning but MAY issue diagnostic output with a note explaining how the request was handled.

I think I have been talked off the proverbial ledge here, I must admit that writing out options 1-4 above did seem like overkill. My only concern now with adjusting the unknown property names directly to avoid breakages is that results returned from a unknown property filter will be "wrong" and will require all clients to strictly check warnings (somehow this feels like more of a breaking change now than queries not working across versions 😅). I was fine with this in the specific case of adding a field with a default value that can be sensibly applied backwards (although still concede this is poor API design), but think we should exercise some caution...

Indeed, CSP was my main initial motivation too. Hopefully we can revisit #455 in 2024...


No Shadows

p5.js lacks shadow / drop shadow support.

https://github.com/processing/p5.js/issues/1771


Tag page:  element can't be child of

The element 'header' must not appear as a descendant of the 'header' element.
W3C validator: https://validator.w3.org/nu/?doc=https%3A%2F%2Fdemo.ghost.io%2Ftag%2Fgetting-started%2F
URL: https://demo.ghost.io/tag/getting-started/

   ...

Tagged

Getting Started

   ...

https://github.com/TryGhost/Casper/blob/ea33b00c0a8c302124a504ac673c056f8c555f82/tag.hbs#L10-L45

Hey @l33d4n,
Thanks, fixed in https://github.com/TryGhost/Casper/commit/21bdffbd8ab0fb416c1c89ec944606ebc1eab745 :)

Great! Thank you.


Add merlin detector mask

The merlin detector of SixS is not in the list.
https://github.com/clatlan/cdiutils/blob/8f573d2d47cbbb508c4f228afcece7caa4d494ef/cdiutils/load/loader.py#L232C1-L232C72

Sure, I have no idea what merlin detector mask looks like. Can you provide me with the associated mask?

i just added it as following (the gap are eliminated automatically in my data)
    elif detector_name in ("merlin"):
        mask = np.zeros(shape=(512, 512))

class MerlinSixS(Detector):
    """Implementation of the Merlin detector for SixS."""

    def __init__(self, name, **kwargs):
        super().__init__(name=name, **kwargs)
        self.saturation_threshold = 1e6

    def _mask_gaps(self, data, mask):
        """
        Mask the gaps between sensors in the detector.

        :param data: a 2D numpy array
        :param mask: a 2D numpy array of the same shape as data
        :return:

         - the masked data
         - the updated mask

        """
        valid.valid_ndarray(
            (data, mask), ndim=2, shape=self.unbinned_pixel_number, fix_shape=True
        )

        data[:, 254:257] = 0
        data[254:257, :] = 0

        mask[:, 254:257] = 1
        mask[254:257, :] = 1
        return data, mask

    @property
    def unbinned_pixel_number(self):
        """
        Define the number of pixels of the unbinned detector.

        Convention: (vertical, horizontal)
        """
        return 512, 512

    @property
    def unbinned_pixel_size(self):
        """Pixel size (vertical, horizontal) of the unbinned detector in meters."""
        return 55e-06, 55e-06

see this code for used for the bcdi package, it's a specific Merlin configuration

In both case if the mask given ior not it do get_mask function where the mask is defined  list of detectors.
The snipped code must do the job.

Done.
The current merlin mask is np.zeros(shape=(512, 512)), ie no masked pixels. Tell me if you want to add the masked pixels as given above.


Set output encoding to utf8 to make unicode tags print correctly

Nice fix, but maybe the Text.IO.readFile above could use the same fix?  Otherwise won't it crash when it tries to read the  file back in for incremental update?
Data.Text says it uses the current system's locale, which I think you can set with IO.Encoding.setLocaleEncoding

@elaforge Nice catch, but it does not seem to have any effect in my environment. I have tried getting ghc tags on Windows under msys 2.0 with C.utf8 locale and it was failing when writing output. After fixing output encoding fast-tags started to work without errors, even merging of tags work. Anyway, I've changed reading of tags file to use utf8 as well, since it seems likely that it may cause issues later.

Looks good, thanks for the fix!


Add conda installation to website.

Describe the problem
Currently in https://tdcommons.ai/start/, the pip installation method is illustrated.
Describe the solution you'd like
Include the conda installation command alongside pip (conda install -c conda-forge pytdc). Installing via conda solved issues I was having, and I believe publicizing an alternative installation method (not just on the github page) can reduce headaches for newcomers.

hi @Pixelatory the conda installation is not being mantained or updated since 2021 as best i can tell


Support for dataType ajax parameter

Because I have a project where the subtitles are on a remote location but only could be fetched with jsonp type jquery ajax, so I added the parameter.

Closing this because it was ignored by maintainers.


The non-test notes are superficial, don't sweat them much.
I'd mostly like to see a refactor on the step definitions, and maybe another swing at the right level of concision vs. reuse of the steps themselves. If you want to move ahead, that's cool too, just take it into account in the other stuff you do.

Btw, good work, it's solid testing code.

Great input. Really helpful. I'm going to try to pull this one again just to make sure I'm solid on test writing.


Api calls

opening pr for comments :)

Submitting a new pull request to the official repo, so I think I should close this one?

:+1:


[release] v1.7.2

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (0d87049) 87.25% compared to head (e03708f) 87.25%.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #120   +/-   ##
========================================
  Coverage    87.25%   87.25%
========================================
  Files           30       30
  Lines         1263     1263
========================================
  Hits          1102     1102
  Misses         161      161

Impacted Files
Coverage Δ

src/ragger/__init__.py
100.00% <100.00%> (ø)

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


fullTitle should consider displayTwentyfour

I implemented the modal version, similar to the one in the demo (material). I've set the displayTwentyfour config to true, yet the fullTitle of the dialog contains the AM/PM value, since this is hardcoded. Could this be changed so that either the fullTitle is customizable or at least follows some of the settings?

That's an oversight on my part. I'll get it fixed when I can.


AP-3108 Ensure code coverage at 100%

This PR addresses two issues:

The eager_loading setting in /config/test.rb was set to false.  This means that only those files
actually used during a test run are included in the coverage results.  By setting this to true, this
ensures that all files are included in the test results, and files that are never hit are shown as
having no coverage.

It fixes a flickering test error where employments were being created by the factory as
Job 1, Job 2 etc were being incorrectly sorted (Job 10 coming before Job 9) and therefore
not matching the expected order.  This fixes it by making sure the numerical element is a
four-difit leading zero number (e.g. Job 0010)

What
Link to story
Describe what you did and why.
Checklist
Before you ask people to review this PR:

Tests and rubocop should be passing: bundle exec rake
Github should not be reporting conflicts; you should have recently run git rebase main.
There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
The PR description should say what you changed and why, with a link to the JIRA story.
You should have looked at the diff against main and ensured that nothing unexpected is included in your changes.
You should have checked that the commit messages say why the change was made.

That sounds much better.  then we'll be alerted in Ci if semething isn't
covered, but don't have to suffer the time hit of loading everything for
running one local test.  Will change it.
On Wed, 31 Aug 2022 at 11:02, Connor McQuillan @.***>
wrote:

@.**** commented on this pull request.
In config/environments/test.rb
https://github.com/ministryofjustice/check-financial-eligibility/pull/1072#discussion_r959400283
:

@@ -10,7 +10,7 @@

Do not eager load code on boot. This avoids loading your whole application
just for the purpose of running a single test. If you are using a tool that
preloads Rails for running tests, you may have to set it to true.

config.eager_load = false

config.eager_load = true # set eager loading to true so that ALL files are reported by simplecov, not just those that are loaded

The default in Rails is something like this now:
config.eager_load = ENV["CI"].present?
In my opinion that's preferable to eager loading every time anyone wants
to run a test.
What do you think?
—
Reply to this email directly, view it on GitHub
https://github.com/ministryofjustice/check-financial-eligibility/pull/1072#pullrequestreview-1091626199,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA4HIOJSLJ3G4G7EYEBFO3V34URPANCNFSM6AAAAAAQBGQY6A
.
You are receiving this because you authored the thread.Message ID:
<ministryofjustice/check-financial-eligibility/pull/1072/review/1091626199
@github.com>

--
Stephen Richards
MOJ Digital and Technology
102, Petty France, SW1H 9 AJ
E: @.***
T: 0759 048 3001


Issue#144-Change-Description-Prefix

Change prefix for Description from d/ to ds/
Adjusted UG according to changes
No adjustment made to DG since no relevant edits were needed

Codecov Report
Base: 60.29% // Head: 60.29% // No change to project coverage :thumbsup:

Coverage data is based on head (07cbd6b) compared to base (7287c9c).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #191   +/-   ##
=========================================
  Coverage     60.29%   60.29%
  Complexity      552      552
=========================================
  Files           103      103
  Lines          2065     2065
  Branches        209      209
=========================================
  Hits           1245     1245
  Misses          748      748
  Partials         72       72

Impacted Files
Coverage Δ

...ain/java/seedu/address/logic/parser/CliSyntax.java
90.00% <100.00%> (ø)

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

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

lgtm


Code reuse for edit/create contact page

I'd say it's poor form (pun intended) to copy and paste the form portion between the edit and create views. I went to this demo page to see how one would reuse a template like that and was disappointed that it doesn't, even though it's exactly the same form. If you add a field you'd have to update both.

So I kind of disagree that duplicating code between the create and edit forms is bad design. In my experience building real apps, rarely are the create and edit forms identical...even if they are in this particular demo app. As a rule, I think a little duplication here is better than trying to find an abstraction that might get in the way in the future.


Rewrite the helpers functions

Write the course helpers functions in the order in which they need to appear (per the flow of the course, not grouped by topic). That will make those rules much more readable. Secondly, you should ensure that the tests build on each other (i.e. testing completion of a lesson means testing the completion of all previous lessons and their respective concepts). You may need to modify the tests for this significantly.

This could be closed by #85. I'll check if we have to do some extra leg work here.


add --cleanup-yml to provide cleanup playbooks

This doesn't actually work as intended - the VM is destroyed and rebooted - need to figure out a way to keep the VM running for the cleanup playbooks


enable deep merge as the default for yaml

Resolves #327

Looks good @gergnz. Can we write some tests for the two behaviors (deep_merge vs not)? This is decently user-affecting, and there should be expectations around that.

Given this comment: https://github.com/stevenjack/cfndsl/pull/326#issuecomment-308580835, would you still like to include the code, or should we just require the deep_merge gem?
Yes, I'll get on and write some tests.

I would like to stick with the "no external dependencies" for now. But if this comes up again, it might be time to decide a new strategy.

👍

@gergnz Feel free to merge this and release

Yay!
Is this pushed up to the gem repository?

@eric-tucker, yes this should be v0.15

Thanks so much @gergnz .  You (and the cfndsl team) rock.  Your turn around on issues/features is amazing.

Sounds very interesting. Keen to try it out 👍🏽


[Bug]: trubles on filter reservation status

What happened?
I go to admin-interface > sales > reservations > dropdown "view all status" select a status (for example "new"). Now I see all reservations with status new. So far so good.
Now I want to see all reservations again. I drop down the view-status-menue and select the option "select all/none". I see for one second all options are marked. Next the page reload and I see only a blank page. No menu, no data, nothing - pure white.
The url is /admin/reservations.
Reloading the page didnt work. I ve to call the /admin page. Then I see the dashboard and can go back to reservations. Here I cant switch the selected status via dropdown-menu view-status. Nearly every time I get a white blank page. I can go back with browsers back-button. The new selected status is saved. But the filtered entries are not updated. It is a bit confusing.
That I can hit the red cross and can reset the filter I ve noticed after 5 minutes playing around with this error while writing this report ;) I suggested the red cross is only for deleting my manually insert id, guest number, table name, etc. and not for resetting all the filters.
What did you expect to happen?
I expect that I can deselect my selection of status and no blank page was load ;)
Version
3.5.x
What browser are you seeing the problem on?
Firefox
Relevant log output
Symfony\Component\ErrorHandler\Error\FatalError: Uncaught Igniter\Flame\Exception\ApplicationException: Ajax handler [list_filter::onSubmit] is not found.
in /var/www/httpdocs/app/main/classes/MainController.php:373

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error
in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ','12'' at line 1 in /var/www/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:82

Fixed https://github.com/tastyigniter/TastyIgniter/commit/de8ec05062adf2368639c6147f1c406d14650617


multi-line margin for "select-checkbox-inline"

.checkbox-inline {
  margin-right: 10px;
  color: green;
}
.checkbox-inline+.checkbox-inline {
  margin-left: 0px;
  color: red;
}

Fixed in devel branch. Even though this is a bootstrap issue not specific to autoform, it seems useful enough to include the workaround in the package.
Borrowed the CSS from here: http://stackoverflow.com/questions/15975968/twitter-bootstrap-inline-checkbox-alignment-issue

Done in AutoForm 5.0, now released.


Fixed typo in documentation

Changed "ASCCI" to "ASCII" in base41.md.

Changed "ASCCI" to "ASCII" in base41.md.

Thanks!


binary trees needed for mission M6A

Sorry for slipping this in at the last minute. It's needed for Mission 6A

Pull Request Test Coverage Report for Build 2045

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 27.897%

Totals

Change from base Build 2040:
0.01%

Covered Lines:
1429

Relevant Lines:
4437

💛  - Coveralls


Implementation of Conv-TasNet using cLN

I have some questions about the implementation of Conv-TasNet. If you use cLN, it should be a causal model, so it should not be able to see subsequent sequence information in the current convolution operation. The Conv-TasNet model you implemented did not process this content. I don't know if I didn't see it or did not realize the content.

You're right, when I ported ConvTasNet into Asteroid at first, I didn't include the causal model. Maybe I should have, it's only a matter of convolutional padding. Would you like to add support for it? It would be nice

If I have time, I will submit it.


LUX Sensor value

The problem
Hi,
compared to other LDR sensors in my house the lux value shown in the awtrix adapter objects is way too low (5...100 times too low).
Where does this value come from? Cant find the request command for Awtrix-light. Is it sure given in lux or maybe percent?
Maybe there are some other mathematics in background.
Auto brightness is working well. But I cant use this sensor for other automations because in dimm light situations its very fast at 0 or zero even if theres much light in the room.
Tested this on two Ulanzis.
Version of nodejs
v18.19.0
Version of ioBroker js-controller
5.0.17
Version of Adapter
v0.10.2
Version of awtrix-light firmware
0.91
Operating system running ioBroker
Linux Bookworm
Checklist of files to include below

[X] iobroker.current.log (Please share the logs in debug mode)
[ ] Contents of the JavaScript browser console (always include in cases of issues with the user interface)

Additional information & file uploads
No response

Where does this value come from?

From awtrix-light. The value is requested via http and the value will be written to the state (without any modification). This is not an adapter issue.

Ok I asked Blueforcer.
Pls find his answer here: https://github.com/Blueforcer/awtrix-light/issues/433#issuecomment-1859134533
The given value of the light sensor in the adapter is NOT lux. Pls fix unit and name.
Thanks in further.


Custom login with json

Hi i have playframework project and i need to implement authorization for it.
I have copied basic example structure and experimented with it, so far i havent found answer for my problem. I have predefined specs for handling requests and results.
Login controller takes in username and account in json format after that code will authenticate posted username and will return acount object if password matches (just like in basic example). After that problem arises. I have no idea how to offer authentication cookie as response. so far i have tried to use
gotoLoginSucceeded method but because my lack of knowledge i haven't configured StartNewSession and it will throw Assertionerror (as it should). Every example returns webpage in controller, but my specs forces frontend and back end to be separated so i cant redirect as response. How i should send the cookie in this case?

Default implementation use cookie.
However you can change this behavior by creating custom TokenAccessor.
There is an example of HTTP Basic authentication.
https://github.com/t2v/play2-auth/blob/09a08e2877df34b16afe032a0a05450bcf34ee03/sample/app/controllers/basic/BasicAuthTokenAccessor.scala
(It does not add auth token into response, your TokenAccessor can add auth token into response header)


Maintain separate firebase instances?

This might be beyond the scope of this module, but I'm trying to figure out how to maintain separate firebase instances. Suppose the developer wants to use one module to point to firebase1 and another module where he wants to point to firebase2.
I started to create a PR to allow this: https://github.com/cerebral/cerebral-module-firebase/pull/2
But, then I realized, that this doesn't really solve the issue because the instance variable on helpers.js is still going to be shared across all instances of this module.
I'm wondering if there's a way to do this without calling .bind a bunch of times on the module's service methods in order to properly set the instance context.

I suppose you could actually instantiate a new class with its own internal firebase instance. But that seems to go against the grain of the functional design pattern.

@awei01 Ideally I think this should work like:
controller.addModules({
  fb1: Firebase({}),
  fb2: Firebase({})
})

Where each module has to keep some internal reference to Firebase, but not sure if that is even possible?  So yeah... my sure we do not try to do something that is really not supported :)

It's definitely possible with the firebase package. https://firebase.google.com/docs/reference/js/firebase#.initializeApp
The main question is how you envision this module to be used. I see it going one of two ways:

The module can be instantiated many times (as you illustrated in your example)

controller.addModules({
    fb1: Firebasse({ configs for fb1} , "fb1-instance1-name"),
    fb2: Firebasse({ configs for fb2} , "fb1-instance2-name"),
})

You have one central firebase module that manages each different firebase app.

controller.addModules({
   firebase: Firebase({ fb1: { configs for 1 }, fb2: { configs for 2 } });
});

Both options are possible, it's just a question of your vision for cerebral-module-firebase. Or, if the above are not in your vision, I understand that, too.

Aha! Cool! Since we have a concept of multiple instance modules I think that is a good way to go. It will also allow you to point to the correct instance by: services.fb1.listenTo etc., instead of: services.fb.listenTo('instanceA'....). Cleaner I think.
So yes, a refactor here to keep an internal instance of Firebase would be a good fix I think.


updated node version test to use semver

Following up on your comment here https://github.com/vandium-io/lambda-tester/pull/34#issuecomment-379488833
Would love to see this merged soon

I already implemented it in the 3.x branch - will be merging to master today and pushing to npm.  Thanks for the pull request


SequentialChain runs the same callbacks over and over in async mode

System Info
In the Async mode, SequentialChain implementation seems to run the same callbacks over and over since it is re-using the same callbacks object.
Langchain version: 0.0.264
The implementation of this aysnc route differs from the sync route and sync approach follows the right pattern of generating a new callbacks object instead of re-using the old one and thus avoiding the cascading run of callbacks at each step.
Async code
        _run_manager = run_manager or AsyncCallbackManagerForChainRun.get_noop_manager()
        callbacks = _run_manager.get_child()
        ...
        for i, chain in enumerate(self.chains):
            _input = await chain.arun(_input, callbacks=callbacks)
            ...

Sync code
        _run_manager = run_manager or CallbackManagerForChainRun.get_noop_manager()
        for i, chain in enumerate(self.chains):
            _input = chain.run(_input, callbacks=_run_manager.get_child(f"step_{i+1}"))
            ...

Notice how we are reusing the callbacks object in the Async code which will have a cascading effect as we run through the chain. It runs the same callbacks over and over resulting in issues.
CC @agola11
Who can help?
@agola11
Information

[ ] The official example notebooks/scripts
[X] My own modified scripts

Related Components

[ ] LLMs/Chat Models
[ ] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[ ] Output Parsers
[ ] Document Loaders
[ ] Vector Stores / Retrievers
[ ] Memory
[ ] Agents / Agent Executors
[ ] Tools / Toolkits
[x] Chains
[X] Callbacks/Tracing
[X] Async

Reproduction
You can write a simple sequential chain with 3 tasks with callbacks and run the code in async and notice that the callbacks run over and over as we can see in the log.
Expected behavior
We should ideally see the callbacks get run once per task.

Here is a test patch for this issue.


[novamov] fix for all included provider (WholeCloud, NowVideo, BitVid, CloudTime, AuroraVid)

Please follow the guide below

You will be asked some questions, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your pull request (like that [x])
Use Preview tab to see how your pull request will actually look like

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x] Searched the bugtracker for similar pull requests

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Bug fix
[ ] Improvement
[x] New extractor
[ ] New feature

Description of your pull request and other information
NovaMov changed their way of providing video files. Now a form must be posted to get the direct link to the video file.
This impacts following hoster:

WholeCloud
NowVideo
BitVid (former known as VideoWeed)
CloudTime
AuroraVid

Read

adding new extractor tutorial and youtube-dl coding conventions sections

and fix all issues.

The only test failing right now on the build server is for CloudTime (HTTP Error 400: Bad Request), when it tries to download the webpage. But it does pass locally.
Can anyone give me a hint how make the test pass or at least bypass it on the build server?
(If nothing helps I will just remove it...)

Rather than make 2 separate web requests its probably faster to grab the weird toker id thing from this script tag <script type="text/javascript" src="/api/toker.php?f=mmdbb1b48eddbb4e43b8e98c3112499ad1.mp4"></script> which is found on the "Continue to video" page  by using the following regex r'toker\.php\?f=([^"]+)' and then construct a download url directly with something like this video_url = 'http://%s/download.php?file=%s' % (self._HOST, the_toker_id_thing_grabbed_from_beforehand) . This ends up with something like the following "http://www.nowvideo.sx/download.php?file=mmdbb1b48eddbb4e43b8e98c3112499ad1.mp4"
Besides being a bit faster by avoiding a second url request this also avoids a problem I was having with some links were it would give you a mpd file instead of a mp3 or flv

ok, thanks for the info i will look into it and see what can be done

I added the proposed method, but I have not found a single example where an mpd file is provided.
Is youtube-dl capable to handle mpd files without any further work?


Feature Request: Add expires shortcuts?

carhartl/jquery-cookie and js-cookie both provided a shortcut to expiration.  If you provided expires: <Number>, then it would assume an expiration of days.  Would you be agreeable to this sort of feature in ember-cookies?
We could also enhance this significantly by supporting a String value specifying a duration and units.  Maybe use the same characters as date formatting to specify units? ex: '3d' or 50M for 3 days or 50 minutes respectively
Thanks for the addon!  Loving it and killing off a jquery plugin and bower dependency!

I'm not sure this is something that's actually needed to be honest, especially as we'd just be adding shortcuts that's already very simple, e.g. For 3 days:
3 * 24 * 60 * 60

Also if you treat expires: 3 as 3 days how would you distinguish that from a 3 second expiry?

Completely agree that it's trivial, but you do have to pass a Date instance for expires, right?  So it's a bit more involved.
this.get('cookies').write(MY_COOKIE_NAME, cookieVal, {
...
expires: new Date(Date.now() + 3 * 24 * 60 * 60 * 1000) // Raw Date approach
expires: moment().add(3, 'days').toDate() // Moment approach
...
}

Again, this is pretty straightforward to write, but I saw it and immediately thought of a utility so I suggested it.  To me, this seems easier:
this.get('cookies').write(MY_COOKIE_NAME, cookieVal, {
...
expires: '3d' // 3 days
...
}

Completely up to you as a maintainer, but just thought I'd suggest it.  Thanks again for the addon!

Re: Number param
I also agree that a Number value for expires is ambiguous.  I just suggested days as a default as it's consistent with the other cookie libraries.  I guess they assume standard cookie duration is in days?  Had I designed the api for those other libraries, I would have probably supported a String variant with value/units as I suggested above.

but you do have to pass a Date instance for expires, right?

Good point ;) I guess allowing to pass a number (and treating this as "seconds from now") would actually be a good idea then.
I'd actually not want to allow strings like '3d' - if we allow passing seconds I think there's very little need for something like this and we'd add a custom vocabulary that mostly adds unnecessary complexity to the library. The main idea behind ember-cookies is to provide a cooke abstraction that works both in the browser as well as on the server and not really to provide a fancy API on top of cookies.

Seconds seems like a good and flexible default to me!  Easy to do the maths from there as you initially commented.
Would you prefer to overload expires as we've been chatting about or add another option key for the seconds config?
I am pretty swamped with work as I am sure you are as well.  Just wanted to hash out the api in case I find some time this weekend to look into a PR.

Aside (Again working through the API)
Millis are usually the standard time manipulation unit, but since cookies only have second precision, I think that's perfectly fine to use seconds as the default here and not to go to that level of precision in this API.

Would you prefer to overload expires as we've been chatting about or add another option key for the seconds config?

I think overloading should be fine.

Millis are usually the standard time manipulation unit, but since cookies only have second precision, I think that's perfectly fine to use seconds as the default here and not to go to that level of precision in this API.

max-age is in seconds as well (see https://developer.mozilla.org/en-US/docs/Web/API/document/cookie) so I think seconds should be fine.

Hey, @justinaray we have maxAge option, which takes a time in seconds, so I've documented that on the Readme. Does that work as an alternative to overloading expires?

Thanks @geekygrappler  and @marcoow.  Max-Age will work for our use case, seems to have pretty good browser support, and MDN says it will be preferred over Expires if both are set and supported.
👍


Rows.Err is not set correctly in the event of an error

Hi,
the following error during fetching the data set from the database is not set correctly.
Error
W-EGOD-17: could not receive data: 'websocket: close 1006 (abnormal closure): unexpected EOF'
Code
for rows.Next() {     err = scanFunc(rows)     if err != nil {        return err     } } if err = rows.Err(); err != nil {     return err }
Rows.Err returns the error for advancing to the next row or error. But the error W-EGOD-17 ... is not set in rows.Err.
You only see the output of the internal logger of the driver.
websocket.go:124: W-EGOD-17: could not receive data: 'websocket: close 1006 (abnormal closure): unexpected EOF'

This is fixed with https://github.com/exasol/exasol-driver-go/pull/114


Akka dead letters encountered

This is the stacktrace:
--------------------------------------
[INFO] [12/18/2015 14:19:00.695] [elasticmq-akka.actor.default-dispatcher-9] [akka://elasticmq/deadLetters] Message [scala.collection.immutable.Nil$] from Actor[akka://elasticmq/user/$a/$a#-833948945] to Actor[akka://elasticmq/deadLetters] was not delivered. [4] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
 I'm using elasticmq version 0.8.12. Thanks

How did you get this? Did you invoke any operations?

@adamw , sorry for late response.
I have a method inside the JmsListener that process hundred thousands of data.  This method downloads the csv file and save each row in a list. After parsing it, we iterate in the list and create an object. It looks like this:
     List sampleObjectList = []
     List numbers = [1, 2, 3, 4, 5, 6, 7, ...']
     numbers.each { number ->
         sampleObjectList << new SampleObject(number: number)
     }
     batchValidateAndSave(sampleObjectList)

We save a batch of objects.

So this works now?


Firebase messaging error when update flutter to v1.20 and android sudio

Launching lib/main.dart on iPhone 11 in debug mode...
Running Xcode build...
Xcode build done.                                           76.3s
Failed to build iOS app
Could not build the application for the simulator.
Error launching application on iPhone 11.
Error output from Xcode build:
↳
** BUILD FAILED **
Xcode's output:
↳
/Users/yaseenabugamess/Development/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_messaging-6.0.16/ios/Classes/FLTFirebaseMessagingPlugin.m:195:43: warning: 'FIRMessagingRemoteMessage' is deprecated: FCM direct channel is deprecated, please use APNs for downstream message handling. [-Wdeprecated-declarations]

(void)applicationReceivedRemoteMessage:(FIRMessagingRemoteMessage *)remoteMessage {
^
In module 'FirebaseMessaging' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Headers/Public/Firebase/Firebase.h:93:
/Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FIRMessaging.h:219:1: note: 'FIRMessagingRemoteMessage' has been explicitly marked deprecated here
__deprecated_msg(
^
In module 'UIKit' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Target Support Files/firebase_messaging/firebase_messaging-prefix.pch:2:
In module 'Foundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:
In module 'CoreFoundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:
In module 'Darwin' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:16:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/usr/include/sys/cdefs.h:191:48: note: expanded from macro '__deprecated_msg'
#define __deprecated_msg(_msg) attribute((deprecated(_msg)))
^
/Users/yaseenabugamess/Development/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_messaging-6.0.16/ios/Classes/FLTFirebaseMessagingPlugin.m:307:24: warning: 'FIRMessagingRemoteMessage' is deprecated: FCM direct channel is deprecated, please use APNs for downstream message handling. [-Wdeprecated-declarations]
didReceiveMessage:(FIRMessagingRemoteMessage *)remoteMessage {
^
In module 'FirebaseMessaging' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Headers/Public/Firebase/Firebase.h:93:
/Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FIRMessaging.h:219:1: note: 'FIRMessagingRemoteMessage' has been explicitly marked deprecated here
__deprecated_msg(
^
In module 'UIKit' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Target Support Files/firebase_messaging/firebase_messaging-prefix.pch:2:
In module 'Foundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:
In module 'CoreFoundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:
In module 'Darwin' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:16:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/usr/include/sys/cdefs.h:191:48: note: expanded from macro '__deprecated_msg'
#define __deprecated_msg(_msg) attribute((deprecated(_msg)))
^
/Users/yaseenabugamess/Development/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_messaging-6.0.16/ios/Classes/FLTFirebaseMessagingPlugin.m:141:30: warning: 'shouldEstablishDirectChannel' is deprecated: FCM direct channel is deprecated, please use APNs channel for downstream message delivery. [-Wdeprecated-declarations]
[FIRMessaging messaging].shouldEstablishDirectChannel = true;
^
In module 'FirebaseMessaging' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Headers/Public/Firebase/Firebase.h:93:
/Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FIRMessaging.h:283:56: note: 'shouldEstablishDirectChannel' has been explicitly marked deprecated here
@property(nonatomic) BOOL shouldEstablishDirectChannel DEPRECATED_MSG_ATTRIBUTE(
^
In module 'UIKit' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Target Support Files/firebase_messaging/firebase_messaging-prefix.pch:2:
In module 'Foundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:
In module 'CoreFoundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:
In module 'Darwin' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:16:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/usr/include/AvailabilityMacros.h:182:64: note: expanded from macro 'DEPRECATED_MSG_ATTRIBUTE'
#define DEPRECATED_MSG_ATTRIBUTE(s) attribute((deprecated(s)))
^
/Users/yaseenabugamess/Development/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_messaging-6.0.16/ios/Classes/FLTFirebaseMessagingPlugin.m:196:52: warning: 'appData' is deprecated [-Wdeprecated-declarations]
[self didReceiveRemoteNotification:remoteMessage.appData];
^
In module 'FirebaseMessaging' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Headers/Public/Firebase/Firebase.h:93:
/Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FIRMessaging.h:226:62: note: 'appData' has been explicitly marked deprecated here
@property(nonatomic, readonly, strong) NSDictionary *appData DEPRECATED_ATTRIBUTE;
^
In module 'UIKit' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Target Support Files/firebase_messaging/firebase_messaging-prefix.pch:2:
In module 'Foundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:
In module 'CoreFoundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:
In module 'Darwin' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:16:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/usr/include/AvailabilityMacros.h:180:60: note: expanded from macro 'DEPRECATED_ATTRIBUTE'
#define DEPRECATED_ATTRIBUTE        attribute((deprecated))
^
/Users/yaseenabugamess/Development/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_messaging-6.0.16/ios/Classes/FLTFirebaseMessagingPlugin.m:306:1: warning: implementing deprecated method [-Wdeprecated-implementations]
(void)messaging:(FIRMessaging *)messaging
^
In module 'FirebaseMessaging' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Headers/Public/Firebase/Firebase.h:93:
/Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FIRMessaging.h:253:1: note: method 'messaging:didReceiveMessage:' declared here
(void)messaging:(FIRMessaging *)messaging
^
/Users/yaseenabugamess/Development/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_messaging-6.0.16/ios/Classes/FLTFirebaseMessagingPlugin.m:308:63: warning: 'appData' is deprecated [-Wdeprecated-declarations]
[_channel invokeMethod:@"onMessage" arguments:remoteMessage.appData];
^
In module 'FirebaseMessaging' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Headers/Public/Firebase/Firebase.h:93:
/Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/FirebaseMessaging/FirebaseMessaging/Sources/Public/FIRMessaging.h:226:62: note: 'appData' has been explicitly marked deprecated here
@property(nonatomic, readonly, strong) NSDictionary *appData DEPRECATED_ATTRIBUTE;
^
In module 'UIKit' imported from /Users/yaseenabugamess/Documents/TopStyleApp/ios/Pods/Target Support Files/firebase_messaging/firebase_messaging-prefix.pch:2:
In module 'Foundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:
In module 'CoreFoundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:
In module 'Darwin' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:16:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.5.sdk/usr/include/AvailabilityMacros.h:180:60: note: expanded from macro 'DEPRECATED_ATTRIBUTE'
#define DEPRECATED_ATTRIBUTE        attribute((deprecated))
^
6 warnings generated.
ld: framework not found flutter_plugin_android_lifecycle
clang: error: linker command failed with exit code 1 (use -v to see invocation)
note: Using new build system
note: Building targets in parallel
note: Planning build
note: Constructing build description

I get the same error, but I solved it with the following command.
flutter clean
cd ios
rm -rf Pods
pod install

Hi @yaseen-abugamess,
Please try above solution and see if it works for you.
If problem persists, it seems to be an issue with Firebase which has separate repo for tracking issue : https://github.com/FirebaseExtended/flutterfire/issues. Please consider opening this issue there.
Closing, as this doesn't seem to be an issue with Flutter. If you disagree, write in comments and I'll reopen.
Thanks.


remove requirements-test.txt

This file was added almost a year ago and hasn't been touched, doesn't look like it's used anywhere in the SDK. pretty sure it was added by mistake so let's get rid of it!
Happy to close the PR if it turns out there's a reason for the file to be checked in.

haha just kidding! turns out it is necessary, forgot to pass the --hidden flag to rg 🙃


[Feature request] Priority list for the format (.txt, .html, .civitai.info, etc)

Hello,
While I like civitai-helper for some of its features. I find their .civitai.info really lacking in terms of useful informations sometimes.
Therefore I would like sd-model-preview-xd to pick my hand crafted .txt over the .civitai.info whenever there is one.

The idea of priority only comes into play with HTML files and Civitai Info files. Everything else doesn't have a priority since you can have a .txt, .md, and image files all appearing at once.
The current priority levels are:
HTML > Civitai Info > Everything else (markdown, txt, and images)
If you dont find the civitai info files useful wouldn't it be easier to just delete them, or not download them to begin with? If for some reason you still want the files around... download them and then rename them to something like civitai.ignore.info so the extension doesn't see it. Then your .txt files will appear.
You could also switch to using HTML files instead of txt files as they take priority over civitai info files.
I just don't see the need for a setting to let people change file priorities when you already have pretty much complete control over what files appear.

I'm going to close this. If someone can articulate a compelling argument to add this I may reconsider, but right now I am not seeing a need for this feature request.


high CPU usage

Microsoft PowerToys version
0.56.2
Running as admin

[X] Yes

Area(s) with issue?
FancyZones
Steps to reproduce
PowerToysReport_2022-03-12-21-38-38.zip

✔ Expected Behavior
No response
❌ Actual Behavior
No response
Other Software
No response

Could you provide a dump file? /needinfo

Related: #14234
cc: @SeraphimaZ fyi

I can't upload the .DMP file, is there any other way to upload it?

Please email it to<EMAIL_ADDRESS>and reference this issue (#16999) /needinfo

@franky920920  hi- not the original bug poster but i just sent you a dump i happened to capture

@crutkas Do you got the dump?

@franky920920 hi- not the original bug poster but i just sent you a dump i happened to capture

The dump didn't help unfortunately.

This seems to have become a problem for me in the most recent release if I can provide a more helpful dump... it was never an issue before.

Also note that I'm on a horribly exotic display configuration spanning 4-5 displays, mixed SDR/HDR, and 2-3 drivers at a time, which is basically unsupportable, but I never had this issue before :)

PowerToysReport_2022-05-06-13-17-26.zip
Fixed by downgrading to 0.57.2.

This is one of the presented workarounds:

The workaround is pretty simple, apply any layout except the default 3-zones PriorityGrid. It should help.

Does this help?

@axfelix can you please replace the text in the C:\Users\...\AppData\Local\Microsoft\PowerToys\log_settings.json with {"logLevel":"trace"} and attach a new bug report when the problem appears again?

Here's a report with {"logLevel":"trace"}; just started PT without using any of its functionality. FZ is constantly using some CPU.
PowerToysReport_2022-06-07-10-37-43.zip

Here's a report with {"logLevel":"trace"}; just started PT without using any of its functionality. FZ is constantly using some CPU.
PowerToysReport_2022-06-07-10-37-43.zip

This case is similar to https://github.com/microsoft/PowerToys/issues/18057, it was fixed in 0.59.

@stinos can you try 0.59?  /needinfo

@crutkas can confirm it's fixed, nice!


Enable notes tag support

Note.java does not have tags field yet.
This should be a very helpful attribute, and it can help users to organize their notes much more efficient.
We can have the tag as a string field, and each tag is separated by a comma.

hi Zhouhao, I'm new to spring boot and like to take one of the open request. Do you think this is a good request for me to start with? I'm still going over the code, and thinking it could help me to understand the whole structure by working on something real.

hi Zhouhao, I'm new to spring boot and like to take one of the open request. Do you think this is a good request for me to start with? I'm still going over the code, and thinking it could help me to understand the whole structure by working on something real.

Thank you! @lodye509 , yeah, practice will make you understand spring boot faster.
This can be a good start, I will give you more details soon.

Thank you! @lodye509 , yeah, practice will make you understand spring boot faster.
This can be a good start, I will give you more details soon.

Thank you ;)

Thank you ;)

Step 1: add new tags field for note table, and update Note entity class.

Add V0_0_9__add_tags_to_note_table.sql into db/migration
I use Flyway for db migration, and you can find more details about it here:SQL-based migrations.
Add a new string field named tags in Node.java

Benefits of db migration: no need to patch it manually, easy to keep it consistent.

Step 1: add new tags field for note table, and update Note entity class.

Add V0_0_9__add_tags_to_note_table.sql into db/migration
I use Flyway for db migration, and you can find more details about it here:SQL-based migrations.
Add a new string field named tags in Node.java

Benefits of db migration: no need to patch it manually, easy to keep it consistent.

Note: make it nullable should be good enough, as tags is an optional attribute of a note.

Note: make it nullable should be good enough, as tags is an optional attribute of a note.

Then it should be all set. We enabled tags support for note now.
What's next: update the unit test

Set tags in public static Note createTmpNote(String userId)
It will be great if you can follow updateNoteByIdShouldSuccess() and add a dedicated test for tags update.

Then it should be all set. We enabled tags support for note now.
What's next: update the unit test

Set tags in public static Note createTmpNote(String userId)
It will be great if you can follow updateNoteByIdShouldSuccess() and add a dedicated test for tags update.

Hi @lodye509, this should be the changes that we need to take for service side.
And please feel free to let me know if you need more information.

I believe you will be more conformable soon.

Hi @lodye509, this should be the changes that we need to take for service side.
And please feel free to let me know if you need more information.

I believe you will be more conformable soon.

@zhouhao thanks for the details~ Yea I didn’t use flyway before, so might need to take a while to start. But no worries I think I can figure this out xD

@zhouhao thanks for the details~ Yea I didn’t use flyway before, so might need to take a while to start. But no worries I think I can figure this out xD

Step 1: add new tags field for note table, and update Note entity class.

Add V0_0_9__add_tags_to_note_table.sql into db/migration
I use Flyway for db migration, and you can find more details about it here:SQL-based migrations.
Add a new string field named tags in Node.java

Benefits of db migration: no need to patch it manually, easy to keep it consistent.

@zhouhao For the new field tags, what's the reasonable maximum length for it? I will say something around 20 since we have text field. What do you think?

Step 1: add new tags field for note table, and update Note entity class.

Add V0_0_9__add_tags_to_note_table.sql into db/migration
I use Flyway for db migration, and you can find more details about it here:SQL-based migrations.
Add a new string field named tags in Node.java

Benefits of db migration: no need to patch it manually, easy to keep it consistent.

@zhouhao For the new field tags, what's the reasonable maximum length for it? I will say something around 20 since we have text field. What do you think?

We can make it larger. People may add multiple tags. How about 128?

We can make it larger. People may add multiple tags. How about 128?

Just checked the tags in instagram lol and seems like most of the self-define tags are between 10 to 15 per one. So 64 is about 4 to 5 tags and 128 is 9ish. I think we can go with 128 for now.

Just checked the tags in instagram lol and seems like most of the self-define tags are between 10 to 15 per one. So 64 is about 4 to 5 tags and 128 is 9ish. I think we can go with 128 for now.

Thank you for your investigation. ;-)

Thank you for your investigation. ;-)

BTW: there is a repo called xxx-starter in this org, which could be helpful for you, if you haven't check it out. ;-)

BTW: there is a repo called xxx-starter in this org, which could be helpful for you, if you haven't check it out. ;-)

Nice! Thank you, what’s this repo actually for?

Nice! Thank you, what’s this repo actually for?

It is used for setting up private configuration for development environment (for internal developers).

It is used for setting up private configuration for development environment (for internal developers).

hello, is everything going ok so far? Just want to check whether anything I can help. No rush, no pressure.

hello, is everything going ok so far? Just want to check whether anything I can help. No rush, no pressure.

hey thank you for asking xD I was stuck on docker a little, but resolved issue now. But I do have a question on mariaDB, so you have mentioned the db change will be patched automatically, but I’m not able to see the changes. Do you have any clue what I have missed?

hey thank you for asking xD I was stuck on docker a little, but resolved issue now. But I do have a question on mariaDB, so you have mentioned the db change will be patched automatically, but I’m not able to see the changes. Do you have any clue what I have missed?

Thank you for your fast response.
Did you tried to start database with docker as below:
cd YOUR_PATH/saltynote-service

# This will start the database
docker-compose up

Thank you for your fast response.
Did you tried to start database with docker as below:
cd YOUR_PATH/saltynote-service

# This will start the database
docker-compose up

Yes I have, and also added one property to enable the history table.

Yes I have, and also added one property to enable the history table.

Sorry, what do you mean about added one property to enable the history table?
Basically, there is no need to manually touch the database, schema change will be patched by flyway too, even the history table.

Sorry, what do you mean about added one property to enable the history table?
Basically, there is no need to manually touch the database, schema change will be patched by flyway too, even the history table.

My bad, I added a parameter to the properties file which can enable the flyway history table. I got error saying this without the parameter.

My bad, I added a parameter to the properties file which can enable the flyway history table. I got error saying this without the parameter.

Interesting. Can you also share the error? Maybe I can take a look, and document it in case other people may also see this error.

Interesting. Can you also share the error? Maybe I can take a look, and document it in case other people may also see this error.

Sure, org.flywaydb.core.api.FlywayException: Found non-empty schema(s) without schema history table! Use baseline() or set baselineOnMigrate to true to initialize the schema history table.

Sure, org.flywaydb.core.api.FlywayException: Found non-empty schema(s) without schema history table! Use baseline() or set baselineOnMigrate to true to initialize the schema history table.

Thank you!
Interesting. Does this mean that you already have some tables in that database before starting this spring boot service?

Thank you!
Interesting. Does this mean that you already have some tables in that database before starting this spring boot service?

Code changes done and merged to master branch.

Code changes done and merged to master branch.


Math: Find Total Hamming Distance in C++

https://leetcode.com/problems/total-hamming-distance/

I'll take this up

We can solve this problem in O(n) time using the fact that all numbers are represented using 32 bits (or some fixed number of bits). The idea is to count differences at individual bit positions. We traverse from 0 to 31 and count numbers with i’th bit set. Let this count be ‘c'. There would be “n-c” numbers with i’th bit not set. So count of differences at i’th bit would be “count * (n-count)”, the reason for this formula is as every pair having one element which has set bit at i’th position and second element having unset bit at i’th position contributes exactly 1 to sum.

@akgmage please assign this to me

#1306 @akgmage I have made a pull request


Provide utility function to mask the output of marshal method: map of dynamo attribute values

Should accept ddb.P type(s) so masks can be build in a type-safe way
Should work on a map of attribute values, as returned by a call to marshal the item
Should also have an option to flatten for update calls, so can just be looped over to extend update expression

implemented through #36


last page load more button

If there is only one page available then there is no next page button being outputted by my system. It seems Infinite Scroll is giving an error on this:
Bad InfiniteScroll path option. Next link not found: .next
.next is the class of the link
InfiniteScroll is right here. There is no next link. It's the last page, so no link to the next and also no faulty anchor without a href.  How do I prevent InfiniteScroll giving an error and trying to load a next page? I don't want to fake a next page link.

Solved for now with a fake link and a rel="nofollow".
Hoping for an answer.

See https://github.com/metafizzy/infinite-scroll/issues/691#issuecomment-357312879


Two asserts wrong in bonfire symmetric difference

Challenge http://www.freecodecamp.com/challenges/bonfire-symmetric-difference has an issue. Please describe how to reproduce it, and include links to screen shots if possible.
Unless I'm misunderstanding symmetric differences, I believe that the two tests showing my code not passing are wrong. All three arrays contain 5, which should be excluded as they are an intersection of the sets (arrays) and therefore not a symmetric difference.

Watch the video that accompanies the challenge:
https://www.youtube.com/watch?v=PxffSUQRkG4
You'll see that you need to take the difference of A and B, and then take the result of that difference and compare it with C.  A and B both have 5, so it does not appear in AΔB, but C does, so AΔBΔC does not have it.  It's not exactly intuitive, but it's how it works.
Order matters, too:  AΔBΔC  does not equal CΔBΔA

Ahh, thank you. OK, I see how it works now. My code actually isn't buggy, my algorithm is wrong! Thank you SaintPeter.

Rex,
I don't think that video does accompany the challenge, at least I couldn't find a link on the bonfire page. It most definitely should as seeing the demonstration really clarified it for me. I knew either there was a bug in the asserts, or I wasn't completely clear on how symmetric differences work.

It may still be in staging.
It does really clarify the problem right?  I know that I started out with
the same solution as you because I had the same concern.  I then went
searching the web to find more info and ran across that video.

Yes, it's a great video. Glad it will be included.
Thanks again for your help.


Use feature flags instead of experimental mode

/kind feature
Which functionality do you think we should add?
Experimental features should be activated based on a configuration file instead of hiding every experimental features under a single experimental flag.
Why is this needed?

Not all experimental features mature at the same speed making it difficult to manage all of them with a single flag
Moving code out of the experimental state requires touching a lot of files while this would only require modifying a value in a single file if such features where managed by feature flags

we had this discussion a while back and the conclusion was that experimental mode is a good solution for us because

as all experimental mode features are under the same domain/wall (experimental), a developer gets to understand the impact their code is having on other experimental features giving them a headstart of resolving future integration problems.
makes it error prone and confusing for early uses as they might forget to enable some feature flags so better to have a single flag i.e. experimental mode.
cc @kadel

Not all experimental features mature at the same speed making it difficult to manage all of them with a single flag
Moving code out of the experimental state requires touching a lot of files while this would only require modifying a value in a single file if such features where managed by feature flags

I completely agree with that. The current experimental mode was originally added only to include everything related to devfiles, and it was supposed to be removed once we fully move to devfile (in odo v2.0.0 release) But it got a little bit out of hand :-(

/close
There is no experimental feature in odo anymore.
If we need something similar in the future we will go with the individual feature flags rather than one global experimental flag.


Need own VCS-servers for testing the tool

I think we should not depend on Github or Bitbucket (or any other) in the testing the CVS-features of Haxelib tool.
We need our own independent VCS-servers for automated (unit-) tests for the Haxelib console tool.
All servers have to support http, https and ssh connections.
List of needed repos:

Git without any auth
Git with login-pass auth
Git with cert/key auth
Hg without any auth
Hg with login-pass auth
Hg with cert/key auth
Svn without any auth
Svn with login-pass auth
Svn with cert/key auth
Maybe Bazaar too

Also we need more tests (unit + integration).

Alternatively the servers can be launched on CI but it's not an easy quest.

Agree, but wouldn't be a good idea to make a public server without auth,
and it'd be better for CI to have a fresh server too.
I took a look on how to create a git server, and it looks like it needs a new user,
travis can give sudo so could be possible, or maybe we can do another way that may be less secure but since it's just for testing.

As a cheap solution we can go with directory-based repos. Both hg and git can use local directories e.g. to clone from. I doubt we need to support svn.


Add toka toka by Fly project

Song Name
toka toka
Artist Name
Fly project
Source
Youtube
Youtube Link
SL-uqGB3w0MHcABQ
Direct File Link
No response
Song ID
683996
Start Offset [ms]
6000
Extra
Created from Auto Nong.
Created for level: 108805633

Принять


Alias dask.do to something else?

The dask.do function is powerful but somewhat difficult to teach to people.  I wonder if some of the learning curve could be improved by a different name.  Options that came to mind included the following:
delay(f)(*args)
task(f, *args)
delayed(f)(*args)  # this is what joblib does

Thoughts?
cc @jcrist @shoyer

This has come up enough that I'm +1 with changing it to something people like better. I like do because it's short, which makes it nice to use inline. Perhaps 2 functions could be nice to support the 2 usecases:
delayed(f)(*args)    # Can be used as a decorator on a function
do(f, *args)         # Or `task`, `delay`, `run`, `submit`, `apply`, etc...

For the second one, I like do best, but we'd have to do some fancy deprecation thing to make it work.

I like "delayed" for the decorator, in part because it mirrors joblib. For
the version that creates a task, I like task(f, *args, **kwargs), although
I'm not sure we really need both. run/submit/apply have possibly confusing
semantics because they suggest a task might start to be run immediately.
On Tue, Apr 5, 2016 at 11:30 AM, Jim Crist<EMAIL_ADDRESS>wrote:

This has come up enough that I'm +1 with changing it to something people
like better. I like do because it's short, which makes it nice to use
inline. Perhaps 2 functions could be nice to support the 2 usecases:
delayed(f)(*args)    # Can be used as a decorator on a function
do(f, *args)         # Or task, delay, run, submit, apply, etc...
For the second one, I like do best, but we'd have to do some fancy
deprecation thing to make it work.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/dask/dask/issues/1084#issuecomment-205934716

I'm only suggesting an alias.  It sounds like people are ok with adding the following:
delayed = do

See https://github.com/dask/dask/pull/1085


[Core][Metrics] Add Seatunnel Metrics module

https://github.com/apache/incubator-seatunnel/issues/2735
https://github.com/apache/incubator-seatunnel/issues/2592
Purpose of this pull request
Complete the code of seatuunel-metrics according to the framework of the issue, and add module seatuunel-metrics, including seatuunel-core, seatuunel-flink, seatuunel-spark three modules.
seatuunel-core is responsible for the basic definition of the seatunnel indicator system, including the definition of indicators and external interfaces
seatuunel-flink is responsible for the connection between seatunel and flink metrics, and accepts flink metrics
seatuunel-spark is responsible for the connection between seatuunel and spark metrics, and accepts spark metrics

Check list

[x] Code changed are covered with tests, or it does not need tests for reason:
[x] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

Please solved ci problems. Thanks

My opinion is that seatunnel provides unified metrics for the connector-v2 api, and then adds the metrics of seatunnel to the existing reporter of the engine.

This is a feature will do next.

For older versions of the connector, the engine's own metrics are used directly.

There alway can use engine own metrics both old version connector and connector-v2

The metrics reporter of seatunnel may only be used for the engine of seatunnel itself.

At now, our reporter can support flink/spark/seatunnel with a little work. It is not conflict with their own reporter.

check file license header

We merge it into st-metrics branch, should have long term to develop it before ready.


sys.config changes taken from upstream GA release

Issue

Link:https://github.com/NebraLtd/hm-block-tracker/issues/84
Summary: Helium miner 2<IP_ADDRESS> release has light miner built into it (disabled state). There are new variables in the upstream sys.config that needs to incorporated into our cdn sys.config

How
This includes three commits that has not been squashed to make reviewing easier

Adds config-state.template as exact replica of config.template and modifies the script to support two separate configs
makes changes to config-state.template to include new upstream config variables to support lightminers
changes snapshotter/sys.config to new values from upstream.

Screenshots

References

Checklist

[ ] Tests added
[ ] Cleaned up commit history (rebase!)
[ ] Documentation added
[ ] Thought about variable and method names

Fixed review comments.


[Bug] formula =I4/$I$23 =SUMIF($C:$C,V3,$I:$I) don't work!

Before you submit this issue, have you checked the following

[X] Is this really a problem?
[X] I have searched the Github Issues for similar issues, but did not find anything.

Affected packages and versions
0.2.2
Reproduction link
https://stackblitz.com/~/github.com/awesome-univer/sheets-vite-demo
Expected behavior
formula =I4/$I$23 =SUMIF($C:$C,V3,$I:$I)  work
Actual behavior
The formula doesn't work
System information
No response

We are closing this issue for now due to the lack of enough information. Please feel free to reopen it once you can provide a minimal reproduction.

https://stackblitz.com/~/github.com/awesome-univer/sheets-vite-demo?file=src/main.ts here is my reproduction

@jikkai there is no re-open button for me

https://stackblitz.com/~/github.com/awesome-univer/sheets-vite-demo?file=src/main.ts here is my reproduction

It's just an official demo, not your repro.

@jikkai https://stackblitz.com/~/github.com/Picktarget/vitejs-vite-1ztedz?file=src/App.vue how about this? I just make a new repo to reproduce it

@jikkai https://stackblitz.com/~/github.com/Picktarget/vitejs-vite-1ztedz?file=src/App.vue how about this? I just make a new repo to reproduce it

This is still an invalid repro.

@jikkai please try it again https://stackblitz.com/~/github.com/Picktarget/vitejs-vite-1ztedz?file=src/App.vue I just commit my changes failed due to the network T.T

@Dushusir Should have a look.

We will process it as soon as possible

@Dushusir hello Is there any progress?

fixed

@Dushusir maybe u should test with the link https://stackblitz.com/~/github.com/Picktarget/vitejs-vite-1ztedz?file=src/App.vue . It happens if I render formula from workbook data


docs: added a link that leads to the official docker desktop downloading documentation

closes #1151
👷🏻 Changes made

Added a link that leads to the official docker desktop download center.
📸 Screenshots

Hello @tamalCodes can you please check the changes I have made and merge the PR if they are alright.

@tamalCodes it would be of great help to me if you could merge this PR before the 31st of this month. Thanks in advance!