Euclidean modulo

Proposal to add Euclidean modulo & division functionality for integers, to address common issues with taking remainders involving negative integers.
Internals discussion here.
Rendered.

While I like the proposal, I really don't like the _e names.

@mcarton What part of it? That it has a short suffix, or that it has a suffix and not a prefix? Both?

How common is usage of these operations? Would it warrant adding another operator to the language?

@Centril: I couldn't think of a good way to measure the use of these operations, as they can be implemented in various different ways. The rationale behind advocating new methods, rather than new operators, was that we could see how often they were used in Rust (say, 12 months down the line), to see whether they were used common enough to be worth considering as operators.

@varkor this makes sense to me. However, many users will shy away from functionality until it has been stabilized, thus usage metrics for unstable stuff might not be fully representative.

@mcarton What part of it? That it has a short suffix, or that it has a suffix and not a prefix? Both?

The shortness.

If the output of these are always positive, should they return unsigned types instead?
Similarly, it feels like something here should enable (-1i8).modulo(200u8) => 199u8.

@scottmcm: I followed the precedent set by the abs method for returning an integer of the same type, rather than the unsigned variant, as I imagined there was previous rationale for this decision.
Regarding inter-type modulo, the mod_e method as specified in the proposal behaves similarly to the built-in % operator, which also does not allow operations like -1i8 % 200u8. Again, the focus here was on consistency: it feels like this issue is something better addressed by a separate discussion (e.g. the internals thread on implicit widening).

As someone who has hacked euclidean modulo as ((a % b) + b) % b previously (that's branchless :sunglasses: ), I can only support this RFC! I in fact implemented the variant for floats, so it'd be great if the RFC could include them :)

Alternative name possibilities?

mod_e
emod
e_mod
euc_mod
eucmod

Maybe floor_div and floor_rem can be used: whereas div and rem truncate the quotient towards zero, the floor_ counterparts round the quotient down.

@est31: I ran some benchmarks before making the RFC comparing the implementation for Euclidean modulo as suggested in the RFC with the branchless variant, and the RFC version turned out to be ~5x faster. It could be that the branch prediction is making the benchmarks nonrepresentative, so if you have any results to the contrary, please do share them!
@tspiteri: Flooring division and modulo is subtly different (see this paper for more details — essentially Euclidean modulo always returns a nonnegative value), so avoiding the terminology floor would be preferable, to avoid confusion.

Regarding the name: I'm happy with a change of name, provided it doesn't become cumbersome — I'd personally prefer the operation name to come first for aiding discoverability (for example, if other methods are added in the future) via autocomplete, etc. Perhaps div_euc and mod_euc strike the right balance between descriptiveness and succinctness?

@varkor I haven't run any benchmarks and was just guessing that a branchless version is faster. The code path is definitely not hot so I didn't care much.

@varkor Yes, flooring and Euclidean division are different; to use floor_div and floor_rem flooring division would of course need to be used. I much prefer flooring over Euclidean; in Wikipedia's list of modulo operators in various programming languages, flooring division is supported by 71 languages including Common Lisp, Clojure, Haskell, Java, Mathematica, MATLAB, Python and Ruby, while Euclidean division is supported by 8 languages including Maple and Scheme. Also, for example the GMP bignum library supports truncating and flooring division, while not supporting Euclidean division. The paper you linked to makes some arguments for Euclidean over flooring, but I think the arguments are simply a matter of taste, while the similarity with other software is a concrete advantage of flooring over Euclidean.

@est31 Your version can overflow. (50i8 % 100i8) + 100i8 overflows.

@tspiteri I agree that it makes sense to consider what other languages do but it shouldn't be the only argument -- Rust does a lot of things better/differently than other languages. I don't see how differences to other software would be a disadvantage for Rust's modulo function, given that the modulo operator % is already the same as in C, Java etc.
You can also view the bandwagon argument from the opposite side: In mathematics, Euclidean modulo is standard that everyone uses, presumably because it has the most regular properties. I also don't think the arguments in the paper are a matter of taste: the code examples really are more uniform if Euclidean division is used. That is anecdotal evidence but I don't think we have any better kind of evidence.
That said, I don't care very much whether it's flooring or Euclidean modulo. I just think the discussion should include more than personal preference and the bandwagon argument. (Also, I'm kind of afraid this proposal will die because of bikeshedding about this.)

In mathematics, Euclidean modulo is standard that everyone uses

Can you elaborate on usage of negative-divisor modulo in mathematics?  I'm only familiar with strictly-positive ones, and for that flooring and euclidean are the same.

Rambling a bit here:
Parroting mathematical usage can just as well be considered 'the bandwagon argument': π is the standard that everyone uses, mostly for the sake of tradition, even though τ has better mathematical properties.
Euclidean division is defined the way it is because it aligns well with Euclid's division theorem for integers (which requires the remainder to satisfy 0 ≤ r < |d|). This theorem in turn is formulated this way presumably because this is the most concise way to make the division result unique.
But this property cannot be maintained in general Euclidean domains (the 'proper' structure to study division-with-remainder), where a total order relation may fail to exist, nor there may be any way to make the result 'naturally' unique (Gaussian integers, polynomials). From this more general perspective, floor division is just as good a definition of division-with-remainder as the 'Euclidean' division. I see no properly mathematical reason to prefer one over the other.
And I don't recall any programming problem where a division-with-remainder by a negative divisor is meaningful, so from this point of view, there also seems to be no reason to prefer either. (Well, I think I can imagine a problem where the choice of definition may conceivably matter, but I still don't see how either is more advantageous).
That perspective, however, would suggest also adding a ceiling division operator (it's the answer to the question 'how many buckets of capacity n do you need to contain N items?') and a combined division-modulo operation (which answers the problem 'given a scalar offset into a two-dimensional array, what are its corresponding two-dimensional cordinates?'). Admittedly the former can be expressed with (N + n - 1) / n, but that behaves badly in the presence of overflow; while the latter can be probably taken care of by the optimiser, but you may want not to rely on that, and it's still neater to write let (y, x) = offset.divmod(stride) than to compute the quotient and remainder separately.

+1 for a combined division-modulo operation.

I've updated the method names in the proposal with a more descriptive _euc suffix, which is clearer, whilst still remaining relatively concise.
Additionally, I've extended the RFC slightly to include Euclidean division and modulo methods for f32 and f64, as there was support in this thread for a complete implementation (and the floating-point exclusion did seem like a gap in the RFC before).
Regarding the discussion about flooring versus Euclidean division/modulo that arose: I think @fstirlitz summed it up well; in practice, there will very rarely be a difference between the results of flooring and Euclidean modulo/division — taking the negative modulo of a number is a very uncommon operation: it's just a matter of deciding what the behaviour in this particular edge case should be. My feeling was, and the general feeling on the internals thread seemed to be, that Euclidean modulo was the least surprising of the two (and mathematical consistency is a bonus).
I'd be hesitant to add a combined division-modulo method in this RFC — it seems like a separate, though tangentially related, issue — and it'd be better not to crowd this RFC with new methods.

Why wasn't the euclidean modulo made the default for rust?
Isn't the way c handles this kind of a mistake, that other languages just copied?

@porky11 The default is truncating division, which is what typical processors provide for their signed division instructions. So I think it is a matter of providing the fastest possible operation as the default.

We definitely should have something like this, I tihnk I'd prefer a single method div_mod though since they are usually used in combination and it may sometimes be more efficient. eg. (2, 3) == (13).div_mod(5).

So I think it is a matter of providing the fastest possible operation as the default.

The faster operations could have been provided as methods. Too late to change anything now though of course :(

I more often need and use the current behaviour. I'm certain both have
their uses and both are as widespread as the other.
Either way the operator behaviour will not be changed, so discussing it
only serves to increase the noise.
On Oct 26, 2017 09:49, "Andrew Cann"<EMAIL_ADDRESS>wrote:

We definitely should have something like this, I tihnk I'd prefer a single
method div_mod though since they are usually used in combination and it
may sometimes be more efficient. eg. (2, 3) == (13).div_mod(5).
So I think it is a matter of providing the fastest possible operation as
the default.
The faster operations could have been provided as methods. Too late to
change anything now though of course :(
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/2169#issuecomment-339568662, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AApc0k443D1UA6bHlFCSiolAykxBJmiSks5swCtigaJpZM4PzIuy
.

I'm not sure I'd implement this for unsigned primitives as well. Euclidean, flooring and truncating remainders are all the same for non-negative dividends and divisors, so the present div and rem are sufficient. The new methods shouldn't be included simply for consistency between signed and unsigned, for example currently signed primitives have an abs method, while unsigned primitives do not.

@canndrew: Eh, it's doable. Current epoch: introduce the div_trunc and mod_trunc (and divmod_trunc?) methods and make plain / and % operators on signed types deprecated. Next epoch: un-deprecate these operators with changed semantics.
By the way: I'd recommend naming these methods div_variant, mod_variant, divmod_variant, since this way other variants (should any be added) will be easier to discover in code completion tools, which usually sort identifiers alphabetically.
@nagisa, can you show an example where truncation semantics are preferable over both Euclidean and flooring semantics?

@Dynisious it happens every time you use a finite field.  For example, suppose you're using the field {0,1,2,3,4} and you want to implement subtraction or addition within that field.  Using modulo division, you could write (x - y) % 5 and be sure that the result will be a member of the field.  But using remainder division, you'd have to do something like (x - y + 5) % 5.  Finite fields are used in many applications: cryptography, RAID, factoring polynomials, etc.

@Dynisious: Sure.

Circular indexing. Suppose you have an array of N elements which you want to index in a circular fashion, i.e. adding N to any index should refer to the same element as the original index. To accomplish this, you may take a linear index, compute its modulo by N, and use the result as an ordinary array index. For this to work correctly with negative indices, either Euclidean or flooring modulo has to be used.
Unique representation of elements of finite fields, as @asomers mentioned above. The algebraic structure doesn't even have to be a field: this problem arises for any ring induced by a finite cyclic group (e.g. integers modulo 20). This is related to the above point, except the former ignores the muliplicative operation.
Coordinate sectoring. Suppose you have some coordinate space which you want to divide into equal-length blocks (e.g. divide a hard disk into sectors). Combined division-and-modulo by the block size can split a linear coordinate into an index of the containing block and offset within a block. To make this work correctly with negative offsets, you should use either Euclidean or flooring division; which one you choose will have an impact on the interpretation of negative block sizes.
Negative-base representation. Admittedly an esoteric one, but still. Negative-base positional system is able to represent any integer as a pure string of digits without an additional sign symbol. In order to obtain a negative-base representation of a number by the well-known iterative division-and-modulo, you have to use the Euclidean definition. (Flooring gives you negative-valued digits, which have worse properties, while truncating division alternates between negative- and positive-valued digits, which is even worse.) Positive base grants none of the definitions an advantage: you have to check the sign of the number at the start either way. (It's still interesting to see how the different definitions of division behave if you don't.)

There's also a use case for ceiling division: the buckets allocation problem I mentioned above, which often arises as a dual of the sectoring problem. What are the use cases of this kind for truncating division?

@Dynisious to add to @fstirlitz 's comment, I'd personally use it for the "coordinate sectoring" use case.
My map generation code uses perlin noise and it has a loop over the indices in the flat array for each sector and for each index it derives a global 2D coordinate, basically adding the sector offset and the offset obtained from taking the index and doing a modulo. Here, normal modulo is okay.
However, when I go into the opposite direction, and want to check which node the mouse cursor is hovering over, I need to obtain the sector the mouse cursor is in, and the position inside the sector. Here I must use euclidean modulo, except if I have a different layout for sectors with a negative offset. This would make a huge difference in the map generation code as I'd have to work around that!
So euclidean modulo is much better for me.

As an author of modulo which I created after implementing variant of this for each project I have started, I strongly want this.
Personally I have not wanted remainder for anything and using it has caused annoying to debug bugs for several algorithms that I have implemented.
Things that I have used euclidean modulo for:

Tilable

texture generation
world generation
point distributions

Data structures

array deque (in java)
open addressed hashmaps

Game logic

And I haven't had need for negative moduli. (I also realised that I hadn't thought what that crate of mine does in this case, because of this)

So is there any reason for having remainder, other than performance?
I also think, having modulo by default matches rusts philosophy better, since it's more consistant and is the default use case.
It would also just have impact on performance for signed numbers, anyway.

@porky11: this mailing list message is probably the best explanation given for why Euclidean/flooring modulo is not the default in Rust. This is not something that's going to change, so it's not worth discussing which is the "right" choice.

@sfackler: is there any chance of starting a FCP for this RFC? As far as I can tell, all the issues that have been raised have been addressed, and it's just sitting around now.

Sorry for the delay!
The @rust-lang/libs team discussed this recently. We feel that the functionality is valuable, but the _euc prefix naming scheme is not the most easily parseable. Either fully spelling out _euclidian or maybe something like _floor might be better.

Looking through the use cases in the thread, I still feel it ought to be heterogeneously-typed.
For example, circular indexing (and deque indexing and open addressing hash tables and anything else were you lookup by the result in a slice) would be much nicer as v[i.modulo(n)], but as proposed it will end up being v[i.modulo(n) as usize] (or .try_into().unwrap(), or something) because this functionality is only useful for things that are signed, and thus aren't usize already.
As a bonus, a type of fn (iN, uN) -> uN makes the behaviour for negative inputs obvious, so it can have a simpler name without a suffix, in addition to usefully expanding the range.

Personally speaking, I would be happy renaming either to modulo or mod_euclidean, with a slight preference towards the former. Considering the % operator is correctly named remainder, this shouldn't be confusing (especially with a disambiguation note in the docs). I'd be happy if most users never had to know the subtleties of flooring vs Euclidean modulo — in almost every case, it'll do what they expect.
Regarding @scottmcm's point about the use cases, I am starting to feel persuaded. Indexing using the result is common, and it would be nice to avoid casts everywhere. Once/if implicit widening ever happens, the distinction should be minimal too.
However, I would prefer to keep the arguments signed — making the second parameter unsigned, though removing the distinction between flooring vs Euclidean modulo, does make it more awkward for the user — as on top of abs, a cast is required, because abs doesn't return an unsigned value. I don't feel there are significant disadvantages to providing the Euclidean behaviour for users making use of it (as it will be clearly documented).

I'm not really sure whether we want long names like overflowing_div_euclidean. Iterator combinators are allowed to have super short names as well, so why should we disallow moderately short names here?

Following on from @est31's point: I don't see the advantage to spelling the name euclidean out fully (when other methods like mul/div, etc. are shortened). Anyone who knows what Euclideon modulo is will know what euc stands for. On the other hand, anyone who doesn't know won't be enlightened by reading the full name — they'll likely just head for the docs, which is equally elucidating for any name. Considering that we expect mod_euc to be reasonably common (especially in particular domains like mathematics or game development), making it significantly longer seems disadvantageous.
I'd like to know what other people think about changing the return type before making any changes, though. It'd be really nice to finalise this RFC at last.

About the return type, it depends on whether this is meant to look like the other arithmetic operators, or like other inherent functions. For operators on primitives, I would expect the output to be like self, whereas for a non-operator-like inherent function a different return type is not something new, see for example [i32::count_ones](https://doc.rust-lang.org/std/primitive.i32.html#method.count_ones.

And another thing, returning unsigned values suggests to me that this is only intended for indexing, not as a normal division operation where operating on signed integers should return a signed integer. But in that case it would make more sense to call it something like cyclic_index.

@tspiteri makes a good point. I think that considering div_euc will return signed values, mod_euc should have the same type (like an operator) — because otherwise the identity x = n  * x.div_euc(n) + x.mod_euc(n) can't be expressed without casting, which just seems wrong, as the two functions are intrinsically linked.
It's unfortunate that the signature will mean casting is required in some cases, but the consistency seems more important here.

@sfackler: is it possible to follow up regarding the naming convention — taking into account the points others have made, is there strong motivation for requiring euclidean over euc? I feel most people would prefer shorter names (given that they're unambiguous) over longer ones, for common operations.
After that has been resolved, are there any other issues stalling this RFC from a FCP?

@est31 something something foolish consistency something something :P
Yeah, we can figure out the naming as part of stabilization.
@rfcbot fcp merge

because otherwise the identity x = n * x.div_euc(n) + x.mod_euc(n) can't be expressed without casting

But it's also adding new methods, so maybe that just means the set of added methods isn't sufficient yet.  Conveniently, there's even naming and semantic precedent for it in f32::mul_add.
You can have x.div_mod(n) == (a, b) → a.mul_add(n, b) == x.  And those two methods are exactly the ones you'd need for @fstirlitz's coordinate sectoring use case above.
(Their types being div_mod : (iN, uN) -> (iN, uN) and mul_add : (iN, uN, uN) -> iN)

(Their types being div_mod : (iN, uN) -> (iN, uN) and mul_add : (iN, uN, uN) -> iN))

This signature (and similarly if mod_euc were modified in the same way) is hardly better than the current signature: you can't index with a uN unless N is size, so you'd still have to cast in every other case. (And one can't just return usizes, because this may be smaller than the input types.) On top of that, it comes at the cost of consistency.
On the other hand, the current signature is very amenable to modification in the future when implicit widening is introduced, which should eliminate the problems entirely.
(Additionally, for consistency purposes, such a signature for i/uN::mul_add is undesirable: the current signature is mul_add: (fN, fN, fN) -> fN) and having a different signature for integers seems prone to confusion.)

Regarding div_mod specifically: I think there is good reason to add such a method (or family of methods), but think it's outside the scope of this RFC; it's been long enough that I'd rather start with what is currently proposed, and introduce a combined method later (as though it's related, it's orthogonal to the motivations here). (Maybe such a method would even be minor enough to forgo the RFC process?)

We subdivided the libs team a bit.

Alright! FCP has now elapsed and it looks like there were no major things brought up, so I'm going to merge!
Tracking issue

Updated Rendered link + added tracking issue to top post.


Minor changes to the pull request checklist

I've added a line about including a what's new entry (see #2104), and removed the stuff about iris-code-generators at @pp-mo's suggestion, since it's obsolete.

Now I'm looking at it, it seems like it could be worth including "have you added any dependencies to conda-requirements.txt/the install page" as well.

@agbutteriss Now I'm looking at it, it seems like it could be worth including "have you added any dependencies to conda-requirements.txt/the install page" as well.

Definitely worth it :+1:


Fix typo in doc

In paragraph:

Each of your views should use only mixins or views from one of the groups of generic class-based views: detail, list, editing and date

Replace "date" with "update"

I believe date is correct. "update" would be the same as "editing", the third item in the list.

I see. But there is a semantic problem with "should use only mixins from one of groups" part of sentence because most mixins in date group are used together with mixins of detail and list group. For example, class DateDetailView is mixing detail+date mixin groups and class BaseDateListView is mixing list+date groups.
I think it would be better to omit "date" from this sentence.

I think it's still a "a good rule of thumb" as the sentence before the hint says. Generally you probably wouldn't use date-based views with the editing views, for example, and you would use DateDetailView rather than creating your own combination of detail views + date mixin. There may certainly be some exceptions. Did you have one in mind?


feat: include container name in error message. Fixes #10007

Fixes https://github.com/argoproj/argo-workflows/issues/10007

docs test seems unrelated

/retest

/retest

Oh that only runs for ci-build.yaml, right. Manually retrigerred the Docs CI. Never seen that flake before though 🤔

There are some libraries that consider errors as part of the API boundary, but we currently don't. This also isn't the first time we've changed an error.

with exact matching

Some libraries, like protobuf, even intentionally insert randomness to prevent you from doing exact matching like with https://github.com/argoproj/argo-workflows/pull/12737#issuecomment-1977948270 / https://github.com/prometheus/client_model/issues/83

I think this a breaking change, we better have a documentation for this. I can imagine there exist users using conditional retry with exact matching on message

added a note


Smarter detection of toctree elements

Related to this: https://github.com/symfony/symfony-docs/pull/16302
In Sphinx we could do this:
Learn more
----------
.. toctree::
    :maxdepth: 1
    :glob:

    /console
    /components/console/*
    /components/console/helpers/index
    /console/*

Sphinx recognizes that you have added /components/console/helpers/index explicitly and then it doesn't include it repeatedly in /components/console/*
When using Docs Builder, we must do this change:
 Learn more
 ----------
 .. toctree::
     :maxdepth: 1
     :glob:

     /console
     /components/console/*
-    /components/console/helpers/index
     /console/*

This is not an essential feature, but it's nice when you want to include some specific article behind all the other articles.

Let's close this issue because we haven't faced this problem again. It was just a single occurrence, so it's fine. Thanks!


CRC Implementation

Need to implement CRC which is 15 bits long using  the polynomial: x15+ x14+ x10+ x8+ x7+ x4+ x3+ 1

Implement RX portion of CAN bus


HDDS-9251. EC-recovery acceptance test is failling randomly

What changes were proposed in this pull request?
Test case of EC offline reconstruction is intermittently timing out.  To fix that, this PR reduces the delay of Replication Manager's start after safe mode exit, and increases the frequency of replication tasks.
https://issues.apache.org/jira/browse/HDDS-9251
How was this patch tested?
Ran EC acceptance test locally.
CI:
https://github.com/adoroszlai/hadoop-ozone/actions/runs/6120159439/job/16612475120

Thanks @sodonnel for reviewing and merging this.


[dev-mvp]: concern_points are not being passed through POST /safe_paths

Steps to reproduce:

Set backend to true
Load data and save in redaction tool
Load data and save in publishing tool

Expected results:
Data POST /safe_paths contains an array of concern_points
Actual result:
concern_points is not passed
Possible solution:
in saveText(), move the code that creates the concern_points from the code handling no backend to just before the check for the backend.  This way both publishing to a backend or file contains the concern_points.
Found in 369a47

I'm not able to reproduce this:

Can you expand on the issue?

@zmon @AdamLeonSmith We are ignoring concern points in both frontend and backend for POST /safe_path API. This field is just kept for backwards compatibility.
The understanding is that /GET safe_paths will return all 'redacted_trails' co-ordinates within its most recently published start_date and end_date for an organization.
cc @mundanelunacy

To explain further:
So the flow @mundanelunacy discussed with me is:

HA will redact trails and save them.
HA publishes trails by entering start_date and end_date.
HA, while publishing trails, does not edit any trails - just the start and end dates.
/GET safe_paths/<org_id> returns concerned_points between the start_date and end_date from the last published entry for that organization_id.

@krishnadurai Thank you for the clarification.  We are running our own API server (two or three weeks old) for a POC/Demo and grabbed the newer front end.
I will let you close this issue.

Closing this per above.


[DISCUSS] Modifies the interface of PArray and PVector for the backends [engine-dev-pr]

Remove the diamond problem (And the need for users to know about virtual inheritance)
Recover type information
Remove void** pointers
Favors composition over inheritance
Remove the unused MakeArray and MakeVector in the Engine factory

This is more to open the discussion about the Engine interface, this is the most important change I see for the moment.
Among the following changes I see:

We could always use a PArray and PVector under mfem::Array and mfem::Vector, that would mean that we would have a default implementation that uses a default cpu PArray and PVector. That would avoid all the unsafe NULL pointers that make mfem::Array and mfem::Vector sloppy, unsafe, create special cases (we have to check for NULL all the time), is difficult to debug, and makes poor API. That would also avoid mfem::Array and mfem::Vector containing both cpu and gpu data which is really bug prone. It might be useful to carry some kind of RTTI related to the dynamic type of the underlying PArray and PVector. This would always allow us to at least chain Pull() then Push() to make backends compatible with each other.

I'm also very sceptical about the real need for Layout, so far this only add a layer of complexity which seems to never be used, and the only thing that a Layout represents is an Integer... So it would be good to know at least what is the expected behaviour of Layout(mfem::Array<int>& offsets) because it is really obscure for the moment.
update: After a team discussion with @v-dobrev , I think it is still open if this is really needed, since we couldn't have a clear explanation of what they are used for. It would be very nice to have some abstract execution trace to give a clearer idea of the parallelization ideas behind Layout. To me it sounded like it imposes backends to support a parallelism model that is very uncertain to ever be used (and might prevent us from using a different one). Besides, we cannot implement for the moment this parallel model since none of us understands what is supposed to happen with Layout that are not just an Integer. I think it should be a priority to, at least, clarify for the team what a Layout is wanting to achieve.

I think that the new structure for mfem::Array and mfem::Vector is overly complicated, I believe it now requires about 10 hours for a new user to understand how an mfem::Vector works. Most of the classes are never used anywhere, they just make things complicated. Here also having composition between mfem::Array and mfem::Vector would simplify a lot the class structure. Coupled with the first change, it could be easy for a user to understand the new class structure. We should not forget that the point of inheritance is to be reused, and not to reuse code. So is it that important to have Array functions to also take Vector? It would not be difficult to extract the Array if needed. To me Array and Vector are two different concepts, an Array is a linear collection, a Vector is a math object (which conceptually shouldn't be resized for instance), so a Vector is not an Array.

I was thinking that ultimately having:
template <typename T>
class Vector_t<T>{
private:
   const BackendId id;
   PVector<T> data;
public:
   Vector_t(const int size, const BackendId id = default): id(id), data(size,id) {} //PVector becomes a factory
   //If we want to keep Layout
   Vector_t(PLayout& layout, const BackendId id = default): id(id), data(layout,id) {}
   ...
};

typedef Vector_t<double> Vector;

Likewise for Array.

@camierjs @v-dobrev Any opinion on this PR? Things you like, things you don't like? Why?

@YohannDudouit , I have not had a chance to look at this PR yet.
In the meantime, can you fix the issues with the failed checks in Travis and Appveyor?

@v-dobrev This PR is not meant to pass Travis and Appveyor as is, I removed the [WIP] to motivate people to take a look at it, maybe that I shouldn't have. This also opens a conversation that is not included in the code, but in the description of the PR. I didn't want to propose 20 different PRs according to the changes of Engine I've proposed on Slack, this PR shows one suggestion that I believe would improved the most Engine, and opens a discussion on 3 other points.
If this PR arouse enough interest we might want to organize a team meeting (with only the interested persons) to discuss it.

OK, can you add then "[DISCUSS]" or "[RFC]" at the beginning of the title? Thanks!

@v-dobrev @camierjs @vladotomov @tzanio You might want to take a look at this PR since it treats a problem that will most likely be discussed in this afternoon's meeting.

I am closing this PR as it is not directly relevant to the okina approach we are focusing on. @YohannDudouit, I'll leave it up to you to decide if you want to keep the branch or delete that too (the commits will remain).


"error":"connect: does not exist (Connection refused)","details":{}

Hi, I've been recieving an error message upon tring to setup the hsdev package. It seems to not be able to connect. Info:

$ hsdev version
<IP_ADDRESS>
$ hsdev start
Server started at port 4567
$ hsdev ping
{"error":"connect: does not exist (Connection refused)","details":{}}

I have also tried $ hsdev start --cache cache but to no avail. Any other commands return the same error message.

Seems, that hsdev can't start. hsdev run fails on Ubuntu

What is the easiest way of updating my version to this new commit? And thanks a bunch for the quick response.

It's not fixed yet. I'll upload new version on hackage when done

Please check hsdev-<IP_ADDRESS>
Works for me on Ubuntu

I have upgraded to hsdev-<IP_ADDRESS>, and everything is working now. Thanks! Some more output from ST3 console that might be of interest:
Sublime Haskell: failed to connect to hsdev server
Sublime Haskell: connected to hsdev server
Sublime Haskell: Inspection failed: 'HsDev' object has no attribute 'hsdev_socket'
Sublime Haskell: loading standard modules info for cabal failed with 'HsDev' object has no attribute 'hsdev_socket'
Sublime Haskell: connecting to hsdev server...
Sublime Haskell: connected to hsdev server
Package Control: No updated packages
Sublime Haskell: hsdev ghc-mod type returns error: File '/home/jip/Code/Haskell/petProject/src/Main.hs' not found, details: {}
unknown include #infix_op
unknown include #infix_op
unknown include #comments
unknown include #common_keywords
unknown include #literals
unknown include #quasi_quote
unknown include #ctor_names
unknown include #comments
unknown include #common_keywords
unknown include #literals
unknown include #quasi_quote
unknown include #ctor_names

It seems to work now tho, i think this issue can be closed. I can insert types and use auto-fix, so I guess everything should be working. Thanks!

Good!
But it seems, that hsdev unable to scan this file: /home/jip/Code/Haskell/petProject/src/Main.hs
Can you try this command: hsinspect /home/jip/Code/Haskell/petProject/src/Main.hs?

This is the output of the command:

{"location":{"project":null,"file":"/home/jip/Code/Haskell/petProject/src/Main.hs"},"inspection":{"flags":[],"mtime":1453590474},"module":{"location":{"project":null,"file":"/home/jip/Code/Haskell/petProject/src/Main.hs"},"name":"Main","declarations":[{"pos":{"line":5,"column":1},"name":"main","decl":{"what":"function","type":"IO ()"}},{"pos":{"line":8,"column":1},"name":"test","decl":{"what":"function","type":"[Integer] -> Integer"}}]}}

After restarting sublime these messages did not show up again (also the unknown includes seem to be gone now. I'm trying to reproduce them as we speak.

Ok, let me know, if something goes wrong. I'll close this issue

Yesterday my installation worked for a brief moment but somehow it stopped working again after 30 minutes of trying out SH's features. hsdev and ghc-mod seem to be working correctly but when invoked together freeze my terminal.
hsdev run has also produced different output without an error message but I do not know how to reproduce it. My SublimeHaskell plugin has since stopped working. The command hsdev ghc-mod lint src/Main.hs freezes the prompt completely. I have tried setting up a new cabal project to start fresh but it didn't help either. Is there anyway I can give you some more helpful output?

Sublime Haskell: connecting to hsdev server...
Sublime Haskell: connected to hsdev server
Sublime Haskell: connected to hsdev server
Package Control: Skipping automatic upgrade, last run at 2016-01-24 12:48:27, next run at 2016-01-24 13:48:27 or after

hsdev: <<loop>>

I've found similar bug on Ubuntu in simple-log yesterday, but I was hoping, that it's not critical.
Try hsdev-<IP_ADDRESS>

No, it's not fixed yet
Trying to figure it out

Ok, I'll be available if you need testing.

`$ hsdev run
24/01/16 15:29:12 +0100	INFO	> Log politics: low = Info, high = Warning
hsdev: bind: resource busy (Address already in use)
24/01/16 15:29:12 +0100	INFO	hsdev> Server started at port 4567
hsdev: <>
exception thread blocked indefinitely in an MVar operation
$ hsdev run --port 7654
24/01/16 15:29:27 +0100	INFO	> Log politics: low = Info, high = Warning
24/01/16 15:29:27 +0100	INFO	hsdev> Server started at port 7654
$ hsdev run --port 7654
24/01/16 15:30:24 +0100	INFO	> Log politics: low = Info, high = Warning
hsdev: bind: resource busy (Address already in use)
24/01/16 15:30:24 +0100	INFO	hsdev> Server started at port 7654
hsdev: <>
exception thread blocked indefinitely in an MVar operation

Changing the port number makes the servers run (or at least not crash, I cannot stop the process however and have to forcequit my terminal). Running on the same port again after forcing the terminal to quit makes the error reappear.

Port 4567 is already in use by hsdev start, thats why hsdev run fails, but this instance of hsdev start doesn't respond due to some reasons. When I killed it (kill -9 pid) and restarted - all seems to be ok.

I just got it to work again (did not upgrade to <IP_ADDRESS> yet). After killing the process and using hsdev stop I could start the server manually through terminal (hsdev start, is it necessary to do this manually?) and then hsdev ghc-mod lint src/Main.hs completed succesfully and sublimehaskell seems to be working again.

Killing process must be enough, Sublime will restart it

Just killing the process doesn't seem to work. I can get it to work now by starting the server manually, and checking if hsdev ghc-mod lint src/Main.hs is working. If it is, sublime will work as well. If I exit ST3, the process does not seem to be shut down (hsdev start --port 4557). If I shut it down, and then start the server manually it works again. Can this point you to the bug a little?

Thanks a lot for help. I'll fix some bugs I've found and then will test it on Ubuntu

I've uploaded hsdev-<IP_ADDRESS> with some fixes.
Please test it when you have some time

Hi, I have tested version <IP_ADDRESS> and some things still seem to be wrong. SublimeHaskell + hsdev only seem to work when I $hsdev run and start up sublime. When I exit sublime hsdev gives a rather long exit message. After closing sublime I need to $hsdev stop and as soon as the process is gone, I can start over again. Just starting sublime does not seem to work. Thanks for the bugfixes anyway, maybe there is something wrong with my own setup if you don't experience these problems anymore?

Do you have Sublime Haskell: Starting hsdev server in Sublime console? And, if any, what goes after it?

This is the output if I start ST3 without starting starting the hsdev server manually:
Sublime Haskell: Starting hsdev server
Sublime Haskell: connecting to hsdev server (0)...
Sublime Haskell: connecting to hsdev server (0)...
Sublime Haskell: failed to connect to hsdev server
Sublime Haskell: failed to connect to hsdev server
Sublime Haskell: connecting to hsdev server (1)...
Sublime Haskell: connecting to hsdev server (1)...
Sublime Haskell: connected to hsdev server
Sublime Haskell: connected to hsdev server

So it seems to connect in the end, although it sometimes needs up to 7 or 8 tries. It did this before the last patch as well. If I start hsdev server manually by $ hsdev run it's all working and this is the ST3 console output:
Sublime Haskell: Starting hsdev server
Sublime Haskell: connecting to hsdev server (0)...
Sublime Haskell: connecting to hsdev server (0)...
Sublime Haskell: failed to connect to hsdev server
Sublime Haskell: connected to hsdev server
Sublime Haskell: Inspection failed: 'HsDev' object has no attribute 'hsdev_socket'
Sublime Haskell: loading standard modules info for cabal failed with 'HsDev' object has no attribute 'hsdev_socket'
Sublime Haskell: connecting to hsdev server (1)...
Sublime Haskell: connected to hsdev server

Another important detail might be that I have to do $ hsdev run from the same directory as where my cabal file resides, otherwise it still isn't working.

Thanks

So it seems to connect in the end

And it still doesn't work in this case?

Another important detail might be that I have to do $ hsdev run from the same directory as where my cabal file resides, otherwise it still isn't working.

Thanks, I'll try to reproduce it

No, it still doesn't work in that case.

Very strange
Can you test $hsdev ping from terminal and these commands from Sublime console:
import SublimeHaskell.autocomplete as a
a.hsdev_client.ping()

Jipperism~$ hsdev ping
{"error":"connect: does not exist (Connection refused)","details":{}}
Jipperism~$ hsdev start
Server started at port 4567
Jipperism~$ hsdev ping
{"error":"connect: does not exist (Connection refused)","details":{}}
Jipperism~$ hsdev run
01/02/16 14:24:29 +0100	INFO	> Log politics: low = Info, high = Warning
01/02/16 14:24:29 +0100	INFO	hsdev> Server started at port 4567
01/02/16 14:24:34 +0100	INFO	<socket: 23>> <socket: 23> connected
01/02/16 14:24:34 +0100	INFO	<socket: 23>> <socket: 23> disconnected
01/02/16 14:24:34 +0100	TRACE	<socket: 23>>  => {"command":"ping","current-directory":"/home/jip","silent":false,"no-file":false,"id":null,"timeout":0}
01/02/16 14:24:34 +0100	ERROR	<socket: 23>> exception: user error (Receive chan closed)

In different terminal:
Jipperism~$ hsdev ping
{"message":"pong"}

In ST3 console:
>>> import SublimeHaskell.autocomplete as a
>>> a.hsdev_client.ping()
True

SublimeHaskell was not working while I called a.hsdev_client.ping().

Does hsdev start from terminal always fails to start server (i.e. hsdev ping fails after hsdev start and works only if you run hsdev run)?
If yes, try this:
hsdev start --log-config "use trace" --log hsdev.log
hsdev ping
hsdev stop
cat hsdev.log

I think this bug is fixed in <IP_ADDRESS>

Hi! Sorry for my late reply, i have been very busy lately. I reinstalled hsdev as well as sublimehaskell and now everything seems to be working perfectly! Awesome man, thanks a lot, I'll play around with it some more today.

Great


[ZeroTrust] add securityContext/resource values

Signed-off-by: Frank Kloeker<EMAIL_ADDRESS>

@eumel8 thank you for your contribution! Since there are conflicts here, I have brought your changes into https://github.com/rancher/helm-project-operator/pull/35 instead; will close this PR, but please leave comments on the PR if there are any concerns!


05 Jun 2024 - A11y Theme Builder Meeting Minutes

Date
2024-06-06 - 09:15am EDT
Zoom info

Meeting link: https://zoom.us/j/91013899295?pwd=Qnh5UVN1aUZ4ak9tODgvMVNLNUg5Zz09
Meeting id: 910 1389 9295
Password: 123225
Call-in: +1<PHONE_NUMBER> US (New York) (Check calendar for more options)

Untracked attendees

Fullname, Affiliation, (optional) GitHub username
...

Meeting notices

FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact<EMAIL_ADDRESS>with any questions.

FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

[x] Convene & roll call (5mins)
[x] Display FINOS Antitrust Policy summary slide
[x] Review Meeting Notices (see above)
[x] Approve past meeting minutes
[x] Community WG update (@PaulaPaul)

[x] badges
[x] NSBE
[x] Landing Page issue

[x] Mentorship update (@aaronreed708)

[x] declines sent
[x] opening issues for color palette, commenting on Figma

[x] Update main branch (@aaronreed708)

[x] EasyCLA issue

[x] ...
[x] AOB, Q&A & Adjourn (5mins)

Minutes

Lisa provided a Community WG update

Conference updates

Cody was accepted as a presenter at All Things Open
We've been accepted to present at FINOS OSFF London
We've been accepted to present at Grace Hopper

FINOS and licensing

Lise is suggesting that we (and perhaps FINOS) needs to think about licenses for Token Studio and Anima in the future

Design Thinking session will happen on 06/11 at 12pm EDT for new landing page

defining requirements for development

First round of badges have been issued to verify the process.  Preparations for issuing more badges next month.
Mao from FINOS has contacted us re: NSBE interest in contributing and amplifying our messages

Paula will reach out to the association

Aaron updated on mentorship

worked with FINOS to get the notifications sent to the candidates that weren't selected
new issues opened for initial work on #820, related to ColorPalette creation

Main branch PR is ready, being reviewed

Aaron brought up the issues that were caused from an EasyCLA email change and what we've learned from the experience, so we'll need to communicate the lessons learned

Decisions Made

[ ] ...

Action Items

[ ] Aaron and Evan need to break the Epic that will be worked on by the mentee into detailed and digestable issues
[ ] Lise to work with Aaron to update video in mkdocs documentation
[ ] ...

Cody Zuschlag - Nearform

Kathleen Burkhardt - BlackRock

Aaron Reed - DFS
Lise Noble - DFS
Omesh Kumawat

Approved in this week's call


Using Carthage can't import RealmStorage

Following the readme directions but RealmStorage isn't accessible. Everything else is. Integrating with existing project. But not bridging to objc. Only using in swift.

Module not found error.

Sorry, did not quite get it, what module not found?
Did you add
import DTTableViewManager
import DTModelStorage

to your swift file or bridging header?

No the problem is I'm not able to access RealmStorage from SWIFT. I'm not trying to use in objective c.
Sent from my iPhone

On Feb 14, 2016, at 2:56 AM, Denys Telezhkin<EMAIL_ADDRESS>wrote:
Sorry, did not quite get it, what module not found?
Did you add
import DTTableViewManager
import DTModelStorage
to your swift file or bridging header?
—
Reply to this email directly or view it on GitHub.

And i'm talking about Swift, not ObjectiveC. ObjectiveC is not supported at all by DTTableViewManager.

I'm closing issue until more info is provided. If you are still experiencing this problem, or have more information to share, please feel free to reopen.


Array access on object not an error

Trying to access a key of an object that does not exist gives a Flow error, but trying to access it as an array does not. Is there ever a valid reason for accessing an Object as an Array? (We just switched the return type of a function from an array of two values to an object, and expected Flow to tell us which functions we needed to update, but it didn't. We missed one, and I just ran into an error now).
const a = {name: 'helo'}
a.nom # error
a[1] # no problem

JavaScript allows you to use array access on objects. Flow has ambitions to support JavaScript "as it is," so Flow allows array access on objects. An exact type could solve your problems, but it'll take explicit annotations:
const a: {|name: string|} = {name: 'helo'};
a.nom //error
a[1] //error

If you've been using unannotated arrays, then Flow was typing them as tuples which behave a lot like exact typed objects.

It's now both erroring


Add character limit to group summary on results page?

Adding some limit to the summary on the results page would be ideal so you don't have entries taking up the whole page, like so:
https://www.dropbox.com/s/zpx5iw0otf26z46/Screenshot 2016-03-08 22.08.55.png?dl=0

@samclaridge Looks like we are doing that now. So, I'll close.


Add FlashTorch and Lucent under Visualization

Thanks for the compilation of PyTorch resources! I've added two more visualization libraries FlashTorch and Lucent (disclaimer I am the owner of Lucent)

Thanks! Merged.


Is the Phoenix Guide for exrm releases deprecated or are my releases being generated incorrectly?

The Phoenix Guides seem to reference an old version (0.19.0) and some stuff happens differently from my experiments:
The guides says that an app-0.0.1.tar.gz tarball will be in rel/app, but these don't appear in my releases (I'm using MIX_ENV=prod). The only tarball I have is in rel/app/releases/0.0.1/app.tar.gz.
Is this the correct tarball to use now? Or should that 0.0.1 tarball appear?

@sashaafm The rel/app/releases/0.0.1/app.tar.gz is the correct tarball.  The Phoenix guide must be incorrect.

@sashaafm The Phoenix guide is slightly out of date, it looks to me like that's the only thing that is outdated though.
/cc @chrismccord

I had actually sent a pull request earlier to correct some of the outdated
stuff there and then noticed the other stuff like the different tarball
directory. I can further update the guide after dinner if you don't mind.
A seg, 29/02/2016, 20:55, Paul Schoenfelder<EMAIL_ADDRESS>escreveu:

@sashaafm https://github.com/sashaafm The Phoenix guide is slightly out
of date, it looks to me like that's the only thing that is outdated though.
/cc @chrismccord https://github.com/chrismccord
—
Reply to this email directly or view it on GitHub
https://github.com/bitwalker/exrm/issues/307#issuecomment-190384922.

@sashaafm That would be very helpful! Thanks!


nexus_1.core.nexusWrappedType is not a function

Prisma CLI version: prisma/1.34.10 (darwin-x64) node-v12.7.0
Prisma server version: 1.34.8
ts-node index.ts
TypeError: nexus_1.core.nexusWrappedType is not a function
at Object.prismaObjectType (/node_modules/nexus-prisma/src/definitions/objectType.ts:21:15)
at Object. (/resolvers/Query.ts:12:15)
at Module._compile (internal/modules/cjs/loader.js:777:30)
at Module.m._compile (/node_modules/ts-node/src/index.ts:493:23)
at Module._extensions..js (internal/modules/cjs/loader.js:788:10)
at Object.require.extensions. [as .ts] (/node_modules/ts-node/src/index.ts:496:12)
at Module.load (internal/modules/cjs/loader.js:643:32)
at Function.Module._load (internal/modules/cjs/loader.js:556:12)
at Module.require (internal/modules/cjs/loader.js:683:19)
at require (internal/modules/cjs/helpers.js:16:16)
error Command failed with exit code 1.

This happens since nexus 0.12.0-rc and  this commit. A workaround is to use the 0.12.0-beta.14 of nexus.

same problem here, does not happen if created with prisma cli 1.34.8, fails when upgrading to 1.34.10 and regenerate client code.

Assuming it is at all possible to have nexus (in refactored form) work with pre-0.4 nexus-prisma, then I think that should be attempted. I want to use the nexus plugin API, but is for now stuck on Prisma 1 and corresponding nexus-prisma. nexusWrappedType is according to nexus an internal function, so nexus-prisma's use of it is probably possible to rewrite?


Allow HTML in the copyright string to be rendered

As a user, I want to license my content unter a Creative Commons license. Therefore, I'd like to be able to add a link inside the copyright string that won't get escaped.
This could be implemented using Hugo's safeHTML.

Interesting idea!

Interesting idea!


Add l1 support to ActualCost

Calculate l1 actual fee via ActualCost: its logic was almost identical to the logic of calculate_actual_fee_and_resources.
Required adding l1_payload_size which was always None for AccountTransaction, which were the only txs ActualCost supported thus far.
Also added sender_address for the opposite reason as the prev bullet.
Removed NEW_TOKEN_SUPPORT TODO since it is already fixed inside ActualCost.

This change is

Codecov Report

Merging #1039 (295147f) into main (91d7ab3) will decrease coverage by 0.15%.
Report is 34 commits behind head on main.
The diff coverage is 47.16%.

@@            Coverage Diff             @@
##             main    #1039      +/-   ##
==========================================
- Coverage   67.79%   67.64%   -0.15%
==========================================
  Files          51       51
  Lines        6253     6456     +203
  Branches     6253     6456     +203
==========================================
+ Hits         4239     4367     +128
- Misses       1632     1706      +74
- Partials      382      383       +1

Files
Coverage Δ

.../blockifier/src/transaction/account_transaction.rs
94.59% <100.00%> (+0.29%)
:arrow_up:

...ates/native_blockifier/src/transaction_executor.rs
15.87% <0.00%> (ø)

...lockifier/src/transaction/transaction_execution.rs
3.00% <0.00%> (+0.05%)
:arrow_up:

crates/blockifier/src/fee/actual_cost.rs
77.55% <52.63%> (-15.96%)
:arrow_down:

... and 8 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Improve transaction logic

This PR improves the transaction logic. A step towards #220.

bors r+

bors r-

Closes #220.

bors r+

bors r-

bors r+

bors r+

bors r+

This is a pretty big bugfix, so I'll create a new release.


Support for vscode-icons

Bonjour
I used to compile VSCode myself on Raspberry. However, since version 1.1 it seems I'm no longer able to do it. At the end, I decided to download the deb installer on the site. Everything works like a charm. Thank you very much.
One point that may help others
If one want to install vscode-icons extension he must edit the file /usr/share/code-oss/ressources/app/package.json and set the "name" to "Code" (and nothing else)
This can be done even if the extension is already installed and no icon show up in the Explorer tab.
Regards, Philippe

Noted.
I've just writte this on a few other tickets but I've been toiling away on some changes that will bring all of the build system into the open, and onto Github.  There were some technical challenges involved in this, but I've been writing up what's changed for when I get it released (very soon).
Sorry for the lack of recent builds, I promise the wait will have been worth it. :-)

The builds have now been updated and are on github, inside this repository.
Can you try installing the latest deb file for your architecture (armhf) from the releases page? (problems with bintray at the minute).


style(gh-pages): change code field in esl-tabs examples

:tada: This PR is included in version 4.0.0-beta.18 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Can't render multiple controls without wrapping them in a container

Describe the bug
The following code should render two controls (as shown in the documentation), however no controls are rendered.
<template #controls>
    <!-- no controls are rendered -->
    <HstSelect title="Color" v-model="state.color" :options="colors" />
    <HstText title="Label" v-model="state.label" />
</template>

Wrapping both controls inside a container solves the issue:
<template #controls>
    <!-- two controls are rendered -->
    <div>
        <HstSelect title="Color" v-model="state.color" :options="colors" />
        <HstText title="Label" v-model="state.label" />
    </div>
</template>

I provided a Nuxt Stackblitz reproduction, with two <Variant>s of <BaseButton>, reproducing the bug.
Reproduction
Nuxt Stackblitz
System Info
System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh

Binaries:
    Node: 18.18.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.14.0 - /usr/local/bin/pnpm

npmPackages:
    @histoire/plugin-nuxt: ^0.17.10 => 0.17.10
    @histoire/plugin-vue: ^0.17.11 => 0.17.11
    histoire: ^0.17.9 => 0.17.9

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion.
[X] The provided reproduction is a minimal reproducible example of the bug.

Experiencing the same issue. This was working fine till<EMAIL_ADDRESS>


Add default validations for addt'l fields not specified in UCLDC_map()

I don't think any of these fields need custom validators since we're comparing the content to what's currently in Solr, but if you think it's a good idea then let me know. Some fields that are funky (they have :: as a separator): campus_data, collection_data, repository_data.

Validator.required_field + Validator.content_match is kind of strange, it does this:

Rikolti Value
Solr Value
Validation Report

"a"
"b"
1 line report: Content mismatch, expected "b", rikolti is "a"

"a"
None
1 line report: Content mismatch, expected None, rikolti is "a"

None
"b"
2 line report: Content mismatch, expected "b", rikolti is None; Required field missing

None
None
1 line report: Required field missing

The only case when we get an error due to required field, but not an error due to a content mismatch, is when the field is already None in Solr. In many of these cases, we're waiving the issue as a post-MVP thing to tackle, since it is already None in Solr.
So including both of these validation functions kind of winds up just making reports super duper long but not actually providing us with any additional actionable information than what we already get from the Validator.content_match function. Could we get rid of Validator.required_field it in the validation definitions you've added here?

@amywieliczka re all of your questions about what various fields are, see:
https://help.oac.cdlib.org/support/solutions/articles/9000101639-calisphere-apis
https://github.com/ucldc/solr_api/blob/master/dc-collection/conf/schema.xml

@amywieliczka Thanks for the feedback!! I'll do these 2 things and ping you for another review when done:

Remove Validator.required_field from validation definitions
Do analysis on which fields from Solr are meaningless/unused, and remove them from the calisphere_solr mapper, the default set of validatable fields, and the OpenSearch schema.

@amywieliczka OK this is ready for your re-review. It was pretty clear that the fields I removed are meaningless/unused.
As discussed, reference_image_md5 is now thumbnail.
And I believe that reference_image_dimensions can be removed also. We don't have the value at the point of validation. In the legacy harvester, solr_updater composes the reference_image_dimensions field from the couchdb field object_dimensions value: https://github.com/ucldc/harvester/blob/b42846bf9d869e6f75dbb0b9f9e0e30273d3d35c/harvester/solr_updater.py#L67
The couchdb field is populated by the image harvester: https://github.com/ucldc/harvester/blob/b42846bf9d869e6f75dbb0b9f9e0e30273d3d35c/harvester/image_harvest.py#L225
I think the content harvester can populate this field as part of the thumbnail dict, so it will look something like:
                "thumbnail": {
                    "properties": {
                        "mimetype": {"type": "keyword"},
                        "thumbnail_filepath": {"type": "keyword"},
                        "thumbnail_dimensions": {"type": "keyword"}
                    }
                }

Or it could even be broken out into width and height and stored as integers?


Add --vaadin-overlay-context-width CSS property

Allow the theme to use the context width to size the overlay.
One use case for this is to set a min-width for vaadin-dropdown-menu-overlay so that it matches the width of vaadin-dropdown-menu-text-field.
This implementation is debatable if it is the best way to support the above use case. We could also choose to implement this in those elements specifically which benefit from this (dropdown-menu, combo-box, and date-picker).
Also, it can be argued that we should also then expose --vaadin-overlay-context-height. IMO we can postpone that for later if we come up with a use case for that.

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

a discussion (no related file):
Would be nice to have a generic implementation for the dropdown use case. Feels like a generic dropdown should support both width and position anchoring to the hosing element. This PR introduces width derived from the host, but not position, that does not feel right.
I would be in favour of fixing the <vaadin-dropdown-menu> width in the element specifically, same way as this is done in combo-box. We can refactor into a generic dropdown later on.

src/vaadin-overlay.html, line 411 at r1 (raw file):

      _attachOverlay() {
        const parent = this.parentNode.host || this.parentNode;
        this.updateStyles({'--vaadin-overlay-context-width': parent.offsetWidth + 'px'});

That’s probably really bad for <vaadin-context-menu>...

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

a discussion (no related file):
Previously, platosha (Anton Platonov) wrote…
Would be nice to have a generic implementation for the dropdown use case. Feels like a generic dropdown should support both width and position anchoring to the hosing element. This PR introduces width derived from the host, but not position, that does not feel right.
I would be in favour of fixing the <vaadin-dropdown-menu> width in the element specifically, same way as this is done in combo-box. We can refactor into a generic dropdown later on.

Probably so.
I actually started by prototyping this in vaadin-dropdown-menu, but then though it’s also usable for combo box (if we can someday use Tomi’s flexbox scroller) and date picker (it could also stretch to the host element width). The possible future vaadin-menu-button would also benefit from this.

src/vaadin-overlay.html, line 411 at r1 (raw file):
Previously, platosha (Anton Platonov) wrote…
That’s probably really bad for <vaadin-context-menu>...

Well, not bad IMO, but possibly confusing. But it shouldn’t be, though. The menu is for that exact “context”, so you just need to read it right :smile:
I can’t think of a good use case for this in context menu now, but I thought it wouldn’t hurt there either, allowing the theme to be creative in using that if needed.

Comments from Reviewable

Opened https://github.com/vaadin/vaadin-dropdown-menu/pull/107
Feel free to close this PR in favor of that one. We can consider if we want to do the same for date-picker still.

I'm not sure I'm reading this right but does this mean the vaadin-combo-box-light will still use the hard coded width of the parent element for the overlay ? This is really bad when the parent element is narrow (in my case in a grid column). The suggestions in the overlay will hardly be readable. However, if I'm able to set the width of the overlay the suggestions appear nicely.

@garcus, combo box still uses the hard-coded value. I believe we won’t be doing this as a general feature for vaadin-overlay for now.
For combo box, as mentioned in some of the issues, the problem is the iron-list inside the overlay, which needs an explicit width to work, it can’t size itself based on the content (because all the items are absolutely positioned).
But, as a workaround, you can define a min-width for all of your combo box dropdowns:
<dom-module id="my-combo-box-overlay" theme-for="vaadin-combo-box-overlay">
  <template>
    <style>
      :host {
        min-width: 300px;
      }
    </style>
  </template>
</dom-module>

Closing in favor of the vaadin/vaadin-dropdown-menu#107


zhj

Description of the feature or fix
A clear and concise description of what the bug or new feature is.
Checkpoints

[ ] Follow the styling guide
[ ] Update CHANGELOG.md
[ ] Update the documentation

重新提交


Need example for decompressing a file

The only example I can find is the one on the main docs page, showing outputting to a string.

BTW, how to read a compressed text file line by line like lzma in Python?


WARNING StrEnum was used from linksys_velop

Some other warning which popped up recently.
2024-05-07 19:07:44.021 WARNING (ImportExecutor_0) [homeassistant.backports.enum] StrEnum was used from linksys_velop, this is a deprecated alias which will be removed in HA Core 2025.5. Use enum.StrEnum instead, please report it to the author of the 'linksys_velop' custom integration

Should be resolved by #465


String extension method MatchContains throws System.InvalidOperationException: Unable to parse method MatchContains

Hi,
I am trying to use the String extension method MatchContains in my Where clause on IRedisCollection.
This is my search where I want to perform an infix search:
redisCollection.Where(x => x.Address.MatchContains("road"));    - inspired by this test
When I execute the query this exception appears:
System.InvalidOperationException: Unable to parse method MatchContains
The property on my model is of type string and marked with an Searchable attribute. I have also tried using the Indexed attribute but this also resulted in the same exception.  A quick search in the git repo points me to the method TranslateMethodStandardQuerySyntax in ExpressionParserUtilities.cs
Versions:
Redis OM   v. 0.7.4
RediSearch v. 2.8.13
RedisJson   v. 2.6.10

@obradl, can you share your model and the code you are using? Or some minimal reproduction. I can't get this to happen on my end.

I also get this error on MatchStartsWith and MatchEndsWith.
Model:
public class House
{
    [RedisIdField]
    [Indexed]
    public required Ulid Id { get; set; };

    [Searchable(Aggregatable = true, Sortable = true)]
    public string Address { get; set; }
}

The calling code:
  var houses = housesCollection.Where(x =>
      x.Address.MatchStartsWith("wood").ToListAsync();

StackTrace:
System.InvalidOperationException: Unable to parse method MatchStartsWith
at Redis.OM.Common.ExpressionParserUtilities.TranslateMethodStandardQuerySyntax(MethodCallExpression exp, List1 parameters)    at Redis.OM.Common.ExpressionParserUtilities.GetOperandStringForQueryArgs(Expression exp, List1 parameters, Boolean treatEnumsAsInt, Boolean negate, Boolean treatBooleanMemberAsUnary)
at Redis.OM.Common.ExpressionTranslator.TranslateBinaryExpression(BinaryExpression binExpression, List1 parameters)    at Redis.OM.Common.ExpressionTranslator.TranslateBinaryExpression(BinaryExpression binExpression, List1 parameters)
at Redis.OM.Common.ExpressionTranslator.TranslateBinaryExpression(BinaryExpression binExpression, List1 parameters)    at Redis.OM.Common.ExpressionTranslator.BuildQueryFromExpression(Expression exp, List1 parameters)
at Redis.OM.Common.ExpressionTranslator.BuildQueryFromExpression(Expression expression, Type type, Expression mainBooleanExpression, Type rootType)
at Redis.OM.Searching.RedisCollectionEnumerator1..ctor(Expression exp, IRedisConnection connection, Int32 chunkSize, RedisCollectionStateManager stateManager, Expression1 booleanExpression, Boolean saveState, Type rootType, Type type)
at Redis.OM.Searching.RedisCollection1.GetAsyncEnumerator(CancellationToken cancellationToken)    at Redis.OM.Searching.RedisCollection1.ToListAsync()

@obradl - Using your model (I cleaned it up a bit because the syntax was off):
[Document(StorageType = StorageType.Json, Prefixes = new[] {"House"}, Language = "norwegian")]
public class House
{
    [RedisIdField]
    [Indexed]
    public required Ulid Id { get; set; }

    [Searchable(Aggregatable = true, Sortable = true)]
    public string Address { get; set; }
}

I ran the following with Redis OM .NET 0.7.4:
var muxer = ConnectionMultiplexer.Connect("localhost:6379");
var provider = new RedisConnectionProvider(muxer);
provider.Connection.DropIndexAndAssociatedRecords(typeof(House));
provider.Connection.CreateIndex(typeof(House));
var collection = provider.RedisCollection<House>();
var str = "wood";
await collection.Where(x => x.Address.MatchContains(str)).ToListAsync();
await collection.Where(x => x.Address.MatchStartsWith(str)).ToListAsync();
await collection.Where(x => x.Address.MatchEndsWith(str)).ToListAsync();

and could not replicate your issue, the correct query is created and sent. Can you send over a full, minimal reproduction that I can run and actually see it break?

I observe that MacthContains works if it is the only operator in  the query, so your example works fine for me as well. However, if do something like this ( using MatchContains on both City and Address) it fails :
using Redis.OM;
using Redis.OM.Modeling;
using StackExchange.Redis;

var muxer = ConnectionMultiplexer.Connect("localhost:6379");
var provider = new RedisConnectionProvider(muxer);
provider.Connection.DropIndexAndAssociatedRecords(typeof(House));
provider.Connection.CreateIndex(typeof(House));
var collection = provider.RedisCollection<House>();

var str = "someText";

var result = await collection.Where(x =>
    x.Address.MatchContains(str) ||
    x.City.MatchStartsWith(str))
    .ToListAsync();

[Document(StorageType = StorageType.Json, Prefixes = new[] {"House"}, Language = "norwegian")]
public class House
{
    [RedisIdField]
    [Indexed]
    public required Ulid Id { get; set; }

    [Searchable(Aggregatable = true, Sortable = true)]
    public string Address { get; set; }

    [Searchable(Aggregatable = true, Sortable = true)]
    public string City { get; set; }

    [Searchable(Aggregatable = true, Sortable = true)]
    public string Region { get; set; }
}


Feature/Question: Set default active(focused) input on screen

Will be handy to select which input will be default after screen shows up.. Now it's most left button or widget.
But I have buttons layout (in HW) as SWITCH and SELECT. and OnScreen I have "No, Yes" buttons, but No is selected as first. I know I can swap on-screen buttons, but would be handy to pre-select that "YES" one, which is right (same as SELECT/ENTER button is on right side)

See this part of the doc. You have full control over which object is the default and the order in which they are subsequently selected.

Oh yea, that works. I swap also creating of elements to make it "logically" in code from left-->right order.. So yes, if I will initialize first item which I want to be default, then it works.
I read doc, but not too carefully to find this section. I look for it around widget / buttons sections


overlapping plots generated by make_magic_plots.py

What command was run:
python make_magic_plots.py on contribution https://earthref.org/MagIC/19580
What happened:
A histogram was generated that overlay an intensity histogram and a pole plot.

What I expected to happen:
We need to update the code so that it makes both better pole plots and doesn't make plots that overlie one another like this.
PmagPy version:
4.2.108

This issue is related to this one in earthref/MagIC: https://github.com/earthref/MagIC/issues/568

@njarboe, do you know if we actually need both /make_magic_plots.py and /programs/make_magic_plots.py in this repo?

it should be in programs - keeps the main directory cleaner.
lisa

On Nov 1, 2022, at 9:10 AM, Rupert @.***> wrote:
@njarboe https://urldefense.com/v3/__https://github.com/njarboe__;!!Mih3wA!AfNBEM-ezbXIthU-bQN3cE0UX88eMKsB6lYmbFA6QrcGwhDVTtDlv_9Xs09giHJ2OBQ4EIzYuYF9SZGYwJWnkJ4$, do you know if we actually need both /make_magic_plots.py and /programs/make_magic_plots.py in this repo?
—
Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/PmagPy/PmagPy/issues/667*issuecomment-1298769228__;Iw!!Mih3wA!AfNBEM-ezbXIthU-bQN3cE0UX88eMKsB6lYmbFA6QrcGwhDVTtDlv_9Xs09giHJ2OBQ4EIzYuYF9SZGYgSGYHJk$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AABKWDLU2B6USCOQ2H6YCQ3WGE6INANCNFSM6AAAAAARHM73JU__;!!Mih3wA!AfNBEM-ezbXIthU-bQN3cE0UX88eMKsB6lYmbFA6QrcGwhDVTtDlv_9Xs09giHJ2OBQ4EIzYuYF9SZGYymg5W7M$.
You are receiving this because you are subscribed to this thread.

They're identical at the moment, so I'll remove /make_magic_plots.py

I don't think they are identical as there is a March 24 commit to the one in programs b8dd06080edbb6225ec0aadfa86e109d8c8e6228 with the last commit to the one in Master being in 2020 0d37a8378ad148f6add5a52db3a504c1c6f22b43
But given that the one in programs is the most recently updated, it is the one that makes sense to move forward with so your plan makes sense.


Date-time-convert.cc Issue

The program is intended to convert a date string from "YYYY-MM-DD HH:MM:SS" format to "MM/DD/YYYY HH:MM:SS" format and print it. However, it contains a memory memory leak issue.
Steps to Reproduce
1- First step to reproduce the issue/bug: Compile and run the provided code.
2- Second step to reproduce the issue/bug: Observe the console output and look at system memory usage.
3-  Third step to reproduce the issue/bug: Check for any errors, warnings, or unusual behavior.
Expected Behavior: The program should output the formatted date (03/17/2022 10:45:30) in the console. The program should allocate memory efficiently and release it at the end of execution.
Actual Behavior: The date is formatted and printed as expected. The program allocates a large amount of memory with malloc(120000000), which is a crazy amount of memory and may lead to a crash.
Screenshots
NO
Additional Information:
Operating System:  Windows 11
Browser: Chrome
Version: CLion version 2024.2.1
Other relevant information: No cleanup is performed for the allocated memory, which could cause memory leaks.
Possible Solution:
Replace malloc(120000000) with a smaller, necessary allocation or remove it since its not needed Use 'delete' to release allocated memory to prevent memory leaks.
Related Issues
N/A
Priority
Medium
Reproducibility
Always
Impact
Medium - The high memory allocation is unnecessary and can cause instability on systems with limited memory.

Hahaha what's wrong with you. Just get more ram. Closing.

Removed memory allocation to fix issue.


Resolver should use only the first matching extension mapper

Currently a tag and/or URI in a schema gets mapped through the resolver of all extensions chained together, end to end before the resulting string (which should represent an on-file schema) gets opened.
It might be better to have this work more like a regex, where the resolvers are tried in a particular order, and once a particular resolver actually resolves the string (i.e changes it), it stops, and doesn't pass through the remaining ones.
Or it's possible that the resolver could return a True or False if the resolver produces a match?
The idea would be to try to prevent one installed extension from hosing other installed extensions. Currently there's not a robust way to prevent this.  Not sure if this could prevent issues like https://github.com/astropy/specutils/issues/465, but it is possible.  Ordering would probably matter.  More thought is needed.
ht: @eslavich

Closing this, since the new plugin for schemas works on the basis of matching exact URIs and thus avoids the problem.


Bug:Album metadata returns 'null' in ShoutCast with react-native-track-playere-dev

Describe the bug
While running the react-native-track-player, dev (Oct 26,2020) version using our Shoutcast stream,  I am observing the album metadata return 'null; value.  At our radio station we utilize special control tokens like "Promo:", "Sponsor:", "Banner:", "Logo:" and "Advert:", note the colon as part of our control token wich is allowed in the Shoutcast and tags.  So when we have 'null' in our album tag when we are streaming that metadata, we will lose control of our radio app not sync-ing with our programming.  The title and artist metadata are working fine.  I have incorporated the metadata redundantly in two ways:  I set up the mp3 ID3 tags for album, artist, and title as well as setting the mp3 file name like "album - artist - title.mp3"    I've included a zipped folder with screenshots showing this file name (Frosty by Major Tom), and another screenshot showing the mp3 ID3 tag data, and finally our radio station screenshot showing the correct metadata for album, artist, and title.  So iit appears to be an issue with the track-playerer not capturing the album metadata in our Android platform.  I have not tested iOS, nor do I have the tools to test iOS at this time.
To Reproduce
Steps to reproduce the behavior:

use the "http://whsh4u-panel.com:14083/stream" as the streaming url.
set your browser to this address:  https://rockitstudios.com/trop-rockit/
Scroll down with the browser until you see the Song Request section.
a. fill in "Major Tom" as the Song artist.
b. fill in "Frosty" as the Song title.
c. Fill in the rest as you see fit, must all be filled correctly before huttung submit button.
Wait about five minutes (timer is set for 5 min +/- completion of previous track.

Environment (please complete the following information):
Run react-native info in your project and share the content.
$ react-native info
info Fetching system and libraries information...
(node:2488) Warning: Accessing non-existent property 'padLevels' of module exports inside circular dependency
(Use node --trace-warnings ... to show where the warning was created)
System:
OS: Windows 10 10.0.19041
CPU: (4) x64 Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
Memory: 6.92 GB / 11.86 GB
Binaries:
Node: 14.8.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.5 - ~\AppData\Roaming\npm\yarn.CMD
npm: 6.14.7 - C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK:
API Levels: 23, 29, 30
Build Tools: 28.0.3, 29.0.2, 30.0.1, 30.0.2
System Images: android-30 | Google APIs Intel x86 Atom
Android NDK: Not Found
Windows SDK:
AllowDevelopmentWithoutDevLicense: Enabled
AllowAllTrustedApps: Enabled
Versions: 10.0.19041.0
IDEs:
Android Studio: Version  <IP_ADDRESS> AI-193.69<IP_ADDRESS>26763
Visual St
HR Services Album Null.zip
HR Services Album Null.zip
udio: Not Found
Languages:
Java: 1.8.0_261 - /c/Program Files/Java/jdk1.8.0_261/bin/javac
Python: 3.8.6 - /c/Users/Bryon/AppData/Local/Microsoft/WindowsApps/python
npmPackages:
@react-native-community/cli: Not Found
react: 16.13.1 => 16.13.1
react-native: 0.63.2 => 0.63.2
npmGlobalPackages:
react-native: Not Found
-8PJBOJB MINGW64 ~/RockitPlayerReact/Example
$
What react-native-track-player version are you using?
react-native-kit/react-native-track-playere-dev (Oct 26, 2020 install from the Github dev)
Are you testing on a real device or in the simulator? Which OS version are you running?
Android Studio Emulator only.
Code
Please, share the code that is causing the issue
Not much to the code to test this:
useTrackPlayerEvents(["playback-metadata-received"], async event => {
console.log("Metadata album/artist/title: ", album, "/", artist, "/", title);
---
What I get in return: "Metadata album/artist/title: ;null'/Marjor Tom/Frosty"
Three sscreenshots in zipped folder:
1. Filename_and_Tags1.png
2. Filename_and_Tags2.png
3. HR Services Broadcasted Metadata.png
HR Services Album Null.zip

Technically not a bug, it was never intended to work like this.
title and artist are from the StreamTitle tag, url is from the StreamUrl. No other tag, afaik, is officially documented in the Icy protocol, so they are completely ignored. All other parameters are always null.
For more implementation details, see the original PR that brought this feature: https://github.com/react-native-kit/react-native-track-player/pull/552
Let me know if this helps or not.

Thank you for your feedback.  I'd like to rebut on your classification.  if you don't mind.   The Abstract statement for this package defines as a "Fully featured track player"   and the description  to this states the reason for "yet another music player" is to provide a more complete and full features...    With this, I ague this is a bug against the vision of the project?   Also,  the position and duration algorithm seems to have the same shortcoming under the Shoutcast streaming.   If you don't mind, sharing with me where I can go into the package and fix this?   Some tech questions.  is your split function filtering out the ":" colon character? As the streaming title (mp3 ffilename) does include the album and the extra " - ".     We can switch to private channel to discuss the details on this and duration so my progress bar works correctly in Shoutcast.   Thanks again for your reply and look forwarad to further discussions.

Also, the StreamTitle includeed the album name as part of the mp3 filename as "album - artist - title.mp3"  This 'album - "  may have been knocked off bt the track perhaps  due to the ":" colon or other algorithms extracting the artist and title.   Can you tell me where that code segment is?  I'd like to go into either the lib (not seeing the split function on ' - ' there), and still hunting for the code procedure in the android/src area of react-native-track=player.   Thanks

We've discussed before about removing the split and keeping the whole StreamTitle under title, we'll definitely do that at some point, the module can't be opiniated like that.
Because radios can format their titles in any way they want, there is no "standard" way to parse it down into artist, title and album. I originally splitted by the " - " because that is how the majority of radios format the title.
If your radio includes the album in the stream title, it's your job to split it down, the module should only serve as a interface between native, standard APIs and react-native.

The code is in the dev branch:
https://github.com/react-native-kit/react-native-track-player/blob/7ce3d08c9915a2d129a65c5f9427f16b264b7691/android/src/main/java/com/guichaguri/trackplayer/service/player/ExoPlayback.java#L404-L412
And in the v2 branch:
https://github.com/react-native-kit/react-native-track-player/blob/2f7ddf0cd68b4682cfbf506c0df6cf8ca1582b40/android/src/main/java/com/guichaguri/trackplayer/service/player/SourceMetadata.java#L89-L97

Thanks very much -- the exoplayer was the only one I didn't check.   May I propose not to delete the split,  instead, add a new tag call it streamTitle and just export the full streamTitle to that. so when we get the track tags, we can just access it through the same interface we obtain artist and title.  Just my thought.  Also, dpn't reject any characters from the streamTitle,  if the radiostation can stream the given character in streamTitle, if your doing any filtering with [A-Za-z etc]+ in any regEx.   Hopefully this will help you and your team.   I'd be glad to help.  Here in the US radio broadcasting industry there is actually a standard in giving streaming titles from the mp3 file name as I described above as "album - artist - title.mp3"  which gets broadcasted as stream title without the ".mp3" extension.  But, if we have the flexibility with receiving streamTitle, we can add additional things like duration etc.   At our broadcasting company, we're not newbies  -- we have some well known station manger(s) and leaders of the industry  that have recently joined us..  Thanks again for following up and offering the links and documentation for me to make these chancges.  I will have to do the same for iOS and windows too.  Hopefully your links include those  code files and locations to.

Forgot to mention.. when we create the file name that becomes the streamTitle, that is typically fallback mechanism in the case the mp3 metadata isn't beomg [rpcessed.   I believe there is a Github streaming MP3 metadata  parser for tags and duration as well as other auxillary tags broadcasted voluntarily such as genre and other items...

Thanks for the pointer and the links.  I found the code and reviewed it.  It is simple.  Apart from the fact the album is null,   I see that our radiostation server providers are 'skipping' some information which I will track down.  Thanks again -- you've been very helpful.    I do hope you consider my proposal to add 'streamingTitle'  object property for all those on the streaming world can use the same native interface as we see fit.


Update introduction.md

🚀 Deployed on https://66d0ce6ac5941b7f825d48a8--cozy-fox-0defec.netlify.app


Multiple Environments explanation

[ ] Minor content fixes (broken links, typos, etc.)
[X] New or updated content
[ ] Translated content
[ ] Changes to the docs site code
[ ] Something else!

Multiple Environments are not yet supported by Astro, but there is an easy work around. On Discord there are multiple support threads but nothing on this topic can be found yet in the docs.

Thanks for submitting this @MedLeon ! I'm marking this for the Technical Steering Committee to confirm as something to document, because sometimes things are undocumented for a reason!
Even if workarounds are successful, when they are not intended as a core Astro feature, they may not supported, or future development issues may not prioritize them.. So, we want to make sure we are setting our readers up for both short-term and long-term success.  😄
Just wanted to make sure I acknowledged this contribution, and let you know what's happening!

@sarah11918 Sounds good! 👍🏼

Hi @sarah11918,
when do you expect the Technical Steering Committee to review the PR?

Hi @MedLeon ! I'm sorry, I know there have been some holidays in the last couple of weeks, but I'm going to push for a resolution on this next week!  Thanks for your patience.

No worries and no rush!
I was just curious 😀. Thanks for the push!

Hi @MedLeon — thanks so much for this! This input was really helpful and triggered some interesting discussion. We’ve checked with the core team how we might want to best tackle this and we’re going to close this for now and hopefully we’ll have a better technical solution instead soon! 🙌


cmd/compile: nil pointer dereference in walk

Using ffa2bd2. The offending commit is probably something recent (last 2 weeks).
I'm seeing this compiler failure building a (proprietary) test:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x5b43b2]

goroutine 1 [running]:
panic(0xa2e120, 0xc42000e0a0)
	src/runtime/panic.go:502 +0x1b2
cmd/compile/internal/gc.(*Mpint).Cmp(0x0, 0xc42007b1d0, 0xc424c325a0)
	src/cmd/compile/internal/gc/mpint.go:252 +0x22
cmd/compile/internal/gc.walkexpr(0xc424c32630, 0xc44340f498, 0xc424c32900)
	src/cmd/compile/internal/gc/walk.go:1521 +0xa23c
cmd/compile/internal/gc.walkexpr(0xc424c327e0, 0xc44340f498, 0x0)
	src/cmd/compile/internal/gc/walk.go:738 +0x1261
cmd/compile/internal/gc.walkstmt(0xc424c327e0, 0xc424c32a20)
	src/cmd/compile/internal/gc/walk.go:192 +0xe59
cmd/compile/internal/gc.walkstmtlist(0xc439669900, 0x11, 0x20)
	src/cmd/compile/internal/gc/walk.go:80 +0x4d
cmd/compile/internal/gc.walk(0xc424c439e0)
	src/cmd/compile/internal/gc/walk.go:65 +0x1e4
cmd/compile/internal/gc.compile(0xc424c439e0)
	src/cmd/compile/internal/gc/pgen.go:391 +0x1d4
cmd/compile/internal/gc.funccompile(0xc424c439e0)
	src/cmd/compile/internal/gc/dcl.go:1258 +0x186
cmd/compile/internal/gc.Main()
	src/cmd/compile/internal/gc/main.go:484 +0x2065
cmd/compile/internal/amd64.Main()
	src/cmd/compile/internal/amd64/galign.go:93 +0x2fa
main.main()
	src/cmd/compile/main.go:33 +0x2a3

\cc @randall77 @mdempsky @ianlancetaylor
I'm still trying to strip the offending code into a smaller reproduction. Any advice on how to isolate the problem is welcome.

Which test? (which source code reproduces this?)
/cc @josharian @davecheney

Probably this: https://github.com/golang/go/commit/e6f9f39ce52e880b54e4cb08bf0cde73cf6c7dc2
@martisch

I confirm that the offending commit is e6f9f39.

Thanks for confirming. @dsnet, would you please revert that commit.
On Thu, Sep 1, 2016 at 9:11 AM, Joe Tsai<EMAIL_ADDRESS>wrote:

I confirm that the offending commit is e6f9f39
https://github.com/golang/go/commit/e6f9f39ce52e880b54e4cb08bf0cde73cf6c7dc2
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/16940#issuecomment-243930244, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA1R9gUyJeOkqU3MTirlmtngONXQlks5qlgoegaJpZM4JyIc4
.

How urgent is this, @dsnet? Can we try rolling forward?

AFK but my guess from my recollection of that CL is that the error stems from something like make([]T, n) where n is a named int type.

Not urgent. It was 1 build failure out of many thousands.

I would prefer to continue the practice of reverting changes rather than
trying to muscle through.
On Thu, Sep 1, 2016 at 10:55 AM, Joe Tsai<EMAIL_ADDRESS>wrote:

Not urgent. It was 1 build failure out of many thousands.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/16940#issuecomment-243945980, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_48GV_J93Zl5J8PIKeVMVNWuXwkks5qliKCgaJpZM4JyIc4
.

Reproduction:
package src

func f(n T) []byte { return make([]byte, 0, T(0i)) }

type T complex64

Will send a fix tomorrow if @martisch doesn't beat me to it.
As for "muscling through", new code will frequently introduce bugs. Reverting on every single bug, during the open dev period, will add a lot of overhead. I am all for reverting when it's during the freeze, or it causes significant breakage that might impede other developers or cause unnoticed further build breakage, or the bug is subtle or unknown and might take a long time to track down, etc. This is a small bug with a minor impact and a minor fix. Let's just fix it.

It was 1 build failure out of many thousands.

Ouch.

I'm fine rolling forward here if the fix is known and everybody can work and build.golang.org isn't all red and impeding workflows.
This just broke on some internal Google code on a test run of tip Go, not affecting anybody, so yay... @dsnet's early testing of Go 1.8 is already bearing fruit.

Working on the fix and new test cases.

CC me on the fix and I'll test the change on the failing test case.

@dsnet based on Robert's comment in #16949, I suspect that the compiler is soon going to reject your test case.


Operator disappeard from the OCP Operatorhub catalog

Hi, the following PR https://github.com/operator-framework/community-operators/pull/1734
was successfully merged and available in the OperatorHub but it no longer shows up.  Can someone help me figure out why it no longer shows up?

There is currently an outage with one of the backends serving community operator catalogs. This can lead to the catalog appear empty.
See: https://status.quay.io

Hi @dlong-1, should be good.

Thanks, everything looks good.


Profile the compile times

Compile times are important for quick iteration. We should investigate the current performance and take actions to reduce the compile times.

Aaron on IRC got 2 seconds for the triangle example, about 30 seconds overall.

triaged: still relevant


Jwt renew

Hi,
I’m using pubsub client to connect Mqtt using jwt auth.
Problem : jwt renewal need the client to be disconnected and reconnected. Could the client be modified (I can help you too) to manage this ?

What changes would you be proposing? The client already supports disconnect and connect... so you can do it in your application. We're not going to add anything jwt specific to this library.

Hi ,
Jwt are going to be refreshed every hour or so , only way to refresh is disconnect and reconnect the client . We know it’s possible to renew without disconnecting the client but haven’t be able to to that just calling client.connect with new credential


[Feature] Add eye button in password section

Description

I want to create a show hide password, eye button
@swaraj-das  please assign me this task.
Screenshots
No response
Checklist

[X] I have checked the existing issues.
[X] I have read the Code Of Conduct
[X] The changes don't break the code
[X] Please attach the screenshots and video of the development work once it is done

@AnitSarkar123 level ??

i want to work on this project. please assign it to me

@Subhajit-2023-44 @Muskan753951 first come first serve basis


Style: align with RuboCop defaults for quotes

single quotes = no interpolation
double quotes = interpolation

for now, we are choosing to align with the RuboCop defaults on this matter. if the RuboCop open source community influences a change to the defaults in future, we may or may not change our minds in future.

For posterity, these changes were introduced by:

Removing 2 entries from .rubocop.yml where we were overriding default RuboCop quote behavior
Running bundle exec rubocop -a afterwards to automatically align athe code base's use of quotes with the change


Add The Isle of Cats

Submitting this PR means you have:

[x] searched the readme file and searched the open pull requests (no duplicates please)
[x] and will follow the desired format
[x] used image links that resolve correctly, are appropriately sized, and are served over HTTPS

Once your PR is created, it will trigger a build a GitHub Action (Awesome-Lint). This includes a format linting process, so if there are any issues with the build, please address them.
Do you have further questions? Check the contribution guidelines or open an issue.
When you're ready, check off the above acknowledgements and continue with your Pull Request... and thanks!

This one also needs the stats block corrected.

@edm00se, I've implemented the required modifications. Would you please review the PR and proceed with the merge? Thank you!


issue when importing in node v20

Thanks for stopping by to let us know something could be better!
PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.

Is this a client library issue or a product issue?
This is the client library for . We will only be able to assist with issues that pertain to the behaviors of this library. If the issue you're experiencing is due to the behavior of the product itself, please visit the  Support page to reach the most relevant engineers.

Did someone already solve this?

Search the issues already opened: https://github.com/googleapis/nodejs-logging-winston/issues
Search the issues on our "catch-all" repository: https://github.com/googleapis/google-cloud-node
Search or ask on StackOverflow (engineers monitor these tags): http://stackoverflow.com/questions/tagged/google-cloud-platform+node.js

Do you have a support contract?
Please create an issue in the support console to ensure a timely response.

If the support paths suggested above still do not result in a resolution, please provide the following details.
Environment details

OS: Ubuntu 22.04
Node.js version: v20.6.0
npm version: 9.8.1
@google-cloud/logging-winston version: 6.0.0

Steps to reproduce

module with the line:  import { LoggingWinston } from '@google-cloud/logging-winston'
start the module ->
/home/daniel/git/asocial-srv/node_modules/@google-cloud/logging-winston/build/src/index.js:16
exports.LOGGING_SAMPLED_KEY = exports.LOGGING_SPAN_KEY = exports.LOGGING_TRACE_KEY = exports.LoggingWinston = exports.getCurrentTraceFromAgent = exports.getDefaultMetadataForTracing = exports.express = void 0;
^

TypeError: Cannot set property getCurrentTraceFromAgent of # which has only a getter
at Object. (/home/daniel/git/asocial-srv/node_modules/@google-cloud/logging-winston/build/src/index.js:16:144)
at Module._compile (node:internal/modules/cjs/loader:1241:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1295:10)
at Module.load (node:internal/modules/cjs/loader:1091:32)
at Module._load (node:internal/modules/cjs/loader:938:12)
at Module.require (node:internal/modules/cjs/loader:1115:19)
at require (node:internal/modules/helpers:130:18)
at Object. (/home/daniel/git/asocial-srv/node_modules/@google-cloud/logging-winston/build/src/middleware/express.js:20:17)
at Module._compile (node:internal/modules/cjs/loader:1241:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1295:10)
Node.js v20.6.0
Making sure to follow these steps will guarantee the quickest resolution possible.
Thanks!

Hi @dsportes, can you please provide the code you're using to try to configure your logger?

Will close this issue for now as more details are needed from the customer for a repro. Please free free to reopen this issue if this is still happening for you.

We get the same error when switching from a CommonJS build to a ESM module build.
If that helps for reproduction