Fix/295 migrate to v3 metapool

Resolves #295

Solidity script for migrating v2 metapool funds in both BondingV2 and ubq.eth to v3 metapool

Its a bit overwhelming to see all the file changes again from this and seemingly your other pull request. In order to wrap this bounty up, perhaps you can walk me through what I need to do in order to complete the migration while I use the ubq.eth EOA?
I assume that we can merge in your other PR I reviewed deeply and then we can go back to review this one to see less changes? Otherwise you should rebase from a newer commit because there's a lot of redundant/old changes in this PR I think.

Its a bit overwhelming to see all the file changes again from this and seemingly your other pull request. In order to wrap this bounty up, perhaps you can walk me through what I need to do in order to complete the migration while I use the ubq.eth EOA?
I assume that we can merge in your other PR I reviewed deeply and then we can go back to review this one to see less changes? Otherwise you should rebase from a newer commit because there's a lot of redundant/old changes in this PR I think.

Yeah, I'll wait until the other PR is merged then do what I need to so only the relevant files are reflected in the changes.

@hashedMae why was this closed?

@hashedMae why was this closed? You can rebase this PR instead of #531
Rebasing is pretty straightforward with the Git Graph extension for vscode.
Name: Git Graph
Id: mhutchie.git-graph
Description: View a Git Graph of your repository, and perform Git actions from the graph.
Version: 1.30.0
Publisher: mhutchie
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph

Had never heard of Git Graph and when I tried to rebase the last PR, it didn't pretty much nothing to clean up the differences.

Normally when you rebase it doesn't show all the redundant commits in the pull request because you "changed the base" commit to one that is after all those commits.


Adding v0.5.0 blog post

What type of PR is this?
/kind documentation
What this PR does / why we need it:
This is a follow up to @shaneutt's PR: #1227 and mirrors https://github.com/kubernetes/website/pull/34968.
Does this PR introduce a user-facing change?:
NONE

/hold for release

/lgtm
/hold for others to review if necessary

/lgtm

Is this ready to go out? Looks that way.

@robscott (or another person from the Gateway project, eg @youngnick): the next steps, as I see them:

do the release

make sure that https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.5.0 is live
make sure that https://gateway-api.sigs.k8s.io/guides/getting-started/ links to the v0.5.0 release

unhold this PR once ready
wait for https://gateway-api.sigs.k8s.io/blog/2022/graduating-to-beta/ to be live

and check it looks right

unhold https://github.com/kubernetes/website/pull/34968

Thanks @sftim! We're hoping to have the release out in around an hour and then we'll remove the holds on these blog posts in the order suggested above.

/hold cancel


Add Suunto Moveslink2 v<IP_ADDRESS>

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if adding a new cask:

[x] Named the cask according to the token reference. Token reference would be moveslink but the editor made a distinction between moveslink and moveslink2. That's why I kept moveslink2.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.
[x] Checked there are no open pull requests for the same cask.
[x] Checked the cask was not already refused in closed issues.
[x] Checked the cask is submitted to the correct repo.

This is in caskroom/drivers: moveslink2


Use Popper for NavBar

This PR changes the Popover component in NavBar to Popper to allow user to open another Menu or interact with Map / DateSelector without having to do additional click to close Popover menu
https://user-images.githubusercontent.com/1814324/186328752-9d7b938d-4f05-4d5a-a3c3-fd00d4f26d9f.mp4

@reed1 - I'm not fully clear on what the issue you are addressing here is. Can you please explain in more detail what is currently not working as desired?

@wadhwamatic in the current version: http://prism-549.surge.sh/, if you open flood menu, then you want to switch to rainfall menu, you'd have to click 2 times, one is to close flood menu, then another one to open rainfall menu. Also if you have a menu opened, you can't immediately interact with map (panning and zooming) without clicking once outside menu to close that menu.
In this version: http://prism-menu-popper.surge.sh/, if you open hazards menu, the you want to switch to vulnerability menu, you'd only have to click one time. And if you have a menu opened, you can immediately interact with map (panning and zooming) without having to close the menu first

Thanks for the review @ericboucher. Good to go from my side.


fix: use optional chaining when isEqualNode is not available

When being used in a test environment, with happy-dom, this method is not implemented.
More context: https://github.com/capricorn86/happy-dom/issues/656
I was facing this issue testing a Nuxt app, with vitest (and https://github.com/danielroe/vitest-environment-nuxt).
Making the check optional, makes my tests pass. But it might be too naive?

Hmm seems like this could result in duplicate tags being inserted for environments that don't support isEqualNode. I believe other packages just polyfill this.
I'll merge for now, let me know if you run into any other issues though
Thanks!


handling of the EKMF Web plugin and library

s390-tools 2.15.0 have added EKMF Web plugin and support library to the set of produced libs and tools. But they don't follow the best practices on how they can be properly distributed.

plugins like zkey-ekmfweb.so should live in $libdir/$project so they can be distinguished from regular shared libraries and not interfere with automatic dependency generators
both plugins and libraries should set soname to inform about the ABI they provide, you already use the symbol version script when linking them
libekmfweb should use libekmfweb.so.1 as its filename (tied to the soname) and make libekmfweb.so the development symlink. I assume there is a reason for having this library as shared, because you are installing ekmfweb.h so you are expecting other users than zkey

You can take a look at the qclib, they also use plain Makefile to manage all details of the building/linking process.

also libekmfweb and the zkey-ekmfweb plugin should go under /usr/lib64 rather than /lib64

Thanks for suggesting this.
I have prepared a patch to introduce what you asked for.
Please take a look and let me know if this is what you are looking for:
https://github.com/ifranzki/s390-tools/commit/b27e3ec68086672213a695e21ff764dac761502e
I moved zkey-ekmfweb.so to /usr/lib64/zkey/. To ensure that zkey can load this plugin I needed to specify the absolute path to the library in zkey/kms-plugins.conf. Is there a better way for this?

Thanks, Ingo. I have commented in the patch itself.

Thanks for the comments. I have reworked the commit according to your comments and force pushed, please see here: https://github.com/ifranzki/s390-tools/commit/d09ed47ea548b831d3556142d15164ef7bf2d9be.
So for zkey-ekmfweb.so I only create the .so without a version in the file names, but I set the soname ELF attribute to zkey-ekmfweb.so.1, is this correct?

Thanks for the comments. I have reworked the commit according to your comments and force pushed, please see here: ifranzki@d09ed47.

thanks, will take a look

So for zkey-ekmfweb.so I only create the .so without a version in the file names, but I set the soname ELF attribute to zkey-ekmfweb.so.1, is this correct?

yes, I would do it this way. It will contain the ABI info, but still allow simple dlopen()ing via zkey-ekmfweb.so.

I have commented in the new patch, I believe it should be the last batch :-) I have applied the changes locally and the result looks good.

Thanks, I have adjusted the commit accordingly:
https://github.com/ifranzki/s390-tools/commit/4a1979de79d9de48a44538f856f1d50f398541a8
We will integrate this patch internally and make it available on the master branch soon.

Awesome, I will add the last version to the Fedora s390utils package.

Would moving zkey-ekmfweb.so to /usr/libexec/zkey/ be fine with you, too?

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_libexecdir is what our guidelines say about libexec, thus I would prefer to keep zkey-ekmfweb.so in /usr/lib64/zkey.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_libexecdir is what our guidelines say about libexec, thus I would prefer to keep zkey-ekmfweb.so in /usr/lib64/zkey.

yes.... it says that libexecdir may be used..... which would be the same location for both Ubuntu and Fedora. Ubuntu cannot use /usr/lib64/zkey at all for the s390x port.
also it is cute that the fedora guidelines mention upstream configuration system.... it would be nice if s390-tools had meson (or make / autoconf, or well anything) to detect and configure these things. As by default rpm macros and debhelper do pass all of these paths with the right expected locations, to buildsystems that have configure step.


Add feature for Swagger 2.0 parameter references

@dkniffin was also a big contributor to this PR
Why?

Addresses #64
Allows for Swagger 2.0 parameter reuse

What Changed?

The parameter method in OperationNode and PathNode can now use symbols as references to root level parameters.

Updated tests for referenced params

Updated README

I like everything about this! Thanks for the docs, tests, and backwards-compatible implementation.

Release as swagger-blocks v1.4.0.

@fotinakis I think we're gonna have another PR very similar to this for responses, fyi. Might be incoming later today.


Pull in frame rate changes from PIC and correct documentation

Issue #, if available:
Description of changes:
Fix documentation for incorrect sample names and update producer C commit to pull in frame rate changes.
To Do:
Update commit once producer C PR is merged.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report

Merging #688 (04eda90) into master (6bbd9fd) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #688   +/-   ##
=======================================
  Coverage   69.47%   69.47%
=======================================
  Files          32       32
  Lines        1661     1661
=======================================
  Hits         1154     1154
  Misses        507      507

Impacted Files
Coverage Δ

src/KinesisVideoStream.cpp
51.19% <ø> (ø)

src/KinesisVideoProducerMetrics.h
100.00% <100.00%> (ø)

src/KinesisVideoStreamMetrics.h
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 6bbd9fd...04eda90. Read the comment docs.


Using ReadBodyRoutePredicateFactory in Custom global Filter

Hi,
I am writing one custom Global Filter which need request-body to work.
Since ReadBodyRoutePredicateFactory is a bean, I am autowiring it in my custom filter and invoking apply and getting Mono.
Now subscribing on it is  never executing and body is not being set in 'cachedRequestBodyObject' attribute and getting null.
Also, when I declare 'ReadBody' with args in yaml, it works through cloud gateway framework. I am confused why it is working and setting 'cachedRequestBodyObject' in attribute when declared in yaml but not working programmatically.
Please guide what am I missing.
TIA
Mohammad

I'm afraid without seeing what you are doing, I won't be able to help.
If you'd like us to spend some time investigating, please take the time to provide a complete, minimal, verifiable sample (something that we can unzip attached to this issue or git clone, build, and deploy) that reproduces the problem.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


Serverless AWS Lambda support

Hello,
Thanks for the work you've done !
I would like to know whether react streaming is supported in serverless environments like lambda or fargate.
Cheers

Yes

Let me know if you run into any issue. Just created a Discord Vike channel for react-streaming: https://discord.gg/H23tjRxFvx.


Set playing to true by default

After some thought, I wonder why playing isn't true by default. Most users, especially those using ReactPlayer as a dumb player with no external controls, will want media to be playing if the component has been mounted. This saves a lot of unnecessary playing={true} props.
This may be a breaking change and perhaps should wait until v1.0, which I think should happen soon.

@CookPete I am not so sure. Especially given that this breaks the whole component on mobile devices, I think it still makes more sense to have it explicit.

Especially given that this breaks the whole component on mobile devices

This is a good point.


Code review

Beside the special cases, tests employed a brute force approach. Over 4000 values and their bit literal representations were computed in Julia and used as test fixtures for this module. All tests pass and results were further experientially validated via the example code.

LGTM. I was so free to publish in order to use it in the gammaln module.

Thanks!


Determine story around JSON message compatibility

So far, we have treated the JSON messages emitted by --message-format=json (docs) to be somewhat stable (with the caveats of adding new fields). However, that stability has been broken at times (see https://github.com/oli-obk/cargo_metadata/issues/240 as an example). We don't have a strategy for how such changes could be made. We should probably come up with some story and documentation for how we manage the compatibility.
This issue is to collect feedback and ideas on how this should be handled and documented.
Note that this somewhat transitively applies to rustc's diagnostic structure. There should probably be a consistent story with both that and cargo's own messages, which may involve consulting with the compiler team.

My thoughts/ideas:
Versioning doesn't work particularly well since introducing a new version that tooling doesn't recognize would cause them to break (and in the debuginfo case, would cause them to unnecessarily to break in most cases since that change only affected the rare projects that would use the string-based types).
We could potentially indicate that types of fields can change between versions, but otherwise meanings of existing fields wouldn't change. But that could be a challenge for deserializers like cargo_metadata since the only choice to stay compatible would be to deserialize to something like serde_json::Value, losing all structure. Or those tools could just accept that type changes would break their tooling.
We could potentially just document that this format is not stable at all, and shed responsibility. An option for tools like cargo_metadata is that they could just do semver-breaking changes periodically.
Another option is to document that the format is stable except in the presence of new opt-in features (like the debuginfo string example). This could make it challenging or impossible to make broader structural changes.

The problem with using requested versions is trying to figure out how to map new concepts into the old version. Things like Cargo.toml evolve independently of the JSON interface. This issue was triggered by https://github.com/oli-obk/cargo_metadata/issues/240 where the type of a field changed. For example, let's say there was a project with:
[profile.dev]
debug = "line-tables-only"

Format version 1 specified that debuginfo was an integer. If cargo tried to keep compatibility with format version 1, what would it show in the debuginfo field? No integer value would be correct. Should it generate an error? That's not much different from just breaking the tool (and possibly worse depending on how the tool parses, since most tools don't care about this field, though an explicit error could be clearer for tools that just fail to parse).

you'd be forced to bump the format version.

This is the part I'm not quite following. Can you clarify what that means?
My interpretation is:

A tool is passing --format-version=1 to indicate which format of JSON it is expecting.
A new cargo release is made that changes the type of a field, and that now requires --format-version=2 and generates an error for =1.

This can be mitigated a little by only generating an error with =1 if the user is using the changes that modified the field type (like the new string-based values), but that still breaks tooling when a user opts into those new values.

The tool will be broken when used with the new release (since it is still passing in =1), and thus the new release is not backwards compatible.

It might be a slightly nicer error message, but for some use cases that would be worse because some tools weren't looking at that field or care about it (and thus would needlessly break them).

but if there are no guidelines or anything that reminds people of those guarantees, the expectation is low, or non-existent.

We do have guidelines that say cargo is intended to be backwards compatible except where specified, but there were no automated tests or tooling to enforce it in this case and nobody recognized that this type snuck into the serialized format or recognized that it was a breaking change until it was too late. We also have versioning built-in to cargo metadata, but that also requires reviewers to recognize when a breaking change is made.
However, even if we did recognize it, I don't know what we would have done differently. None of the options seem particularly good to me. That is, they all seem to break tooling in one way or another.
The answer might be that the only option we have is to break backwards compatibility in some way. Then the question is, which approach causes the least breakage? Of the options I see, it seems like we stumbled on the course with the least amount of breakage (although we should have been more explicit about it in the docs, and proactive in updating the cargo_metadata crate). I'm not saying it was the best course, though. I'm just concerned about forcing tools to break via version declarations when they wouldn't otherwise be broken (when they don't care about the changes).


P1 - kube runtime may change user's python environment

In current design, the kube runtime may change users' python path, e.g. python linked to python2 other than python3.
Proposal:

use the existing python to create py2 and py3 virtualenv, and install essential packages on demand
runtime plugin activate the python virtualenv as they like
some plugins may assume an existing python environment, e.g. tensorboard, jupyter-notebook ...

fixed in https://github.com/microsoft/pai/pull/4157


Support streaming code unit sequences by saving incomplete code unit sequences as encoding state

Consuming code unit sequences from a streaming source may result in attempts to decode a partial code unit sequence.  At present, an exception will be thrown when such underflow occurs.  An alternative would be to store the partial code unit sequence in the iterator state and then have the iterator compare eusing encoding = utf8_encoding;
auto state = encoding::initial_state();
do {
std::string b = block_and_get_more_data();
auto tv = make_text_view<utf8_encoding>(state, begin(b), end(b));
auto tv_it = begin(tv);
while (tv_it != end(tv))
...;
state = tv_it;  // Trailing state is in end iterator, preserve it
// to seed state for the next iteration.
} while(!b.empty());qually to the end iterator.  This would enable code like the following to work correctly even if buffer ends fail to fall on a code unit sequence boundary.
using encoding = utf8_encoding;
auto state = encoding::initial_state();
do {
   std::string b = get_more_data();
   auto tv = make_text_view<utf8_encoding>(state, begin(b), end(b));
   auto tv_it = begin(tv);
   while (tv_it != end(tv))
     ...;
   state = tv_it;  // Trailing state is in tv_it, preserve it
                   // to seed state for the next iteration.
} while(!b.empty());

A problem with this approach is that it leaves open the possibility for trailing code units (e.g., garbage at the end of the encoded text) to go unnoticed.  Because of this, the behavior above probably shouldn't be the default behavior, but it should be possible for code to opt in to it; perhaps via a policy class as suggested in #14.

I have been thinking about this topic (wrote this two things: https://github.com/ruoso/u5e/blob/master/StreamVsIterators.md
https://github.com/ruoso/u5e/blob/master/StreamVsFormat.md )
I believe it's best if there is a more clear "firewall" between raw data and text. The code handling the specific streamed protocol (such as HTTP or IRC for instance) is in a much better position to validate the data before 'declaring' it to be text. Doing that in the iterator itself creates an undue burden on everyone handling that type of code.

I agree that ensuring proper data boundaries in packet oriented protocols is best practice.  I think there will always be cases where that isn't possible though.  In those cases, the only solutions I've found so far are for the iterator to throw an exception, block (on advancement of the underlying code unit iterator), or the approach described in the first comment of this issue.
The initial email thread where I requested feedback on text_view talked about some of these options.  You can find it at: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Tu84_TQOlhc/lV0MdIq1HQAJ

My point is that introducing that support is counter productive. It is a
use case that only makes sense from a theoretical standpoint.
In practice, the industry consensus is that the only reasonable way to
handle the distinction between what is semantically considered "text" and
what is a "sequence of bytes" is by creating a strict type-safe firewall
between code that handles text and code that handles bytes.
Any library support that weakens that firewall not only is not useful
(since the network layer does need to be byte-by-byte precise), but it is
actually harmful (because it leads developers into thinking it's possible
to send "text" over a socket, when reality is way more complicated than
that).
Em sáb, 24 de set de 2016 22:07, Tom Honermann<EMAIL_ADDRESS>escreveu:

I agree that ensuring proper data boundaries in packet oriented protocols
is best practice. I think there will always be cases where that isn't
possible though. In those cases, the only solutions I've found so far are
for the iterator to throw an exception, block (on advancement of the
underlying code unit iterator), or the approach described in the first
comment of this issue.
The initial email thread where I requested feedback on text_view talked
about some of these options. You can find it at:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Tu84_TQOlhc/lV0MdIq1HQAJ
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tahonermann/text_view/issues/15#issuecomment-249398160,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAE9K3iJ8xC-7KZEN0babtqN4xeMl3WLks5qtddHgaJpZM4HaxGH
.

I think there are legitimate use cases.  People stream text across command line pipes all the time.  Granted, blocking and data loss tend not to be issues in those cases.
At any rate, addressing this issue is not high on my priority list.  This issue was opened due to concerns raised in the email thread mentioned in https://github.com/tahonermann/text_view/issues/15#issuecomment-249398160


bluetooth: controller: nrf: Provide info about used DPPI resources

Use common definitions of HAL_USED_PPI_CHANNELS and HAL_USED_PPI_GROUPS
macros that will provide (through z_bt_ctlr_used_nrf_ppi_* variables)
information about either PPI or DPPI (depending on the SoC) resources
used by the Bluetooth controller.
Update also the hal_nordic module revision, to make the related nrfx
allocator aware of those reserved DPPI resources.

@anangl please update to SHA

@carlescufi I think it would be good to have https://github.com/zephyrproject-rtos/zephyr/pull/30351 merged first, as it will generate a conflict in west.yml.

@carlescufi I think it would be good to have #30351 merged first, as it will generate a conflict in west.yml.

Yep, that's done now.

Rebased and updated with the proper SHA.


Added Lamp Effect Component

The transform: translateZ(1px) is the properties getting added to Spotlight and Glowing Light which should not be there.

Once this is resolved, the port will be ready for review.

@rahul-vashishtha Your problem it's a side effect of vueuse/motion as you mention, and I think for motion stuff it's better to use framework-agnostic library. Not only for motion but for every stuff that are browser native. Vueuse/motion is not so much active, so not good to include.
The code changes above are just an example with GSAP, but you could do the same with animate.js.

@nathan-de-pachtere I have removed the vueuse/motion and made the animation css only.
I'm thinking of removing vueuse/motion permanently from the project in near future as it creates a lot of issues with different components.

Super nice in CSS only ;)


From within Google Drive preferences it appears as though I could opt for "Mirror files" which sounds like it would create the typical local folder (/Volumes/GoogleDrive/My Drive), however, to save space on a laptop I'd strongly prefer not to:

Does NOT Exist: smb://localhost/Google Drive/My Drive

There’s your problem. You’re giving it a network address, but it requires a filesystem path. Your network directory will be mounted somewhere, probably under /Volumes. That’s the path you need to find.

which sounds like it would create the typical local folder (/Volumes/GoogleDrive/My Drive)

That’s what happens with Stream files too, that’s the whole use case of this Workflow. If you Mirror files you probably wouldn’t need it.


Scatter plot not properly scaling multiple plots

Issue: I have a pair of data sets that I need to display that are proper scatterplots, with a non-uniform time-based x-axis. I need to display both data sets on the same plot. Both start "near" the same time, but end at different times. Both plot individually just fine singly. However, when both are plotted together, the x-axis is only valid for the 2nd variable plotted, if either AutoScale() or DateTimeTicksBottom() are called between calls to Add.Scatter(). Workflow for this analyst visualization application requires adding an arbitrary number of data sets per single plot, so both are called to plot, scale, and render a scatter plot of a common phenomenon simultaneously.
ScottPlot Version: 5.0.37
Code Sample:
		double[] Values1 =
		{
			1,
			2,
			3,
			4,
			5
		};

		DateTime[] Dates1 =
		{
			new DateTime(2024, 5, 16, 9, 6,  20, 30),
			new DateTime(2024, 5, 16, 9, 7,  20, 30),
			new DateTime(2024, 5, 16, 9, 8,  20, 30),
			new DateTime(2024, 5, 16, 9, 9,  20, 30),
			new DateTime(2024, 5, 16, 9, 20, 20, 30)
		};

		double[] OATime1 =
		{
			Dates1[0].ToOADate(),
			Dates1[1].ToOADate(),
			Dates1[2].ToOADate(),
			Dates1[3].ToOADate(),
			Dates1[4].ToOADate()
		};

		double[] Values2 =
		{
			1,
			2,
			3,
			4,
			5,
			6,
			7,
			8,
			9,
			10
		};

		DateTime[] Dates2 =
		{
			new DateTime(2024, 5, 16, 9, 6, 20, 30),
			new DateTime(2024, 5, 16, 9, 7, 20, 30),
			new DateTime(2024, 5, 16, 9, 8, 20, 30),
			new DateTime(2024, 5, 16, 9, 9, 20, 30),
			new DateTime(2024, 5, 16, 9, 10, 20, 30),
			new DateTime(2024, 5, 16, 9, 11, 20, 30),
			new DateTime(2024, 5, 16, 9, 12, 20, 30),
			new DateTime(2024, 5, 16, 9, 13, 20, 30),
			new DateTime(2024, 5, 16, 9, 14, 20, 30),
			new DateTime(2024, 5, 16, 9, 15, 20, 30)
		};

		double[] OATime2 =

{
Dates2[0].ToOADate(),
Dates2[1].ToOADate(),
Dates2[2].ToOADate(),
Dates2[3].ToOADate(),
Dates2[4].ToOADate(),
Dates2[5].ToOADate(),
Dates2[6].ToOADate(),
Dates2[7].ToOADate(),
Dates2[8].ToOADate(),
Dates2[9].ToOADate()
};
		// Data Set 1
		Plot myPlot1 = new();
		myPlot1.Add.Scatter(OATime1, Values1);

		myPlot1.Axes.DateTimeTicksBottom();
		myPlot1.Axes.AutoScale();

		myPlot1.SavePng("Data1.png", 400, 300);

		// Data Set 2
		Plot myPlot2 = new();
		myPlot2.Add.Scatter(OATime2, Values2);

		myPlot2.Axes.DateTimeTicksBottom();
		myPlot2.Axes.AutoScale();

		myPlot2.SavePng("Data2.png", 400, 300);

		// Data Sets Combined Autoscale Only called

		Plot myPlot3 = new();

		myPlot3.Add.Scatter(OATime1, Values1);

		//myPlot3.Axes.DateTimeTicksBottom();
		myPlot3.Axes.AutoScale();

		myPlot3.Add.Scatter(OATime2, Values2);

		myPlot3.Axes.DateTimeTicksBottom();
		myPlot3.Axes.AutoScale();

		myPlot3.SavePng("Data3.png", 400, 300);

		// Data Sets Combined Ticks Only called

		Plot myPlot4 = new();

		myPlot4.Add.Scatter(OATime1, Values1);

		myPlot4.Axes.DateTimeTicksBottom();
		//myPlot4.Axes.AutoScale();

		myPlot4.Add.Scatter(OATime2, Values2);

		myPlot4.Axes.DateTimeTicksBottom();
		myPlot4.Axes.AutoScale();

		myPlot4.SavePng("Data4.png", 400, 300);

I wrote a workaround that added a state variable to bypass running the plot customizations after initially setting them. However, this results in no scaling on either the x or y axis upon refresh. Is it your intent that all data has to be loaded before scaling or setting time on the axis?


Skip running ESLint on ignored files

I started configuring vite-plugin-checker for one of my projects today, and I ran into the same issue described in #115. I'm not entirely clear why that issue was closed, as it seemed to me that vite-plugin-checker was still trying to lint ignored files, even in the latest release.
This PR updates the ESLint checker to resolve #115 more directly. Now, when a file changes, the plugin calls eslint.isPathIgnored to see if the file has been ignored in the ESLint config. This should avoid the warning.

@kylewlacy will it fix this issue?
 WARNING(ESLint)  File ignored because of a matching ignore pattern. Use "--no-ignore" to override. (undefined)

@Scanerrr Yes, it should fix that warning!

I'd love to see this get merged, nicely done @kylewlacy ! This is causing a lot of noise on my project.


[WIP] add bridge from Iterator to ParallelIterator

Half of https://github.com/rayon-rs/rayon/issues/46
This started getting reviewed in https://github.com/QuietMisdreavus/polyester/pull/6, but i decided to move my work to Rayon proper.
This PR adds a new trait, AsParallel, an implementation on Iterator + Send, and an iterator adapter IterParallel that implements ParallelIterator with a similar "cache items as you go" methodology as Polyester. I introduced a new trait because ParallelIterator was implemented on Range, which is itself an Iterator.
The basic idea is that you would start with a quick sequential Iterator, call .as_parallel() on it, and be able to use ParallelIterator adapters after that point, to do more expensive processing in multiple threads.
The design of IterParallel is like this:

IterParallel defers background work to IterParallelProducer, which implements UnindexedProducer.
IterParallelProducer will split as many times as there are threads in the current pool. (I've been told that https://github.com/rayon-rs/rayon/pull/492 is a better way to organize this, but until that's in, this is how i wrote it. >_>)
When folding items, IterParallelProducer keeps a Stealer from crossbeam-deque (added as a dependency, but using the same version as rayon-core) to access a deque of items that have already been loaded from the iterator.
If the Stealer is empty, a worker will attempt to lock the Mutex to access the source Iterator and the Deque.

If the Mutex is already locked, it will call yield_now. The implementation in polyester used a synchronoise::SignalEvent but i've been told that worker threads should not block. In lieu of https://github.com/rayon-rs/rayon/issues/548, a regular spin-loop was chosen instead.
If the Mutex is available, the worker will load a number of items from the iterator (currently (number of threads * number of threads * 2)) before closing the Mutex and continuing.
(If the Mutex is poisoned, the worker will just... stop. Is there a recommended approach here? >_>)

This design is effectively a first brush, has the same caveats as polyester, probably needs some extra features in rayon-core, and needs some higher-level docs before i'm willing to let it go. However, i'm putting it here because it was not in the right place when i talked to @cuviper about it last time.

I don't have any specific performance numbers for this on hand, at least not any that don't just count the thread-spawn/mutex-lock costs on a job that would be handled much better sequentially. Maybe i should borrow a task from one of the people that requested this, so i have a proper task to measure. :P

I'd love to review this too! I'm adding it to my calendar for later this week, so I can give it some time.

OK -- I reviewed this with @QuietMisdreavus. Looks pretty good! I think we should change the name, though I don't know what name I want. Maybe parallelize? adapt_into_par_iter? Something else? Maybe an RFC?! :)
Also, we added some benchmarks. We found that for nbody is was approx. the same as the traditional par iter, but for game of life is was radically slower. Meh.

@QuietMisdreavus @cuviper I'm sorry i'm super slow, but I'd like to see this land -- I think we had settle on something involving the word "bridge" for the name, right?
I was thinking that most of the iterator combinators (e.g., map) take fn(self) but are not named into. Perhaps we should follow suite here, and name this bridge_to_par_iter?

On gitter, the "bridge" ideas were into_par_bridge and into_par_bridge_iter.

I kinda like the idea of just par_bridge? There's a parallel with par_iter, but it's distinct enough to highlight that it's separate from other parallel iterators.

I've pushed a commit that renames the trait from AsParallel to ParallelBridge (and the method name from as_parallel to par_bridge). What do you think?

Time to cross this bridge... thanks!
bors r+


Upgraded the meshkit errors with the make error command

Signed-off-by: sayantan1413<EMAIL_ADDRESS>Description
Upgraded to the meshkit error
This PR fixes #113
Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

Is the error utility output going directly into the root folder? Let’s find another home for it, if so.

All greens build check marks! ✅

@DelusionalOptimist, does the forthcoming workflow place this output in a specific folder?

Yes, we're going with a new helpers directory for component_info and other files generated by the utility. The upcoming workflows will be similar to the one at https://github.com/layer5io/meshkit/blob/master/.github/workflows/error-ref-publisher.yaml and will abide by this.

The updated make targets would look somewhat like this then: https://github.com/layer5io/meshkit/blob/8577bc689c39420e58e39967abd1f4957d002d9a/Makefile#L10-L14

Hey @DelusionalOptimist @leecalcote what changes do I need to make here?

Good question. I’ll leave you in the capable hands of Mr. Pareek.

Hey @DelusionalOptimist the component_info.json is getting generated out the helpers directory .

Hey @DelusionalOptimist the component_info.json is getting generated out the helpers directory .

Yes @sayantan1413, you're right, I've been wondering the same.
@mgfeller the update command ignores the -i flag and creates a new component_info.json in the current directory. Is this expected behaviour?

Hey @DelusionalOptimist the component_info.json is getting generated out the helpers directory .

Yes @sayantan1413, you're right, I've been wondering the same.
@mgfeller the update command ignores the -i flag and creates a new component_info.json in the current directory. Is this expected behaviour?

@DelusionalOptimist @sayantan1413 no it isn't intended than way, it is a bug if it does, I have look.

Hey @DelusionalOptimist the component_info.json is getting generated out the helpers directory .

Yes @sayantan1413, you're right, I've been wondering the same.
@mgfeller the update command ignores the -i flag and creates a new component_info.json in the current directory. Is this expected behaviour?

@DelusionalOptimist @sayantan1413 no it isn't intended than way, it is a bug if it does, I have a look.

@DelusionalOptimist @sayantan1413 it is a bug. I'll fix it asap. Sorry about that.

@sayantan1413 @DelusionalOptimist please have a look here https://github.com/layer5io/meshkit/pull/85
would be nice if you could build and test locally gh pr checkout 85 then make  make build-errorutil
thanks!

Hey @mgfeller I tested this in my local machine and observed that the component_info.json file only remains in the helpers directory and is not generating outside the helpers directory anymore. @DelusionalOptimist what's your view on this?

Hey @DelusionalOptimist @mgfeller  layer5io/meshkit#85 got merged and after that I ran the command go get github.com/layer5io/meshkit/cmd/errorutil to get the latest version of it. But I am still facing the problem that the component_info.json file is getting generated outside the helpers directory. So can you have a look at this?

@sayantan1413 you'll have to wait for a new release of meshkit for go get github.com/layer5io/meshkit/cmd/errorutil to work here.
By default it gets you the latest tagged release which in this case doesn't contain the fix yet.
You can specify master branch like this:
go get github.com/layer5io/meshkit/cmd/errorutil@master but idk if its a good practice.

Yes @DelusionalOptimist it working perfectly now. But I have used go get github.com/layer5io/meshkit/cmd/errorutil@master to get the latest change so should I push my changes now or should I hold it for the next update for the errorutil and then upgrade it and push my changes then ?   // @mgfeller @leecalcote @kumarabd

Umm I missed this line For this PR just move it to helpers directory manually okay @DelusionalOptimist I will do it in that way for this PR.

@sayantan1413 there seems to be one dependency CI issue.

Yes @kumarabd but I think that due to any version problem ? Like I am getting confused about this error. So can anyone help me out how to solve it? // @DelusionalOptimist @mgfeller

Hey @kumarabd just a question that have you manually passed the failed CI issue or it passed on its own?


Fixes #2616. Support combining sequences that don't normalize

Fixes #2616 - Checks if the normalized string length is greater than 1 and adds it to the Contents.
Pull Request checklist:

[x] I've named my PR in the form of "Fixes #issue. Terse description."
[x] My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
[x] My code follows the Terminal.Gui library design guidelines
[x] I ran dotnet test before commit
[ ] I have made corresponding changes to the API documentation (using /// style comments)
[x] My changes generate no new warnings
[x] I have checked my code and corrected any poor grammar or misspellings
[x] I conducted basic QA to assure all features are working

PR to this PR incoming with suggested fixes to Unit Tests...

@tig I already finished this.

@tig I already finished this.

I don't think your test in TabView is working. Here's what it should look like:

Here's what I see:

Another test (in Unicode scenario):
sb.Append ('e');
sb.Append ('\u0301');
sb.Append ('\u0301');
testlabel = new Label ($"Should be an e with two accents: {sb}") { X = 20, Y = Pos.Y (label), Width = Dim.Percent (50), CanFocus = true, HotKeySpecifier = new Rune ('&') };
Win.Add (testlabel);

Perhaps we shouldn't try normalizing at all? Like this:

Re: NetDriver - I suspect Console.Write can't handle combining marks.

Perhaps we shouldn't try normalizing at all? Like this:

There is no problem on the AddRune because on the UpdateScreen I can get the correct string in the output variable,

Re: NetDriver - I suspect Console.Write can't handle combining marks.

Yes I believe is that.

Perhaps we shouldn't try normalizing at all? Like this:

There is no problem on the AddRune because on the UpdateScreen I can get the correct string in the output variable,

Do you have an objection to replacing the current code in this PR with the code I suggested above that removes the calls to normalize?

Do you have an objection to replacing the current code in this PR with the code I suggested above that removes the calls to normalize?

@tig did you already saw what it do? You are replacing the previous p

Do you have an objection to replacing the current code in this PR with the code I suggested above that removes the calls to normalize?

This is worst.

Absolute chaos.

@tig sorry but I don't have more head to handle with this. I think it's reasonable for now, attended to the difficult degree you added to this.

I dove in deep this morning and I think I understand how all this should work much better. I composed a message on my home computer but didn't have a chance to finish my thoughts before I had to run. As soon as I get home I'll finish it.
The net is: We can make combining marks work on both NetDriver and WindowsDriver, but the current design of AddRune/AddStr/UpdateScreen will not work. In addition TextFormatter (and others) are doing things in such a way that will not work.

Good info:

https://github.com/microsoft/terminal/issues/16132
https://github.com/microsoft/terminal/issues/8000

@tig try this code on WindowsDriver on the WriteToConsole method. It seems to support true color but I need help.
	[DllImport ("kernel32.dll", SetLastError = true)]
	//public static extern bool SetConsoleTextAttribute (IntPtr hConsoleOutput, CharacterAttributes wAttributes);
	public static extern bool SetConsoleTextAttribute (IntPtr hConsoleOutput, int wAttributes);

	public enum CharacterAttributes {
		FOREGROUND_BLUE = 0x0001,
		FOREGROUND_GREEN = 0x0002,
		FOREGROUND_RED = 0x0004,
		FOREGROUND_INTENSITY = 0x0008,
		BACKGROUND_BLUE = 0x0010,
		BACKGROUND_GREEN = 0x0020,
		BACKGROUND_RED = 0x0040,
		BACKGROUND_INTENSITY = 0x0080,
		COMMON_LVB_LEADING_BYTE = 0x0100,
		COMMON_LVB_TRAILING_BYTE = 0x0200,
		COMMON_LVB_GRID_HORIZONTAL = 0x0400,
		COMMON_LVB_GRID_LVERTICAL = 0x0800,
		COMMON_LVB_GRID_RVERTICAL = 0x1000,
		COMMON_LVB_REVERSE_VIDEO = 0x4000,
		COMMON_LVB_UNDERSCORE = 0x8000
	}

		if (force16Colors) {
			int i = 0;
			//CharInfo [] ci = new CharInfo [charInfoBuffer.Length];
			//foreach (ExtendedCharInfo info in charInfoBuffer) {
			//	ci [i++] = new CharInfo () {
			//		Char = new CharUnion () { UnicodeChar = info.Char },
			//		Attributes = (ushort)(((int)info.Attribute.Foreground.ColorName) | ((int)info.Attribute.Background.ColorName << 4))
			//	};
			//}

			//result = WriteConsoleOutput (_screenBuffer, ci, bufferSize, new Coord () { X = window.Left, Y = window.Top }, ref window);

			_stringBuilder.Clear ();

			//var csbi = new CONSOLE_SCREEN_BUFFER_INFOEX ();
			//csbi.cbSize = (uint)Marshal.SizeOf (csbi);
			//if (!GetConsoleScreenBufferInfoEx (_screenBuffer, ref csbi)) {
			//	var err = Marshal.GetLastWin32Error ();
			//	if (err != 0) {
			//		throw new System.ComponentModel.Win32Exception (err);
			//	}
			//}
			if (!SetCursorPosition (new Coord (0, 0))) {
				var err = Marshal.GetLastWin32Error ();
				if (err != 0) {
					throw new System.ComponentModel.Win32Exception (err);
				}
			}

			Attribute? prev = null;
			foreach (var ci in charInfoBuffer) {
				var attr = ci.Attribute;

				if (attr != prev) {
					prev = attr;
					if (!SetConsoleTextAttribute (_screenBuffer,
						(attr.Foreground.R + attr.Foreground.G + attr.Foreground.B & attr.Foreground.A) |
						(attr.Background.R + attr.Background.G + attr.Background.B & attr.Background.A))) {

						var err = Marshal.GetLastWin32Error ();
						if (err != 0) {
							throw new System.ComponentModel.Win32Exception (err);
						}
					}
				}

				if (!ci.Empty) {
					_stringBuilder.Append (ci.Char);
				}
			}

			//if (!SetCursorPosition (csbi.dwCursorPosition)) {
			//	var err = Marshal.GetLastWin32Error ();
			//	if (err != 0) {
			//		throw new System.ComponentModel.Win32Exception (err);
			//	}
			//}

			string s = _stringBuilder.ToString ();

			result = WriteConsole (_screenBuffer, s, (uint)(s.Length), out uint _, null);

@tig try this code on WindowsDriver on the WriteToConsole method. It seems to support true color but I need help.

Happy to. May be a few days though.
I'm not seeing how this is relevant to combining sequences though. Can you explain?

No it's not. Forget.

Combining Marks have GetColumns() == 0
TextFormatter.Draw is currently doing var runeWidth = Math.Max (rune.GetColumns (), 1); and thus incrementing the column when a combining mark is encountered.
AddRune always assumes a combining mark is 0 width and should be combined with the preceding Cell (unless Col == 0).
AtlasEngine (Console.Write("a\u0301\u0301")) DOES render multiple CMs correctly.

However, it ALSO moves the cursor to the right for each CM. Thus Console.Write("a\u0301\u0301\u0328x") results in:

Note, this is the same thing you see with echo "[au{0301}u{0301}x]":

If I SetCursorPostion() to the row/col to just to the right of the a, WT 'forgets' the CM.
In otherwords, internally AtlasEngine is holding each CM as a used column.

AtlasEngine also, treats individual CMs (Console.Write("\u0301")) as 1 column width glyphs if in the 1st column.

Unless, I'm missing something, until AtlasEngine changes, on Windows, we cannot really support NON-NORMALIZED combining marks in a way that users would expect. Any glyph made up of a base char and n or more combining chars will use base.ColumnWidth() + n columns.
I think for us to support combining marks correctly we need to do the following:

Always try to normalize. This at least lets the most common combining mark use-case (base + 1 CM) work in many cases.
Have ConsoleDriver.AddRune treat a combining mark as a 1 column wide glyph. E.g. if rune.IsCombiningMark() == true then ConsoleWidth == 1.
Have ConsoleDriver.AddStr enumerate the runes in str and add them to ConsoleDriver.Contents such that Cell.CombiningMarks is setup correctly (if str[0] is a CM, special case).
Drivers' UpdateScreen

treat any Cell.Rune.IsCombiningMark() == true as taking 1 column.
use Cell.Rune.CombiningMarks().Count > 0 to append the marks to output.

Please see my PR to this PR: https://github.com/BDisp/Terminal.Gui/pull/162
I do not think #2616 can be fixed at this time. I think the best we can do is basically ignore CMs that can't be normalized. My PR to your PR does this.

Please see my PR to this PR: BDisp#162
I do not think #2616 can be fixed at this time. I think the best we can do is basically ignore CMs that can't be normalized. My PR to your PR does this.

Done @tig. Thanks.

@tig why you write u301 twice here \u0301\u0301\u0328?

@tig why you write u301 twice here \u0301\u0301\u0328?

It was just an example of 3 CMs.

@tig why you write u301 twice here \u0301\u0301\u0328?

It was just an example of 3 CMs.

I see. For have sure it could be normalized. You don't know if there is 3 different combining marks that can normalize on terminal? It would be better.

@tig why you write u301 twice here \u0301\u0301\u0328?

It was just an example of 3 CMs.

I see. For have sure it could be normalized. You don't know if there is 3 different combining marks that can normalize on terminal? It would be better.

\u0301\u0301\u0328 will not normalize! It results in

e\u0301\u0301\u0328 will not normalize. It results in:

You can pile on as many \u0301 as you want:


Resnet model

@darsnack

[x] added model
[x] added test
[ ] resolve test errors
I am getting the following errors while testing FluxModels

AlexNet: Error During Test at /home/nabanita07/FluxModels.jl/test/VisionModel/alexnet.jl:5
  Got exception outside of a @test
  UndefVarError: AdaptiveMeanPool not defined
  Stacktrace:
   [1] alexnet() at /home/nabanita07/FluxModels.jl/src/VisionModel/alexnet.jl:4
   [2] top-level scope at /home/nabanita07/FluxModels.jl/test/VisionModel/alexnet.jl:6
   [3] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/Test/src/Test.jl:1113
   [4] top-level scope at /home/nabanita07/FluxModels.jl/test/VisionModel/alexnet.jl:6
   [5] include(::String) at ./client.jl:439
   [6] top-level scope at /home/nabanita07/FluxModels.jl/test/runtests.jl:6
   [7] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/Test/src/Test.jl:1113
   [8] top-level scope at /home/nabanita07/FluxModels.jl/test/runtests.jl:6
   [9] include(::String) at ./client.jl:439
   [10] top-level scope at none:6
   [11] eval(::Module, ::Any) at ./boot.jl:331
   [12] exec_options(::Base.JLOptions) at ./client.jl:264
   [13] _start() at ./client.jl:484

ResNet: Error During Test at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:5
  Got exception outside of a @test
  UndefVarError: inplanes not defined
  Stacktrace:
   [1] resnet(::typeof(FluxModels.VisionModel.basicblock), ::Symbol, ::Array{Int64,1}, ::Array{Int64,1}) at /home/nabanita07/FluxModels.jl/src/VisionModel/resnet.jl:37
   [2] ResNet18() at /home/nabanita07/FluxModels.jl/src/VisionModel/resnet.jl:78
   [3] macro expansion at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:13 [inlined]
   [4] macro expansion at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/Test/src/Test.jl:1113 [inlined]
   [5] top-level scope at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:6
   [6] include(::String) at ./client.jl:439
   [7] top-level scope at /home/nabanita07/FluxModels.jl/test/runtests.jl:7
   [8] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/Test/src/Test.jl:1113
   [9] top-level scope at /home/nabanita07/FluxModels.jl/test/runtests.jl:6
   [10] include(::String) at ./client.jl:439
   [11] top-level scope at none:6
   [12] eval(::Module, ::Any) at ./boot.jl:331
   [13] exec_options(::Base.JLOptions) at ./client.jl:264
   [14] _start() at ./client.jl:484

I tried adding the current master version of Flux but it show the error which I have mentioned on discourse. https://discourse.julialang.org/t/flux-master-is-incompatible-with-geometricflux/43404

alexnet test passed, showing errors for resnet. will fix it.
┌ Warning: Slow fallback implementation invoked for conv!  You probably don't want this; check your datatypes.
│   yT = Float64
│   T1 = Float64
│   T2 = Float32
└ @ NNlib ~/.julia/packages/NNlib/sSn9M/src/conv.jl:206
┌ Warning: Slow fallback implementation invoked for conv!  You probably don't want this; check your datatypes.
│   yT = Float64
│   T1 = Float64
│   T2 = Float32
└ @ NNlib ~/.julia/packages/NNlib/sSn9M/src/conv.jl:206
┌ Warning: Slow fallback implementation invoked for conv!  You probably don't want this; check your datatypes.
│   yT = Float64
│   T1 = Float64
│   T2 = Float32
└ @ NNlib ~/.julia/packages/NNlib/sSn9M/src/conv.jl:206
┌ Warning: Slow fallback implementation invoked for conv!  You probably don't want this; check your datatypes.
│   yT = Float64
│   T1 = Float64
│   T2 = Float32
└ @ NNlib ~/.julia/packages/NNlib/sSn9M/src/conv.jl:206
┌ Warning: Slow fallback implementation invoked for conv!  You probably don't want this; check your datatypes.
│   yT = Float64
│   T1 = Float64
│   T2 = Float32
└ @ NNlib ~/.julia/packages/NNlib/sSn9M/src/conv.jl:206
ResNet: Error During Test at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:5
  Got exception outside of a @test
  UndefVarError: inplanes not defined
  Stacktrace:
   [1] resnet(::typeof(FluxModels.VisionModel.basicblock), ::Symbol, ::Array{Int64,1}, ::Array{Int64,1}) at /home/nabanita07/FluxModels.jl/src/VisionModel/resnet.jl:37
   [2] ResNet18() at /home/nabanita07/FluxModels.jl/src/VisionModel/resnet.jl:78
   [3] macro expansion at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:13 [inlined]
   [4] macro expansion at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/Test/src/Test.jl:1113 [inlined]
   [5] top-level scope at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:6
   [6] include(::String) at ./client.jl:439
   [7] top-level scope at /home/nabanita07/FluxModels.jl/test/runtests.jl:7
   [8] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/Test/src/Test.jl:1113
   [9] top-level scope at /home/nabanita07/FluxModels.jl/test/runtests.jl:6
   [10] include(::String) at ./client.jl:439
   [11] top-level scope at none:6
   [12] eval(::Module, ::Any) at ./boot.jl:331
   [13] exec_options(::Base.JLOptions) at ./client.jl:264
   [14] _start() at ./client.jl:484

Test Summary: | Pass  Error  Total
Vision Models |    1      1      2
  AlexNet     |    1             1
  ResNet      |           1      1
ERROR: LoadError: Some tests did not pass: 1 passed, 0 failed, 1 errored, 0 broken.
in expression starting at /home/nabanita07/FluxModels.jl/test/runtests.jl:5
ERROR: Package FluxModels errored during testing

inplanes is defined and I am not sure why it is throwing up an error.

ResNet: Error During Test at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:6
  Test threw exception
  Expression: (size(ResNet18(rand(256, 256, 3, 50))) == (1000, 50), #= /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:7 =# @test((size(ResNet34(rand(256, 256, 3, 50))) == (1000, 50), #= /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:8 =# @test((size(ResNet50(rand(256, 256, 3, 50))) == (1000, 50), #= /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:9 =# @test((size(ResNet101(rand(256, 256, 3, 50))) == (1000, 50), #= /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:10 =# @test(size(ResNet152(rand(256, 256, 3, 50))) == (1000, 50)))))))))
  MethodError: no method matching ResNet18(::Array{Float64,4})
  Closest candidates are:
    ResNet18() at /home/nabanita07/FluxModels.jl/src/VisionModel/resnet.jl:78
  Stacktrace:
   [1] top-level scope at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:6
   [2] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/Test/src/Test.jl:1113
   [3] top-level scope at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:6

Test Summary: | Pass  Error  Total
Vision Models |    1      1      2
  AlexNet     |    1             1
  ResNet      |           1      1
ERROR: LoadError: Some tests did not pass: 1 passed, 0 failed, 1 errored, 0 broken.
in expression starting at /home/nabanita07/FluxModels.jl/test/runtests.jl:5
ERROR: Package FluxModels errored during testing

This is the final error. I guess something like ResNet18(inplanes, outplanes, ...) might fix this.

Now, there is a method mismatch error. I haven't changed to Float32 in test/VisionModel/resnet.jl.
ResNet: Error During Test at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:8
  Test threw exception
  Expression: size(m(rand(256, 256, 3, 50))) == (1000, 50)
  MethodError: no method matching (::Chain{Tuple{Conv{2,4,typeof(identity),Array{Float32,4},Array{Float32,1}},BatchNorm{typeof(relu),Array{Float32,1},Array{Float32,1},Float32}}})(::Array{Float64,4}, ::Array{Float64,4})
  Closest candidates are:
    Any(::Any) at /home/nabanita07/.julia/packages/Flux/IjMZL/src/layers/basic.jl:38
  Stacktrace:
   [1] (::SkipConnection)(::Array{Float64,4}) at /home/nabanita07/.julia/packages/Flux/IjMZL/src/layers/basic.jl:259
   [2] applychain(::Tuple{SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,AdaptiveMeanPool{4,2},typeof(flatten),Dense{typeof(identity),Array{Float32,2},Array{Float32,1}}}, ::Array{Float64,4}) at /home/nabanita07/.julia/packages/Flux/IjMZL/src/layers/basic.jl:36 (repeats 4 times)
   [3] (::Chain{Tuple{Conv{2,2,typeof(identity),Array{Float32,4},Array{Float32,1}},BatchNorm{typeof(relu),Array{Float32,1},Array{Float32,1},Float32},MaxPool{2,2},SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,SkipConnection,AdaptiveMeanPool{4,2},typeof(flatten),Dense{typeof(identity),Array{Float32,2},Array{Float32,1}}}})(::Array{Float64,4}) at /home/nabanita07/.julia/packages/Flux/IjMZL/src/layers/basic.jl:38
   [4] macro expansion at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:8 [inlined]
   [5] macro expansion at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/Test/src/Test.jl:1113 [inlined]
   [6] top-level scope at /home/nabanita07/FluxModels.jl/test/VisionModel/resnet.jl:6

Okay I fixed ResNet18. Can I have write permissions to your fork? It will be easier for me to push a commit and explain.

Surprisingly, there are no official implementations of Option A from the paper online (source). Whenever the dimensions change, the width/height are halved and the # of channels doubles. For Option B and C, this is not an issue, because the projection shortcut is used. For Option A, this was an issue with our implementation, because even though we use cat to match the channels, the width/height would still be off. The only solution I found (in the link above) is to pool the shortcut input before padding with zeros.
There were some other issues with basic block and bottleneck too. Here's the list of things I changed:

Added a missing pad = 1 to basic block so that it preserves the width/height
Updated identity to pool to halve width/height then cat to add channels
Updated resnet to not downsample on the very first set of repeated blocks, since the downsampling is handled by the initial max pooling
Updated AlexNet test to use Float32 since the fallback CPU conv! is very slow

There are still issues with ResNet50+ which use Option B. Instead of fixing those, I am going to explain my debug workflow, and you can try and debug+fix the remaining test failures. I saw you added print statements in resnet which is good, but these will only execute during the model building stage (i.e. when you call model = ResNet18()). They won't tell you the dynamic size information as the input passes through the network. The strategy below is what I used to do that. It isn't the only way to debug in Flux, but it was what was useful for this error.
Pre-requisite: I used Revise.jl to be able to quickly iterate as I fixed errors. You should install Revise.jl in your global environment (not within FluxModels.jl).

First, run ]test FluxModels to see what tests are failing. Pick a specific test case to fix (here I will assume ResNet18 is failing).
Next, open up a fresh Julia REPL in the project root directory with julia --project=..
Start Revise: using Revise, then import FluxModels: using FluxModels.
Instantiate the model to debug: model = ResNet18()
Create a dummy input: x = rand(Float32, 224, 224, 3, 50); (here I used a 224x224 image because that's what's used in the paper, so matching the input sizes allows me to compare against Table 1 in the paper).
Pass the input through the model layer by layer, printing debug info as you go. Here is what I typed into the REPL to do that:

julia> for (i, layer) in enumerate(model)
       println("Layer $i ($(typeof(layer)))")
       println("insize: $(size(x))")
       global x = layer(x)
       println("outsize: $(size(x))")
       println()
       end

This prints out debug info like so:
Layer 1 (Conv{2,2,typeof(identity),Array{Float32,4},Array{Float32,1}})
insize: (224, 224, 3, 50)
outsize: (112, 112, 64, 50)

Layer 2 (BatchNorm{typeof(relu),Array{Float32,1},Array{Float32,1},Float32})
insize: (112, 112, 64, 50)
outsize: (112, 112, 64, 50)

Layer 3 (MaxPool{2,2})
insize: (112, 112, 64, 50)
outsize: (56, 56, 64, 50)

Layer 4 (SkipConnection)
insize: (56, 56, 64, 50)
ERROR: DimensionMismatch("dimensions must match: a has dims (Base.OneTo(27), Base.OneTo(27), Base.OneTo(64), Base.OneTo(50)), b has dims (Base.OneTo(56), Base.OneTo(56), Base.OneTo(64), Base.OneTo(50)), mismatch at 1")
Stacktrace:
 [1] promote_shape at ./indices.jl:178 [inlined]
 [2] promote_shape(::Array{Float32,4}, ::Array{Float32,4}) at ./indices.jl:169
 [3] +(::Array{Float32,4}, ::Array{Float32,4}) at ./arraymath.jl:45
 [4] (::SkipConnection)(::Array{Float32,4}) at /Users/darsnack/.julia/packages/Flux/IjMZL/src/layers/basic.jl:259
 [5] top-level scope at ./REPL[15]:4
 [6] eval(::Module, ::Any) at ./boot.jl:331
 [7] eval_user_input(::Any, ::REPL.REPLBackend) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:86
 [8] run_backend(::REPL.REPLBackend) at /Users/darsnack/.julia/packages/Revise/tV8FE/src/Revise.jl:1165
 [9] top-level scope at REPL[2]:0

Fix the first layer whose output isn't right. In my case, I saw that Layer 4 was wrong. I see that the input size to Layer 4 is 56 x 56 x 64 x 50 which is correct according to Table 1. Keep in mind that even though the error may be in Layer 4, it could be because you passed in an input whose size is not correct. (If it is not correct, then double check the previous layers' output sizes to see which prior layer screwed up). From the stack trace, I can see that I am trying to add a 27 x 27 x 64  x 50 array to a 56 x 56 x 64 x 50 (this is x and y from the identity shortcut). I know from Table 1 that x should be 28 x 28 x 64 x 50. This led me to the first fix which was adding the correct padding to basicblock which controls the size of x. I also see that y needs to be downsampled, leading me to add the pooling operation to identity.
Implement the fixes and repeat Steps 4-8 (since you are using Revise, after saving the source file, you should see the changes).
Once you successfully get through Steps 4-8 w/o errors, go back to Step 1 and repeat the entire process for the next test that you want to fix.

I can't see your changes made nor in my branch of my fork or here.

Wait so can you see them? They show up for me.

Finally all resnet models are working.

It can be merged now, right?/

Yes there is no need for code changes, but I am trying to get the CI to work before merging

Can I help? and how?

It's an error with a pointer conversion in LLVM.jl. There's a PR to that repo to fix it, but I'm just ignoring 32-bit machines for now in the CI.


HBASE-23019 Handle --skip-errorprone on branch-1

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

:blue_heart:
reexec
0m 45s
Docker mode activated.

_ Prechecks _

:green_heart:
dupname
0m  0s
No case conflicting files found.

:blue_heart:
shelldocs
0m  0s
Shelldocs was not available.

:green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-1 Compile Tests _

:blue_heart:
mvndep
5m 53s
Maven dependency ordering for branch

_ Patch Compile Tests _

:blue_heart:
mvndep
0m 12s
Maven dependency ordering for patch

:broken_heart:
shellcheck
0m  0s
The patch generated 3 new + 30 unchanged - 1 fixed = 33 total (was 31)

:green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

_ Other Tests _

:blue_heart:
asflicense
0m  0s
ASF License check generated no output?

8m  6s

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-620/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/620

Optional Tests
dupname asflicense shellcheck shelldocs

uname
Linux 204ca1d5ad03 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-620/out/precommit/personality/provided.sh

git revision
branch-1 / 72ea366

shellcheck
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-620/1/artifact/out/diff-patch-shellcheck.txt

Max. process+thread count
52 (vs. ulimit of 10000)

modules
C:  U:

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-620/1/console

versions
git=1.9.1 maven=3.0.5 shellcheck=0.4.7

Powered by
Apache Yetus 0.11.0 https://yetus.apache.org

This message was automatically generated.

+1 and thanks!


[WIP] ✨ Add DockerMachine.Spec.CustomImage for customizing the container image the node runs

What this PR does / why we need it:
This enables the customization of the container image that is used for running a given DockerMachine instance. This is useful in situations where you'd like to customize the node image in some way to better suit your needs.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
Release note:

/ok-to-test
looking very nice

/lgtm

I believe this is good to go, I've done a good bit of testing locally and things look good.

/approve


Another SSG-EG quirk?

With this .vgm:
https://deflemask.com/ssgeg_issue_10.vgm
Sometimes ymfm is doing an attack of the SSG-EG where NUKED/HW seems not doing so: https://deflemask.com/ssgeg_issue_10.png
On nuked you will hear only some little "pock" sounds always (it sounds like filling a glass with water), ymfm sounds like an alarm.
https://deflemask.com/ssgeg_issue_10_ymfm.wav
https://deflemask.com/ssgeg_issue_10_nuked.wav
I say "sometimes" because 5 seconds ago I have triggered the same .vgm and I have heard a more accurate version on YMFM.
This one: https://deflemask.com/ssgeg_issue_10_ymfm_2.wav
I'm really confused here.
Do you get the second version 100% of the time? I'm trying here to be sure if this is a bug in the emulation or in my implementation.

Interesting. My VGM renderer, which can run ymfm and nuked side-by-side, only produces the "alarm" version, but nuked sounds the same. I don't get the "pock" sounds out of nuked.
https://aarongiles.com/for/github/issue10-ymfm.wav
https://aarongiles.com/for/github/issue10-nuked.wav

Interesting indeed... If you got those results this seems to be a timing issue.
I'm using VGMPlay with Nuked to play the vgms: https://github.com/vgmrips/vgmplay (I always get the "pock" version there on https://deflemask.com/ssgeg_issue_10.vgm)
But on my tracker I get mostly the "pock" version and in some cases the "alarm" version (~90% vs ~10% ration)
I did a vgm which triggers 8 consecutive notes and some of them are with the "pock" and others with the "alarm", even with Nuked on VGMPlay:
https://deflemask.com/ssgeg_issue_10_repeat.vgm
https://deflemask.com/ssgeg_issue_10_ymfm_repeat.wav
Could you please tell me if you get the "pock" version here?
On Nuked I get the first note and the third note with the "alarm" shape and the rest with "pock". On my tracker this is random but seems to be ok then.

Huh. On that one I get alternating alarm/pock on ymfm, but just a single alarm on nuked followed by all pock:
https://aarongiles.com/for/github/issue10-repeat-ymfm.wav
https://aarongiles.com/for/github/issue10-repeat-nuked.wav

Interesting... I’m wondering now if this is intended behavior. Nuked seems to be, at least, consistent in the order of those different types of envelopes.
On my tracker I get a completely random order. I’m trying to find the way to avoid that in order to get deterministic songs.

Just to add more info. News from the hardware:
https://deflemask.com/ssgeg10_2_hardware.wav
https://deflemask.com/ssgeg10_2_ymfm.wav
https://deflemask.com/ssgeg10_2.vgm
Apparently this behavior of switching envelopes (alarm and pock) is right! I can't understand when and why this is happening however. I get random switching in ymfm, that's the only difference. Hardware and nuked seems to be more predictable.

Ok, spent some good time with this issue again today. The problem is as follows:
With SSG enabled, if the envelope attenuation becomes greater than 0x200 and we're in release mode, then the attenuation is set to maximum (0x3FF). Both ymfm and nuked have this logic.
As you suspected, the issue is timing. Due to nuked emulating the pipelining in the chip, the effects of key on/off events are delayed relative to ymfm's implementation.
In this particular case, when a the key off comes, one of the operators is in attack mode with almost maximum envelope (0x00E in the case I'm looking at), but with output inverted. When the key off arrives, the SSG inversion stops, but the level is snapped to the inverted level, which is 0x200 - 0x00E, or 0x1F2. At this point, the release starts incrementing the envelope.
Now, if the new key on is processed BEFORE the release reaches 0x200, then the new attack will start from close to 0x200 and start decreasing with the attack rate. However, if the key on arrives AFTER the release reaches 0x200, then the envelope is snapped down to 0x3FF and the attack starts from ground zero.
I've thought of a couple of hacks to potentially fix this, but it's just going to alter the timing a hair, and it wouldn't take much to cause the behavior to happen differently. I'll give this another day's thought, but am inclined to close this as a "won't fix" issue.

What do you mean by "it doesn't have this issue?" Do you mean it behaves like hardware or like nuked or some differences between the two? ;)

Sorry, I mean the old MAME core behaves in a "deterministic" way. The issue (at least on my case in DefleMask Tracker) is that a song with YMFM will sound different each time you play it.

What's your timing model like? Is it guaranteed that you will issue all register writes at the exact same time, relative to the number of clock() calls, on each run? If so, ymfm should be 100% deterministic. If you have a non-deterministic case, maybe you could generate a log of all the write/clock/output calls made to ymfm (text file would be fine) so that I can write code to replay them in order.

Ok, I tried a bunch of different ways to make ymfm align with nuked, and it comes down to the envelope generator clock. This clock runs at 1/3 of the sample rate, and the output for edge cases like this strongly depends on which of the 3 cycles your key-ons and other writes happen.
To prove this, I modified my vgmplayer to generate 0, 1, or 2 samples of output (24 nuked clocks) after reset. These extra samples move the starting position of the writes relative to the envelope clock. As you can see from the resulting wav files, each result is different:
https://aarongiles.com/for/ymfm/nuked-offs0.wav
https://aarongiles.com/for/ymfm/nuked-offs1.wav
https://aarongiles.com/for/ymfm/nuked-offs2.wav
The tests you have provided are highly sensitive to precisely where in the envelope sequence the writes arrive. If you always guarantee the same number of clocks prior to playback of a sequence, the result should be identical. But if you allow the system to free-run the clocks prior to the start of execution, then you will get random behavior on this sequence depending on how many clocks have happened since the last reset.


Tracking: improve scan_range

[ ] support multiple ranges. e.g., select from table where x > 10 or x < 5, and in
[ ] store Datum with the correct data type instead of expr. But maybe we need constant folding  first.

[ ] support constant expression instead of only literal expression
[ ] do not cast in executor (workaround in https://github.com/singularity-data/risingwave/pull/3470)

Alternatively maybe we can use a cast on Datum in fe, which doesn't need constant folding

related: #3479

To calculate the vnodes to prune paritition (https://github.com/singularity-data/risingwave/issues/3450), we have to store evaluated Datum in scan_range 🤔


Update courses section

Broken link removed (503 Service unavailable)
Add new course about Meteor and Vue

thanks @diavrank !


SwitchAnalyzer - fix for semicolon after case/default

See the test cases "two case and default with semicolon instead of colon" and "alternative syntax nested with mixed colon/semicolon".

Thank you @kubawerlos.


Added an permanent discord invite link

Thank you for the contribution. I am going to close it has been fixed


Variable terrain is referenced before assignment

I get the error:
            tiles[id_] = objects.Tile(
                id_=id_,
                type_=_type,
>               terrain=terrain,
                animation=animation,
                image=image,
                properties=properties,
                tileset=None,
            )
E           UnboundLocalError: local variable 'terrain' referenced before assignment

..\..\..\pytiled_parser\pytiled_parser\xml_parser.py:542: UnboundLocalError

I'm like 90% sure this is a problem with earlier versions of the typing library. I will have to look for other instances of this issue and set up testing for it

Irrelevant as of the new v1.0.0 JSON re-write that was just released.


No reply to commands for ttyd running at win10

Describe the bug

install ttyd with scoop. Run it with 'ttyd -p 8080 cmd'
go to http:ip/8080
see the cmd prompt
try to enter any command
nothing is happened

Expected behavior
Keypresses must be displayed, commands must be entered
*Environment:
ttyd:
ttyd 1.7.4-fa1ee59 (libwebsockets 4.3.2-unknown)

ttyd OS:
Microsoft Windows [Version 10.0.19043.1052]

Browser:
Crome Version 121.0.6167.85 (Official Build) (64-bit)

Browser OS:
Ubuntu x86_64 22.04.3 LTS (Jammy Jellyfish)

Read the changelog: https://github.com/tsl0922/ttyd/releases/tag/1.7.4
Also, check log message:
N: The --writable option is not set, will start in readonly mode

-W did the trick ! 🙈


Make the plot sizes use numbers underneath

Part of #2585
https://user-images.githubusercontent.com/3683420/195160042-4216a646-bf95-4462-b474-2839c9e478ce.mov

Will wait to merge until more work for the grid is lined up


Add option to invoke Callback URL each time a GovernanceProcesses outcome changes

In combination with https://github.com/metagov/metagov-prototype/issues/19, we can support Drivers that want to communicate exclusively via hooks. Right now some GovernanceProcesses require the Driver to be able to poll Metagov for changes to GovernanceProcesses, which means the Driver needs to have some scheduler.

Closed with https://github.com/metagov/metagov-prototype/pull/42. Callback URLs are invoked any time the outcome changes.


AirspeedVelocity.jl CI + Benchmarks

Just so we can monitor that the macro itself stays speedy and also that load time doesn't increase (especially for default_mode="disable" which people will use in packages)

coverage: 100.0%. remained the same
when pulling f5f2adb27cdf1eb7ea9e269933af5fff31c8c4d3 on asv
into 167412f19a7ca6dd4aeb82006572230e46b32021 on main.


maestral-gui: 1.6.5 -> 1.7.0

Description of changes
https://github.com/samschott/maestral/releases/tag/v1.7.0
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 218208 run on x86_64-linux 1

3 packages built:

maestral (python310Packages.maestral)
maestral-gui
python311Packages.maestral

1.7.1 was just released with a fix for darwin.

Updated to 1.7.1.

Result of nixpkgs-review pr 218208 run on x86_64-linux 1

3 packages built:

maestral (python310Packages.maestral)
maestral-gui
python311Packages.maestral


Sending a reply with original email content quoted below

Issue Summary
I'm trying to send a reply as a thread, where the original email content is quoted below the reply content (as a standard email reply has).
Following https://github.com/sendgrid/sendgrid-nodejs/issues/482#issuecomment-641747083 and https://github.com/sendgrid/sendgrid-nodejs/issues/690#issuecomment-393336215 I have been able to create reply (which is successfully grouped as a thread) but the reply email itself doesn't include the previous email content as quoted content.
As there is a lack of documentation for replying in general I am unsure how to achieve this?
Steps to Reproduce

Use Inbound Parse to post RAW message content to API endpoint
Use simpleParser to parse email content
Send reply as snippet below
Reply is received but doesn't include the original email content as quoted content.

Code Snippet
  const parsedEmail = await simpleParser(req.body.email);
  const msg = {
    to: parsedEmail.from?.text,
    headers: {
      References: `${parsedEmail.references} ${parsedEmail.messageId}`,
      'In-Reply-To': parsedEmail.messageId,
    },
    from<EMAIL_ADDRESS>// actual email removed for the purposes of this snippet
    subject: `Re: ${parsedEmail.subject}`, // where subject is the sender's subject.
    text: 'This is the reply from SendGrid',
  };

Technical details:

sendgrid-nodejs version: 7.4.2
node version: 14.16.0

Hello @SKempin,
Thanks for submitting a GitHub issue! We are very sorry that you are running into this problem. In order to better serve you, as this does not present itself as a library specific issue, we would like to ask that you reach out to our support team at https://support.sendgrid.com.
Thank you!
SendGrid DX Team

@thinkingserious I submitted this as an issue but the team was unable to support. Is this not possible to achieve?

For anyone looking for this behaviour I was able to emulate the formatting by wrapping the content in block quotes:

   On ${datestamp}, at ${timestamp}, ${from} wrote:

${originalEmailContent}