Added loop point support to sf::Music

After working a bit with SFML, I noticed that I couldn't set any custom loop points for sounds, and I need them for a game I'm working on. I spotted issue #177 sitting around, so I figured I would try implementing myself.
For sf::Music / sf::SoundStream, I added a feature to detect a loop point and cut off the streaming of the buffer, and a pair of virtual functions that can allow sf::SoundStream to let its derived class decide where to seek upon looping. It's accomplished entirely within those two classes without doing anything too funny with OpenAL, and I'm happy with what I managed to accomplish with it.
For sf::SoundBuffer / sf::Sound, I ran into some more constraints. OpenAL-Soft has a way to set loop points, but it's not a well-documented feature, and it is also a buffer trait, rather than a source trait. It has a few more restrictions on the allowable values compared to the Music version because of this. It uses an "enum" value called AL_LOOP_POINTS_SOFT defined in "alext.h", which was present in SFML but not included, and I figured it was fair game to use. If not, then I can take the SoundBuffer implementation out.
The inline documentation will explain any interface differences, but they're roughly the same, with getLoopStart(), getLoopEnd(), setLoopPointsFromTime(), and setLoopPointsFromSamples(). Three of those work with sf::Time, to keep everything consistent, the fourth is if you have an exact sample position you want to use.
I hope this isn't frowned upon, but for testing, I augmented the SFML Sound Example to include some additional playings of the resource sounds, and demonstrating some of the extra features of the Music implementations. At least it should be easy to build and test. If any modification or more proof-of-functionality is needed, please let me know!

Bump again. :stuck_out_tongue:

I think someone should try to implement this feature with the new sound file API, and see if it is simple enough, or if there is anything that we could add to SFML to make it easier.

I've went ahead and implemented a proof-of-concept showing this can be done using sf::SoundStream and sf::InputSoundFile here. I don't think this pull request is necessary any longer.

Very nice :+1:

Hmmm, now the only question that remains is if this should just be handled by SFML or the programmer.

I guess we could add this feature to sf::Music, since it seems to integrate quite well with the existing implementation.
We could go with 2 to 8 functions (begin/end separated or grouped, sf::Time argument only or overload with sample count). Personally I prefer 2 functions, to keep the addition small; I think we can achieve 1-sample precision with microseconds.
struct LoopPoints
{
    sf::Time begin;
    sf::Time end;
};

void setLoopPoints(LoopPoints);
LoopPoints getLoopPoints() const;

How does it mix with sf::Music::setLoop()? What's the default value for loop points -- it should be the whole duration for backward compatibility?

How does it mix with sf::Music::setLoop()?

If loop is enabled, it loops between begin and end, otherwise it doesn't loop at all.

What's the default value for loop points -- it should be the whole duration for backward compatibility?

sf::Time::Zero would mean "disabled loop point", as with other functions that take an optional sf::Time.

I'm not sure if "disabled loop point" is intuitive, since sf::Time::Zero is a valid time. Shouldn't music.getLoopPoints() return LoopPoints(sf::Time::Zero, music.getDuration()) as long as setLoopPoints() has not been called?

This is a valid point, but I see two possible drawbacks to this approach:

you need to have a loaded music to get its duration, which is far less convenient than using a special constant
we really need to check whether time is precise enough for 1-sample resolution :grin:, otherwise music.getDuration() might ignore a few samples at the end

I'm not sure if the special meaning of "disabled loop point" is intuitive, since sf::Time::Zero is a valid time, referring to the begin of the music.

It makes sense to me.  I for one liked the idea of end == sf::Time::Zero indicating the end of the track; we're talking about a loop, which implies modular arithmetic:  zero is both the beginning and the end.  Then, if either begin or end is zero, it's effectively disabled because the music already loops at the corresponding point by default.  Unless I'm misunderstanding what is meant by "disabled"....

whether time is precise enough for 1-sample resolution

Probably, unless you're using a sample rate >1MHz.  I don't know about the average audio card these days, but mine (on-board) supports a maximum of 192kHz, where each sample is a little over 5 microseconds long.

Sorry I disappeared for so long there. I've been busy coding for classwork and my internship, which saps my willingness to code on my own time for stuff like this, but the notifications got my attention.
As for the semantics of this version, a LoopPoints struct containing a pair of sf::Time objects sounds good. The main reason I had a sample count version of my original implementation was so that a programmer who knew exactly how to loop the given track could specify it without having to do a conversion that would just get reversed internally. I don't know quite how important it is though, since as criptych said, reasonable sample rates all have granularity larger than a microsecond (which I think is the granularity of sf::Time). The merit of the function taking sample counts is hard to say.
I agree with Bromeon on the defaults. Personally I think that there's little practical reason to set the loop points while Music is unloaded, since I believe the placement of loop points will almost always depend on the audio content of the Music being played. In my opinion, unloaded sf::Music should always return LoopPoints(sf::Time::Zero, sf::Time::Zero), even if you try to set it, and when Music is loaded, it should auto-set the range to LoopPoints(sf::Time::Zero, music.getDuration()), so that setLoop(true) will cover the whole sound. In the rare case where you'd have the range decided in advance, there's little overhead in keeping a struct around until sf::Music is ready to accept it.
I also think that there isn't too much you can do with "special" values. Internally, all you need is a pair of times / sample counts and the m_loop boolean in order to know everything about how the sound should loop. If looping is disabled, that's easy to check by itself, and there's no harm in getLoopPoints() returning the range that the Music WOULD loop if it was enabled, especially if we go with (Zero, Duration) by default. When I was programming the old implementation, the only time I found use for special values was when processing the parameters passed to setLoopPoints(). "Begin" can correctly be any value from Zero to Duration. "End" has the same domain, but since Zero is equivalent to Duration in this context, I adjust it to avoid an unnecessary implied seek to the beginning of the file. The second special case is if Begin == End after clamping, in which case the range is invalid. Whether that should cause a "no-op" or a "reset to default range" is up for discussion. Treating Zero as a special value internally doesn't really accomplish anything.
Those are all my thoughts on the matter. Sorry for it being so long.

First, some semantics have to be made clear, as they have fundamental implications on the API.

Are loop points orthogonal to the other properties?

Yes: loop points can be set before loading, loadFromFile() doesn't reset them. They can be beyond the duration, setLoopPoints() doesn't contain error checks. We need to decide how play() handles incorrect loop points.
No: they can only be set after loading, but errors can be caught directly.

Does sf::Time::Zero actually refer to the beginning?

Yes, but it's also the end in a loop. However, following this modular argument, the music should wrap around. If loopBegin > loopEnd, the music would play a loop from loopEnd to the end and then start again from the beginning until loopBegin. If loopBegin = loopEnd, the whole music would be played, but not necessarily starting at time zero.
No, it's just an arbitrary magic constant. Case differentiations will make both implementation and usage more complex.

Do we provide only access via time or also samples?

Both. Possible would be two structures, one with sf::Time begin/end, the other with std::size_t. How are they named? LoopPoints and LoopSamplePoints? LoopTimePoints and LoopSamplePoints? LoopTimes and LoopSamples? ...?
Only time. We should not do this carelessly if we know that we will eventually introduce samples, because not considering the coexistence of samples and times now will leave us with fewer options later, as we can't break existing APIs.

That's a pretty good way to summarize the relevant discussion topics. As far as "2-Yes" goes, it should be clear that I support it, but I just want to put in an argument for its viability.
I implemented wrap-around in the original version of this pull request without any difficulties. It takes no additional logic beyond the expected "If at Duration, seek to 0. If at End, seek to Begin.", and it won't cause any trouble for users because its not an easily stumbled-upon feature. Although its uses are limited, anyone who intentionally puts Begin after End likely desires this behavior in the first place, and would be unhappy with their "inverted loop" being arbitrarily rejected.

Are loop points orthogonal to other sf::Music attributes?

sf::Sprite's texture area falls into the 'yes' case. Similarly, we could argue that loop points should also be orthogonal. However, I'm not 100% convince that's a good choice -- I haven't experimented that much with loops though.

Does sf::Time::Zero actually refer to the beginning?

If the underlying question is whether or not we should support warp-around loops or not, in a human-friendly way, I'd say Zero is the beginning of the music. So the loop [0, 0] would play the whole music over and over. So the next question is: how do we disable looping? I guess the simplest way would be the introduction of a boolean flag (enable/disable looping).
My point is that having condition such as if start > end then play everything is not flexible and in many case counterintuitive. Having a on/off switch is much simpler for the user and implementer.

Do we provide only access via time or also samples?

There's also an analogy with the graphics module here: at some point we had to add Text::findCharacterPos to allow the user to convert index to position. Would Music::findSample(sf::Time) make sense?

So the next question is: how do we disable looping? I guess the simplest way would be the introduction of a boolean flag (enable/disable looping).

There is already setLoop(bool loop), problem solved :smiley:

My point is that having condition such as if start > end then play everything is not flexible and in many case counterintuitive.

begin > end would rather be used to have a loop that wraps around, as I described in point 2.

There's also an analogy with the graphics module here: at some point we had to add Text::findCharacterPos to allow the user to convert index to position. Would Music::findSample(sf::Time) make sense?

I don't think it's comparable. Samples are uniformly spaced and can be converted to time (and vice versa) very easily on user side. The only problem is the potential precision of sf::Time, but such a function wouldn't solve it either.

There is already setLoop(bool loop), problem solved

Amazing how I missed it! :sweat_smile:

begin > end would rather be used to have a loop that wraps around, as I described in point 2.

That was just a (bad) example of the logic I wanted to avoid but since the problem is already solved... :-)

Whew... Sorry I disappeared for so long. But I finally got around to re-implementing loop-points in the most recent version of SFML.
Regarding Bromeon's 3 semantics, my current code follows "No", "Yes", and "Only Time". I went with a single getLoopPoints() / setLoopPoints() pair, but instead of adding a LoopPoints pair to Music, I added a more generic TimeSpan to Time.hpp (but I can undo that if it's unwanted).
The way I have SoundStream handle loop events from its derived classes is a bit more straightforward than last time, and I no longer need one of the protected virtual functions I added. The implementation should be more robust as well, and I even found and fixed a few minor bugs in Music's current version (one involving a miscalculation of the playing offset in certain cases, and another preventing the offset from being adjusted before the Music starts playing).
Let me know if there's more that needs discussion to be had. I'm still open to feedback.

By the way, I'm not hijacking the built-in sound test anymore. I just have a basic testing program, along with a WAV file that works well with integer time values:
loopPointTest.cpp
count.wav
You launch it using loopPointTest file [seek_start] [loop_begin loop_end], and it will visualize the file duration, the loop points, and the play position, until you press Ctrl+C.
A simple example is loopPointTest count.wav 0 1 5, which will play the sound from the beginning, then loop between 1s and 5s (like a lot of video game background tracks that have a one-time "opener").

Not sure about the TimeSpan. This feels misleading, since sf::Time is essentially a time span as well. I'd rather use offset and duration internally.

It's at least not related to this PR and might be discussed separately (forum?).

Now that I think about it, you're probably right that a generic sort of time span is probably best represented in the "position, length" manner, rather than "beginPos, endPos".
Loop points, however, are still probably best represented as a pair of positions. This is mainly so that you can set loopEnd to an absolute position (such as 0 or getDuration()) without having to offset it from loopBegin. Plus it's not even necessarily a span, because while the times sort-of represent a connected range, they mainly just define a seeking rule of sorts: "if at loopEnd, go to loopBegin".
So even if the semantics of a generic TimeSpan are a topic for another day, it might be best if I confine my implementation to a smaller-scoped Music::LoopPoints sort of thing.
Any objections?

I agree. Imagine having 3 loop points. That wouldn't be possible really with time spans (not saying that we need this ;)).

Man... If you were able to add several pairs of loop points. Along with the ability to start the playing offset at any point, that could result in some crazy complicated play-paths. But it quickly reaches the "why aren't you just editing the sound file to play like that". You only really need 1 pair of loop points to fulfill the desired purpose: Clamping the sound playback to a desired area, regardless of where the playing offset is.
In fact, the whole reason I implemented this is for simple background music. All sorts of video games and other interactive media have music tracks that start on an opening section and then cleanly move into an infinite loop until it's time to unload the music. But PC games are notorious for not supporting that. Many have music that just plays once, or that uncomfortably loops to the beginning regardless of whether the track was designed for it. I'd want that issue solved.
Back to the task at hand though... I'll move the struct tomorrow if I hear no objections. But in the meantime, has anyone else run my tester and confirmed that it works as desired? The changes are all within the bounds of the library, and the tester just uses carriage return to make an ASCII progress bar of sorts. So it should run on any system that has a terminal and knows what a SIGINT is, but I would still like confirmation that it's working for other people.

I'm not sure if your bug fixes should go in a separate PR, just so that they get the attention they deserve (sound stream implementation is easily broken). Let's make sure that @binary1248 reviews these changes.

The test program works for me, except I had to change the "sfml" in the include paths to upper-case :)
@LaurentGomila If no one raises concerns regarding this PR in general (I do not, except the TimeSpan thing), then this can be added anyway. Not sure if a separate bug PR is required then.

I just wanted to emphasize the fixes in SoundStream.cpp, they are easily ignored since this PR is about loop points in sf::Music.

The LoopPoints container has been moved.
Now since we're talking about the bugfixes, I should probably explain them a bit more. I happened across both of them after the loop point implementation was essentially completed.
I only found the first one because I was using a file and loop points that were exact numbers of seconds long, which matches the SoundStream buffer size. Currently, if onGetData() reads to the exact end of the file, it will return true due to the full read, even though there's no mode data available. However, this means that the buffer isn't properly marked as an "end". When it's time to read the next buffer after that, it will read 0 bytes and return false. This will trigger a seek to 0 (in the old version), or a call to onLoop() (in the new version), and flag the buffer as an "end". But since the read was 0, the buffer then gets refilled with a second's worth of post-seek data. The two buffers get played normally, but it's now the second on that's flagged as the end, even though it contains beginning data. And when it gets unloaded, the sample counter gets reset one second too late. This creates a "lag" that persists over the playback, forever reporting an incorrect play position.
My fix involved m_tellPos, which I had already added for checking where we are in the file and if we're coming up to a loop point. Now, even if the a read fills the whole buffer, if the position afterwards lands on the loop end or the file end, then onGetData() returns false.
A slightly different case involved a similar error when the play position starts on a loop endpoint or the end-of-file. It causes the same "delayed zero-read" effect, though the offset corrects itself after a loop iteration. Since no sound is loaded yet, there's no rightful owner of the "end" status, so my solution is the immediateLoop parameter in fillAndPushBuffer() it's only set to true during the fillQueue() call as the thread starts up. It essentially gives fillAndPushBuffer() permission to immediately adjust m_samplesProcessed to the correct post-loop value, instead of deferring things until the refilled buffer gets unloaded a second too late.
The other "bug" is more of a shortcoming. When I was testing, I tried to set the "play start" by calling setPlayingOffset() between openFromFile() and play(). I noticed it didn't work, and the music always began from the start. I noticed the onSeek(Time::Zero); call in play() and I didn't see any proper reason for it. The paused and playing cases were already covered, and if the music was stopped, then either the music was newly loaded (already 0), newly-stopped (already 0), or at an offset that was explicitly adjusted after loading or stopping (why would you overrule that?). So I removed the onSeek(Time::Zero); line, and moved the m_samplesProcessed = 0; line to initialize(), to make sure that case is still covered.
While I'm at it, I sort-of question the logic behind the "playing" case. The one commented with "If the sound is playing, stop it and continue as if it was stopped". What's the reason for that? My common sense tells me that calling play() while the music is already playing should do nothing, not stop the sound and restart it as 0. That's what stop() is for, so one can just call that before play() to get the effect sensibly.
So that's my summary of the bugs. It's not up to me whether they're made into a new PR, but I will note that the first one in particular has a solution that's tied pretty heavily into my Loop Points implementation.

We definitely want to be able to set both loop points in one function call, since that minimizes any stopping we have to do and avoids a race condition if the loop triggers between setting the two, but that can be done simply with a 2-parameter setter and a pair of getters.
The struct isn't really necessary, and I'd actually prefer omitting it personally. I was just going with what Laurent and Bromeon agreed to back on March 29, to keep the function count low. I can change it back, but I don't want to keep going back and forth too much. We need to reach a final decision one way or the other soon.

Personally I'd rather want to reduce the amount of classes than member functions. So :+1: for dropping the class. @LaurentGomila @Bromeon? (And the rest of course, too)

I would leave the class in. Loop begin and end logically belong together, as they denote an interval. Therefore, the code becomes more object-oriented. In particular, separate setters for loop begin and end don't allow error checks like begin < end (in case of no wrap-around). Keep also in mind that C++11 makes it easy to call a combined function with setLoopPoints({start, end}).
Furthermore, it's well possible that such an interval might be used somewhere else in the future, then we could just move this class to the sf namespace and add a typedef within sf::Music. We might even name the class Interval in the first place, or possibly CyclicInterval or similar to underline the wrap-around semantics.
I would use the term "begin" instead of "start", as it's consistent with the STL.
The current implementations violates the code conventions in a few places (whitespaces, implicit conversion of int to bool, no use of () in logical operators, ...).

@Cobaltergeist Do you still have the time to work on this, or should somebody else take over?

@Cobaltergeist Do you still have the time to work on this, or should somebody else take over?

Sorta. I can't really say right now whether I want to remain as the person working on this, but for now I pushed a quick update...
I went and fixed the stray comma (I think it appeared there when I tried to add another value to the enum, but I undid that, forgot about the comma, and GCC didn't complain), the bool return on a logical error, some implicit bool conversions, and a bit of redundancy, but I'm not sure what the remaining problems are, if any.
I'm also not sure whether I have the time to separate the SoundStream fixes into a new PR, since it'll require some manual work, and a lot of the code is a prerequisite to the Loop Points functioning properly.
One more thing, on the subject of wrap-around loops. I know I've defended them before, but that was only based on how easy they are to implement, given the logic of detecting a loop endpoint. Their addition isn't a huge gain, yet restricting them felt pointless to me. But if their presence requires a global change in the semantics and understanding of sound duration, maybe they are more trouble than they're worth. Adding another case to the if statement at line 179 of Music.cpp should take them out of consideration if that's desired.

Thanks for the update!

Sorta. I can't really say right now whether I want to remain as the person working on this, but for now I pushed a quick update...

Don't hesitate to let other people work on it if you're interested that this PR isn't abandoned but don't know your availability. Your commits will remain as a base, so the contribution information isn't lost ;)

I'm also not sure whether I have the time to separate the SoundStream fixes into a new PR, since it'll require some manual work, and a lot of the code is a prerequisite to the Loop Points functioning properly.

Laurent's idea was:

I'm not sure if your bug fixes should go in a separate PR, just so that they get the attention they deserve (sound stream implementation is easily broken). Let's make sure that binary1248 reviews these changes.

And since the beginning of this PR, some issues in sf::SoundStream have already been fixed. So we should review what's still necessary. It would already help a lot if the currently 9 commits could be reduced to 2: one for the underlying fixes (that don't add any functionality), and one for the new loop point API.

One more thing, on the subject of wrap-around loops. [...] if their presence requires a global change in the semantics and understanding of sound duration, maybe they are more trouble than they're worth.

Isn't sf::Music::getDuration() independent of loop points? So I'm not sure what exactly you're referring to. I agree that it may be slightly more complex to imagine wrap-around, and we can also leave it away initially and add it in a later PR.

How do we move forward with this PR?

If we hear nothing more from @Cobaltergeist, I'd say somebody else adopts his work.

Now that #1118 and #1154 are merged, I'm resuming work on this. Expect a revision soon, with a couple changes that I've had a while to think about.
That said, the question of whether to include a dedicated LoopPoints struct is still divisive. I'd love to see a definitive answer emerge soon. Personally, I'm currently on the side of leaving the struct out. It would complicate the question of the Sample Offset overloads, which I'm thinking of re-including alongside the sf::Time ones, since I feel they might be more useful than previously considered.

Actually, if I make it templated, I can keep some sort of LoopPoints struct and still have the sample overload without an ugly inconsistency in the function signatures. It might even be worthwhile to revisit the old sf::TimeSpan idea, but make it templated in the same way as sf::Vector.
So basically we'd need some sort of sf::Span<T>, and then:
typedef sf::Span<sf::Time> TimeSpan; and
typedef sf::Span<Uint64> SampleSpan.
Then the loop point getter/setter overloads can take each of those specializations.
Alternatively I could just use std::pair, but using the first and second doesn't seem like the user-friendliest solution, unless I use a hacky way to alias the members using references.

Here's a revised version of the Loop Point Implementation.
After putting some thought into it, I've altered the design a bit, changing my stance on a few points. Here are those points, with justification.

The struct is kept. (This halves the number of needed getters functions, without adding too much complexity.)
Loop point pairs are now externally specified as [offset, length] instead of [begin, end]. sf::Music still uses [begin, end] internally. (Most cases of 'time ranges' use this convention, including the few scattered results I found in google searches about ways to specify loop points for other programs that recognize them.)
"Sample" versions are provided. (If a sound is designed to be looped, the designer would almost certainly specify this info in sample units rather than seconds. This saves two conversions.)
The loop point struct is templatized, with specialization typedefs for sf::Time and Uint64 units, and is generically named sf::Span with members offset and length. (In case we want to use sf::Span for other things outside of sf::Music, it would be as easy as moving the struct body and tweaking the typedefs.)
While technically the ability to play inverted loops isn't absent, such loops are now considered invalid by the setters. (It's hard to specify and validate what counts as a well-formed loop-point pair with this functionality exposed, plus I STILL can't think of an use case where inverted loops are the most sensible audio solution.)
Loop Point validation is now stricter: Setting fails if the begin offset is outside the file, or if the length is 0. The length is then clamped to sampleCount - offset (With [offset, length] semantics and with no inverted loops, this is a simple and straightforward means of validation. No "0 = End" debate to be had.)

If a there is a stong case against some of these changes, they should not be hard to revert or tweak.
Along with this, I've accounted for my recent Audio PRs, and slightly improved the robustness of the sample offset propagation in loop-end cases. Other conventions, including the onLoop() call, the clearing of the loop points on file load, and the lack of defaults on the new setters, were maintained.
And of course, with new signatures, we need a new test.cpp file.

As I already said earlier:

Personally I prefer 2 functions, to keep the addition small; I think we can achieve 1-sample precision with microseconds. If more functions are needed we can always add them later.

This would also be more consistent with setPlayingPosition (for example) taking a sf::Time only.

I just think that restricting the input type to Time is inviting some frustration to callers of the Loop Point code, wasting a few CPU cycles per call and a minute of programmer time per call site. As I said, in nearly any case where you have a song with pre-built loop points, they will be stored as samples.
It's like taking an angle in Radians from your physics system, and passing it to your renderer that also uses Radians internally, but the call to pass the value only takes Degrees. It's an easy conversion to do, and in most cases you won't lose any important amount of precision, but it still wastes a bit of time while writing and running the code.
Speaking of precision, with improved rounding that I can use, samples and times should match 1-to-1 as long as the time granularity is at least twice the sample granularity. Since we use microseconds for time units, this will hold for any audio with a sample rate under 500kHz (channel count has no effect). This is an order of magnitude higher than typical 44.1kHz or 48kHz audio we'd expect to be playing, but only ONE order of magnitude. In fact, some programs like Audacity have the option to export 384kHz, so we aren't too far off from the limit. I know that Bromeon was previously concerned about a different type-imposed limit in edge cases.

If std::size_t is a 32 bit type, then "only" 27 hours of music can be played at 44.1kHz.

I feel like if the duration overflow case was a concern, then the sample rate precision loss case would be one too.
If you still insist on keeping samples out of loop point and playing position accessors, I can make a change to the timeToSamples() and samplesToTime() functions. I can save a bit of precision by using microsecond Time accessors and an intermediate double instead of float. This still doesn't get around the mathematical limit I mentioned earlier.
Either way, I can switch to the internal SampleSpan pretty easily.

What's the status on this, besides requiring a rebase?

I have the precision improvements and internal SampleSpan staged locally, but I was mainly waiting on feedback for my desire to keep the sample setter.
But if we want to save that discussion for another PR, I can ditch the sample-typed functions and push a rebased/squashed commit as early as tonight.

I decided that I'd rather see this merged quickly than keep fighting for the sample getter/setter. So here's a version without them, along with the internal SampleSpan and improved Time/Sample conversion precision.

SFMLBuildMaster: Build this please.

@LaurentGomila, when you find the time, can you give this another review?

Loop point pairs are now externally specified as [offset, length] instead of [begin, end]. sf::Music still uses [begin, end] internally. (Most cases of 'time ranges' use this convention, including the few scattered results I found in google searches about ways to specify loop points for other programs that recognize them.)

I'm not sure if this is actually easier -- it's inconsistent to STL begin-end pairs, and I can imagine that many loop points are specified relative to the beginning or end of the music theme, and not relative to the duration.
Why is there still getSampleCount()? It should only be necessary together with sample overloads (which should be discussed at a later stage).

The format of the loop points is taste only.
Begin/end is similar to STL (iterators).
Start/duration is closer to SFML (position/size).
I prefer the former - especially with sound - but it's trivial to convert between the two types.
Specifying a sound chunk by duration is actually useful if you know how long the sound should be; you can just change the start point. But, as said above, it's simple enough to do end = begin + requiredDuration.

Whether begin/end or begin/duration is used, is largely personal taste and both will have similar argumentation. For music tracks it makes in my opinion more sense to specify the time in start & duration, as this is how I generally would be thinking of your music sections. Besides, we're not trying to copy the STL or anything, so the comparison doesn't really matter and might be confusing to some.
I'd say we stick with the current design, unless someone has better arguments than personal opinions or the STL.

@Cobaltergeist Any update on this?

Sorry for the wait. It's amazing what coding for work does to one's drive to code for personal projects.
Anyway, I've finally rebased and addressed the following concerns:

Removed getSampleCount()
Removed public SampleSpan typedef
Fixed abbreviated parameter and local names
Moved the divide-by-zero check
Added some parentheses

I kept NoLoop as-is because enums are a semi-standard way to use constants without introducing either globals or macros. BufferCount uses this same strategy. The only reason NoLoop is on its own (and not in the same block as BufferCount) is because it needs protected instead of private visibility so that classes derived from SoundStream can use it.

Thanks for the update! @LaurentGomila can you give this another look?

I'll do my best.

Any more news? I can rebase soon, but if there are any remaining changes I need to make, I'd prefer to address everything in one go.

Alright, that should do it. This has been the oldest opened PR for quite some time by now. Let's get this tested and merged so we can put it behind us.

SFMLBuildMaster: Build this please.

A huge thank your for all your work over the past 2 years! 😄
(Stay tuned for potential bugfixes 😉)

I can't believe it's finally been merged.  Feels like it has been forever.

Feel free to let me know when 3.0 changes open up. Between #1118 and this, I've had to work around an API that's doesn't propagate a lot of helpful information. A breaking-allowed change would let us clean up a lot of this stack.

I'm interested in hearing your ideas on a better API approach. If you feel like providing some more feedback, I'll gladly open a thread in the SFML Development forum section.

Well, the gist of it concerns the amount of information NOT passed in calls and returns during the whole read()/seek() workflow.
Decision choices throughout my Soundstream-related PRs like #1118's immediateLoop, #1154's retry logic, and this PR's onLoop() function were all focused on a higher-level function trying to discover or infer the state of underlying objects. Things like figuring out whether a short/zero read means EOF, Loop-Point, IO-Error, or just a quirk of the codec reader, when the read() calls only return Int64s and bools. Or having SoundStream figure out where Music wants to seek on a loop point to avoid desyncing of m_samplesProcessed, when seek() returns void. In my opinion, these cases would be better off just exposing more information in return values, but I can't break the APIs to change that yet.
It'd mostly involve changing function signatures, and possibly adding a "Read Result" enum or struct.


Improve ad_utility::.strip() and ad_utility::splitAny()

Use std::string_first/last_not_of to simplify
Template so we only need one version for string/char* chars to strip

@joka921 very good points, it makes no sense to stick with such low level primitives as the original code used. I really should study up on some of those STL algorithm tricks. I'll address your comments and agree on the potential for std::string_view though I think that's a question for another PR

@joka921 I've amended the commit with better documentation and also made splitAny() a template as well. Instead of reimplementing it completely with find_.*_of(), for now it just uses the same "convert to std::string_view" trick. Interestingly http://en.cppreference.com currently seems to miss the std::string_view(const std::string&) constructor.


[Feature] Allow players to apply spell effects

There should be an option to allow players to apply spell effects (via drag and drop) to tokens, even if they are lacking ownership of the characters.

The option is ownership. As a stated system goal, we don't want to be breaking the Foundry permission model. Auras work by using the GM permissions as opposed to the player permissions in a passive sense. What you are asking for is actively to break the permission model, and that is presently outside of the scope of the project design goals.
They question is why should the system implement this, as opposed to a module. And from the system design view this is very much module-space.


Generic-multifield(4.0.0) still not working properly in tablet viewport

Hello, I was closely following the resolve of https://github.com/merkle-open/aem-generic-multifield/issues/38, that you fixed in release 4.0.0. I migrated to this version and there were some improvements, but there is still an issue in smaller viewports ( VP < 1024).
The issues before:
If you had a large textarea and a multi-field component in the same dialog - the text area was missing and not interactable - this was fixed!
You could not click on the add(+) button of the multi-field - this is also fixed!
The issues now:
Once you click on the add(+) on the multi field, in my case I have a new dialog with a big text area, this text area is now not visible and interactable . Also the OOTB adobe Save and Cancel dialog in the bottom of the form get transferred to the top of the dialog( this is okey) in the form of X and / ( tick) ( this is also okey) the issues with these new buttons are.
First of all - if you click on any one of them - they close both the edit dialogs ( the main one in which the have the multi field and the dialog of the multi field itself). The 2nd issue is - the tick (/) Done checkmark saves the dialog even if there were fields with a mandatory check and were left empty, so the button can save invalid data to the multi field fields.

Hello @QmmParkett ,
Thank you for inputs.

A general note on the way the granite dialog works for viewports smaller than 1024 px. It is the OOTB behavior that all dialog views now correspond to URLs and page loads rather than same page modals. There is no fix to this issue and simply the stack that adobe has decided to go for here. It will not be the intention of the generic multifield to go above and beyond the inherited behavior of the parent granite implementation.
When you refer to "large textfield" which is no longer visible, are you referring to a RTE configuration? I would kindly ask you to share the dialog definition of the component which include the generic multifield definition as well as the dialog item definition. Also, please confirm that this is being tested on a AEM as a cloud service SDK with version non later than 2023.12.0

regards,
Michael

Hello @MichaelHeil,
Regarding the 1st point - just to make sure I understand you correctly, in smaller VP any button clicked will result in a saving of the dialog successfully, no matter if the validations are not met ?
Regarding the 2nd point I am using Adobe Experience Manager 2023.9.13420.20230907T185228Z-230800
and yes I am referring to a RTE configuration.
I am attaching the content.xml-s for both the parent component and the multifield component.
parentComponent.txt
child.txt
Regarding point 3 I followed the steps very closely.
The pom version is updated to 4.0.0

The old bundle was uninstalled

The new bundle is installed

and the old namics folder under /apps in CRX was deleted and a new folder merkle was created

regards,
Simeon

Hello @QmmParkett

No, of course validation is NOT being skipped. As stated, in that viewport, every dialog confirmation (saving the dialog successfully) will result in a page reload and the parent dialog of the item dialog is not reopened.
There seems to be a clear issue with your local setup. Maybe even just caching somewhere. Maybe it's best if you tested on a vanilla instance. The RTE has no issues working in that viewport. Also, we consider it best practice to have a dedicated tab for the RTE element (with not other properties within that same tab). I have added and example component. It includes 3x TODOs which need to be resolved before working. Then it will serve you as an example implementation.

rtetest.zip

Can not be reproduced -> closing issue

Hi, so I updated my local AEM instance to the March release and I imported your component to my codebase and tested with it. I am attaching a video this time, so that the issues at hand are better visible
https://github.com/merkle-open/aem-generic-multifield/assets/24268262/c4fab40a-5b65-4724-bed0-868f2b074d9c
https://github.com/merkle-open/aem-generic-multifield/assets/24268262/d664d9f3-30d7-4087-a47f-8c8825a934c6

Hello @QmmParkett,
Please showcase this issue on a vanilla instance within a WKND tenant.
regards,
Michael


Delete trusted_certificates directory on CLI init

Since it's no longer supported, we should delete the trusted_certificates subdirectory upon initialization of the notary CLI.

This was closed by #1042.


Page data not being pulled form Squarespace

A sub navigation page has been duplicated in Squarespace, exists in the /config page and is accessible globally via the public URL. When running the local server, the homepage works fine as expected but when going to the new URL, it's showing a blank page (just echoing out the header and footer).
Errors from the log are as follows:

I have also tried the sqs buster to clear all local cache and started from fresh. It seems the server isn't pulling the latest version of Squarespace's database, or, this is being cached elsewhere (where the sqs buster does not cover).

Looks like your blocks don't have values when returning from the squarespace api... do those blocks exist?

Those blocks exist, and they're showing/working on the Squarespace website. Is there anything else I can debug or share to help expose the exact issue I'm having?


Fix ScanType enum export

Exports the ScanType enum, which is needed to build the ScanOptions struct

can you fix CI?


Fix version package

Codecov Report

Merging #17 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #17   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines           21        21
  Branches         3         3
=========================================
  Hits            21        21

Impacted Files
Coverage Δ

flake8_no_implicit_concat/__init__.py
100.00% <100.00%> (ø)

flake8_no_implicit_concat/_version.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Skipped Modules

If there is no unit test, the module is basically skipped. It should still generate the report.xml file with 0% covarage.
Reason: We should know what is covered and what is not, and the average coverage of all modules are calculated wrong due to this skip.
Oztechan/CCC#185

Fixed in 0.4.3


Golf 0.1.2

This patch updates the Golf dependency to 0.1.2. This solves issue codedellemc/rexray#766 as it's related to akutz/golf#2 solved by akutz/golf#3.

Codecov Report

Merging #453 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #453   +/-   ##
=======================================
  Coverage   30.55%   30.55%
=======================================
  Files          29       29
  Lines        1777     1777
=======================================
  Hits          543      543
  Misses       1176     1176
  Partials       58       58

Continue to review full report at Codecov.

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


[Datagrid] Filter panel state does not update after changing filters with setAllFilters function

What package(s) are you using?

[x] Carbon for IBM Products (or Carbon for IBM Cloud & Cognitive)
[ ] Legacy/CDAI
[ ] Legacy/Security

Detailed description

Describe in detail the issue you're having.

After manually updating the filters via setAllFilters from https://react-table-v7.tanstack.com/docs/api/useFilters#instance-properties, the internal filter state is update within datagrid but the filter panel does not reflect those changes. Filters show previous state.

Is this issue related to a specific component?

Datagrid, filter panel

What did you expect to happen? What happened instead? What would you like to
see changed?

Exception is that the filter panel re-renders with the updated state after changing the filters with setAllFilters.
The <FilterSummary/> component reflects the changes correctly.

What browser are you working in?

Chrome

What version of the @carbon/ibm-products (or @carbon/ibm-cloud-cognitive)
package are you using?

1.49.0

What offering/product do you work on? Any pressing ship or release dates we
should be aware of?

CP4WAIOps
Steps to reproduce the issue

Render a table with the filter panel enabled
Apply filters
Attempt to pragmatically change the filters using setAllFilters
Notice that datagridstate.state.filters and <FilterSummary/> update accordingly while the filter panel keeps the previous selections. (i.e. previous checkboxes checked etc.)

Additional information

Screenshots or code
Notes

@AlexanderMelox to verify if this has been addressed or separate issue.

@AlexanderMelox I just tried the latest build that includes your fix for the initial filters and that works great!
This issue, however is not resolved.

Issue has been resolved in #3024


Need a Angular- UI Date picker where we can select Month and Year in the dropdown.

jQuery has https://jqueryui.com/resources/demos/datepicker/dropdown-month-year.html
Need something similar to this in Angular-UI-DatePicker

All jquery datepicker options can be passed to the datepicker. See the options section of the readme for the example.

Thanks.


Can't export

Hello, I did everything according to the instructions from YouTube, when I clicked OK in export skin an error popped up connecting to the site for insertion. I already rebooted the computer and did everything, still nothing changes, I suffered for a long time and abandoned this matter, now I remembered and decided to write to you

Send a screenshot of the error message.


Clarification on what is meant by NotBefore

Hi Karina,
Can you clarify the language for the following?

This release will NotBefore the following roots
This release will NotBefore the TLS EKUs to the following roots
This release will NotBefore the Code Signing EKUs to the following roots

i.e. What does it mean that the release will NotBefore the Code Signing EKU for those selected roots?
Question(s):

Does it mean that files that are signed by certificates that are chained to these roots will no longer be trusted for Code Signing?
Similar to the first question, files signed using the same hierarchy before the release date will still be trusted/valid?
Does this specifically impact only the files that are signed after the Feb2021 release date?
Can you share the exact date this went into effect?
Is there a way for organizations to opt-out or temporarily allow trust back for these roots CodeSigning EKU?

thanks

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

ID: 7947fabb-68cf-53f1-938b-9d058a5b5fe8
Version Independent ID: 41c00c20-ce22-1eb1-f830-d1d55c0ba466
Content: February 2021 Deployment Notice - Microsoft Trusted Root Program
Content Source: trusted-root-docs/2021/Feb2021.md
Service: security
GitHub Login: @kasirota
Microsoft Alias: kasirota

Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


Dimension declarations in 2D arrays reversed?

Hello.
Here are two programs that ought to be equivalent, one in C and the other in Cowgol:
https://github.com/ibara/cowgol-utilities/blob/main/2darray.c
https://github.com/ibara/cowgol-utilities/blob/main/2darray.cow
However, they are not equivalent. The output from the C version is what I would expect but that is not the output from the Cowgol version. To get the expected output from the Cowgol version, swap the dimension index declaration on line 6. That is, put XMAX before YMAX in the Cowgol version, even though all other accesses are in the form [y][x].
This is a bit unexpected, so bringing it up in case it is not intentional.
Discovered when writing a Game of Life implementation in Cowgol.

Oh, interesting. That's not actually supposed to work! I've just had else on another forum complain about only having single-dimension arrays, too...
I will look into this; it's clearly almost working so it would be good to regularise. Thanks for the test case.

Did not check the source but dare to ask anyway - is this already supported?

sizeof for 2d arrays also returns unexpected values (bytesof is ok):
var mshorts: uint16[5][2] := { {1, 2, 3, 4, 5}, {6, 7, 8, 9, 10} };

sizeof returns 2

Given the structure of the initialiser, I would expect sizeof in that case to return 2 --- there are two elements in the outermost array.
What's happening here is that clearly [] is associative in the wrong direction. Which is a shame as it's much easier to parse this way round.


Ability to Delete Account

Hey gang,
Love what you've done. I notice that you aren't able to reset your account/delete it. It's always nice to have control over your data but beyond that, I've found that once you go through a level, you can't redo it in a different programming language. Thought this would be a worthy consideration going forward. Keep up the good work.
Matt

Re-labelled title as the other problem has been fixed.


[Support] Unable to connect with wireguard

In raising this issue, I confirm the following:

[x] I have read and understood the contributors guide.
[x] The issue I am reporting can be replicated.
[x] The issue I am reporting can be is directly related to the pivpn installer script.
[x] The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

Issue
I'm unable to connect to my wireguard server from my Android (or any) client, there's no obvious error I just switch my client on in my phone (while disconnected from my WiFi) and I can't reach any of my devices connected to my local network (like my router web admin interface) or the internet.
Have you searched for similar issues and solutions?
Yes, this one was similar however changing the default port didn't fix it for me:
https://github.com/pivpn/pivpn/issues/1128
Console output of      curl -L install.pivpn.dev | bash
    |  We have detected an existing install.                             │
    │ /etc/pivpn/wireguard/setupVars.conf                                │
    │                                                                    │
    │ Please choose from the following options (Reconfigure can be used  │
    │ to add a second VPN type):                                         │
    │                                                                    │
    │        Update      Get the latest PiVPN scripts                    │
    │        Repair      Reinstall PiVPN using existing settings         │
    │        Reconfigure Reinstall PiVPN with new settings               |

Console output of      pivpn add or pivpn add nopass
These seem to be working fine:
  Enter a Name for the Client:

Console output of      pivpn debug
::::		PiVPN debug		 ::::
=============================================
::::		Latest commit		 ::::
commit 32bd1c628af9e1926f3f4471c0bf49c74deff7c7 (grafted, HEAD -> master, origin/test, origin/master, origin/HEAD)
Author: Orazio<EMAIL_ADDRESS>Date:   Fri Jul 24 18:52:57 2020 +0200

    Update LatestUpdate.md
=============================================
::::	    Installation settings    	 ::::
PLAT=Raspbian
OSCN=buster
USING_UFW=0
IPv4dev=eth0
IPv4addr=<IP_ADDRESS>/24
IPv4gw=<IP_ADDRESS>
install_user=pi
install_home=/home/pi
VPN=wireguard
pivpnPORT=51820
pivpnDNS1=<IP_ADDRESS>
pivpnDNS2=
pivpnHOST=REDACTED
INPUT_CHAIN_EDITED=0
FORWARD_CHAIN_EDITED=0
pivpnPROTO=udp
pivpnDEV=wg0
pivpnNET=<IP_ADDRESS>
subnetClass=24
UNATTUPG=1
INSTALLED_PACKAGES=(wireguard wireguard-tools wireguard-dkms qrencode)
=============================================
::::  Server configuration shown below   ::::
[Interface]
PrivateKey = server_priv
Address = <IP_ADDRESS>/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
### begin Javier ###
[Peer]
PublicKey = Javier_pub
PresharedKey = Javier_psk
AllowedIPs = <IP_ADDRESS>/32
### end Javier ###
=============================================
::::  Client configuration shown below   ::::
[Interface]
PrivateKey = Javier_priv
Address = <IP_ADDRESS>/24
DNS = <IP_ADDRESS>

[Peer]
PublicKey = server_pub
PresharedKey = Javier_psk
Endpoint = REDACTED:51820
AllowedIPs = <IP_ADDRESS>/0, ::0/0
=============================================
:::: 	Recursive list of files in	 ::::
::::[4m/etc/wireguard shown below	 ::::
/etc/wireguard:
configs  keys  wg0.conf

/etc/wireguard/configs:
clients.txt  Javier.conf

/etc/wireguard/keys:
Javier_priv  Javier_psk  Javier_pub  server_priv  server_pub
=============================================
::::		Self check		 ::::
:: [OK] IP forwarding is enabled
:: [OK] Iptables MASQUERADE rule set
:: [OK] WireGuard is running
:: [OK] WireGuard is enabled (it will automatically start on reboot)
:: [OK] WireGuard is listening on port 51820/udp
=============================================
:::: Having trouble connecting? Take a look at the FAQ:
:::: https://github.com/pivpn/pivpn/wiki/FAQ
=============================================
:::: WARNING: This script should have automatically masked sensitive       ::::
:::: information, however, still make sure that PrivateKey, PublicKey      ::::
:::: and PresharedKey are masked before reporting an issue. An example key ::::
:::: that you should NOT see in this log looks like this:                  ::::
:::: YIAoJVsdIeyvXfGGDDadHh6AxsMRymZTnnzZoAb9cxRe                          ::::
=============================================
::::		Debug complete		 ::::

Have you taken any steps towards solving your issue?
I'm using a custom domain pointing to my public IP as my endpoint, however I tried to switch to using the IP directly and still didn't work.
I followed the FAQ and try running a tcpdump and I couldn't see any packets so my clients aren't reaching the server for some reason:
# tcpdump -n -i eth0 udp port 51820
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -o wg0 -j ACCEPT

# iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A POSTROUTING -s <IP_ADDRESS>/24 -o eth0 -m comment --comment wireguard-nat-rule -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE

Looking at the logs in the Android app I can see it's stuck on Sending handshake initiation then it shows Handshake did not complete after 5 seconds; retrying and it repeats indefinetly.
I was able to set this up on a different Raspberry Pi a few weeks ago, I'm not sure what I did wrong here.

I was able to set this up on a different Raspberry Pi a few weeks ago, I'm not sure what I did wrong here.

This was my problem, I realised I didn't change the IP in my router port forward rules and it was still pointing to my old Rasberry Pi's IP.


Fix for cordova >= 3.6.3

CDVShared.m has been removed
https://github.com/apache/cordova-ios/blob/master/RELEASENOTES.md#363-20140908

@gbenvenuti, you've merged commit, but you don't add this changes to npm: https://www.npmjs.com/package/cordova-plugin-screen-orientation
I try to install from cordova plugin add cordova-plugin-screen-orientation.

hi @mrmasterix, yes you're correct I haven't published to npm is there are still problems with cordova 4 and ios9.  I've now published as 1.4.1 with this PR.

@gbenvenuti, I look forward to... :)


Improve social sharing in CKAN

Fixes #1 and #2
Proposed fixes:
Features:

[ ] includes tests covering changes
[X] includes updated documentation
[X] includes user-visible changes
[ ] includes API changes
[ ] includes bugfix for possible backport

Please [X] all the boxes above that apply

This is looking good @edmondatto. Could you create some more Github Issues on the remaining features? We'll commit to master for now until we have the basics nailed down.

@DavidLemayian Could you clarify on the remaining features? Also, the PR you merged fixes both issues ( #1 & #2) Shouldn't they both be closed?

Hi @edmondatto. Don't know how I missed your ping here. I've just made significant architecture changes to the code following how ckan and others structure their directory structures.
For clarification of remaining features: it's the unit tests, API changes, and bug fixes for back ports that you've listed in the PR description. We should create Github issues in relation to these.
As for closing the issues, they'd remain open until we have tests done so that we can reference the features we are testing for. (Note that the use of word "features" here is not the same as the sentence before this)


Update Utils dependencies

User Story - Business Need
We wish to keep dependencies up to date so that we do not need such massive overhauls of our system. This is a recurring task to update all dependencies we are able to update. Any conflicts shall get a dedicated ticket. This task should be a day of work at most because it only updates non-breaking changes.

[ ] Ticket is understood and QA has been contacted

User Story
As VA Notify,
I want to keep our service up to date
So that we are secure and as free of bugs as possible.
Additional Info and Resources

All dependencies are in requirements files of various sorts.

Engineering Checklist

[ ] Review "Tech Debt" tickets in backlog to identify packages already known to have breaking changes (don't try to upgrade these) For example, mistunes should not be upgraded on this ticket.
[ ] Review the setup.py file as it contains dependencies
[ ] Review open Dependabot PRs to determine where the changes will take place (open them and look at the files touched).

Do not modify these PRs

[ ] Passes all tests locally
[ ] Passes QA Suite regression testing against Dev with the API pulling in this latest commit
[ ] If there are any failures, create a ticket, and label it "tech debt"

[ ] Created ticket has the package name in the title

[ ] requires an API PR to pull in the latest commit from utils (ask if this is not understood)

Acceptance Criteria
Repo dependencies are updated and we have no broken functionality. Issues opened by Dependabot or listed in the Makefile are resolved. Tickets with the "tech debt" label created for any updates we could, or should, not do.
QA Considerations

[ ] Affected Dependabot PRs are closed after merge (may need to rebase them using dependabot command)
[ ] QA Regression tests pass after deploying this and API code.

Hey team! Please add your planning poker estimate with Zenhub @coreycarvalho @cris-oddball @EvanParish @k-macmillan @kalbfled @MackHalliday @mchlwellman

I am only updating dependencies that are tightly specified (i.e. not >=).  These include pyyaml and test dependencies.

There were no failures.  I added a bullet point to the "Engineering wins" section, but there's nothing to demo in a separate slide.


Fixed switched green and blue colors

The green and blue color render were switched and I just switched them back.

Sorry I made two PR but I have never done these before and github is overwhelming for me.


Change recommendation from Elixre to Regexr

Resolves issue #507
Please let me know if anything else is required

Looks great!


After focus textinput User have to tap twice to select any value in dropdown.

If you are starting a new project I recommend you to not use this library, because it's not being maintained. But if you already have this library on your project, I recommend to replace by this one: https://www.npmjs.com/package/react-native-material-dropdown-v2-fixed

If you are starting a new project I recommend you to not use this library, because it's not being maintained. But if you already have this library on your project, I recommend to replace by this one: https://www.npmjs.com/package/react-native-material-dropdown-v2-fixed

getting same issue in this library also

I got the solution for this bug..
just add keyboardShouldPersistTaps="always" in flatlist in this library..
path in library where we will change : src/components/dropdown/index.js


hasClass fails when it shouldn't

Consider the following:
TestHarness = function(props) {
        return (

                <CKStepsTextCell {...props} />

        );
    };

var wrapper = enzyme.mount(<TestHarness />);

console.log(wrapper.find(CKStepsTextCell).html());
// outputs
//

console.log(wrapper.find(CKStepsTextCell).hasClass('foo'));
// outputs
// false

Running enzyme 2.3.0 with react 15.1.0

Having dug through the lib a bit, it seems to be failing when trying to verify wrapper.find(CKStepsTextCell) is a DOM Component (literally in the function isDOMComponent in TestUtils).
  isDOMComponent: function (inst) {
    return !!(inst && inst.nodeType === 1 && inst.tagName);
  },

When inst gets here, it has no nodeType property and no tagName property.

hasClass is meant to verify that a DOM node has a class name, and you're using a composite component (<CKStepsTextCell/>) in your find query. I would say you should pass find a query that returns a DOM node, since composite components don't actually have a className property.
If we supported this we'd have to assume you meant to query the root DOM node of the composite component. Maybe we should just document that hasClass operates on DOM nodes only.
cc @ljharb what do you think?

Actually, internally, it appears the node is retrieved automatically. Note https://github.com/airbnb/enzyme/blob/master/src/ReactWrapper.js#L659, where the function single is called and https://github.com/airbnb/enzyme/blob/master/src/ReactWrapper.js#L846, the implementation of single, where this.node passes into the test.

The node property on a ReactWrapper instance will refer to the actual component itself, in your case CKStepsTextCell.
this.node = this.component.getWrappedComponent();

Feel free to console.log out wrapper.node in your test to verify.
If you were to mount a DOM element directly you'd be correct
const wrapper = mount(

)

I see, thanks for the clarification. Still, would be nice if I could check for class contents using the component.

The point of shallow rendering is that you shouldn't be checking for "what CKStepsTextCell renders", which includes its class name. The unit tests for CKStepsTextCell should be testing that.
If you want to integration-test the entire render tree of a component, use mount or render.

True; I didn't write this particular test initially so I won't attempt to defend it. The point still stands though that it's sort of silly it's not assumed hasClass would query the root node of a composite component. All components have to have a singular root node anyway -- it's not a leap, at least I don't think.

hasClass checks the className prop. In your example, that element that you found doesn't have that className. The result of its render method does, sure - but you didn't render that component. In other words, you're only making assertions about its props, not about what it renders.

Ah, that's the part I wasn't getting (result of the render method is irrelevant for the purposes of checking class value). Thank you for explaining -- in my mind this method was analogous to something like jquery's hasClass method from way back when.


Support resolving key type from union constrained tables

Purpose

$subject

Fixes https://github.com/ballerina-platform/ballerina-lang/issues/30859
Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[x] Added necessary tests

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

[ ] Increased Test Coverage
[ ] Added necessary documentation

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

We need to push this to beta branch @grainier @pcnfernando

Already moved it in https://github.com/ballerina-platform/ballerina-lang/pull/30863.
Cherry picked the commits. Hence, will not conflict while merging stage to master.

Ack. Just noticed this.


Create designated directory for diffs and file backups

As we integrate more version control capabilities into the project, such as applying diffs and creating backups of modified files, we should create a standardized directory structure to store these artifacts.
The proposed solution is to add a new top-level directory called something like "diffs_and_backups" that can house the following:

Diff files generated by the LLM or other tools, with a naming convention like {filename}diff{timestamp}.txt
Backup copies of files before they are modified, named like {filename}backup{timestamp}.txt
Any other version control related artifacts

Having a designated home for these files will keep the project organized, make it easy to locate diffs and backups, and avoid cluttering up the main directories.
Please provide any feedback on the proposed directory name and structure. Once finalized, we can create the new directory and establish it as the standard location for storing diffs, backups, and similar version control files.

We need to add a way to roll back a change if needed.


Color picker not appearing in edit color modal until an input has focus after refresh / initial load

When the editor is initially loaded, a color picker does not initially appear when you open the color edit modal dialogue.  Clicking a color input activates the colour picker, but this perhaps should appear by default.
Loom of issue:  https://www.loom.com/share/63055c5daee240f0bca2d368ca62e771
Suggest Polish label

Great feedback. Agreed. This should be a simple fix. Appreciate the Loom. Feel free to go for it if you want @prichter. Otherwise, happy to do it too.

@prichter  @alexdanilowicz  - Is this fixed? Unable to replicate.

I don't think so, but don't worry about it

Fixed in pull request #74


What command can I run to (re)generate a new portjs.js file

Hi Richard,
I believe that I handled the dependencies at Makefile#L17
CAMLGRAPH = /home/ubuntu/.opam/4.02.1/lib/ocamlgraph
JSOFOCAML = /home/ubuntu/.opam/4.02.1/lib/js_of_ocaml
STUBLIBS = /home/ubuntu/.opam/4.02.1/lib/stublibs/

but I'm not sure which command I have to run to (re)generate a new portjs.js file. I tried to run make and make all but I just got these compile files below:
~/portugol$ make all
for d in "src"; do \
		( cd $d ; make ) \
	done
make[1]: Entering directory `/home/ubuntu/portugol/src'
ocamldep -I /home/ubuntu/.opam/4.02.1/lib/ocamlgraph -I /home/ubuntu/.opam/4.02.1/lib/stublibs/ utils.ml location.ml driver.ml io.ml types.ml values.ml env.ml builtins.ml ast_utils.ml ast.ml preprocess.ml analyze_variables.ml typer.ml interp.ml cfg.ml  lexer.ml parser.ml parser.mli exe_main.ml repl_main.ml > .depend
ocamldep -I /home/ubuntu/.opam/4.02.1/lib/ocamlgraph -I /home/ubuntu/.opam/4.02.1/lib/stublibs/ utils.ml location.ml driver.ml io.ml types.ml values.ml env.ml builtins.ml ast_utils.ml ast.ml preprocess.ml analyze_variables.ml typer.ml interp.ml cfg.ml  lexer.ml parser.ml parser.mli exe_main.ml repl_main.ml > .depend
Native Compiling utils.ml
Compiling location.mli
Native Compiling location.ml
Native Compiling driver.ml
Native Compiling io.ml
Native Compiling types.ml
Compiling values.mli
Native Compiling values.ml
Native Compiling env.ml
Compiling builtins.mli
Native Compiling builtins.ml
Native Compiling ast.ml
Native Compiling ast_utils.ml
Byte Compiling utils.ml
Byte Compiling types.ml
Byte Compiling ast.ml
Compiling parser.mli
Native Compiling parser.ml
Native Compiling lexer.ml
Native Compiling preprocess.ml
Native Compiling analyze_variables.ml
Native Compiling typer.ml
Compiling interp.mli
Native Compiling interp.ml
Native Compiling cfg.ml
Native Compiling exe_main.ml
ocamlfind ocamlopt -package "lwt,lwt.unix" -I /home/ubuntu/.opam/4.02.1/lib/ocamlgraph -I /home/ubuntu/.opam/4.02.1/lib/stublibs/ -linkpkg \
	-o portuml graph.cmxa utils.cmx location.cmx driver.cmx io.cmx types.cmx values.cmx env.cmx builtins.cmx ast_utils.cmx ast.cmx lexer.cmx parser.cmx preprocess.cmx analyze_variables.cmx typer.cmx interp.cmx cfg.cmx exe_main.cmx
Byte Compiling location.ml
Byte Compiling driver.ml
Byte Compiling io.ml
Byte Compiling values.ml
Byte Compiling env.ml
Byte Compiling builtins.ml
Byte Compiling ast_utils.ml
Byte Compiling lexer.ml
Byte Compiling parser.ml
Byte Compiling preprocess.ml
Byte Compiling analyze_variables.ml
Byte Compiling typer.ml
Byte Compiling interp.ml
Byte Compiling cfg.ml
Byte Compiling exe_main.ml
Linking bytecode executable ...
ocamlfind ocamlc -package "lwt,lwt.unix" -I /home/ubuntu/.opam/4.02.1/lib/ocamlgraph -I /home/ubuntu/.opam/4.02.1/lib/stublibs/ -dllpath-pkg lwt,lwt.unix -dllpath /home/ubuntu/.opam/4.02.1/lib/stublibs/  \
	-linkpkg -o portuml.byt graph.cma utils.cmo location.cmo driver.cmo io.cmo types.cmo values.cmo env.cmo builtins.cmo ast_utils.cmo ast.cmo lexer.cmo parser.cmo preprocess.cmo analyze_variables.cmo typer.cmo interp.cmo cfg.cmo exe_main.cmo
make[1]: Leaving directory `/home/ubuntu/portugol/src'

Can you write a short tutorial/explanation of how to (re)generate a new portjs.js file? Thanks.

Hello Moreno,
I think you have. Sorry for the poorly documented project.
If you get the devel branch, there is now a INSTALL.org file which has some hints about compiling and dependencies.
For you current problem (I guess you are using master 40c89aa89cfae6a8055575bfc62431be903c6a3d ),
in the src directory, type make js.
The current devel branch now compiles js too as a default target, if you prefer. I tend to commit there first and whenever satisfied, merge it into master.
Can you tell me which branch you are using, in order to help you better.

Hi Richard, it works!
The commands sequence I ran:
~/portugol$ make all
~/portugol$ cd src/
~/portugol/src$ make js
~/portugol/src$ js_of_ocaml portjs.byt

Yes, I'm using your master branch forked to ESOedX/portugol updated from your latest changes ESOedX/portugol/commits/master.
I'm going to take a look at the devel branch but for now it works fine at master branch. :+1:
Thanks!


Update pagination component

Problem statement
FOLLOW ON FROM #4779
With cursor pagination, we can't use a common pattern, ex:

< Previous , 1, 2 ... 99, 100, Next >

How can we work around that limitation but still help users understand where they are in any given view of data? It can be easy to get lost when you have 100s of results with only:

< Previous Next >

What you need to know
Talked over this with Kevin and Dawn while reviewing submission history filtering. Was curious if we could count "pages" as number of results instead. Could be a way to help folks understand their spot in a given list of data. Ex:

< Previous , 01-10, 11-20 ... 51-60, 61-70, Next >

Would be helpful to know the total results for any given page and/or page with a filter applied. Ex:

100 total things in this view
25 results with your current filter applied
Current page = results 01-10

Solution to implement is below. Update from Kevin in #4788
With the pagination refactor from #1922, we're able to see a current page number and know the pageSize value, which can allow us to display an item number range in lieu of a page number for our paginated list.
Example
// gives you the first item on the page
// e.g. page 2 would be -> 10 * (2 - 1) + 1 = 11
const firstItem = paginator.pageSize * (paginator.currentIndex - 1) + 1

// gives you the last item on the page
// e.g. page 2 would be -> 10 * 2 -> 20
const lastItem = paginator.pageSize * paginator.currentIndex
return Items: {firstItem} - {lastItem} // Items: 11 - 20

Acceptance criteria

[ ] Pagination component is updated from design in #4779
[ ] A user can page backwards and forwards
[ ] A user can see what range of results they are currently in
[ ] A user can see the total number of results are currently available to page through

To do
Design

[ ] ...

@bgantick just added you as the assignee on this one and updated AC to match the related design ticket.

Closing, duplicate of #5286


Old URL for  CLI docs page is showing 404

Describe the bug
The CLI docs are down - https://arrow.apache.org/datafusion/user-guide/cli.html they're just showing 404 "Not Found"
To Reproduce
go to https://arrow.apache.org/datafusion/user-guide/cli.html
Work around is to use https://web.archive.org/web/20240227014509/https://arrow.apache.org/datafusion/user-guide/cli.html
Expected behavior
see them
Additional context
No response

@samuelcolvin Docs for CLI were recently moved to https://arrow.apache.org/datafusion/user-guide/cli/index.html in this PR: #10078
@alamb could we setup a redirect?
https://arrow.apache.org/datafusion/user-guide/cli.html is the URL that shows up in search results when looking for datafusion cli. Might confuse users to land on a missing page.

Thanks.
Redirect would be good.

Thanks -- yes @tinfoil-knight  and @samuelcolvin  -- a redirect (or even just a page saying the content moved with a link to the new site). Prs most welcome

@alamb @jayzhan211
I would like to try this.

take

Thank you @doupache 🙏

(I hit this issue when google searching today so figured I would make a PR)
This is what I came up with : https://github.com/apache/datafusion/pull/10187

I double checked the link and it appears to be going to the right place now. Thank you for the report @samuelcolvin  -- sorry it took so long to fix


Love this.

I just wanted to acknowledge this project. I'm really enjoying it so far. I can see it has tons of potential. Awesome work.

Thank you very much!

If you have any recommendations, do let me know :)


Opt.Nullable implementation

Fix for #555.

Opt.Nullable container implementation to store possible-null value
Only non-null values should be placed inOpt.Single container

@davvd Please proceed with code review.

@happy-neko Thanks, I will find someone to review this PR soon

@krzyk review this one, please

@Happy-Neko please see my comments

@krzyk fixes committed, thanks for the review.
One thing I disagree with is accepting null in Opt.Single constructor. Since this is container for non-null value we should be defensive here and not instantiate object in invalid state hiding the bug. Adding simple validity check here already revealed at least two bugs in our code (see #609).

@Happy-Neko have a look here http://www.yegor256.com/2015/05/07/ctors-must-be-code-free.html#comment-2014240415

@Happy-Neko minor thing in the javadocs and we can go

@krzyk javadocs fixed.

@rultor merge pls

@rultor merge pls

@krzyk Thanks for your request. @yegor256 Please confirm this.

@Happy-Neko hey... we're against NULL at all. we don't need to deal with NULL ever. we just don't know what NULL is. by creating such a class we admit that NULL has its place in OOP. but it doesn't

@yegor256 Nullable renamed to Optional.

@Happy-Neko I don't understand what all this is for. we should get rid of NULL everywhere,  not create some wrappers for it. NULL is an anti-pattern, in the first place. it must not exist in Java code. that's what ticket #555 is about.

it must not exist in Java

@yegor256 obviously java is created with other thoughs. null considered ok by language creators, it is used in every single library in any hava project(and in JDK itself). Creators of Java just removed everything what they don't like from C++ and got actually Java. Don't you think of creating your own programming language?

@exper0 Java creators made many mistakes. we should not just blindly follow their ideas. NULL is a bad thing, no matter who created it or where.

@yegor256 just curious - do you know any language without null or nil concept? I understand your position - in perfect world null doesn't make sense. However, java HashMap may return null, there are lot of such examples. Does it mean we shouldn't use the code where null is normal value?

@exper0 I don't know any languages without NULL. I don't have an answer about JDK classes. let's try to think what to do with them. ideally, we should stay away from them. but it's not always possible. ideas?

@yegor256

not create some wrappers for it. NULL

Optional<T> is not wrapper for null. It is container for specific type that may be empty. This is how possible absence of value is represented in languages that forbid null references (for ex. Swift). We already have Opt.Single for empty containers. Is it wrapper for null, what do you think?
Anyway we could not throw away API methods that may return null whether we like it or not. And this means testing return values for nullability. If you want to reduce 'null' literal usage in the code this is the way:
final Optional<Type> result = someUglyMethod();
if (result.has()) {
    // method returned something; extract with result.get()
} else {
    // method returned nothing
}

@Happy-Neko yes, this is probably the only option we have... let's go for it

@yegor256 done.

@Happy-Neko first, I didn't understand why did you rename Opt to Optional. second, your pull request doesn't prevent us from using null again. There must be some check for that. @krzyk please, take a look

@Happy-Neko OK, after looking at the places where null is used in the code I think you approached in to general way, while actually you should go and remove all the nulls possible.
Here is a good start:

BkSafe, assert not needed, workaround for poor exception handling
CcBase64 - all asserts are not needed if qulice is upgraded to 0.16.1
FkHitRefresh - this null check is not needed if earliler we check that the directory exists
FtBasic - assert not needed, workaround for poor exception handling
Href - null check not needed, one has to check if key exists instead
Items - check if File is directory first, then null should not happen
MainRemote - not sure here, probably more investigation needed
Options - check if key exists instead of null check, and in the matcher case, check matcher.groupCount
PsBasic - check if key exists (containsKey)
PsGoogle - check if key exists (Json is a Map)
RqCookies - again containsKey

and so on, each case has to be analyzed, and I think in majority of the cases null can be removed, so there is no point in introducing another class that will have  != null.

@yegor256 fixes committed.

@yegor256 @krzyk
What work need to be done to have this PR merged? Please keep in mind this ticket allocated time budget 30 min.

@Happy-Neko You can use todos for some parts of the work. You didn't address @yegor256 comments (about renaming to Optional, and about a check to prevent using nulls).
And I still think the correct approach would be to just remove the nulls from the code by using a correct API (e.g. map.get(..) != null is not correct, one should use map.containsKey()) and it is quite easy, not controversial. You could leave some of those nulls in a todo, together with a check that would fail a build if a null appears in the code.
This would be much easier then what you are doing in current PR, where you assume that we can't get rid of JDKs nulls, it might not be possible, but you didn't try it.

@krzyk @yegor256

Optional is different class (not implementing Opt interface). Opt was removed as redundant because Optional can serve both as empty and non-empty container.

Checking for null return values or changing API methods is outside of this PR's scope  - implementing container type.

Decision to wrap return values in Optional was confirmed by @yegor256 here https://github.com/yegor256/takes/pull/610#issuecomment-190291755

I am sticking with it due to task's estimated time budget.

TODO is already created #608.

@Happy-Neko @yegor256 do we proceed with this PR? It is already 1.5 month old.

@Happy-Neko I don't understand why you removed Opt.Empty and replaced with Optional, Opt.Empty should stay as it was, and all of its usages should be unchanged. What you did introduced additional nulls to the project which is in contradiction what this ticket is for.
As @yegor256 confirmed that we need a container for nulls, create just that, don't throw away existing Opt classes.
Your new null container class will be used (probably in future tasks - add todo) to replace places where we have null and can't get rid of them.

@yegor256 is Happy-Neko still with us?

@davvd @yegor256 @krzyk
I could not work on assigned issues, please reassign them.
Also netbout's google login is not working and I could not set "away" status.

@Happy-Neko so, please close this PR if you can't work on it now

@yegor256 @Happy-Neko can we drop this PR? It doesn't seem like it will finish.

@krzyk ok.

@ypshenychka review this ticket please, for compliance with our quality rules

@davvd Quality is good.

@davvd Quality is good.

@ypshenychka many thanks

@krzyk just added 10 mins to @ypshenychka (for QA), payment ID is 84796490; Much appreciated! 1 hour and 18 mins was added to your account, payment ID 84796509, time spent is 1730 hours and 33 mins; you're getting extra minutes here (c=63); added +78 to your rating, now it is equal to +3761


Support for ifelse

For simplicity should we add support for ifelse?  This contributed to user error in transitioning from JAGS to NIMBLE in a nimble-users list message dated 31 July 2021.

@perrydv If it's a trivial addition to make, then it seems quite reasonable.


Put build-tools on path for current project

This is a follow on from the build-tools PR yesterday, doing the same thing for the current project.
It also removes the MAFIA_HAPPY like env vars are they are no longer required.
/cc @thumphries

Looks good 🐫

:goat:

🍔  that was fast!
Do we still need the bin symlinks?

Do we still need the bin symlinks?

I tried getting rid of them, but the problem is that ensureBuildTools runs on every mafia command, and the symlinks are a fast way to check that we already have the build tool. It shaves about 2 seconds off the build.
Potentially we could put the symlinks in the sandbox instead, that might be a bit cleaner, but I'll leave that for another day.


⚠ Spryr has degraded performance

In 93ff07f, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 3357 ms

Resolved: Spryr performance has improved in 76b0112 after 25 minutes.


⚠ Guya.moe Proxied has degraded performance

In 8c47200, Guya.moe Proxied (https://ice.guya.moe/) experienced degraded performance:

HTTP code: 200
Response time: 11964 ms

Resolved: Guya.moe Proxied performance has improved in 7e685e6 after 4 hours, 31 minutes.


[BUG]

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.
[ ] My answer given in the checkbox above is a lie.

What problem did you encounter?
The see page or join buttons wont show up on my status

They won't show for yourself. They'll show for other people.


calldata vs memory for leafs in verifyMultiProof for MerkleProofLib

In verifyMultiProof the leafs data location is specified as calldata:
function verifyMultiProof(
    bytes32[] calldata proof,
    bytes32 root,
    bytes32[] calldata leafs, // <-- calldata
    bool[] calldata flags
) internal pure returns (bool isValid)

This provides an issue when trying to hash values in the smart contract itself and pass them into the verification. For example, the following code does not compile:
bytes32[] memory leafs = new bytes32[](tokenIds.length);
for (uint256 i = 0; i < tokenIds.length; i++) {
    leafs[i] = keccak256(abi.encode(tokenIds[i], timestamps[i]));
}

MerkleProofLib.verifyMultiProof(proof.proof, merkleRoot, leafs, proof.flags);

The error produced:
Invalid type for argument in function call. Invalid implicit conversion from bytes32[] memory to bytes32[] calldata requested.

Ah, time to add verifyMultiProofCalldata and verifyCalldata versions, and make the default versions memory based.

ty for quick response


Ignore system files

Is there any way to ignore node's native modules, like modules. I don't think anyone wants to see that.

I tried --hidden=['module.js'], but sure enough, module.js is still shown in the debugger. Has anyone ever actually cared what module.js is doing? I'm trying to debug my code not node's native modules. I don't understand why it's even there, much less the default, and much lesser the default that is seemingly impossible to work around.

How about --hidden=^module.js$?


Autocomplete does not provide hints and completions for function parameters

VS Code Version: 1.54.0
OS Version: MacOS 10.15.7
Language: Typescript

Our file:
const aVariable = 'asd'
const anotherVariable = 'asd'

console.log  // #1
console.log()  // #2

Steps to Reproduce:
Setting False, does not autocomplete function, but autocompletes variable.
1.
In settings.json, set:
  "javascript.suggest.completeFunctionCalls": false,
   "typescript.suggest.completeFunctionCalls": false,

Type console.l
Autocomplete it into console.log
Add paranthesis console.log(
Start typing variable console.log(aVar
It shows code hints and can autocomplete variable

Setting True, autocompletes function, but does not auto complete variable.
1.
In settings.json, set:
  "javascript.suggest.completeFunctionCalls": true,
   "typescript.suggest.completeFunctionCalls": true,

Type console.l
Autocomplete it into console.log()
Start typing variable console.log(aVar)
It does not give code hints and cannot autocomplete variable

Does this issue occur when all extensions are disabled?: Yes
Related:
https://github.com/microsoft/vscode-go/issues/3075#issuecomment-599326659
https://github.com/microsoft/vscode-go/issues/3037
https://github.com/microsoft/vscode-go/pull/3038
Notes:
If there is another setting needed to make this work, feel free to point me out to the right direction. I absolutely have no idea how this IDE was coded with typescript and has so many users, but miss this simple feature. Am I doing something wrong?

Try setting "editor.suggest.snippetsPreventQuickSuggestions": false.
You can also always manually trigger suggestions with ctrl+space

Thanks, that worked.
I don't see any good reason why these 2 settings are not default.


UI changes to improve the look

Hey, can I work on this issue.
Also can you suggest me any color scheme you would like.

@Im-Abhi  Hey ,thanks for the interest.
Right now i want it to have light theme ,I will add dark theme afterwards. So use combination of light colors. I don't want to use normal white as it looks very flat. Other shades of white might look good.
Some points to consider -

The user should be able to see all kind of pictures clearly.
And it should not be too bright and should give a calm feel.


Allow nc_inq_var_szip() to return NC_NOERR and zero for parameters for vars without szip, also added parallel szip test

Well this szip stuff was more of a can of worms than I expected! However, as my first boss used to say: "Anything worth doing is worth doing right." ;-)
In this PR we allow nc_inq_var_szip() to return success and zeros for parameters if szip is not on for the var. This matches the behavior of the API with the other filters. It is not an error to do an inq on a filter, even if the filter is not present.
Also renamed test tst_parallel_zlib2.c to tst_parallel_compress.c, and added a szip test that will only be run of szip is present in HDF5, and parallel filters are allowed.
Also fixed the incorrect location of the AC_SUBST call which was causing problems for non-netcdf-4 builds.
Also more documentation to help explain and capture all the fun twists and turns of szip use.
This PR includes #1619 and #1623
Fixes #1622
Fixes #1618

This failed travis due to the test_byterange.sh test. Probably network timeout. I will update the branch to launch another travis run...

I'm going to take this PR down. These changes are included in later PRs.


adding a missing comma that's causing template engine to error

I missed this when I added an id

CI: No security warnings found


'Recompose name' approach to lab team on ingestion

Hi Kyu - This is the edit I had in mind, just looking through your error stack in 979. If this works, we cacascade the fix to 983 with some changelog edits

I just added another commit to address the second reference to team_member. This makes create_new_team format-ambivalent. Either way it is passed in, insert_from_name will decompose for itself, and then run decompose_name for itself so that the full_name is first last when checking

@CBroz1 doesn't LabMember.insert_from_name('Kyu Hyun Lee') still lead to an error because of the extra space?

My goal was to avoid errors by passing the inverted version

yeah well that means the team_members parameter to LabTeam.create_new_team must be last, first, right? that's fine for NWB ingestion case but if someone wants to call the function to create a new lab team then team_members has to be last, first, which is unnatural (and your motivation for not going with my change initially, I thought).


Buy Glo modal: dollar input UI broken

Current:

Previously was:

Let's make sure it returns to that

The impact input should definitely have its own custom component styling since it's not shared anywhere else


the description of 18.9, section 18.9.1 references section 18.9

I am not sure that was meant to be done here, but section 18.9.1 references section 18.9.  Maybe this is meant to be a reference back to 9.3?  It seems like this should be updated to not be self referential or removed.
https://github.com/c2pa-org/specifications/blob/153a62110fa0f6a61d4b960509fc50a645c6c2e1/build/site/specifications/2.1/specs/C2PA_Specification.html#L8839C1-L8840C1

Oh. Will investigate - thanks!!


Feature/volume motion blur

Summary
Added support for eularian deformation motion blur for volumes.
Change Log

Moved the MotionPosition enum from camera to a kernel_types.h to be able to use in kernel
Added a new function to geom_volume.h to support different up_axis configurations
Added velocity_scale field to ccl::Object and kernel object to scale volume motion blur
Added an fps field to Camera

Testing
Please see the hdCycles PR: https://github.com/tangent-opensource/hdcycles/pull/75

Hi @sergeneren,
The results look good and the implementation in line with the paper equations (6/7 in Eulerian Motion Blur). Just a couple of questions.

Is the behavior for out of bounds lookups specified by the extension type (extend/clip/etc)? The Arnold paper mentions dilatating the volume based on the (pre-filtered) max velocity. I wonder if the quality improvements justify it or not. Maybe this is already currently done during export in which case ignore the question.
Have you tried running it inside usdview?

@dedoardo thanks for the review,

Dilating the bounding box of the volume by the max filtered velocity has not been implemented here because based on my experience in Maya project I've seen that filtering had a significant impact on the time to first pixel (mainly because my filtering implementation was single-threaded and did lots of sorting). But during the production, out of many shots there was only two cases that needed dilation in the vel field and it was easily solved by expanding the velocity vdb by some voxel amount before export and filtering was only needed once. So it was a deliberate choice.
I couldn't yet test it in usdview (having a rez package conflict about usd version and I'm trying to resolve it)

Thanks for the reply @sergeneren

Good to know, if it's happening so rarely I agree it's probably best to resolve the issue during export when needed rather than slow down all the other volumes. I'm guessing it was something with very high velocity causing this?
Ok, I asked exactly because I was running into similar issues and wasn't sure whether it war related to this PR. It's more likely due to building issues.


Add positional arguments to command usage

It would be incredibly nice to document positional arguments somehow, maybe by adding an 'Args' field to Command struct.
This may already be possible, but looking at the code/readme it was not obvious. Thanks for your help.

@LLParse I think you're looking for the ArgsUsage string, present on both the App and Command structs :smiley:

How sill am I, that plain english eludes me! Thanks for your quick reply @meatballhat


Screen Reader mode enabled without intent

Type: Bug
Restarted Insiders for an update and Screen Reader mode is suddenly on, including audio cues while typing. I have no idea how to disable it, as the Screen Reader Optimized status bar icon is clickable (changes color), but doesn't do anything.
(Edit: I eventually found editor.action.toggleScreenReaderAccessibilityMode command, but I don't see any logs that I used that command before)
cc @meganrogge who recommended @deepak1556 as assignee.

VS Code version: Code - Insiders 1.84.0-insider (7dff07893ac160244db210e574eccc05f1cba2cb, 2023-10-24T05:35:10.309Z)
OS version: Darwin x64 23.0.0
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz (16 x 2400)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
4, 4, 4

Memory (System)
64.00GB (0.74GB free)

Process Argv
--log trace --crash-reporter-id 4cf0a6f0-aaf8-4da3-9b2b-81f6c639c12b

Screen Reader
no

VM
0%

@deepak1556 not aware of any changes on your end, so i'm just reverting the only relevant PR

Just launched a fresh Insiders and got this notification:

I do see it detecting a11y for me in telemetry events
telemetry/accessibility … "measurements":{"enabled":1…`
Version: 18b7f75a9fab40499744c2e9c6ba9af64d5c6744, 2023-10-25T05:37:06.169Z (9 hrs ago)

Indeed then, it seems an issue with detection @deepak1556 , not sure why this would be showing otherwise as nothing's changed on my side.

No changes have been made in the runtime with respect to a11y detection, on macOS the runtime can enter a11y mode in the following 2 scenarios,

Setting AXEnhancedUserInterface attribute on the application which is usually done by screen readers (VoiceOver)
Setting AXManualAccessibility attribute on the applications which is usually done by third party window managers

@digitarald are you using any custom window tiling managers ?

I do run window managers, yes. So, I guess I'll close this for now as it might have been an update, like Bartender 5.


QueryParser incorrectly rejects an IRI containing a colon to separate host and port

With rdf4j-queryparser-sparql version 2.3.0, an IRI containing a colon to separate the host and port is incorrectly rejected as invalid. This problem does not occur with version 2.2.4.
To reproduce, use an org.eclipse.rdf4j.query.parser.QueryParser to parse this SPARQL:
PREFIX incunabula: <http://<IP_ADDRESS>:3333/ontology/incunabula/simple/v2#>

CONSTRUCT {
    ?book incunabula:title ?title .
} WHERE {
    ?book a incunabula:book .
}

This throws the following exception:
java.lang.IllegalArgumentException: Invalid IPv4 address U+3A at index 14: http://<IP_ADDRESS>:3333/ontology/incunabula/simple/v2#
	at org.eclipse.rdf4j.common.net.ParsedIRI.create(ParsedIRI.java:266)

While it is probably uncommon to include port numbers in IRIs stored in a triplestore, we are using the RDF4J SPARQL parser in a SPARQL-based DSL in which we need to be able to do this.

We are facing the very same issue in a slightly different context within our application: we are using the HttpRepositoryConfig and provide as endpoint URL some location with an IP address (say 'http://<IP_ADDRESS>:8080/openrdf-sesame/repositories/repo').
In our application we use a bootstrap mechanism for repositories and persist the result model of HtppRepositoyConfig#export in a turtle file. Parsing such a turtle file with above URL as repository URL will fail.
A minimal test case that reveals the cause is
	@Test
	public void testParsedIri() throws Exception {

		String iriString = "http://<IP_ADDRESS>:8080/openrdf-sesame/repositories/repo";
		ParsedIRI iri = new ParsedIRI(iriString);
		Assert.assertEquals(iriString, iri.toString());
	}

A test case for our ttl parsing problem is
	@Test
	public void testParseBrokenTtl() throws Exception {

		String ttl = "<http://ex.com/s> <http://ex.com/p> <http://<IP_ADDRESS>:8080/openrdf-sesame/repositories/repo> .";
		Model m = Rio.parse(new StringReader(ttl), "http://ex.com/", RDFFormat.TURTLE);
		Assert.assertEquals(1, m.size());
	}

Note: it looks as setting org.eclipse.rdf4j.rio.helpers.BasicParserSettings.VERIFY_URI_SYNTAX as non fatal error does not help