Implement ICtCp color space per BT.2100

BT.2100 defines a new color space ICtCp. I can help add support for this to zimg.

Patches welcome. Is there an enumerated value for this system (matrix_coefficients)?

It's a multi-step process. Convert RGB to LMS then do PQ. Then matrix. It's spelled out in BT.2100.
Regards,
Dzung Hoang

On Mar 15, 2017, at 9:18 PM, sekrit-twc<EMAIL_ADDRESS>wrote:
Patches welcome. Is there an enumerated value for this system (matrix_coefficients)?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I mean for the standard colorspace triplet (matrix-transfer-primaries). Has a code value been specified by ITU/MPEG?
As for the details of ICtCp, I see that the transfer characteristics can be either PG or HLG.

The JCT-VC is preparing draft text to add ICtCp support in HEVC.
http://phenix.int-evry.fr/jct/doc_end_user/documents/25_Chengdu/wg11/JCTVC-Y1003-v1.zip
There is no assigned triplet for ICtCp. The matrix_coeffs syntax element value is 14 for ICtCp color space which is specified by equations (E-62) to (E-64). The transfer function can be PQ (transfer_characteristics = 16) or HLG (transfer_characteristics = 18), but the HEVC spec does not limit ICtCp to these two transfer functions.
  From: sekrit-twc<EMAIL_ADDRESS>
To: sekrit-twc/zimg<EMAIL_ADDRESS>Cc: dzung-hoang<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Sent: Wednesday, March 15, 2017 9:22 PM
Subject: Re: [sekrit-twc/zimg] Implement ICtCp color space per BT.2100 (#69)
I mean for the standard colorspace triplet (matrix-transfer-primaries). Has a code value been specified by ITU/MPEG?As for the details of ICtCp, I see that the transfer characteristics can be either PG or HLG.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

If a matrix_coeffs value has been reserved, that is sufficient. The constants described in BT.2100 appear to be specific to the Rec.2020 primaries. Is there a generalization?

ICtCp was designed with Rec.2020 colorimetry in mind. It is possible, but unlikely, that ICtCp will be used with another colorimetry.

I finished coding and am testing.

I just checked in my code changes. Please review and post comments here.
https://github.com/dzung-hoang/zimg

Can you upload a ICtCp test image with reference RGB image? I have left my remarks on your commit.

I updated the code per your comments.
https://github.com/dzung-hoang/zimg/commit/aa29d54e1a7ab5b6be7cfb0f33954e3fbf06b52b
I am working on generating ICtCp test image using HDRConvert used by JCT-VC/JVET.

unit test pushed
https://github.com/dzung-hoang/zimg/commit/a4b34069f569d9d98d41e438c03535c0b80bb9ef

I agree to WTFPL.
Regarding the ICtCp test image, I have a question on the image file format. I used testapp for my own testing and came across a limitation in the file format. This line of code in colorspaceapp.cpp colorspace_main() is a concern for me.
		ImageFrame src_frame = imageframe::read(args.inpath, "i444s", args.width, args.height, zimg::PixelType::FLOAT, !!args.fullrange_in);
When studying the code, it looks to me like this read function overrides the pixel type in the format specification with FLOAT. Why do you not allow other values of PixelType?

The colorspaceapp is only for testing the colorspace module, which works in float. The depthapp can generate floating-point images for use with colorspaceapp. You can upload the test image in any format you like, e.g. 10/16-bit yuv dump, BMP, etc.

Any updates?

I have been busy at work and am traveling. The difficulty I'm having is that I cannot find any coded content with ICtCp colorspace.
I thought I could use HDRtools from
https://gitlab.com/standards/HDRTools
but I don't trust it and need further study to verify that it works with ICtCp.
Regards,
Dzung Hoang

On Mar 30, 2017, at 6:55 PM, sekrit-twc<EMAIL_ADDRESS>wrote:
Any updates?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I finished testing on an SDR image and an HDR image. The files are attached.
test_images.zip

I tried to verify the code with your EXR images, but when I convert 'cosmos_2048x858_ictcp' to RGB as such:
testapp.exe colorspace -w 2048 -h 858 --visualise x.bmp<EMAIL_ADDRESS><EMAIL_ADDRESS>ictcp:st_2084:2020 rgb:st_2084:2020
The output image is all white pixels. I inspected the contents of the ICtCp EXR, and it appears all Y pixel values are near 1.0, which would be unusual for ST.2084. Can you explain what colorspaces the images you provided are in?

BT.2100 assumes that the R/G/B value of 1.0 corresponds to 10000 nits. Also, the floating point representation assumes full-range samples. Therefore you need to specify the following options: "--fullrange-in --fullrange-out --peak-luminance=10000"
The cosmos image is an image taken from Cosmos Laundromat and remastered in HDR by Netflix.
https://gooseberry.blender.org/
The color square is a sRGB image, and you need to set "--peak-luminance=100."
I am attaching the script I used for testing.
test_cosmos.zip

Thank you for the update. I was able to verify that the conversion from ICtCp to RGB matched the reference image with '--peak-luminance=10000'.
Can you comment on the numerical issues I mentioned in my edit? I reproduced the steps used in the pipeline as a unit test and observed severe error in the green channel for certain test vectors. The attached code can be used to inspect the issue in a debugger.
https://pastebin.com/XAKPnzpb
You can also observe these issues if you attempt to round-trip the color square, storing the intermediate result in half-precision (EXR).

I am in the process of implementing a DoubleToHalf conversion in Excel VBA to try to find a stable matrix.

I have not done this investigation yet, but it may be necessary to use gaussian solvers (e.g. sgesv) instead of an inverse matrix. From what I can tell, an LU solution requires no more FLOPs (9 muls) than a matrix-vector product in the 3x3 case.

I am looking into the effect of rounding modes when converting from float to half-float.

Do the standards or reference software provide any guidance on decoding ICtCp? On my end, I tried several approaches, but none of them were able to eliminate the problem. In fact, I noticed the issue can also be reproduced with the test vector (R=0, G=1.0, B=0). Even without any quantization of the intermediate result, this vector comes out as (R=0.09, G=1.0, B=0.014).
Part of the issue appears to be the dynamic range of the ST.2084 function, as even 1E-5 absolute error near zero in the linear domain maps to 0.1 in the transformed domain.

I just realized the aforementioned error would be invisible in PQ domain, since 1E-5 linear is 0.1 nits and 1.0 linear is 10000 nits. Perhaps there is no issue.

I cannot reproduce your result for RGB=[0,1,0]. See the attached spreadsheet. One round trip with 10-bit quantization of ICtCp gives me the reconstructed RGB=[-0.0039, 0.997691, -5.93973E-05].
ICtCp_Worksheet.zip

The discrepancy appears to be that you are using linear RGB values, but I am using R'G'B'.

I updated the spreadsheet to fix the quantization function to reflect A.2 in SMPTE-2084-2014, and also to allow selecting the bit-depth.
ICtCp_Matrix.zip
Not surprisingly, the accuracy depends upon the selected bit-depth. Bit-depth of 11 seems to be the sweet spot for preserving the primary colors after clipping.
For each bit-depth, we can tweak the LMS-to-RGB matrix to get exact round-trip of the primary colors. I'll attempt that next.

It was easier than I thought to derive a LMS-to-RGB matrix to get exact round-trip of the primary colors. We basically just compute round-trip LMS of the identity RGB matrix, and then compute the matrix inverse of the round-trip LMS. See the attached spreadsheet.
ICtCp_Matrix_v2.zip

That method only accounts for errors caused by quantization, but in a real workflow, numerical errors can come from many sources, particularly data compression. Consider this scenario:
(1) Movie in R'G'B' received from distributor or studio.
(2) Movie is converted to HDR10+/ICtCp and compressed with HEVC Main 10
(3) Movie is converted back to R'G'B' at display interface.
The general principle that should hold is that errors in ICtCp should result in proportional errors in RGB.

I would disagree with the proportional RGB error metric. The right metric should be perceptual-based. The attached document set has a good treatment of compression errors of IPT-PQ (ICtCp with SMPTE-2084 PQ) compared to Y'CbCr.
m37266-v2-m37266_IPTPQ_v2.zip

I agree that dE2000 is a better measure than RGB per-channel error. Can you provide a reference for computing dE2000 of HDR values? There are only 2^30 code points in 10-bit PQ space, so it should be possible to exhaustively test the conversion error.

This has a DeltaE computation module.
https://gitlab.com/standards/HDRTools
Look for DistortionMetricDeltaE.cpp.

I noticed that I was using the float-int cast in my quantization function, which was increasing the error considerably. After I applied correct rounding, I am seeing dE2000 of ~0.05 for (R=0,G=1,B=0) with 10-bit quantization and ~0.1 for (R=0,G=1,B=1). (R=0,G=1,B=1) appears to be the worst-case input. The simple YCbCr system has dE2000 of ~0.03 and ~0.01, respectively. The error appears to be stable and does not increase significantly with additional round-trips. Is this a reasonable result?

That seems even better than published results.

I will need to investigate again to ensure I am measuring dE correctly.

I did an exhaustive analysis and found that the overall dE was not worse than NCL for ICtCp as implemented in the commit.

Since one of the aims of ICtCp is to improve color gamut mapping, I suggest you allow ICtCp to be used with any gamut and not just BT.2020. I will use zimg for color gamut mapping experiments and I'm sure others would too if this restriction were removed.

That would require a different RGB-LMS matrix, would it not? I noticed the document in m37266-v2-m37266_IPTPQ_v2.zip proposed for LMS to be a value of color_primaries, but that appears to not have been accepted by JCT-VC.

Now that I think about it, generating ICtCp output with a different input color primaries is already supported by zimg. The input color primaries are first converted to BT.2020 and then ICtCp conversion is performed. The challenge for color gamut mapping is to figure out how to manipulate the ICtCp color space to reduce or expand the color volume. Then the inverse conversion is performed from ICtCp to linear BT.2020 RGB and then to the target color primaries.

@sekrit-twc Can you help us with ICtCp in ffmpeg? Please?https://trac.ffmpeg.org/ticket/7624
Dolby vision with ICtCp is being presented incorrectly.

@ValZapod I do not understand. Is there some action required from z.lib here?

@sekrit-twc Well, it is not working by default. (( And this is how it looks: https://github.com/HandBrake/HandBrake/issues/1728#issuecomment-448015493
Please?)))

@sekrit-twc I forgot to give you an issue in trac. https://trac.ffmpeg.org/ticket/7624
Also that file .ts with ICtCp. https://drive.google.com/file/d/1aP276spsqW-EbIIVrzdI9mwTYO87d0ac/view?usp=sharing

That's a problem with ffmpeg or ffmpeg's zimg wrapper (I assume you mean using zimg through ffmpeg's zscale filter).
I tried that sample, and ffmpeg returns "unspecified" for all relevant colorspace parameters. Is that file even valid?

@sekrit-twc What does it mean valid? Did you try to open it in VLC? It is good but for the color. It is just hevc in TS. (Though this hevc is called dvhe and it has dolby vision layer in NAL unit 62 and 63 (see https://trac.ffmpeg.org/ticket/5688) -- but this is not really important, this data can be skipped.)

@ValZapod
Dolby Vision uses the IPT colorspace, which is different from ICtCp. See Here and Here. IMHO, supporting IPT should be a feature request. However, given that IPT is Dolby-proprietary and is likely to be covered by patents, this decision should be made after careful deliberation.

Hello again, @dzung-hoang . Is there any information about the IPT colorspace? The linked document only states that "proprietary IPT [is] similar to BT.2100 ICtCp."

@sekrit-twc, there is some technical detail in the linked Dolby white paper.

I found the information on page 7.
[I P T] = [[0.4 0.2 0.2] [4.4550-4.85100.3960] [0.80560.3572-1.1628]] * [L M S]
Rotation = [[1 0 0] [0 0.4226 -0.9063] [0 0.9063 0.4226]]
Scalar = [[1 1 1] [1.4 1.4 1.4] [1 1 1]]
Is the takeaway that IPT differs from ICtCp in the matrix coefficients step, using the product of the aforementioned three matrices instead of the LMS-ICtCp matrix?

No, the page shows the derivation of ICtCp from IPT. If you were to apply all three matrix multiplies, you would end up with ICtCp.
This info is really background information on how ICtCp was derived from IPT. The exact details are in confidential Dolby Vision documents, which I have not seen. I suppose some more digging around might reveal a public source. I would dig into JVET and JCT-VC documents where Dolby made presentations on IPT and ICtCp. I would also check HDRConvert on github. This is the software JVET and JCT-VC uses to convert different color formats.
Sent from Yahoo Mail for iPhone
On Sunday, November 10, 2019, 1:29 PM, sekrit-twc<EMAIL_ADDRESS>wrote:
I found the information on page 7.
[I P T] = [[0.4 0.2 0.2] [4.4550-4.85100.3960] [0.80560.3572-1.1628]] * [L M S]
Rotation = [[1 0 0] [0 0.4226 -0.9063] [0 0.9063 0.4226]]
Scalar = [[1 1 1] [1.4 1.4 1.4] [1 1 1]]
Is the takeaway that IPT differs from ICtCp in the matrix coefficients step, using the product of the aforementioned three matrices instead of the LMS-ICtCp matrix?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@sekrit-twc Mmm. First, there is a file "03. Color Bars BT2020 50%_Blue Filter_Dolby_Vision.mp4" in
https://diversifiedvideosolutions.com/UHD_Project/Dolby_Vision_Test_Pattern_Demo.zip
which can be used to check if it is really just ICtCp or there are some modifications. Right?
And anyway as of now I think VLC (and ffplay and ffmpeg) just does normal BT.2020 conversion, am I right? It can still be better if it used BT.2100 ICtCp.

I found the information on page 7.
[I P T] = [[0.4 0.2 0.2] [4.4550 -4.8510 0.3960] [0.8056 0.3572 -1.1628]] * [L M S]
Rotation = [[1 0 0] [0 0.4226 -0.9063] [0 0.9063 0.4226]]
Scalar = [[1 1 1] [1.4 1.4 1.4] [1 1 1]]
Is the takeaway that IPT differs from ICtCp in the matrix coefficients step, using the product of the aforementioned three matrices instead of the LMS-ICtCp matrix?

There is a typo in your L'M'S' to IPT conversion matrix.  As I already replied, Rotation and Scaler conversions are there to convert IPT to ICtCp.
The following link confirms the above conversion matrix. https://gitlab.com/standards/HDRTools/blob/master/common/src/ToneMappingBT2390IPT.cpp
This should be sufficient information to add support for IPT.

@dzung-hoang IPT as finally the one in Dolby Vision? Or this is still not enough?

Are those https://github.com/testing-av/testing-video/blob/9256b779f7721bd3dbdceedab7c65b6f64bbab79/core/src/main/java/band/full/video/dolby/VdrDmDataPayload.java#L42 correct IPTPQc2 og Dolby Vision profile 5 coefficients?
/** IPT to LMS */
    public static final short[] IPTPQ_YCCtoRGB_coef = {
        8192, 799, 1681, // 1.0,
        8192, -933, 1091, // 1.0,
        8192, 267, -5545, // 1.0,
    };

    /** IPT to LMS */
    public static final long[] IPTPQ_YCCtoRGB_offset = {
        0, 134217728, 134217728 // 0, 0.5, 0.5
    };

    /** LMS inverse cross-talk matrix for c == 0.02 */
    public static final short[] IPTPQc2_RGBtoLMS_coef = {
        17081, -349, -349,
        -349, 17081, -349,
        -349, -349, 17081,
    };

Guys, I (well, not I) found this ITU-T H Suppl. 18 document that specifies two "inverted" matrixes for ICtCp with 15 decimal places. I then found out that those matrixes are just https://www.wolframalpha.com/input/?i=Inverse[SetPrecision[{{2048%2F4096.%2C+2048%2F4096.%2C+0}%2C+{6610%2F4096.%2C+-13613%2F4096.%2C7003%2F4096.}%2C+{17933%2F4096.%2C+-17390%2F4096.%2C+-543%2F4096.}}%2C+30]] and that you can get in integers matrixes https://www.wolframalpha.com/input/?i=Inverse[SetPrecision[{{2048%2F4096.%2C+2048%2F4096.%2C+0}%2C+{6610%2F4096.%2C+-13613%2F4096.%2C7003%2F4096.}%2C+{17933%2F4096.%2C+-17390%2F4096.%2C+-543%2F4096.}}%2C+Inf]]


ReqMgr2: status update via  web UI is broken

It returns a status Ok, however no changes were made to the request itself. The reason seems to be coming from the fact that you always update the request priority as well, this is what is sent downstream from web interactions:
{"RequestStatus":"aborted","RequestPriority":"250000"}
which then does not end in an statusUpdate in Request.py, e.g.
https://github.com/dmwm/WMCore/blob/master/src/python/WMCore/ReqMgr/Service/Request.py#L508
I'm still checking on how to fix it.

We actually should split it in two parts:

via web UI, if the priority is not changed, then it should be removed from the parameters passed to ReqMgr2
ReqMgr2 validation has to properly handle and update those 2 parameters when both are changed.

@vkuznet can you take care of 1) please? It would be very similar to the change you made for RequestStatus, when it does not change, then remove it from the parameters passed upstream.
I'm taking care of 2)

Alan, could you please point me to VM with concrete workflow. In order to see which part of code to change I need to see which web UI part you're talking about.

Sure, you can try moving this workflow
https://alan-cloud2.cern.ch/reqmgr2/fetch?rid=amaltaro_TaskChain_Data_HG1607_Validation_160627_235214_1091
to aborted status (don't change anything else). It will give you a thumbs up (Ok) but nothing really changed.

Alan, ok I modified a code but I need to test it. To do so we usually used reqmgr2-dev Seangchan's node and he put there some requests that I can play with via web interface. Can you do that for me? or tell me how to create few requests. I may several iteration since I'll debug web interface and see how requests will flow from web UI to the server. The code on reqmgr2-dev is modified already and ready for a test. If you can't do it on reqmgr2-dev may be you can give me access to your VM where I change the code and we can test it.

Giving it a second thought, case 2) does not seem to be needed. I cannot think of any real use case.
That means we only need the UI fix that you are working on (though I made a few improvements in another PR).
Seangchan's VM seems to be broken, I get a couch unauthorized when injecting a new request.
Anyways, I gave you access to alan-cloud2.cern.ch, just try not to break it (badly), since I have some tests on going there. You can pick a couple of workflows that are running and play with them. Otherwise let me know and I can inject more.

Alan, please take this PR: https://github.com/dmwm/WMCore/pull/6959
Per discussion in this issue it fixed the problem with RequestPriority parameter (as any other as well) if they're not changed they're removed from passed JSON. The code on your VM contains this fix, I changed the code manually, so please go ahead and test it with few workflows.


DeprecationWarning from traitlets

With DeprecationWarnings on, I get the following warning message with ipympl 0.1.1 and traitlets 4.3.2:
/sage/local/lib/python2.7/site-packages/ipympl/backend_nbagg.py:125:
DeprecationWarning: metadata {'sync': True} was set from the constructor.
With traitlets 4.1, metadata should be set using the .tag() method, e.g.,
Int().tag(key1='value1', key2='value2')
  _model_module = Unicode('jupyter-matplotlib', sync=True)

So line 125 (and the subsequent similar code) should be updated to
  _model_module = Unicode('jupyter-matplotlib').tag(sync=True)

The current ipympl requires ipywidgets>=7.0 which in turn requires traitlets>=4.3.1, so there is no need to support traitlets < 4.1.

Thanks @NathanDunfield! Good catch.
Feel free to open a PR. I would be happy to merge.

@SylvainCorlay PR created!

Thanks!


feat: Add map to line profile

Added a map to the bottom of this page:

Fix #542

So do you want me to do it in a new pr?

@Tamir198 it's up to you :)

I think I will want you to merge this and do it in a new pr just to prevent bug conflicts with Darkmift user who is also working on this part on the page.
Sounds good?

@Tamir198 sure, thanks. Let's merge it.
I gave you permissions to the repo, so feel free to merge things whenever you want (as long as there are no regressions and anyone made at least one code-review)

@all-contributors please add @Tamir198 for his code :clap: :medal_sports:


[Bug] Theme incompatible with PyCharm 2024.3

Describe the bug
The Oxocarbon theme is currently not compatible with PyCharm 2024.3. This incompatibility is shown as a warning message in the JetBrains Marketplace: "Not compatible with the version of your running IDE (PyCharm 2024.3)".
To Reproduce
Steps to reproduce the behavior:

Go to JetBrains Marketplace
Search for "Oxocarbon" theme
Attempt to install on PyCharm 2024.3
Observe combability warning message

Expected behavior
The theme should be compatible with the latest PyCharm version (2024.3) and allow for successful installation and application within the IDE.
Desktop (please complete the following information):

OS: Windows
IDE: PyCharm
IDE Version: 2024.3

Screenshots

Addtional context
It would be helpful to know if this compatibility issue affects other JetBrains IDEs on version 2024.3, as this information could help identify whether this is a PyCharm-specific issue or a broader compatibility problem across the JetBrains suite.

Same for all IDEs


Building a fresh project with create react app gives a module error.

Describe the bug
Building a fresh project with create react app gives an error.  Note, that this is with create react app v5.
node ➜ /workspaces/dapwords/dapwords/app (main ✗) $ yarn build
yarn run v1.22.15
warning ../package.json: No license field
$ react-scripts build
Creating an optimized production build...
Failed to compile.

Module not found: Error: Can't resolve './ConnectionProvider' in '/workspaces/dapwords/dapwords/app/node_modules/@solana/wallet-adapter-react/lib'
Did you mean 'ConnectionProvider.js'?
BREAKING CHANGE: The request './ConnectionProvider' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

To Reproduce
Steps to reproduce the behavior:
yarn create react-app app --template typescript
cd app
yarn add @solana/wallet-adapter-wallets  @solana/wallet-adapter-base @solana/wallet-adapter-react @solana/wallet-adapter-react-ui @solana/web3.js

Then copy your example code into the project.
yarn build

Expected behavior
builds

It looks like this is an issue coming from react-scripts v5, which is what the new app is being initialized with.
The react-ui-starter project builds as expected with react-scripts v4: https://github.com/solana-labs/wallet-adapter/blob/52c5195cb64ed3b8aec00e104b2cafc681818c2c/packages/starter/react-ui-starter/package.json#L43
Looking @ https://github.com/facebook/create-react-app/releases/tag/v5.0.0 it seems like the switch the Webpack 5, or maybe the eslint changes, could be responsible.

A potential workaround is described here: https://github.com/reduxjs/redux/issues/4174
  {
    test: /\.m?js/,
    resolve: {
      fullySpecified: false,
    },
  },

Thanks for the reply.   I'm not expert, so forgive me if I'm mistaken, but I think doing webpack config modifications requires the create-react-app project to eject, right?
I verified that it works fine in CRA v4.

I'm also not an expert on CRA. But I think you can customize your config without ejecting using https://github.com/gsoft-inc/craco

I saw that project in the react-ui starter and thought it would help but Craco only supports CRA v4 according to their current readme. :(

Let me know if you find anything about the issue!

Had the exact same issue using CRA v5. Not sure if this is a good solution, but manually changing the package.json to "react-scripts": "^4.0.3" and running "yarn install" after worked for me.

Yeah, I would recommend to anyone reading this to not use CRA v5 until https://github.com/gsoft-inc/craco/issues/353 is resolved and we can upgrade the starter packages here with an updated version of Craco.

  {
    test: /\.m?js/,
    resolve: {
      fullySpecified: false,
    },
  },

This worked for me as well. Thanks for the suggestion! Hopefully they fix soon.

Had the exact same issue using CRA v5. Not sure if this is a good solution, but manually changing the package.json to "react-scripts": "^4.0.3" and running "yarn install" after worked for me.

Worked for me beautifully.  Thanks

I tried today to build an app with my own webpack configuration. For people that tried to do the same thing and get brought here, check this answer on stack overflow + add .mjs loader as dlazares has shown.
https://stackoverflow.com/questions/69431515/how-to-use-webpack-and-web3-in-react

Is there any fix to this? "react-scripts": "^4.0.3" does not fix the issue with react-scripts test

@kevinforrestconnors did you try running the code in the CRA-based starter projects?

  {
    test: /\.m?js/,
    resolve: {
      fullySpecified: false,
    },
  },

Which config file does this code need to be in?

@kevinforrestconnors see https://github.com/reduxjs/redux/issues/4174 for that

@kevinforrestconnors see reduxjs/redux#4174 for that

I installed craco and ran the tests using this config:
craco.config.js
module.exports = {
  webpack: {
    test: /\.m?js/,
    resolve: {
      fullySpecified: false,
    },
  },
};

Same issue,
 ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){export * from './useWalletModal';
                                                                                ^^^^^^

    SyntaxError: Unexpected token 'export'

@kevinforrestconnors there isn't enough context to know what the issue is from an error like that. I'm happy to take a look, but please provide a link to a repository that reproduces the issue for you and steps on how to reproduce it.

@kevinforrestconnors there isn't enough context to know what the issue is from an error like that. I'm happy to take a look, but please provide a link to a repository that reproduces the issue for you and steps on how to reproduce it.

thanks for taking a look, here is a reproducible repo https://github.com/kevinforrestconnors/reproducible-issue

@jordansexton, I'm facing the same issue now. But I'm not using Craco. There's something should be done with my webpack.config.js (I think).
Here's the error I see:
ERROR in<EMAIL_ADDRESS>17:0-27
Module not found: Error: Can't resolve './adapters' in '/Users/test/Desktop/swap2/node_modules/@solana/wallet-adapter-wallets/lib/esm'
Did you mean 'adapters.js'?
BREAKING CHANGE: The request './adapters' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
 @ ./src/App.jsx 27:0-177
 @ ./src/index.js 4:0-24 13:33-36 18:33-36 23:33-36 28:33-36 33:33-36

@jordansexton, I'm facing the same issue now. But I'm not using Craco. There's something should be done with my webpack.config.js (I think).
Here's the error I see:
ERROR in<EMAIL_ADDRESS>17:0-27
Module not found: Error: Can't resolve './adapters' in '/Users/test/Desktop/swap2/node_modules/@solana/wallet-adapter-wallets/lib/esm'
Did you mean 'adapters.js'?
BREAKING CHANGE: The request './adapters' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
 @ ./src/App.jsx 27:0-177
 @ ./src/index.js 4:0-24 13:33-36 18:33-36 23:33-36 28:33-36 33:33-36

@jordansexton, I'm facing the same issue now. But I'm not using Craco. There's something should be done with my webpack.config.js (I think).
Here's the error I see:
ERROR in<EMAIL_ADDRESS>17:0-27
Module not found: Error: Can't resolve './adapters' in '/Users/test/Desktop/swap2/node_modules/@solana/wallet-adapter-wallets/lib/esm'
Did you mean 'adapters.js'?
BREAKING CHANGE: The request './adapters' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
 @ ./src/App.jsx 27:0-177
 @ ./src/index.js 4:0-24 13:33-36 18:33-36 23:33-36 28:33-36 33:33-36

Look at my previous answer. It should resolve your problem.

@jordansexton, I'm facing the same issue now. But I'm not using Craco. There's something should be done with my webpack.config.js (I think).
Here's the error I see:
ERROR in<EMAIL_ADDRESS>17:0-27
Module not found: Error: Can't resolve './adapters' in '/Users/test/Desktop/swap2/node_modules/@solana/wallet-adapter-wallets/lib/esm'
Did you mean 'adapters.js'?
BREAKING CHANGE: The request './adapters' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
 @ ./src/App.jsx 27:0-177
 @ ./src/index.js 4:0-24 13:33-36 18:33-36 23:33-36 28:33-36 33:33-36

Look at my previous answer. It should resolve your problem.

@kevinforrestconnors there isn't enough context to know what the issue is from an error like that. I'm happy to take a look, but please provide a link to a repository that reproduces the issue for you and steps on how to reproduce it.

thanks for taking a look, here is a reproducible repo https://github.com/kevinforrestconnors/reproducible-issue
to reproduce, npm i && npm test

Updating to the latest version of these packages fixes the issue
    "@solana/wallet-adapter-base": "^0.9.0",
    "@solana/wallet-adapter-react": "^0.15.0",
    "@solana/wallet-adapter-react-ui": "^0.8.0",
    "@solana/wallet-adapter-wallets": "^0.14.0",

@kevinforrestconnors there isn't enough context to know what the issue is from an error like that. I'm happy to take a look, but please provide a link to a repository that reproduces the issue for you and steps on how to reproduce it.

thanks for taking a look, here is a reproducible repo https://github.com/kevinforrestconnors/reproducible-issue
to reproduce, npm i && npm test

Updating to the latest version of these packages fixes the issue
    "@solana/wallet-adapter-base": "^0.9.0",
    "@solana/wallet-adapter-react": "^0.15.0",
    "@solana/wallet-adapter-react-ui": "^0.8.0",
    "@solana/wallet-adapter-wallets": "^0.14.0",

@jordansexton, I'm facing the same issue now. But I'm not using Craco. There's something should be done with my webpack.config.js (I think).
Here's the error I see:
ERROR in<EMAIL_ADDRESS>17:0-27
Module not found: Error: Can't resolve './adapters' in '/Users/test/Desktop/swap2/node_modules/@solana/wallet-adapter-wallets/lib/esm'
Did you mean 'adapters.js'?
BREAKING CHANGE: The request './adapters' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
 @ ./src/App.jsx 27:0-177
 @ ./src/index.js 4:0-24 13:33-36 18:33-36 23:33-36 28:33-36 33:33-36

Could you share what you're trying to import?
From the error it looks like you're trying to do a deep import, consider importing from the root of the package:
import {Adapter} from '@solana/wallet-adapter-wallets';

@jordansexton, I'm facing the same issue now. But I'm not using Craco. There's something should be done with my webpack.config.js (I think).
Here's the error I see:
ERROR in<EMAIL_ADDRESS>17:0-27
Module not found: Error: Can't resolve './adapters' in '/Users/test/Desktop/swap2/node_modules/@solana/wallet-adapter-wallets/lib/esm'
Did you mean 'adapters.js'?
BREAKING CHANGE: The request './adapters' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
 @ ./src/App.jsx 27:0-177
 @ ./src/index.js 4:0-24 13:33-36 18:33-36 23:33-36 28:33-36 33:33-36

Could you share what you're trying to import?
From the error it looks like you're trying to do a deep import, consider importing from the root of the package:
import {Adapter} from '@solana/wallet-adapter-wallets';

@jordansexton, I'm facing the same issue now. But I'm not using Craco. There's something should be done with my webpack.config.js (I think).
Here's the error I see:
ERROR in<EMAIL_ADDRESS>17:0-27
Module not found: Error: Can't resolve './adapters' in '/Users/test/Desktop/swap2/node_modules/@solana/wallet-adapter-wallets/lib/esm'
Did you mean 'adapters.js'?
BREAKING CHANGE: The request './adapters' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
 @ ./src/App.jsx 27:0-177
 @ ./src/index.js 4:0-24 13:33-36 18:33-36 23:33-36 28:33-36 33:33-36

Look at my previous answer. It should resolve your problem.

That was really helpful. Thx <3

@jordansexton, I'm facing the same issue now. But I'm not using Craco. There's something should be done with my webpack.config.js (I think).
Here's the error I see:
ERROR in<EMAIL_ADDRESS>17:0-27
Module not found: Error: Can't resolve './adapters' in '/Users/test/Desktop/swap2/node_modules/@solana/wallet-adapter-wallets/lib/esm'
Did you mean 'adapters.js'?
BREAKING CHANGE: The request './adapters' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
 @ ./src/App.jsx 27:0-177
 @ ./src/index.js 4:0-24 13:33-36 18:33-36 23:33-36 28:33-36 33:33-36

Look at my previous answer. It should resolve your problem.

That was really helpful. Thx <3

Closing since it seems like the issues are fixed in the current release which ships proper ESM and CJS builds. Thanks everyone for your input! If you're still having issues after upgrading, please open a new issue with a reproduction.

Closing since it seems like the issues are fixed in the current release which ships proper ESM and CJS builds. Thanks everyone for your input! If you're still having issues after upgrading, please open a new issue with a reproduction.


No Images downloaded

This is the first time I've had this issue. It'll create a folder for the images but won't download them.
Command used: java -jar lezhin-comics-downloader-2.8.1.jar -l=en -n=sexercise_en -r=78~
Lezhin Comics Downloader v2.8.1         If you have any questions, contact me by 'https://github.com/ImSejin/lezhin-comics-downloader/issues' Starting ChromeDriver 98.0.4758.102 (273bf7ac8c909cde36982d27f66f3c70846a3718-refs/branch-heads/4758@{#1151}) on port 28224 Only local connections are allowed. Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe. ChromeDriver was started successfully. Feb 19, 2022 2:13:13 PM org.openqa.selenium.remote.ProtocolHandshake createSession INFO: Detected dialect: W3C         Request login page: https://www.lezhin.com/en/login         Successfully logged in: access token(90c5f346-b376-44b2-8340-47fe104146b6)         Request comic page: https://www.lezhin.com/en/comic/sexercise_en

Hi, refer to #87.

All fixed. Thank you!


Expand/collapse icon

Type: Feature Request
Hello dear vscode developers :)
As a developer I think the expand/collapse icon is very terrible. I will be so nice to change it to a plus/mius icon.
Thank you veeeeeeery much.
VS Code version: Code 1.75.0 (e2816fe719a4026ffa1ee0189dc89bdfdbafb164, 2023-02-01T15:23:45.584Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No

You can do that by using a different product icon theme.
E.g. https://marketplace.visualstudio.com/items?itemName=davidbwaters.macos-modern-theme


Rename config value to use unsecured instead of insecure

We're using unsecured everywhere else. And this setting defaults the frontend and OTLP endpoint auth modes to unsecured. Seems like it should be consistent.
If merged, I'll backport to P5.
Microsoft Reviewers: Open in CodeFlow

/backport to release/8.0-preview5


Anerdw: Blacklist<PHONE_NUMBER>

Anerdw requests the blacklist of the number<PHONE_NUMBER>. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Jeff Schaller in Charcoal HQ


Replace TimeInterval with google.type.Interval.

This should be a binary-compatible change.

This change is

Depends on #154


arch-x86,arch-arm: Remove static variables in decoders

There were a number of variables in the arm and x86 decoders that are static (e.g., the decode cache). It's a bit interesting that this doesn't cause problems with multiple cores since each core has its own decoder.
However, this causes segfaults if you run different cores on different host threads. We are experimenting with running gem5 with multiple host thread (i.e., in parallel), and removing these static variables resolves the segfault.
This change also adds const to any other static variables to ensure that they cannot be modified.

I'd love some feedback on this. Does any know why these variables were static? It seems like static was not a good idea.

My hunch is that assuming an homogeneous multicore system, the same MachInst would translate into the same instruction object regardless of the CPU id. So not only we would save some storage; in theory one CPU could reuse the caching work done by another (which might be running ahead).
Having said that I never looked into the decoder cache in detail so I might be wrong.
It would be interesting to see if we suffer a host performance penalty when simulating a multicore system when removing the static and making the decoder cache a per-CPU structure...
I understand we should pay the penalty anyway in a parallel implementation of gem5

My hunch is that assuming an homogeneous multicore system, the same MachInst would translate into the same instruction object regardless of the CPU id. So not only we would save some storage; in theory one CPU could reuse the caching work done by another (which might be running ahead).

That was my guess too. I also wonder if this was some premature optimization ;)

It would be interesting to see if we suffer a host performance penalty when simulating a multicore system when removing the static and making the decoder cache a per-CPU structure...

I'll run some tests. Given this change touches structures that are highly utilized in the core of gem5, I think we should go through some extra testing. However, I wanted to get the code out the ASAP so others could weigh in.

Here's the results from our tests. Thanks @erin-le for running this!
We tested Linux boot (no systemd) in atomic mode. My hypothesis is that this change will affect atomic more than any other mode. We ran with 8 cores and with 1 core. The 8 core data is below, since that should be more interesting. There was little change the Arm performance, and a ~5% slowdown for x86. However, we only ran these once, so it's possible the that 5% is in the noise.
I think this is the worst case, so 5% is probably livable. I'm open to hearing any feedback!
Arm
before:
hostSeconds                                    573.02                       # Real time elapsed on the host (Second)

after:
hostSeconds                                    574.73                       # Real time elapsed on the host (Second)

x86
before:
hostSeconds                                   1198.61                       # Real time elapsed on the host (Second)

after:
hostSeconds                                   1245.15                       # Real time elapsed on the host (Second)


Ubuntu DSVM Python environment names need updating

Some of the python environments referenced here (py38_pytorch, py38_tensorflow) do not exist on newly-deployed Ubuntu DSVMs with gen1 images.

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

ID: f12930c3-494d-9404-0493-d2a7e992fc73
Version Independent ID: 9a1baeb7-c0d7-18ee-5ede-47779988bd83
Content: Reference: Ubuntu Data Science Virtual Machine - Azure Data Science Virtual Machine
Content Source: articles/machine-learning/data-science-virtual-machine/reference-ubuntu-vm.md
Service: data-science-vm
GitHub Login: @timoklimmer
Microsoft Alias: tklimmer

@mawah Thanks for the feedback. We are investigating the issue and will update you shortly.

@mawah Based on the latest release notes both these environments should be available in environment azureml_py38_PT_TF for version: 22.04.01
Could you check if environment is available with conda env list?
You can check version of your DSVM using the following commands:
az vm show -g <your_rg> -n <your_vm_name>  --query storageProfile.imageReference.exactVersion -o tsv

@mawah We will now proceed to close this thread. If there are further questions regarding this matter, please tag @RohitMungi-MSFT in your reply.


Fixed redirect handler

RedirectFollower now reports 429s and 404s with are handled by retry and marking the url for deletion.
If this run here passes we can proceed with merging this PR.
EDIT: what this run does it process a package list copied from before https://github.com/SwiftPackageIndex/PackageList/pull/712 (the manual run I processed and merged this morning on my laptop to stop the rollbar items). The expectation is for this to produce the same diff (although there will be a couple more moved urls in it, as some packages have changed urls during the day).
This PR will not submit a PR but we can check the diff output in the logs.

Passed, thank god


Changed definitions version to 1.5

Changed the definitions from the 1.4 version to 1.5

In reference to issue
#6

Thanks!


Fixed using invalid iterator (CID:20570650)

std::vector::erase() invalidates iterators and references at or after the point of the erase. Return value of std::vector::erase() shall be used to initialize the iterator (Return value: Iterator following the last removed element. )

@gbaned , any problem merging this PR to mainline? So far it was approved 4 times already :-).

@gbaned , any problem merging this PR to mainline? So far it was approved 4 times already :-).

Hi @robert-kalmar  There was an internal import issue, hence it was approved 4 times. It is looks good now.  Thank you.


Allow bash execuption

Hi,
i have used your plugin and it is a good help for my project.
But the scriptable plugin is only limited to execute javascript files.
Could it be a good extension to allow any kind of scripts?
The code that could handle that:
const execSync = require('child_process').execSync;
function exec(description, command) {
    console.log(`Package: ${description} : ${command}`);
    var output = execSync(command).toString('utf8');

    if (output) {
        console.log(output);
    }
}

And the configuration in the serverless.yml could look like
custom:
  scriptHooks:
    before:deploy:createDeploymentArtifacts: make deploy

This would increase the reusability in many different projects programming language independent.
In our case we want to execute python scripts that are execute before some kind of deployment

Thanks for your request, I have added this feature in 0.3.0. You can try it now, with the same usage as you wrote.
The logic is: if the command exists, execute it as a javascript file, else execute as a bash script.


Revert "fix(apps/staging/prod): reduce ats disk size"

Reverts PingCAP-QE/ee-ops#244

/retest

/approve


Ethical Warning

It's so embarrassing. You add this library developed by me to your own repository and don't give any references. You have to forked this project.

Sorry, and I understand. but i want to keep it up to date, since your library is outdated. but you're right i will put some reference into your repo.


Very crude demo using RaphaelJS

Hi,
I loved springy and I maybe use it on my next project. Since I can't rely on Canvas, I did a very quick and dirt prototype using RaphaelJS. It doesn't have drag and drop, just the very basic stuff.
I thought it might be useful for someone else too, to here it is.

Thanks for the contribution. Looks pretty good and the performance seems decent too.
I've had performance problems in the past with SVG based renderers, but this seems to run fine. Nice one. :-D


proposal: go/types: lazy resolution of imported objects

cmd/compile uses an indexed export format that allows lazily resolving imported objects so that only the objects that are actually used by user code need to be loaded into memory. However, the go/types API doesn't currently support lazy import resolution, so the gcexportdata importer still needs to eagerly load all objects. (It's able to use the index to skip loading of objects that were already loaded by another importer though.)
This proposal is to add a new function to facilitate lazy import resolution:
func (s *Scope) InsertLazy(name string, resolve func() Object) Object

Semantically from the end user's point of view, this function behaves like:
func (s *Scope) InsertLazy(name string, resolve func() Object) Object {
    obj := resolve()
    if name != obj.Name() {
        panic("invalid resolved object name")
    }
    return s.Insert(obj)
}

except it's unspecified when/whether resolve is actually called.
Importer implementations can then use this function to create lazy objects to add to the Package.Scope without having to fully load all details right away. go/types then assumes responsibility for noticing when it has a lazy object and calling resolve to get the actual object.
For example, a partial sketch of how this might really work:
type lazyObject func() Object

// Unused methods to implement Object.
func (*lazyObject) Pkg() *Package { panic("unresolved object") }
// ...

func (s *Scope) InsertLazy(name string, resolve func() Object) Object {
    if alt := s.elems[name]; alt != nil {
        return alt
    }
    if s.elems == nil {
        s.elems = make(map[string]Object)
    }
    s.elems[name] = lazyObject(resolve)
    return nil
}

func (s *Scope) Lookup(name string) Object {
    obj := s.elems[name]
    if resolve, ok := obj.(lazyObject); ok {
        obj = resolve()
        if name != obj.Name() {
            panic("invalid resolved object name")
        }
        s.elems[name] = obj
        if obj.Parent() == nil {
            obj.setParent(s)
        }
    }
    return obj
}

Other internal code that directly accesses Scope.elems would need to be similarly updated to handle lazyObjects. User code should be unaffected though: the public APIs will always return fully resolved objects.
One possible concern with lazy resolution though is the resolve function for any unresolved objects will need to hang onto the importer resources for constructing them. Which in turn means the Scope, Package, and any other Objects from that same package will also keep those resources live. I would expect this is likely still an improvement over the status quo (i.e., holding onto a single flat byte slice, rather than the complete object/type graph).
Another possible future extension would be for the Scope to only keep a weak reference to the resolved object, and then re-resolve it on demand as needed. I think this would be transparent both to users and importer implementations (as long as the resolve method is safe to invoke multiple times).
/cc @griesemer @findleyr

@dominikh points out that this has implications for concurrent calls to Scope.Lookup, which I hadn't considered.
But I think we have a bunch of options on how to keep that working. E.g., either synchronize on the Scope (with a fast path for scopes without any lazy objects) or turn lazyObject into a separate struct with its own internal synchronization.
We can also add a flag to either turn on/off lazy resolution (depending on whether we make lazy importing the default or not), though I think it's probably preferable if we can just make lazy importing always work.

CL 323569 has a working example of using this extension for types2.
Two observations from updating the types2 importer to use InsertLazy:

Initially, I thought I could just add lazy objects for the directly imported package's symbols, and then lazily add indirect imports as needed. But that caused this test to fail, because it imports "net/http" and then expects sync.Mutex to be Lookup'able:

https://github.com/golang/go/blob/79bda650410c8617f0ae20dc552c6d5b8f8dcfc8/src/cmd/compile/internal/importer/gcimporter_test.go#L380-L386
This wasn't hard to fix, and fixing it actually made the importer somewhat simpler (able to get rid of some extra maps), and is probably necessary anyway to make concurrent Lookups safe. But it surprised me, so I thought I'd note it.

Previously the gcexportdata importer broke type cycles by declaring the TypeName early so it would be visible later via Scope.Lookup when importing the underlying type and any associated methods. However, the proposed API doesn't support this, because the object won't be inserted until the resolve function returns.
Instead I changed to to keep a separate "predeclared" map that holds TypeNames until they've been declared properly. This is a little clumsy, but it turns out to also be useful for indicating when it's safe to Complete any interfaces. And handling recursive defined types is always a little clumsy because of cycles. So I don't think this was too bad of a solution.

CL 323629 further adds another API to types2, conceptually equivalent to:
func NewTypeNameLazy(pos token.Pos, pkg *Package, name string, resolve func(named *Named) (tparams []*TypeParam, underlying Type, methods []*Func)) *TypeName {
    obj := NewTypeName(pos, pkg, name, nil)
    named := NewNamed(obj, nil, nil)
    tparams, underlying, methods := resolve(named)
    named.SetTParams(named)
    named.SetUnderlying(underlying)
    for _, method := range methods {
        named.AddMethod(method)
    }
    return obj
}

except that again resolve may be called later (or never).
Not only does this allow avoiding resolving defined types whose definitions go unused, but it also completely eliminates the complexity of handling recursive types within the importer, instead letting go/types manage these details. I've also wanted to add lazy type loading to cmd/compile for a while.
Also, after prototyping it, I also realized that it actually seems somewhat similar to the current instance stuff, so maybe they can actually share a common implementation.

Related: https://go.dev/cl/447737: internal/gcimporter: API for shallow export data


Keccak implementation and selector calculation

I'm wondering if it's better to use sha3 specific library for that, instead of whole CryptoSwift package. E.g. https://github.com/coruus/keccak-tiny


Clarify isolation mechanism over CLIC memory mapped registers

Per discussions in fast interrupt TG we are expecting memory mapped registers to be aliased in M/S mode systems, it would be good to provide some clarity in spec to avoid confusion.
For example, below statements may make people think that CLIC is enforcing priv mode identifier on memory bus when accessing these registers:
All CLIC-memory mapped registers are visible to M-mode. Interrupt registers clicintip[i], clicintie[i], clicintattr[i], clicintctrl[i] configured as M-mode interrupts are not acessible to S-mode and U-mode. Interrupt registers clicintip[i], clicintie[i], clicintattr[i], clicintctrl[i] configured as S-mode interrupts are not acessible to U-mode.
In S-mode, any interrupt i that is not accessible to S-mode appears as hard-wired zeros in clicintip[i], clicintie[i], clicintattr[i], and clicintctl[i].
Another example is that cliccfg might be RO for S mode and RW for M mode, but memory map says it is RW:
0x0000         1B          RW        cliccfg

Will add clarification to spec about how memory apertures are intended to be protected across privilege modes.

In TG meeting 6/8/2021 we realized the discussion of memory apertures was incorrectly removed from the spec, and need to be reinstated to remove this confusion.

Added back text on memory apertures in commit https://github.com/riscv/riscv-fast-interrupt/commit/f2c9a1e7ef6fab9eb69bff39b0c0f1d677dc4561 .  Still needs a little clean up to help clarify these issues.


Connected components code added

Implementation of program to count number of connected components in an undirected graph
Fixes #1599
Type of change

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have created a helpful and easy to understand README.md
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works

@Ayush7614 @Amit366 @ravikr126 @Saurabh4626 , Kindly review my PR


LSNBLDR-940: NPE protection for missing comments section on student page

https://jira.sakaiproject.org/browse/LSNBLDR-940
Western recently ran into an issue where somehow a student page's comment section was deleted (every student page has a comment section by default). We haven't been able to identify exact steps to reproduce the ability to delete the comments section as a student, but the result was that trying to navigate to the student page in question would throw an uncaught NPE exception. The stacktrace would take over the entire portal, meaning the user had no way to reset the tool, or navigate back to the site without either manually entering the URL, or closing and re-opening their browser, etc.
The problem manifests because the ID of the comments section is stored in the student page object. However, when the comments section gets deleted, the ID for it remains in the page object. So when SimplePageBean.getItemsOnPage() runs, it detects that is had an ID for a comments section, asks the service for that item (which returns null), and then it tries to access the ID of this null object to stick in the itemCache map, which throws the NPE.

Thanks for splitting the cleanup from the fix ;)

No worries, I tried to take it easy, some of these lessons files are crazy!


cargo wasm-pack install does not work on aarch64

🐛 Bug description
I want to install wasm-pack on my server which runs an arm64/aarch64 CPU. The installer does not work so I did cargo install wasm-pack. It compiles but when I run npm install -g wasm-pack or yarn global add wasm-pack it fails.
🤔 Expected Behavior
It registers to the system and does not crash npm.
👟 Steps to reproduce

cargo install wasm-pack
sudo npm install -g wasm-pack

/usr/bin/wasm-pack -> /usr/lib/node_modules/wasm-pack/run.js

><EMAIL_ADDRESS>postinstall /usr/lib/node_modules/wasm-pack
> node ./install.js

/usr/lib/node_modules/wasm-pack/binary.js:20
  throw new Error(`Unsupported platform: ${type} ${arch}`);
  ^

Error: Unsupported platform: Linux arm64
    at getPlatform (/usr/lib/node_modules/wasm-pack/binary.js:20:9)
    at getBinary (/usr/lib/node_modules/wasm-pack/binary.js:24:20)
    at install (/usr/lib/node_modules/wasm-pack/binary.js:38:18)
    at Object.<anonymous> (/usr/lib/node_modules/wasm-pack/install.js:4:1)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:75:12)
    at internal/main/run_main_module.js:17:47
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>postinstall: `node ./install.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>postinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!  As MacOS aarch64 works fine

https://github.com/rustwasm/wasm-pack/pull/1102

https://github.com/rustwasm/wasm-pack/pull/1122

I'm not sure this issue will be resolved by #1122, since that PR fixes the the download one-liner script. This seems to be triggered by a JS error, so the download logic must be duplicated there.
I could port the same fix to JS as a part of the original MR (it would still be in the spirit of it), because this has come to bite me a second time.

Fixed in v0.11.0.


Added "newexposure" to ZWO config file

Hi Thomas,
The dev branch still says it's 9 commits ahead and 1 behind the master branch.  It also said that last night when I did the PR, which is probably why it included more than just the one file I  changed.
How do we fix it?
Eric

@EricClaeys ,
Once I've merged dev into master, the easiest is probably to delete your local dev branch and pull the new one from the repo.
git stash     <-- Stash your changes if you have any outstanding code changes
git branch -D dev    <-- deletes your local dev branch
git fetch     <-- retrieves latest repo changes
git checkout dev      <-- select the dev branch
git pull      <-- pull the branch changes from the repo. This creates your new dev branch
git stash pop       <-- This brings back your changes onto the dev branch

Then you should be good to make new commits on the dev branch.

I’m a bit confused about the all the recent updates because I’ve been out of town for 10 days, are all the 0.8 changes updated in github now ?      Bill P.
Sent from my iPad

On Sep 2, 2021, at 11:25 AM, Thomas Jacquin @.***> wrote:

@thomasjacquin approved this pull request.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Bill,
what's in GitHub is a fix for people with version 0.8 that were getting the ASI_ERROR_TIMEOUTs.  The fix allows you to turn off the "Version 0.8 Exposure" mode, which then uses the version 0.7 mode.  All the other version 0.8 features are still active though.
If you use the GUI you'll want to update it as well as "allsky" since the GUI fix includes that new option - click on "Show Advanced Settings" at the bottom of the page, then look for "Version 0.8 Exposure".
If version 0.8 is currently working for you, you don't need this fix.  Unfortunately using the version 0.7 exposure method results in a warmer camera.

I use 2 SD cards one for 0.7 nightly and another for 0.8 tests and do not use the GUI interface yet.  Should I reload 0.8 from scratch to pick up all the new changes ?
0.7 camera heat is my concern with the ASI178MC at gain 225.
Thanks ….. Bill in Orange County California
Sent from my iPad

On Sep 2, 2021, at 1:33 PM, EricClaeys @.***> wrote:

Bill,
what's in GitHub is a fix for people with version 0.8 that were getting the ASI_ERROR_TIMEOUTs. The fix allows you to turn off the "Version 0.8 Exposure" mode, which then uses the version 0.7 mode. All the other version 0.8 features are still active though.
If you use the GUI you'll want to update it as well as "allsky" since the GUI fix includes that new option - click on "Show Advanced Settings" at the bottom of the page, then look for "Version 0.8 Exposure".
If version 0.8 is currently working for you, you don't need this fix. Unfortunately using the version 0.7 exposure method results in a warmer camera.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Bill,
You can just download the changed files - capture.cpp, README.md, and settings_ZWO.json.repo.  But if you're more comfortable downloading everything from scratch you can do that, too.
Note that disabling the 0.8 exposure mode (i.e., setting "newexposure" to 0) also disables the "cooler sensor" improvement in 0.8, but for people getting the ASI_ERROR_TIMEOUTs in 0.8, there's no way around that.


Importing databases as drivers

Currently the users.go and posts.go namespace is very cluttered since both the application routes and structure methods lie in the same file. In very beginning the routes and structure methods were apart and lately I've felt like the original plan was better than the current, where the files have the code for both. Therefore, I'm creating this issue to let everyone know about those plans.
The current idea is to have separate folder called db and inside of it the drivers as in gorm or rethinkdb. These folders will then contain all necessary structure methods for posts and users, likely both in their own files. These drivers could then be imported in the application users.go and posts.go using forced namespace such as driver.
In the most ideal scenario you could switch between databases by changing a single line in the users.go and posts.go file. However, to achieve this it requires all drivers to have the necessary methods with same naming standards. The naming standards is something I have to create sometime in the future, but will hopefully bring more clarity in the source code to whomever is reading it. This should also make adding new database flavors easier.

This enchantment is currently under progress, which will eventually lead to closing of #27. You can see the WIP on branch database-drivers.


.dts animation bug, cannot export rotations - "Tuple object has no attribute 'x'

you didn't fix this open it aaaaaaaaaaaaaaa


migration: fully migrated customize landing page to playwright

Describe your changes:

I worked on migrating customize landing page to playwright

Type of change:

[ ] Bug fix
[x] Improvement
[ ] New feature
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] My PR title is Fixes <issue-number>: <short explanation>
[ ] I have commented on my code, particularly in hard-to-understand areas.
[ ] For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

@ShaileshParmar11 changes made as per comments!


neovim/wrapper.nix bug, wrapperArgs applied twice to makeWrapper

https://github.com/NixOS/nixpkgs/blob/80e3487ed40c1e976f2484cb06bb8cce41ef9da2/pkgs/applications/editors/neovim/wrapper.nix#L38
wrapperArgsStr  <<  lib.escapeShellArgs wrapperArgs
https://github.com/NixOS/nixpkgs/blob/80e3487ed40c1e976f2484cb06bb8cce41ef9da2/pkgs/applications/editors/neovim/wrapper.nix#L42
https://github.com/NixOS/nixpkgs/blob/80e3487ed40c1e976f2484cb06bb8cce41ef9da2/pkgs/applications/editors/neovim/wrapper.nix#L62-L66
finalMakeWrapperArgs << commonWrapperArgs  << wrapperArgs
https://github.com/NixOS/nixpkgs/blob/80e3487ed40c1e976f2484cb06bb8cce41ef9da2/pkgs/applications/editors/neovim/wrapper.nix#L132
makeWrapper  (finalMakeWrapperArgs: has wrapperArgs) (wrapperArgsStr: has wrapperArgs) <--- wrapperArgs applied twice..

This leads to my vim config failing because I'm getting to many --cmd's.
Is there a workaround @teto  ?

what's your config like, you should be allowed 10 --cmd so that's weird. Are you on stable-23.05 ?

It's an elaborate recursively wrapped custom build... It might have been close to 10 -c's or --cmd's easily and a few duplicated ones pushed me over 🙂 . I had to roll back to restore the config temporarily and can't reproduce it right now. I'll get back to you when I try again.

@teto Sorry for the noise, I think I have another issue. I must have broken quoting when trying to unroll my wrappers manually to debug, noticed the duplication and got vim's "too many --cmd's" error.
I'm not close to 10 -c or --cmd, and only the lowest wrapper duplicates the args - the following layers are makeWrapper based anyways.

Not sure I understand, do you still have issues with it ?
I've unassigned myself from the issue since I only use unstable and am working on some heavy changes https://github.com/NixOS/nixpkgs/pull/237425 with the goal of making configuration easier for 23.11 (and lua support hopefully). Happy to review a PR that fixes the issue at hand.

should be fixed now


Error stack sometimes won't go to line definition if script is built-in

Godot version:
3.2 stable
OS/device including version:
Windows 10 x64
Issue description:
When encountering a runtime error inside a built-in script, the editor fails to go to the definition.  This might affect other parts of the call stack, but I've only tested it with an error at the top.
Steps to reproduce:

Create a normal script at scene root.
Create a built-in script.  Add a function test() to it.
Introduce a runtime error in test().  (assert(false) will probably work)
Call test() from the root script's _ready() function.
Run program.
Click the line defs at different parts of the call stack.  The external scripts should work, but the built-in script should fail.

Unable to reproduce this on Manjaro GNU/Linux.

I'm no longer able to reproduce this myself in my project.  May have been related to other issues such as cyclic dependency checks.  I can close the issue until I encounter it again.


[feat] Upgradeability

It would be logical to have the upgradeability in the code by using something like OZ upgradeable module. Would request to get that added.
References

Closed in #36.


Timeout with GPT-4, stream = true required

It seems that with GPT-4 it takes too long to receive a response from APIs. In the reference they mention this stream = true to start receiving the first tokens immediately and avoiding a timeout.

Hi @Pierquinto
I am able to use GPT-4 without any problems. Can you give us a concrete example when you run into the timeout issue?
After our last release in the past days we are now able to continue making the client capable of streamed responses. I will give you an update as soon as possible.

I am also keep getting a lot of "Idle timeout reached" for model gpt-3.5-turbo chat requests:
[2023-03-20 08:38:13] prod.INFO: [ERROR] [openai_50] [217/500] Vocalex English [Idle timeout reached for "https://api.openai.com/v1/chat/completions".]
[2023-03-20 08:38:16] prod.INFO: [Success] [openai_50] [189/500] Span-Gles [32 / 61]
[2023-03-20 08:38:17] prod.INFO: [Success] [openai_500] [29/150] efWiki [250 / 304]
[2023-03-20 08:38:39] prod.INFO: [ERROR] [openai_50] [481/500] TX Text Control ActiveX Server [Idle timeout reached for "https://api.openai.com/v1/chat/completions".]
[2023-03-20 08:38:42] prod.INFO: [Success] [openai_50] [365/500] TX Text Control .NET Server [28 / 73]
[2023-03-20 08:38:43] prod.INFO: [Success] [openai_50] [366/500] TX Text Control ActiveX Standard [17 / 52]
[2023-03-20 08:38:47] prod.INFO: [Success] [openai_50] [367/500] Mpeg Splitter [55 / 134]
[2023-03-20 08:39:16] prod.INFO: [ERROR] [openai_50] [219/500] Solar Eclipse Calculator [Idle timeout reached for "https://api.openai.com/v1/chat/completions".]
[2023-03-20 08:39:17] prod.INFO: [ERROR] [openai_500] [30/150] SILEX [Idle timeout reached for "https://api.openai.com/v1/chat/completions".]
[2023-03-20 08:39:17] prod.INFO: [Success] [openai_50] [190/500] Toy Train Widget [19 / 59]
[2023-03-20 08:39:19] prod.INFO: [Success] [openai_50] [191/500] Gotham Search [30 / 59]
[2023-03-20 08:39:23] prod.INFO: [Success] [openai_50] [192/500] Alpha Phi Alpha [31 / 80]
[2023-03-20 08:39:25] prod.INFO: [Success] [openai_50] [193/500] Black Friday Countdown [31 / 88]
[2023-03-20 08:39:27] prod.INFO: [Success] [openai_50] [194/500] EuroOffice Map Chart [38 / 88]
[2023-03-20 08:39:30] prod.INFO: [Success] [openai_50] [195/500] FinanceJ [36 / 87]
[2023-03-20 08:39:33] prod.INFO: [Success] [openai_50] [196/500] Kate Mara Screen Saver [39 / 89]
[2023-03-20 08:39:35] prod.INFO: [Success] [openai_50] [197/500] IQ Geography Quiz [26 / 88]
[2023-03-20 08:39:47] prod.INFO: [ERROR] [openai_50] [485/500] Stellar Phoenix Windows Data Recovery Software [Idle timeout reached for "https://api.openai.com/v1/chat/completions".]
[2023-03-20 08:39:52] prod.INFO: [Success] [openai_500] [30/150] Drobo Dashboard [648 / 1412]
[2023-03-20 08:40:09] prod.INFO: [Success] [openai_500] [31/150] Touchtip [278 / 331]
[2023-03-20 08:40:21] prod.INFO: [Success] [openai_500] [32/150] BrainXT [213 / 327]
[2023-03-20 08:40:32] prod.INFO: [Success] [openai_500] [33/150] RiftVault [191 / 226]
[2023-03-20 08:40:35] prod.INFO: [ERROR] [openai_50] [228/500] Lock My PC [Idle timeout reached for "https://api.openai.com/v1/chat/completions".]
[2023-03-20 08:40:39] prod.INFO: [Success] [openai_50] [198/500] python-slownie [63 / 143]
[2023-03-20 08:40:42] prod.INFO: [Success] [openai_50] [199/500] Property Set Library [47 / 106]
[2023-03-20 08:40:45] prod.INFO: [Success] [openai_50] [200/500] gapbuffer [44 / 68]
[2023-03-20 08:40:47] prod.INFO: [Success] [openai_50] [201/500] filelike [17 / 45]
[2023-03-20 08:40:47] prod.INFO: [ERROR] [openai_50] [486/500] CoffeeCup Free DHTML Menu Builder [Idle timeout reached for "https://api.openai.com/v1/chat/completions".]

How did y'all get access to the GPT 4 api already 😢

change your php.ini and apache settings.

Are you able to offer examples of this? I too have been having issues streaming GPT-4. I can do it with 3.5 but 4 keeps timing out (I keep hitting the 30s timeout on AWS (Vapor)).
I know some of the timeouts with 3.5 over the weekend were network related as they have been having many issues, but I would love to know how to properly set this up in production.
Locally, it streams fine--but obviously this is less than ideal for paying users.

Hi @Pierquinto
Hope our release yesterday resolved your issues with GPT-4.
Otherwise don't hesitate to reopen the issue.

we are seeing lots of timeouts even though our timeout is set to 8 mins! This is with GPT-4. GPT3.5 works fine but has such a small token limit that it doesn't work for our use case

I'm still seeing this pop up in the latest version (0.7.3), specifically for the GPT-4 model. It occurs exactly at 30 seconds, so it's clearly some kind of timeout. But strange that this doesn't also happen for GPT-3.5, only for GPT-4 model.
But I've already set every Nginx and PHP setting that I know of:
Nginx:
proxy_read_timeout 360s;
proxy_connect_timeout 20s;
proxy_send_timeout 360s;
client_body_timeout 360s;

fastcgi_buffers 16 32k;
fastcgi_buffer_size 64k;
fastcgi_busy_buffers_size 64k;
fastcgi_connect_timeout 360s;
fastcgi_send_timeout 360s;
fastcgi_read_timeout 360s;

PHP:
request_terminate_timeout = 180


Forforeach/allow whitespaces instead of entry date in 61 statement

In city files there are white 4 spaces instead of entry date. This PR allows empty spaces instead of digits

Hey @wolph, thanks for this library. We are using it to process mt940 files and it works well. Recently we received a couple of files that failed to process due to whitespaces instead of the entry date.
I opened this PR that attempts to allow such a situation and passes it gratefully.
Let me know what you think

Apologies for the really slow response, life is just crazy at times :)
Really nice pull request with tests and everything, love it! I'm merging it straight away and I'm working on a new release to address all of the open issues.


Add CentiBitcoin to denominations

I was looking to maintain compatibility easily with core tests, and many of the tests use cent denominations.  It would be nice to be able to use cent as a denomination in rust-bitcoin as well.

nit: We could add "cBTC" to the test function  denomination_string_acceptable_forms

I'm kinda tempted to just support all SI prefixes...

@tcharding

As an addition to the current PR, we could add "cBTC" to the test function  denomination_string_acceptable_forms
One of the things I noticed with denomination_string_acceptable_forms is that cBtC, cBTc, CBTc etc are all also valid...

I'm kinda tempted to just support all SI prefixes...

I'd be happy to add k (kilo). We probably don't want M because it's almost never used and may be confused with m, which is commonly used. G, T, ..., are all impossible.
We alreday support n and p (nano, pico), though TBH I don't quite understand how these are used. Not sure that going smaller has any value, since a micro-BTC is already a couple of pennies and we're going down to a millionth of that..
Are there any others that we're missing?

@tcharding

As an addition to the current PR, we could add "cBTC" to the test function  denomination_string_acceptable_forms

One of the things I noticed with denomination_string_acceptable_forms is that cBtC, cBTc, CBTc etc are all also valid...

Yes you are correct, IIRC that was by design. I'd ack it if you changed it to be more restrictive but I'm not too fussed either way.

Perhaps we should use "mSAT" instead of the current "msat" i.e., always capitalise SAT (this fits in with "sats" being the colloquial and lower case). Then we could enforce BTC always in capitals as well and then we can enforce the first letter is case sensitive i.e., then  there is only a single acceptable form with regards to capitalisation.

This whole capitalisation is messy either way. If we're going to make something more restrictive then I'd propose forbidding BtC and so - either whole unit is capitalised or it isn't.


Google Maps API multiple times on this page

Hey Guys! Whats up?
I am having a problem using the library in Ionic 2
Everytime I am navigating to the screen with the angular2 google maps is like is creating the map again
And I am getting this error:
     You have included the Google Maps API multiple times on this page. This may cause unexpected errors.

Any help, please?

I tested today. This is working fine for me!
Have you included any locations dependencies from Google in your Index scripts?

No, absolutely nothing :(
Do you have an example of yours?

I'm facing the same problem now.
But I think, I should mention, that I had to import the API in the index.html file already, as I need it for the Autocomplete API. I think that scenario is close to @jlsuarezs problem, as I think to remember, that Ionic loads the Maps API by default.
Still I think there should be a check for multiple loads.

@jlsuarezs @doncabron there is a common error that happens when you load the GOOGLE_MAPS_PROVIDERS in the wrong place. When you load it in your component where you use the map and the component get instantiated multiple time (e.g. page changes), then the api will load multiple times on the page.
So, make sure you use GOOGLE_MAPS_PROVIDERS in your bootstrap() method or in your root app component. Hope this helps :)
Closing this now. Feel free to reopen if you think there is a bug.

Hi, I'm having this same problem on Ionic 2.
I've set the GOOGLE_MAP_PROVIDERS inside ionicBootstrap(), but it seems to load the api twice if the page with GOOGLE_MAP_DIRECTIVES is the root page when the app initially loads.
It works well when the app initially loads on another page without the maps, and then going to the page with google maps.

same problem here!

same problem here ..

same problem

@itzharDev when I delete any of those, the app doesn't work anymore.


Fix main -> rebranch automerge

Merge remote-tracking branch 'main' into 'rebranch'
Conflicts:
CMakeLists.txt
Take new BRIDGING_MODE
+ option(BRIDGING_MODE [=[
+ How swift-C++ bridging code is compiled:
+     INLINE:       uses full swift C++ interop and briding functions are inlined
+     PURE:         uses limited C++ interp an bridging functions are not inlined
+     DEFAULT:      based on the build configuration
+ ]=] DEFAULT)
+
 +option(SWIFT_USE_SYMLINKS "Use symlinks instead of copying binaries" ${CMAKE_HOST_UNIX})
 +set(SWIFT_COPY_OR_SYMLINK "copy")
 +if(SWIFT_USE_SYMLINKS)
 +  set(SWIFT_COPY_OR_SYMLINK "create_symlink")
 +endif()
 +

SwiftCompilerSources/Sources/SIL/GlobalVariable.swift
Take new
private extension TupleExtractInst {
  var isResultOfOffsetSubtract: Bool {
    if fieldIndex == 0,
       let bi = tuple as? BuiltinInst,
       bi.id == .USubOver,
       bi.operands[1].value is IntegerLiteralInst,
<<<<<<< HEAD
       let overFlowFlag = bi.operands[2].value as? IntegerLiteralInst,
       overFlowFlag.value.isZero() {
||||||| 8b40353e22f
       let overFlowFlag = bi.operands[2].value as? IntegerLiteralInst,
       overFlowFlag.value.isNullValue() {
=======
       let overflowLiteral = bi.operands[2].value as? IntegerLiteralInst,
       let overflowValue = overflowLiteral.value,
       overflowValue == 0
    {
>>>>>>> upstream/main
      return true
    }
    return false
  }
}

turned into
private extension TupleExtractInst {
  var isResultOfOffsetSubtract: Bool {
    if fieldIndex == 0,
       let bi = tuple as? BuiltinInst,
       bi.id == .USubOver,
       bi.operands[1].value is IntegerLiteralInst,
       let overflowLiteral = bi.operands[2].value as? IntegerLiteralInst,
       let overflowValue = overflowLiteral.value,
       overflowValue == 0
    {
      return true
    }
    return false
  }
}

CC @eeckstein please take a look. These seem to be from your patches. Also, can you properly namespace your cmake variables in the future? Thanks.

@swift-ci please smoke test

I'm going to merge to unblock the automerger. The macOS bot is currently building llbuild, which is pretty late-game. It has already run the Swift tests, which passed:
6 warning(s) in tests
Slowest Tests:
--------------------------------------------------------------------------
243.08s: Swift-validation(macosx-x86_64) :: Python/swift_build_support.swift
180.31s: Swift-validation(macosx-x86_64) :: Sema/type_checker_perf/slow/rdar19612086.swift
157.68s: Swift(macosx-x86_64) :: Prototypes/CollectionTransformers.swift
143.18s: Swift(macosx-x86_64) :: Interop/Cxx/stdlib/foundation-and-std-module.swift
143.10s: Swift(macosx-x86_64) :: Sema/availability_stored_unavailable_maccatalyst.swift
135.73s: Swift-validation(macosx-x86_64) :: BuildSystem/llvm-targets-options.test
116.02s: Swift(macosx-x86_64) :: Interpreter/objc_implementation_swift_client.swift
96.99s: Swift(macosx-x86_64) :: Generics/rdar74321043.swift
74.76s: Swift(macosx-x86_64) :: refactoring/ConvertAsync/basic.swift
70.16s: Swift(macosx-x86_64) :: IDE/complete_macros_expanded.swift
68.77s: Swift-validation(macosx-x86_64) :: BuildSystem/infer-cross-compile-hosts-on-darwin-macosx.test
64.12s: Swift(macosx-x86_64) :: Driver/loaded_module_trace_foundation.swift
63.79s: Swift(macosx-x86_64) :: Driver/loaded_module_trace_header.swift
54.57s: Swift-validation(macosx-x86_64) :: BuildSystem/llvm-targets-options-for-cross-compile-hosts.test
52.77s: Swift-validation(macosx-x86_64) :: BuildSystem/default_build_still_performs_epilogue_opts_after_split.test
48.85s: Swift(macosx-x86_64) :: SourceKit/CursorInfo/cursor_info.swift
47.44s: Swift(macosx-x86_64) :: RemoteAST/foreign_types.swift
47.25s: Swift(macosx-x86_64) :: refactoring/ConvertAsync/convert_params_single.swift
47.17s: Swift(macosx-x86_64) :: Interpreter/dynamic_replacement.swift
47.15s: Swift(macosx-x86_64) :: refactoring/ConvertAsync/convert_function.swift

Tests Times:
--------------------------------------------------------------------------
[   Range   ] :: [               Percentage               ] :: [   Count   ]
--------------------------------------------------------------------------
[240s,260s) :: [                                        ] :: [    1/16828]
[220s,240s) :: [                                        ] :: [    0/16828]
[200s,220s) :: [                                        ] :: [    0/16828]
[180s,200s) :: [                                        ] :: [    1/16828]
[160s,180s) :: [                                        ] :: [    1/16828]
[140s,160s) :: [                                        ] :: [    3/16828]
[120s,140s) :: [                                        ] :: [    1/16828]
[100s,120s) :: [                                        ] :: [    1/16828]
[ 80s,100s) :: [                                        ] :: [    0/16828]
[ 60s, 80s) :: [                                        ] :: [    5/16828]
[ 40s, 60s) :: [                                        ] :: [   19/16828]
[ 20s, 40s) :: [                                        ] :: [   78/16828]
[  0s, 20s) :: [*************************************** ] :: [16718/16828]
--------------------------------------------------------------------------

Testing Time: 1690.03s
  Unsupported      :   450
  Passed           : 16841
  Expectedly Failed:    40


[storescu|echoscu] Compact way to set called AE title

As a user of these tools, I would like to specify the called application entity title alongside the AE host and address, making it compact and easier to remember.
Instead of this:
dicom-storescu --called-ae-title PACS-ARCHIVE localhost:104

I would be able to write:
dicom-storescu PACS-ARCHIVE@localhost:104

I believe this would require a change of the dicom-storescu syntax from:
dicom-storescu [FLAGS] [OPTIONS] <addr> [files]...

to:
dicom-storescu [FLAGS] [OPTIONS] <called-ae-title> | <addr> [files]...

And the equivalent for dicom echoscu (without the files tokens).
We would need also to keep backwards compatibility with older versions.


bump linuxkit to version that supports sbom; disable for now

This is the first of several small PRs to change how we generate SBoMs. It is meant to fix our missing SBoMs from the new external kernel format, but also simplify and speed up our SBoM generation.
This PR just bumps to the latest version of linuxkit, which has support for adding SBoMs both to packages via linuxkit pkg build (using buildkit's sbom support), and collating those in the final image via linuxkit build.
For now, the package-sbom part is enabled (by default), which won't do anything with it yet. Since package contents are unchanged, and therefore the tags are unchanged, it won't rebuild anything. Any changes to a package after this PR merges will pick that up and get the SBoM added to the OCI image.
The collating part that happens when you build the rootfs, via linuxkit build, is disabled in this PR. We are keeping the current method through the next few PRs, where we run one big scan on the final rootfs.tar.
The entire list of PRs for this process are:

This one to bump linuxkit but disable final image sbom collation
Make insignificant changes to all of our packages (e.g. adding a comment line), which changes the git tree hash, forcing a rebuild. Since it will be after this PR, those rebuilds will include SBoMs on all of the packages.
Add SBoM generation to eve-kernel
Enable SBoM collation in the final linuxkit build of rootfs.tar, which will work since all of the packages will have been updated with SBoMs. Simultaneously, disable the current sbom generation, and update the process that collates sources to get it from the newly-generated final SBoM

cc @mikem-zed

It does @eriknordmark ; I'm working on that separately.

Second one in place with #3595
I already opened a similar PR for our upstream linuxkit packages, which should merge in shortly.

Created an issue for 3 here. @mikem-zed can you do that?


Add support for syntax which finds directory anywhere in repository

Description
Changes proposed in this pull request:

Add support for syntax which finds directory anywhere in repository

Related issue(s)
Fixes #68

what's the status of this? Is it safe to use the current head of the source branch atm?


Add delete button to dashboard post/page list

Each row in the post/page list should have a delete button.

looks like this is added, at least in dev; closing the issue


Onboarding Form Steps 1 and 3 Logic

Scope of changes
Implements form logic for steps 1 and 3 of onboarding form.
Notes:
An error message appears stating that all of the fields aren't complete at the end of the video provided below. However, all of the fields are completed. I didn't see an error response in my network. In addition, the regular sidebar appears a few seconds after the error message appears. Could this be happening because of the check on line 46 of step 4's form?
Fixes SC-20564 & SC-20567
Type of change

[x] new feature
[ ] bug fix
[ ] documentation
[ ] testing
[ ] technical debt
[ ] other (describe)

Acceptance criteria
https://www.awesomescreenshot.com/video/20605256?key=2010f92cefbd9cfc2f4b038b54207bda
Definition of Done

[x] I have manually tested the change running it locally (having rebuilt all containers) or via unit tests
[ ] I have added unit and/or integration tests that cover my changes
[ ] I have added new test fixtures as needed to support added tests
[ ] I have updated the dependencies list if necessary (including updating yarn.lock and/or go.sum)
[ ] I have recompiled and included new protocol buffers to reflect changes I made if necessary
[x] Check this box if a reviewer can merge this pull request after approval (leave it unchecked if you want to do it yourself)
[x] I have notified the reviewer via Shortcut or Slack that this is ready for review
[ ] Front-end: Checked sm, md, lg screen resolutions for effective responsiveness
[ ] Backend-end: Documented service configuration changes or created related devops stories

Reviewer(s) checklist

[ ] Front-end: I've reviewed the Figma design and confirmed that changes match the spec.
[ ] Any new user-facing content that has been added for this PR has been QA'ed to ensure correct grammar, spelling, and understandability.
[ ] Are there any TODOs in this PR that should be turned into stories?

Scope of changes
Implements form logic for steps 1 and 3 of onboarding form.
Notes: An error message appears stating that all of the fields aren't complete at the end of the video provided below. However, all of the fields are completed. I didn't see an error response in my network. In addition, the regular sidebar appears a few seconds after the error message appears. Could this be happening because of the check on line 46 of step 4's form?

The regular sidebar appears because the member status changes from Onboarding to Active.

Fixes SC-20564 & SC-20567
Type of change

[x]  new feature
[ ]  bug fix
[ ]  documentation
[ ]  testing
[ ]  technical debt
[ ]  other (describe)

Acceptance criteria
https://www.awesomescreenshot.com/video/20605256?key=2010f92cefbd9cfc2f4b038b54207bda
Definition of Done

[x]  I have manually tested the change running it locally (having rebuilt all containers) or via unit tests
[ ]  I have added unit and/or integration tests that cover my changes
[ ]  I have added new test fixtures as needed to support added tests
[ ]  I have updated the dependencies list if necessary (including updating yarn.lock and/or go.sum)
[ ]  I have recompiled and included new protocol buffers to reflect changes I made if necessary
[x]  Check this box if a reviewer can merge this pull request after approval (leave it unchecked if you want to do it yourself)
[x]  I have notified the reviewer via Shortcut or Slack that this is ready for review
[ ]  Front-end: Checked sm, md, lg screen resolutions for effective responsiveness
[ ]  Backend-end: Documented service configuration changes or created related devops stories

Reviewer(s) checklist

[ ]  Front-end: I've reviewed the Figma design and confirmed that changes match the spec.
[ ]  Any new user-facing content that has been added for this PR has been QA'ed to ensure correct grammar, spelling, and understandability.
[ ]  Are there any TODOs in this PR that should be turned into stories?

@masskoder In the video, you should see that an error message appears stating that all of the fields aren't complete. However, they are. The dashboard changes after the status updates, but the user has to click Next again to be navigated to the completion step. The issue is that the user shouldn't see an error message if all of the fields are complete. Also, they shouldn't have to click Next twice if they have completed all of the required fields.


Down arrowhead icons on compose page have no accessible name

Checklist

[X] I have used the search function to see if someone else has already submitted the same bug report.
[X] I will describe the problem with as much detail as possible.

App version
8.0b1
Where did you get the app from?
Google Play
Android version
14
Device model
Pixel 5
Steps to reproduce

Start the Android TalkBack screen reader.
Open Thunderbird Beta.
Compose a new email message.
Use TalkBack to navigate to the down arrowhead icon next to the From field, or the icon next to the To field.

Expected behavior
TalkBack says the purpose of the button, such as "more" or "expand" or "additional fields".
Actual behavior
TalkBack says "unlabeled button" and does not convey the purpose of the button.
Logs
No response

I would like to work on this issue.

Hi @kewisch  I'd like to work on this issue. Could you please assign it to me?


Placeholder Issue, New Automerge Text vs RawText

I think we want to migrate many types to RawText in Automerge 3.
What are they? How should that migration happen?

Do you mean the RawString type from the javascript @automerge/automerge/next package? If so there would be nothing to do in this package I think. The equivalent of RawString in autosurgeon is String.
However, with the advent of automerge/next more people will be using Text (as in the RGA text CRDT in automerge) where previously they would have been using String and we might want to introduce equivalent functionality in autosurgeon. One way to do that would be to extend the autosurgeon attribute for strings like this:
#[dervive(Hydrate, Reconcile)]
struct Contact{
    #[autosurgeon(representation = "text")]
    name: String
}

In general I think we should be using newtypes which implement Hydrate/Reconcile to achieve this kind of thing but for string specifically this feels like it might be worth it given that it is so ubiquitous?


Detect shellslash on Windows

Windows users may have set shellslash in their vimrc without changing their shell.
https://www.reddit.com/r/neovim/comments/e1vl6o/plugupdate_not_working/
Actual fix is to port https://github.com/junegunn/fzf/commit/7a11a06cbd03353e7c0c7ddc25cd6e9fe58cef6d#diff-24d9d57e35df5afce7890f2400917919R29-R76 from fzf Done. Works on Vim. Neovim breaks if shellslash is set. Don't know why.

I give up. On Neovim, set shellslash with any shell breaks vim-plug on Windows. Vim allows both shellslash and noshellslash for any shell after this change. Tried using system([]) to reduce the batchfiles on Neovim but there's no effect. It might be failing on s:spawn or earlier.

Neovim works with set shellslash if, on s:spawn, set noshellslash is set temporarily within try/finally/endtry. Why?

Any further updates? I think shell=cmd.exe and shellslash is more convenient for cross platform developing, especially for guys like me who are coding both on Windows and *nix using vim as portable solution

@ZSaberLv0 If you upgrade your Vim, you can set completeslash instead. If that's insufficient and there is a regression, create a new ticket. set shell=cmd.exe shellslash is a landmine because of shellescape, tempname, and other functions and options that deal with filepaths. Vim and Neovim haven't fixed it for Windows to this day and many 3rd-party plugins break if you use non-default shell settings.

thanks for your tip, I'll try completeslash


ci(publish): explicitely reference docker hub as registry

Fix the docker publication on the Docker Hub, login was done the the registry was missing in the image names.

:tada: This PR is included in version 2.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add tiny example to Client

Writing examples seems to be a good way to learn rust! Anyway, I'm not sure this example is good enough for your doc. Feel free to close: I already learned a bit by writing it.

Thanks for the pull request! I think the Client could use an example like you sent. It'd probably be best to hide several of the lines (put a # at the start of the line). All the imports, and the function wrappers.
I'd also be sure to put the client in a variable, since the docs just above suggest holding on to it.

@seanmonstar Ok thanks! I'm not familiar with hidding lines. I tried to hide imports and function wrapper but I'm not sure I done it right. I also put the client in a variable. Hope it's good enough now!

Hi all ^_^
Little ad for you :)
There is project https://github.com/shmutalov/gitter-rs using reqwest :P Maybe helpfull

Cool, thanks!


Lost records from the Subscribe() channel when records arrive concurrently

Reproducible by commit https://github.com/textileio/go-threads/commit/66af150f51efb296c7c6591248acb15e840a6dd8 . Run following and you'll see some record appears only 2 times, rather than expected 3.
GOTRACEBACK=all  testground run single --wait -p go-threads -t sync-threads -b exec:go -r local:exec -i 2 -tp records=10 -tp verbose=2 | grep "record #" | cut -d ":" -f 4- | sort | uniq -c | sort -r

It doesn't seem to relate to https://github.com/textileio/go-threads/issues/525 .

Note that the logic has changed a bit to surface the issue.


Missing setter for connectionStringSource in MongoDb4Provider

Description
It's no way to create MongoDb4Provider programmatically.  Setter for  connectionStringSource is missing in Builder.
Configuration
Version: 2.14.0+  (From the first version when MongoDB 4 support was added)

Thanks so much for the report and the PR @ihordz, much appreciated! I will merge them momentarily.
You are both right and wrong. You're right that MongoDb4Provider indeed doesn't expose connectionStringSource in its builder. That said, you don't (and shouldn't!) need that for programmatic configuration. You shouldn't be using the MongoDb4Provider class directly, but rather be accessing it via AppenderComponentBuilder. See the programmatic configuration guide for details.
As a matter of fact, by accessing the classes directly rather than using the configuration API, you are walking on thin ice. Log4j crew strives to provide backward compatibility at the API (i.e., log4j-api) and configuration level, though we are not that strict when it comes to the implementation (i.e., log4j-core) itself. Hence, I strongly advise you to always stick to the configuration API for programmatic configuration.

Thank you @vy for quick merge and good advice.