Provide a way to do bit grooming before compression

In the NOAA GFS data files they are doing something neat to get better compression.
For this to work, all we need to know is the number of bits. So we could have:
nc_def_var_smoothing(ncid, varid, nbits);
to turn this on.
For some code from Jeff Whitaker see #1543. (They call this "quantizing" and maybe that's a better name. I'm not sure if "smoothing" is correct.)
This is part of #1545

I support adding lossy compression to netCDF. However, bit smoothing is sub-optimal because it always rounds down. Bit Grooming alternately rounds up (to 1s) and down (to 0s) which reduces the statistical biases of rounding by orders of magnitude. See the comparisons in:
Zender, C. S. (2016), Bit Grooming: Statistically accurate precision-preserving quantization with compression, evaluated in the netCDF Operators (NCO, v4.4.8+), Geosci. Model Dev., 9, 3199-3211, doi:10.5194/gmd-9-3199-2016.

@czender excellent point! And great reference.
I propose to add this to netcdf-c after the agu. I am thinking of the following functions:
nc_def_var_quantize(ncid, varid, nbits)
nc_inq_var_quantize(ncid, varid, &nbits_in)
These would only apply to NC_DOUBLE and NC_FLOAT, calling with any other type will return an error.
nc_def_var_quantize() will add an attribute _netcdf_nbits=12 for example.
Some things to note:

The savings in file size can be enormous.
NOAA GFS is already doing this; other model teams also are or will be. This will be popular.
This is fully backward compatible (as not all our new compression features will be).

You are welcome to use the NCO code lines 576--860 (not all are necessary) of https://github.com/nco/nco/tree/master/src/nco/nco_ppc.c

@czender I was already planning to steal your code. ;-)

Tagging in @lesserwhirls and @DennisHeimbigner to this discussion, so that we can consider the potential impact on NetCDF java as well. Adding the FORTRAN and C++ interfaces shouldn’t be a problem.

This will have no impact on Java, because the files can be read in the normal way.
If netCDF-Java would also like to add this feature, that is of course possible. I would not hold back the rest of the netCDF community while waiting for Java.
I will add these calls to the Fortran APIs as well; just forgot to mention it, but of course we want both the F77 and F90 APIs to fully reflect the C API.

Also would welcome input from @jswhit and @gsjaardema on this issue...

I assume we’re talking about something like this?
https://www.unidata.ucar.edu/blogs/developer/en/entry/compression_by_bit_shaving
We don’t have a way of doing this (writing) via the netCDF-Java API currently, but would be easy to add (have code in our tests). Could also tie in to whatever the C library ends up doing since we use the C library for writing. Reading won’t be an issue.
One question though - what would a variable look like? How would nbits be encoded? Would it be exposed as an attribute (so a need to update the NUG)?
No technical concerns from a netCDF-Java point of view, but thank you @WardF for even asking the question. Surprises are never fun :-)

@lesserwhirls this is part of a larger discussion about netcdf-c and compression. See #1545
I was going to ask if netcdf-java is now using the C library. You say for writing only? Why is that? Why not read as well as write?

@lesserwhirls no problem, I don't want to (potentially) add to your roadmap/workload without at least waving in your direction first ;).
No particular hurry on this; when lossy compression has come up in meetings or at conferences, the scientists have expressed their... hesitancy to truncate any of their data, even when it objectively contains no information.  The lack of people asking for it makes it a relatively low priority internally, but adding support through a PR contribution is effort I can justify ;).   Anyways, back to prepping for AGU. Thanks all!

@lesserwhirls this is part of a larger discussion about netcdf-c and compression. See #1545
I was going to ask if netcdf-java is now using the C library. You say for writing only? Why is that? Why not read as well as write?

Note: this was all done before my time, but here is my take.
Writing because, I think, the HDF documentation was too unclear regarding how writing is to be done (for example, chunking, VLEN, I think?) to support all of the features needed to write netCDF-4. We'd need to rope in John Caron for the details.
In terms of reading, we do support reading through the C library, but it's not threads safe (we have to thread lock on the java side to ensure we're ok there). That's a pretty big bummer. We've enabled reading through C on the server side (TDS), and performance of the server was...well, we don't do that, and never recommend for users it outside of super rare debugging cases (once). John wrote native HDF5 read support, so he utilized that to support reading netCDF-4. We do run into some issues in making sure the Java library and the C library see things in a similar way (Enums, for example), but that's helpful for everyone as it exposes areas in need of clarification in the netCDF data model documentation (not always, but sometimes).
Also (my opinion), it's really hard to recommend an on disk data format for archive purposes that relies on a single implementation for reading. That's one of the reasons why I loved the netCDF-3 on disk formats before my time at Undiata.

@lesserwhirls thanks for the clarifications. Thread-safety is something Denis has been working on I believe.
The classic formats are all still alive and well, for those who don't want to depend on HDF5. That said, HDF5 is an official NASA format that is guaranteed support based on the large amount of very expensive Earth science data NASA owns in HDF5. ;-)

I don't doubt the support one bit, and my comments should not be taken as a ding (just in case it came across that way), but knowing that a separate read implementation can be done is certainly a plus :-)

I think this functionality could handled with the current library
since quant can be packaged as jusy another filter.

I agree with Elena, although a general purpose filter handling ability is great, it is too complex for most users. As with HDF5, I believe the most common compression methods should be specified in the API, including this one.

As implemented in NCO, Bit Grooming exposes to the user the number of significant digits, then uses an internal table to convert this to minimum number of bits to quantize while preserving the requested number of significant digits. Bits are finer-grained and thus more flexible, yet less familiar to scientists than significant digits. The underlying bit-masking implementation is the same. NCO chose to expose digits rather than bits because there is something satisfying about knowing how many significant digits the quantization is guaranteed to preserve. netCDF is lower-level than NCO so perhaps bits are the better quantity to expose throught the API. In any case, I hope netCDF makes an intentional decision that considers this aspect of usability before deciding on the API. This is just another example of how user-friendliness and flexibility often lead to different outcomes.

As implemented in NCO, Bit Grooming exposes to the user the number of significant digits, then uses an internal table to convert this to minimum number of bits to quantize while preserving the requested number of significant digits. Bits are finer-grained and thus more flexible, yet less familiar to scientists than significant digits. The underlying bit-masking implementation is the same. NCO chose to expose digits rather than bits because there is something satisfying about knowing how many significant digits the quantization is guaranteed to preserve. netCDF is lower-level than NCO so perhaps bits are the better quantity to expose throught the API. In any case, I hope netCDF makes an intentional decision that considers this aspect of usability before deciding on the API. This is just another example of how user-friendliness and flexibility often lead to different outcomes.

100% agree. I think setting the significant digits is the right call, although if the API could support both, that'd be even better.
@czender - does NCO add any metadata to variables that use Bit Grooming to indicate that the process has been done?

Yes, see http://nco.sf.net/nco.html#number_of_significant_digits and/or the Bit Grooming paper referenced above.

@edwardhartnett Sorry for not responding earlier, but I think this would be a great capability.

Setting significant digits is an interesting take on this. I had not considered it but am certainly not opposed. I agree that for users, significant digits is much more understandable than significant bits. I will study Charlie's paper and then get back with a proposed implementation, after the AGU next week.

Yes, see http://nco.sf.net/nco.html#number_of_significant_digits and/or the Bit Grooming paper referenced above.

Excellent - thank you @czender! number_of_significant_digits looks good to me. Maybe also an attribute to for retained bits as well (perhaps as a less visible "special attribute")? At any rate, would want to make sure this gets added to the NUG.

I don't think we want to make this a special attribute (i.e. one that is hidden from the user by the netCDF  API).
There's a problem adding to the list of special attributes: earlier versions of netCDF will not know to hide that attribute. So there will be a different number of attributes in the file, depending on library version used to read it.
I believe we can simply add a new attribute, visible to users, but start with an underscore. Since users only get this attribute when they explicitly call nc_dev_var_groooming(), everyone will know what to expect and all versions of the library will be able to read and understand the file (even versions that don't have the nc_def_var_grooming() function!)
Absolutely this would be documented in the NUG. The CF Conventions gang might also be interested in the definition of this attribute.

At the AGU I have been chatting with people about this and there is a great deal of interest.
Stephan Siemen, Head of Development for ECMWF, says that compression, including lossy compression, is of great interest for ECMWF data sets, both model output and data from the Copernicus Sentinel satellites.
So we have strong interest from NOAA for their main operational forecasting system (GFS), from NCAR's biggest climate modeling group (CESM), and from the ECMWF.

That's great to hear. I'll be at the EarthCube booth (#510)  from 1-2 today (Tuesday) if you would like to chat in person.

I'll drop by as well, I'd be interested in this conversation. Hope the conference is going well for everybody.  @czender I tried to stop by your poster earlier but, predictably, it was pretty well mobbed.

It was good to discuss this with @czender and @WardF at the AGU! ;-)
I have studied Charlie's paper - it is excellent and does a great job answering all the detailed questions and comparing the different approaches. I agree with Charlie that bit grooming can be a very valuable lossy compression technique, and the fact that NOAA is already using a similar algorithm (and absolutely depends on it to get the required compression) is a strong indication that this is a good feature.
I have a paper in which I am outlining all the proposals for new compression in the C/Fortran APIs. Anyone interested in reviewing or collaboration should shoot me an email.

@czender quick question: you support specifying both NSD (number of significant digits) or DSD (decimal significant digits).
Why both? It would seem that NSD would be sufficient. Am I missing something?

NSD is better suited for science. DSD is more familiar to some laypeople who think of significance as how many digits before or after the decimal point. The section of the paper that discusses 800 pound gorillas attempts to convey the possible DSD use-cases. I personally would always use NSD and never use DSD, but I wrote the software for generic purposes that others may find useful.

OK, this has been a great discussion, but I believe this feature is something better suited to the CCR than to netcdf-c. So I will close this issue, but will refer to it again when adding this feature to the CCR.

I would like to re-open this discussion.
I propose adding two new functions to the C API - nc_def_var_grooming() and nc_inq_var_grooming(). (And equivalent F77 and F90 wrappers). The Java team would have to do their own version if they wish to write bit groomed data from java - reading data would work transparently for java.
These functions would apply bit grooming to data as it is written, and would be available to all binary formats. Calling nc_def_var_grooming() would add a (not hidden) attribute, indicating that bit grooming was used, and it's settings.
We need to discuss exactly what settings and parameters are used - NSD as discussed above, would be my first choice.
This feature is already present in CCR, but the CCR version has two serious limitations:

Only available for netCDF/HDF5 files.
Only works when readers also have CCR installed.

By putting this capability in the C library, it would be transparent (and fully backward-compatible) to readers (using C, Java, or Fortran), and would be of benefit to all binary formats including classic format. (Which does not include compression, but would still benefit if the classic files were compressed after being written.)
This would also greatly benefit Zarr backend data, if it does not already include bit grooming (@DennisHeimbigner does it?)
This would also include an extra variable in netcdf_meta.h to indicated whether the feature is available or not.

I still need to know why this cannot be handled as just another filter.

Also, it looks like NumCodecs supports quantize for python. Is it the same?

It can be handled as a filter (and currently is), but as noted:

Will only help with netCDF4/HDF5 data.
Requires that the filter also be installed on all reading machines.

The requirement for the filter when reading is a real problem. If bit grooming were in the netCDF C library, then it would be fully backward compatible with all netCDF versions. NetCDF-Java could read the data without problem, as could any existing HDF5 version.
When implemented with a filter, the data is is not readable to anyone who does not have the filter installed.  This would mean that 4.8.0 is required as well. NetCDF-Java could also not read the data, without implementing some filter code. This is a real bummer.
So if NOAA uses the bitgroom filter, all (!) uses of the NOAA data will have to install CCR in order to read the data. That's a significant problem. Instead, large data producers will just continue to do it themselves (as NOAA is doing now). It would be better if netCDF provided a standard solution that worked for everyone.
Also, bit grooming in netcdf-c will help with classic and Zarr formats.
I don't understand your second question, about NumCodecs. However, quantization implies that something like bit shaving is supported, However, bit grooming is superior to most quantization schemes, since it keeps data averages the same.

Back from PTO and getting caught up.  Tagging in @lesserwhirls since this touches on netCDF-Java.

Ed-
I don't understand the point about "Will only help with netCDF4/HDF5 data."
Presumably we can also use it with NCZarr since there is a codec defined for it.
My main concern is the idea of embedding this specific filter into the netcdf library.
That seems a very slippery slope. How do we decide which filters go into the netcdf-c
library?  I would have thought that putting it into ccr is exactly the right solution.

@DennisHeimbigner well for one, you couldn't use it with netCDF3--not sure how important that use case is. The problem with relying on the CCR, if this filter becomes really important, is that:

netCDF-java doesn't have a CCR
It becomes a support issue, where users find out they can't open a file and then have to figure out how to build, compile, and install an additional library that isn't a standard part of netCDF installs for e.g. ArcGIS, MATLAB

Could you include the filter as part of netcdf-c without adding a special API to enable it?

If netcdf-java is using the netcdf-c library then it can use any filter accessible to netcdf-c.
If reading with pure Java, then you don't have most filters available anyway.
I think this is the point of CCR. They have to install HDF5, then they can also install CCR.

If you install ArcGIS or MATLAB, you don't have to install HDF5, it's shipped with the software. Are we expecting the companies responsible for those tools to also ship the CCR?
You're right, netCDF-java reading with pure Java, which is the standard install of netcdf-java, doesn't have most filters. That's precisely the problem I've been stating over and over again. I'm trying to keep that from getting to be a bigger problem.

I don't know how matlab works, so how do they ship HDF5? As a static lib?
They must have some mechanism for dealing with other dependencies like libcurl.
NCZarr adds new (optional) dependencies like libzip and the aws sdk. I wonder how MATLAB will deal with those?
BTW about java, perhaps we need to see what the java zarr implementations do.

It occurs to me that we have had support questions from people at MATLAB.
It might be a good idea to bring them into this conversation.

@DennisHeimbigner I'm sure Mathworks has no problem building HDF5 themselves. They build it and libcurl and ship it (either statically or as a dynamic lib/DLL) with their installed product. That's not a big deal. I have no idea how their users are supposed to tell MATLAB to look for some random dynamic library on their system so they can open some data file they downloaded off the internet.
I don't think the average MATLAB user is familiar with worrying about dynamic libraries, the whole point of using a tool like MATLAB is to avoid that nonsense. Which brings us to Mathworks needing to ship a CCR plugin (if they're getting lots of complaints from customers), at which point I really wonder what the point of not shipping it with netcdf-c is?

I have no idea how their users are supposed to tell MATLAB to look for some random dynamic library ...

But that is the case now. I wonder what they do? Do they tell their users that they
cannot read/write any compression but zlib and szip? Do they already bundle other
compressors along with hdf5?

I went searching and found this:

https://www.mathworks.com/matlabcentral/answers/393621-how-can-i-import-a-lzf-compressed-hdf5-dataset-in-matlab

Here's the docs, looks like you can load a dynamic filter.

I think that Charlie Zender should talk to them about CCR; I suspect they would
be very interested.

Bit grooming is quite different from other filters. The usual filter is a compression/decompression algorithm, like zstandard. Clearly both writer and reader need to have zstandard in order to use it. Compressed data needs to be uncompressed, so the zstandard code is run when writing and when reading. For that, CCR is a fine solution.
Bit grooming is only needed by the data writer. The reader does not need to have any special software to read bit-groomed data. However, the HDF5 filter mechanism does not allow for this - the filter is required for both readers and writers, even though in the case of reading, the filter does absolutely nothing. Without installing the bit groom filter, HDF5 will not read the data.
The questions of matlab and netcdf-java and new compression filters is a separate conversation. Bit grooming stands on its own merits as a worthy feature, which would bring many benefits to producers and consumers of large data sets, using the existing zlib compression.
@dopplershift in answer to your questions, yes, any of the filters could be automatically installed with netcdf-c. Currently netcdf-c includes the bzip2 filter (though it does not install it on the user machine - it just uses it for testing filter code). So if zstandard becomes very popular and we want to make it part of the standard netcdf-c build, we can easily do that. Netcdf-java would have to be modified to understand zstandard compression, just as it now can understand zlib.
So we could add the currently-existing bit-grooming filter to netcdf-c, and then all future versions of netcdf-c could read bit-groomed data, but not past versions, and not netcdf-java. Only netCDF/HDF5 files would be able to use bit grooming.
The point of this issue is that bit grooming would be better implemented not as a filter, but in the library code itself. This would require no modifications to netcdf-java, and bit groomed data would be readable by all historical versions of netcdf. It would also work for zarr and classic formats.

That is a good point about the write-only filter. But there must be a fair number of
such manipulative filters. How many different ones are we talking about?

Bit-grooming is the only one I know of.
All the other filters are compression/decompression, so needed for both reading and writing.

At this point we need an implementation of this
as an HDF5 custom filter. That way I can incorporate it into both libhdf5
and libnczarr.

@DennisHeimbigner we have a working bit-groom filter here: https://github.com/ccr/ccr/blob/master/hdf5_plugins/BITGROOM/src/H5Zbitgroom.c
I can do the netcdf/HDF5 implementation.
We need to consult closely with @czender - he has some upgrades in mind for the filter, we should take on-board.
If this is implemented in netcdf-c, then we would remove it from CCR.

I would prefer to add this as a built-in filter so that we do not need to extend the API.
Also, that would make it easier to use in ncgen and nczarr.

We should still extend the API to make this easy for users to use...

I leave that question for discussion: new API or  use existing def_var_filter?

I think filters are not the answer.
If we implement this as a filter, we still have all the compatibility problems: such data cannot be read by older versions of netcdf-c, cannot be read by netcdf-java, and cannot be read by HDF5 (without installing the filter, even though it is not doing a thing for readers).
I was thinking this should be implemented in that giant function that does type conversion of data. As the data are converted (or even if the data are not converted) the big grooming algorithm can be applied.
In this way we get netcdf-java for free, as well as all older versions of netcdf-c and native HDF5. I suspect @lesserwhirls and @dopplershift would prefer it if we did not break netcdf-java reads with this feature, and there is no reason we need to.
If we just forget about filters in this case, it becomes a lot simpler for everyone...

If you do it in the write functions (which are not chunk aware) then you need
to make sure that the algorithm is idempotent because it could end up being
applied to the same data multiple times. Do we know it that true for this algorithm?
Also, when you say "jave" do you mean the pure java read-only implementation
or the mixed implementation using java+netcdf-c?

I believe @edhartnett means if it's implemented as a library feature, the pure Java implementation gets to read these files with no code modifications.
If it's left as a filter, netCDF-Java would have to at least recognize and ignore the filter to read the data.

@DennisHeimbigner how can it be applied to the same data multiple times? (Unless the user re-writes the data?) In the case of HDF5 it would be applied before the data are chunked, and the chunking would not affect the results.
@dopplershift is correct - if we make it part of the library, not just netcdf-java, but all existing versions of netcdf-c will be able to read the data for free. When I say netcdf-java I mean the native Java read-only implementation, which is very important. (However, it would also be readable by all existing java+netcdf-c implementations, without upgrading netcdf-c.)
@czender is of course the expert in this code, which is his. @czender would you like to comment on the idempotence of the bitgroom algorithm? I believe that it is idempotent, as long as the same starting point is chosen each time.

how can it be applied to the same data multiple times? (Unless the user re-writes the data?) In the case of HDF5 it would be applied before the data are chunked, and the chunking would not affect the results.

You have to take all possibilities into acct. So you have to assume some user will write the same data more than once. Possibly in two different programs.  Otherwise you have some
kind of write once situation of which the user needs to be aware.

At this point, I am mostly convinced by Ed's arguments that we should build this into the library as a non-filter.
It would need to be added it to nczarr as well.
How about netcdf-3?

I believe it should also be applied to classic formats. This will benefit users in 2 ways:
1 - files can be compressed as a post processing step before storage
2 - data can be stored with correct precision.
Also it will be easier to document and explain if it applies to all binary formats.

Some issues that need to be resolved:

What types? Float and double of course.
What about integer types (for simulated fixed point)?
From H5ZBitgroom, there are 5 parameters:

no. of significant digits to keep -- default is 3
typesize (in bytes)
missing value flag -- 0 => do not use missing value, !0 => use
missing value part 1 (what byte order?)
missing value part 2

We can get the type from the variable's type.
Can we get the missing value from a "missing_value" attribute?
Or is it the same as _FillValue?
Do we want to record the use of quantize + parameters in the file
using some special attribute like "_Quantized"
Idempotent? As mentioned we have to take into account multiple writes.

Related question: what if the two writes use different parameters?

What name? NumCodecs uses Quantize, Zender uses Bitgroom.
I prefer quantize as more descriptive.

All good questions. Some answers I know now, some remain to be worked out.
Only float and double types can use grooming. For all other types trying to turn on grooming returns error EBADTYPE (or EINVAL?)
As with deflate or other var settings, the settings for grooming cannot be changed once enddef has been called. So the settings are final for the var before any writes are done, and can not be changed, so writes cannot have different parameters.
We do want to record parameters in a non-hidden attribute that is added whenever grooming settings are turned on.
What is in a name? I don't mind what we call it. But quantization has typically referred to bit-shaving (i.e. always using 0s). Bit grooming is when we alternate 0s and 1s.
Questions to consult with @czender on when he returns later this week:

idempotency
fill value

Howdy all, and sorry for the delayed response due to my off-the-grid vacation. I have just finished reading the last 10 days of this thread which occurred while I was away. I'll try to answer and ask as many questions as I think are still relevant to the discussion.
First, let me clarify that BitGrooming is a pre-processor for compression, and is not itself a compressor. BitGroomed data remain in IEEE format on-disk, hence there is no need for special software for reading. BitGrooming (BG) is a form of quantization, as are BitShaving and BitSetting, and a few other algorithms (DigitRounding, ...)  not mentioned here. BG simply eliminates (by alternately shaving and setting) the least significant bits of floating-point mantissas, until the resulting mantissa preserves no more than the user-requested Number of Significant Digits (NSD). An easy to implement alternative would be to no more than the user-requested Number of Significant Bits (NSB). I think most scientists would prefer NSD, since that is the language of instrumental/numerical precision, though computer scientists might prefer NSB.
BG enhances the compression ratio (CR) of subsequent lossless compression algorithms (that for our purposes require netCDF4 format to invoke) by eliminating the randomness beyond the least significant digit. I hope this makes clear that netCDF3 format can contain BG'd data, though its CR is identically 1, so BG'd netCDF3 datasets do not change size. BG'd netCDF4 datasets that are subsequently compressed will be smaller (CR(BG) > CR(no-BG), where CR is input size/output size) than the same datasets were they compressed without first using the BG algorithm.
Idempotency:
My understanding is that BG is idempotent. The output of BG depends solely on the specified NSD. If previously BG'd data are re-BG'd they will not change unless NSD2 (the newer value of NSD) is smaller than NSD1 (the previous value), in which case more bits/digits will be quantized. BG is irreversible since precision can only be eliminated, not created, so attempting NSD2 > NSD1 should probably return an error to avoid confusion, and attempting NSD2 >= NSD1  should be OK, IMHO. The NCO BG implementation includes user-visible variable-metadata to indicate the NSD of BG'd variables. The CCR implementation does not. FWIW, both implementations treat requests to BG integer variables as no-ops (not errors).
Fill Value:
The NCO and CCR implementations of BG sometimes refer to _FillValue as "missing value" in descriptions/documentation. They are synonymous and their usage depends on my own idiosyncratic preferences for distinguishing semantics from syntax.
Please ping me via this thread for any additional clarifications. I am pinging @jtolento, a UCI grad student who has been working to update the BG algorithm to be more efficient.

@czender I think we all understand that bit-grooming (and it's cousins) does not, in itself, compress the data.
For example, the advantage of applying bit-grooming to a netCDF classic file would be that such a file would compress better. That is, we would write such a file, and then gzip the file. That file would be smaller than if we write the file without bit-grooming, and then compress it.
The question I have with fill value is this: what if the user specifies a fill value with more precision than the bit-groomed data? For example, if I have a fill value of 9.99999 and then specify bit-grooming with NSD=3? Then, the values that were 9.99999 will become 9.99 or 10.0, correct? So neither result will be equal to the fill value.
Does that mean that when bit grooming is applied, we must also apply it to the fill value? How do we handle the fact that alternate values of 9.99999 will be rounded different ways by the bit-groom? Do we have two different fill values? Or do we check for fill value as we bit groom and handle it specially (I think this will be the answer).
In terms of changing the NSD, that will not be allowed. Once enddef is called, the NSD is final. Attempts to change it will return NC_ELATEDEF -  Attempt to define var properties, like deflate, after enddef.

@edwardhartnett We are on the same page with respect to BG being a pre-filter.
Regarding fill values: The BG algorithm as implemented in both NCO and CCR does not touch any data equal to the _FillValue attribute, if any. Before the (irreversible) BG procedure is applied to any value, that value is compared to the _FillValue, if any. BG only quantizes valid data, not data equal to _FillValue. That is why the _FillValue argument is input to and not changed by the BG algorithm. Of course the comparison takes time,  so it is only performed when has_mss_val is true. A wrinkle to note is that the current implementations only respect explicitly defined _FillValue attributes. Values equal to the default fill values (NC_FILL_DOUBLE, NC_FILL_FLOAT) will be BG'd unless the _FillValue attribute is explicitly defined to be one of those values. I think this behavior moots the rest of your FV questions. If not, let me know.
Regarding NSD: I have no problem with making it immutable in libnetcdf. Just pointing out the consequences of more and less strict behaviors.

OK, but we also need to apply the fill value rule to default fill values. Or figure something else out - perhaps require that a fill value be set before allowing bit-grooming to occur? Or just treat default fill values the same way - that is, check for them, and don't apply the BG algorithm for fill values.

If _FillValue has not been set when bitgrooming is defined, we could automatically
set the _FillValue to the default fill value.

It's easy enough to change the implementation to treat all floating pointing variables as having a _FillValue, either explicitly or implicitly defined. If _FillValue is explicitly defined then there would be two comparisons prior to BG'ing a value, first to the explicit _FillValue attribute, and second to the default fill value for that type. If _FillValue is implicitly defined to be the default value for that type, then there is only one comparison. I have never been sure whether this is the intended way to use the default _FillValue, though you are the experts so now it's clearer to me.

WRT fill values, the CCR code and the code in my PR both ignore data that matches the fill value, when doing quantization. This works with the defined fill value, if the user has defined one, or the default fill value, if the user has not defined one.
On to another question: should quantize work with scalars? I believe the answer is yes...

Thanks @WardF ! I'm so happy to see this great new feature make it's way into the hands of users! ;-)


Microsoft.AVS provider actions

Can we incorporate the Microsoft.AVS provider actions into this documentation please?

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

ID: 33219707-3b9f-cc6b-541e-a806dc82622a
Version Independent ID: b4e96391-bcf9-1f30-cb44-ed339469da4f
Content: Azure resource provider operations
Content Source: articles/role-based-access-control/resource-provider-operations.md
Service: role-based-access-control
GitHub Login: @rolyon
Microsoft Alias: rolyon

@dan-dimitrov
Thanks for your feedback! We will investigate and update as appropriate.

@dan-dimitrov
Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can take a look at it accordingly.
@rolyon
Can you please check and add your comments on this doc update request as applicable.

Hi @dan-dimitrov
Thanks for your feedback. This resource provider has been added. Let us know if you have additional feedback.
https://learn.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftavs
thanks

#please-close


[agora_uikit: 1.0.2][flutter_web: 3.0.5] MissingPluginException issue

Hi guys
I saw that the web support is marked as done so i thought I'll give this package a try.
i'm looking for a good video calls platform for very long time.
i used the example
my code is
import 'package:agora_uikit/agora_uikit.dart';
import 'package:flutter/material.dart';

class CallsView extends StatefulWidget {
  const CallsView({Key? key}) : super(key: key);

  @override
  State<CallsView> createState() => _CallsViewState();
}

class _CallsViewState extends State<CallsView> {
  final AgoraClient client = AgoraClient(
      agoraConnectionData: AgoraConnectionData(
        appId: "******",
        channelName: "test",
        username: "user",
        tempToken:
            "******",
        rtmEnabled: false,
      ),
      enabledPermission: [
        Permission.camera,
        Permission.microphone,
      ]);

  @override
  void initState() {
    super.initState();
    initAgora();
  }

  void initAgora() async {
    await client.initialize();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
        appBar: AppBar(
          title: const Text('Agora UIKit'),
          centerTitle: true,
        ),
        body: SafeArea(
          child: Stack(
            children: [
              AgoraVideoViewer(
                client: client,
                layoutType: Layout.floating,
                enableHostControls: true, // Add this to enable host controls
              ),
              AgoraVideoButtons(
                client: client,
              ),
            ],
          ),
      ),
    );
  }
}

The error I get
Error: MissingPluginException(No implementation found for method checkPermissionStatus on channel flutter.baseflow.com/permissions/methods)
    at Object.throw_ [as throw] (http://localhost:40000/dart_sdk.js:5080:11)
    at MethodChannel._invokeMethod (http://localhost:40000/packages/flutter/src/services/restoration.dart.lib.js:1567:21)
    at _invokeMethod.next (<anonymous>)
    at http://localhost:40000/dart_sdk.js:40641:33
    at _RootZone.runUnary (http://localhost:40000/dart_sdk.js:40511:59)
    at _FutureListener.thenAwait.handleValue (http://localhost:40000/dart_sdk.js:35438:29)
    at handleValueCallback (http://localhost:40000/dart_sdk.js:35999:49)
    at _Future._propagateToListeners (http://localhost:40000/dart_sdk.js:36037:17)
    at [_completeWithValue] (http://localhost:40000/dart_sdk.js:35872:23)
    at async._AsyncCallbackEntry.new.callback (http://localhost:40000/dart_sdk.js:35906:35)
    at Object._microtaskLoop (http://localhost:40000/dart_sdk.js:40778:13)
    at _startMicrotaskLoop (http://localhost:40000/dart_sdk.js:40784:13)
    at http://localhost:40000/dart_sdk.js:36261:9

Thank you

Hey @hmbenhaim, UIKit currently supports Android and iOS as of now. We are working on adding support for Web and desktop. In the meanwhile you can use the agora_rtc_engine package to add web support for your application.


Apply the standard hash.Hash interface on Go solution (conflict resolved)

I just add the hash.Hash interface, in this case the Go authors can put the crypto algorithm to the official Go source.

I created the new pull request, and resolve conflicts in go part. Resubmit of #75


IOTDB-1111 load configuration -global command do not support in the d…

…istributed version
Description
Content1 ...
Content2 ...
Content3 ...

This PR has:

[ ] been self-reviewed.

[ ] concurrent read
[ ] concurrent write
[ ] concurrent read and write

[ ] added documentation for new or modified features or behaviors.
[ ] added Javadocs for most classes and all non-trivial methods.
[ ] added or updated version, license, or notice information
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious
for an unfamiliar reader.
[ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold
for code coverage.
[ ] added integration tests.
[ ] been tested in a test IoTDB cluster.

Key changed/added classes (or packages if there are too many classes) in this PR

@PowerMockIgnore({"com.sun.org.apache.xerces.", "javax.xml.", "org.xml.", "javax.management."})

@PowerMockIgnore({"com.sun.org.apache.xerces.", "javax.xml.", "org.xml.", "javax.management."})


Add support for CLI command groups

Here is a contribution that I think might be useful to more than just me: when dealing with lots of commands that, oftentimes most of them can be logically grouped together and organized as a tree of commands, like most well known CLIs do (docker, terraform etc.).
This implementation is easy to use and doesn't add a lot of code to the existing codebase, but feel free to challenge it if you feel it's warranted. Also, English is not my native language so I might have made mistakes in the documentation, please correct or reword things as you see fit :)

Any interest in this @danielgtaylor ?

Hi @danielgtaylor, any chance to see this PR merged soon?

@danielgtaylor while you're there, can I inquire about #34 too? 🙏

Also, I tried to update the bindata.go file but it seems like the tools used for that have quite evolved over the last time they've been used in this project, and produce quite different output so I'd prefer you have a look at this if you accept this PR.

This feature had been implemented in our fork: https://github.com/exoscale/openapi-cli-generator/


Expose unmodified hostname (non-lowercase)

Is your feature request related to a problem? Please describe.
The hostname is currently being coerced into lowercase, but hostnames on Windows are usually expected to be all-uppercase and on unix systems hostnames aren't guaranteed to be lowercase either (https://github.com/starship/starship/issues/5666).
Describe the solution you'd like
Expose an API that returns the unmodified system-provided hostname.
Describe alternatives you've considered
Change the API not to modify the system-provided hostname.
Additional context
https://github.com/starship/starship/issues/5666
https://github.com/ardaku/whoami/issues/39

Thanks for opening this issue @davidkna!
I think the current behavior could be rethought, leaning towards the alternative.  Linking to https://github.com/ardaku/whoami/issues/39, as it's relevant here.  Since hostnames are case-insensitive, I'm guessing the reasoning for keeping the casing here is specifically for UI display, which normally I would defer to devicename rather than hostname for, but the case of a shell is different.  In the case of Windows, though, I'm unclear as to what should be expected; Should it be expected to be all-caps, or should it be expected to match the devicename (camel-case in that issue)?

As far as I know, hostnames are still more relevant for networking than device names, and I feel that for display it's useful to preserve any casing. Windows usually uses all-caps in the user-interface for hostnames, so I'm not sure if doing magic behind the scenes is useful, but if they match, I imagine is unlikely to do any harm.
Also, accoriding to this serverfault answer case-sensitivity of hostnames is only discouraged, not forbidden in the specifications.

accoriding to this serverfault answer case-sensitivity of hostnames is only discouraged, not forbidden in the specifications.

Interesting, thanks for bringing this up.

As far as I know, hostnames are still more relevant for networking than device names, and I feel that for display it's useful to preserve any casing. Windows usually uses all-caps in the user-interface for hostnames, so I'm not sure if doing magic behind the scenes is useful, but if they match, I imagine is unlikely to do any harm.

Thanks, this answers my question, in that using the hostname casing as specified from the windows API WhoAmI would be more accurate to the specification than using the device name casing - (usually?) all caps, especially with the case-sensitivity issue.
Will revert that part of https://github.com/ardaku/whoami/commit/8445e54135db829fe9d51b882fe69c6e87598f16

Unmodified hostname is available via whoami::fallible::hostname() in the pre-release: https://crates.io/crates/whoami/1.5.0-pre.0
If you'd like to help test, I'd like to know if you run into any issues testing with the pre-releases.  Thanks again, @davidkna!


Telldus live broken after update -> 0.59.2

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version):
hass --version
0.59.2
Python release (python3 --version):
python3 --version
Python 3.5.2
Component/platform:
Running on Ubuntu 16.04
Description of problem:
Telldus Live stopped working after update. Not sure what version I was running before, but last before this update was about a month ago.
Been using HA for about 6 months and this used to work.
Now I get:
2017-12-08 11:45:05 ERROR (MainThread) [homeassistant.config] Invalid config for [tellduslive]: [public_key] is an invalid option for [tellduslive]. Check: tellduslive->tellduslive->public_key. (See /home/hass/.homeassistant/configuration.yaml, line 87). Please check the docs at https://home-assistant.io/components/tellduslive/
Can't find any information on the link provided in the message about a configuration change.
Config has not been changed since last update.
Tried restoring old configuration.yaml. No change.
Expected:
Problem-relevant configuration.yaml entries and steps to reproduce:
tellduslive:
  public_key: XXXXXXXXXXXXXXXXXXX
  private_key:  XXXXXXXXXXXXXXXXXXX
  token:  XXXXXXXXXXXXX
  token_secret: XXXXXXXXXXXXX

Traceback (if applicable):

Additional info:

Did you look through the changelog before updating? Could this be relevant under the headline "Breaking Changes"

•Tellduslive update with support for auto config and Local api (@fredrike - #10435) (tellduslive docs) (breaking change)

Thank you! Didn't find that part of the change log when i googled the error message.
Solved be removing 4 config lines under "tellduslive:" and restarting HA.


PF4J site for github pages

Wow. Super. How can I see the result? How can I modify the content?
I have a something similar for another project. The source of the site is available here. I used Jekyll.

Hi, It's based on the https://github.com/lviggiano/owner site http://owner.aeonbits.org/ which is almost the same as http://jekyllrb.com/
by running antrun:run it will run jekyll locally and you can see it on localhost.

For the moment, we will go with readme file and probably with wiki from Github.
The argument is the lack of time on my part


feat(pbn): import a PBN deal

Coverage increased (+0.2%) to 99.161% when pulling cd27d0f876f34d85999e07b795bd55c616dd04ff on greenkeeper/update-all into da47fd16a3c26ed647bae3e6acf2eb9b727c36fb on master.


Feature request - Total data downloaded

If you could, print this at the end of each run, then we could see what du -h shows and compare to see what's in the cache on disk vs just now downloaded.
Having this in all three programs would be great because then you can bash script running each of them and see what the total is.
Thanks!

Released in v2.0.0


Daydream mode?

I would like to have this on my tablet, when I leave it docked at my desk. Most daydream apps are disappointing and this one looks like a strong candidate for a useful Daydream.

Daydream is a good idea. I'd like to look into it, but might not have time this week.
Feel free to try out an implementation.


allow public namespaces created with no org prefix

Purpose
To allow the user create public namespaces with no org prefix
Brief changes

Added a append org prefix checkbox in the namespace creation page
Will check public namespace name global uniqueness before creation

global uniqueness means the name is not used as any public namespace as well as any private namespace

Effect
1. when append org prefix checkbox is checked (default behavior)

2. when append org prefix checkbox is unchecked

Codecov Report

Merging #1476 into master will increase coverage by 0.12%.
The diff coverage is 85%.

@@             Coverage Diff              @@
##             master    #1476      +/-   ##
============================================
+ Coverage      48.4%   48.53%   +0.12%
- Complexity     1801     1809       +8
============================================
  Files           379      379
  Lines         10930    10947      +17
  Branches       1121     1125       +4
============================================
+ Hits           5291     5313      +22
+ Misses         5253     5245       -8
- Partials        386      389       +3

Impacted Files
Coverage Δ
Complexity Δ

.../apollo/portal/controller/NamespaceController.java
3.77% <0%> (ø)
2 <0> (ø)
:arrow_down:

...ork/apollo/portal/service/AppNamespaceService.java
71.42% <89.47%> (+4.76%)
19 <5> (+7)
:arrow_up:

...lo/configservice/util/InstanceConfigAuditUtil.java
70.17% <0%> (-0.88%)
13% <0%> (-1%)

...ervice/service/ReleaseMessageServiceWithCache.java
86.9% <0%> (ø)
25% <0%> (ø)
:arrow_down:

...work/apollo/biz/message/DatabaseMessageSender.java
66.66% <0%> (+16.66%)
8% <0%> (+2%)
:arrow_up:

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 976b69d...04f99dd. Read the comment docs.

Coverage increased (+0.1%) to 52.087% when pulling 04f99ddbe46ef084c17aa9850864027eed779c35 on nobodyiam:allow-public-namespace-with-no-org-prefix into 976b69d019e6c8be409ed93c7a1dc861bbc82643 on ctripcorp:master.

Awesome, I think this can make the config model more flexible. Sometimes, people may need global namespace.


Add Mbed-Os Docker definition.

Our team currently work on bringing support for Mbed OS platform into the CHIP project.
Here is our first step to fulfill this goal.
Problem

missing Dockerfile definition for MbedOS

Summary of Changes

add chip-build-mbedos directory with mbed-os specific Dockerfile
replace cmake with version v3.19.3 in chip-build Dockerfile (mbed-os requirement)

Thanks for this! Can we also add a GitHub workflow to verify this docker file/build?
Yeah, sure!

Thanks for this! Can we also add a GitHub workflow to verify this docker file/build?

Yeah, sure!

Seems fine as a separate PR, can you file an issue for this - and is there an ETA for this platform providing an example?

I will have to ask my technical leader for his opinion about ETA for platform example.
However probably the first one will be a shell example.
Ok, I will github workflow in separated PR.

@woody-apple We want to provide the shell, lock and lighting example. Our plan is to first get the Shell example working with Bluetooth and WiFi implementation in our fork, submit it then continue to improve the Mbed platform support.
We're just starting the integration and I can't provide firm date. However I would expect the Mbed platform support to be submitted to this repository at end of March or early April.
Having docker images from this repository usable in our fork would help us during this period where we have to sync often and work using the both the fork and the upstream repo.

Resolve merge conflicts with PR #4657 - I guess @woody-apple change will land on master first.

In our team we decided to close this PR and return with mbed integration when we will have more complete solution.


Merge pull request r1.3 from tensorflow/master

Update from origin to r1.3

Can one of the admins verify this patch?

Done


x/vgo: cannot require k8s.io/client-go v6.0.0

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go 1.10
Does this issue reproduce with the latest release?
n/a
What operating system and processor architecture are you using (go env)?
darwin/amd64
What did you do?
Daves-MacBook-Pro(~/src/github.com/heptio/contour) % cat go.mod
module "github.com/heptio/contour"

require (
        "k8s.io/client-go" v6.0.0
)

What did you expect to see?
Build success (or at least fetching of the v6.0.0 tag) then probably blowing up with something else
What did you see instead?
Daves-MacBook-Pro(~/src/github.com/heptio/contour) % vgo build ./cmd/contour
vgo: errors parsing go.mod:
/Users/dfc/src/github.com/heptio/contour/go.mod:4: invalid module: k8s.io/client-go should be v1, not v6 (v6.0.0)

Possibly the same as https://github.com/golang/go/issues/23977? If that bug is correct, only v1 and v2 should currently work.

For anyone interested. A quick workaround is to use the commit:
require (
        "k8s.io/client-go" v0.0.0-20171206195300-78700dec6369ba22221b72770783300f143df150
)

Duplicate of #23977
There are many discussions on the inclusion of the /v_N_ component in the import path. There doesn't need to be another issue for the discussion to leak onto.


Client Allocation Request for: IPFS Found

Client Allocation Questions
Core Information

Name: IPFS Found
Website / Social Media: https://filecoin.in/
DataCap Requested: 5TiB
Addresses to be Notarized: f1xromiih5gr5l63gk6j2plrk45qrdl22y32hmxty
Notary Requested: ericfish

Hi, @IPFSUnion
Our Datacap can be allocated to the region of Asia-GCN. Please modify and reopen this issue if you are in this region.


Error with windows update

Hello,
After running the script, Windows Update can no longer search for Windows updates, an error appears.
Is there a way to resolve this ?
Thanks in advance.

@Nexium57 what version of windows are you on Home, Pro, Enterprise? What version of the install did you do and with what options?

Hello, this is a Windows Home version, is a version 22H2

Hello, this is a Windows Home version, is a version 22H2

Someone didn't read the requirements....
Home editions are not supported on this script.  Please take care to read the readme before running random scripts on the internet.
Please read the following wiki article explaining how to reverse the changes.
https://github.com/simeononsecurity/Windows-Optimize-Harden-Debloat/wiki/How-to-Reverse-the-Changes-performed-in-Windows‐Optimize‐Harden‐Debloat


Swapped benchmark version with and without custom OP

The one used for VNN-COMP 2023 should be at root level

Unfortunately, the diff is too large for GitHub. I ran
mkdir custom_OP
mv vnnlib/ onnx/ instances.csv generate_properties.py custom_OP/
mv no_custom_OP/* .
rm -r no_custom_OP/

This PR does not update the README, which still refers to no_custom_OP.
An alternative fix would be to unify the generate_properties.py file, and to add a flag to switch between both versions. The default should be to use no custom OP.


[BUG] (cdk-graph-plugin-threat-composer) Generated architecture image too large for threat composer

Describe the bug
After adding some infrastructure, the embedded png image can be too large to import to threat composer.
Expected Behavior
Able to import a generated threat model into threat composer.
Current Behavior

Reproduction Steps
Add a few components, import the generated threat-model.tc.json file into threat composer.
Possible Solution
Add support for svg images in threat composer as they will likely be much smaller. Consider also increasing the size limit.
Additional Information/Context
No response
PDK version used
0.23.13
What languages are you seeing this issue on?
Typescript, Java, Python
Environment details (OS name and version, etc.)
OSX

Is this a bug in PDK or Threat composer?

Kind of both, I've raised one for threat composer here: https://github.com/awslabs/threat-composer/issues/100
I think we should keep this open so we remember to switch to svg output.


Expose lavalink sessions for plugins

This pr adds the ability for plugins to easily access the sessions without having to import the lavalink server as a dependency
in some plugins i want to have rest routes such as /v4/sessions/{SESSION_ID}/players/{GUILD_ID}
this is rather annoying atm since you have to add the lavalink server as a compile only dependency

two such example plugins would be https://github.com/topi314/LavaLyrics or https://github.com/topi314/LavaQueue


Add postsubmit test run with debug mode

Jenkins job manager/presubmit passed

Jenkins job manager/presubmit passed

Jenkins job manager/presubmit passed


Complete implementation of remaining Spark transformers

[ ] OneHotEncoder
[ ] RFormula
[ ] PolynomialExpansion
[ ] Interaction
[ ] Imputer
[ ] VectorIndexer
[ ] Word2Vec

These require MurmurHash3 to be added as a built-in PFA function (refer to related Hadrian issue):

[ ] HashingTF
[ ] FeatureHasher

Hi @Paxanator thanks for your interest in Aardpfark!
Yes I agree, OneHotEncoder as from Spark 2.3 would be the best way forward for this transformer. Let me know if you need some assistance.

Thank you for putting the library together! I'll wait on the Spark Version bump before trying to tackle it


MFCMAPI crashes when opening associated items

Open associated items crashes with MFCMAPI 18.2.18154.97 64-bit on Outlook 2016 MAPI 1805 (9330.2087 C2R). Our Exchange is 2016 On-Prem (15.1.1466.8 when looking at OWA html sources).
I logged on to my Outlook profile for my cached mailbox: no matter on which folder I try to open the associated items, MFCMAPI crashes.
Regards
Sven

Crash occurs on dynamic_cast in MsgStoreDlg.cpp
`
void CMsgStoreDlg::OnDisplayAssociatedContents()
{
if (!m_lpHierarchyTableTreeCtrl) return;
	// Find the highlighted item
	auto lpMAPIFolder = dynamic_cast<LPMAPIFOLDER>(m_lpHierarchyTableTreeCtrl->GetSelectedContainer(mfcmapiREQUEST_MODIFY));

`
This is with VS 2017 15.7.3 in rtti.cpp (C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.14.26428\crt\src\vcruntime\rtti.cpp) when auto offsetValue is calculated an access violation occurs:
`static void * FindCompleteObject(void* inptr)           // Pointer to polymorphic object
{
// Ptr to CompleteObjectLocator should be stored at vfptr[-1]
const auto pCompleteLocator = GetCompleteObjectLocatorFromObject(inptr);
const auto inAddr = reinterpret_cast<uintptr_t>(inptr);
auto pCompleteObject = inAddr - pCompleteLocator->offset;
// Adjust by construction displacement, if any

// We know we can read an int from inptr, because it points at pointer to vtbl.
// Therefore we optimistically read the int here even if cdOffset is 0, in
// order to make it legal to generate a cmov instruction.
const auto cdOffset = pCompleteLocator->cdOffset;
auto offsetValue = *reinterpret_cast<int *>(inAddr - cdOffset);

`

Same issue here. Trying to Open associated contents table on Inbox and it crashes.
Tried with MDB_ONLINE and MAPI_NO_CACHE checked.

I know what I did - I've pulled 18.2.18154.97 while I fix this...

BTW - what I did was let resharper convince me to convert a ton of static_cast to dynamic_cast when MAPI objects can't deal with that. Rather than unwind all of that though, I'm gonna take this opportunity to eliminate ALL casts of MAPI objects. Might take a few days...

Hopefully fixed by #140 - build will be up shortly for testing

Try this release.

Fixed. Thank you!


Add CMake option for providing a custom extension API

Rather than require people to fork the forked godot-cpp, they can update CMakePresets.json with
    {
      "name": "platform-base",
      "hidden": true,
      "generator": "Ninja Multi-Config",
      "binaryDir": "${sourceDir}/build/${presetName}",
      "cacheVariables": {
        "CMAKE_EXPORT_COMPILE_COMMANDS": true,
        "GODOT_GDEXTENSION_DIR": {
          "type": "FILEPATH",
          "value": "${sourceDir}/../gdextension"
        }
      }
    },

and place their dumped extension JSON and headers in a folder they control.
I admit I don't know CMake well enough to know if there's a better way to customize this without needing to modify Presets but godot-cpp does read that variable.

I experimented with adding a new CMake option for providing the extension_api.json at one point, same as what godot-cpp does, but ran into problems due to how I manage the external libraries (like godot-cpp), where it wouldn't actually build properly whenever the extension_api.json file was modified, so I ended up abandoning that effort.
But yes, I realize it's a bit of a hassle currently. I'll see if I can take another look at it at some point.
(If you're just looking to make a build for Godot 4.3-beta1, I'm in the middle of packaging one as we speak.)

I'm on double precision build with custom modules so I'm always going to be stuck with my own builds I think - but we used the CMake variable for our own extension too.
Your issues with it make sense - I feel like I'm constantly deleting the build cache when working with godot-cpp + CMake.

I don't believe you need to target a custom extension_api.json just because you have custom engine modules, assuming of course that you haven't modified Godot Jolt to actually make use of them.
I'm pretty sure you should be able to get away with just building a GDJ_DOUBLE_PRECISION build of Godot Jolt, or use the prebuilt one that I'm about to publish.

I'll give the prebuilt a shot then - I've been on 4.3 since before I moved to Jolt so I'll test and report back later tonight.

You can find the prebuilt one here: v0.13.0-beta1

Prebuilt worked great! Seems extensions aren't as picky about the JSON as I once believed.
Simplifies my engine upgrades in the future slightly, thanks!

I'm gonna be honest with myself and say that I likely won't get around to doing this, so I'll go ahead and close this.
If someone has a strong need for this I might take another look at it, but given where the winds are blowing it's more likely that this extension will be migrated to Godot (and put into maintenance mode) before I get around to actually doing this anyway.


[BUG] When changing from Live-preview mode to reading mode a new pane gets opened in loop

Create a new note
Insert a video URL

Switch to edit/live-preview mode
ctrl/cmd+p -> Open media from link
Paste the same link
Start the video, take some notes

Switch from Edit/Live-preview to reading

Here's what's happen
Switch another time from edit to reading mode

This goes on endlessy... Hope someone can resolve. Thank's.

Another Solution
Downgrade you obsidian to v0.14.15. Remember to disconnect the wifi before you open obsidian v0.14.15, then turn off About > Automatic updates.

Hi, thank’s. Is the author going to fix this any time soon?
Than’s for giving a solution.

I came up a workaround to this issue instead of switching mode back and forth, just use 3 panels.
first split the editor into 2, then turn one into preview mode, click timestamp link in preview panel will open a video panel and all 3 are linked.

Another Solution
Downgrade you obsidian to v0.14.15. Remember to disconnect the wifi before you first time open obsidian v0.14.15, then turn off About > Automatic updates.

sorry,why it's still not working with v0.14.15?

Hi, thank’s. Is the author going to fix this any time soon?
Than’s for giving a solution.

Another Solution
Downgrade you obsidian to v0.14.15. Remember to disconnect the wifi before you open obsidian v0.14.15, then turn off About > Automatic updates.
—
Reply to this email directly, view it on GitHub, or unsubscribe.

Another Solution
Downgrade you obsidian to v0.14.15. Remember to disconnect the wifi before you first time open obsidian v0.14.15, then turn off About > Automatic updates.

That works. Thank u!

this bug is when edit/live-preview mode ,it make anther. i use callouts, put timestamps into >[!note].And  setting like this

this bug is when edit/live-preview mode ,it make anther. i use callouts, put timestamps into >[!note].And setting like this

It does not work.

this bug is when edit/live-preview mode ,it make anther. i use callouts, put timestamps into >[!note].And setting like this

It does not work.
you can see this
https://forum.obsidian.md/t/fix-problem-with-media-extended-plugin-when-switch-from-editing-to-reading/56432

this bug is when edit/live-preview mode ,it make anther. i use callouts, put timestamps into >[!note].And setting like this

@fireflysss It works! Thanks a lot!

I came up a workaround to this issue instead of switching mode back and forth, just use 3 panels. first split the editor into 2, then turn one into preview mode, click timestamp link in preview panel will open a video panel and all 3 are linked.

I recommend using JeffChien's method because it can be embedded in a list, although fireflysss's callouts method also works, it is not as flexible as a list when adjusting levels.
Here is image of the two methods

it's about the  function, setGroupMember()

Apologies for the long period of inactivity on this project. I wanted to inform you that the plugin has been fully rewritten for the v3 release. I'm currently preparing for the beta release. Once it's available, if you encounter similar issues, please don't hesitate to open a new issue. Thank you for your understanding.


updated iin

Api doc reference
Fetch All IINs Supporting Native OTP
Fetch All IINs with Business Sub-type

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 89.53%. Comparing base (079b9ff) to head (65d9481).

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #107      +/-   ##
==========================================
+ Coverage   89.43%   89.53%   +0.09%
==========================================
  Files          22       22
  Lines         426      430       +4
==========================================
+ Hits          381      385       +4
  Misses         45       45

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Include flagged data

At the moment flagged data such as estimated, provisional or break in time series are automatically discarded by the code.
In agreement with @SarahBetoulMubareka , we propose to include them modifying https://github.com/xapple/waste_flow/blob/c00dc4c4d30374c6c0513b80595bee092db626dd/waste_flow/zip_files.py#L122-L123
With
for col in map(str, years):
            # First extract potential numeric part
            df[col] = df[col].str.extract('(\d+)', expand=False)
            df[col] = df[col].apply(pandas.to_numeric, errors = 'coerce')

Hi Selene,
That sounds good. May I suggest that if you want to propose a modification to the code for review you should open a "Pull Request" instead of an "Issue". Or better yet, you can simply commit the change to the master branch after checking that all the tests pass. 👍🏻


[url_launcher_web] Fix a typo in a test name and fix quote consistency

Description
Fix a typo in a test name and fix quote consistency.
Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

Okay, I wasn't sure if it was worth the churn of bumping the package version.

Okay, I wasn't sure if it was worth the churn of bumping the package version.

Thanks @jamesderlin, this way this revision can be published to pub without having to think "why is this revision failing" :)

Published, thanks for merging!


retryer implementation to handle throttling exceptions on AWS

This change is an adaption of #387 / #442 for AWS provider
that should address #491 (which, as I get from the context, is AWS-specific)

Hi @stanssh ! Thank you for your contribution!
I'm just not sure how we can e2e test that the feature works! Any suggestions? :smile:

Hi @stanssh ! Thank you for your contribution!
I'm just not sure how we can e2e test that the feature works! Any suggestions? smile
Hi @gusfcarvalho,
TBH I'm not sure either, I think the biggest challenge with e2e testing of this would be getting a stable rate limit hit in AWS, while at the same having verified retry parameters in place, "verified" in a sense we're sure that helps to handle sporadic limit responses from AWS end.
IBM retry is not being e2e-tested, AFAICT.

IBM retry is not being e2e-tested, AFAICT.

This is mostly because IBM is a community maintained provider, so we are (very) flexible on what gets e2e-tested there. Since AWS is an internally maintained provider, we tend to be a little bit more demanding on it.
Maybe there is a way to simulate it using localstack, but it wouldn't really be useful for our e2e tests anyways. @knelasevero @moolen WDYT? I'm up for not having an e2e here.

Hi
I have same issue in our AWS account. Could you please merge it.

/ok-to-test sha=3557fab


DPF: Test and Sample Updates

Feature #20
After #115
Upstream https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/issues/902
Description
Samples and tests currently use the InlineDataFlowController, which was a temporary solution until the Data Plane Framework was in place.
Upstream issue https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/issues/871 will use the HttpDataFlowController to perform communication between the Control Plane and the Data Plane.
Test and samples need to be updated to use the DPF instead of the InlineDataFlowController.
Integration tests and implementation of missing pieces are part of #173.
Acceptance Criteria

[x] Usage of InlineDataflowController is replaced by the HTTPDataFlowController
[x] Samples and tests leverage the Data Plane for data transfer

Tasks

[x] Review PR for upstream issue 871
[x] Update samples and integration tests

Put on hold, conversation on Tuesday 22/03 required to move forward.

Observability will be taken care by #173

Upstream PR https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/pull/1060


[BACKEND] Reduce code cleanup and bug fix for the fast path

https://github.com/openai/triton/issues/1715

Differences seem benign as the instruction counts/types do not change.
e.g.,
- or.b32    %r279, %r278, 1024;
- or.b32    %r280, %r278, 2048;
- or.b32    %r281, %r278, 3072;
+ add.s32   %r279, %r278, 1024;
+ add.s32   %r280, %r278, 2048;
+ add.s32   %r281, %r278, 3072;


.ply file

Can I display a .ply file in this plugin?

Hi,
Currently I support glb, gltf and obj format in this package


Wrong commutation result in PauliOp

Information

Qiskit Aqua version: master @ 367bc9d
Python version: 3.7.5
Operating system: osx

What is the current behavior?
A, B commute but commutes() method of PauliOp gives False.
Steps to reproduce the problem
A = X ^ Z
B = Z ^ X

A.commutes(B)
---
False

(A @ B) == (B @ A)
---
True

What is the expected behavior?
Suggested solutions
    def commutes(self, other_op: OperatorBase) -> bool:
        if not isinstance(other_op, PauliOp):
            return False
        # Don't use compose because parameters will break this
        dot  = np.sum(self.primitive.z * other_op.primitive.x)
        dot += np.sum(self.primitive.x * other_op.primitive.z)

        return (dot % 2) == 0

Thanks. I think
        if not isinstance(other_op, PauliOp):
            return False
        # Don't use compose because parameters will break this
        return self @ other_op == other_op @ self

or
        if not isinstance(other_op, PauliOp):
            return False
        # Don't use compose because parameters will break this
        return self.primitive * other_op.primitive == other_op.primitive * self.primitive

is intuitive.

@t-imamichi

        return self @ other_op == other_op @ self

This will raise if
from qiskit.circuit import Parameter
coeff = Parameter('c')
A = coeff * Z
B = Z

or
        return self.primitive * other_op.primitive == other_op.primitive * self.primitive

and this if
A = Z ^ Z
B = Z

Current commutes() calculates a qubit-wise commutativity.
I am not sure why, but this is confusing.

Recently I have implemented is_commutative for Pauli in Terra.
https://github.com/Qiskit/qiskit-terra/pull/5299

@ikkoham
Oh I see, though documentation is somewhat misleading.


Cannot set imu_data_rate >100Hz for CV7

Hi,
I'm trying to set the imu_data_rate to 250 Hz in my parameter file and I keep getting the following error
'terminate called after throwing an instance of 'mscl::Error_Communication'. The IMU is capable of data rates up to 1kHz, so I'm not sure why there seems to be a 100Hz limit built into the ROS driver. Can anyone assist me with diagnosing this problem?
Thanks

Hi @shahyaan, please open a bug report issue on https://github.com/LORD-MicroStrain/microstrain_inertial and fill out as much information as you can from the form, that would help me diagnose the problem, thanks


Cant import Grid

Hi, since a couple of days I can't seem to use the Grid component anymore.
When I build the next message appears
Cannot find module<EMAIL_ADDRESS>imported from<EMAIL_ADDRESS>
Im using<EMAIL_ADDRESS>with<EMAIL_ADDRESS>and<EMAIL_ADDRESS>Also when I import the Grid the next message appears
Svelte: Cannot find module wx-svelte-grid or its corresponding type declarations.
Cannot resolve definitions for module 'wx-svelte-grid'

I also get

Cannot find module wx-svelte-grid or its corresponding type declarations.

when trying to follow the demo steps in a typescript environment.

Same here


[TabsUnstyled] Introduce new component

Preview - https://deploy-preview-29597--material-ui.netlify.app/components/tabs/#unstyled-component
I've added one example without any styles and one customized. I got inspiration for the customized tabs from the homepah showcase.

From the MD implementation, I haven't implemented the indicator slot, I think the same can be achieved by using border/":before" element, or a custom component implementing the new slot. Also, I haven't implemented the scrollable logic in this iteration, we can discuss if we want it in by default.
The implementation itself is kind of a merge between the implementation in the lab and the one we have in the MD package.
TODOs:

[x] Introduce hooks
[x] Introduce unstyled components
[x] Add Tabs in the material-next package (with tests) [The scrolling logic is still in the component, we can extract this later in a useScroller hook or something similar]

What's the likeliness that once we try to integrate them back together it will work (which is not something we want to trade on)?

What do you mean by "integrate them back together"? I got confused with the overall concern of working in isolation from MD...

@danilo-leal I was asking about having @mui/materal depending on @mui/base; not living in parallel.
My fear is that all the stories I have heard in software about future integrations: never worked, it has to be designed from the beginning one step at a time. material-ui-pickers -> @mui/lab was under this case.

@oliviertassinari for this we have the material-next package (which @mnajdova I encourage you to use). It enables us to test integration while allowing experiments. We also won't need to worry that the stable MD components will be based on alpha Base components.
Another topic: @mnajdova, I see you've decided not to build the unstyled component on hooks. What's the reason for this?

@michaldudak If we can have @mui/material-next with all the demos and tests passing on it, then :+1: then the only downsides is about v5 -> v6 that might be a bit bumpy for developers to migrate, but at least, we ensure no regressions.

I was planning to integrate it in the material-next package, wasn’t sure if this should be in the same step, but happy to do it.
I focused on implementing the component now, and was adding tests for it. I will create a hook now and extract the logic, now that I have the test it’s easier to e sure that it works.
@michaldudak should I use the hook or the components in the material-next? I guess adding the same tests as in the material package should be enough for testing the component right?

wasn’t sure if this should be in the same step, but happy to do it.

@mnajdova @michaldudak Fair, in this case, we can scope down the constraint I propose we follow: an unstyled component is considered done once the material-next version of its is depending on unstyled, and all the tests+the docs of the material v5 are still functioning properly on the material-next version.

@mnajdova @michaldudak Fair, in this case, I can scope down the constraint I propose we follow. A new version: an unstyled component is considered done once the material-next version of it is depending on unstyled, and all the tests+the docs of the material v5 are still functioning properly on the material-next version. Would this work?

Makes sense 👍 I went here with using the hook after talking with @michaldudak as it looked like we would be using one level of abstraction less. Happy to change it to use the unstyled component too. Or maybe we can consider implementation two versions, but I think that would be too much.

An unstyled component is considered done once the material-next version of it is depending on unstyled, and all the tests+the docs of the material v5 are still functioning properly on the material-next version. Would this work?

I've got one concern with this - it may happen (that the unstyled component introduces changes that are not compatible with @mui/material v5 (like FormControl). In this case, your constraint won't be satisfied, as we are introducing breaking changes on purpose. As we discussed in the past, we shouldn't aim for 1-1 replacement of @mui/material but see this as an opportunity to introduce improvements.
As for unstyled component vs hook - there are tradeoffs with either option:

if we treat @mui/material-next as the candidate to actually replace @mui/material in v6 (or generally in the future), we should use the hooks version to minimize the levels of abstraction used (= improve perf). Similarly, Joy components could also be built using hooks. The downside of that is that we'll have no internal usage of unstyled components and they will have to be tested using unit and regression tests.
if material/next package is meant to just validate the implementation of @mui/base components/hooks, then we can go ahead and use unstyled components as the base of mui/material-next components.

if material/next package is meant to just validate the implementation of @mui/base components/hooks, then we can go ahead and use unstyled components as the base of mui/material-next components.

I would say it should replace it, so using the hook makes sense. So far, we are testing the component only via the demos, as far as I could see. Is this enough? Should we teach developers to use the unstyled component if they don't need some structural changes in the component but just want to style it, and to use the hook if they want to have more ownership on the rendered tree?

@michaldudak In https://github.com/mui-org/material-ui/pull/29597#issuecomment-968804988, note that my proposal targets @mui/material-next, not @mui/material. Does this change your point of view?

As for unstyled component vs hook - there are tradeoffs with either option:

Here, it seems that we are saying & doing that the headless API is better to build a design system. This leads me to wonder. Who will use the unstyled Component then?

note that my proposal targets @mui/material-next, not @mui/material
I'm aware of this. My point was that we may not always be able to successfully run the existing test suite without modifications as the API and/or behavior may change.

Who will use the unstyled Component then?
We will find out once they are actually used. It's not a big investment on our side to create unstyled components based on hooks and it may turn out some developers prefer to work on components, not hooks.

My point was that we may not always be able to successfully run the existing test suite without modifications as the API and/or behavior may change.

@michaldudak Oh yeah agree, I'm updating my proposal. My main thought was that we would be able to look at each test fail and see if it's a regression or intended.

We will find out once they are actually used.

Agree


September 27th, 2021 Community Meeting

Please add a topic in this thread and add a link to the Github issue associated with the topic.
Please make sure you give folks enough time to review/discuss the topic offline on Github before coming into the meeting
(optional) Paste the image of an animal :smile_cat:

Testing private git repositories in PRs using https://github.com/shipwright-io/build/pull/849

API review issue for builds - have we effectively replaced this with the SHIP process? https://github.com/shipwright-io/build/issues/516

more quay.io/shipwright image pruning ??
quay.io/shipwright/mutate-image:latest
Also, how does one get permission to even view https://quay.io/repository/shipwright ??

ko fix is https://github.com/google/ko/pull/448, but it's orthogonal to the image issue.
There's no image at quay.io/shipwright, so that's why that link 404s (for everyone, I assume). quay.io/shipwright/mutate-image does exist, and can be browed here: https://quay.io/repository/shipwright/mutate-image?tab=tags

@gabemontero I think what you want is https://quay.io/organization/shipwright

@gabemontero I think what you want is https://quay.io/organization/shipwright

you are correct @coreydaley :-)

Agenda item: participate in Hacktoberfest? https://hacktoberfest.digitalocean.com/

Minutes:

Git server PR - defer to next meeting.
API review issue - we should close this issue for more focused issues. Any outstanding wants/discussion points should have a separate issue created.
quay.io/shipwright/mutate-image doesn't have a latest tag. We update our nightly build to tag latest as well as nightly, however this can lead to complexities in generating the release. Will be discussed further in an issue.
Hacktoberfest - we probably aren't ready to participate. A lot of changes are in flight, we don't have enough "good first issues" for new contributors.

Issue about missing latest tag: https://github.com/shipwright-io/build/issues/877


Images for Product Variations

Hello everyone
In Product Variations page and in Variations  table we can see Images column but i don't see any upload button for upload image per each Variation. how we can upload images for each product Variations  . for example i have three color and i want upload images for each color and in product details page when user select red color we show images of red color of product.
@thiennn

I am not sure I have time to implement this. At the moment, you can add all the images to the main product so that customers can view them.

Support admin to upload images for product variant. In the product details page merge those images with the main product. When a product variant is selected show that image

Blocked by this https://github.com/aspnet/AspNetCore/issues/6742


[Docs] Upgrade license.

Purpose of the pull request
ref #10346

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

Codecov Report

Merging #10365 (6296b6d) into dev (ffe809b) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev   #10365      +/-   ##
============================================
- Coverage     40.56%   40.55%   -0.01%
+ Complexity     4739     4736       -3
============================================
  Files           869      869
  Lines         35273    35273
  Branches       3935     3935
============================================
- Hits          14309    14306       -3
- Misses        19534    19535       +1
- Partials       1430     1432       +2

Impacted Files
Coverage Δ

...lphinscheduler/rpc/common/AbstractRpcCallBack.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...er/master/dispatch/host/assign/RandomSelector.java
77.77% <0.00%> (-5.56%)
:arrow_down:

...dolphinscheduler/remote/future/ResponseFuture.java
81.96% <0.00%> (-1.64%)
:arrow_down:

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 ffe809b...6296b6d. Read the comment docs.


[BUG] - Button animation seems to be broken on 2.3.6

NextUI Version
2.3.6
Describe the bug
The animation of the button on click doesn't work the same as in 2.3.5
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue

upgrade from 2.3.5 to 2.3.6

Expected behavior
On 2.3.5 the animation starts from the location of the click in the button.
on 2.3.6 it starts always in the middle on the X axis but seems to be right on the Y axis.
Screenshots or Videos
2.3.6:
https://github.com/nextui-org/nextui/assets/5081484/05a7eccc-7f7e-4c83-a25a-328736184005
2.3.5 (expected behavior):
https://github.com/nextui-org/nextui/assets/5081484/8c95577c-1587-45a4-893c-c69d58ba4c54
Operating System Version
macOS Sonoma 14 (arm64)
Browser
Chrome

Is there any update on  this? still happens on the latest version

@lgariv  update to latest version.  Issue resolved there

No longer reproducible in latest version.


MGMT-18417: Update oauth-proxy

Upgrade oauth-proxy to get the last security fixes.

/lgtm
/approve


[BUG] dust error tx when accumulating memo output with 0 value

Issue Description
when adding a memo with 0 value to outputs using coinselect/accumulative , psbt composite doesn't work properly,
resulting dust error when broadcasting the raw tx.
Solution

don't add memo output using coinselect/accumulative.
add memo using psbt.addOutput separately.

@mikewyszinski , we faced the same issue for ledger integration and solved by using psbt.addOutput instead.
let me know your thoughts

goign to modify the fix to avoid undercalculating fees if a memo is present


Feature request - "Cancel Submissions"

Hi,
Thank you for the awesome platform.
I'm running a competition, and due to some technical issues, I've had to cancel and resubmit a lot of submissions.
Hence, a feature suggestion would be to add a "Cancel Submissions" option similar to "Rerun/Delete Submissions".

Best,
Johannes

Interesting suggestion. However, as long as the cancellation does not really prevents computation (#872), this is not that relevant.

@Didayolo, so the cancellation doesn't really do anything?

@johanneskruse Actually it depends. If the submission is still in "Submitted" status, still not sent to a worker, then it is cancelled for real (from what I know). However, if it is already running, cancelling it won't stop the on going computation from the compute worker.

Makes sense, thanks for the clarification. During the issues encountered with #1473 I usually cancel submissions when they get congested (and backlog becomes too large, and people started submitted the same submissions over and over again), also to make it visible for participants that it is no longer submitting.


dotnet_style_prefer_is_null_check_over_reference_equality_method not included in .NET code style settings

I noticed that dotnet_style_prefer_is_null_check_over_reference_equality_method setting is absent from the master list under .NET Code style settings (bullet point list under h2 with id net-code-style-settings), item Expression-level preferences but it is documented further in the text in the corresponding section. Can we have it added to the list at the top?

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

ID: 5299f22f-4b0f-9e81-883e-d34b2b520bf2
Version Independent ID: 6a9db168-c592-29a0-59b7-1ff2f517e558
Content: .NET language conventions for EditorConfig - Visual Studio
Content Source: docs/ide/editorconfig-language-conventions.md
Product: visual-studio-windows
Technology: vs-ide-general
GitHub Login: @TerryGLee
Microsoft Alias: tglee

@obohaciak I went ahead and updated the documentation!

Thanks @mikadumont!


MDM deprecated - replace by PDM?

Hi @Luncher91,
I have a quick look at what you are building and it looks interesting to me. I have installed VS 2017 remote debugger and tried running ActivDbgNET but it fails on Type.GetTypeFromProgID("MDM.AD1"); inside of IMachineDebugManager GetMDM() method.
The error indicates that you are trying to instantiate MDM that is deprecated? This link suggest using PDM instead.
Also, would this debugger also be able to debug ASP classic (eg attach to w3wp process)?

Hi,
Or I might be completely wrong ... after reading a little bit, here I found out that PDM/SDM might be used just to provide debugging extension for Visual Studio. Or, it might be that Microsoft.VisualStudio.Debugger.Interop uses PDM/SDM to enable debugging for VS only.
I have found an example of how to build Lua debugger extension for VS here using VisualStudio.Debugger package.
And I also found JS/VBScript debugger here that might be interesting...
I have tried to do something with ClearScript example but I lack some proper knowledge to make something useful out of it, hope you might find it more useful. :)

@Vertygo  Any luck with implementing debugger with ClearScript  ?

@jaskaran0001 Unfortunately I haven't.


update dependent plugin versions

@gabemontero fyi, more plugin versions have bit-rotted.
@tdawson post 3.4, we're going to need to refresh/update a bunch of the dependent plugins we package.

@bparees 10-4


non-italic-monokai Theme

[x] Extension name: neos21.non-italic-monokai
[x] Extension GitHub or homepage:

https://marketplace.visualstudio.com/items?itemName=Neos21.non-italic-monokai
https://github.com/Neos21/vscode-non-italic-monokai

Thank you for your request! The extension is now live in the code-server extension marketplace.


Add commands to supported commands

Related to #146

Signed-off-by: Gökhan Özeloğlu<EMAIL_ADDRESS>

Hey @roseduan. Can you review this PR?

Applied CR requests in d7891f9. Can you review the PR again @roseduan?

LGTM

LGTM


[Feature] Add support for General Supply Documentation MRV submission

Fully tested against the deployed CI Test General Supply Documentation policy on staging:

Although the tests pass it appears that the Trust Chain on Staging hasn't appeared. Will need to investigate this.


ComparingOnlyFieldsOfType only provided types for comparison

Describe the bug
Assuming that this is not intentionally designed I chose bug, but it might very well be a feature request to further tweak the recursiveComparison behavior:
When comparing a nested structure the types provided in the comparingOnlyFieldsOfTypes not only affect the comparison but also the collection of values to compare.

assertj core version: 3.24.2
java version: 17
test framework version: junit 5.9.2

Test case reproducing the bug
The following test case will pass. However, when I use (NestedClass.class, String.class) as arguments for the comparingOnlyFieldsOfTypes the assertion will fail.
As said, this is probably by design but would be really great is if there is an option that the collection of values to compare does not filter out the NestedClass so that "A" and "B" are still collected to be compared.
I have a nested tree where a specific class occurs at different locations and I only want to compare the identifier field. This would require me to put all branches in the comparison to make sure they are reached.
@Test
    void test() {
        TestClass a = new TestClass(new NestedClass("A"));
        TestClass b = new TestClass(new NestedClass("B"));

        assertThat(a).usingRecursiveComparison()
                .comparingOnlyFieldsOfTypes(String.class)
                .isEqualTo(b);
    }

    @RequiredArgsConstructor
    private class TestClass {
        private final NestedClass nestedClass;
    }

    @RequiredArgsConstructor
    private class NestedClass {
        private final String nestedClassField;
    }

Thanks for reporting this, we'll look into it shortly !

This is a bug, we don't register the fields of types that don't match the compared types when these types could have fields whose type are in the compared types list.

As requested by @joel-costigliola
using version 3.24.2 the following assertion fails. Using 3.25.0-SNAPSHOT the assertion succeeds.
`
BuildRecipe buildRecipe = TestBuildRecipeBuilder.getBuildRecipe();
buildRecipe.getBuildItems().get(0).setBuildItemId("buildItemId");
buildRecipe.getBuildItems().get(0).getBuildItemChildren().get(0).setBuildItemChildId("buildItemChildId");
    BuildRecipe buildRecipe2 = TestBuildRecipeBuilder.getBuildRecipe();
    buildRecipe2.getBuildItems().get(0).setBuildItemId("buildItemId");
    buildRecipe2.getBuildItems().get(0).getBuildItemChildren().get(0).setBuildItemChildId(null);

    // basic recursive comparison
    assertThat(buildRecipe2).usingRecursiveComparison().isNotEqualTo(buildRecipe);

    // compare only the types with the differences. This doesn't work in 3.24.2 but does work in 3.25.0
    assertThat(buildRecipe2).usingRecursiveComparison()
            .comparingOnlyFieldsOfTypes(AbstractBuildItem.class, BuildItemChild.class)
            .isNotEqualTo(buildRecipe);

    // compare ignoring the types with the differences. This works in both versions
    assertThat(buildRecipe2).usingRecursiveComparison()
            .ignoringFieldsOfTypes(AbstractBuildItem.class, BuildItemChild.class)
            .isEqualTo(buildRecipe);

`
Very nice!
I did notice one additional difference. The field name for 'setBuildItemId' is 'buildItemId' so I checked what would happen if I specified comparing only that fieldname:
`
BuildRecipe buildRecipe = TestBuildRecipeBuilder.getBuildRecipe();
buildRecipe.getBuildItems().get(0).setBuildItemId("buildItemId");
buildRecipe.getBuildItems().get(0).getBuildItemChildren().get(0).setBuildItemChildId("buildItemChildId");
    BuildRecipe buildRecipe2 = TestBuildRecipeBuilder.getBuildRecipe();
    buildRecipe2.getBuildItems().get(0).setBuildItemId("buildItemId");
    buildRecipe2.getBuildItems().get(0).getBuildItemChildren().get(0).setBuildItemChildId(null);

    // basic recursive comparison
    assertThat(buildRecipe2).usingRecursiveComparison().isNotEqualTo(buildRecipe);

    // compare only the fields with the differences.
    // in 3.24.0 - Assertion error, objects are considered equal
    // in 3.25.0 - IllegalArgumentException "The following fields don't exist: {buildItemChildId}{buildItemId}"
    assertThat(buildRecipe2).usingRecursiveComparison()
            .comparingOnlyFields("buildItemId", "buildItemChildId")
            .isNotEqualTo(buildRecipe);

    // compare ignoring the fields with the differences, this results in the same assertion error for both 3.24.2 and 3.25.0-SNAPSHOT
    // in 3.24.2 - Assertion error:
    // field/property 'buildItems[0].buildItemChildren[0].buildItemChildId' differ:
    // - actual value  : null
    // - expected value: "buildItemChildId"
    // in 3.25.0 - Assertion error, same as in 3.24.0
    assertThat(buildRecipe2).usingRecursiveComparison()
            .ignoringFields("buildItemId", "buildItemChildId")
            .isEqualTo(buildRecipe);

`


DoubleValue update of inf str

Summary
When SQL is formatted using the FORMAT TabSeparatedWithNamesAndTypes in ClickHouse
the ClickHouseTabSeparatedProcessor will update the value as a String. In this case, if the double type is inf, -inf, or nan, it will not be able to be parsed.
Checklist
Delete items not relevant to your PR:

[ ] Unit and integration tests covering the common scenarios were added
[x] A human-readable description of the changes was provided to include in CHANGELOG
[ ] For significant changes, documentation in https://github.com/ClickHouse/clickhouse-docs was updated with further explanations or tutorials

@Chen768959 sorry for the delay
Can you some tests to cover

@Chen768959 sorry for the delay Can you some tests to cover
Sure


能够自定义故障报警的次数（微信、钉钉等）

目前，出现故障后，企业微信会一直报警，直到处理了故障，报警才会结束。
建议增加一个功能：能够自己定义，当出现故障后，微信等报警的次数

增加降噪方式，比如连续多少次才报警

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿

Add noise reduction methods, such as how many times in a row before calling the police

或者连续多少分钟异常，再报警
如果上次也是异常，且已经报警过了，就不用
如果上次是正常的，本次已经出发，就需要告警

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿

Or how many minutes in a row is abnormal, and then call the police
If it was also abnormal last time and the alarm has been reported, there is no need to
If it was normal last time and this time has already started, you need to warn

已支持告警收敛功能，重复告警在设置的一段时间收敛只发一次

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿

The alarm convergence function has been supported. Repeated alarms will be converged within a set period of time and will only be sent once.


Improve coverage of knative package (currently close to 6%)

See: https://app.codecov.io/gh/knative-sandbox/kn-plugin-func/tree/main/knative

@lance @zroubalik @lkingland can we merge this one now?

/kind chore

Now this should be the codecov chore link https://app.codecov.io/gh/knative/func

/assign

/assign @matejvasek

@salaboy we are now at 64% test coverage on the knative package. This puts us well into the "Usable" state as defined here: https://github.com/knative/community/pull/1157
I think we want to continue improving this to get to "Stable" (70%) but for the purposes of this issue, I think we can close it now and if we have a specific target (like 70%) we can create a new issue for that. It might be good, actually to have an Epic similar to the on-cluster build epic, with subtasks to track specific goals for specific packages.
Feel free to reopen this if you disagree and would like to discuss.


'async' modifier cannot be used with 'abstract' modifier

'async' modifier cannot be used with 'abstract' modifier
abstract async init(): Promise;

That is correct. An abstract method can not be async, because it has no implementation.
You forgot to fill out the issue template.

can i remove async is there any alternative i am getting this error 'async' modifier cannot be used with 'abstract' modifier

You can remove it, and then check out some JavaScript tutorials to learn what async actually does. And note that this is not a support forum.

The only two things the async modifier does is: 1. make a function return a promise, and 2. allow use of await in the implementation.  Since an abstract method has no implementation and you already have to declare its return type as Promise<Whatever>, the async is redundant in that context.

It looks like this is a question rather than a bug report. This issue tracker is for tracking bugs and active work on TypeScript itself, rather than a general forum for programmers using TypeScript to get help or ask questions.
You can ask questions on sites like Stack Overflow. We are not able to provide one-on-one support on the issue tracker. Please read the issue template carefully - it has important information on what kinds of reports can be acted on here, as well as links to useful TypeScript resources. Thanks!

What an utter pain.  No consideration for those of us who have to deal with legacy code.  A major re-write is now required.
Thanks Microsoft.

A major re-write is required, because a keyword is not allowed in a situation where it makes no sense and has no effect?

When dealing with legacy code, yes.

Having to remove one single word, resulting in the same behavior, constitutes a "major re-write"? Wow.

I didn't write it


apply anysize patch (seems to have been rolled back in 0.8.4 update)

This should fix #275

I don't really need this in my build because my build of dwm has a patch that makes it unnecessary.