zooming in remote pdf

I have integrate your library in my app. But am facing an issue when am populating the downloaded pdf from remote server. The issue is that the pdf is not zoomable.
Part of the xml is :
     <es.voghdev.pdfviewpager.library.PDFViewPagerZoom
        android:id="@+id/pdfViewPager"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_weight="1.55"
      />

Am able to download and view the pdf in the activity. The portion of the code is given below:
public class Pdf extends AppCompatActivity implements DownloadFile.Listener{
  RemotePDFViewPager remotePDFViewPager;
 PDFPagerAdapter adapter;
   PDFViewPager pdfViewPager;

 @Override
public void onCreate(Bundle savedInstanceState){
    super.onCreate(savedInstanceState);
remotePDFViewPager = new RemotePDFViewPager(getBaseContext(), "http://partners.adobe.com/public/developer/en/xml/AdobeXMLFormsSamples.pdf",this);
           pdfViewPager = (PDFViewPager) findViewById(R.id.pdfViewPager);
}

public static void open(Context context){
    Intent i = new Intent(context, Pdf.class);
    context.startActivity(i);
}

  @Override
    public void onSuccess(String url, String destinationPath) {

    adapter = new PDFPagerAdapter(this, FileUtil.extractFileNameFromURL(url));
     pdfViewPager.setAdapter(adapter);
 }

In onSucces if am using PDFPagerAdapterZoom , the pdf which gets loaded to activity is so small, then too am able to zoom it. But I want the pdf to be as the size when I use PDFPagerAdapter and with zooming option in it.
How to make pdf as the size of when it loads via PDFPagerAdapter with zooming ?

Hello,
If I haven't understood you wrong, you want to set up an initial zoom level in the PDF document, then be able to zoom/unzoom it.
The issue is similar to this other. I'm trying to implement an elegant default zooming solution, but haven't found the best one yet.
I suggest you to do what the user does,
pdfViewPager.setScaleX(1.5f);

When I give
pdfViewPager.setScaleX(1.5f);
I finding that the ui is not looking good.
If is give pdfViewPager.setScaleY(1.5f);
I could see that some portion of pdf am not able to see. Is there any solution for the same ?

Hello,
yes, you can do that. Just download the PDF file and assign it a zooming pager adapter when download is complete.
Have a look at the samples, I think one of the remote ones is zoomable.
Just use the zoomable adapter.
Let me know if it helps :)
Thanks for using the lib

De: shyamsam<EMAIL_ADDRESS>Enviado: jueves, 9 de junio de 2016 8:47
Para: voghDev/PdfViewPager
Asunto: [voghDev/PdfViewPager] zooming in remote pdf (#8)
May I know what are changes to be done when am downloading a pdf from a remote server. As per your sample it shows the pdf in the actvity, but is it possible to make that pdf zoomable ?

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/voghDev/PdfViewPager/issues/8, or mute the threadhttps://github.com/notifications/unsubscribe/AEu88K_5mzMG8O00W_3MlSLDsMfnVtxKks5qJ7bogaJpZM4IxrPO.

In next releases of the lib I'm planning to set a default zoom level. It is not done yet.
You can check changes in the make_scale_setable branch.
Thx for using the lib! Hope you like it

De: shyamsam<EMAIL_ADDRESS>Enviado: jueves, 9 de junio de 2016 12:23
Para: voghDev/PdfViewPager
Cc: Olmo Gallegos; Comment
Asunto: Re: [voghDev/PdfViewPager] zooming in remote pdf (#8)
When I give
pdfViewPager.setScaleX(1.5f);
I finding that the ui is not looking good.
If is give pdfViewPager.setScaleY(1.5f);
I could see that some portion of pdf am not able to see. Is there any solution for the same ?

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/voghDev/PdfViewPager/issues/8#issuecomment-224856446, or mute the threadhttps://github.com/notifications/unsubscribe/AEu88BByCr_J3ickIChjZrJFMuXwUBvWks5qJ-mugaJpZM4IxrPO.

Hi again,
version 1.0.0 of the library has been released. You can now set a default scale to the PDFPagerAdapter, so every rendered page will have this scale applied.
There is a sample included in samples project, have a look at it and let me know if it suits your needs.
Thanks


0.4.1

Codecov Report

Merging #17 (286b19f) into main (74c6cde) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #17   +/-   ##
=======================================
  Coverage   97.24%   97.24%
=======================================
  Files           8        8
  Lines         363      363
  Branches      102      102
=======================================
  Hits          353      353
  Misses         10       10

Continue to review full report at Codecov.

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


Anka cache builder

Fixes runtimeverification/devops#24

This does not seem sufficient to get rid of the intermittent errors, but it is still a marked improvement, so I'd like to get it merged.

I put an approval on this, @dwightguth . Please consider my concerns above about the OCaml backend tests not working on master builds, and if there are big changes (in addition to the above), ping me again.


License reported to be open-source in documentation

Provide a link to the page with an issue:
https://docs.pachyderm.com/latest/enterprise/overview/
Describe what is wrong:
It seems to me that the above depiction of a "Pachyderm Open Source Core" doesn't represent Pachyderm's licensing terms correctly.
As far as I understood Pachyderm is not open source, at least since the following commit:
https://github.com/pachyderm/pachyderm/commit/240e4d598c9977612ab3e180a4f4efe78ed04a23#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R76
This page seems to confirm that: https://www.pachyderm.com/about/pachyderm-community-license-faq/
Describe the suggested changes:
I propose to make the documentation more coherent by not describing Pachyderm's source-available core as Open Source.

Thank you for your feedback.
Your point is valid that Pachyderm Community Edition is not Open Source  (under the strict OSI definition of Open Source anyway). In the announcement you referenced (https://www.pachyderm.com/about/pachyderm-community-license-faq/), we openly notified the Community that we were shifting some components away from a stricto sensu, OSI-defined, open-source license and towards a source-available limited license. We also explained the reasons for this partial shift very transparently and reaffirmed that Pachyderm remains committed to the open-source culture.
I went ahead and searched for the term "open source" in our documentation. I found one remaining occurrence that is now gone (See attached PR).
I'll go ahead and close this issue but feel free to re-open it if you feel like the issue has not been addressed.
Thank you for being a user.


Mas i1793 repairkeysrange

Add fold to accelerate read repair on ranges on keys.
The fold will simply prompt a GET on every key, which will in turn prompt a read_repair if that is necessary.
Some consideration was given to making a more targeted change - e.g. only GET those keys that exist on a specific node with a known repair requirement.  However, preference is to keep the change a simple as possible, with some flexibility in the API to divert from specifying all to repair in a future change.

Tes: https://github.com/basho/riak_test/pull/1357

https://github.com/basho/riak/discussions/1081


Unique no 3

Have you read the Contributing Guidelines on Pull Requests?
Yes
Description
Unique_no_3
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
#988

@HarshCasper @iamrajiv @Abhijit2505 @SKAUL05 Please review my code.

Made requested changes . Kindly review. @iamrajiv @SKAUL05 @Abhijit2505 @Kajol-Kumari @HarshCasper @atarax665

@ishi0301 Resolve the merge conflicts.

Resolved conflicts. @iamrajiv @HarshCasper @Abhijit2505 @SKAUL05 @Kajol-Kumari @atarax665 .Please review.

@iamrajiv removed that line

@iamrajiv formatted the code.

@SKAUL05 @Abhijit2505 kindly review.

@all-contributors please add @ishi0301 for code


Prime Suspect in "Game Breaking" Glitch

I've been trying to make a 1.12.2 modpack for me and the buds and I've run into a strange and extensive bug which even affects the game outside of modded. Whenever I download this mod, the skybox breaks. Rendering a black flickering streak visible across the sky. The damage is so bad in fact, that it somehow even affects non-modded versions of 1.12.2 (vanilla). I have no idea what's happening here, but it only happens when I download your mod. I have the latest java 8 and nvidia drivers, and it's only repairable with a complete reinstall of minecraft or the mod launcher you're using.

Are you using OptiFine?

Not at all.

All right, I've only ever seen this type of error in conjunction with OptiFine, and removing that fixed the issue. Since you said the error persists unless Minecraft or the launcher is reinstalled, I was thinking OptiFine may be present as mod inside the Minecraft jar file itself, making it seem like no mods are installed (since the mods folder is empty).
Particle Culling does not change anything about the sky, it does not change anything else either, other than stopping the call to the code that renders particles. There are no other modifications made that could influence something like this, or things saved that could persist between different Minecraft launches and even into vanilla.
To try and reproduce this, I installed just Particle Culling v1.3.1 and MixinBootstrap 1.1.0 with Forge 2860, loaded up an instance of Minecraft in a completely empty folder (apart from the mods of course), and I wasn't able to reproduce the issue. It also doesn't make sense that it happens without this mod installed, because how would it be able to change anything if it's not loaded. It's very unlikely to be this mod's fault because of that, and rather an external issue - perhaps something triggered when using different mods (including this one) together that clash, causing some wrong value to be written somewhere that persists over different game launches (but that's a wild theory - I am not aware of something persisting like this). It could be NVIDIA's GPU drivers (I have an AMD GPU, so I can't test that theory).
Unless some clear reproduction steps that work for me can be found, I won't look further into this. I consider this issue out of my control to be fixed.


Some considerations for reliable NCMC work values

There are a few things we should make sure we're doing in perses to get good, robust protocol work measurements:

Use the DeterministicForces platform property so that PME gives deterministic energies on CUDA
Use a tight integrator constraint tolerance to ensure that we converge constraints (1e-6 or smaller)
Use a PME tolerance of 1e-4 or smaller
Use mixed precision if available

I think most of these are being done already, but we want to make sure we got all of them in perses by default.

These conditions are all necessary for both relative free energy calculations and nonequilibrium switching, but nobody has ever confirmed these have been carefully implemented throughout.


Udonsharp Editor Error

Describe the bug in detail:
So the main Error I have been getting in Unity, when trying to put a new media player in, is something to do with Udon Sharp Editor, now its CsSharp, and some other things
Provide steps/code to reproduce the bug:
Just trying to add a Media player, Pro TV v 2.2 lastest update into the Suburban Lakehouse Package.

Follow the installation instructions, you need to use the unitypackage https://github.com/vrchat-community/UdonSharp#installation


[ENG-11090][eas-cli] prompt users if they want to continue if provisioning the devices fails

Why
https://linear.app/expo/issue/ENG-11090/prompt-user-whether-they-want-to-continue-if-we-fail-to-provision
How
Prompt users if they want to continue if we fail to provision the devices
Test Plan
(Yeah I know it says 0, I commented out the if statement to test it)

/changelog-entry chore Prompt users if they want to continue if EAS CLI fails to provision the devices


allow for adding/removing services after govisord is started.

loading a new service would require restarting supervisord, killing all the processes under
its current responsibility. similarly should be possible to disable and purge services, or reload
their definition. nice tool tho!

This is a good idea, and not too hard to implement -- after all its probably a relatively straight-forward thing to extend govisord -- the main logic here is "NewProcessFromJson".  We would just need to add some code to monitor for file changes -- and rather than a SIGHUP or something it should take a command over the REST API to rescan.


fix: line-width not dependant on screen width

This makes it so much more viewable on mobile devices using the default stylings for line width rather than explicitly defining it here. On other devices like laptops, there is no difference.

Device
before
after

iPhone

Laptop

I added a media query, it should be fine now. Unfortunately, I don't use obsidian on my phone, so I missed this problem, thanks


Firebase callFunction returns bad request when you add json data input.

Describe the bug
When using the firebase call function, adding data input returns bad request response from firebase. Two variations of this are observed.

Json data input returns bad request 400 result from firebase server.
When you just enter text and it succeeds, the req.body.data does not contain the data sent from the ESP32

Code:
FirebaseJson json;
json.set("data/message", "Some text data example.");
json.set("data/token", "Example of token data.");
String data;
json.toString(data, true);

// Serial.println(data.c_str());

if (Firebase.Functions.callFunction(&fbdo, FIREBASE_PROJECT_ID, PROJECT_LOCATION, "getAudio", data.c_str()))
{
  Serial.printf("ok\n%s\n\n", fbdo.payload().c_str());

}

To Reproduce
Steps to reproduce the behavior:

Run code snipper example provoked above. You will get a bad request response.
Replace the data.c_str() with just a plain string constant, and you also get a bad request reply.

Expected behavior
Json objects converted into string constants should appear as part of req.body.data object in cloud functions.
Screenshots
If applicable, add screenshots to help explain your problem.
IDE and its version:

PlatformIO - 5.1.1
Esspresif 32 3.2.0

Additional context
Can you also confirm if the library supports compatibility with both the cloud function onRequest and onCall functions.

You must  edit the json serialized string to keep the json tag to be parsed as string not serialized string.
For example
JSON object
{"a":"b"}
When pass to Firebase.Functions.callFunction
"{"a":"b"}" <-- invalid c char array or C++ string when used as payload
Use escape sequences is not enough
"{\"a\":\"b\"}"   which will translate to string payload  "{"a":"b"}" <-- still not valid C/C++ string
It should be
"{\\\"a\\\":\\\"b\\\"}" which will translate as the string payload "{\"a\":\"b\"}"
The functions argument will get string "{\"a\":\"b\"}"  which you need javascript JSON.parse to parse to JSON object like this.
var obj = JSON.parse(stringPayload);
Then use obj.message and obj.token in your cloud functions.
Then the solution is replace " in data payload with \\\" before pass to Firebase.Functions.callFunction

Above method may complicate I will add support to JSON type data in the next library update.

You can update the library to v2.2.3 and check this example for how to.


Add possibility to only add newly found properties and do not overwrite already existing ones

Sometimes the foods collected from Tandoor already have properties assigned and one does not want those properties to be overwritten.
For that case a possibility that already present properties are not overwritten should be added.
Th behavior should be as follows:

No properties are present => all properties retrieved from USDA should be assigned
Some properties are already present => only apply the ones that are not already present at the food
All properties are present => Do not do anything, do not even request data from the USDA database

Reopen because I made a mistake in the commit message which I only noticed after merging the PR. I reverted the changes.


feature request: expose presign API in python binding

In https://github.com/vastsa/FileCodeBox/pull/87, it needs presign function, and we havn't exposed it in python binding. So it's time to expose presign_stat, presign_read and presign_write of Operator in python binding.

Please note that not all services can implement the presign feature. I suggest prioritizing support for server relay first and then assessing if further action is necessary.


Mark node: as external for Node.js compatibility

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[x] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Explain
Last time I asked to add polyfill for Buffer API. That's no longer neccessary because Cloudflare added a bunch of nodejs APIs to Workers. They are all prefixed by node:.
Example:
import { Buffer } from 'node:buffer';

These APIs are enabled via compatibility_flags nodejs_compat and work for Workers, Pages and wrangler.
The APIs is here: Node.js compatibility

I'm for this change but I think it may make sense having it behind some sort of config option, maybe nodeCompat? That way we can document what this means and not suddenly start allowing node packages for people who don't know what that means on Cloudflare.

I'm for this change but I think it may make sense having it behind some sort of config option, maybe nodeCompat? That way we can document what this means and not suddenly start allowing node packages for people who don't know what that means on Cloudflare.

I committed the suggested solution yesterday, not sure GitHub will notify the mods so that I quote your reply here.

We should also add notes to the docs about this :pray: We'll also will need some opinions from other maintainers before we can merge

We generally try to avoid adding options, so unless there's a scenario where we don't want to do it, I would suggest we should always do it.
However, I'm not sure whether it's enough? @cimnine reported in https://github.com/sveltejs/kit/pull/10521 that they had to use alias to actually address an issue using a Node.js module. Is there some kind of guidance we could provide users as to when external is sufficient and when alias would be required?

However, I'm not sure whether it's enough? @cimnine reported in https://github.com/sveltejs/kit/pull/10521 that they had to use alias to actually address an issue using a Node.js module. Is there some kind of guidance we could provide users as to when external is sufficient and when alias would be required?

I'm still not 100% sure what the decision is re: various esbuild options being passable to the adapters - regardless this might be a nice change to reduce friction even if we do end up merging one of the esbuild option related prs - WDYT? @benmccann

any updates on this? can't get postgres working on cloudflare and this might be related

any updates on this? can't get postgres working on cloudflare and this might be related

You can try my adapter while waiting @chientrm/adapter-cloudflare.
Remember to add flag nodejs_compat to your Workers or Pages.

Hello, will the fix be merged anytime soon ?

any updates on this? can't get postgres working on cloudflare and this might be related

You can try my adapter while waiting @chientrm/adapter-cloudflare.
Remember to add flag nodejs_compat to your Workers or Pages, and set adapter: adapter({ nodeCompat: true }).

Unfortunately, that doesn't work for me. I get these errors on Cloudflare Pages during build:
The package "stream" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.

The same with a lot other Node packages in nodemailer.

any updates on this? can't get postgres working on cloudflare and this might be related

You can try my adapter while waiting @chientrm/adapter-cloudflare.
Remember to add flag nodejs_compat to your Workers or Pages, and set adapter: adapter({ nodeCompat: true }).

Unfortunately, that doesn't work for me. I get these errors on Cloudflare Pages during build:
The package "stream" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.

The same with a lot other Node packages in nodemailer.

how do you import stream?

any updates on this? can't get postgres working on cloudflare and this might be related

You can try my adapter while waiting @chientrm/adapter-cloudflare.
Remember to add flag nodejs_compat to your Workers or Pages, and set adapter: adapter({ nodeCompat: true }).

Unfortunately, that doesn't work for me. I get these errors on Cloudflare Pages during build:
The package "stream" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.

The same with a lot other Node packages in nodemailer.

how do you import stream?

I do not import it, but nodemailer does.

you can fork nodemailer and make it import node:stream instead of stream. Docs here: https://github.com/sveltejs/kit/pull/10544#issuecomment-1870098868

any updates on this? can't get postgres working on cloudflare and this might be related

You can try my adapter while waiting @chientrm/adapter-cloudflare.
Remember to add flag nodejs_compat to your Workers or Pages, and set adapter: adapter({ nodeCompat: true }).

Unfortunately, that doesn't work for me. I get these errors on Cloudflare Pages during build:
The package "stream" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.

The same with a lot other Node packages in nodemailer.

how do you import stream?

I do not import it, but nodemailer does.

I updated my @chientrm/adapter-cloudflare recently, it enable node compat by default, no need adapter: adapter({ nodeCompat: true }). At this point I don't think the team's gonna merge this pull request. You may aswell fork your own adapter and publish for your personal use.

Hmm, I don't know how to merge this commit lol.

I merged it via the GitHub UI for you

@chientrm @benmccann @Rich-Harris Thanks! 🎉

@Rich-Harris While things are better, still are still un-usable in some cases :/
When bundling a project with wrangler and the node_compat flag, several things happens

https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/deployment-bundle/esbuild-plugins/nodejs-compat.ts this plugin flags all node modules are externals.

These polyfills https://github.com/cloudflare/workers-sdk/blob/ef0642796dbe17b30fd7b83ccfd3efc651ce0a1a/packages/wrangler/src/deployment-bundle/bundle.ts#L334 are injected

This allows cloudflare workers and cloudflare pages projects to correctly build if there's a supported library such as "pg" that doesn't use "node:x" specifiers and use incompatible APIs.
Note that there's also an issue with wrangler deploy where this is not possible to specify node_compat: true, therefore the project must be built manually, then deployed.
To recap, I'm using a forked version of the cloudflare adapter to treat everything as externals and to inject the polyfills.
Another gotcha is that the nodejs compatibility flag is not compatible with the polyfills while building with wrangler ... But it's still possible to build manually and enable the flag.
I'm not sure what would be a possible solution, but it would be nice to enable esbuild custom settings for the cloudflare adapters.

I am getting exceptions for every single package I am trying to use.
{
  "outcome": "exception",
  "scriptName": "pages-worker--1989843-preview",
  "diagnosticsChannelEvents": [],
  "exceptions": [
    {
      "name": "Error",
      "message": "Dynamic require of \"node:crypto\" is not supported",
      "timestamp":<PHONE_NUMBER>319
    }
  ],
}

Using:

"@sveltejs/kit": "^2.5.0"
"@sveltejs/adapter-cloudflare": "^4.1.0"

I think, inside 'hooks.server.ts', got a custom handle which performs:
import {V4} from 'paseto'
...
await V4.verify(sessionToken, secretKey)

and I suspect that's the issue.
Got "nodejs_compat" flag enabled but it does not help.

Yep, I even changed it to something else to see if the build fails and it does.

According to the documentation the flag name is: "nodejs_compat"

Is this supposed to work for Pages Adapter or do I have to use Worker adapter, because I am still getting the Could not resolve "crypto" or Could not resolve "node:crypto".

Same question as @absktoday but for a dependency that is attempting to import url. Cloudflare states this is supported in Pages, and yet the adapter throws an error. I am using Cloudflare Pages which does not use wrangler.toml (as far as I know?). I created one anyways to see if it would "trick" the adapter but it did not work. My workaround is to fork the dependency and remove those imports :(

Is the error at runtime on Cloudflare pages, or at buildtime either locally or on the CF pages builder @devinellis? What imports is the package using url or node:url? Could you share a minimal reproduction?

Sorry for the lack of detail:

The package is doing require('url'). Commenting these lines out in a fork made the problem go away.
It fails both locally and in the CF Pages builder.
Setting nodejs_compat in wrangler.toml or in the Pages Dashboard didn't seem to make a difference.

Note if I am reading the CF docs right, nodejs_compat no longer needs the node: prefix on package names, as long as your compatibility_date > 2024-09-23


rfc: simplify changelog process

This PR is also an RFC to simplify our changelog process.
The Current Process
We have an open PR that is being automatically updated periodically: https://github.com/artsy/eigen/pull/8135/files in theory with changes from most recent release. It looks for the last submission tag and parses our changelog messages out of the commits since that tag. Release captains then check this PR for relevant changes.
In practice this has been a little problematic:

There is no control over tags compared: so for example this week a hotfix went out so this became the submission compared against, however only a couple commits went into this hotfix so the changelog was incorrect
It leaves an open PR in the repo but it is unclear when if ever we want to merge it so it doesn't actually create a reviewable record of changes
If someone doesn't fill out changelog in big PRs they get missed
It is just a bit complicated, it needs an extra job in CI and periodic updates in the repo and multiple scripts to manage in the repo

All of these are solvable problems but I propose just simplifying a bit because I think the benefit of all this automation isn't actually worth the complexity.
Proposed process
When release captains are preparing for a release they run a changelog script locally with the target submission tag and the last submission tag. This will output something similar to this:
$ yarn ts-node scripts/changelog/generateChangelog.ts ios-8.12.5-2<IP_ADDRESS>-submission main                                                                                (base)
yarn run v1.22.19
$ ~/node_modules/.bin/ts-node scripts/changelog/generateChangelog.ts ios-8.12.5-2<IP_ADDRESS>-submission main
- bump @testing-library/react-native from 12.0.1 to 12.1.2 - gkartalis : Dev changes : PR #8682
- bump react-native-screens from 3.15.0 to 3.20.0 - gkartalis : Dev changes : PR #8683
- Artwork list sorting - sam : Cross-platform user-facing changes : PR #8672
- enable hermes on Android - gkartalis : Dev changes : PR #8658
- fix Median Auction Price result issue on Android - mrsltun : Android user-facing changes : PR #8685
- create collected artists grid view - mounir : Cross-platform user-facing changes : PR #8654
- refresh auction lots rail when lots close - kizito : Cross-platform user-facing changes : PR #8667
- format artwork description for artwork lists flow - dimatretyak : Dev changes : PR #8691
- update pagination count for artwork lists - dimatretyak : Dev changes : PR #8690
- add bottom offsets for artwork lists views - dimatretyak : Dev changes : PR #8696
- fix errors in the contact the specialist form -daria : Cross-platform user-facing changes : PR #8688
- enable hermes on iOS - gkartalis : iOS user-facing changes : PR #8659
- podfile update - gkartalis : Dev changes : PR #8707
- support pull-to-refresh on empty artwork list view - dimatretyak : Dev changes : PR #8706
- sync artwork save state with artwork lists - dimatretyak : Dev changes : PR #8713
- create artist preview bottom sheet modal (MyCollection) -daria : Cross-platform user-facing changes : PR #8686
- add ability to delete artwork list - dimatretyak : Dev changes : PR #8714
- Missed react native build phase change in upgrade - Brian : Dev changes : PR #8722
- correctly display total selected artwork lists counter - dimatretyak : Dev changes : PR #8728
- Remove myCollectionOnboarding wrong tracking event - mounir : Dev changes : PR #8729
- Context menu for artwork items - gkartalis : iOS user-facing changes : PR #8606
- dev menu weirdness on android - gkartalis : Dev changes : PR #8732
- Fix segment crash - Brian : Android user-facing changes : PR #8735
- Point to fixed segment version - Brian : Android user-facing changes : PR #8738
- Ability to edit artwork list - dimatretyak : Dev changes : PR #8720
- mark `AREnableArtworkLists` as ready for release - dimatretyak : Dev changes : PR #8747
- update app version to 8.13.0 - mrsltun : Dev changes : PR #8749
- Update debugging.mb - Brian : Dev changes : PR #8751
- don't display contextual menu button for "Saved Artworks" list - dimatretyak : Dev changes : PR #8752
- use relay fragment for artwork list header - dimatretyak : Dev changes : PR #8753
- Add docs for asdf - Brian : Dev changes : PR #8755
- Add location detection visualiser dev toggle - ole : Dev changes : PR #8757
- hot reloading experience + relay-config removal - gkartalis : Cross-platform user-facing changes : PR #8761
- correctly display artwork save state on artwork list screen - dimatretyak : Dev changes : PR #8760
- artwork list analytics (stage 1) - dimatretyak : Dev changes : PR #8763
- Fix public IP for location on "Shows for You" rail on home screen - ole : Cross-platform user-facing changes : PR #8758
- artwork list analytics (stage 2)  - dimatretyak : Dev changes : PR #8764
- support soft launch of artwork lists for Artsy employe - dimatretyak : Dev changes : PR #8769

PRs without changelog entries:
PR #8675: fix: UI blocking bugs
PR #8677: chore: update metaphysics graphql schema
PR #8676: refactor: use the same relay env for MyCollection screens
PR #8681: chore: update version number #trivial
PR #8687: refactor: update empty state for artwork lists
PR #8694: fix(CX-3637): adjust the avatar add button design
PR #8684: RFC: Add Geolocation service
PR #8693: fix: address menu item UI review comments
PR #8697: fix: hot reload when app is run using yarn start
PR #8665: [CX-3630] feat: Add location support to "Shows for You" rail
PR #8701: Revert "fix: hot reload when app is run using yarn start"
PR #8703: chore: update release note 8.12.5
PR #8705: chore(deps): update dep @artsy/cohesion from 4.125.1 to v4.126.0
PR #8699: Chore: prepare for 8.12.5
PR #8708: chore: update metaphysics graphql schema
PR #8692: fix(GRO-1645): add padding to results grid
PR #8718: chore: update metaphysics graphql schema
PR #8719: chore: prepare for 8.12.6
PR #8712: fix: Add ACCESS_FINE_LOCATION Android permission
PR #8717: fix: Disable Shows for You location feature flag
PR #8711: fix: Change error message to console log
PR #8721: fix: Remove totalCount from auctionResultsByFollowedArtists home screen queries
PR #8724: chore: update metaphysics graphql schema
PR #8726: chore: update metaphysics graphql schema
PR #8731: fix: hide context menu on android
PR #8734: fix: use large again for test js job
PR #8736: chore: mark vir ready for release #trivial
PR #8739: chore: minor dev menu improvements
PR #8727: chore: make artist list item clickable
PR #8740: chore: update metaphysics graphql schema
PR #8742: chore: update metaphysics graphql schema
PR #8746: chore: update metaphysics graphql schema
PR #8748: chore(deps): update dep @artsy/cohesion from 4.126.0 to v4.127.0
PR #8765: Revert "fix: hot reloading experience + relay-config removal"
PR #8754: feat(CX-3702): create artists grid view
PR #8767: chore(deps): update dep @artsy/cohesion from 4.127.0 to v4.129.0
PR #8768: Revert: "feat(iOS): Enable hermes on iOS"
✨  Done in 23.33s.

Release captains then paste that in the QA doc and use it going forward for release notes.
Later maybe we can decide to commit this back each release for now I propose just keeping it simple as you can always just run the script again with the same tags.
If Accepted

I will merge this PR deleting old changelog scripts
I will remove any ci using the old changelog scripts and close the PR
I will update the release captain docs to account for the new process

I am very much for this new process. The current process is a pain. 👍🏾👍🏾👍🏾👍🏾

thanks for all the feedback! merging! let me know if anyone runs into issues!


constructor -> classConstructor

This renames the constructor parameter of the JavaScript class object to classConstructor.  Since constructor is a property on object prototypes, we can't simply check if {class}.constructor exists or is non-null.

Could you share your use case? If you first check global.type === "class", constructor should always be an object or null.

Ah, I didn't have the check for type === "class" in place as well, whoops!  (I still think that the variable name should be different simply because it's already in use, but I'll let you decide whether or not it should be changed.)

Mmm, I can see how it's not ideal because it defeats the purpose of using a discriminated union when all your constituents have this property, but classConstructor sounds awkward. I'm very ambivalent.

(In the mdn-bcd-collector, we usector instead, if that helps at all!)

Sure, ctor sounds good to me. I was trying to use less abbreviations ^^


Created xy_3 example

Closes #95

I think this looks good. And I agree it makes sense to have plot 1 match the default settings rather than the NCL appearance. Are there any other keywords that can be used to manipulate a line plot in Python that we could also demonstrate?

I think this looks good. And I agree it makes sense to have plot 1 match the default settings rather than the NCL appearance. Are there any other keywords that can be used to manipulate a line plot in Python that we could also demonstrate?
@jukent
I added dash_capstyle to make the dashes rounded. I could add point markers, but with the dashes things get too cluttered. Point markers come up in a few NCL examples we haven't made in python yet (i.e. xy_37) so I think it might be best to leave the markers out of this example. Is there anything else you think I should add?

I think that's good! Nice work.


SpecAugment issue

I notice the SpecAugment code is still not quite right.  That previous suggestion to check the default parameter was made under the assumption that the current code is using Lhotse's SpecAugment, but it's not, it's using the one in asr_datamodule.py.  In fact, the current code is using the following defaults:
        time_warp_factor: Optional[int] = 80,
        num_feature_masks: int = 1,
        features_mask_size: int = 13,
        num_frame_masks: int = 1,
        frames_mask_size: int = 70,
        max_frames_mask_fraction: float = 0.2,
        p=0.5,

which interacts badly with the code:
if num_frame_masks_parameter.default == 1:
num_frame_masks = 2
... because I was assuming the default is 10 for the new code (as it is in Lhotse) but actuall this code uses a default of 1.
One fix might be to just change the current code's default to 10; another (probably better) would be to remove the current SpecAugment code and just import it from Lhotse.

I thought it was using the implementation from Lhotse. Will check.

Sorry my bad, was due to a merge.


Add FB13 dataset

Background and Context
FB13 dataset is useful because it contains labels for the validation and test sets.
Description
Add a load_fb13() to the datasets module.

Solved by #155


Windows OpenGL and bgra texture: Angle vs Wgl

Describe the bug
In my project, I'm using an opengl control to render a bgra texture (with silk.net). This worked fine in Linux, but when I switched to windows the texture is just black. When I switch to an rgba texture, the rendering is ok but with red and blue inverted, of course.
Now I noticed that using wgl (opengl core) instead default angle (opengl es) the texture is correctly rendered in bgra.
Unfortunately, when using wgl, my opengl control is more "laggy", not sure how to explain this (the texture data is updated every frames).
I did read somewhere:
OpenGL ES 3 does not have mandatory support for GL_BGRA,
but the extension `GL_EXT_texture_format_BGRA8888` supports it and it is present in ANGLE.
Fallback for OpenGL ES implementations without `GL_EXT_texture_format_BGRA8888` is to use RGBA8 with texture swizzle mask to swap the red and blue channels.

So I'm not sure if it's really an avalonia problem, I'll try to investigate more tomorrow.
Environment

OS: windows 11
Avalonia-Version: 11.05
GPU: Nvidia rtx 3060 mobile

OpenGL ES 3.x support is limited in Angle - https://github.com/google/angle?tab=readme-ov-file#level-of-opengl-es-support-via-backing-renderers
Not sure if your user case fails under these limitations.

Hi,
Thanks for your reply @maxkatz6. I'm still not sure what is the real root of the problem, but for sure it's not really related to Avalonia, so i close this issue..
Just for your information, i do "fix" this problem by using an rgba texture instead bgra then swap red and blue:
gl.TexParameter(TextureTarget.Texture2D, GLEnum.TextureSwizzleR, (int)GLEnum.Blue);
gl.TexParameter(TextureTarget.Texture2D, GLEnum.TextureSwizzleB, (int)GLEnum.Red);


Fix isPlainObj function for objects from different context

We can't create immutable object with Immutable.fromJS if source object has been created in different context (e.g. we want to create immutable object in chrome extension's popup, but source for immutable object is received from background page).
We have plain JS object in the background page:
var data = {
    item1: {
        name: 'Name 1'
    },

    item2: {
        name: 'Name 2'
    }
};

In the popup.js script we want to get this object and create immutable version of it:
chrome.runtime.getBackgroundPage(function(page) {
    var data = page.data;
    var immutableData = Immutable.fromJS(data);
});

but we can't because 'data' has been created in different context (in the background page).
immutableData === data; //true

If we serialize and deserialize data we can have immutable version:
var dataAfterSerialization = JSON.parse(JSON.stringify(data));
var newImmutableData = Immutable.fromJS(dataAfterSerialization);

newImmutableData.toString() === 'Map { "item1": Map { "name": "Name 1" }, "item2": Map { "name": "Name 2" } }'; //true

Full example is here - https://github.com/Elergy/Immutable-extension-test

The problem with this approach is that it becomes very expensive. isPlainObject is called many times through Immutable.js and changing it from an O(1) to an O(N) operation to support an obscure use case is probably the wrong tradeoff.
I would strongly suggest using a custom version from fromJS which supports exactly the characteristics you're looking for if the version that comes with Immutable doesn't work for you.
If your data that's been created in a different realm is safe to convert (e.g. has no complex or exotic objects - every object can be safely replaced with Map), then you can use a very simple implementation of fromJS:
function fromJSGreedy(json) {
  return Array.isArray(json) ?
    Immutable.List(Immutable.IndexedSeq(json).map(fromJSGreedy)) :
    Immutable.Map(Immutable.KeyedSeq(json).map(fromJSGreedy));
}

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

@leebyron what about using Object.prototype.toString instead of === Object?
function isPlainObj(value) {
  return value && (Object.prototype.toString.call(value) === '[object Object]' || value.constructor === undefined);
}

If this test is robust enough and don't hurt performance it could be a nice fit.
By the way, I encountered the same issue using a JS SDK that was returning a plain JS Object created from another frame.

I think this pull request has timed out, so I am going to close it. I think it would be an improvement to have something O(1) here that just works a bit better so if you are interested in making that work then please feel free to reopen!


logits = Lambda(lambda z: z/temperature)(x)

What's the use of this line of code?
dilatedunet.py
logits = Lambda(lambda z: z/temperature)(x)

When I had implemented just the u-net, the performance was lackluster. I thought perhaps forcing the model to be more "decisive" might help -- by decisive, I mean to force the model to mainly output 0 or 1 for each pixel-wise probability, rather than having many outputs near 0.5. This can be accomplished by rescaling the logits (by using an effective "temperature" must less than 1).
Ultimately, that wasn't the problem and using dilated convolutions helped.


Just figuring it out

Hey, I appreciate all the hard work you've done on this project.  I like the looks of it.
This may or may not be the proper place to ask for help, but I don't know where else to go.  I did some research online first.  :)
I have an angular app that I've been working on and now I'm trying to integrate it with drywall.  I'm kinda learning Jade at the same time.  :)  Anyway, I'll lay out my files for this new function and then I'll give you my results.
My Schema
'use strict';

exports = module.exports = function(app, mongoose){
  var requestSchema = new mongoose.Schema({
    title: {
      type: String,
      required: true
    },
    type: {
      type: String,
      required: true
    },
    user: {
      type: String,
      required: true
    }
  });
  app.db.model('Request', requestSchema);
};

index.js
'use strict';

exports.init = function(req, res){
  res.render('requests/index');
};

exports.find = function(req, res, next){
  req.query.title = req.query.title ? req.query.title : '';
  req.query.type = req.query.type ? req.query.type : '';
  req.query.user = req.query.user ? req.query.user : '';

  res.render('requests/index', { title: 'myTitle', type: 'someType', user: 'me'});
};

index.jade
extends ../../layouts/default

block head
  title Requests

block neck
  link(rel='stylesheet', href='/views/requests/index.min.css?#{cacheBreaker}')

block body
  div.row
    div.col-sm-6
      div#header
      div#filters
      div#results-table
      div#results-paging
      div.page-header
        h1 Requests
      table(class="table table-striped")
        thead
          th Title
          th Type
          th User
          th Delete
        tbody#results-rows
          tr(ng-repeat="request in requests")
            td
              a(ui-sref="editRequest({id:request._id})") Request
            td= type
            td <%= user %>
            td Delete

So my results:

I figured out that my ui-router stuff doesn't fit.  So ignore the "a(ui-sref" stuff for now. :)  For the 3 table datas after that, I got "someType" for the first one, which was a great test/proof of concept.  The second one didn't work as I'd hoped.  It displays "<%= user %>" directly on my page.  And the third td is obviously just a placeholder for now.
I got the "<%= user %>" part from admin/users and the like.  And in the js file, the init function can be ignored.  I had that as my first proof of concept.  Just taking it one step at a time.  :)  Inside find function of the js file though, the first three lines I kind of just have there.  Sort of a copy/paste from one of your js files like admin/users etc.  I'm not sure how to finish out my render, however.
I do have the data in my drywall database in a collection called "requests".  It is built like the schema listed here.  It is the same schema used in my working application, actually.  :)
Anyway, I'd certainly appreciate any help given.  I'd love to learn to use this effectively!  :D

Thanks for opening an issue. Warning: I don't have any experience with Angular myself.

Hey, I appreciate all the hard work you've done on this project. I like the looks of it.

Thanks for the kind words.

I have an angular app that I've been working on and now I'm trying to integrate it with drywall.

Typically you'd start with Drywall and start customizing. Integrating it with another app may could turn into a lot of work.

Since you're not using backbone, may I suggest checking out Frame. Frame is the API from Drywall, build with Hapi instead of Express, it doesn't have a front-end (you can build everything in Angular if you like) and it has decent test coverage.
@Silom made a front-end for it with Angular a while back called ngFrame.

Thank you for your quick response!  Much appreciated!
I haven't ever used backbone or frame.  I'll start taking a look at them now!

Typically you'd start with Drywall and start customizing. Integrating it with another app may could turn into a lot of work.

Well really it's just a single form page and a results page.  So let's consider it building anew on Drywall rather than integrating something existing.  :)  I feel like what I've done so far is very close to actually displaying my the data from my Mongodb.  While I'm looking over the documentation you've pointed me to so far, would you mind looking at the simple files I've pasted here and tell me if I'm close or just totally hosed it?  lol
Thanks again!

Whoops, horrible misclick.  Sorry, long day at work.  :)

There are quite a few technologies in Drywall to get familiar with:
https://github.com/jedireza/drywall#technology
Once you're comfortable with them though, it's easier to understand how they connect and where to make changes.
We don't have tutorials/guides on these different technologies, they're well documented online. But we do have a a set of wiki pages for Drywall specific stuff:
https://github.com/jedireza/drywall/wiki
To build up an understanding, I'd suggest:

first get to know our Gruntfile and how the client side files are produced (Grunt)
then understand the client and server sides of the contact page (Jade and Backbone)
then move on to the login
then start taking on the admin screens like statuses

Your mileage may vary.

These days, personally, I'd reach for Frame instead of Drywall and build the front-end in something besides Backbone. I'm closing this issue for now. I hope some of this helps inspire the right path forward.
Don't hesitate to ask more questions. :+1:


executive summary catches spacing of text is off

The line spacing of the text in executive summary catches is smaller than the "stock" section that comes before it.

I noticed that. Will look into it. Will sort out some formatting issues later once we've finalised the text.

It happened when I merged those catch tables, and the Table e was changed automatically. I thought I was seeing things and then I forgot about it but yes there is an issue. It must be due to the \Sexpr{} values changing somehow in that section, because I changed those too.
See #708 and commit fa320f23e20a4a7da25ff62e7430634903ce44e2


Add Rust Course to Smart Contract and test minting NFT

for the record. If viable in the available timeframe we should mint this NFT at Moonbeam since is the most used and known EVM at Polkadot Ecosystem

Added to issue #186


1.4.1 backports

PR: 7144 -- Wait for for k8s objects until are synced and processed before initializing cilium daemon (@aanm) -- https://github.com/cilium/cilium/pull/7144
PR: 7143 -- allocator: Wait until kvstore is connected before allocating global identities (@tgraf) -- https://github.com/cilium/cilium/pull/7143
PR: 7139 -- policy: Fix ipcache synchronization on startup (@tgraf) -- https://github.com/cilium/cilium/pull/7139

$ for pr in 7144 7143 7139; do contrib/backporting/set-labels.py $pr done 1.4; done

This change is

test-me-please

test-docs-please

test-missed-k8s


bug when wifi adapter is phy0

I noticed your script uses the command seq 10 to iterate phy1 to phy10. The problem is if it's phy0, it will not work.
I fixed this by changing the line to:
for IDX in $(seq 0 10); do

Cool! Want to make a PR?


Support conf file

Currently, only command args are supported, and the command gets super long.
Please support conf file parsing from default ~/.faraday/faraday.conf file.

Please, also add to the README the location of this config file, with an example configuration.

Hello @junderw what do you think the faraday.conf should contain?


Introducing hipification of CuPy for ROCm compatibility with CUDA

Overview
This pull request introduces the hipify utility to facilitate the conversion of CUDA C/C++/Cython code into HIP C/C++/Cython code within CuPy. Hipify offers a straightforward search-and-replace mechanism that maps CUDA constructs to their HIP equivalents, allowing CuPy to support AMD's ROCm ecosystem seamlessly. This addition particularly targets the conversion of CUDA files to HIP equivalents for CUDA/Stub builds, as detailed in the modified setup.py.
Main Changes
Integration of hipify:
The primary modification is in setup.py (see relevant section):

Determines whether to trigger the hipification process based on the presence of ROCm.

Utilizes hipify to generate HIP-compatible files by recursively converting the CUDA codebase.

Implements a custom mapping configuration, ensuring a precise mapping from CUDA constructs to HIP constructs.

Custom mapping and hipify mechanism:

Introduces a specific mapping, converting CUPY_USE_GEN_HIP_CODE to CUPY_DONT_USE_GEN_HIP_CODE.

Facilitates a mechanism for selecting the appropriate libraries only if on ROCm platforms; defaults to legacy CUDA code otherwise.

cuRAND Example:
An example integration is provided for cuRAND, demonstrating the specific mapping and library-switching mechanism between HIP and legacy CUDA versions.(see mechanism here)
Impact
This update ensures that CuPy can smoothly support both CUDA and ROCm, widening its compatibility range. It reduces manual intervention in maintaining both ecosystems and streamlines the conversion process, particularly in CUDA-to-HIP mappings. Importantly, existing CUDA code remains unchanged, ensuring compatibility for NVIDIA GPUs.

docker: failed to register layer: write /opt/rocm-6.1.0/lib/llvm/bin/flang-legacy: no space left on device.
https://github.com/cupy/cupy/actions/runs/8914357746/job/24481782055

It seems that this is because the rocm docker image is getting larger than before (rocm-5.0). I checked container sizes that pulled rocm images (see SIZE column):
$ docker system df -v
REPOSITORY                                                                         TAG                        IMAGE ID       CREATED         SIZE      SHARED SIZE   UNIQUE SIZE   CONTAINERS
rocm/dev-ubuntu-22.04                                                              6.1-complete               0708dce5557e   2 weeks ago     26.2GB    0B            26.23GB       1
rocm/dev-ubuntu-20.04                                                              5.0-complete               5d4953aabf2a   2 years ago     11.2GB    0B            11.24GB       1

Also, according to this document, we have only 14GB disk space on GitHub-hosted runners.
https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

I'm not sure how we should run build-rocm job on GitHub-hosted runners, however, I'm going to temporarily replicate and update #7964 to test the changes on this PR work on the self-hosted runners.

Also I will update #7964 itself to make it ready to merge, which may require our members to confirm our policy to have self-hosted runners on a public repository.

Thank you for the contribution and all the help improving support for ROCm in CuPy! Regarding this pull request, I'm a bit concerned about the potential instability this may introduce and the negative impact it could have on both user and developer experience:

This change would require users to install hipify-torch in order to build CuPy for ROCm, which adds an extra step and potential barrier to the installation process.
All contributors modifying CUDA code in the CuPy repository would need to be familiar with hipify-torch. Given that hipify-torch uses search-and-replace approach, I'm assuming it's highly likely to encounter failures in edge cases.
Hipified files are left in the source tree. They are recognized as untracked files by Git and could be noisy or accidentally committed. (as shown below)
Since hipify-torch is not versioned, the build results of CuPy could vary uncontrollably based on the latest commit in the hipify-torch repository (https://github.com/ROCm/hipify_torch).

CuPy has a ROCm support that is already mature, and in my current understanding, the introduction of hipify-torch does not appear to provide significant value compared to the drawbacks mentioned above.
% pip install -e . -v
Using pip 24.0 from /home/maehashi/.pyenv/versions/3.10.13/envs/local-3.10.13/lib/python3.10/site-packages/pip (python 3.10)
Obtaining file:///home/maehashi/Development/cupy
  Running command python setup.py egg_info
  Generating cache key from header files...
  Cache key (1700 files matching /home/maehashi/Development/cupy/cupy/_core/include/**): 65dbfe98a23933f1a73cec9264029f473436ff11
  INFO: hipification of cupy_backends in progress ...
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cuda.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_nccl.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_nccl_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/stream.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/stream.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cusparse.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cusparse_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cublas.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cublas_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cuda_profiler_api.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_hip_profiler_api.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/stream.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/stream_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cutensor.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cutensor_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/stream.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/stream.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/__init__.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/__init__.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cusolver.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cusolver_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cudnn.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cudnn.h [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cuda_runtime.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_hip_runtime.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_extern.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_extern_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_typedef.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_typedef_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_softlink.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_softlink.pxi [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/__init__.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/__init__.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_typedef.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_typedef_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_extern.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_extern_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/profiler.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/profiler_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvtx.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvtx_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/__init__.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/__init__.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cudnn.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cudnn_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparselt.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparselt.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/_cnvrtc.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/_cnvrtc_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparselt.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparselt_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvtx.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvtx_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cudnn.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cudnn_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand_hip.pxd [ok]
  Successfully preprocessed all matching files.
...

docker: failed to register layer: write /opt/rocm-6.1.0/lib/llvm/bin/flang-legacy: no space left on device.
https://github.com/cupy/cupy/actions/runs/8914357746/job/24481782055

It seems that this is because the rocm docker image is getting larger than before (rocm-5.0). I checked container sizes that pulled rocm images (see SIZE column):
$ docker system df -v
REPOSITORY                                                                         TAG                        IMAGE ID       CREATED         SIZE      SHARED SIZE   UNIQUE SIZE   CONTAINERS
rocm/dev-ubuntu-22.04                                                              6.1-complete               0708dce5557e   2 weeks ago     26.2GB    0B            26.23GB       1
rocm/dev-ubuntu-20.04                                                              5.0-complete               5d4953aabf2a   2 years ago     11.2GB    0B            11.24GB       1

Also, according to this document, we have only 14GB disk space on GitHub-hosted runners. https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

Thanks for pointing this out. As ROCm versions have evolved, the base ROCm images have grown in size. I have added a cleanup of unnecessary items that take up some runner disk space to account for this. See modification here

Thank you for the contribution and all the help improving support for ROCm in CuPy! Regarding this pull request, I'm a bit concerned about the potential instability this may introduce and the negative impact it could have on both user and developer experience:

This change would require users to install hipify-torch in order to build CuPy for ROCm, which adds an extra step and potential barrier to the installation process.
All contributors modifying CUDA code in the CuPy repository would need to be familiar with hipify-torch. Given that hipify-torch uses search-and-replace approach, I'm assuming it's highly likely to encounter failures in edge cases.
Hipified files are left in the source tree. They are recognized as untracked files by Git and could be noisy or accidentally committed. (as shown below)
Since hipify-torch is not versioned, the build results of CuPy could vary uncontrollably based on the latest commit in the hipify-torch repository (https://github.com/ROCm/hipify_torch).

CuPy has a ROCm support that is already mature, and in my current understanding, the introduction of hipify-torch does not appear to provide significant value compared to the drawbacks mentioned above.
% pip install -e . -v
Using pip 24.0 from /home/maehashi/.pyenv/versions/3.10.13/envs/local-3.10.13/lib/python3.10/site-packages/pip (python 3.10)
Obtaining file:///home/maehashi/Development/cupy
  Running command python setup.py egg_info
  Generating cache key from header files...
  Cache key (1700 files matching /home/maehashi/Development/cupy/cupy/_core/include/**): 65dbfe98a23933f1a73cec9264029f473436ff11
  INFO: hipification of cupy_backends in progress ...
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cuda.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_nccl.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_nccl_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/stream.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/stream.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cusparse.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cusparse_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cublas.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cublas_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cuda_profiler_api.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_hip_profiler_api.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/stream.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/stream_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cutensor.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cutensor_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/stream.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/stream.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/__init__.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/__init__.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cusolver.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cusolver_hip.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/_softlink.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cudnn.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cudnn.h [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_cuda_runtime.h -> /home/maehashi/Development/cupy/cupy_backends/cuda/cupy_hip_runtime.h [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_extern.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_extern_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_typedef.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_typedef_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_enum.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_softlink.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_softlink.pxi [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_enum.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/runtime_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/__init__.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/__init__.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_typedef.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_driver_typedef_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_extern.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/_runtime_extern_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/api/driver_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.pyx [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/profiler.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/profiler_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusolver_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cutensor_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvtx.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvtx_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nccl_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/__init__.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/__init__.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvrtc_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cublas_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cudnn.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cudnn_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparselt.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparselt.pxd [skipped, no changes]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse.cpp -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparse_hip.cpp [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/_cnvrtc.pxi -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/_cnvrtc_hip.pxi [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparselt.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cusparselt_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvtx.pyx -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/nvtx_hip.pyx [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cudnn.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/cudnn_hip.pxd [ok]
  /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand.pxd -> /home/maehashi/Development/cupy/cupy_backends/cuda/libs/curand_hip.pxd [ok]
  Successfully preprocessed all matching files.
...

Thank you for your insights @kmaehashi,
While hipify-torch adds an extra installation step, it aligns us with industry practices and uses PyTorch's proven method for ROCm users. Our current ROCm support is mature, however it does not fully utilize newer ROCm capabilities. Adopting hipify-torch keeps CUDA and ROCm aligned, ensuring functional parity, and minimizes changes on the CUDA side. We hope it will make the development process streamlined, preventing it from falling behind CUDA.
Thanks for addressing the user/dev experience feedback, after some thought on this I was thinking we could make the user/dev experience better by adding in the following:

We want to have more open-source community engagement and welcome any suggestions to streamline the development process. For edge cases or any questions that arise, please involve the CuPy ROCm developers to help address any issues. Mentioned here @pnunna93, @lcskrishna, @bmedishe and @shbiswas834.  I can also collaborate with the hipify-torch team to provide a more comprehensive README.

To address the issue of hipified files in the source tree, we can update our .gitignore configurations. This should help keep the repository organized, reducing noise, and preventing accidental commits of these files. I have proposed a solution here.

I discussed the stability concern with hipify-torch with the PyTorch team, and they mentioned they currently ensure stability by pinning to specific commits. We can adopt this approach to prevent build variations and maintain consistency an example can be found here. Additionally, I can collaborate with the hipify-torch team to provide a more comprehensive versioning support in the future that we can track.

I appreciate the feedback and am open to other suggestions on how to make the user/dev experience more positive with this change.

Also I will update #7964 itself to make it ready to merge, which may require our members to confirm our policy to have self-hosted runners on a public repository.

Thanks, @takagi. Please let me know if there's anything I can do to help. I understand that some teams using self-hosted runners on public repositories have a setup where a maintainer needs to approve a pull request before CI workflows can run. This is done using the "Approve and Run" button for added security see approving-workflow-runs-from-public-forks for more information.

Thanks, @AdrianAbeyta. Our team had a talk about "Approve and Run" button and we would not like to use it because, even on workflows using a GitHub-hosted Runner, e.g. for linting and document building, it requires manual approval on every commit. We tried it before and feel it is too cumbersome.
Instead, we think of another solution. We plan to have two repositories, A (public, used for development) and A-fork (private, used for testing, with self-hosted runner registered). A test comment to a pull request on A will trigger pushing the commit from A to A-fork, then starting the CI workflow on A-fork.

@kmaehashi  Would you make some response on https://github.com/cupy/cupy/pull/8316#issuecomment-2113474595?

While hipify-torch adds an extra installation step, it aligns us with industry practices and uses PyTorch's proven method for ROCm users. Our current ROCm support is mature, however it does not fully utilize newer ROCm capabilities. Adopting hipify-torch keeps CUDA and ROCm aligned, ensuring functional parity, and minimizes changes on the CUDA side. We hope it will make the development process streamlined, preventing it from falling behind CUDA.

Thanks for the clarification! I think it would be very ideal to be able to integrate the codebase between CUDA and ROCm codebases. However, I'm thinking that there may be cases where mere string-based search-and-replace will not work, where cupy_backends/hip has served as a layer to absorb such differences. For example,

https://github.com/cupy/cupy/blob/v13.1.0/cupy_backends/hip/cupy_hipblas.h#L74-L80
https://github.com/cupy/cupy/blob/v13.1.0/cupy_backends/hip/cupy_hipsparse.h#L11-L21
https://github.com/cupy/cupy/blob/v13.1.0/cupy_backends/hip/cupy_rocsolver.h#L28-L36
https://github.com/cupy/cupy/pull/8335/files

It could also be the case that new APIs introduced in newer CUDA have not yet been available in HIP. Unless you only support the latest ROCm (this means dropping support for older ROCm even for stable CuPy releases), this could be a problem.

We want to have more open-source community engagement and welcome any suggestions to streamline the development process. For edge cases or any questions that arise, please involve the CuPy ROCm developers to help address any issues. Mentioned here @pnunna93, @lcskrishna, @bmedishe and @shbiswas834.  I can also collaborate with the hipify-torch team to provide a more comprehensive README.

As the usage of CuPy by our community grows, I believe it is important to continuously  maintain CuPy's ROCm support up-to-date. Thank you everyone as always for your ongoing support!


Add an option to move the HUD

Is your feature request related to a problem? Please describe.
Yes, the HUD that display whenever you are using AutoClicker from this mod or not
It kinda "in the way" with other HUDs
Describe the solution you'd like
Maybe an option to change the X/Y Offset
Describe alternatives you've considered
Similar but maybe draggable?
Additional context

Agreed, we need something like this.


(PUP-4466) Add acceptance tests for functions written in the Puppet language

Unit testing covers the 4x function API and specifically tests behavior around functions written in Puppet DSL. This commit adds new acceptance tests which validate basic user-level functionality where Puppet functions cross component boundaries.

CLA signed by all contributors.

Can you either squash commits or prefix the second commit with "(PUP-4466)". The release ticketmatch.rb script will require manual intervention for commits that don't meet the commit format guidelines.
Thanks!

squash commits

Oops, sorry. Squashing...


allow hide open editors

feat: https://github.com/lapce/lapce/issues/2268
Show

Hide

[ ] Added an entry to CHANGELOG.md if this change could be valuable to users

Codecov Report

Merging #2273 (5ce19ee) into master (53cd9a8) will increase coverage by 0.06%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff            @@
##           master   #2273      +/-   ##
=========================================
+ Coverage    8.89%   8.96%   +0.06%
=========================================
  Files         136     136
  Lines       59513   59080     -433
=========================================
  Hits         5295    5295
+ Misses      54218   53785     -433

Impacted Files
Coverage Δ

lapce-data/src/config.rs
0.00% <ø> (ø)

lapce-ui/src/explorer.rs
0.00% <0.00%> (ø)

... and 14 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

This requires a restart to take effect right?

restart or reopen workspace

Thank you so much @tk103331
Just a few nitpicks that come to mind.

It would probably be better to consistently keep a positive configuration action, rather than a negative one. Meaning, have a config that says "Show open editors" that defaults to true, instead of "Hide open editors" that defaults to false. This would be a good thing to actually have all across the configurations.
Is there a way to avoid having to restart the editor or the workspace?

Cheers !

It's probably better to mention that a restart is required somewhere then.
Either on a small toast (that can even be reused by other configs that require restarting), or directly as a (Requires restarting Lapce) mention next to each config.
Cheers

Close due to new UI


Checking for Dev build Updates not working.

I've noticed in the last couple of days that OCAT doesn't really download new builds any more when clicking on "Get OpenCore".
It says: "No Update available".
But when I download the latest dev build manually and import it, it's clear the latest version wasn't intsalled.
Could you look that?
Thanks.

For the update source, if you choose
https://github.com/dortania/build-repo
you can view its distribution file here
https://github.com/dortania/build-repo/releases
OCAT cannot get the development version of OpenCore when the first file is not OpenCore.
In this case, you can choose another update source, which is always only for OpenCore, so there is no problem
https://github.com/bugprogrammer/HackinPlugins
Any questions or ideas, please feel free to leave a comment, thanks.

Because the current online update source except the official one (which needs to be downloaded manually and then imported into OCAT). Other online update sources are not perfect, for example, they don't support Linux system. So OCAT will have to do for now, if there are any changes, I will always pay attention and upgrade OCAT at the first time.

This issue has been optimized in the latest version, please upgrade to the latest version.


JKJ

Describe the bug
https://bolt.new/
Link to the Bolt URL that caused the error
https://bolt.new/
Validations

[X] Please make your project public or accessible by URL. This will allow anyone trying to help you to easily reproduce the issue and provide assistance.

Steps to reproduce
https://bolt.new/
Expected behavior
https://bolt.new/
Screen Recording / Screenshot

Platform
Browser name = Chrome
Full version = <IP_ADDRESS>
Major version = 131
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
performance.memory = {
  "totalJSHeapSize": 39372991,
  "usedJSHeapSize": 36892711,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}

Additional context
Error:
NotFoundError: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.
    at Zj (https://bolt.new/assets/components-BPQqK2_k.js:24:26518)
    at ck (https://bolt.new/assets/components-BPQqK2_k.js:24:27829)
    at dk (https://bolt.new/assets/components-BPQqK2_k.js:24:28297)
    at ck (https://bolt.new/assets/components-BPQqK2_k.js:24:27978)
    at dk (https://bolt.new/assets/components-BPQqK2_k.js:24:28297)
    at ck (https://bolt.new/assets/components-BPQqK2_k.js:24:27978)
    at dk (https://bolt.new/assets/components-BPQqK2_k.js:24:28102)
    at ck (https://bolt.new/assets/components-BPQqK2_k.js:24:27978)
    at dk (https://bolt.new/assets/components-BPQqK2_k.js:24:28297)
    at ck (https://bolt.new/assets/components-BPQqK2_k.js:24:27978)
Component stack:
    at div
    at div
    at MenuContent$1 (https://bolt.new/assets/_index-NyEmdF5V.js:88:124727)
    at div
    at div
    at W (https://bolt.new/assets/components-BPQqK2_k.js:24:43638)
    at https://bolt.new/assets/_index-NyEmdF5V.js:88:121307
    at ClientOnly (https://bolt.new/assets/ErrorBoundary-U3t4dt5d.js:1:1119)
    at div
    at W (https://bolt.new/assets/components-BPQqK2_k.js:24:43638)
    at https://bolt.new/assets/_index-NyEmdF5V.js:145:9492
    at https://bolt.new/assets/_index-NyEmdF5V.js:145:26365
    at Chat (https://bolt.new/assets/_index-NyEmdF5V.js:145:25147)
    at ClientOnly (https://bolt.new/assets/ErrorBoundary-U3t4dt5d.js:1:1119)
    at div
    at IndexLayout (https://bolt.new/assets/_index-NyEmdF5V.js:145:39818)
    at Index$1
    at RenderedRoute (https://bolt.new/assets/index-BkkrDsoJ.js:36:3987)
    at Outlet (https://bolt.new/assets/index-BkkrDsoJ.js:36:7773)
    at W (https://bolt.new/assets/components-BPQqK2_k.js:24:43638)
    at App
    at ClientOnly (https://bolt.new/assets/ErrorBoundary-U3t4dt5d.js:1:1119)
    at Layout (https://bolt.new/assets/root-Dgim_hb8.js:60:25)
    at RenderedRoute (https://bolt.new/assets/index-BkkrDsoJ.js:36:3987)
    at W (https://bolt.new/assets/components-BPQqK2_k.js:24:43638)
    at DataRoutes (https://bolt.new/assets/components-BPQqK2_k.js:33:6470)
    at Router (https://bolt.new/assets/index-BkkrDsoJ.js:36:7825)
    at RouterProvider (https://bolt.new/assets/components-BPQqK2_k.js:33:3672)
    at W (https://bolt.new/assets/components-BPQqK2_k.js:24:43638)
    at W (https://bolt.new/assets/components-BPQqK2_k.js:24:43638)

अभी यह सब चीज ढंग से काम नहीं कर रही हैं

अभी यह सब चीज ढंग से काम नहीं कर रही हैं

Hey @Zafarkhan91, thanks for the report.
We'll get this fixed soon, but meanwhile you can proceed by disabling the browser extension that your are using to translate the page into different language. The browser extension is breaking Bolt here.


transition CI to github actions

Travis-CI seems to have stopped working. It is probably fixable, but given that Tock and libtock-rs already use github actions, this PR transitions our CI to github actions instead.
I think this covers everything but I have not tested the bors setup. Also, this now uses a third party Github Action to install the arm toolchain (https://github.com/fiam/arm-none-eabi-gcc). I could not get the existing install technique to work -- tar kept throwing errors (maybe we used too much disk space?) and this was easier. If someone else wants to dig into that more please feel free.
This no longer caches the toolchains in the way that our travis-CI setup did, but the build typically completes in 3-4 minutes anyway so I don't think it is worth the effort.

Can we split the checks up like in Tock? As in have formatting be a separate check, say.

Can we split the checks up like in Tock? As in have formatting be a separate check, say.

Done


FEATURE: Add send-on-request/text update

Rather than sending out a ton of images all at once, it would probably be best to simply update users with a small text message, along the lines of:

There are 34 unseen spoilers. Type 'send' to receive them!

This would allow users to control when and where they receive their spoilers. This is particularly relevant for people with data limits.

We could also link it to the like button?

Implemented as per PR #18


Site changed, cannot log in with cookies or password.

Prerequisites

[*] Did you read FAQ section?
[*] Did you test with the latest releases or commit ?

Description
Attempting to log in with either the username/password method and cookie method fails to work.
Steps to Reproduce

Attempt to log in with username/password
Get server reply: 'Please complete the reCAPTCHA verification.'
Attempt to log in with cookie
Get error "Cookie already expired/invalid"

Traceback (most recent call last):
File "PixivBrowserFactory.pyc", line 301, in login
TypeError: 'NoneType' object is not subscriptable
Error at login(): (<class 'TypeError'>, TypeError("'NoneType' object is not subs
criptable"), <traceback object at 0x076BE580>)
Error at doLogin(): (<class 'TypeError'>, TypeError("'NoneType' object is not su
bscriptable"), <traceback object at 0x082B3580>)
Cannot Login!
press enter to exit.
Expected behavior: [What you expected to happen] Log in with the previous password or cookie method.
Actual behavior: [What actually happened] Receive errors.
Versions
20191215 release
You can get this information from executing PixivUtil2.py --help.

Q3. I cannot login to Pixiv!
- Check your password.
- Try to login to the Pixiv Website.
- Try to use the config.ini on the [Authentication] section.
- Check your date and time setting (e.g.: https://www.timeanddate.com/)
- Disable Daylight Saving Time and try again.
- Copy your session values from browser:
1. Open Firefox.
2. Go to Pixiv website and login, remember to enable [Remember Me]
check box.
3. Right click the page and select View Page Info.
4. Click the Security tab.
5. Click the View Cookies button.
6. Look for Cookie named = PHPSESSID.
7. Copy the content value.
8. Open config.ini, go to [Authentication] section, paste the value
to cookie, set keepsignedin = 1.

That isn't helpful. I've gone through these steps multiple times.

Unfortunately,I met this problem few hours ago,too.The error message is quite similar.
Traceback (most recent call last):   File "PixivBrowserFactory.pyc", line 305, in login TypeError: 'NoneType' object is not subscriptable Error at login(): (<class 'TypeError'>, TypeError("'NoneType' object is not subscriptable"), <traceback object at 0x07A2D6C8>) Error at doLogin(): (<class 'TypeError'>, TypeError("'NoneType' object is not subscriptable"), <traceback object at 0x079A2FA8>) Cannot Login! press enter to exit.

I have the same problem. Patiently waiting for a fix. ;-)

I used a different account, and did not receive this error. Something must be different for some cases.

most likely they are doing some A/B testing with the login screen. I didn't get the error so far so I cannot really test it.
Also are you running from source or from the zipped archive? Please check the new release from yesterday.

That right click, page info doesn't even work in my version of FF, 71 64bit.  I can view certs, CLEAR cookies, view saved passwords, and click help.
Better I think to hit F12 for dev console, hit the storage tab and then choose cookies on the left. Look for the value on the right.  Make sure you are on the pixiv page when you do this.

I guess this is because pixiv remove the logout.php link from the site?
Currently it detect whether the user are logged in successfully using cookies based on the availability of the logout.php. I guess I need to change it to check the string for pixiv.user.loggedIn = false;
https://github.com/Nandaka/PixivUtil2/blob/master/PixivBrowserFactory.py#L269

I created a new account and copied the new cookie to config.ini,and didn't receive this error.
Then I logged in the old acccount and copied the cookie to config.ini,the problem happened again.
PixivDownloader said"Cookie already expired/invalid.",but when I tryed to log in pixiv by changing cookie on Chrome,the old account's cookie worked.

try https://github.com/Nandaka/PixivUtil2/releases/tag/v20191220-beta1

Hello. I also have had login errors for the last few days. I have just tried the latest v20191220-beta1 version. I've followed the instructions for changing cookies and I get an error with both an old cookie and a new one.
Trying to log in with saved cookie
Cookie already expired/invalid.
Logging in...
Traceback (most recent call last):
File "/home/pi/PixivUtil2/PixivBrowserFactory.py", line 308, in login
data['post_key'] = post_key['value']
TypeError: 'NoneType' object is not subscriptable
Error at login(): (<class 'TypeError'>, TypeError("'NoneType' object is not subscriptable"), <traceback object at 0x73d1a408>)
Error at doLogin(): (<class 'TypeError'>, TypeError("a bytes-like object is required, not 'BeautifulSoup'"), <traceback object at 0x73e40a68>)
Cannot Login!
press enter to exit.

Same here. Tried last version ( v20191220-beta1), it still happens :(

Can you replace the library.zip with the attached file and retry? It should generate login_error.html if the TypeError: 'NoneType' object is not subscriptable happen, so I can check it.
library.zip

Tried it and yep, it generates a login_error.html. Do you need the file or you already know if that's the problem just knowing it's generated?

Cookie already expired/invalid.
Logging in...
Traceback (most recent call last):
  File "PixivBrowserFactory.pyc", line 308, in login
TypeError: 'NoneType' object is not subscriptable
Error at login(): (<class 'TypeError'>, TypeError("'NoneType' object is not subscriptable"), <traceback object at 0x0BEF2DC8>)
Error at doLogin(): (<class 'TypeError'>, TypeError("'NoneType' object is not subscriptable"), <traceback object at 0x0BF8C308>)
Cannot Login!
press enter to exit.```

Try this one?
library.zip

It works! It still can't login on its own, but if you paste a cookie it works fine.

Works for me as well off of cookie, didn't test other.

how to fix it?

no issue using cookie for me, check the main thread https://github.com/Nandaka/PixivUtil2/issues/814


Plugin Description
Supports loading .per files into Binary Ninja
Plugin Repository URL
Repo URL: https://github.com/redballoonsecurity/permap
Real Release

[X] I have made a real release

Thanks! I just submitted a PR as it looks like you've got a leftover in the readme you should fix and do a re-release. Consider using  https://github.com/Vector35/release_helper to make that process easier.

Good catch, I've updated the readme and made a new release

Added previously but forgot to close! Thanks for the submission.