Error: bash: /_temp/AZ_CLI_GITHUB_ACTION_1642662288004.sh: No such file or directory

We are trying to run AzureCLI action in our GitHub self-hosted agent which is created in the  AKS cluster. We are getting the following issue,

Agent Image: ubuntu:20.04
AzureCLI version: 2.32.0
Not sure if anything was missed in configuration?

Hi @GopikaV24 this might happen if the file doesnt have executable permissions. You can confirm that using the following command.
ls -l ./scripts/moveFiles.sh

Two methods to fix this:

Change file permissions before cli step

    run: |
        chmod +x ./path_to_file/file_name.sh

directly add ‘sh’ before the command:

    run: |
        sh ./path_to_file/file_name.sh

Hi @t-dedah ,
I have tried to give permission before CLI action and inside CLI action also, getting the same issue.

We are getting this issue for inlinescript also.
     - name: Azure CLI script1
        uses: azure/CLI@v1
        with:
          inlineScript: |
            az -v

@GopikaV24 Will it be possible to share the template so that we can replicate the issue?

@t-dedah, By referring below mentioned repo we are creating a selfhosted image and POD in AKS Cluster.
GitHub Runner in Docker Reference: https://github.com/SanderKnape/github-runner

Any updates?

I'm having the same issue when running shell scripts.
And I am calling chmod before executing the script.

Hi @GopikaV24 Can we also confirm if the file actually exists at the required location?

Hi, @GopikaV24! I want to know if you are still facing the issue. If yes, could you check whether the AZ_CLI_GITHUB_ACTION_CurrentTime.sh file is actually in the _temp directory by running ls -la /_temp in the inlineScript of Azure/cli? This file might fail to create for some reason.

For a long time with no activity, closing the issue now.  If there is any further question to discuss, please open a new issue.

@MoChilia @t-dedah the permission issue on the script that is generated by azure/cli and source from inlinescript
I'm facing the same issue:
    - name: Azure CLI script to copy artifact
      uses: azure/cli@v2
      with:
        azcliversion: latest
        inlineScript: |
          az storage blob upload --account-name REDACTED  --container-name REDACTED  --name target_file_name --file ${{inputs.file_path}}/${{inputs.file}} --auth-mode login

which results in:
(...)
Digest: sha256:38f8385bb27f9b6dabee3045852cabce2e9da7d4ed35d5783b4691a02489b4c2
Status: Downloaded newer image for mcr.microsoft.com/azure-cli:latest
bash: /data/runner/work/_temp/AZ_CLI_GITHUB_ACTION_1724706079140.sh: No such file or directory

cleaning up container...
MICROSOFT_AZURE_CLI_1724706078695_CONTAINER

There might be a condition were the action fails to create the script in /data/runner/work/_temp/ but I would expect createScriptFile to fail if that was the case... I'm confused.

@MoChilia Can we re-open that issue please ?

Hi @FlorentATo, could you please open a new issue and share your runner settings with me? Let me know if it's GitHub-hosted or self-hosted.

https://github.com/Azure/cli/issues/161


REMINDER: The branch used on Minor Name Change testing server is not the main branch, but is instead the work_in_progress_parent_guardian_assent_changes branch

In the future, when addressing how the assent questions are asked for parents and guardians, you may need to switch back to the main branch. The main branch is at the stage where assent is only asked of those who have said that they are presenting the form on behalf of the child. Each of the changes made to the work in progress branch are detailed in the prior GitHub Issue.

This issue appears stale--all of the work is merged


refact routes, more friendly to forecast and truth values

Pull Request
Description
Refactor routes to take into account forecasts/truths
How Has This Been Tested?
unittests

[ ] Yes

If your changes affect data processing, have you plotted any changes? i.e. have you done a quick sanity check?

[ ] Yes

Checklist:

[ ] My code follows OCF's coding style guidelines
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked my code and corrected any misspellings

Codecov Report

Merging #80 (73caee4) into main (114a224) will increase coverage by 0.00%.
The diff coverage is 100.00%.

:exclamation: Current head 73caee4 differs from pull request most recent head 395c511. Consider uploading reports for the commit 395c511 to get more accurate results

@@           Coverage Diff           @@
##             main      #80   +/-   ##
=======================================
  Coverage   99.58%   99.58%
=======================================
  Files          10       11    +1
  Lines         239      243    +4
=======================================
+ Hits          238      242    +4
  Misses          1        1

Impacted Files
Coverage Δ

src/tests/test_main.py
100.00% <ø> (ø)

src/gsp.py
100.00% <100.00%> (ø)

src/main.py
96.00% <100.00%> (-1.23%)
:arrow_down:

src/tests/test_gsp.py
100.00% <100.00%> (ø)

src/tests/test_pv.py
100.00% <100.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Remove unit table breakdown by AMI percentage

Issue

Addresses #347
[ ] This change is a dependency for another issue
[ ] This change has a dependency from another issue

Description
This change collapses the per-AMI unit tables into a single unit table, in the individual listing view.
Before:

After:

This change also fixes a bug: previously, the unit table didn't show up at all for the Detroit data. With this change, we always show a single unit table in the individual-listing view.
Forward-looking note: in the future, we may decide that we want to display either AMI percentages or income eligibility requirements (derived from AMI percentages) or something else. At that point, we could either revert this change (so that we go back to "individual tables per AMI percentage") or we could just add a new column to the table.
Type of change

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Prototype/POC (not to merge)
[ ] This change is a refactor/address technical debt
[ ] This change requires a documentation update
[ ] This change requires a SQL Script

How Can This Be Tested/Reviewed?
Start the app and look at the individual listing view for listings with units at different AMI percentages (e.g. "TEST: DEFAULT, MULTIPLE AMI AND PERCENTAGES") and for listings with units all at the same AMI percentage (e.g. "TEST: DEFAULT, RESERVED").

[X] Desktop View
[X] Mobile View

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have reviewed the changes in a desktop view
[X] I have reviewed the changes in a mobile view
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have assigned reviewers
[ ] I have updated the changelog to include a description of my changes

@tomgebauer I believe this change brings us in line with the mocks, but let me know if this is the wrong direction!

@anders-schneider this is looking good. I'm wondering if we need the total count column since users are primarily interested in availability. Do we show/hide columns in the table based upon whether we have/don't have data ?

@anders-schneider this is looking good. I'm wondering if we need the total count column since users are primarily interested in availability. Do we show/hide columns in the table based upon whether we have/don't have data ?

We added the total count column since (initially at least) we won't have any availability information for any listings - they'll all have to say "unknown" or "waitlist" or something like that.
And on whether we show/hide columns if we do/don't have data: we don't currently do that, but we could file a ticket for that if we want it!


MELEE BUFF

Take a closer look if you wish, but most melee weapons are buffed.
As a general rule:
If it can be two handed, and it's hard to get, it does 50-60 damage. This means it 2 taps any unarmoured target (excluding oni or other races with DR buffs) and 3 taps any armoured target.
If it's one handed, and it's hard to get, it does 30-40 damage - this means it 3-4 taps any unarmoured target and 4-5 taps any armoured target, depending on the armour and race.
If it's makeshift, it probably 3-4 taps any unarmoured target, and 4-5 taps any armoured target, but swings slower (generally, pickaxes and shit).
Knives also do between 20-30 damage so they're good if you get the drop on the enemy, but have smaller hitboxes despite swinging fast.

I'm highly in favour of this change. I'd actually say that this is a rather miniscule buff as most combatants tend to wear highly protective hardsuits in general. I think we could see some of the rarer melee 'weapons' such as armblades get faster attack rates as well. I think it'd be a welcome change, since melee is rather underpowered in a world where people can just shoot you.

I'll just redo this the proper way


LambDynamicLights is broken on the latest version of Sodium (0.5x)

https://github.com/LambdAurora/LambDynamicLights/issues/175#issue-1839253538

What is the issue? This is an issue with lambdynamiclights and/or sodium.

Your right. Working on a fix now.


Container elements not properly rendered inside of SVG elements

I'm not sure if this is an issue with ExpressJS or Jade, but the typical HTML container elements (div and span come to mind) that supposedly work in SVG elements too are rendered outside of the SVG element.
An example like the following would cause the div to get rendered outside the SVG element. Note : I have tried adding all the gobbledy gook that you would normally add if it was an SVG file. It didn't change a thing. I tried doing height/width with and without quotes, with and without pixels. I tried putting everything inside of style="". It still renders the div outside of the SVG element.
  svg#testing
    defs
      pattern#flowers(patternUnits="userSpaceOnUse" width=276 height=183)
        image(xlink:href='/img/flowers.jpg', height=183 width=276)
    div
      circle#circle(cx=50 cy=50 r=10 fill='url(#flowers)')

Well... all my formatting was removed. I can assure you all the indentation is correct. The circle SVG element renders correctly when the div is removed.

I added your formatting :) It's definitely a Jade issue or some sorts, rather than anything Express.


Feature/75 front end package json

Summary
Create an independent package.json for the front-end code
Description for the changelog
Closes #75 - Moved front-end code to a different folder structure and it now has its own package.json.  Updated build process and removed minified files from source control.
Other info

Dockerfile builds front-end and works with the new directory structure
Readme reflects changes made and removed some duplicated information (installation/build had the same info)
Changed root package.json to just have convenience scripts for building and running
Relative paths updated as necessary
Front-end uses webpack now for bundling, and outputs into dist (ignored in gitignore).

The package.json was becoming unruly when trying to update the build process using the existing tools, too many tasks
There is no dev server configured at this time (could be done in the future, but maybe not needed where there's a full rewrite planned)
The bundles that are created are not fully optimized, they could be chunked better.

The root package.json now does the following:

The main scripts (install, test, start) were changed to be backwards compatible: install will install td.site and td.server npm dependencies via postinstall script. test will run tests for td.site and td.server. start will build td.site and then run td.server

Some of the required resources from node_modules on the front-end are copied to the dist directory by webpack; local references were updated to reflect that

I believe this requires a documentation update.  Do you want me to wait for #80 to be done before working on that?


Radio button does not align with text

What happened?
Trying to make a row of radio buttons but the text does not align with the button.

What type of frontend frameware are you seeing the problem on?
Angular
Which version of iX do you use?
v2.0.3
Code to produce this issue.
<input checked id="checkbox_1_1" name="group_1" type="radio" />
    <label for="checkbox_1_1"> Checked </label>

    <input id="checkbox_1_2" name="group_1" type="radio" />
    <label for="checkbox_1_2"> Normal </label>

    <input disabled id="checkbox_1_3" name="group_1" type="radio" />
    <label for="checkbox_1_3"> Disabled </label>

I cannot reporduce this behaviour. Are you sure there is no local styling in place that causes this effect?

I found the problem, the global font-size was messing the alignment of the radio


Fixing the chef-dk nightly builds resulting from tightly pinned dependencies conflicting with loosely pinned dependencies

https://github.com/chef/chef/pull/2990
\cc @chef/client-core

:+1:

If I update the version constraint then I shouldn't need this change, correct?  Or is the override here for the software definition of chef, and the gemspec is for the gem definition of chef?

I think you've got it right.  The build does tight pinning to the exact version that we deliver in an artifact.  The gemspec in the project specifies what versions of chef the chef-dk will work with, and you always want to be more liberal there to avoid version constraint hell.  Currently chef-dk works fine with chef 12.0.0 through 12.0.3 so you don't want to bump the lower limit there in case something else pins explicitly to 12.0.x for some reason.
Granted, in this specific case that's not likely to be too important, but if you always bump the constraint as a rule then you'll inevitably wind up creating a mess at some point, so the better rule is to be as permissive as possible in the gemspec.


Can't change add to a git repo inside a path ignored by parent .gitignore

I have a git repo at my home, with holds my settings and ignores everything else using .gitignore. All my sources are in ~/src, which are ignored in .gitignore. When I have other repos in ~/src, I can't add a file in any repos in ~/src folder. It keeps throwing error that the file is ignored by .gitignore. How do I get git-plus to recognize the repo the file belongs to?

Are you trying to stage files in repos that are inside ~/src? If so, make sure you open those repos as projects in atom.

Yes. My gut repo is in ~ and ~/src is ignored. I do have other repos under
src, but they are not recognized at all whether I open them as projects or
not. It is defaulting to ~ and does not show any pending changes.
On Fri, Aug 7, 2015, 7:07 AM Akonwi Ngoh<EMAIL_ADDRESS>wrote:

Are you trying to stage files in repos that are inside ~/src? If so, make
sure you open those repos as projects in atom.
—
Reply to this email directly or view it on GitHub
https://github.com/akonwi/git-plus/issues/225#issuecomment-128709707.

what do the .gitignore files look like?

# Ignore everything
**

# Do not ignore these.
!.gitignore
!.bashrc
!.bash_profile
!.inputrc
!.vimrc
!/.vim/
!/.ssh/
!/.fonts/

/.ssh/known_hosts

This is what I have.

Sorry I dropped off this issue. Can you verify this is still a problem for you? I just tried to replicate it and I'm not seeing it.
If I open atom with atom ~/ then only the unignored files are in the project. If i open atom with atom [something ignored], everything still works fine.


feature/loginViewModel_test

Summary
Explain the high-level impact of these commits in plain language.
Use bullet points for brevity.
Reasons
Provide the rationale for these changes.
Explain why these commits were necessary to address the issue.
Use bullet points for clarity.
References
Include links to relevant GitHub issues or helpful documentation to provide context.
If this PR resolves a GitHub issue, use "closes #123" format.

Welcome to Codecov :tada:
Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


⚠ Bofrost.fr has degraded performance

In 24da6f3, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1542 ms

Resolved: Bofrost.fr performance has improved in 6427bef.


Disturbed alignment of home page

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
@Its-Aman-Yadav Assign me this task under GSSOC'24.

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

I agree to follow this project's Code of Conduct. I'm a GSSOC'24 contributor. I want to work on this issue. I want fix this issue i can solve the all alignment issue in the website.


Fix lower triangular shear values

Description
This fixes the shear decomposition for lower triangular matrices. It closes #1826 and #1830 by enabling round trips with lower triangular shear matrices. It doesn't change our API, but makes it now conform to user expectations (I hope), by detecting whether lower triangular or upper triangular matrices are being used and doing the decomposition appropriately as needed. Tests have also been added, but it could probably do with some real world testing too!!
Thanks to input from @tlambert03 @jni @zeroth @VolkerH @GenevieveBuckley. This is now ready for review.
Type of change

[x] Bug-fix (non-breaking change which fixes an issue)

References
Closes #1826
Closes #1830
How has this been tested?

[x] Tests added

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works

Now that I'm thinking more about this, the renaming should be consistent with the other two functions as well.
How about this set of names, @sofroniewn

is_matrix_any_triangular
is_matrix_upper_triangular
is_matrix_lower_triangular

is_matrix_any_triangular
is_matrix_upper_triangular
is_matrix_lower_triangular

I like these suggestions, will rework to include, thanks @jni @GenevieveBuckley for the review!

This is ready for re-review. I dropped check_shear_triangular and added is_matrix_triangular which I think was a good idea, but unfortunately now need to duplicate the error message. Open to suggestions @GenevieveBuckley @jni. I'm also happy to merge as is

This is ready for re-review. I dropped check_shear_triangular and added is_matrix_triangular which I think was a good idea, but unfortunately now need to duplicate the error message. Open to suggestions @GenevieveBuckley @jni. I'm also happy to merge as is

No particular suggestion here, the slight duplication doesn't bother me too much.


Create xpublish routers for building APIs around xarray datasets

Currently, there are suites of services included in THREDDS that are relied upon by users to access data. This issue tracks some attempts to replicate the experiences users expect when requesting and viewing remote xarray datasets from outside of python notebooks.
To accomplish this, we will be building xpublish routers that can be modularly composed together to create the service suite a user would need or want to expose their data to other users. This effort started at the IOOS CodeSprint 2022 (Original prototypes from that event here: https://github.com/asascience/restful-grids) Below is a services wish list of sorts as we compile and build out prototypes:

[x] OpenDAP (via https://github.com/gulfofmaine/xpublish-opendap)
[x] EDR (via https://github.com/gulfofmaine/xpublish-edr)
[x] WMS (via https://github.com/asascience-open/xpublish-wms)
[ ] Catalog Services (a la browsing datasets on Thredds or other catalog html site)

Other service suggestions are welcome!

cc @abkfenris

I haven't gotten to play with your router yet, but I did just find rio-tiler which sits under titiler, which may allow you to factor out some of the tiling functionality that they have already implemented.

I haven't gotten to play with your router yet, but I did just find rio-tiler which sits under titiler, which may allow you to factor out some of the tiling functionality that they have already implemented.

Yeah i found that too.. They actually tile in the exact same way as I was, which is a little unfortunate because I was hoping that they would have a more efficient method.

I am also building a prototype frontend for these routers to be used via the browser here: https://github.com/asascience-open/xreds

Nice! This is the kind of thing I'm thinking about for Xpublish distros, which speaking of I've got a draft of a more public post in the hackmd doc to try to get others interested.
Some so we don't have to keep re-inventing the wheel
https://github.com/NCEI-NOAAGov/zarrdap/blob/24a7c5a7fd0fec055cacff21b6fa977cb5b1de02/app/api_dap2/backend.py#L81-L93
👀
https://github.com/asascience-open/xreds/blob/0aa2474e7def7f96791c1443a9547cc39b907823/xreds/server.py#L30-L48

I haven't run it yet to see what you've got, but an idea for the frontend to use hvplot explorer to be able to take a quick look at datasets, at least until building out more integrated exploration tools.

So far, it's basically a simplistic Godiva clone: it uses the wms endpoint to display layers on a map and you can click to query data at given points. You can choose your timestep, color ranges, and color palette. Right now memory struggles a bit because it's not setup with dask or anything.
 I started with wms frontend because it's the easiest of all of these to build in a silo while also showing that we can indeed use the data straight from NODD and kerchunk without thredds or any other aggregation services.
I am not very knowledgeable about hvplot or any frontend python tools, I pretty much always build the data devices in python but the frontend services in JavaScript.
Excited to keep this coversatikn moving along and happy to collaborate.

@mpiannucci, to meet your "Catalog Services" need, I wonder if you could lift some code from or integrate with ZarrDAP, which implements a custom HTML ZarrDAP Catalog and from it generates an Intake catalog.

Yeah that sounds like a good approach. We will be meeting with the zarrdap folks this week and talking about possible collaboration and integrations

Can we build routers for generating STAC or Intake catalogs on the fly?


Fade and scale transition in scaffold FAB causes all elements in tree to turn invisible

Unexpected behaviour occurs if you have multiple transitions inside a scaffold's floating action button. Having a ScaleTransition or a FadeTransition within the subtree works fine, but incorporating them bothe in the subtree causes all of the elements in the tree to turn invisible when the animation is at the 0% position.
Even more unexpectedly: if you add a some widget (eg Text) above the transitions, it all starts working fine again.

Repro
import 'package:flutter/material.dart';

void main() => runApp(new MyApp());

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return new MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData.dark(),
      home: new Scaffold(
        body: new Center(child: new Text('Press the button')),
        floatingActionButton: new App(),
      ),
    );
  }
}

class App extends StatefulWidget {
  @override
  State createState() => new AppState();
}

class AppState extends State<App> with SingleTickerProviderStateMixin {
  AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = new AnimationController(
      vsync: this,
      duration: const Duration(milliseconds: 200),
    )..forward();
  }

  void toggleExpansion() {
    if (_controller.isDismissed) {
      _controller.forward();
    } else {
      _controller.reverse();
    }
  }

    @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return new Column(
      crossAxisAlignment: CrossAxisAlignment.center,
      mainAxisSize: MainAxisSize.min,
      children: [¨
        // Uncomment to make it work again
        // new Text('Plain text'),
        new FadeTransition(
          opacity: new CurvedAnimation(
            parent: _controller,
            curve: Curves.easeOut,
          ),
          child: new Text('Fade'),
        ),
        new ScaleTransition(
          scale: new CurvedAnimation(
            parent: _controller,
            curve: Curves.easeOut,
          ),
          child: new Text('Scale'),
        ),
        new Container(height: 16.0),
        // The following widget become invisible for no apparent reason
        new FloatingActionButton(
          child: new Text('X'),
          onPressed: toggleExpansion,
        ),
      ],
    );
  }
}

Flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel master, v0.2.4-pre.91, on Microsoft Windows [Version 10.0.16299.309], locale fi-FI)
[!] Android toolchain - develop for Android devices (Android SDK 27.0.3)
! Some Android licenses not accepted.  To resolve this, run: flutter doctor --android-licenses
[√] Android Studio (version 3.0)
[√] VS Code, 32-bit edition (version 1.21.1)
[√] Connected devices (1 available)

Sorry for the late response. Is this still the case in recent Flutter versions?


Maybe a -minimal version (without all the thousands of preinstalled packages)

Maybe it would be cool to have a very small image with just the improvements from Atomic Studio without all the 100 bilion apps that we add by default, that will allow people with less storage to use this image (E.G.: I need to make a VM with literally 60 GBs or space to test this image.)

Tons of these billions of apps could already be made optional with the new Yafti soon IMO. Or even just through studio add. Pre-installed software is useful for offline environments and discovering new things, so I think a -minimal image is the bare minimum.

I guess the best way to go forward is to make the default images the minimal ones, and make a new tag named -fx (like swayfx), that would have a bunch of stuff included by default. It would be a pattern a lot like bluefin and bluefin-dx!

Done :+1:


Currency field doesn't fire dom-input-event on user's input

Reproduction
https://formkit.link/91ee471316785e54b4360bc7074c8cd2
Describe the bug
Simple text field (type="text") fires dom-input-event, but field with currency (type="currency") not.
Environment
• OS: macOS
• Browser: Chrome
• Version: 118.0.5993.88 (Official Build) (arm64)

@dreamerrrrrrrrr this has been resolved at FormKit Pro v0.126.8


Add sphinx gallery

Closes: https://github.com/pygfx/pygfx/issues/345 #145
This PR contributes a sphinx gallery that converts examples into a nice RST file including output renders. It also reorganizes the example folder into introductory, feature_demo, and validation examples to track them better and to display examples by category in the gallery.
Note that this is a large PR. Most of the changes are fairly light-weight, though, so a lot of the touching lines are things like adding a title in the docstring or renaming an example. The critical pieces are in conf.py (the sphinx config) and in utils/gallery_scraper.py.

One current issue is that some examples (e.g. the PBR render of the helmet) use models from examples/models. Currently these are loaded by getting a path to the model via __file__; however, __file__ is not defined when the example is run by sphinx, so those examples break. I'm not sure how we want to resolve this though. My intuitive approach would have been to think of a gfx.sample_models.[helmet/teapot] approach, but this means that we have to include this data in the package, which I am not a fan of. Then again, it might be useful because users that copy down the example from the docs will face the same pathing issues on their machines since a path based on __file__ (pointing to the target of the copy/paste) will break too.

Here is also a benchmark on how long the examples take to build on my machine. It doesn't look too bad:

computation time summary:
    - ..\examples\feature_demo\plot_collection_line.py:                    20.45 sec   0.0 MB
    - ..\examples\feature_demo\plot_pbr2.py:                               16.97 sec   0.0 MB
    - ..\examples\feature_demo\plot_multi_select.py:                        3.65 sec   0.0 MB
    - ..\examples\introductory\plot_hello_triangle.py:                      3.15 sec   0.0 MB
    - ..\examples\validation\plot_validate_color.py:                        2.03 sec   0.0 MB
    - ..\examples\validation\plot_validate_light_shadow.py:                 1.95 sec   0.0 MB
    - ..\examples\feature_demo\plot_scene_subplots_video.py:                1.92 sec   0.0 MB
    - ..\examples\validation\plot_validate_mesh_colormap.py:                1.87 sec   0.0 MB
    - ..\examples\feature_demo\plot_multi_slice2.py:                        1.83 sec   0.0 MB
    - ..\examples\feature_demo\plot_light_spotlight_shadows.py:             1.82 sec   0.0 MB
    - ..\examples\validation\plot_validate_volume.py:                       1.76 sec   0.0 MB
    - ..\examples\validation\plot_validate_image1.py:                       1.75 sec   0.0 MB
    - ..\examples\validation\plot_validate_depth_clipping.py:               1.72 sec   0.0 MB
    - ..\examples\feature_demo\plot_multi_slice1.py:                        1.70 sec   0.0 MB
    - ..\examples\validation\plot_validate_helpers2.py:                     1.70 sec   0.0 MB
    - ..\examples\feature_demo\plot_light_spotlights.py:                    1.65 sec   0.0 MB
    - ..\examples\validation\plot_validate_helpers1.py:                     1.63 sec   0.0 MB
    - ..\examples\validation\plot_validate_culling.py:                      1.63 sec   0.0 MB
    - ..\examples\feature_demo\plot_colormap_mesh.py:                       1.61 sec   0.0 MB
    - ..\examples\feature_demo\plot_wireframe_material.py:                  1.59 sec   0.0 MB
    - ..\examples\feature_demo\plot_mesh_depth_material.py:                 1.58 sec   0.0 MB
    - ..\examples\feature_demo\plot_cylinder.py:                            1.58 sec   0.0 MB
    - ..\examples\validation\plot_validate_image2.py:                       1.55 sec   0.0 MB
    - ..\examples\validation\plot_validate_box.py:                          1.53 sec   0.0 MB
    - ..\examples\validation\plot_validate_image_colormap.py:               1.52 sec   0.0 MB
    - ..\examples\feature_demo\plot_image_click_events.py:                  1.52 sec   0.0 MB
    - ..\examples\validation\plot_validate_ndc.py:                          1.51 sec   0.0 MB
    - ..\examples\feature_demo\plot_skybox.py:                              1.49 sec   0.0 MB
    - ..\examples\feature_demo\plot_light_shadow.py:                        1.48 sec   0.0 MB
    - ..\examples\feature_demo\plot_scene_in_a_scene.py:                    1.48 sec   0.0 MB
    - ..\examples\feature_demo\plot_scene_subplots2.py:                     1.47 sec   0.0 MB
    - ..\examples\feature_demo\plot_colormap_image.py:                      1.45 sec   0.0 MB
    - ..\examples\feature_demo\plot_custom_object3.py:                      1.44 sec   0.0 MB
    - ..\examples\feature_demo\plot_custom_object2.py:                      1.40 sec   0.0 MB
    - ..\examples\feature_demo\plot_colormap_channels.py:                   1.33 sec   0.0 MB
    - ..\examples\feature_demo\plot_picking_mesh.py:                        1.31 sec   0.0 MB
    - ..\examples\feature_demo\plot_custom_object1.py:                      1.21 sec   0.0 MB
    - ..\examples\feature_demo\plot_transparency2.py:                       1.19 sec   0.0 MB
    - ..\examples\feature_demo\plot_manual_matrix_update.py:                0.98 sec   0.0 MB
    - ..\examples\feature_demo\plot_panzoom_camera.py:                      0.97 sec   0.0 MB
    - ..\examples\feature_demo\plot_helpers_gizmo.py:                       0.96 sec   0.0 MB
    - ..\examples\feature_demo\plot_spheres.py:                             0.91 sec   0.0 MB
    - ..\examples\feature_demo\plot_light_directional_shadow.py:            0.88 sec   0.0 MB
    - ..\examples\introductory\plot_orbit_camera.py:                        0.85 sec   0.0 MB
    - ..\examples\feature_demo\plot_pbr.py:                                 0.82 sec   0.0 MB
    - ..\examples\introductory\plot_clipping_planes.py:                     0.82 sec   0.0 MB
    - ..\examples\feature_demo\plot_mesh_slice.py:                          0.81 sec   0.0 MB
    - ..\examples\feature_demo\plot_geometry_cubes.py:                      0.78 sec   0.0 MB
    - ..\examples\feature_demo\plot_scene_subplots1.py:                     0.73 sec   0.0 MB
    - ..\examples\introductory\plot_object_bounding_box.py:                 0.70 sec   0.0 MB
    - ..\examples\feature_demo\plot_volume_render1.py:                      0.67 sec   0.0 MB
    - ..\examples\feature_demo\plot_two_canvases.py:                        0.63 sec   0.0 MB
    - ..\examples\feature_demo\plot_instancing_mesh.py:                     0.61 sec   0.0 MB
    - ..\examples\feature_demo\plot_show_scene.py:                          0.58 sec   0.0 MB
    - ..\examples\feature_demo\plot_geometry_polyhedron.py:                 0.57 sec   0.0 MB
    - ..\examples\feature_demo\plot_scene_overlay.py:                       0.57 sec   0.0 MB
    - ..\examples\feature_demo\plot_physical_color.py:                      0.57 sec   0.0 MB
    - ..\examples\feature_demo\plot_image_plus_points.py:                   0.54 sec   0.0 MB
    - ..\examples\feature_demo\plot_transparency1.py:                       0.51 sec   0.0 MB
    - ..\examples\feature_demo\plot_synced_video.py:                        0.51 sec   0.0 MB
    - ..\examples\feature_demo\plot_show_image.py:                          0.50 sec   0.0 MB
    - ..\examples\feature_demo\plot_volume_render2.py:                      0.50 sec   0.0 MB
    - ..\examples\feature_demo\plot_world_bounding_box.py:                  0.49 sec   0.0 MB
    - ..\examples\feature_demo\plot_geometry_plane.py:                      0.44 sec   0.0 MB
    - ..\examples\feature_demo\plot_picking_color.py:                       0.44 sec   0.0 MB
    - ..\examples\feature_demo\plot_volume_slice2.py:                       0.43 sec   0.0 MB
    - ..\examples\feature_demo\plot_volume_slice3.py:                       0.42 sec   0.0 MB
    - ..\examples\feature_demo\plot_wireframe2.py:                          0.37 sec   0.0 MB
    - ..\examples\feature_demo\plot_volume_slice4.py:                       0.36 sec   0.0 MB
    - ..\examples\feature_demo\plot_wireframe1.py:                          0.35 sec   0.0 MB
    - ..\examples\feature_demo\plot_line_basic.py:                          0.34 sec   0.0 MB
    - ..\examples\feature_demo\plot_geometry_torus_knot.py:                 0.33 sec   0.0 MB
    - ..\examples\feature_demo\plot_line_thick.py:                          0.32 sec   0.0 MB
    - ..\examples\feature_demo\plot_volume_slice1.py:                       0.31 sec   0.0 MB
    - ..\examples\feature_demo\plot_geometry_polyhedron_subdivisions.py:    0.29 sec   0.0 MB
    - ..\examples\feature_demo\plot_geometry_klein_bottle.py:               0.29 sec   0.0 MB
    - ..\examples\feature_demo\plot_geometry_image.py:                      0.27 sec   0.0 MB
    - ..\examples\feature_demo\plot_picking_points.py:                      0.25 sec   0.0 MB
    - ..\examples\introductory\plot_cube.py:                                0.24 sec   0.0 MB
    - ..\examples\introductory\plot_light_basic.py:                         0.24 sec   0.0 MB
    - ..\examples\feature_demo\plot_line_segments.py:                       0.22 sec   0.0 MB
    - ..\examples\feature_demo\plot_flat_shaded_torus.py:                   0.22 sec   0.0 MB
    - ..\examples\feature_demo\plot_show_util.py:                           0.20 sec   0.0 MB
    - ..\examples\introductory\plot_offscreen.py:                           0.19 sec   0.0 MB
    - ..\examples\feature_demo\plot_line_performance.py:                    0.18 sec   0.0 MB
    - ..\examples\feature_demo\plot_post_processing2.py:                    0.00 sec   0.0 MB
    - ..\examples\feature_demo\plot_sponza_scene.py:                        0.00 sec   0.0 MB
    - ..\examples\feature_demo\plot_post_processing1.py:                    0.00 sec   0.0 MB
    - ..\examples\feature_demo\plot_show_stl.py:                            0.00 sec   0.0 MB
    - ..\examples\cube_qt.py:                                               0.00 sec   0.0 MB
    - ..\examples\cube_wx.py:                                               0.00 sec   0.0 MB
    - ..\examples\integration_qt.py:                                        0.00 sec   0.0 MB
    - ..\examples\introductory\points_basic.py:                             0.00 sec   0.0 MB
    - ..\examples\light_view.py:                                            0.00 sec   0.0 MB
    - ..\examples\text_with_qt.py:                                          0.00 sec   0.0 MB

Adding this link here for future reference.
It is possible to specify a custom static thumbnail image for a gallery example. This can be useful for gui-specific examples that we can't run on CI. For these, we can either run it offline and insert the thumbnail, or we could display a static image (eg the logo of the GUI backend used) for those examples.
Here is the link to the relevant docs: https://sphinx-gallery.github.io/stable/configuration.html#providing-an-image-for-the-thumbnail-image

I've reorganized this PR to make use of Display and introduced the ability to configure how gallery examples are built using comments of the form
# sphinx_gallery_pygfx_<name> = <value>

This builds on top of sphinx-gallery's mechanism, which takes the form of # sphinx_gallery_<name> = <value> (which I have discovered today). This is nice because we can configure sphinx-gallery to remove these comments from the produced RST and IPYNB files, making the result look clean. To this, I've added a pygfx namespace to isolate the variables we care about.
With this, we can easily control when to render. To create a render below a given example's code block one has to specify
# sphinx_gallery_pygfx_render = True

This will trigger our scraper to check the global scope for a variable named "renderer". The variable to check can be controlled by specifying
# sphinx_gallery_pygfx_target_name = "<var_name>"
# eg.
# sphinx_gallery_pygfx_target_name = "disp"

inside the block. The resulting variable is assumed to be a Display, Renderer, or Canvas, and is used to render the image to display.
I've also added plumbing to procude animations/GIFs by (via # sphinx_gallery_pygfx_animage = True); however, this is not fully implemented yet, because I first need to figure out how to generate video using pygfx (https://github.com/pygfx/pygfx/issues/381#issuecomment-1328226839).
I've also fixed the __file__ issue mentioned earlier.
What is missing now is to set up lavapipe on the CI runners that build the docs (GH Actions and RTD). However, it should already be possible to build the gallery locally as part of the normal doc-building procedure.

Okay, now the tests are passing (with exception of the one that currently breaks globally). One downside is that the doc build now takes 74 minutes because we are rendering all the examples (twice). (For comparison, on my machine with GPU building the docs takes less than 5 minutes.)
Here is a summary of how long each example takes to build on GH Actions. We may wish to discuss which examples are worth building.

computation time summary:
    - ../examples/feature_demo/plot_pbr2.py:                               112.51 sec   0.0 MB
    - ../examples/validation/plot_validate_volume.py:                      106.87 sec   0.0 MB
    - ../examples/validation/plot_validate_light_shadow.py:                105.47 sec   0.0 MB
    - ../examples/validation/plot_validate_ndc.py:                         105.25 sec   0.0 MB
    - ../examples/validation/plot_validate_mesh_colormap.py:               105.07 sec   0.0 MB
    - ../examples/validation/plot_validate_color.py:                       103.77 sec   0.0 MB
    - ../examples/validation/plot_validate_culling.py:                     103.36 sec   0.0 MB
    - ../examples/validation/plot_validate_box.py:                         102.63 sec   0.0 MB
    - ../examples/feature_demo/plot_light_spotlight_shadows.py:            102.58 sec   0.0 MB
    - ../examples/feature_demo/plot_wireframe_material.py:                 102.55 sec   0.0 MB
    - ../examples/feature_demo/plot_custom_object3.py:                     102.46 sec   0.0 MB
    - ../examples/validation/plot_validate_helpers1.py:                    102.24 sec   0.0 MB
    - ../examples/validation/plot_validate_image_colormap.py:              102.19 sec   0.0 MB
    - ../examples/validation/plot_validate_image1.py:                      102.16 sec   0.0 MB
    - ../examples/validation/plot_validate_depth_clipping.py:              101.85 sec   0.0 MB
    - ../examples/validation/plot_validate_helpers2.py:                    101.81 sec   0.0 MB
    - ../examples/validation/plot_validate_image2.py:                      101.19 sec   0.0 MB
    - ../examples/feature_demo/plot_light_spotlights.py:                    98.47 sec   0.0 MB
    - ../examples/feature_demo/plot_multi_select.py:                        98.06 sec   0.0 MB
    - ../examples/feature_demo/plot_custom_object2.py:                      97.59 sec   0.0 MB
    - ../examples/feature_demo/plot_mesh_depth_material.py:                 97.28 sec   0.0 MB
    - ../examples/feature_demo/plot_colormap_mesh.py:                       95.81 sec   0.0 MB
    - ../examples/feature_demo/plot_scene_subplots2.py:                     95.68 sec   0.0 MB
    - ../examples/feature_demo/plot_scene_subplots_video.py:                95.11 sec   0.0 MB
    - ../examples/feature_demo/plot_collection_line.py:                     91.74 sec   0.0 MB
    - ../examples/feature_demo/plot_dynamic_env_map.py:                     90.46 sec   0.0 MB
    - ../examples/feature_demo/plot_colormap_image.py:                      90.44 sec   0.0 MB
    - ../examples/feature_demo/plot_custom_object1.py:                      89.49 sec   0.0 MB
    - ../examples/feature_demo/plot_image_click_events.py:                  83.58 sec   0.0 MB
    - ../examples/feature_demo/plot_multi_slice1.py:                        82.83 sec   0.0 MB
    - ../examples/feature_demo/plot_light_shadow.py:                        82.75 sec   0.0 MB
    - ../examples/feature_demo/plot_multi_slice2.py:                        80.21 sec   0.0 MB
    - ../examples/feature_demo/plot_picking_mesh.py:                        79.07 sec   0.0 MB
    - ../examples/feature_demo/plot_pbr.py:                                 75.18 sec   0.0 MB
    - ../examples/feature_demo/plot_cylinder.py:                            75.16 sec   0.0 MB
    - ../examples/feature_demo/plot_colormap_channels.py:                   72.98 sec   0.0 MB
    - ../examples/feature_demo/plot_transparency2.py:                       71.32 sec   0.0 MB
    - ../examples/feature_demo/plot_scene_in_a_scene.py:                    71.08 sec   0.0 MB
    - ../examples/feature_demo/plot_skybox.py:                              35.31 sec   0.0 MB
    - ../examples/feature_demo/plot_scene_subplots1.py:                     33.32 sec   0.0 MB
    - ../examples/feature_demo/plot_volume_render1.py:                      32.77 sec   0.0 MB
    - ../examples/feature_demo/plot_spheres.py:                             32.23 sec   0.0 MB
    - ../examples/feature_demo/plot_mesh_slice.py:                          31.76 sec   0.0 MB
    - ../examples/feature_demo/plot_light_directional_shadow.py:            30.83 sec   0.0 MB
    - ../examples/feature_demo/plot_manual_matrix_update.py:                29.99 sec   0.0 MB
    - ../examples/feature_demo/plot_panzoom_camera.py:                      26.79 sec   0.0 MB
    - ../examples/feature_demo/plot_scene_overlay.py:                       25.85 sec   0.0 MB
    - ../examples/feature_demo/plot_transparency1.py:                       25.64 sec   0.0 MB
    - ../examples/feature_demo/plot_volume_render2.py:                      25.24 sec   0.0 MB
    - ../examples/feature_demo/plot_instancing_mesh.py:                     23.48 sec   0.0 MB
    - ../examples/feature_demo/plot_physical_color.py:                      18.84 sec   0.0 MB
    - ../examples/feature_demo/plot_synced_video.py:                        18.82 sec   0.0 MB
    - ../examples/feature_demo/plot_line_basic.py:                          18.71 sec   0.0 MB
    - ../examples/feature_demo/plot_volume_slice4.py:                       18.07 sec   0.0 MB
    - ../examples/feature_demo/plot_picking_color.py:                       17.61 sec   0.0 MB
    - ../examples/feature_demo/plot_volume_slice2.py:                       17.34 sec   0.0 MB
    - ../examples/feature_demo/plot_volume_slice3.py:                       17.28 sec   0.0 MB
    - ../examples/feature_demo/plot_geometry_polyhedron.py:                 16.93 sec   0.0 MB
    - ../examples/feature_demo/plot_world_bounding_box.py:                  16.76 sec   0.0 MB
    - ../examples/feature_demo/plot_geometry_cubes.py:                      14.45 sec   0.0 MB
    - ../examples/feature_demo/plot_helpers_gizmo.py:                       14.44 sec   0.0 MB
    - ../examples/feature_demo/plot_wireframe2.py:                          13.71 sec   0.0 MB
    - ../examples/feature_demo/plot_picking_points.py:                      13.01 sec   0.0 MB
    - ../examples/feature_demo/plot_geometry_plane.py:                      12.78 sec   0.0 MB
    - ../examples/feature_demo/plot_line_thick.py:                          12.69 sec   0.0 MB
    - ../examples/feature_demo/plot_volume_slice1.py:                       12.29 sec   0.0 MB
    - ../examples/feature_demo/plot_wireframe1.py:                          11.98 sec   0.0 MB
    - ../examples/feature_demo/plot_geometry_torus_knot.py:                 11.19 sec   0.0 MB
    - ../examples/feature_demo/plot_image_plus_points.py:                   10.53 sec   0.0 MB
    - ../examples/feature_demo/plot_geometry_klein_bottle.py:               10.20 sec   0.0 MB
    - ../examples/feature_demo/plot_line_performance.py:                    10.14 sec   0.0 MB
    - ../examples/feature_demo/plot_flat_shaded_torus.py:                    9.63 sec   0.0 MB
    - ../examples/feature_demo/plot_line_segments.py:                        9.12 sec   0.0 MB
    - ../examples/feature_demo/plot_show_scene.py:                           9.11 sec   0.0 MB
    - ../examples/feature_demo/plot_show_image.py:                           8.06 sec   0.0 MB
    - ../examples/feature_demo/plot_geometry_polyhedron_subdivisions.py:     7.48 sec   0.0 MB
    - ../examples/feature_demo/plot_show_stl.py:                             6.30 sec   0.0 MB
    - ../examples/introductory/plot_orbit_camera.py:                         6.19 sec   0.0 MB
    - ../examples/feature_demo/plot_geometry_image.py:                       5.94 sec   0.0 MB
    - ../examples/introductory/plot_clipping_planes.py:                      5.26 sec   0.0 MB
    - ../examples/introductory/plot_light_basic.py:                          3.84 sec   0.0 MB
    - ../examples/introductory/plot_object_bounding_box.py:                  3.50 sec   0.0 MB
    - ../examples/introductory/plot_show_util.py:                            3.41 sec   0.0 MB
    - ../examples/introductory/plot_points_basic.py:                         2.76 sec   0.0 MB
    - ../examples/introductory/plot_hello_triangle.py:                       2.53 sec   0.0 MB
    - ../examples/introductory/plot_cube.py:                                 1.93 sec   0.0 MB
    - ../examples/introductory/plot_offscreen.py:                            0.47 sec   0.0 MB
    - ../examples/other/cube_qt.py:                                          0.00 sec   0.0 MB
    - ../examples/other/cube_wx.py:                                          0.00 sec   0.0 MB
    - ../examples/other/integration_qt.py:                                   0.00 sec   0.0 MB
    - ../examples/other/light_view.py:                                       0.00 sec   0.0 MB
    - ../examples/other/post_processing1.py:                                 0.00 sec   0.0 MB
    - ../examples/other/post_processing2.py:                                 0.00 sec   0.0 MB
    - ../examples/other/sponza_scene.py:                                     0.00 sec   0.0 MB
    - ../examples/other/text_with_qt.py:                                     0.00 sec   0.0 MB
    - ../examples/other/two_canvases.py:                                     0.00 sec   0.0 MB

Apart from that, what is now pending in this PR is:

Get RTD to build the gallery (I don't have a good way to test this, but @almarklein offered to check if we can get PR builds working. This should help)
Add video/GIF for some examples.

Wow, 100s for one frame ...

(twice).

Why are we rendering them twice?

takes 74 minutes

This is a problem for RTD, because the built limit is 15 min, 30 min for a business account.

@almarklein offered to check if we can get PR builds working. This should help)

No luck yet ...

Why are we rendering them twice?

Because sphinx-gallery will run the example incrementally to give us access to the variables. This involves calling either run() or show() at some point which triggers a render behind the scenes that gets discarded. We then render a second time when we explicitly call img = canvas.draw() inside the scraper to actually produce the image we save for the gallery.

This is a problem for RTD, because the built limit is 15 min, 30 min for a business account.

Indeed. Though this assumes that we are using a similar instance/machine for both services.
We could also start considering building the gallery images offline and tracking them as a "static" asset that gets regenerated on regular intervals and then pulled in by RTD when building the docs. Once I am done reorganizing the examples, I don't think they will change frequently...

I think you mentioned that we can also simply specify the thumbnail to use. So could we run all examples on our own terms, store the screenshots, then run sphinx gallery with the custom screenshots that we just made? That way we can already reduce the build time by half. And much further once we can do #362.

Yes, we could manually render all the examples and create a folder that contains the resulting images (either inside this repo, or externally). We would then pull in those images during CI builds and use them as output instead of rendering the images on the runner. This would save 50%-ish of the time.
We could also introduce a new environment variable similar to the one that forces the auto GUI to use the offscreen, maybe something like WGPU_SPHINX_MODE which would skip the rendering when run() is called. This would save the other 50%-ish of the time to build the gallery.

Yes, we could manually render all the examples and create a folder that contains the resulting images (either inside this repo, or externally). We would then pull in those images during CI builds and use them as output instead of rendering the images on the runner. This would save 50%-ish of the time.

I meant in one CI build step:

Generate screenshots and gifs for the gallery, store in a local folder.
Build the gallery using the results in the local folder.

I meant in one CI build step:

Not sure I understood you correctly. If we render on GH Actions and build the gallery on RTD wouldn't we get a race condition?Both are triggered by pushes and I don't know a good way to ask RTD to wait for an action to finish before starting to build the docs.

Haha, communication is hard 😄   I meant to do it as part as the build itself, as a pre-processing for the Sphinx build. E.g. from the conf.py we could call something that renders the screenshots, and then Sphinx proceeds as usual, except the gallery logic will not run the examples, it will use the pre-rendered screenshots.

The long build time is a problem. Let's see what our options are now.

If we apply my suggestion and use Korijns trick #362, we can probably run all examples in a short enough time, so it could run on RTD. Some obstacles though:

For this to work we need to update wgpu-py to the latest wgpu-native, to hopefully get rid of the memory leaks that we were seeing. I hope to get to that next week.
We don't know yet whether we can even render examples on RTD.

Host docs on GH pages.
Render screenshots at GH actions and somehow host docs into RTD. There are several options (see #345) but each is tricky in its own way.

The first option would definitely have my preference. My suggestion for moving forward would be to:

Update this PR to only render screenshots for a few examples, so the build time is short enough for RTD.
Try to get it to run on RTD.
When we have a new wgpu-py, see if we can get #362 working.
Update the gallery building to use that.

E.g. from the conf.py we could call something that renders the screenshots, and then Sphinx proceeds as usual, except the gallery logic will not run the examples, it will use the pre-rendered screenshots.

I think I'm still stuck not understanding because I still don't see how this would reduce build time. The problem is that CI uses CPU rendering, which is painfully slow and either approach (pre-processed render vs render during doc building) will suffer from that bottleneck.
Are you thinking of saving some overhead costs (#362)? We are already doing all the scraper-related rendering in the same thread, but I can check if we can shave off more time by reusing e.g., the canvas or the renderer where it makes sense (i.e., for examples that use a Display and don't define an explicit canvas).
Another issue with not running the examples is that it will not call the scraper on examples that are not run/rendered. As a result, we would have to hardcode the image paths into each example (we could, but it's a bit ugly). We would also lose any other output, e.g., if a block prints FPS: 3 then the gallery captures that and will display it below the block when running the example.

The long build time is a problem. Let's see what our options are now.

There is also the option to do something similar to what we do in wgpu when bindings are updated: We build the gallery locally (on a machine with GPU), upload the resulting images, skip any rendering on CI, and use the pre-rendered images instead.
This would keep CI fast and run on RTD without too much hassle (we can pull in external images as a pre-build step). The downside is that images don't update when examples update; however, this may be mitigated by examples not changing frequently.

We could also build in an option (environment variable, or a flag on renderer) to make calls to render/draw a noop to optimize the initial scraping of code.

We could also build in an option (environment variable, or a flag on renderer) to make calls to render/draw a noop to optimize the initial scraping of code.

Yes, I was thinking of this option as well something like WGPU_SPHINX_MODE (though I don't like environment variables) or simply a monkey-patch inside conf.py that makes wgpu.gui.offscreen.run a noop. This way, we'd save 50% of the runtime.

Also, different topic, we would ideally like to have PR builds on RTD set up to better test the gallery, both in terms of runtime and in terms of final result.
I am now done with all my pending PRs except for this one, so I will pick up some new ones today or tomorrow. Should I look into RTD pr builds (and it registering as a check inside the PR)?

Sure, go ahead

We could also build in an option (environment variable, or a flag on renderer) to make calls to render/draw a noop to optimize the initial scraping of code.

Yes, I was thinking of this option as well something like WGPU_SPHINX_MODE (though I don't like environment variables) or simply a monkey-patch inside conf.py that makes wgpu.gui.offscreen.run a noop. This way, we'd save 50% of the runtime.

A monkey-patch in conf.py sounds good to me.

Also, different topic, we would ideally like to have PR builds on RTD set up to better test the gallery, both in terms of runtime and in terms of final result.
I am now done with all my pending PRs except for this one, so I will pick up some new ones today or tomorrow. Should I look into RTD pr builds (and it registering as a check inside the PR)?

Go ahead!

Are you thinking of saving some overhead costs (https://github.com/pygfx/pygfx/pull/362)? We are already doing all the scraper-related rendering in the same thread, but I can check if we can shave off more time by reusing e.g., the canvas or the renderer where it makes sense (i.e., for examples that use a Display and don't define an explicit canvas).

Yes, it'd avoid everything being rendered twice, and it would give us more room for tweaks to make it faster. But I completely overlooked the fact that we're already "doing" what #362 proposes 😄  Sorry for introducing confusion.
From what we saw in earlier experiments, re-using the device creates the biggest benefit, and this happens by default when the examples run in the same process.
This means that the building is slow for the same reason that #362 is slow: because of the memory leaks in wgpu-native. With some luck, the gallery building in this PR will become much faster when wgpu-py updates!
So, let's cut the build time in half by avoiding the initial draws. And then try things running on RTD.

that's interesting. I added the monkeypatch that I suggested earlier this week. On my local system this does speed up the gallery building (didn't quantify explicitly, but the build logs reported about 1-2 sec less per example) while still producing the screenshots as expected.
On CI this seems to make a massive difference. Rendering the docs is now down to 3 minutes (!) from around 70-80 min. I'll look into RTD now to see if I can get a rendered output and see if everything is created correctly.

@almarklein Some bad news on the rendering on RTD front. I've tried installing lavapipe on RTD, but I keep running into permission errors. I will have a think if I can come up with a way of installing it that doesn't involve apt and potentially reach out to the RTD devs for some feedback. Hopefully one of these approaches proves fruitful. If not, we may have to consider alternatives.

@Korijn
Here is the latest one that tried using sudo for permissions: https://readthedocs.org/projects/pygfx/builds/18800543/
Here is the one that tried to directly install via apt-get: https://readthedocs.org/projects/pygfx/builds/18800442/

Eek! Yeah, let's reach out to the RTD devs and see if something's possible ...

The only way to install apt packages is via build.apt_packages, and sadly PPAs are not supported. See here: https://github.com/readthedocs/readthedocs.org/blob/624b13d5a208f11c1a06a9422888ebc5fdb1114d/docs/user/config-file/v2.rst#build-apt-packages

Eek! Yeah, let's reach out to the RTD devs and see if something's possible ...

Yes. I've sent a message yesterday. Let's see what they say.

The only way to install apt packages is via build.apt_packages, and sadly PPAs are not supported.

I am aware. Though I was hoping that there might be a way around this, i.e., that this is a limitation in the API of apt_packages rather than an explicitly chosen restriction.

There are ways to "install" .deb packages without root access, see here for example: https://askubuntu.com/a/350
It's not exactly trivial though..

@Korijn That's exactly what I've been looking into just now ... you must be reading my mind 😅
My main doubt is if wgpu will pick up the local installation. Do you have any experience here? Or know where I can read up on what to configure to point wgpu to those drivers (maybe setting PATH is enough)?

On this page: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers
Read the section: === Using alternative drivers - Here be dragons ===
I think this is what you want to do:
* zink + lavapipe - OpenGL emulated on a software Vulkan driver:
  Set VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json MESA_LOADER_DRIVER_OVERRIDE=zink
* llvmpipe OpenGL software render:
  Set MESA_LOADER_DRIVER_OVERRIDE=llvmpipe

._. I tried a fresh ubuntu 22.04 image in WSL and the gallery builds fine without having to rely on a custom PAA. However, doing the same on RTD results in a segfault. Could this be because WSL uses a different kernel than standard ubuntu?

._. I tried a fresh ubuntu 22.04 image in WSL and the gallery builds fine without having to rely on a custom PAA. However, doing the same on RTD results in a segfault. Could this be because WSL uses a different kernel than standard ubuntu?

Seems unlikely.

Jackpot! 🚀 🤩  @Korijn @almarklein We now have a gallery on RTD: https://pygfx--384.org.readthedocs.build/en/384/_gallery/index.html
Looks like the issue was just one example (collection_line.py), which I think we can afford to not build. Not 100% sure what the issue with it is (segfaults are hard to debug remotely; my guess is OOM), but it is also one of the heavy examples that we were discussing not to build on CI anyway. I am happy to exclude it from rendering for now.

We are finally ready to give this PR a serious review :)
There is likely some scaffolding left over from some of the experimentation that I've done to get this running, so if anything looks out of place feel free to question it. Otherwise, all the pieces should be in place.
Also note: In this PR; I have only done minimal changes to the examples to make them compliant with sphinx-gallery. Once this is merged, I will do a few follow-up PRs where I will refactor individual examples to prettify them or introduce Display.

Looks good!
I'm surprised this doesn't suffer from the issues found in #362. Does sphinx-gallery sandbox the examples to subprocesses?

I'm surprised this doesn't suffer from the issues found in https://github.com/pygfx/pygfx/pull/362. Does sphinx-gallery sandbox the examples to subprocesses?

Not that I am aware of, no. Neither does CI/Docs which builds the gallery in GH Actions. It used to be slow, but ever since I monkey-patched wgpu.gui.offscreen.run and replaced it with a no-op, things have been running fast and smooth.

@almarklein I looked into WEBP as an alternative to GIF for animations. As you suspected, supported formats are hardcoded into the source (here). I've opened a ticket upstream to ask for support (here), but in the meantime I've implemented a workaround using the following hack:
def _get_sg_image_scraper():
    # add webp as supported extension
    import sphinx_gallery.scrapers
    sphinx_gallery.scrapers._KNOWN_IMG_EXTS += ("webp",)

    return pygfx_scraper

This gives us WEBP support and makes our gradients look nice again.

but ever since I monkey-patched wgpu.gui.offscreen.run and replaced it with a no-op, things have been running fast and smooth.

@Korijn could be worth trying that in #362. This would mean it'd be related to asyncio 🤔

I can think of a number of ways that could be the problem indeed! I will investigate.

Nice to see smooth gradients in the animation ❤   It looks like the thumbnail is static (as intended). Did you do anything to make that work, or does SphinxGallery accidentally make it static when it makes the thumbnail?

Nice to see smooth gradients in the animation ❤ It looks like the thumbnail is static (as intended). Did you do anything to make that work, or does SphinxGallery accidentally make it static when it makes the thumbnail?

Just FYI: the thumbnail was not static when it was still a .gif.
Also, I think the image quality is a little low, there seem to be a lot of compression artifacts. Can we raise the quality a little?

Did you do anything to make that work, or does SphinxGallery accidentally make it static when it makes the thumbnail?

No, this is "by accident". I expected the thumbnail generation to break when I create a WEBP, but instead, it is picked up and turned into a static WEBP.
At some point, I should look into how this process works and how to tell sphinx-gallery that it should either generate a PNG from the WEBP or do that manually and tell the gallery to use the image we generate as thumbnail instead. In my mind, the current approach is a good enough start and then we can revise from there in future PRs.

Just FYI: the thumbnail was not static when it was still a .gif.

No, because the thumbnail has the same format as the original image. Since GIF is officially supported by sphinx-gallery and WEBP isn't there is likely something that doesn't behave 100% correct. Something we may want to investigate, but I'm not sure if we should do that here or in a follow-up.
That said, we want thumbnails to be static. If not, you will see a lot of moving things in the gallery overview, which will be a bit messy.

Also, I think the image quality is a little low, there seem to be a lot of compression artifacts. Can we raise the quality a little?

Yes, because WEBP uses YUV420. I will have a look if we can control the compression quality 👍

Yes, because WEBP uses YUV420. I will have a look if we can control the compression quality 👍

That said, we already improve over the default quality that comes out of GIF (and its 256 colors) 🥲

@Korijn Now we are using lossless compression, so any compression artifacts should disappear. This comes at the cost of additional runtime though, so we may need to revisit this once our examples or animation needs have grown to the limitations of RTD build time.

@Korijn I didn't get a notification that you resolved the conversation (GH doesn't seem to do those), so I missed that we can merge this until now.
Master/Main has moved on, so I have re-synced the branch and resolved a merge conflict manually. Take a look and see if it still looks good :) From my side, we are still LGTM.

@Korijn the validation tests broke because of a pathing issue after the ids update. That's now fixed :)

Awesome work!

And with that the gallery is live! Nice!


Can we get a version that can interact with other JSON (de-) serializers?

We have situations where we receive or have to send a JSON Object with some of the values being FHIR Objects, and others being non-FHIR Objects.
Sadly, HAPI-FHIR does not allow using it together with Gson, Jackson, or any other JSON library currently, which makes this very hard (practically impossible).
We’d like to see a way to do this natively, for example by HAPI-FHIR providing typeadapters for Gson.

Hi Janne,
I'd like for HAPI to migrate to natively using either GSON or Jackson instead of JSR 353 which it currently uses. At the time we started the project it looked like JSR 353 had a bright future but that doesn't seem like it's the case anymore.
I don't know that we have a schedule for doing this yet though- if anyone wants to have a try at this I wouldn't object. :)
Are you asking for support for multiple parsers though? I'm not sure I understand the benefit there. In my mind it probably makes more sense to go with Jackson since that's the more powerful parser.. Gson is more ubiquitous though, so that's a point in its favour. It probably wouldn't be toooo hard to support GSON and Jackson, but it would be more work for sure.

We have Apache camel running in front of HAPI FHIR to do conversions. Is that an option?
Sent from my iPhone

On 4 Mar 2016, at 18:37, Janne Koschinski<EMAIL_ADDRESS>wrote:
We have situations where we receive or have to send a JSON Object with some of the values being FHIR Objects, and others being non-FHIR Objects.
Sadly, HAPI-FHIR does not allow using it together with Gson, Jackson, or any other JSON library currently, which makes this very hard (practically impossible).
We’d like to see a way to do this natively, for example by HAPI-FHIR providing typeadapters for Gson.
—
Reply to this email directly or view it on GitHub.

Are you asking for support for multiple parsers though? I'm not sure I understand the benefit there. In my mind it probably makes more sense to go with Jackson since that's the more powerful parser.. Gson is more ubiquitous though, so that's a point in its favour. It probably wouldn't be toooo hard to support GSON and Jackson, but it would be more work for sure.

No, sorry if it seemed like that.
I was just hoping for you to support either of those.
As obviously this transition won’t be done by Monday (and I need it by then) I’ll just hack something together for that uni project and add a link to this thread with some explanations on how to do it properly for the team which will take over my project next year.

@jamesagnew Btw, do you have any suggestions on how to get this running with Gson or Jackson already today? Doesn’t have to be perfect, of course.

@jamesagnew Sorry to bother you again, but: Could you make a tiny change (which would already improve usability with other parsers a lot) which adds 2 methods on the IParser to encode from IResource to JsonObject and deserialize from JsonObject to IResource?

In terms of support for GSON/Jackson, probably the easiest thing to do would be to create a copy of HAPI's JsonParser class. In that copy, you could delete all references to javax.json and replace them with equivalent calls to GSON/Jackson's parser classes.
I don't actually think this part would be hard to do- it's really the change management around updating documentation and things like that which have held me back so far..

@jamesagnew I already did that, and am already using that in my projects, but I’d hope that this feature would end up natively by the time the next team takes over my project (because I don’t trust they’ll be able to maintain it)

Hi Janne,
Which parser did you end up using? Any interest in contributing it back to HAPI? If it gives us a headstart in moving away from javax.json I guess that's the fastest way to get it natively supported.. :)

I ended up using Gson (because we use that in our project already), but I don’t think my code is worth being integrated here again. I can upload it later today, though.


Added client filter for logout message

@mcdonnelldean please take a look, this PR is adding the filter on client.

@mcdonnelldean it also fixes the issue with page not loading correctly after force logout


Small Iterative improvements

Hi @adpick, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Adam Pickersgill). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

@adpick : Thanks for your contribution to the Azure documentation! The author, @JiangChen79, has been notified to review your proposed change.


[Opinion] More customizability / Comparison to QTTabBar

Hello!
While I used »QTTabBar« (http://qttabbar.wikidot.com - unfortunately no screenshots anymore on the website itself, just google its name for some) as a Windows File Explorer extension, it finally stopped working and its developer is again gone for years already.
On my search for a replacement — which means, something like the original and not a program like all the »commanders« out there — the only one I found is this one. Fine so far.
However, tests shows that this really is what I am looking for but has no even close the customizability like the extension mentioned above. While I do not need just the half of it, some crucial things are missing. Several entries of applications in the context menu, for exmaple. And the custom links are really too close to the also really limited quick access area of the original File Explorer. There not even is a real list view; one has to built one using the details view and hiding columns.
I understand that this project is relatively new and the team is realtively small and that development is a hard business. So, you might take the extension I mentioned and its feature as suggestions for new addition on the one hand.
On the other hand and with the news that Microsoft is working on a new File Explorer theirself, I ask myself where this all leads to. And what the roadmap is for Files under this circumstances. While Files at the moment only is usefull for some users and with new competition from Microsoft, where does this lead to?
Just an opinion on the general status of the situation; no harm meant! ;-)
Greetings from Germany and this grey and rainy day,
Tim

Thanks for the feedback. Please make a new issue following the issue templates if I have missed any entry's below and for future feedback. It tells you how to fill it out if you don't know what to put for a section.

Several entries of applications in the context menu

Please make a bug report following the issue template for this and show what entries are missing.

There not even is a real list view

This is being tracked here #1928


Make toast message thinner

First of all, this is a really excellent app.
It would be nice if the toast bar that appears when you make a change to a file (such as renaming) were only as wide as the text. I do a lot of renaming files and moving them to other folders, and whenever I rename a file the toast message completely obscures the move option. If the toast bar message were only as wide as the message, the option to move the file would probably not be totally obscured. Screenshot attached.

No big deal if wide toast bar is a design decision you don't want to change, it's impossible to make everyone happy all the time.

Sounds good, want me to close the issue or leave it for you to close?

Please leave it open. I'll close it when I tackle this.

I see the new behavior - thanks!


Deployment Patterns?

Hi --
Love the bot, great work, thank you for open-sourcing it. Really appreciate the code coverage and thorough usage of modern Python development tools.
Quick question -- what deployment pattern do you recommend for this? Is this something you typically export out as a Lambda behind API Gateway? Is there a simpler pattern?
Thanks!
Ankur

Hey @ankur-hop! Great question!
I would not recommend Lambda or other serverless patterns as this framework does take advantage of blocking on a web socket connection. Therefore, I'd recommend deploying this on a very small instance like an AWS t2.micro or even a Digital Ocean $5/month droplet.
I've been using a Home Server, always on desktop, for development and that has worked great.
I recently merged in a PR that adds a sample Dockerfile which might be a good jumping off point!


input goes to wrong tab

If I have more than one pdf tab open, any toolbar command (e.g. zoom, rotate), in any of the tabs, affect the content of only the first tab opened.
0.14.0

wouldn't be surprised if this was related to #56

duplicate of #55


More semantics: rasterio name collision

In GitLab by @Huite on Aug 11, 2018, 23:17
from imod import rasterio obviously collides with import rasterio, which is somewhat inconvenient because it's not unlikely you're using both at the same time.
One alternative is renaming it imod.rio: it goes great with the three letter aesthetic we've got going so far!
rio also seems to be surprisingly uncommon as the rasterio alias within Python; it is of course the name for the CLI, but I kinda like that as it's still the right association without colliding.
What do you think?

In GitLab by @visr on Aug 15, 2018, 16:12
We just discussed that rio might not be obvious to those not familiar with rasterio. It might be better to rename to imod.raster instead. This will also be more clear inside the imod-python codebase where rasterio is also used. Ideally we do this with a deprecation warning to help users upgrading code.

In GitLab by @Huite on Mar 13, 2019, 18:47
I've come around a little: the convenience functions should actually make it rather unlikely that you're importing rasterio separately. rasterio also communicates more clearly where the functionality is coming from than raster.

In GitLab by @Huite on Mar 13, 2019, 18:47
closed


[FLINK-22098][table-planner-blink] Fix bug for window join: plan is wrong if join condition contain 'IS NOT DISTINCT FROM'

What is the purpose of the change
Now plan is wrong if window join contain 'IS NOT DISTINCT FROM'. This pull request aims to fix the bug.
Brief change log

Fix bug in WindowJoinUtil

Verifying this change

Added test in WindowJoinTest

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

cc @wuchong

@godfreyhe Thanks for review, I've addressed failed case

@flinkbot run azure


fix: deploy timeout error message

Adds a space between comma-separated list, removes extra s.

Updated to following conventional commits format.

Closing in favor of #298


Make controller props available automatically via this.props

We tend to copy information from controller props into state in the initialize method, and then (when we remember) update it in changeProps. This change is designed to avoid that - if we need to use props they should be available via this.props and always up-to-date.
I've made props reactive, as I think there's potential for gotchas otherwise, but I have also marked them as protected - the intent is to use them within the controller rather than externally. We can consider making them public though if that seems useful.

Thanks @justinweiss - your suggestions make sense. We could make props readonly by wrapping them in a getter, is that what you were thinking? (I assume the readonly modifier won't work since we do want to update them)
  private _props: Props

  get props() {
    return this._props
  }

Hm, that would just prevent reassigning the props as a whole.
I was wondering if there was a way to make props' properties read-only when accessing them directly, but still allowing us to update them internally. For example, something like using defineProperty to make the properties non-writeable, but redefining them when they change. Or wrapping props in an object that would define getters for all its keys, but not expose its internal state or provide setters.
But I don't know if that would play well with observable. I'm not sure it's worth it.

Right, good point. I thought about using Object.freeze but also not sure if that'd play nicely with observable. Then I realised we could just wrap props in the Readonly type, which at least makes it clear in the types - I've done that


character name

hi when using say "text" is there a way to hide "character name" tab above? or have the name change
every time (But itd be easier if i could just hide it. I cant figure out "TEXT" tab linked to picture, so SAY
i think is best way...
side note: i see you made pazzt too, can bitsy convert to zzt in your other converter?
https://rabbitboots.com/blog/2018/05/04/maze-minders-bitsy-to-zzt/
would "sharp" help it convert to 8bit? https://github.com/lordofduct/BitsySharp

Currently, there is no option to hide the character name, but it shouldn't be very difficult to implement.
Converting to ZZT sounds like a cool idea, and it is looks possible, but the results would be limited, mainly since the character set is not redefinable; anyway, the suggestion has been registered for later (https://github.com/haroldo-ok/bitsy-converter/issues/17)
Using BitsySharp to convert it to 8 bit platforms wouldn't help much, since the language is mostly designed for more robust platforms, and while there exist C# compilers targeting 8 bit platforms, they only implement a subset of the language/API. and BitsySharp probably isn't designed with those limitations in mind.

ah i see! great. Yes please keep me posted about character name hide (or way to change it each time character speaks) as im starting to prototype more and more in blocklyvn8bit :)

also (unrelated to char name, but to text in general) is there a way to have the text and black bg partially show the picture below? like 50 percent transparent? thanks be well.

Hello,
Unfortunately,  the targeted platforms don't have support for translucency.

got it. I can make the jpg with the text included as a work around if need be. :)

That could work, depending on how the image is tailored, but you must keep in mind the color limitations

ah yes thanks for reminder. I like how blocklyvn8bit has a bigger picture background than say "DAAD"
https://github.com/daad-adventure-writer/daad but i notice DAAD has text under...is there a way to
maybe move the text down to bottom in blocklyvn8bit to make the picture look bigger/more visual.
Keep up nice work!

Good idea; it would certainly be nice for the user to be able to configure the visual layout. Added to the "todo" list: https://github.com/haroldo-ok/BlocklyVN8bit/issues/20

for the logic I have it so when user presses 1 goes to a dif bg then if presses 2.. but then the options 1/2 show up again...
how can I progress like if someone presses 1 then the option to press 3 to go to bg3, then 7 to go to bg7 and not go back? thanks

Hello;
In order to prevent the user to go back to a previous choice, it would be necessary to set some variable to identify that the choice was used and put the option inside an "if" block; this would allow to show or hide options dinamically.
There currently isn't an "end" option; one alternative would be to create a block that keeps looping to itself.
As for menus with large amount of options, the application isn't currently capable of handling those.

hi i understand the idea of a loop as a way to kinda end the game in the screen the person is in :)
Ill look into how to see if variables was used. as far as options for large menus, can letter variables be used?
like if condition = a, jump to another scene.. this would give 26 options at least !

The main problem would lie in fitting all the options on the screen; maybe adding some scrolling mechanism to the menu would be a more realistic option.

ah sorry i wasnt clear i mean like every new screen 2 more new options (so only 2 or 3 options per scene)... keep on gaming! :)

building to test prg is showing blue lines for pictures...is there any format i need the pictures to work better?

text works fine...

AFAIK, for BlocklyVN8Bit, it must be valid a 320 x 200 PNG image. The 8bitunity library also places further restrictions, but BlocklyVN8Bit should, in theory, automatically convert an generic PNG to the more strict format that 8bitunity requires.
Did some error appear during the build process?

thanks that fixed it, it went to 202 pixels some how! I didnt see any errors... do the images for the portraits have to be smaller/another size? happy new year!

That's weird.. BlocklyVN32x, which BlocklyVN8Bit was based on, used a fixed resolution of 320 x 202; maybe there exists some remaining code that would be still doing that, under some circunstances? That would certainly be a bug.
As for the portraits, BlocklyVN8Bit should be automatically resizing them to fit the screen height, should they become too tall. Of course, there's always the possibility of there being some bug; if you want to resize the portraits manually, you should try to keep them smaller than 200 pixels, but, again, the tool should be resizing them automatically.


Update entry-points.md

Update Concept (documentation): We are telling webpack that we would like an output file with filename: [name].bundle.js

Thanks!


h5netcdf version 1.0

As recently brought up by @shoyer in https://github.com/h5netcdf/h5netcdf/pull/110#pullrequestreview-679253913, h5netcdf is approaching version 1.0 release. With the recent developments (eg. phony_dimensions, dimension scale handling and many fixes) the overall alignment with netcdf4-python was greatly improved.
There are still some incongruences and incompatibilities between h5netcdf and netcdf4-python. Some of them can and should  be addressed before version 1.0.
This issue should track all issues, pull requests and other missing things, that need to be tackled before version 1.0 is released. I'm starting with those I can contribute to.

[x] Issue #88 -> PR #104 + PR #112 (dimension scales)
[x] Issue #98
[x] Issue #52 (align with netcdf4 chunk-size heuristics) -> resolved by #127
[x] Issue #36 (isunlimited()-method) #135
[x] Issue #23 (masking)  -> will be resolved by PR #103 and #125
[x] PR #114 (issue & PR templates)
[x] API documentation
[x] rename master -> main
[x] Add Changelog.rst to source distribution #123
[x] #116
[x] #129
[x] #134, #135
[x] Issue #89, #161 --> PR #162, #163
[ ] Issue #165, PR #166, How does netcdf-c recognize netCDF4 format
[x] #167
[x] #168

No love for #116? :cry:

@dionhaefner I'll put it on the list.

@shoyer I took the chance to release 0.14.0 with the recent changes, to have it into the wild before getting to 1.0. The API/documentation is the last point on this list for version 1.0. The due date is still end of March which should work.

I've created a first version of documentation (currently available on my fork, https://kmuehlbauer.github.io/h5netcdf-docs/).
I'll have a PR ready the next days.
@shoyer It would be great if you could have a glance on the rendered docs. Also others are invited to have a look. Any comments appreciated.

Things move along more or less smoothly. Version 0.15.0 is out now, adding the new documentation only. The documentation is now available via github pages https://h5netcdf.github.io/h5netcdf/.
Please note that h5netcdf-version 1.0 is due 31st of March 2022 in about two weeks from now. If there are any problems which should get fixed before the 1.0 release please open issues.
ping @drew-parsons regarding packaging at debian.

There is one last blocker which need to be ruled out.
In #165 we've identified a major problem with regard to writing standard conforming files. A possible solution was implemented and merged in #166.
Additionally a discussion was initiated over at Unidata How does netcdf-c recognize netCDF4 format to get to the bottom of this and come up with a future proof solution. If you have additional thoughts on that please join the discussion.
As a consequence we might have to postpone h5netcdf 1.0 until that discussion comes to a conclusion.

The new documentation page looks great!
My main suggestion would be to switch around some content between the homepage and the "Overview" page. Right now the homepage talks mostly about the history of the project, but users are probably more interested in information from the "Overview", like the "Why h5netcdf" section. "History" could go in a less prominent location.

With regards to identifying conforming netCDF files, I think your solution in #166 is about as well as you could hope to do. I don't think this should really be a blocker for h5netCDF 1.0. In my opinion, the NetCDF4 file format should always have required some explicit identification, but that was not the case originally.

With regards to identifying conforming netCDF files, I think your solution in #166 is about as well as you could hope to do. I don't think this should really be a blocker for h5netCDF 1.0. In my opinion, the NetCDF4 file format should always have required some explicit identification, but that was not the case originally.

Thanks, then I'd suggest we just move along with version 1.0 and adapt to a possible solution when https://github.com/Unidata/netcdf-c/discussions/2258 is resolved.

We are finally approaching the release date (31st of March). There is the preparation PR #168 with some final changes. This PR will be merged later today to get a chance to see the docs build correctly etc.
Tomorrow would be the day for any last minute fixes. So if there is any immediate need to add changes/fixes please respond in time.
Final steps on Thursday:

change Development Version to Version 1.0.0 (March 18th, 2022) in CHANGELOG.rst
adapt last sentence in https://h5netcdf.org/#history to reflect release
update CI sphinx-build to only deploy on release
create release

Sad this happens, but the PyPI-upload failed. I'll investigate.

:tada: :rocket: We have just released h5netcdf version 1.0.0 :rocket: :tada:

h5netcdf 1.0.0 on PyPI
h5netcdf docs on h5netcdf.org

Many thanks to all who have contributed in one way or the other to make this happen, this is also your achievement. :1st_place_medal:
:heart: Huge thanks from my side to Stephan for all his dedication and love for h5netcdf. BTW, @shoyer h5netcdf does not have some advertising channel, where we could announce this milestone? :mega:
Looking forward to a healthy future for h5netcdf. :four_leaf_clover:


Adding transparent PNG image falls behind the PDF form elements.

When the .png transparent image is added to existing PDF Document with pdf form elements - it is rendered behind the pdf elements (like z-order problem). It should be possible to force any added image to be on top of all existing elements. I did it with iText (overlay) and it worked. Here is a piece of code I used to add image with pdf-lib:
const imgName = "Img_" + getUniqueNum();
const [img, imgDims] = pdfDoc.embedPNG(imageUint8Array);
  let contentStream = pdfDoc.createContentStream(
    drawImage(imgName, {
      x: posLeft,
      y: posBottom,
      width: tagWidth,
      height: tagHeight
    })
  );

  const pages = pdfDoc.getPages();
  const page  = pages[pageIndex];

  page.addImageObject(imgName, img).addContentStreams(pdfDoc.register(contentStream)).normalizeCTM();

The resulting screenshot is attached.
Thanks,
Andrei.

Hello @andazin. I'm not sure why this is happening. Are you able to share the document before and after modification with pdf-lib? If so, I can dig into this and try to figure out the cause, and how it might be fixed.

Andrew.
Thank you for reaching out.
The attached are the original document and 2 others with transparent PNG
and non transparent JPEG inserted.
It is not unique to the only this one document, but also to the ones with
PDF form elements.
Please, let me know if you need some other samples or help - I am more than
happy to contribute to fixing this amazing library.
Thanks,
Andrei Razine.
On Wed, Oct 10, 2018 at 2:08 PM Andrew Dillon<EMAIL_ADDRESS>wrote:

Hello @andazin https://github.com/andazin. I'm not sure why this is
happening. Are you able to share the document before and after modification
with pdf-lib? If so, I can dig into this and try to figure out the cause,
and how it might be fixed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Hopding/pdf-lib/issues/35#issuecomment-428673721, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABUl6CYEclo__IUjB_VEoBMo2Ch8JQSpks5ujjecgaJpZM4XNR2j
.

@andazin I'm unable to find the PDFs you attached, either in my email inbox or on the GitHub thread itself. Did you perhaps forget to attach them? If you're sure you attached them, can you try leaving a comment directly on the GitHub website (instead of using email), and attaching the PDFs to that?

01-Original.pdf
JPEG-Inserted.pdf
PNG-Inserted-01.pdf
PNG-Inserted-02.pdf
I just added the Original PDF and the result of adding different images.

I'm going to close this for now. But, please feel free to reopen it if you're still interested! (I certainly am. I'm very curious how iText was able to accomplish this).

If your trying to fill out the form fields, there’s a better approach than applying images on top of them. I can provide an example of how to do this with pdf-lib.

I would really appreciate an example if you have some time.

function getAcroFields(pdfDoc) {
  if (!pdfDoc.catalog.get(PDFName.of('AcroForm'))) return [];
  const acroForm = pdfDoc.context.lookup(pdfDoc.catalog.get(PDFName.of('AcroForm')));

  if (!acroForm.get(PDFName.of('Fields'))) return [];
  const acroFields = pdfDoc.context.lookup(acroForm.get(PDFName.of('Fields')));

  return acroFields.array.map(field => pdfDoc.context.lookup(field));
}

function createPDFArray(array, pdfDoc) {
  return array.reduce((array, value) => {
    array.push(value)
    return array
  }, new PDFArray(pdfDoc.context))
}

function createPDFDict(dict, pdfDoc) {
  return Object.entries(dict).reduce((dict, [key, value]) => {
    dict.set(key, value)
    return dict
  }, PDFDict.withContext(pdfDoc.context))
}

function findAcroFieldByName(pdfDoc, name) {
  const acroFields = getAcroFields(pdfDoc)
  return acroFields.find((acroField) => {
    const fieldName = acroField.get ? acroField.get(PDFName.of('T')) : {}
    return !!fieldName && fieldName.value === name
  })
}

function fillAcroTextField(
  pdfDoc,
  acroField,
  fontObject,
  text,
  fontSize = 15,
) {
  const fieldRect = acroField.get(PDFName.of('Rect'))
  const fieldWidth = fieldRect.get(2).number - fieldRect.get(0).number
  const fieldHeight = fieldRect.get(3).number - fieldRect.get(1).number

  const appearanceStream = pdfDoc.register(
    PDFContentStream.of(
      createPDFDict({
        Type: PDFName.of('XObject'),
        Subtype: PDFName.of('Form'),
        BBox: createPDFArray([
          PDFNumber.of(0),
          PDFNumber.of(0),
          PDFNumber.of(fieldWidth),
          PDFNumber.of(fieldHeight),
        ], pdfDoc.context),
        Resources: createPDFDict({
          Font: createPDFDict({
            FontObject: fontObject
          }, pdfDoc.context)
        }, pdfDoc.context),
      }, pdfDoc.context),
      drawLinesOfText(text.split('\n'), {
        color: { type: ColorTypes.RGB, red: 0, green: 0, blue: 0 },
        font: 'FontObject',
        size: fontSize,
        rotate: degrees(0),
        xSkew: degrees(0),
        ySkew: degrees(0),
        x: 2,
        y: fieldHeight - 13,
        lineHeight: fontSize,
      })
    ),
  )

  acroField.set('V', PDFString.fromString(text))
  acroField.set('Ff', PDFNumber.of(1))
  acroField.set('AP', createPDFDict({ N: appearanceStream }, pdfDoc.context))
}

const fillInField = (fieldName, text, fontSize) => {
  const field = findAcroFieldByName(pdfDoc, fieldName)
  if (!field) throw new Error(`Missing AcroField: ${fieldName}`)
  fillAcroTextField(pdfDoc, field, StandardFonts.Helvetica, text, fontSize)
}

fillInField('Nom et prénom', 'Mario')

I've got to this point, it took quite some time, but now I'm stuck on this error:
TypeError: pdfDoc.register is not a function

I don't know how to replace the register function, to make the whole code work.
Also, could you tell me how to check a box please?

Hello @nesk!
It looks like the example you are referencing was created for an old version of pdf-lib. Here's an example that should work with the latest version of the library: https://github.com/Hopding/pdf-lib/issues/205#issuecomment-568938999
There should be some issues about toggling form field check boxes. Here's one I was able to dig up that might be helpful: https://github.com/Hopding/pdf-lib/issues/109#issuecomment-568484109

Thank you @hopding!


Backport swift.yml changes to kilo

This PR backports the following commits from master to kilo:
13ddcb5 allow for mass when not setting up swift
3804f0e Fix typo in swift.yml
Closes issue #172

:+1:


Support React 17

We're using React-SearchKit which depends on react-overridable, which needs React <= 16.
Our app runs okay on React 17 forcefully installing react-overridable with npm install --force. I also tried to upgrade react-overridable to require React 17 ("react": "^17.0.2") and run npm run test with positive results.
Is there something else I can check to be sure we can upgrade?

PR welcome :) We use react 17 in indico so no changes needed

Great, I opened #14


Word Embedding Question

I am trying to run the Example 1 with word embeddings using the following code:
embeddings = Embeddings({"path": "word-vectors/GoogleNews-vectors-negative300.magnitude",
"storevectors": True,
"scoring": "bm25",
"pca": 3,
"quantize": True})
sections = ["US tops 5 million confirmed virus cases",
"Canada's last fully intact ice shelf has suddenly collapsed, forming a Manhattan-sized iceberg",
"Beijing mobilises invasion craft along coast as Taiwan tensions escalate",
"The National Park Service warns against sacrificing slower friends in a bear attack",
"Maine man wins $1M from $25 lottery ticket",
"Make huge profits without work, earn up to $100,000 a day"]
print("%-20s %s" % ("Query", "Best Match"))
print("-" * 50)
for query in ("feel good story", "climate change", "health", "war", "wildlife", "asia", "north america", "dishonest junk"):
# Get index of best section that best matches query
candidates = embeddings.similarity(query, sections)
uid = np.argmax(candidates)
print("%-20s %s" % (query, sections[uid]))

But I am getting the following error:
Traceback (most recent call last):
File "2.py", line 24, in
candidates = embeddings.similarity(query, sections)
File "/home/vyasa/.virtualenvs/txtai/lib/python3.6/site-packages/txtai/embeddings.py", line 228, in similarity
query = self.transform((None, query, None)).reshape(1, -1)
File "/home/vyasa/.virtualenvs/txtai/lib/python3.6/site-packages/txtai/embeddings.py", line 179, in transform
embedding = self.model.transform(document)
File "/home/vyasa/.virtualenvs/txtai/lib/python3.6/site-packages/txtai/vectors.py", line 155, in transform
weights = self.scoring.weights(document) if self.scoring else None
File "/home/vyasa/.virtualenvs/txtai/lib/python3.6/site-packages/txtai/scoring.py", line 133, in weights
weights.append(self.score(freq, idf, length))
File "/home/vyasa/.virtualenvs/txtai/lib/python3.6/site-packages/txtai/scoring.py", line 217, in score
k = self.k1 * ((1 - self.b) + self.b * length / self.avgdl)
ZeroDivisionError: float division by zero
Do I need to do something with the word embeddings before I can use it for similarity search ?

Thank you for taking the time to write an issue.
BM25 scoring requires a pass over the data before it can be used. If you add the following line before running the queries, it should work. With this demo dataset, it will pretty much be the same as average embeddings.
embeddings.scores([(uid, text, None) for uid, text in enumerate(sections)])

Closing this issue, re-open if the issue still persists.