Rename product and scheme to SwiftSockets

Now that we have the Pod ready, the problem is that CocoaPods names the framework in the same way as the pod (completely ignoring the xCode project), so right now if you build directly with xCode or with Carthage, the framework is named ARISockets.framework, but if you fetch the dependency with CocoaPods it is named SwiftSockets.framework.
What I did in this PR is renaming everything needed in order for the framework to be always built as SwiftSockets.framework (which IMHO is a way cooler name :+1:)
I think what Carthage fetches by default is the last tagged release, so you would need to do that after merging.

Hm, if we do this I'd rather rename the whole thing. Might give it a shot later today.

Please give the rename-to-SwiftSockets branch a try. Does it still need a scheme or something? If it's OK, I'll merge it in and make a release later.

Looking good, I also changed the name of the scheme in #14, it is not needed but otherwise when building with Carthage it says "Building sheme ARISockets"

Is this still open or are we good here? If not, what do you want me to change?

I think we are good! Thanks
2015-12-10 10:48 GMT+01:00 Helge Heß<EMAIL_ADDRESS>
Is this still open or are we good here? If not, what do you want me to
change?
—
Reply to this email directly or view it on GitHub
https://github.com/AlwaysRightInstitute/SwiftSockets/pull/13#issuecomment-163558537
.


Enable optimizer for CI

Feature Request
Describe the feature you'd like
Currently，we haven't enable optimizer for CI，we should enable it in 0.2.0 release

Resolved in #569


Parallels Tools out of date w/ PD 11 and boot2docker-1.8.1 image

The latest/default image is boot2docker 1.8.1, and the boot console seems to indicate Parallels Tools pieces being added/run, but the GUI insists that tools are out of date.
The GUI actions to try and update tools will of course fail because it wants to mount the prlstools.iso image on the CDROM which is already connected to the boot2docker.iso image.

Unlikely other guest systems, in boot2docker we have Parallels Tools preinstalled and currently they are a little bit outdated: https://github.com/boot2docker/boot2docker/pull/954
There is a special build of Parallels Tools and since it is bundled with boot2docker.iso, it could not be updated by the traditional way.
Parallels Desktop detects that tools version is different and shows yellow "!" label, which looks confusing. So, let it be a known issue.
But in fact, these Parallels Tools are functioning correctly. Please ignore the warning in GUI.
P.s. Probably, this behavior will be improved in the future, with Docker Machine 0.5.0.

@legal90 that makes sense, the issue however is that the PD support folks insist on trying to get the PD tools updated, and since that doesn't work, they claim the whole caboodle is "unsupported" - any chance you could get the PD Knowledge Base article that points to this copy of docker-machine to note the discrepancy?

I'm sorry for a later update - in Parallels Desktop 11.0.1 this issue have been worked around:
For boo2docker guests the Parallels Tools status is not displayed as outdated and "Update" button has been removed from the GUI.
@y3ddet Thanks again for catching this!


Pyimg4 and chunked kerneldiff

A couple optimizations that fix lower end Linux systems. Pyimg4 helps because it doesn't overflow the ram therefore locking up the machine. Kerneldiff patch is for the same reason.

faster, now, sorry

@verygenericname but what about pyimg4, img4 still locks up my pc


✨ Add structured meta data

Add METADATA.yaml to working group repository in order to provide the following data for #1699 in a structured way:

Group Name
Short Description
Facilitator
Members
Communication Channels

/cc @pbakaus

@rsimha can you please merge


Reset seqlet coordinates with respect to "--window"

The seqlet coordinates (per example) are returned relative to the "trimmed" contributions For example, if the user specificies a window of 100 with the "--window" argument, on a full sequence input width of 100 then the return seqlet coordinates, then the seqlet coordinates should be shifted by 450 bp when saving to the file MODISCO output file.
Alternatively, this could be just documented. I was trying to use the H5 file (after backwards conversion) to call seqlet hits on the examples and this messed me up for a couple of hours.

Could you clarify how you get a 450 bp shift when setting --window to 100? Doesn't it mean that there is a 100bp window centered on the peak center, and then all seqlet coordinates per example are with respect to that 100bp window? I am also trying to call seqlet hits and having issues. Thanks


[Bug] Regression handling RGB in XC modality

Describe the Bug
This sample is no longer rendered correctly: https://viewer.imaging.datacommons.cancer.gov/v3/viewer/?StudyInstanceUIDs=<IP_ADDRESS>.4.1.59<IP_ADDRESS>.1677425356.1733

For comparison, see how it used to work here: https://github.com/OHIF/Viewers/issues/3354#issuecomment-1673389784:

To download the files in that study (note - it is ~233GB!), assuming you have python and pip on your system, do the following:
pip install --upgrade idc-index
idc download <IP_ADDRESS>.4.1.59<IP_ADDRESS>.1677425356.1733

Steps to Reproduce
Load the sample study referenced in the above into the viewer.
The current behavior
First series shows grayscale with multiple slices arranged in a mosaic. Second does not load at all.
The expected behavior
Both should show up in color as used to work in the past given the screenshot in https://github.com/OHIF/Viewers/issues/3354#issuecomment-1673389784
OS
macOS
Node version
n/a
Browser
Chrome

For instance, if I want to debug this specific study without downloading it, how can I do that in my local OHIF since you said the DICOMweb server is public?
CC @igoroctaviano

@sedghi I am not an OHIF developer, so I cannot answer how to do it in OHIF configuration (@igoroctaviano can), but IDC public DICOMweb endpoint is this: https://proxy.imaging.datacommons.cancer.gov/current/viewer-only-no-downloads-see-tinyurl-dot-com-slash-3j3d9jyp/dicomWeb (documented in https://learn.canceridc.dev/portal/proxy-policy). Note that the "no downloads" wording in the URL is legacy, and we do not restrict that DICOMweb endpoint for downloads - as discussed in the link above.

DICOM PlanarConfiguration will indicate whether color image is ordered as RGBRGB or RRGGBB. Need to investigate.

Must be something else then. I get the impression that color image handling in OHIF is extremely fragile (whether compressed or uncompressed).

@dclunie what could be causing the imagine not to show as a single image in current v3 version, but rather a bunch of images, while it's shown as a single image in v2?

@dclunie what could be causing the imagine not to show as a single image in current v3 version, but rather a bunch of images, while it's shown as a single image in v2?

@pedrokohler, this is typically related to a decoding issue. I'd suggest rolling back to commits before any recent RGB/decoding changes, testing them one by one.
@sedghi, it might be a good idea to open an issue to add snapshot testing in CS3D to help prevent these kinds of regressions.
Here’s a similar issue we encountered previously: https://github.com/cornerstonejs/cornerstone3D/pull/829

There's a widespread problem with DICOM color images. Here's the core issue:

When dicom servers sends DICOM color images, they can convert the pixel data from one color space (like YBR422) to another (like RGB) as we know, however, these servers frequently don't update the metadata to reflect this conversion. So you end up with a mismatch - the metadata might say "YBR422" even though the actual pixel data has been converted to RGB.
Apparently the DICOM standard suggests that the Photometric Interpretation field should reflect the format of the stored data (am I right @dclunie ?). But this raises a question - what should happen when the data gets converted?
Due to this widespread inconsistency, we can't reliably trust the Photometric Interpretation value in the metadata. To work around this, we developed a solution that tries to detect the actual pixel data format by analyzing the values themselves (implemented here). While this approach improved our ultrasound image support and made things more consistent, we're still encountering some issues with it as you see in this issue

Take a look at these discussions for instance
https://discourse.orthanc-server.org/t/orthanc-convert-ybr-to-rgb-but-does-not-change-metadata/3533/3
I need help fixing the color settings permanently.

@sedghi if you can provide a reproducible example demonstrating DICOM non-compliance of Google Healthcare API DICOMweb implementation, we can escalate through our collaborators at Google to try to get it fixed. I do not know enough about this issue to reproduce it myself.

Can @dclunie clarify the DICOM standard's requirements for Photometric Interpretation? Should we update it to match the actual pixel data after conversion?

@sedghi @fedorov after lots of testing, I found that this PR was the responsible for making it fail: https://github.com/cornerstonejs/cornerstone3D/pull/829/files
I'll investigate further to see what exactly is happening there

@pedrokohler thank you, but let's wait to hear from @dclunie about the question asked by Alireza first!

Very long ... sorry ...
Here are few points to consider wrt. what the standard says about this and how it relates to @sedghi's description of the recent changes, and what might be needed to make this more robust going forwards:

when an image is encoded in an uncompressed transfer syntax, all of the DICOM attributes in the Image Pixel Module need to accurately describe the binary contents of the uncompressed PixelData attribute, including PhotometricInterpretation - e.g., if the pixels are RGB, then that's what it needs to say, if they really are YBR (e.g., were encoded that way be the ultrasound machine) then again, that's what PhotometricInterpretation needs to say (usually YBR_FULL); see "Native" format in PS3.5 and Photometric Interpretation in PS3.3.
if an image is decompressed, whether from a lossless or lossy transfer syntax, and re-encoded in DICOM, obviously the decompressed file is required to have the correct description of the decompressed PixelData in the Image Pixel Module attributes - the classic example being when a JPEG image in YBR_FULL_422 is color component converted into RGB during decompression; what the standard requires in this respect is obvious; problems arise when the encoder of the decompressed image fails to set Photometric Interpretation correctly - viewers may try to apply heuristics to work around this (e.g., it's YBR_FULL_422 but decompressed so its probably wrong so I will assume RGB) but like any heuristics, they may fail, as we are apparently seeing here
if an image is compressed, whether losslessly or lossy, then the image pixel data characteristics (including the meaning of the color components +/- downsampling of the chrominance channels) may or may not be expressed in metadata within the compressed bit stream, but if it is, that is always to be used "to control the decoding"; that said, the DICOM Image Pixel Module attributes are still required to be "consistent with the characteristics of the compressed data stream" (even though in practice they may sometimes not be); for lossy baseline JPEG, the compressed bitstream might not describe the color components, so DICOM Photometric Interpretation of YBR_FULL_422 is really  important to signal this, and RGB for compressed data is intended to indicated that the color components have NOT been transformed (as is the case with Leica/Aperio WSI, for example); the presence of a JFIF header is not required in the compressed bitstream, but if present, may signal YCbCr components rather than untransformed RGB components

From an application implementation perspective this can be even more challenging depending on what the underlying toolkits and libraries and codecs do and how much control there is over what they do (e.g., a lossy baseline JPEG decoder might always attempt YCbCr to RGB conversion even if they really were RGB, or always do it if a JFIF header is present, or check for the Adobe marker segment that signals RGB, or whatever).
To restate the obvious, the only way to mitigate against unexpected code changes causing failures is to test - have a good range of test inputs representing as many known good (and bad) variants as possible, and a decoded result to expect, and automate the comparison in regression tests. For properly encoded DICOM images (uncompressed, compressed and decompressed/re-encoded) there should be no question about the correct result. For "bad" images (e.g., RGB Photometric Interpretation for a YCbCr encoded lossy JPEG bitstream signaled by a JFIF header, or a decompressed JPEG that still has YBR_FULL_422 for the Photometric Interpretation) some heuristics may be implemented to work around this and need to be tested too but the heuristic should never prevent the correct handling of a correct image.
In the case of the Cornerstone PR #829 that was mentioned as responsible for the problem, there is a new function isColorConversionRequired() that is supposed to work around an [Orthanc server bug "Orthanc convert YBR to RGB but does not change metadata"](https://discourse.orthanc-server.org/t/orthanc-convert-ybr-to-rgb-but-does-not-change-metadata/3533/17), and which @sedghi also referred to. Unfortunately it seems that insufficient testing was done to assure that this workaround did not undermine handling of "correct" images in which the codec had handled the color component transformation (and chrominance channel upsampling; repeating it would screw things up, if that is what is actually happening.
The heuristic in isColorConversionRequired() seems to be trying to detect uncompressed chrominance downsampling based on the downsampling description in Photometric Interpretation matching the decompressed pixel data length, which is a whole other thing (and as @sedghi described, is often related to funky ultrasound images; some uncompressed or decompressed RLE ultrasound images really do have uncompressed color component downsampling). I don't actually see how the function (and its consequences if it returns true) actually specifically target the Orthanc defect anyway, other than by assuming that if it says YBR_FULL_422 but the decompressed pixel data length is not downsampled (i.e., it just equals columns * rows * samplesperpixel * bytespersample; I think the imageFrame must already exclude the padding byte to even judging by other code therein).
However, since our problem images should be Photometric Interpretation RGB and uncompressed, I am not sure how this PR is causing our images to fail, since isColorConversionRequired() should return false by my reading of it.
I assume there is no issue with the DICOMweb side of things, in that the image requested was returned uncompressed. If it had been requested with an Accept header of image/jpeg rather than application/octet-stream, and the server has lossy JPEG compressed them to satisfy the frame request (perhaps even retrieve rendered), and of course while doing that would very likely color space transform them, with no explicit means of signaling that (except perhaps a JFIF header included in the compressed bitstream). See also the warning about this sort of thing in the description in PS3.18. I.e., the metadata response and the bulk pixel data response would be inconsistent in such cases wrt. the characteristics of the pixel data. This is purely speculative on my part since I have now idea how OHIF is retrieving these images, or under what circumstances the routines in the PR get invoked.
I also see a bunch of stuff in the PR about Palette Color Lookup Tables, but that should not be relevant to us since they won't be in the problem image.

@pedrokohler you should also use samples mentioned in https://github.com/OHIF/Viewers/issues/2934!

@fedorov @dclunie the problem is the isColorConversionRequired function of the PR I sent above.
Once I force it to return true for the dataset above, it renders the image correctly.
@dclunie what else could be checked inside this function so that we would be able to tell that this image requires conversion? For instance, I could check to see if the modality is XC and always return true in this case - note that I don't know if this makes any sense, I'm just giving an example.

@dclunie Thank you David for the excellent DICOM color crash course. It will help us improve our color handling stability.

@fedorov It looks like this was really a cornerstone3D issue but it was already fixed in this PR https://github.com/cornerstonejs/cornerstone3D/pull/1457/files
I'm waiting for Bill Longabaugh to confirm that idc-slim does not have the master branch deployed, but rather an older branch that has a previous cs3d version being used.
If this is indeed the case, then we just need to deploy the master branch and the issue should be fixed.

I'm waiting for Bill Longabaugh to confirm that idc-slim does not have the master branch deployed, but rather an older branch that has a previous cs3d version being used.

You mean ViewersV3, not idc-slim, right?

You mean ViewersV3, not idc-slim, right?

My bad. Yes, I mean ViewersV3.

Replicating from Slack and to keep @dclunie in the loop. @pedrokohler can you please take a look?
Per @wlongabaugh:
OK, in the past, it appears the > 32 MB slices got sent as roughly ~20 MB slices, and this appeared to be due to a change in the Accept: transfer-syntax=* request header: https://github.com/ImagingDataCommons/IDC-ProjectManagement/issues/1574#issuecomment-1924983645
1:13
OK, I admit I was wrong, and yes it used to work, by getting the > 32 MB slices to work by getting them to be ~20 MB on the wire.
I note the current V3 viewer is sending this:
accept:
multipart/related; type=application/octet-stream; transfer-syntax=*; transfer-syntax=*
[1:12](https://cornerstonejs.slack.com/archives/GP0DDMVMF/p1730830348498009)

Is the second transfer-syntax=* (and w/o a ";") messing things up?

Checkout extensions/cornerstone/src/initWADOImageLoader.js that is the location that decide on the transfer syntax

@fedorov I removed the duplicate and just tested it with transfer-syntax=* and with transfer-syntax=*;, meaning both with and without semicolon. Still same error occurs in both cases.

@fedorov either way this error has nothing to do with this ticket. According to @wlongabaugh on Slack this same error is occurring in production right now.

Sometimes the type should be in quotes. We used to have an option to omit it, as including it can trigger an options request flow on some servers, slowing things down. However, sometimes it requires the type to be in quotes, like multipart/related; type="application/octet-stream"; transfer-syntax=*.

@wlongabaugh @pedrokohler note that while accessing IDC DICOM store directly - bypassing the proxy - I am able to visualize both series.
See demo here: https://app.screencast.com/QEePMcwuQOuWb.
Also note the type is indeed in quotes:

No server error

For this experiment, I utilized the v3 instance deployed by @igoroctaviano via https://github.com/ImagingDataCommons/idc-viewers-sandbox-gha-testing. I do not know where that version is relative to various IDC tiers.

Could it be that the proxy started dropping the quotes @wlongabaugh?

@fedorov The code that forwards the headers from the client to the Google backend has not changed.

The proxy code that passes the headers through to the backend is
headers={key: value for (key, value) in request.headers if key != 'Host'},

so however the Python requests package treats header quotes is what is happening.

It is true that the Python version has been upgraded, as the old version was no longer supported. Seems unlikely that the requests behavior would change for handling headers, but that is a difference.

But I see that the 32M+ slices series no longer loads in production either, where the headers are what they have always been:
accept: multipart/related; type=application/octet-stream; transfer-syntax=*
accept-encoding: gzip, deflate, br, zstd

the Python version is still 3.8, and the proxy code has not changed in many months. That is still running against v1 (not v1beta1) which implies Google changed some behavior since we deployed in the summer of 2023.

the headers are what they have always been

I have no means to ascertain what they have always been. I do observe that when I use OHIF sandbox instance against IDC DICOM store directly, the parameters are in quotes. I do not know if this has any effect on the issue we are discussing.

@fedorov  The important question remains. What size are the slices coming back from the store when hit directly: 32M+ or ~20MB?

@fedorov @dclunie @sedghi I was able to make it work with the current version just by forcing a transfer-syntax=1.2.840.10<IP_ADDRESS> instead of transfer-syntax=*
@dclunie @fedorov do we want to use this transfer-syntax in other cases as well or just this one?
@sedghi what's the best way to make OHIF use this transfer-syntax in this specific case or any other cases that Clunie and Fedorov specify?

Hmm, we don't handle transfer syntax on a case-by-case basis. Honestly, I don't think there's a good way to do this. Didn't Pedro try the latest Cornerstone3D, and wasn't it working?

To make sure we don't forget: this sample used to work without the need to explicitly specify transfer syntax back in February 2024!

You can remove the transfer syntax and try it; it's not mandatory.

@fedorov Again, can we please find out what size are the slices coming back from the store when hit directly: 32M+ or ~20MB?

@pedrokohler it is more important to understand the source of the regression than to find a workaround to just make it work. Can you please try all the items we discussed yesterday, and report on the findings?

Try to not include transfer-syntax=*, try not to have quotes, try to request single part
Look at the changes in the code around header
Go back to the version of ViewersV3 from February and test against the proxy and against DICOM Google server directly

I went back the versions of idc's ViewersV3 up to February and it did not work. The same issue happened.

@fedorov Again, can we please find out what size are the slices coming back from the store when hit directly: 32M+ or ~20MB?

It's over 32MB

I'm fixing the double transfer syntax here just FYI https://github.com/OHIF/Viewers/pull/4478

@sedghi @fedorov @wlongabaugh  FYI removing the transfer-syntax completely also works

removing the transfer-syntax completely also works

Really? We had to add that to get it to compress back in 2023. That's weird. Sounds like a simple fix then?

@pedrokohler If your test that dropping the transfer-syntax worked was against v1 of the API, you need to check against v1beta1 as well.

FYI removing the transfer-syntax completely also works

@pedrokohler as before, when you say "works", can you confirm if the content returned is compressed or not?

removing the transfer-syntax completely also works

Really? We had to add that to get it to compress back in 2023. That's weird. Sounds like a simple fix then?

My read of the issue that you brought back is that we indeed had to remove it to compress back in February (not in 2023, based on the comment date). See below the screenshot of the issue that is in our private repo that you mentioned on slack.

when you say "works", can you confirm if the content returned is compressed or not?

@fedorov when I say it works I mean the proxy doesn't return a 500 error, and given its limit is 32MB it means it gets compressed. The responses come with ~27MB slices as opposed to the 32+MB of when we we're going around the proxy.

Perfect, great news! This also seems to indicate, if the comment in that older issue is accurate, that there is no change in the behavior of the GHC backend.
Next, can you please test this with v1beta GHC endpoint?
After that, can you please proceed with testing against the IDC proxy?
@wlongabaugh please remind us which tiers use which version of GHC API. I do not know where to find that information.

Next, can you please test this with v1beta1 GHC endpoint?

Can you provide a server url?

After that, can you please proceed with testing against the IDC proxy?

Hmm... not sure what you mean here. Can you elaborate?  You mean another proxy?

Sorry I missed that you tested against the proxy. We need to know the behavior with both direct access to GHC and via the proxy. While using proxy, you cannot choose API version, you can only do it while accessing directly, substituting v1 with v1beta1.
Are you able to download that study and make a Google DICOM store for direct testing, or you need help with that?

Are you able to download that study and make a Google DICOM store for direct testing, or you need help with that?

@fedorov I've never created a google DICOM store and I don't have access to IDC's GCP account, which means I'd need help indeed.

note that while accessing IDC DICOM store directly - bypassing the proxy - I am able to visualize both series.

I tried using the IDC fork's config file and the GCP server you sent in the message from the quote above, but I'm getting this error when I try to login

(also I'm not sure that by logging in with the default oidc config I'd be able to access this specific server anyway)

I was wondering how @pedrokohler would be able to access GHC directly, as he does indeed not have permissions.
The version of the API we are using is in the proxy runtime configuration file that lives in each tier. E.g. for test it in in gs://webapp-deployment-files-idc-test/proxy/proxy_runtime_config.txt.
The dev and test proxies are running v1beta1. Production proxy is still running v1.

@fedorov OK, I have reread my comment you highlighted above. https://github.com/OHIF/Viewers/issues/4382#issuecomment-2465278258 Yes, I originally thought it was the other way around, that we needed the transfer-syntax key/value to make it work. But yeah, we needed to drop the key/value to make it work. This all makes sense now. That was my first impression of this when it came up, that there was some change in compression that made it work, back at the start of 2024. So drop the transfer-syntax in V3.

transfer-syntax=* means allow ANY transfer syntax on the server, omitting transfer syntax means LEI

https://www.dicomlibrary.com/dicom/transfer-syntax/
Explicit VR Little Endian
I believe it's a sensible default for OHIF to follow. It tells the server not to bother with conversion and to send whatever is available, as OHIF can support it. This reduces the server's response time. If there's an issue with using *, it indicates a bug in OHIF.

The issue is not a bug in OHIF, but the fact that by providing it in the request, Google will not try to compress the 35MB+ slices it sends out.

This reduces the server's response time. If there's an issue with using *, it indicates a bug in OHIF.

The issue in this case is not with OHIF per se, but with the specific combination of OHIF/data/user requirements. To summarize the long thread, we need to have the server compress the data before sending. We have good reasons for that. With the current transfer-syntax=* we cannot satisfy our needs.
Can this be somehow addressed at the OHIF level without us making customizations specific to our fork/use case?
I do not think this use case is limited to IDC.

@pedrokohler I created a DICOM store that has Visible Female XC study: projects/idc-sandbox-000/locations/us-central1/datasets/fedorov-dev-healthcare/dicomStores/visible-female. I gave you all the necessary permissions. You can use this store to test against DICOM store bypassing proxy, and compare behavior between v1 and v1beta GHC API.

@fedorov if you make sure the server already has compressed data stored for that study then the * should work, no? Can't you call an api in google and ask for change in stored data format?

First, based on the explanation from @dclunie yesterday, compression in this scenario is done at the HTTP level - it does not change the transfer syntax.
Second, one of our principles in IDC is not to modify the original encoding of the images in the files that are ingested into the DICOM server.

BTW I added all transfer syntax test data we had here https://github.com/cornerstonejs/cornerstone3D/pull/1568
Seems like we only are not supporting
DeflatedExplicitVRLittleEndianTransferSyntax

I will reiterate that one way to deal with this is to have the proxy look at the URLs being requested, and if it includes ones of these problematic studies, it can modify the requests headers (ditch transfer-syntax=*) for those studies to kick off the compression.

I will reiterate that one way to deal with this is to have the proxy look at the URLs being requested

@wlongabaugh in my list of preferred options, increasing complexity of a proxy that is specific to IDC is not at the top. IDC proxy based solution will never benefit other users of OHIF Viewer, and I think there is a good chance that this situation is not unique to IDC. In our case, we need this because of the proxy limitations on the buffer size. In other cases users may want to have smaller buffer size due to limited network bandwidth.
@sedghi would it be possible to add an option for the client/application to choose whether transfer-syntax=* should be included or not?
I hope the answer is yes, and then the client could perhaps estimate the size of PixelData based on frame size and bit depth, and decide based on that whether it should be included or not and request server compression? This could also be controllable via a config option. Just one idea. Maybe there is a better way to know what is the size of the object in the original encoding.

Yes, setting it is optional, but if you don't, every compressed study will be decompressed, as far as I know. So, perhaps we should have a per-study configuration or something similar.

CC @wayfarer3130

@sedghi, you wrote:

Yes, setting it (transfer-syntax=*) is optional, but if you don't, every compressed study will be decompressed, as far as I know.

Short version - I don't think that is a compliant way of receiving compressed frames, even if Google does support it, so you should not be asking for transfer-syntax=*
TL;DNR:
The details here are a digression from the topic at hand (getting back uncompressed XC images, and getting large ones through the proxy by deflate applied at the Content-Encoding rather than Transfer Syntax level), ...

The deflate CAN be applied at hte content encoding level, but it means to apply default to the multipart/related body as well as to the overall body - that is what static dicomweb does for encoding such images.

... but it is relevant since it has apparently been observed that requesting multipart/related; type="application/octet-stream"; transfer-syntax=* has an undesirable (and relevant) side effect of blocking Content-Encoding ( e.g., as deflate) as distinct from the simpler (and correct)multipart/related; type="application/octet-stream".
If you request application/octet-stream (whether single part or multipart), as I understand it. the standard says you will get back uncompressed bytes, and the Google documentation implies you will get back uncompressed bytes because the default TS is uncompressed (and it will perform decompression as necessary if it can).
However, I don't think it is legal for a DICOMweb server to return in a frame request a compressed bitstream in an application/octet-stream media type. That media type is only to be used for uncompressed data.

Yes, that is actually correct - it should have been
multipart/related; type="image/*"
with a secondary accept of
multipart/related; type="application/octet-stream"; q=0.9
The application/octet-stream is only valid for DICOM encoded responses, and I had conflated that with using it on the frame level retrieve.
Preferring images over application/octet stream, all of them encoded in multipart/related.
It would also be acceptable to do the following set:
image/*, application/octet-stream; q=0.9, multipart/related; type="image/*;q=0.8, multipart/related; type="application/octet-stream"; q=0.7
Or, if known that the server supports single part, just the first two.

Rather, the server is required to return image/jpeg for JPEG transfer syntaxes, etc. Otherwise how would you know (without inspecting the compressed byte stream) what scheme is used to compress the byte stream in the response, if it was not signaled in the media type in the returned Content-Type header field? See DICOM PS3.18 <IP_ADDRESS>.2 Compressed Bulkdata Media Types.
I know that the Google server documentation for retrieval of frames says it supports multipart/related; type="application/octet-stream"; transfer-syntax=* and further that

"For application/octet-stream the bulk data will be returned in whatever format it appears in the uploaded DICOM file"

but I think this is fundamentally wrong; returning compressed byte streams as application/octet-stream is not what the standard specifies; I don't think you should be requesting that, even if it (sometimes) works.
Perhaps you should be requesting multipart/related; type="*/*" or similar, if you don't care how it is compressed or if it is uncompressed, and the Content-Type in the response should tell you what it actually is. Perhaps even multipart/related; type="*/*"; transfer-syntax=*

Yes, but added several request types with q parameters to indicate preference.  I don't know that it will work for image/* but technically it is supposed to work AFAIK.

However there is a warning in the Google documentation about image/jpeg defaulting to a .70 TS that is not supported, so if the images are lossless JPEG such as TS .50, then perhaps type="*/*"; transfer-syntax=* will freak it out.
How is OHIF figuring out what compression scheme is used when requesting multipart/related; type="application/octet-stream"; transfer-syntax=* (perhaps there is a transfer-syntax parameter on the Content-Type of the response that you are cuing off)?

There is the transfer syntax in the response data - which is actually required to distinguish between image/jpeg for .50 and .70

I hope you are not using any TransferSyntaxUID value that might be present in the metadata (if they return Group 0x0002 data elements in the metadata, which they shouldn't) as opposed to (trying to) use QIDO AvailableTransferSyntaxUID in CP 1901. I don't think that Google supports AvailableTransferSyntaxUID though. To state the obvious, if Group 0x0002 TransferSyntaxUID is returned in the metadata, its value will not necessarily match whatever is in the returned pixel data if any transcoding has occurred.

No, that isn't used there.  However, the AvailableTransferSyntaxUIDs is used to sub-select the accept header to the comrpessed format if it is provided in the original metadata.

I will do some more experiments wrt. what the Google server does or does not support, but the bottom line is that I think a more robust approach by OHIF to getting back (lossless) compressed pixel data if that is the form it is available in may be required if you have felt the need to use multipart/related; type="application/octet-stream"; transfer-syntax=* for that reason and don't have an alternative pathway already.
I would be very interested to hear if you have experience with DICOMweb servers other than Google's that respond to multipart/related; type="application/octet-stream"; transfer-syntax=* with anything other than uncompressed pixel data.

It is supported fairly generally - I can think of at least 4 PACS systems supporting it.
Bill
PS @dclunie - thanks for responding to that, I had assumed incorrectly that the transfer syntax parameter was supported for this accept header as well as the others, and apparently others have made the same assumption.

According to  <IP_ADDRESS>.1 Multipart Media Types, it is actually legal to request
multipart/related; type="application/octet-stream"; transfer-syntax="*"
I agree the interpretation of that is a bit iffy, but the request itself is legal according to the syntax.

:) "iffy" is one way to put it - "wrong" is another!
I will draft a CP to add a note to PS3.18 to indicate that returning compressed streams in application/octet-stream is not correct, and that combined with transfer-syntax="*", it should only match uncompressed transfer syntaxes (perhaps including the recent encapsulated uncompressed to get around size limits). Then WG 27 can discus the matter.

BTW. AvailableTransferSyntaxUIDs should not be in the metadata - it is an instance level search transaction attribute.

Following this exchange - are there any practical and actionable implications regarding how to proceed with achieving the behavior needed for our use case - requesting compression applied to Content-Encoding?

Also CCing @amazy the lead for orthanc team, if he can help us with how ohif should send requests

Since I'm not a standard expert at all, I'll not comment on the standard itself or on how it should be understood.
I must admit that Orthanc's behavior wrt to multipart/related; type="application/octet-stream"; transfer-syntax="*" was inspired by the Google implementation and it was not incompatible with our understanding of the standard.
That being said, here is how Orthanc works:

in the /metadata route, Orthanc always returns the PhotometricInterpretation is it is stored in the DICOM file stored in Orthanc whatever the Accept headers received.
if called on ../frames/1with transfer-syntax="*", Orthanc will return the frame without any transcoding -> the PhotometricInterpretation returned in the /metadata route will match the one from the pixels
if called with .e.g transfer-syntax="1.2.840.10<IP_ADDRESS>", Orthanc will transcode the frame and will potentially return pixels with a different PhotometricInterpretation than the one returned in /metadata

For this reason, we concluded, together with @sedghi, that using transfer-syntax="*" was the best (and only) option for OHIF to receive pixels from Orthanc with the PhotometricInterpretation matching the one returned in an earlier call to /metadata.
We are, of course, open to making Orthanc more standard compliant if it needs to be.  In such a case, that would be great to have access to a few well documented test scenarios or scripts for everyone to validate their implementations.

I will work with @dclunie on making sure that the CP that he has started has examples of how to ask for the image in a compressed format which is standards compliant, as that is a very common question and given how many people get it wrong, it is clear we need some clarification as to what is and is not allowed.

@amazy the PhotometricInterpretation question (and whether the value in the metadata response is applicable to whatever compressed or uncompressed pixel data is retrieved) should be somewhat orthogonal to the question of whether compressed pixel data byte streams are obtained in the correct manner using image/* or incorrectly using application/octet-stream.

Wrt. drafting examples, many years ago (2018/10/23) I posted the following message to the WG 27 mailing list and got zero responses. It is out of date now (since we have both updated the standard, extended the use of single part responses, and added specific solutions such as AvailableTransferSyntax, which may or may not have been implemented), but I think we should be able to improve it and generalize it and come up with an exhaustive list of requests and appropriate responses:

Hi WG27 folks
I have some general questions related to compressed images that
arise particularly when using anything other than baseline JPEG
images sent to an origin server.
Suppose I send a multi-frame lossless JPEG 2000 (.90) image
to an origin server, and for the sake of argument, assume it
stores it in the supplied Transfer Syntax.
Note that it is multi-frame image, not single frame.
As a QIDO-RS and WADO-RS user agent:

How do I tell in what Transfer Syntax the origin server has
stored an image (i.e., that I sent it as .90)?

1a. in QIDO-RS, is (0002,0010) permitted in the request/response?
1b. in RetrieveMetadata, is (0002,0010) permitted in the response?
1c. in the dcm-parameters of the RetrieveMetadata Content-Type,
even though there is no inline binary data returned?

What comes back in the response if I accept in a RetrieveInstance
request only:

2a. '/' ?
2b. 'multipart/related; type="application/dicom"' ?
2c. 'multipart/related; type="application/dicom"; transferSyntax=...90' ?
2d. 'multipart/related; type="application/dicom"; transferSyntax=...91' ?
2e. 'multipart/related; type="application/dicom"; transferSyntax=...70' ?
2f. 'multipart/related; type="application/dicom"; transferSyntax=...50' ?
2g. 'multipart/related; type="application/dicom"; transferSyntax=...1' ?
2h. 'multipart/related; type="image/jp2"' ?
2i. 'multipart/related; type="image/jpeg"' ?
2j. 'multipart/related; type="application/octet-stream"' ?

What comes back in the response if I accept in a RetrieveInstance
request all of:

3a. 'multipart/related; type="application/dicom"; transferSyntax=...90,
multipart/related; type="application/dicom"; transferSyntax=...91,
multipart/related; type="application/dicom"; transferSyntax=...70,
multipart/related; type="application/dicom"; transferSyntax=...50,
multipart/related; type="application/dicom"; transferSyntax=...1' ?
3b. 'multipart/related; type="image/jp2",
multipart/related; type="image/jpeg",
multipart/related; type="application/octet-stream"' ?

What comes back in the response if I accept in a RetrieveFrame
request only:

4a. '/' ?
4b. 'multipart/related; type="image/jp2"' ?
4c. 'multipart/related; type="image/jpeg"' ?

What comes back in the response if I accept in a RetrieveRendered
Frame request only:

5a. '/' ?
5b. 'multipart/related; type="image/jp2"' ?
5c. 'multipart/related; type="image/jpeg"' ?

What is the difference, if any, if the image is sent in (.91) in
the first place, rather than (.90), remembering that .91 can be
lossless or lossy (reversible or irreversible)?

If the response contains a DICOM PS3.10 file, or its metadata,
and any Transfer Syntax conversion performed involved further
lossy compression:
7a. is the SOP Instance UID changed?
7b. are any mandatory Lossy Compression attributes set?

For each answer, where do you think it is currently specified
in the standard, and is the behavior required or optional?
David


samtools view arguments in alignReads.sh/detectAllelicConcatenated function

I assume the following line
$MEA_BIN_SAMTOOLS view -bt $PARAM_REFFASTA "$PARAM_OUT_PREFIX".sam > "$PARAM_OUT_PREFIX".unsorted.bam

should be updated to
$MEA_BIN_SAMTOOLS view -b "$PARAM_OUT_PREFIX".sam > "$PARAM_OUT_PREFIX".unsorted.bam

or at least to (in case of using STAR)
$MEA_BIN_SAMTOOLS view -bt `dirname $PARAM_REFFASTA`/chrNameLength.txt "$PARAM_OUT_PREFIX".sam > "$PARAM_OUT_PREFIX".unsorted.bam

in alignReads.sh
PARAM_REFFASTA points to the folder, not to the file chrNameLength.txt.
Samtools manual says
The -t and -T options provide additional reference data. One of these two options is required when SAM input does not contain @SQ headers, and the -T option is required whenever writing CRAM output.

In case of STAR sam file already includes header, so we don't need -t. As for the other tools I didn't check.

Good find. As you say, when using STAR, samtools must be using the sam header information because the code points to the folder, not chrNameLength.txt.
This is one example of many redundancies in the code which ensures that each aligner (bowtie2, bwa, tophat2, STAR, bismark) is handled properly post-alignment.
Of course, implementing these changes will improve the code and I will do so, thank you.


Error: fontVariationSettings and ttcIndex

    "tns-ios": {       "version": "4.2.0"     },     "tns-android": {       "version": "4.2.0"     }
Unable to apply changes on device: emulator-5554. Error is: Failed to build plugin nativescript-google-analytics :
Error: Command ./gradlew failed with exit code 1 Error output:
/Users/nalexeev/.gradle/caches/transforms-1/files-1.1/core-1.0.0.aar/fdc1653b7147869a0140773583eb43f4/res/values/values.xml:133:5-70:AAPT: error: resource android:attr/fontVariationSettings not found.
/Users/nalexeev/.gradle/caches/transforms-1/files-1.1/core-1.0.0.aar/fdc1653b7147869a0140773583eb43f4/res/values/values.xml:133:5-70: AAPT: error: resource android:attr/ttcIndex not found.
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':verifyReleaseResources'.

com.android.ide.common.process.ProcessException: Failed to execute aapt

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 3s

@Nurgunkalol  Hello. I had a similar situation. The following release is a root cause of this issue.
https://developers.google.com/android/guides/releases
In my case, I needed to fork this repository and change following lines to use the old version of Google Play Services.
Before:
https://github.com/sitefinitysteve/nativescript-google-analytics/blob/cc486f90d31222297fa8952ccc6c147a229b48ed/src/platforms/android/include.gradle#L11
After:
implementation "com.google.android.gms:play-services-analytics:16.0.0"

@Nurgunkalol Fixed version is here.
https://github.com/sovation/nativescript-google-analytics


chore: refactor PodInstancesTable

while trying to consolidate implementations for the ServicesTable and the
PodInstancesTable (we'll also later need to have a look at the
ServicesInstancesContainer) these changes emerged.
They help in comprehending what's going on and will be utterly helpful when
fixing the FilterBar on that Table (which has several bugs, as i learned during
this exercise).

:tada: This PR is included in version 5.0.39 :tada:
The release is available on:

v5.0.39
GitHub release

Your semantic-release bot :package::rocket:


does not contain a CMakeLists.txt file.

I'm unable to build the project.  It says:
CMake Error at CMakeLists.txt:14 (add_subdirectory):
The source directory
C:/.../libapt-master/deps/glfw

does not contain a CMakeLists.txt file.
CMake Error at CMakeLists.txt:16 (add_subdirectory):
The source directory
C:/.../libapt-master/deps/libbig

does not contain a CMakeLists.txt file.

You didn't use "git clone --recursive" probably. So the glfw submodule is missing (and for that matter all other submodules)

when looking at the example I get alot of "GL_INVALID_VALUE error generated. Invalid clear bits" when I hover over  anything I can do about that?

What is going on? :D

I closed it. Then had a question. Opened it up. fixed it and closed it again.


Salesianos pizarrales

Please add my school to the list, thx!!
https://www.salesianospizarrales.com/

@arubioliva I am sorry, I have to close the request without merging, because you made a mistake in a request and requested to merge too many files, most of them do not relate to the organization which you would like to add to this repository. Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


Use stricter assertions

Use stricter assertions

[Current coverage][cc-pull] is 72.89%

Merging [#15][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master        #15   diff @@
==========================================
  Files             4          4
  Lines           343        343
  Methods          19         19
  Messages          0          0
  Branches          0          0
==========================================
  Hits            250        250
  Misses           93         93
  Partials          0          0

Powered by Codecov. Last updated by [4595394...a78775f][cc-compare]
[cc-base-branch]: https://codecov.io/gh/mpociot/laravel-apidoc-generator/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/mpociot/laravel-apidoc-generator/compare/459539456a1a6c039f9b8f8fff7aaff13db8b088...a78775f62b8d922169ed23bbf6f5d649225287be
[cc-pull]: https://codecov.io/gh/mpociot/laravel-apidoc-generator/pull/15?src=pr


Fix json files cleanup when generating manifests

Fix #498
Fix #515

@lilic @kakkoyun would you mind telling me if this does the trick?
Since we are also generating a kustomization json file outside of the manifests directory, I wanted to try this approach instead of removing the file manually.

Let me verify, missed this somehow!

Sadly this errors out for me.

find: -delete: manifests/setup/0namespace-namespace: relative path potentially not safe
find: {}: No such file or directory
find: {}: No such file or directory
find: {}: No such file or directory
find: {}: No such file or directory
find: {}: No such file or directory
find: {}: No such file or directory
find: -delete: manifests/setup/prometheus-operator-clusterRole: relative path potentially not safe
find: -delete: manifests/setup/prometheus-operator-clusterRoleBinding: relative path potentially not safe
find: -delete: manifests/setup/prometheus-operator-deployment: relative path potentially not safe
find: -delete: manifests/setup/prometheus-operator-service: relative path potentially not safe
find: -delete: manifests/setup/prometheus-operator-serviceAccount: relative path potentially not safe
make: *** [manifests] Error 1

@brancz @lilic I addressed your comments, PTAL

Awesome, thank you!


Custom Audio Voice clone using elevenlabs API key

Hello, I want voice clone application on my custom audio data, can anyone provide me with the python code using ElevenLabs API key.
please refer the steps below.
step 1: Upload custom audio/path to custom audio
step 2:  Select the voice_id/voice from elevenlabs //like Adam, Rachel etc.
step 3: select the model
step 4: your custom audio file generated with the dubbing voice of Adam
step 5: Finish
Thank you!

Please see the README for how to do so! https://github.com/elevenlabs/elevenlabs-python?tab=readme-ov-file#clone-voice

audio = client.generate(text="Hi! I'm a cloned voice!", voice=voice)
brother I want audio file instead of text.
audio = client.generate(file = audio.mp3, voice=voice) // for reference may be code like this
I want correct code for voice dubbing.
Thank you!


Custom functions to determine whether or not to pin/unpin headroom element

In a modified version of this that I changed, I added the ability to pass in two new options: shouldPinCheck and shouldUnpinCheck (couldn't think of better names). These are functions that must return true/false. They are fired inside the shouldPin/shouldUnpin functions in the return statement.
Therefore, if a headroom goes to unpin and the shouldUnpinCheck returns false, the headroom element shouldn't be unpinned. Same thing for the shouldPinCheck but opposite.
If it was useful to me, I thought it may be useful to someone else as well. Maybe this should be added into the codebase.

Closing as this is effectively a duplicate of #38 and the PR #125 offers a potential solution


Bridge mode

What was wrong?
The real impetus for adding native "bridge" capability to trin came when the HeaderWithProof type was added to the spec. After implementing it in trin (#488) I set about implementing it in ethportal-bridge. This wasn't as straightforward as I hoped, and I had trouble locating a suitable merkle proof library that was compatible with how we wanted to use these proofs. Anyways... I came to the conclusion that it might not be worth duplicating all the types b/w trin and ethportal, so I started this branch of work to experiment with native bridge capacity in trin. Trin as a bridge also offers some other benefits (namely speed, it takes ~ 5-6 minutes to offer an epoch's worth (8192) of headers).
I'm not convinced trin as a bridge should / can replace eth-portal. I'd consider our general "bridge" architecture still an open question, but one that we should decide sooner rather than later to avoid any further unnecessary duplication of work. It's probably best discussed in some upcoming sync w/ all the client teams.
How was it fixed?
This pr introduces basic bridge functionality to trin.

Fetch Headers / Uncles / Receipts from geth asynchronously
Offer Header / HeaderWithProof / Bodies / Receipts to the portal network.
2 modes.

latest - track the head of the chain
backfill start at genesis

To-Do

[ ] Add entry to the release notes (may forgo for trivial changes)
[ ] Clean up commit history

Copying my comments from Discord here...

Generating a HeaderWithProof requires access to the HeaderOracle in order to lookup the epoch accumulator (whether it's available locally, or sourced from the history network) and then generate the proof. To generate proofs with the "separate" architecture will require some extra complexity - either in the jsonrpc api (eg some kind of special Offer endpoint) or internal logic inside trin-history that will automatically add the proof.

Trin's bridge takes advantage of rust's nice async api, and spawns many tasks concurrently. I'm not confident that our jsonrpc server can handle this (at least until we complete the transition to jsonrpsee) without sacrificing the gains from executing async tasks.

I'd like to re-endorse my preference for leaving trin's bridge as "native" (as how it exists in the current pr). For the reasons above, along with others mentioned during the call. It reduces the overall complexity of the code. Imo, a single, moderately-sized file (bridge.rs) does not necessarily constitute "bloat" . We can always extract it down the road, if the necessity proves worthwhile, but atm I feel like it's perfectly viable to leave the bridge functionality as "native"

And adding some clarifications...

There are two ways I can see us doing this. Imo, neither is ideal.

Add a custom jsonrpc endpoint (eg portal_historyOfferHeader). Since we only get a Header from geth - this endpoint will take the Header as a param - and then generate a proof (using the HeaderOracle) before offering the HeaderWithProof to the network. My thoughts... Do we really want to add yet another custom Offer endpoint to our api?
Inside the jsonrpc handling for portal_historyOffer - we add some custom logic to detect an eligibleHeader, and if so, we generate and attach a proof. But now that I type this out, this obfuscates some fairly significant logic, and I don't see this as a legitimate option anymore.

This bridge implementation fetches 128 geth headers across 8 spawned tasks concurrently. This repeats, until it has an epoch's worth of headers. Then it (more or less) repeats this process to fetch uncles & receipts. Within these concurrent tasks, the content is offered to the network over jsonrpc.

Our jsonrpc server - in its current state (pre #ogneev ) is fragile. I come across broken pipes fairly frequently, even with sending single commands. I'm skeptical that our jsonrpc server can withstand the assault of offer commands. Now, transitioning to jsonpsee will stabilize our server, and add support for batch commands. I don't see the benefit of wasting time, wrangling with a fussy jsonrpc server (in its current state), when we have a more stable implementation coming down the pipeline. This isn't an argument against the merits of extracting bridge into an "external" service, just an argument that it's not worth extracting until our jsonrpc server stabilizes.

@ogenev
I do appreciate the time you took to type those out, thank you. I think it will be better if we continue this discussion during sync tomorrow, but for now / posterity, i'll jot down some quick thoughts.

Ok, but fluffy is also implementing a "native" bridge. So then, is the effort of a client-agnostic bridge worth it just for "ultralight"?
Every bridge node design we've considered is accompanied by a running node. Maybe this idea would be useful down the road (like years from now), but it doesn't even come close to a priority / important use case to consider imo.
...
Yes, I'm against duplicating code, but I'm also hesitant to extract every little piece of trin-core into it's own package - until it's necessity is sufficiently justified. In the case of ethportal-api with glados, I believe it was sufficiently justified. In this case, I'm not so sure I agree, but I definitely don't see it as a priority.
Same as number 4
I don't agree. We expect all trin users to have some familiarity with the command line. This is how they are expected to manage allocated machine resources.
I haven't thought this one through yet... but I don't see why this would be a problem with the "native" design.
Again, I don't see why this would be a problem with the "native" design

Ultimately, I think it's best if we continue this discussion in sync tomorrow, I find it much easier to come to a consensus via dialogue. But if I were to summarize my opinion on this matter...
Perfect is the enemy of good. "Native" bridge mode is not intended (yet) for users. We don't have users. Even if we did, I don't see a strong argument for why we should build it for their use. Bridge architecture should be considered "in-house" at least for this year until we can deliver an mvp. It should be fast, and functional. Our goal is to build a functional mvp network. Not a pretty, easy-to-use client for end users that supports their every dream (eg running their own bridge).

Following up from our 1-1 convo, do you still feel good about merging this into a branch instead of master? If so, you can create a branch and modify this PR or open a new PR against it. It's still nice to get a quick look at the code, but it doesn't have to be held to the same standard.
I also remember that you wanted to rebase on top of some other PR that was in progress. Which one was that?

@carver My thinking was that I would just leave this branch (bridge) as the main branch to track bridge development. All future updates / bugfixes to the bridge would be opened up in a pr against this branch. And then, when / if we're ready to merge bridge functionality into master, I'll open up that pr and the bridge code can be reviewed then.

I don't like that PRs against it would be in the "wrong" repo, and that releases would be coming from your personal fork. I'm okay with it as a temporary situation. If we're still using your repo branch in 3-6 months, then the priority to move it to an ethereum/trin branch will go up a lot, from my perspective.

@carver Sorry, I misunderstood your suggestion. No problem moving this into it's own branch. Closing this pr in favor of #552


Disable Project Files checkboxes during deploy

Currently you can update the Project Files while a deployment is occurring. Should the entire webview be disabled during the deployment?

Triage discussion: we're OK with this behavior, but if we get more user feedback on it, we will reconsider.


[Blade] Cannot overwrite twice same block

I have a following view structure:
A.blade.php
@section('example')
Hello!
@show

B.blade.php
@extends("a")

@section('example')
@parent
Hi!
@stop

C.blade.php
@extends("b")
@section('example')
@parent
Bonjour!
@stop

Expected result:
Hello!
Hi!
Bonjour!

Actual result (second @overwrite does nothing)
Hello!
Hi!

I think it is a same problem as described here: http://stackoverflow.com/questions/18417130/laravel-4-extending-a-section-declared-in-a-master-template-more-than-once

This is unfortunately a limitation of our system. If you can figure out a better way, that would be really awesome. :)

Is this even a limitation? It seems to work for me (though I'm not doing the duplicate "extends" thing.)
@appcia Have you tried using @append instead of @stop (that way you also don't need the @parent)?


Announcement: Highlighting real-time reconstruction of a corridor with RealSense D435i and T265

Hi everyone,
In the YouTube video link below, software developed at Intel Labs China called FAST Mapping is used in conjunction with RealSense D435i and T265 to map a long corridor in real-time.
https://www.youtube.com/watch?v=dvyha4ftj7E
Video description: "This video shows the reconstruction of a long corridor in a university building. It was done by FAST Mapping, a software package developed at Intel Labs China.  FAST Mapping takes pose-aware depth image sequences as input, and fuse all the measurements into a 3D map.  It runs in real-time on a Intel Core CPU.   The input data in this show are from the OpenLORIS-Scene datasets, recorded by a robot equipped RealSense cameras".
Further details of the project can be found at the link below.
https://lifelong-robotic-vision.github.io/dataset/scene

Hello @MartyG-RealSense
Do you know if the FAST Mapping code is available on github  ?
Regards

I researched your request.  One of the people who worked on this mapping project, Xuesong Shi, is a research scientist based at Intel Labs China, so he is probably nearest to Intel Labs China's "FAST Mapping" code.
https://www.intel.com/content/www/us/en/artificial-intelligence/bios/xuesong-shi.html
I could not find any open source GitHub links to the FAST Mapping system.  I recommend mailing XuesongShi to ask them about it.  I will display his email address as an image so that spam tools can't extract it from this page!


Adds the preserving of  for strokes (in addition to fills)

@FWeinb  This PR adds to currently existing behavior where currentColor is preserved for fills (I added this probably a year ago :yum: ), even if the clean array contains fill. Specifically, this PR also checks and preserves stroke.
Below you see I'm adding a stroke color from use element to achieve a second color.

I ran grunt and tests passed locally
The reason we're exploring strokes at all, is that we currently control our svg icon sizes via CSS class like icon-large, icon-small, etc. What happens, is that the stroke ends up scaling in an undesirable way where we'd prefer to have the option of having it not scale. Also, it'd be nice to actually be able to leave strokes as strokes on export from the vector program ex. AI (right now we compound path everything). To achieve the "no scale" we're going to utilize Chris's idea here: http://codepen.io/chriscoyier/pen/dIlep essentially:
.no-scale {
  vector-effect: non-scaling-stroke;
}

The code looks good and makes sense. Thanks, @roblevintennis!

thanks @jonathantneal !


Removed duplicate Program Files entry in cmds

Commands listed "program files" twice.  Removed second reference to Program Files folder since %programFiles% was specified.
i.e. %programFiles%\Program Files\ (duplicate) to just %programFiles%\

#sign-off


fix(repository): meaningful error when server doesn't return data

The server returns an empty array. Never an empty response, right? If it's an empty response, JSON.parse() would throw. If it's an empty array or null, I still don't think we should just throw an exception. That's up to the developer implementing this.

for x =[] -> !!x === true. so, it empty arrays would handed over to populateEntities and JSON parsed
for x= null, undefined -> !!x === false, don't parse (would throw obscure error), but throw meaningful error now (that's the idea at least)

I get that, but null doesn't have to throw an error. You can get a 201 with an empty response, which shouldn't throw an error. I don't agree with this.

basically Exactly! currently that would throw a JSON.parse error down the line. i prefer fail fast and hard :smile:

sorry, not JSON.parse error, but an error from populated.markClean(); down a few lines, as populated is null
so the error thrown currently is 'populated.markClean() is not a function/undefined or something'. which isn't a helpfull error message

👍


How to check  optional enclosed param

Package version eg. v8, v9:
v9
Issue, Question or Enhancement:
Question
Code sample, to showcase or reproduce:

All hi, I want to validate the enclosed optional parameter how I can make it?
I have a field arr [1,2, 3] - this parameter not obligatory, and I need to check enclosure in this massif, but this massif not obligatory, now after dock I can make only this way**: validate: "required, dive, required"'** and the field arr obligatory has to be, and at me on a task not obligatory how to make check on enclosure without check on presence of the field?

Hey @AlexMain
If I understand you correctly, you only want to validate the array if it’s present.
I think you’re looking for validate:”omitempty,dive,required”
Please let me know if this is what you’re looking for :)

Thanks, it's work.

helpful tip :) I think it will be great if you can add it to the docs


feat: develop back-end of the ATRI blog

I've only implemented one class, because I'm going to let the team implement the other classes in the new task i open.


fix(portal): make home link close open menus

📥 Proposed changes
Ensure the home link closes any open full screen menus when clicked
☑ Submission checklist

[x] I have read the CONTRIBUTING doc
[x] yarn build works locally with my changes
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation (if appropriate)

💬 Further comments
affects: @fremtind/portal
ISSUES CLOSED: #917

Will fix in #990


form types

wildlife
wildlife tree
https://www2.gov.bc.ca/gov/content/environment/plants-animals-ecosystems/wildlife/wildlife-data-information/submit-wildlife-data-information/data-submission-templates

Riparian assessments
https://www2.gov.bc.ca/gov/content/industry/forestry/managing-our-forest-resources/integrated-resource-monitoring/forest-range-evaluation-program/frep-monitoring-protocols/fish-riparian

I'm going to start with a form that is used for reporting incidental observations. See info here at the bottom of the page for a brief description. This is uber cool. It's super casual, you can accumulate observations as you go and submit whenever you want I think.


fix: Fixed policy name when create_role is false

Fixes #369
Fixes #370

This PR is included in version 4.4.1 :tada:


⚠ Processors has degraded performance

In 7c1c883, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 72 ms

Resolved: Processors performance has improved in c9684a6.


App crushing

I'm getting following error and app become crushed while swipe 30-35 page of any pdf file:
AndroidRuntime: FATAL EXCEPTION: main
Process: com.example.pdf, PID: 11626
java.lang.ArithmeticException: divide by zero
at

Sometimes this error occurring after swipe few page, I think its a memory issue. Is there any workaround to control memory consumption??
PID: 29307
java.lang.RuntimeException: An error occured while executing doInBackground()
at android.os.AsyncTask$3.done(AsyncTask.java:300)
at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:355)
at java.util.concurrent.FutureTask.setException(FutureTask.java:222)
at java.util.concurrent.FutureTask.run(FutureTask.java:242)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)
Caused by: java.lang.NullPointerException
at com.github.barteksc.pdfviewer.RenderingAsyncTask.proceed(RenderingAsyncTask.java:103)
at com.github.barteksc.pdfviewer.RenderingAsyncTask.doInBackground(RenderingAsyncTask.java:67)
at com.github.barteksc.pdfviewer.RenderingAsyncTask.doInBackground(RenderingAsyncTask.java:31)
at android.os.AsyncTask$2.call(AsyncTask.java:288)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)

It's not memory issue, I will fix it soon.

Should be fixed in 1.4.

Whether this issue is fixed in 1.5.0 ? Please confirm.

As I wrote, it was fixed in 1.4


add scalar function for cast so it can be calculated at compile time

Fixes #8534

Codecov Report

Merging #8535 (b72bd95) into master (900f01f) will decrease coverage by 43.67%.
The diff coverage is 0.00%.

:exclamation: Current head b72bd95 differs from pull request most recent head 6c09550. Consider uploading reports for the commit 6c09550 to get more accurate results

@@              Coverage Diff              @@
##             master    #8535       +/-   ##
=============================================
- Coverage     70.65%   26.98%   -43.68%
=============================================
  Files          1674     1662       -12
  Lines         87743    87369      -374
  Branches      13279    13250       -29
=============================================
- Hits          61999    23580    -38419
- Misses        21439    61587    +40148
+ Partials       4305     2202     -2103

Flag
Coverage Δ

integration1
26.98% <0.00%> (+<0.01%)
:arrow_up:

integration2
?

unittests1
?

unittests2
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...n/function/scalar/DataTypeConversionFunctions.java
0.00% <0.00%> (ø)

...in/java/org/apache/pinot/core/common/Operator.java
0.00% <ø> (ø)

...operator/AcquireReleaseColumnsSegmentOperator.java
0.00% <ø> (ø)

...he/pinot/core/operator/BitmapDocIdSetOperator.java
71.42% <ø> (+3.24%)
:arrow_up:

...g/apache/pinot/core/operator/DocIdSetOperator.java
96.29% <ø> (+3.43%)
:arrow_up:

.../pinot/core/operator/InstanceResponseOperator.java
82.05% <ø> (-2.95%)
:arrow_down:

...apache/pinot/core/operator/ProjectionOperator.java
76.92% <ø> (-8.27%)
:arrow_down:

...re/operator/StreamingInstanceResponseOperator.java
0.00% <ø> (-76.93%)
:arrow_down:

...erator/combine/AggregationOnlyCombineOperator.java
75.00% <ø> (-1.93%)
:arrow_down:

...core/operator/combine/DistinctCombineOperator.java
76.92% <ø> (-0.86%)
:arrow_down:

... and 1272 more

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 900f01f...6c09550. Read the comment docs.

Some thoughts:

one option may be to drop the cast function if it is casting something to a numeric type. For example intColumn > cast(10.3 as long) could just be rewritten to intColumn > 10.3 and things would still work fine.
we should probably throw a syntax error if user tries to do something like intColumn > '12.3' or intColumn > cast('10.3' as INT) (casting a string literal to an int value) and that will encourage the user to write query with proper literal values.
A cast function is probably more useful during run time if for example the user wants to force cast string column values into numerical values (for example WHERE CAST(stringColumn AS INTEGER) > intColumn. Otherwise, as far as compile time literals are concerned, it seems like just replacing the CAST function with literal would work? If the literal type is not compatible, then an exception will be thrown which will encourage user to fix the literal in the query?

Currently CastTransformFunction doesn't support multi-valued column casting. We should keep the scalar function and transform function consistent (either both support MV or both not support MV). IMO multi-value handling is a little bit tricky because of the array type (primitive vs boxed), and we should add some queries test to ensure it works end-to-end and covers ingestion, compilation, aggregation and post-aggregation. I'd suggest first adding the basic support for SV, and then having a separate PR to add the MV support

I agree that dropping MV support would simplify this a lot.

Some thoughts:

one option may be to drop the cast function if it is casting something to a numeric type. For example intColumn > cast(10.3 as long) could just be rewritten to intColumn > 10.3 and things would still work fine.
we should probably throw a syntax error if user tries to do something like intColumn > '12.3' or intColumn > cast('10.3' as INT) (casting a string literal to an int value) and that will encourage the user to write query with proper literal values.
A cast function is probably more useful during run time if for example the user wants to force cast string column values into numerical values (for example WHERE CAST(stringColumn AS INTEGER) > intColumn. Otherwise, as far as compile time literals are concerned, it seems like just replacing the CAST function with literal would work? If the literal type is not compatible, then an exception will be thrown which will encourage user to fix the literal in the query?

I agree, this is essentially what adding this scalar function allows existing mechanisms to do. This change allows replacing the cast function over a literal or over another function which can be calculated at compile time with the literal, by making a function available during query compilation - see CompileTimeFunctionsInvoker.

and we should add some queries test to ensure it works end-to-end and covers ingestion, compilation, aggregation and post-aggregation. I'd suggest first adding the basic support for SV, and then having a separate PR to add the MV support

Agreed ^ but post-aggregation is not supported (described in #8424) which should be a separate fix

Can we get this merged then? @Jackie-Jiang @walterddr


Some fixes and add for arm/arm64

Before sending a pull request, please review Contribution Guidelines:
https://github.com/google/syzkaller/blob/master/docs/contributing.md

Not sure if safe to sign CLA, so close


change download table to two-dimensions

e.g.:

Format
EN
CZ
DE
ES
FR
...other languages

docx
---
---
---
---
---
---

html plain
---
---
---
---
---
---

html with help
---
---
---
---
---
---

We have to discuss the final format.

Format
EN
CZ
DE
ES
FR
...other languages

docx
plainwith-help
plainwith-help
plainwith-help
plainwith-help
plainwith-help
plainwith-help

html
plainwith-help
plainwith-help
plainwith-help
plainwith-help
plainwith-help
plainwith-help

markdown
plainwith-help
plainwith-help
plainwith-help
plainwith-help
plainwith-help
plainwith-help

... other formats
plainwith-help
plainwith-help
plainwith-help
plainwith-help
plainwith-help
plainwith-help


No need to show BUY NOW button in the Booking product.

Terms

[X] Before you openning this issue, i have checked if the issue has already been reported.

Bagisto Version(s) affected
master
Issue Description
If there is any booking product here no need to show the BUY NOW button.
Preconditions
need to enable the buy now button options.
need to add booking product
Steps to reproduce

Go to 'Homepage'
Click on 'Booking Product'
See the error

Expected Result
In the Booking Product no need for the BUY NOW button.
Actual Result
But It is showing the buy now button.
Screenshots

Additional context
No response

please assign this issue to me


Is there any architecture document?

I am interested in Hoverfly and I want to know how it works, which components exist in it, how these components interact with others.
Is there any architecture document?

Hey @erkanerol,
There is currently no architecture documentation for Hoverfly. The reason for this is that we are currently in a beta stage and we often make changes to the architecture so that it is best suited to what is needed. Producing richer documentation including diagrams of the architecture will come as part of our 1.0 release.
The best way to follow the code is to look at core/hoverfly.go, specifically the processRequest(). This function is called to handle each request that is made to the proxy.


[WIP] add rabbitmq-server for end2end pubsub tests

added pika python lib for doing the testing on the client side
added rabbitmq-server installation. this part is currently not working. not sure if the root cause is related to the rabbitmq-server installation, since there are no log files. for example:

http://pulpito.front.sepia.ceph.com/yuvalif-2019-06-06_08:31:46-rgw:multisite-add_http_endpoint_tests-distro-basic-smithi/

manual installation using: yum, apt, and zypper was verified on: centos7, ubuntu16 and opensuse15.1

This PR is a needed for following test PR: https://github.com/ceph/ceph/pull/28263 to execute the amqp end2end tests

@djgalloway I'm in the process of adding notification to RGW (see https://github.com/ceph/ceph/pull/28971).
Unlike in the case of pubsub, the only tests that are possible with notification are "push" tests.
Allowing rabbitmq installation on the test nodes would enable these tests, as currently the feature is not tesable at all in teuthology.
Note, that once merged, using "notifications" would be recommended over fetching events from pubsub.
Would appreciate your help with this one!

The first commit 784fec9 and the last one d19794d can be squashed if the latter is really wished.

I'm just wondering why this test requires any dependencies on the teuthology server side?
I just don't know why I need all this on my teuthology server in my development box.
From other side, why not try and design a test so it could make use of some role and install there all the required stuff and run the tests and later grab results?

I'm just wondering why this test requires any dependencies on the teuthology server side?
I just don't know why I need all this on my teuthology server in my development box.
From other side, why not try and design a test so it could make use of some role and install there all the required stuff and run the tests and later grab results?

Agree. Even the HTTP tests that does not require any software are problematic when they require connectivity from RGW towards the servers executing the tests.
OTOH, this is much easier when running standalone test on you local dev machine (not in teuthology), as no other role is needed.
This would require different test code for local vs. teuthology execution of the test.
Will cancel this PR.


Running bigcode/starcoder2-3b model usingexamples/starcoder2/qlora.yml config failed

Please check that this issue hasn't been reported before.

[X] I searched previous Bug Reports didn't find any similar reports.

Expected Behavior
Running the code with this config, I saw the following error. I did a google and issue search, but did not find any hit

examples/starcoder2/qlora.yml

modules versions:

axolotl git hash: 8a82d2e0a443fb866b15d7bd71fffbd8171de44b  (pip -e .)
transformers              4.38.2
base docker: winglian/axolotl:main-py3.10-cu118-2.1.2

Current behaviour
Error log
ValueError: The checkpoint you are trying to load has model type `starcoder2` but Transformers does not recognize this architecture. This could be because of an issue with the checkpoint, or because your version of Transformers is out of date.

Steps to reproduce
accelerate launch -m axolotl.cli.train examples/starcoder2/qlora.yml

Config yaml
# snippet of `examples/starcoder2/qlora.yml`

base_model: bigcode/starcoder2-3b
model_type: AutoModelForCausalLM
tokenizer_type: AutoTokenizer
trust_remote_code: true

load_in_8bit: false
load_in_4bit: true
strict: false

datasets:
  - path: mhenrichsen/alpaca_2k_test
    type: alpaca

Possible solution
I updated transformer 4.38.2, but it still failed the same issue
Which Operating Systems are you using?

[X] Linux
[ ] macOS
[ ] Windows

Python Version
3.10.13
axolotl branch-commit
main/8a82d2e0a443fb866b15d7bd71fffbd8171de44b
Acknowledgements

[X] My issue title is concise, descriptive, and in title casing.
[X] I have searched the existing issues to make sure this bug has not been reported yet.
[X] I am using the latest version of axolotl.
[X] I have provided enough information for the maintainers to reproduce and diagnose the issue.

Hi @ehartford ,
Any suggestion or input would be appreciated.

Could you provide more stack trace?
According to this, try upgrade transformers? https://github.com/huggingface/text-generation-inference/issues/1620#issuecomment-1982177243


QGC not flashing PX4 on Cube Yellow but Identifying it as a flashable target for PX4

When I attempt to flash a cube yellow with QGC to flash PX4, I get the following error:
Found device: Hex/ProfiCNC
Connected to bootloader:
Version: 5
Board ID: 120
Flash size: 1998848
Unable to find specified firmware for board type
Upgrade cancelled
------------------------------------------
If upgrade failed, make sure to connect directly to a powered USB port on your computer, not through a USB hub. Also make sure you are only powered via USB not battery.
Upgrade cancelled
------------------------------------------

This is the case regardless of which version of QGC I use 4.0.5 or nightly. I have been told that the Yellow is PX4 compatible but have been having issues actually flashing one to PX4.
Here are the following related discuss posts on both cubepilot and PX4
https://discuss.cubepilot.org/t/cube-yellow-in-px4/1468
https://discuss.px4.io/t/proficnc-yellow-and-orange-cube/11848
https://discuss.px4.io/t/proficnc-yellow-and-orange-cube/11848/10

The Yellow Cube is not supported by PX4 at present.  ArduPilot and PX4 use essentially the same bootloader, and share the same protocol so that you don't have to re-flash the bootloader in order to switch between ArduPilot and PX4.  The error above is the upload script telling you that it found a bootloader, but does not know what board it is (because PX4 does not have Cube Yellow support).
I am working with other developers on support for the Orange Cube, however; that could potentially be out in a month or so.

The Yellow Cube is now available as the PX4 build target cubepilot_cubeyellow.

@JacobCrabill cubepilot_cubeyellow is buildable but not useable unless flashing using the SWD tool.  #15513 for additional info.


Add invalid test cases

Just a few examples of invalid usage

Needs the following:

Test case directory called invalid, next to the valid directory
A flat list of test case input files with descriptive names, e.g. missing_end_marker.in
A test case in test_file_sanitizer.py, test_sanitize_invalid(inp: str)


zeal: unstable-2021-12-25 → unstable-2022-10-02

Change of note: qt5 → qt6
Description of changes

Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Why the move to qt6? I'm not saying not to do it, but what is the reason?

In general because, Upstream added qt6 support on July ( https://github.com/zealdocs/zeal/pull/1420 )
Personally because qt 6.4.1 compiled out of the box with gcc12 and qt 5.15.7 didn't (checked, still the latest lgpl patch release) doesn't

The issue with qt6 is that the applications look like crap under KDE because the theme isn't picked up automatically. I'm much more in favour of doing something like this instead:
{
  zeal-qt5 = libsForQt5.callPac......;
  zeal-qt6 = qt6Packages.callPac......;
  zeal = zeal-qt5;
}

At least people have a choice between TheNewHotness and Doesn'tLookLikeTheRedHeadedStepChild.

Oh, I wasn't aware of that issue. Will amend the merge request like that.

Only tested zeal-qt6 on GNOME 43, could you test zeal-qt5?

Have a look at https://github.com/NixOS/nixpkgs/pull/202131 for how to deal with the differences between qt5 and qt6.

Oh right
(if isQt5 then [
    qtlocation
  ]

That is very useful.


AuthorManager::fetchByID limit and start do not work

Because the authormanager caches its authors before returning them, and the limits are only used on the non-cached query, you will get unexpected results when paginating or limiting a large array of author id's.
A possible fix would be to stop caching the author data at all, because generally it is only a handfull of records that is being cached anyway, and the additional overhead of the array_intersect and array_diff function calls will be worse than fetching one (or two) more records from the database by its primary key!

@brendo, @creativedutchmen: is this enough?

I think so, at least for the moment. It makes sense to remove the $where & $joins from fetchByID. The function name after all is not fetchByIDandWhere :D.

Okey dokey, pull request coming then :)


not working when second symbol is EURO

below apis aren't working:
https://exchangeratesapi.io/api/latest?symbols=INR,EUR
https://exchangeratesapi.io/api/latest?symbols=USD,EUR
https://exchangeratesapi.io/api/latest?symbols=JPY,EUR
however it works when base is not EURO
ex:
https://exchangeratesapi.io/api/latest?symbols=JPY,EUR&base=USD
please support base EURO as well.
Thanks in advance:)

I think EUR is the default base, so euro is supported.
The actual problem here is that checking for the rate of EUR-EUR doesn't output the value of ”1.0“.

Well, if you require EUR as a symbol when having EUR base, your code has issues :)

@JerryBels , I could handle with that code but if thats the case then
https://exchangeratesapi.io/api/latest?symbols=USD,INR&base=USD
this api shouldn't return with "USD":1.0 as base is already mentioned as USD.
It makes sense if returned value contain both symbols even if base is same.

same problem here


gamma distribution with rate parameter

The current gamma distribution takes scale as the second parameter, but sometimes we need rate instead.

done by https://github.com/ReMobidyc/ReMobidyc/pull/120


'add_child' use child type instead of factory type

Changed the logic for when adding a node inside of Node.add_child and TypedNode.add_child to use the given Nodes class (providing support for extending the Node class) instead of deriving the class from the default factory.
If the child has been checked to ensure it is a Node instance, there is no reason to use the default factory, rather use the class of the given Node, as it may differ from the default node factory.
All tests pass.

Thanks for contributing!


Refactor for #2112

Rename senderUuid to sender

Any reason this is a draft? Seems good

The current changes of this PR don't seem to cover all occurrences of senderUuid. This is the search result with keyword senderUuid in 21w11a (https://github.com/FabricMC/yarn/tree/87ebde22cc9f9c9a28109fab774763330cd2e7cf).
8 results - 6 files

mappings/net/minecraft/client/gui/ClientChatListener.mapping:
  5: 		ARG 3 senderUuid

mappings/net/minecraft/client/gui/hud/InGameHud.mapping:
  83: 		ARG 3 senderUuid

mappings/net/minecraft/network/packet/s2c/play/GameMessageS2CPacket.mapping:
   4: 	FIELD field_25133 senderUuid Ljava/util/UUID;
  10: 		ARG 3 senderUuid
  13: 	METHOD method_29175 getSenderUuid ()Ljava/util/UUID;

mappings/net/minecraft/server/PlayerManager.mapping:
  133: 		ARG 3 senderUuid

mappings/net/minecraft/server/command/CommandOutput.mapping:
  9: 		ARG 2 senderUuid

mappings/net/minecraft/server/network/ServerPlayerEntity.mapping:
  123: 		ARG 3 senderUuid

Superseded by #2306.


Updated the BWC workflow to have 2.2.0 as the backward supported version in BWC tests

Description
Updated the BWC workflow to have 2.2.0 as the backward supported version in BWC tests
Issues Resolved
#524
Check List

[X] New functionality includes testing.

[X] All tests pass

[X] New functionality has been documented.

[X] New functionality has javadoc added

[X] Commits are signed as per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #536 (7da92a9) into main (c7379f8) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main     #536   +/-   ##
=========================================
  Coverage     84.04%   84.04%
  Complexity     1019     1019
=========================================
  Files           146      146
  Lines          4188     4188
  Branches        373      373
=========================================
  Hits           3520     3520
  Misses          492      492
  Partials        176      176

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


Create Profile form validation

When required form inputs are empty we should show some feedback when user clicks submit button. Currently, nothing happens.

Related to https://github.com/oasisprotocol/oasis-wallet-web/pull/1913
https://github.com/oasisprotocol/oasis-wallet-web/blob/545a5f1bba7d24df715d8ca1013335a48f385c8a/src/styles/theme/ThemeProvider.tsx#L278-L286
Without customized colors:

Or move required from CheckBox to FormField and customize the error message:

If checkbox is not wrapped in FormField it also shows focus:


Add ARM builds for docker

Fixes #460

@blagojts I don't really like how much copy/paste goreleaser now has. One alternative could be to use https://github.com/docker/build-push-action What do you think?


New 21st May Update source need offset update

not only offsets bro struct has changed too!

https://github.com/anarh1st47/CSGOSimple/commit/d451465d5edca1aaf76a35fbc449f8892dfcd0ff

You have the source why not try learning something for once? Instead of making an issue

Because no one teaches me =(

Lean =(

Project rip?

@xbread , Looks like rip, but u may look for a forks, for example, my own:D


DSA <IP_ADDRESS> Strings : Implementation of Strings in C & C++

Description
Explain the implementation of strings in C and C++
Task

[ ] Audio
[ ] Video
[ ] Documentation

Note

While requesting the issue to be assigned, please mention your NAME & BATCH NUMBER.
Mention the type of contribution you want to make.
Kindly refer to the Issue Guidelines.
Do not use the assign command for this issue. Follow the above procedure.
In case you see that the issue has already been assigned, try to request a different task within the same issue.
Changes should be made inside the DSA/directory & DSA branch.
Name of the file should be the same as the issue.
This issue is only for 'GWOC' contributors of the 'DSA' Domain.

Domain
DSA
Type of Contribution
Audio, Video, Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

Domain
DSA
Type of Contribution
Audio, Video, Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

Pranjali R
DSA batch 7
I want to work on this issue

Documentation

@1PRatgit Assigning this issue to you for documentation.
Make sure to submit a PR within 7 days.
All the best !!

batch - 2
documentation
Dhruti Gandhi

/assign
->documentation

Prabha Kumari
Batch-1
Contribution type: Documentation

can I work on it?
Name-Tanvi Deshmukh
batch-5
Contribution type: documentation

The issue is already assigned.


the only person with more than 5 braincells here

i actually speak proper english and im not a 5 year old

Is defined not you apparently.


The number of count from influxdb is less than the csv file.

The version of influxdb is 2.0.0-beta.16.
Below is a sample of the content of the CSV data file.
#datatype dateTime,long,string,measurement
time,elapsed,label,threadname
1589330715899000000,47,ndomLoginPre_sum,2020vv6
1589330715906000000,47,ndomLoginPre,2020vv6
1589330715960000000,167,inForPassword_sum,2020vv6
1589330715961000000,167,inForPassword,2020vv6
1589330716130000000,11,ranchInfo_sum,2020vv6
1589330716131000000,11,ankBranchInfo,2020vv6

There are 1570897  lines in the 3.list.csv files, there is only one measurement 2020vv6, no other measurements.
I use the write command to insert the data with no error.
./influx write -b jmeterjtl3_1_50 -f ./3.list.csv -t 1II1-rPY7t_B349PIXYtNrAaZolOFkvCH3_GHurSkm8tznuI5sQux3KocUyogOljcG-gM4h6g7yL1231231231w== --format=csv
However, the count of the data in influxdb is 794985.
Below is the query command.
from(bucket: "jmeterjtl3_1_50")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "2020vv6")
  |> filter(fn: (r) => r["_field"] == "elapsed")
  |> count()
  |> yield(name: "count")

I have checked the start time and the end time, v.timeRangeStart is earlier than the start time of data, v.timeRangeStop is later than the end time of data.  I don't know why the count number is less than the csv file.

I know the reason. Because some of the datas have the same timestamp and the same tag. They are overwrited. So I will close this issue.


⚠ Bofrost.de has degraded performance

In 6c1d4e9, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1032 ms

Resolved: Bofrost.de performance has improved in e7a95ca.


Fails to install with "This extension is not installable on any currently installed products"

Tried to install the extension from Azure Data Studio but the vsix fails.
27/09/2018 02:37:06 - Microsoft VSIX Installer
27/09/2018 02:37:06 - -------------------------------------------
27/09/2018 02:37:06 - vsixinstaller.exe version:
27/09/2018 02:37:06 - 15.8.3252
27/09/2018 02:37:06 - -------------------------------------------
27/09/2018 02:37:06 - Command line parameters:
27/09/2018 02:37:06 - C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\VSIXInstaller.exe,d:\Users\AdamPawsey\Downloads\sqlops-combine-scripts-1.3.0.vsix
27/09/2018 02:37:06 - -------------------------------------------
27/09/2018 02:37:06 - Microsoft VSIX Installer
27/09/2018 02:37:06 - -------------------------------------------
27/09/2018 02:37:09 - Initializing Install...
27/09/2018 02:37:09 - Extension Details...
27/09/2018 02:37:09 - 	Identifier         : sqlops-combine-scripts
27/09/2018 02:37:09 - 	Name               : Combine Scripts
27/09/2018 02:37:09 - 	Author             : BateleurIO
27/09/2018 02:37:09 - 	Version            : 1.3.0
27/09/2018 02:37:09 - 	Description        : Create a single combined script from several files.
27/09/2018 02:37:09 - 	Locale             : en-US
27/09/2018 02:37:09 - 	MoreInfoURL        :
27/09/2018 02:37:09 - 	InstalledByMSI     : False
27/09/2018 02:37:09 - 	SupportedFrameworkVersionRange : [0.0,2147483647.2147483647]
27/09/2018 02:37:09 -
27/09/2018 02:37:09 - 	SignatureState     : Unsigned
27/09/2018 02:37:09 - 	Supported Products :
27/09/2018 02:37:09 - 		Microsoft.VisualStudio.Code
27/09/2018 02:37:09 - 			Version :
27/09/2018 02:37:09 -
27/09/2018 02:37:09 - 	References         :
27/09/2018 02:37:09 - Signature Details...
27/09/2018 02:37:09 - 	Extension is not signed.
27/09/2018 02:37:09 -
27/09/2018 02:37:09 - Searching for applicable products...
27/09/2018 02:37:09 - Found installed product - Global Location
27/09/2018 02:37:09 - Found installed product - ssms
27/09/2018 02:37:09 - Found installed product - Visual Studio Enterprise 2017
27/09/2018 02:37:09 - VSIXInstaller.NoApplicableSKUsException: This extension is not installable on any currently installed products.
   at VSIXInstaller.ExtensionService.GetInstallableData(String vsixPath, String extensionPackParentName, Boolean isRepairSupported, IStateData stateData, IEnumerable`1& skuData)
   at VSIXInstaller.ExtensionPackService.IsExtensionPack(IStateData stateData, Boolean isRepairSupported)
   at VSIXInstaller.ExtensionPackService.ExpandExtensionPackToInstall(IStateData stateData, Boolean isRepairSupported)
   at VSIXInstaller.App.Initialize(Boolean isRepairSupported)
   at VSIXInstaller.App.Initialize()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()

Azure Data Studio Version information...
Version 1.0.0
Commit cab8f3e37c9ac4367e0dacef5185da08bd8021c2
Date 2018-09-20T22:04:35.897Z
VS Code 1.26.1
Shell 2.0.9
Renderer 61.0.3163.100
Node 8.9.3
V8: 6.1.534.41
Architecture x64

Hi @apawsey and thanks for reaching out.
Extensions on SQL Ops Studio (and Azure Data Studio) still doesn't have the slick, intuitive interface as on VS Code. To install the VSIX file, you need to open the command palette (Ctrl+Shift+P) and choose Extensions: Install from VSIX and accept the security warning. From there, it should work well.
I'll update the readme as well to reflect this.
Just as a side note: Do you know about the VS Code version?


Links & Comments API Endpoints

https://www.reddit.com/dev/api#section_links_and_comments

[x] /api/comment
[x] /api/del
[x] /api/editusertext
[ ] /api/event_post_time
[ ] /api/follow_post
[ ] /api/hide
[ ] /api/info
[ ] /api/lock
[ ] /api/marknsfw
[ ] /api/morechildren
[ ] /api/report
[ ] /api/report_award
[ ] /api/save
[ ] /api/saved_categories
[ ] /api/sendreplies
[ ] /api/set_contest_mode
[ ] /api/set_subreddit_sticky
[ ] /api/set_suggested_sort
[ ] /api/spoiler
[ ] /api/store_visits
[x] /api/submit
[ ] /api/unhide
[ ] /api/unlock
[ ] /api/unmarknsfw
[ ] /api/unsave
[ ] /api/unspoiler
[x] /api/vote

While /api/submit is implemented it is missing some things like Video, VideoGif, and Poll types.
it is also missing flairs on creation, "events", collection, and whatever "post_set" is. Most of this info is included in the Submission class.
Not entirely sure how to properly test things like video & video gif. And flair stuff is blocked by #5 possibly? Need some way to get flair ids for this subreddit.


producer.connect() Missing in readme/ Example

Expected behavior
As your example in readme.md you didn't mention to connect to producer.connect(). It should have it and on error it should send message to next queue
Actual behavior
Without connecting to producer you will not be able to send message to next topic or retry topic. So its failing to send the message in next queue
Steps to reproduce the behavior

Connect to Kafka cluster '...'
Configure consumer with '...'
Publish message '....'
See error

Supporting materials

Additional Specs

Node.js version [e.g. 18.1.0]
Kafka version [e.g. 3.2.0]
KafkaJS version [e.g. 2.1.0]

Additional context
Add any other context about the problem here.

Merged in Main, So closing this now