082117: Build errors....

Restoring NuGet packages...
To prevent NuGet from restoring packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages during build.'
1>------ Rebuild All started: Project: CGM.Communication, Configuration: Debug Any CPU ------
1>Common\Serialize\SegementHandler.cs(10,7,10,35): warning CS0105: The using directive for 'CGM.Communication.Extensions' appeared previously in this namespace
1>Data\Repository\PumpRepository.cs(82,27,82,38): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.
1>Data\Repository\NightscoutRepository.cs(29,27,29,44): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.
1>Data\Nightscout\UploadLogic.cs(241,28,241,41): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.
1>Extensions\ByteExtension.cs(49,17,49,25): warning CS0219: The variable 'KEY_SIZE' is assigned but its value is never used
1>CGM.Communication -> C:\Dev\CGM.NET.NET standard\CGM.Communication\bin\Debug\netstandard1.4\CGM.Communication.dll
1>Successfully created package 'C:\Dev\CGM.NET.NET standard\CGM.Communication\bin\Debug\CGM.Communication.1.0.0.nupkg'.
1>Done building project "CGM.Communication.csproj".
2>------ Skipped Rebuild All: Project: CGM.Uwp, Configuration: Debug x86 ------
2>Project not selected to build for this solution configuration
3>------ Rebuild All started: Project: CGM.Uwp.BackgroundTask, Configuration: Debug Any CPU ------
3>C:\Dev\CGM.NET\CGM.Uwp.BackgroundTask\Nightscout.cs(6,7,6,15): error CS0246: The type or namespace name 'GalaSoft' could not be found (are you missing a using directive or an assembly reference?)
3>C:\Dev\CGM.NET\CGM.Uwp.BackgroundTask\Nightscout.cs(15,15,15,21): error CS0234: The type or namespace name 'Models' does not exist in the namespace 'CGM.Uwp' (are you missing an assembly reference?)
3>C:\Dev\CGM.NET\CGM.Uwp.BackgroundTask\Nightscout.cs(50,32,50,46): error CS0246: The type or namespace name 'BayerUsbDevice' could not be found (are you missing a using directive or an assembly reference?)
========== Rebuild All: 1 succeeded, 1 failed, 1 skipped ==========

hmmmm... sometimes I do not understand github..... well, I have removed the backgroundtask-project and it should build now.

This is fixed.


R&D: @TestVisible alternative

Can an attribute contain a Object with fns (same design as the "test" object in Greased) provide a way to see private attributes and functions when populated.
If so, it could be populated only in test use and this would provide the same access model as @TestVisible
This needs to be testing and built if it works.

Something like @TestVisible would be awesome indeed. I don't think we can achieve it in a honest way. I'd be fine with that limitation for greased for the time being.
explanation:
If I understood correctly your approach seems to work around the issue in the literal sense. We wouldn't be testing the actual private attribute in the end. It also seems to me we would be asking developers to comply to certain ways of coding their components (again, if I understood correctly) in order to be testable with greased.

I agree. We recently discovered a nice alternative. That is to create another component which extends the component being tested and expose API fns from there. This component would be test only i.e. not deployed.
Once you have api fns in the sub-component, you have access to all the attributes and helper fns so now you can interact with them and return them if necessary. This has worked for us this week so I'll add it to the readme soon.


How to skip violations for Laravel's anonymous migration classes

Hello,
Here are my deptrac config files:
project-dir/deptrac-config/
├── deptrac.baseline.yaml
└── migrations.yaml

# deptrac.baseline.yaml
deptrac:
  skip_violations:
    ../database/migrations/workspaces/2022_05_05_130121_storage_config_to_settings.php:
      - App\Modules\Settings\Models\Settings

# migrations.yaml
imports:
  - deptrac.baseline.yaml

deptrac:
  paths:
    - ../app
    - ../database/migrations
  exclude_files:
    - '#.*test.*#'
  analyser:
    types:
      - "class"
      - "use"
      - "file"
  layers:
    - name: App
      collectors:
        - type: className
          value: .*App\\.*
    - name: Migration
      collectors:
        - type: directory
          value: ../database/migrations
  ruleset:
    Migration: ~

But when I run:
php deptrac.phar analyse --config-file=deptrac-config/migrations.yaml

It is not skipping the skip_violations and it says:

 --------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Errors
 --------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Skipped violation "App\Modules\Settings\Models\Settings" for "../database/migrations/workspaces/2022_05_05_130121_storage_config_to_settings.php" was not matched.
 --------------------------------------------------------------------------------------------------------------------------------------------------------------------

Do you know what did I miss? Thank you!

Does https://github.com/qossmic/deptrac/issues/1073#issuecomment-1378951045 help?

A repro repo would be nice, but at least, can you give the output you get that shows the violation?


Add next.js plugin

Adds a next.js plugin that exposes the webpack plugin.

Heya! Thanks for the PR!
Have you seen the section in the readme? https://github.com/wooorm/xdm#next
It’s such a few lines of code, that I’m not sure whether it’s worthwhile to add a plugin.
Plus, now folks need to learn this plugin’s interface, instead of learning webpack + xdm.

Oh! I didn't notice this in the readme somehow. The issue is that webpack(config){} you define there will clobber any other webpack config modifications any other plugins define. The plugin interface unfortunately has some sharp edges like that, and isn't all that well documented. Most next.js users I'd wager don't ever want to have to manually form / think about a webpack config -- especially since it's not intuitive how that plugin interface works.

But this is how the next-mdx plugin works too? https://github.com/vercel/next.js/blob/canary/packages/next-mdx/index.js

You're missing the last line that checks if the input object has a webpack field:
module.exports = {
  // Support MDX files as pages:
  pageExtensions: ['mdx', 'tsx', 'ts', 'jsx', 'js'],
  // Support loading `.mdx`:
  webpack(config) {
    config.module.rules.push({
      test: /\.mdx$/,
      use: [{loader: 'xdm/webpack.cjs', options: {}}]
    })

    return config
  }
}

vs
module.exports = (pluginOptions = {}) => (nextConfig = {}) => {
  const extension = pluginOptions.extension || /\.mdx$/

  return Object.assign({}, nextConfig, {
    webpack(config, options) {
      config.module.rules.push({
        test: extension,
        use: [
          options.defaultLoaders.babel,
          {
            loader: require.resolve('@mdx-js/loader'),
            options: pluginOptions.options,
          },
        ],
      })

      if (typeof nextConfig.webpack === 'function') { // <- this one
        return nextConfig.webpack(config, options)
      }

      return config
    },
  })
}

That’s more about what else folks put in there though, no? And they still can do that? https://nextjs.org/docs/api-reference/next.config.js/custom-webpack-config

Yeah, the only issue is that your example only tends to work if yours is the base config that all plugins are being added to.
If you are a next.js user and, for example, you use another example like the one that's in this repo, it's not immediately obvious how they are combined (by merging the webpack functions). It's fine if you're okay with that, it's just something I found rather hard when I was getting to know next.js -- adding this system then means understanding the plugin interface and understanding webpack.

Yeah, the only issue is that your example only tends to work if yours is the base config that all plugins are being added to.

I’m explicitly suggesting that folks add this to their next.config.js, so it should always be the base config?

It's fine if you're okay with that, it's just something I found rather hard when I was getting to know next.js

That’s understandable!

adding this system then means understanding the plugin interface and understanding webpack.

The reason I prefer not adding plugins for every static site generator that exists (there are so many!!) is that I want to prevent an exponential gulp/grunt problem from happening. It’s hard to maintain those glue projects (e.g., this PR missing docs, tests, and won’t work at all because xdm/package.json is ESM). And it’s a superfluous (IMO) abstraction layer.
I want folks to learn about the two important layers: xdm and Next (or whatever else they want to use). Not also have to learn that layer in between
I appreciate your PR, but I think it makes more sense as docs where folks can copy/parse those few lines of code. Feel free to maintain it elsewhere though. And: docs improvements on xdm + Next are super welcome!

I’m explicitly suggesting that folks add this to their next.config.js, so it should always be the base config?

The tricky thing comes if you had, say two, like this:
// suggested config A:
module.exports = {
  // Support MDX files as pages:
  pageExtensions: ['mdx', 'tsx', 'ts', 'jsx', 'js'],
  // Support loading `.mdx`:
  webpack(config) {
    // do some fancy stuff with webpack
   config.modules.yyy.doSomething();
   config.modules.xxx.doSomething();
    return config
  }
}
// suggested config B:
module.exports = {
  // Support MDX files as pages:
  pageExtensions: ['mdx', 'tsx', 'ts', 'jsx', 'js'],
  // Support loading `.mdx`:
  webpack(webPackConfigDifferentName) {
    webPackConfigDifferentName.module.rules.push({
      test: /\.mdx$/,
      use: [{loader: 'xdm/webpack.cjs', options: {}}]
    })

    return config
  }
}

Now, unless you understand webpack internals and the next.js plugin interface, it might not be obvious that you need to (1) rename the variable name, and (2) concat the two webpack() bodies to make this work.
I understand your reluctance to support all those, though. Just wanted to make sure it was understood :)

Do you have an example of another integration? I can’t find zemndm and I’m not completely seeing the problem here

Ah it’s okay. Maybe it’ll come up again, no worries!
On Sat, 27 Mar 2021 at 5:58 pm, Titus @.***> wrote:

Do you have an example of another integration? I can’t find zemndm and
I’m not completely seeing the problem here
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/wooorm/xdm/pull/33#issuecomment-808770454, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABDJGLV4BIOUV7NQTFZSKZDTFYMFRANCNFSM4Z5C3TFA
.


Close statement client after consuming the current results

This PR fixes the issue that the presto-cli sometimes does not clear the console properly on Ctrl-C as the statement client was closed immediately and the current results could not be consumed (which basically made console.resetScreen() in the finally block a noop).

presto:nyigitbasi> ... my query ...;

Query 20151118_194430_00070_5qcf7, RUNNING, 1 node, 102 splits
http://localhost:8080/v1/query/20151118_194430_00070_5qcf7?pretty
Splits: 102 total, 0 done (0.00%)0 done
CPU Time: 0.0s total,     0 rows/s,     0B/s, 0% active
Per Node: 0.0 parallelism,     0 rows/s,     0B/s
Parallelism: 0.0
0:03 [0 rows, 0B] [0 rows/s, 0B/s]ows/s,     0B/s] [  <=>                                     ]

Query aborted by userOWS/s  BYTES  BYTES/s  QUEUED    RUN   DONE
presto:nyigitbasi>       0     0B       0B       0      1      0
  1.......R      0       0     0B       0B       0      1      0
    2.....S      0       0     0B       0B      68     32      0

I assume this fixes https://github.com/facebook/presto/issues/3666, no?

Yes, this should fix it.

Merged, thanks!


Bounds from literature

Load lower and upper bounds from the literature. I couldn't find a page on the internet with them, so we'll have to look on papers...

Check:
M. Yagiura, T. Ibaraki and F. Glover,
A Path Relinking Approach with Ejection Chains for the Generalized Assignment Problem,
European Journal of Operational Research, 169 (2006) 548-569.


fix: set noautocmd before opening border window

Currently noautocmd is not set (like for the popup window) when opening the border.
This leads to issue with other floats like Telescope.
Fixes Noice issue https://github.com/folke/noice.nvim/issues/11

Great, thanks!

Thanks! 😃


OCRC target

[ ] #3

[x] 1. Add custom OCR hotkey support
[ ] 2. Improve result GUI

[ ] 1. Transform MsgBox into Edit control (ReadOnly/Editable)
[ ] 2. Translate support
[ ] 3. Search support
[ ] 4. Type realtime transform support (Remain spaces/Remain wraps/Intelligent paragraph/Chinese punctuation/English punctuation/Intelligent Punctuation/...)

[ ] 3. Improve text format

[ ] 1. Intelligent paragraph
[ ] 2. Chinese punctuation
[ ] 3. English punctuation
[ ] 4. Intelligent Punctuation

[ ] 4. Add Mathematical formula support (via Mathpix)

Close due to the name changing of the branch.


A way to automatically scale the camera so that the currently visible object(s) fill the viewport

What problem does this solve or what need does it fill?
Setting up a camera to give a "full picture" of an object while being agnostic to the object's size and shape can be somewhat tedious.
What solution would you like?
This feature request was inspired by the VTK project, which has a ResetCamera() function and ResetCameraScreenSpace(). This makes it very easy to load in a mesh, set an initial camera view, and then let VTK scale everything for you so that your object occupies most of the screen space, which is great for rendering previews of a model (i.e. exporting images of a model, implementing some kind of "showcase" functionality, etc.).
What alternative(s) have you considered?
Implementing this myself by calculating the bounding box of the object(s) and setting scale appropriately.
Additional context
Aforementioned link to VTK project.

I don't have experience with VTK but I do with Unity's asset preview system.
It is worth considering that there may be a future use case where multiple objects need to be rendered within a camera's view.
Scaling an object may work for a single object, but can become cumbersome with lots of child/offset objects if there are relative nested scales. (Can result in non-uniform scaling visual bugs). On the other hand, scaling the camera can lead to clipping.
I think the way Unity does this is it renders an empty scene with just the object(s) being previewed, the camera is then moved to the outside of the cumulative bounding box and offset by a distance. When a preview is hovered over then the user can rotate the model and use the scrollwheel to adjust the distance offset. Only one preview scene is active at a time, other previews are cached as static images until selected.
It also seems to do something to orient the object so visible faces face the camera more often than not, in cases where mesh normals may not be visible.
gltf only allows for units in meters so this may help creating asset previews directly of gltf files. I'd imagine there is some sort of Sketchfab style viewport in existence somewhere.
Having a built-in function to match bounds of the camera to an object's bounds is useful in other contexts and a good starting point.

@TolinSimpson VTK's implementation is entirely camera-based and does not scale objects. Looking at the code for ResetCamera(), an overall bounding box is calculated by taking the extrema of all bounding boxes of all objects ("properties" or "props" as VTK calls them) using the ComputeVisiblePropBounds() function. The camera's position is calculated using viewing angles and its focal point is set on the center of the new overall bounding box. Then the camera's up vector is reset if the new view plane normal is parallel to it.
I may take a stab at my own implementation of this for bevy if I get some spare time.

If no-one is working on it, I may give it a try. I am learning rust, so a good opporutnity for me.


Dash in region name

Hi! Dash in state name does not work for Russian regions:
https://github.com/louis-e/arnis/blob/main/src/getData.py#L27
I've tested it here: https://overpass-turbo.eu/
This one works:
[out:json];
area[name="Иркутск"]->.city;
area[name="Иркутская область"]->.state;
area[name="Россия"]->.country;
way(area.country)(area.state)(area.city)[!power][!place][!ferry];
(._;>;);
out;

And this one(as replace in code do) doesn't
area[name="Иркутская область"]->.state;
Link to the city: https://www.openstreetmap.org/relation/1430614
Not sure is it Russia states problem or a global one, maybe Denmark regions have the same issue: https://github.com/louis-e/arnis/issues/12

Hi there, thanks for reporting this! Yeah, I've seen that this is the case for a lot of countries. I'm sometimes confused with the OSM naming standards, seems like the dash is just required in some cases. Will adjust this in the code and in the Readme. Thanks a lot!


dbSta: enable string redirection in openroad to function with with_output_to_variable

Fixes:

with_output_to_variable does not work in OpenROAD like it does in OpenSTA because the functions that enable this behavior is overridden for the logger. This enables this redirection to have the same behavior as OpenSTA.

What command would show the effect of this change?

with_output_to_variable test {check_setup}

In this case, instead of printing the output the text is stored in $test
A quick example:
with_output_to_variable test {puts "1234"}
puts "Text in variable: $test"

Should print:
Text in variable: 1234

Currently the redirect doesn't work, so it outputs:
1234
Text in variable:


Support fine-grained logrotateAdditionalFiles intervals, with a separate logrotate conf file for each configured interval

In Singularity, we don't want to rely on logrotate(8) on Mesos agent hosts having support for hourly or finer-grained logrotate intervals. We therefore "fake" it by having SingularityExecutor write cron entries with schedules corresponding to those finer-grained intervals. These cron entries invoke logrotate -f to force rotation on the cron schedule.
Up until now, the only one of these "finer" intervals we supported in Singularity was hourly. We'd now like to support even finer intervals than that. However, Singularity up until now has written all these "cron-faked" hourly logrotate entries for a given Singularity Task to a single logrotate conf file. If we now add support for "cron-faked" rotation every five minutes, for example, we wouldn't want to write them into the same logrotate file as an hourly config, because then when cron calls logrotate -f on the file, it'll run both the hourly and the five-minutely configs.
This PR addresses this problem by separating out the cron-faked logrotate conf files by interval. So now, if we have three logrotateAdditionalFiles in SingularityExecutor's configuration...
  logrotateAdditionalFiles:
  - filename: logs/a.log
    logrotateFrequencyOverride: HOURLY
  - filename: logs/b.log
    logrotateFrequencyOverride: EVERY_MINUTE
  - filename: logs/c.log
    logrotateFrequencyOverride: EVERY_MINUTE
  - filename: logs/d.log
    logrotateFrequencyOverride: EVERY_FIVE_MINUTES

...then we write three separate logrotate conf files:
/etc/logrotate.d/hourly/SomeSingularityTaskId.HOURLY:
    <logrotate config entry for a.log>

/etc/logrotate.d/hourly/SomeSingularityTaskId.EVERY_MINUTE:
    <logrotate config entry for b.log>
    <logrotate config entry for c.log>

/etc/logrotate.d/hourly/SomeSingularityTaskId.EVERY_FIVE_MINUTES
    <logrotate config entry for d.log>

...and the cron file now looks like:
/etc/cron.d/SomeSingularityTaskId.logrotate:
0 * * * * root logrotate -f -s /statefile /etc/logrotate.d/hourly/SomeSingularityTaskId.HOURLY > /dev/null 2>&1

* * * * * root logrotate -f -s /statefile /etc/logrotate.d/hourly/SomeSingularityTaskId.EVERY_MINUTE > /dev/null 2>&1

*/5 * * * * root logrotate -f -s /statefile /etc/logrotate.d/hourly/SomeSingularityTaskId.EVERY_FIVE_MINUTES > /dev/null 2>&1

NOTE: This PR changes the filename format for the conf files written to /etc/logrotate.d/hourly/ (from ${singularityTaskId} to ${singularityTaskId}.${logrotateInterval}, but this should be safe, because all changes are limited to the SingularityExecutor module. So existing tasks will undergo SingularityExecutor cleanups based on the old name format, and new tasks launched after this rolls out will use the new name format on both the write and cleanup paths.

@baconmania is this one still needed?

Yeah - we're still working on testing it


Logical links support for visual query builder

VQB has to support logical foreign keys and references. If we create joins based on logical foreign keys they have to work correctly.

This feature was implemented already. I've made a tiny fix for PostgreSQL hidden columns.

verified


Update README to Add downloads badges to packages table

This pull request introduces improvements to the README table as follows :

Incorporating download badges for enhanced visibility.
Sort the packages based on download statistics.

Hey @liliumorion thanks for your PR :heart:, can you please add some description to this PR, and explain your changes :pray:.

Hey @liliumorion thanks for your PR ❤, can you please add some description to this PR, and explain your changes 🙏.

Done.


Improve EU referendum homepage link copy for SRs.

Screen reader users have the option to navigate by jumping between anchor tags and reading out the content. "More information" does not provide a lot of context about what the link does.
There is another equivalent PR open on frontend: https://github.com/alphagov/frontend/pull/945
After

What does the external link tracking event look like now? The event label might have changed?

I don't have enough experience using GA to know off the top of my head if it uses the anchor tag content or the href to group the events. Good question though, who might be in a better position to answer?

If you right click the link to open in new tab, then check the original tabs network requests, you should see a post to collect. In the payload you'll see the request parameters, specifically we want to check what this changes to: &el=More%C2%A0information

That is indeed changed:
// snip
&ec=External%20Link%20Clicked
&ea=https%3A%2F%2Fwww.eureferendum.gov.uk%2F
&el=More%C2%A0information%20about%20the%20EU%20referendum
// snip

So both the address and the label is passed through on the request payload, and the label has changed.

I think that's fine, it'll be a new event type but we should be able to combine them for numbers.


Fallible deserialization documentation is a bit sparse

There are a few things that could be improved in the documentation for the following things:

trait Outgoing: Better explain how this trait relates to serde's traits
ruma_api!: Explain the concept of fallible deserialization before jumping to ruma_api::Outgoing
Outgoing derive macro: Make it clear that #[wrap_incoming] and #[wrap_incoming(Type)] without the "with" part are (only) useful for fallible deserialization of nested structures.

The Outgoing trait has been removed.


Add breaking change for SSE comparison methods

Fixes #17838.

Thanks Tom! (Are you sure you want to own the /includes/ folder? ;) )

Definitely not, I'd like to relinquish ownership to the team. 😄

Definitely not, I'd like to relinquish ownership to the team. 😄

Fine with me, I'm sure with others too.


Fix a-la-carte components and eslint for Nuxt v2

I noticed a few issues from @Codefa's PR #56 and spent a little time fixing all the various errors that were appearing in Nuxt v2.
To test this PR, just specify the nuxt2 branch from my repo.
$ vue init XanderLuciano/nuxt#nuxt2 my-project

Error free a-la-carte :)

This PR will resolve #56, #58, and #59.
As well as resolving issues #54 and #37.

Note: It's recommended to use vuetify-loader for vuetify from 1.3.0 on - https://github.com/vuetifyjs/vuetify/issues/3496#issuecomment-427077294

@XanderLuciano Please merge these fixes to your forked repository let me test your forked vuetify/nuxt repository

Merged to XanderLuciano/nuxt:master
You can test with the following command:
$ vue init XanderLuciano/nuxt my-project

This was wrong. The context API shown above is separate form the extend build context.

This was wrong. The context API shown above is separate form the extend build context.

See nuxt starter template is deprecated must use create-nuxt-app

That's fine, I just didn't want to lead any future googlers down the wrong path over such a small misunderstanding and simple 3 line fix.


Implement Streaming Tables in CreateRule

Replace the current simple tables in CreateRule by the tanstack tables that get their data from the streaming hooks.

This is a non-issue now. It was fixed behind the scenes over different PRs.


Task/A2patel submission

Assignment 2 Parth Patel Submission

You need to put images in your README.md submissions.  This is not optional.  Last chance to rectify this.


[Issue 2304] Update showing estimated withdrawal time

Related issues:
#2304

🚀 Deployed on https://pr-2309--sw-web-runner.netlify.app


v2 tag

@KevinRohn, can you make a v2 tag in this repository which will point to the latest v2 version of this action so we can use it in our workflows like this:
  - name: Get Release data of private repository
    uses: KevinRohn/github-full-release-data@v2

And there won't be any need to update all workflows when a non-breaking change is introduced.

Ok, I will have a look at it. I will let you know, when it`s done!

@kirillmorozov done.


Home Manager scripts should use run wrapper

As described in the documentation, scripts inside home.activation should include run before each effectual command so that they are not executed in dry-run mode.

Should printf and echo commands writing to stdout or stderr instead of to a file also be passed to the provided run function?

run is only necessary for commands which actually produce a change.
However, we should consider using this for debug output:

You can also use the provided shell function verboseEcho, which acts as echo when verbose output is enabled.

It may also be useful to restore the echo commands that were removed in #304, but using that function. I wasn't aware of it until now.

You can also use the provided shell function verboseEcho, which acts as echo when verbose output is enabled.

It may also be useful to restore the echo commands that were removed in #304, but using that function. I wasn't aware of it until now.

I added this to https://github.com/danth/stylix/issues/306.


some unmanaged tools break within interactive rez-env'd shell

For example, currently xdg-open breaks for me, which causes 'rez-context -g' to fail.
We need a general way to use a tool within a resolved environment if it is available in that env, otherwise fall back to the unresolved env. To do this, interactive rez-env sessions will have to store the pre-resolved env in a file - let's say, 'orig_environ.yaml' alongside the other tempfiles. Then, tools such as xdg-open could be run within this env, if not provided as a package tool in the rez'd env.

We've noticed this as well.  In our case meld is a good example.  We only
had a python 2.6 install so it fails in an environment that has resolved to
python 2.7.
Your solution suggests that every package would have to list every tool it
exposes?  Is that right?
On 19 May 2015 at 10:44, allan johns<EMAIL_ADDRESS>wrote:

For example, currently xdg-open breaks for me, which causes 'rez-context
-g' to fail.
We need a general way to use a tool within a resolved environment if it is
available in that env, otherwise fall back to the unresolved env. To do
this, interactive rez-env sessions will have to store the pre-resolved env
in a file - let's say, 'orig_environ.yaml' alongside the other tempfiles.
Then, tools such as xdg-open could be run within this env, if not provided
as a package tool in the rez'd env.
—
Reply to this email directly or view it on GitHub
https://github.com/nerdvegas/rez/issues/202.

First, I'm not suggesting that Rez create wrapper scripts on the fly or anything, so that running 'meld' in a rez'd env somehow calls meld in the original (pre-rez) environment. I think that's just going too far - at that point you may as well provide a meld package I think... or, probably better in this case, make 'meld' available in a suite, that way you don't have to include it in the request. I've done this in the past - we have a 'bootstrap' suite which provides a set of tools from outside rez'd environments.
I was considering the cases where Rez itself subproc's programs - such as when 'rez-context -g' is used. In this case the behaviour would be:

If the program is listed as a tool by any package in the current context, then run the tool directly within the rez'd env;
Otherwise, run the tool in the pre-rez'd env.

Two more things to consider here:

It might be useful to provide a new rez tool - 'rez-exec' maybe - that provides the same behaviour from the command line (perhaps with more options). So for eg, you could run "rez-exec meld" within a rez'd env, and it would follow the same rules mentioned above.

Another useful feature might be to have a configurable rez setting which, when enabled, causes suites and/or nested rez'd envs to use the pre-rez'd env as the starting point, rather than the current env. In effect this would cause suite tools / further rez'd envs to ignore any changes within the current rez'd env. How could you use this? You might create a 'meld' tool in an empty context within a 'bootstrap' suite that you keep on PATH. If this option were turned on, then you would always have a 'meld' binary available, which would effectively run outside of the current rez env. Of course there's the flipside problem - if you turned on this behaviour globally, there may be cases where you want to use a tool from a suite, but when you run that tool, other changes the user might have made to the current env (unrelated to rez) would disappear. Perhaps the setting would need to be stored on the suite rather than applied globally. A "++use+rez+env" option on the suite tool would be made available also, to override this setting.

Ok, that makes more sense!
Yes, rez exec sounds useful - although it reminds me of rez run which I think got dropped on the switch to rez 2.  exec sounds too much like it's going to run in the current environment thought.  rez revert (to revert the rez environment) or rez up (to go up a sub-shell)?

Yeah I'm not fond of 'rez-exec' either. But I don't like 'rez-up' or 'rez-revert' either! Suggestions:
rez-invoke
rez-native-invoke
rez-safe-exec
?


Integration of runner

This aligns the worker with the changes made at the node with respect to the runner and game-registry.  It also moves dependencies to the public repository from the private one.

Looks good! Nothing to add, except maybe updating the doc: https://github.com/ajuna-network/worker/blob/master/cli/demo_connect_four.sh#L4
CI is not yet building

Thanks.  Once building I will remove the draft.


fix (config) : Display helpful message when user tries to set okd preset on arm (#3389)

Fixes: Issue #3389
Relates to: Issue #3389
Solution/Idea
Fix #3389
Add additional handling in validatePreset method for failing the validation when okd preset is provided on arm architecture. Validation would fail with message directing user to use other preset values.
Proposed changes

Update validationPreset method with an additional check to fail when okd value is provided on arm architecture. It now checks for two conditions

whether provided preset value is valid (already existing validation)
whether okd is not provided on arm or arm64 architecture

Testing
:warning: A machine with arm architecture is required to test these changes

crc delete
crc config set preset okd (should fail with invalid value error)

Old behavior
When user tried setting okd preset on arm architecture, CRC allowed doing this:
crc : $ crc config set preset okd
To confirm your system is ready, and you have the needed system bundle, please run 'crc setup' before 'crc start'.
crc : $ cat ~/.crc/crc.json
{
  "consent-telemetry": "yes",
  "preset": "okd"
}

New behavior
Once these changes are merged, user would get error when he tries above action on arm architecture:
crc : $ crc config set preset okd
Value 'okd' for configuration property 'preset' is invalid, reason: preset 'okd' is not supported on amd64 architecture, please use different preset value
crc : $ cat ~/.crc/crc.json # Config file is not updated
{
  "consent-telemetry": "yes"
}

/ok-to-test


problem with mempool for AMPI programs

Original author: Celso Mendes
Original issue: https://charm.cs.illinois.edu/redmine/issues/57

I believe that there is a problem with mempool in Charm++ and it's affecting AMPI programs in some cases.
For current tests on Cray systems, using the Cray compiler (cce), we are having to build the codes with a line like
ampicc -o prog prog.c -dynamic -thread context -swapglobals -memory os-isomalloc ...
The reasons for having to use those options are:

-dynamic: we plan to invoke code that uses GPUs, and that requires dynamic linking
-thread context: as suggested by Nikhil, this fixes some problems that had been observed in the past
-swapglobals: this is the only feasible mechanism to handle globals with AMPI, as TLS would require static linking
-memory os-isomalloc: suggested by Gengbin; needed for migration without having to pack/unpack data

So, using those options, the example code from the Charm++ distribution (tests/ampi/migration/) breaks on a Cray system if it is compiled with an AMPI built with the Charm++ version from the GIT repository on Fe.23/2013. This error has been observed on JYC for both the mpi-crayxe and gemini_gni-crayxe layers of Charm.
However, that works fine if the AMPI used is built from the contents of the Charm GIT repository that existed on Feb.8/2013, prior to various modifications implemented on the mempool functionality. To obtain that older version, these commands were used:

git clone git://charm.cs.uiuc.edu/charm.git
git reset --hard 92515ffdd2b84839c8daa787706f606e1ab7227e                (this is a commit prior to the mempool changes)
edit file src/arch/mpi-crayxe/conv-mach.h to #define CMK_AMD64 1         (recent change from Phil; needed so that swapglobals will work)
edit file src/arch/gemini_gni-crayxe/conv-mach.h to #define CMK_AMD64 1  (similar to above)
build AMPI:  ./build AMPI mpi-crayxe --disable-charmdebug                (having PrgEnv-cray set, to use the Cray compiler)

On JYC, I left a snapshot of the error above, under directory ~cmendes/BUG-AMPI/ where there is a Makefile that builds the successful version of the program (built with the older Charm version, named 'charm-PHIL') and the buggy version (built with 'charm-git'). There is a copy of the outputs from execution on two JYC nodes. The error message (which can be seen on file run.git_out) is like
Stack walkback for Rank 1 starting:
[empty]0x5555b7ffffff   mempool_destroyXTTorus.h:204
Stack walkback for Rank 1 done
Process died with signal 11: 'Segmentation fault'
The results from successful executions of the same program are under file run.PHIL_out.
Hence, I strongly suspect that the error is being caused by those changes to mempool on Feb.8/2013.
-Celso

Original author: Nikhil Jain
Original date: 2013-03-06 18:38:24

mempool shouldn't be freed till the very end - however freeing mempool can get very tricky, and that is what consumed time :)

Original date: 2013-03-07 00:51:02

Celso says

I just tested on JYC, with the reported example and a few others,
and the new AMPI from today's repository after your fix works fine!


Support ignoring errors

We need to support ignoring certain types of errors, for example 412 that means the content has already been rerendered before CP got to it.
cc @wikimedia/services

Coverage decreased (-0.2%) to 94.813% when pulling 71cf768151ef1e49dc59a1dba6db3c946438bdef on Pchelolo:ignore into a42c8b179f8f3e1ce04362daa933542ea94a3678 on wikimedia:master.

:+1:

Coverage increased (+0.3%) to 95.228% when pulling 25e690f98bc624f62696b7ff76bc837588ba1750 on Pchelolo:ignore into a42c8b179f8f3e1ce04362daa933542ea94a3678 on wikimedia:master.

Puppet patch with the config changes: https://gerrit.wikimedia.org/r/#/c/295680/


Option for window.showOpenDialog to always use SimpleFileDialog (not just in browser)

Hi, the team and I working on the Azure extensions for VS Code have a lot of scenarios we would like be able to use this file picker through the window.showOpenDialog API.

Currently, afaik this is the file picker that is used in browser environments, and is called the SimpleFileDialog in the codebase. What we would love is if a property like useSimpleDialog?: boolean could be added to the OpenDialogOptions interface, that when true would force window.showOpenDialog to use the SimpleFileDialog instead of the native file dialog in all environments. We would also like to be able to control the title of the quick pick.
https://github.com/microsoft/vscode/blob/1bbe9cfd599ccb1bc1fa220ee05201add6d7c9db/src/vs/workbench/services/dialogs/browser/simpleFileDialog.ts#L103
The main reason we like the simple dialog over the native dialog is that no context or prompt can be given to the user with the native dialog. For example, we can't tell the user "Select the folder you'd like to deploy" while the dialog is shown. But we think this could be possible by using the SimpleFileDialog and the title of the quick pick.
Other things we like more about the simple dialog is that it is less disruptive when using it in a wizard. And it's the same across all operating systems.
cc: @isidorn

After discussing with @alexr00 we think this is not something we would like to expose to extensions because:

It would provide an inconsistent open dialog experience to the user
there is already a setting that lets the user decide if they want to use the simple file picker. If we let extensions choose which dialog to appear then we would sometimes not respect the setting.

So instead I suggest that we try to tackle your primary concern with the native dialog.
@alexweininger is the main problem that you can not control the title of the native dialog?
Your other two concerns:

Less disruptive when using as a wizard: for wizards you should use the quick pick API diractly and not the openDialog
Same across all operating systems: I think actually a native dialog is preferred since the app feels more native then and it is not like users are looking for consistency across OS. This is just how some VS Code UI behaves and is expected IMHO

@bpasero there is no Electron API to control title of Native File Dialog? Do you maybe have some ideas for workarounds such that the extension could give more context when opening the file dialog?

@isidorn there is a title option for native dialogs in Electron API but we have been setting this to the product name, for example:
https://github.com/microsoft/vscode/blob/02d4cb5383cc863f5c8aa496e107baf31f4da8d9/src/vs/code/electron-main/app.ts#L1057

@bpasero great thanks. The only problem I see is that on macOS the title of the native dialog is not even rendered anywhere. On Windows I see the title area of the open dialog though.
So a more fitting request might be to allow extensions to customise the title of the open dialog.

ping @alexweininger for my question


Set --no-document (--no-ri --no-rdoc) option in rvm_gem if gem installed from local sources

We use puppet-rvm to install rvm, ruby, and some gems from already existing gem files.
One of the gem is a legacy one and has broken documentation. In result, output of gem install gem-with-broken-docs.gem is always erroneous and puppet-rvm fails as soon as it processes this gem. Unfortunately, we cannot fix it and rebuild gem.
Initially I thought, that I can pass parameter like --no-documentation to rvm_gem, but :withopts param appears does not work for such cases.
A quick look at https://github.com/maestrodev/puppet-rvm/blob/maestrodev/lib/puppet/provider/rvm_gem/gem.rb code shows that in install method docs never installed for gem if :source param n/a. But in our case, we use :source param to point out to gem's location.
A simple code modification will solve issue:
if source = resource[:source]
  # ...
  case uri.scheme
  when nil
    # no URI scheme => interpret the source as a local file
    #command << source
    command << '-N' << source # --no-documentation if local file
  when /file/i
    command << uri.path
  when 'puppet'
    # we don't support puppet:// URLs (yet)
    raise Puppet::Error.new("puppet:// URLs are not supported as gem sources")
  else
    # interpret it as a gem repository
    command << "--source" << "#{source}" << resource[:name]
  end
else
  command << "--no-rdoc" << "--no-ri" <<  resource[:name]
end

Also, for consistency, it make sense to disable docs installation for all cases by default.
Another option is to add install/update options param to rvm_gem type.

I'm going to close this based on its age. If you can still reproduce it, please reopen.


Doesn't seem to register HDF5 1.14.2 as a version.

Had to roll back to 1.10.10 in order for hdf5-sys to register a version of HDF5 during the cargo build process.

Do you have the version string? In #243 I saw and implemented support for strings like <IP_ADDRESS>

I'm sorry. I don't understand what that means.

If you look in the H5pubconf.h header of the install, what is the value of H5_VERSION?

It is the same as this issue title "1.14.2"
/* Version number of package */
#define H5_VERSION "1.14.2"

I'm also hitting this issue - is it correct that hdf5-rs is currently incompatible with HDF5 1.14.2?

I'm having the same problem. On Arch linux 6.5.8 with the latest hdf5 1.14.2-1 package installed, cargo fails when building a project with hdf5 0.8.1 as a dependency. cargo build ends with the following error:
  Found HDF5 pkg-config entry
      Include paths:
      - "/usr/include"
      Link paths:
      - "/usr/lib"
  Located HDF5 headers at:
      "/usr/include"
  Parsing HDF5 config from:
      "/usr/include/H5pubconf.h"

  --- stderr
  thread 'main' panicked at /home/dennis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hdf5-sys-0.8.1/build.rs:200:21:
  Invalid H5_VERSION: "1.14.2"
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
     1: core::panicking::panic_fmt
               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
     2: build_script_build::Header::parse
     3: build_script_build::LibrarySearcher::finalize
     4: build_script_build::main
     5: core::ops::function::FnOnce::call_once
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

My /usr/include/H5pubconf.h header also reports version 1.14.2, same as @trippalamb:
/* Version number of package */
#define H5_VERSION "1.14.2"

Are you using the version from crates.io or using themaster branch from here?

@nleroy917  try to set the hdf5 dependency to the git repo in your Cargo.toml. That did it for me.
[dependencies]
hdf5 = { git = "https://github.com/aldanor/hdf5-rust.git" }

I just saw your comment above. Thank you, I will try this. I'm actually getting this build error in someone elses project, so I need to do a clone, change the Cargo.toml, then try a custom build... will report back...

@nleroy917 Is it possible to add an override? https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html

😱 That worked super well. Even better since hdf5 was going to be a dependency of a dependency. I've got another problem now about not having a threadsafe version of hdf5 installed, but I think that one is unrelated to this issue 😅

Could be easier to use the static version of hdf5, try enabling the static feature (still only in master).

Oh, it looks like its actually an issue with hdf5-sys:
thread 'main' panicked at ~/.cargo/git/checkouts/hdf5-rust-c1072d7a2617f7d8/26046fb/hdf5-sys/build.rs:697:17:
        Enabled feature "threadsafe" but the HDF5 library was not built with HDF5_ENABLE_THREADSAFE
        note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
      error: `cargo rustc --lib --message-format=json-render-diagnostics --manifest-path Cargo.toml --release -v --features pyo3/extension-module --crate-type cdylib -- -C 'link-args=-undefined dynamic_lookup<EMAIL_ADDRESS>failed with code 101

Interestingly, I don't even have threadsage set:
[patch.crates-io]
hdf5 = { git = "https://github.com/aldanor/hdf5-rust.git" }
hdf5-sys = { git = "https://github.com/aldanor/hdf5-rust.git", features = ["static", "zlib"]}

@nleroy917 try to set the hdf5 dependency to the git repo in your Cargo.toml. That did it for me.
[dependencies]
hdf5 = { git = "https://github.com/aldanor/hdf5-rust.git" }

If I do this, it breaks my dependency on hdf5-sys. Is there a way to adjust for this? I'm reasonably new to rust and don't have a great grasp on the way the cargo works.

@trippalamb Add another line with hdf5-sys and the same contents

That did indeed seem to fix it. I appreciate it.

I was able to solve my problem by just unset-ing my HDF5_DIR variable. I have it in my .zshrc since I need it so often, but this time it was causing problems I guess.


Add an Assert.Inconclusive method

Hi,
have you ever considered to include an Assert.Inconclusive method, known from .Net (see https://msdn.microsoft.com/de-de/library/ms243815.aspx ), maybe raising some kind of an EInconclusiveTest exception?
This could replace/extend the ENoAssertionsMade exception and be handled equally (in first place).
On second hand, you could consider to turn FFailsOnNoAsserts into a member of type TTestResultType and handle such an exception as the defined result.
At last, one could consider to extend TTestResultType by an Inconclusive state (and let the ITestRunner and ITestLogger handle this case).
Possible use case: We have tests that we know won't work at specific operating systems or have other dependencies (like 'need a floppy drive for this test'). We neither wan't such a test be marked as failed nor passed, because it actually wasn't executed. But an information about it not being executed would be valuable.

I'm open to this suggestion, but any implementation would need to keep in mind that we would like to implement parrallel test runs at some point in time.

Here's the English link (above is in German): https://msdn.microsoft.com/en-us/library/ms243815.aspx
I think we could actually implement this fairly easily if we fully implement warning support.  I did a quick search for TTestResultType.Warning, and I believe the GUI is the only thing that uses it (to warn if no asserts, rather than fail - which should be optional as discussed in #154).
Now, I don't want to get into "this test failing should be a warning" or anything like that - but I think making FailOnNoAsserts an optional warning, then add Assert.Inconclusive to this, and it would integrate nicely.
I too have a few tests that only work when certain conditionals are in place, not to mention, like MS says in the article above, it is the default stub for a new test - so the IDE expert could use it in the default code template.
I guess the only problem with this I see is something @vincentparrett or @staticcat needs to weigh in on: what about support for warnings on Continua and others that rely on NUnit output?  Does NUnit output support any more states than DUnitX and Continua are supporting now?  Looking at my CI, it is Pass/Fail/Not Run.  I don't really feel the warning fits into any of those, and I wouldn't want to implement this if it couldn't flow across the board in a first-class implementation.

I'm not against this. DUnitX currently doesn't do anything with warnings either. Happy to accept a PR for both (makes sense to do them together).
NUnit supports Warnings and Inconclusive, so  Continua CI should too, we'll deal with any issues around that if needed.

No PR eventuated so closing. Feel free to submit one for review.


python3Packages.aplpy: fix build

Description of changes
Fix python3Package.aplpy build.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[x] sandbox = true

[x] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 297698 run on aarch64-darwin 1

4 packages failed to build:

python312Packages.aplpy
python312Packages.aplpy.dist
python312Packages.spectral-cube
python312Packages.spectral-cube.dist

8 packages built:

python311Packages.aplpy
python311Packages.aplpy.dist
python311Packages.glueviz
python311Packages.glueviz.dist
python311Packages.pvextractor
python311Packages.pvextractor.dist
python311Packages.spectral-cube
python311Packages.spectral-cube.dist

output of nixpkgs-review on x86_64-linux:
2 packages failed to build:
python312Packages.spectral-cube python312Packages.spectral-cube.dist
10 packages built:
python311Packages.aplpy python311Packages.aplpy.dist python311Packages.glueviz python311Packages.glueviz.dist python311Packages.pvextractor python311Packages.pvextractor.dist python311Packages.spectral-cube python311Packages.spectral-cube.dist python312Packages.aplpy python312Packages.aplpy.dist

Result of nixpkgs-review pr 297698 run on aarch64-darwin 1

4 packages failed to build:

python311Packages.glueviz
python311Packages.glueviz.dist
python312Packages.spectral-cube
python312Packages.spectral-cube.dist

8 packages built:

python311Packages.aplpy
python311Packages.aplpy.dist
python311Packages.pvextractor
python311Packages.pvextractor.dist
python311Packages.spectral-cube
python311Packages.spectral-cube.dist
python312Packages.aplpy
python312Packages.aplpy.dist

I will address python312Packages.spectral-cube build failure in other PR.

python312Packages.spectral-cube build failure should be fixed by #298610.

@ofborg build python312Packages.aplpy


Increasing responsive widths

Currently, bootstrap supports several browser widths, with the largest as 'extra large' which catches all experiences greater than 1200px. Unfortunately, w3schools has identified that as of last year, 90% of all browsers exceed this. While I can create a custom solution, it seems ideal for bootstrap to add additional widths (xl2, xl3, etc) to encompass the growing display situation.

I vote against. Bootstrap is a mobile-first experience.

Build responsive, mobile-first projects on the web with the world's most popular front-end component library.

Why md/lg/xl are insufficient? Can't you add expand LG or XL widths? Or add your own media sizes in boostrap?
// Grid breakpoints
//
// Define the minimum dimensions at which your layout will change,
// adapting to different screen sizes, for use in media queries.

$grid-breakpoints: (
  xs: 0,
  sm: 576px,
  md: 768px,
  lg: 992px,
  xl: 1200px
) !default;

I think I would vote against as well because I don't believe your 95% would take advantage of these larger breakpoints.  Bootstrap makes it so easy to build in your own additional breakpoints, I would say this is better solved on a per-project basis.

This could be a breaking change to projects if this came out, I reckon if we're going to change them, leave it until v5. That being said, I agree with @ItaloBC


python3Packages.matplotlib: 3.4.3 -> 3.5.0

Motivation for this change
Upgrades python3Packages.matplotlib from 3.4.3 to 3.5.0
This PR was automatically generated by nixpkgs-upkeep.

CI workflow that created this PR.
Internal tag: cf2b42ab55eee2f1aaa9cc9f94939182.

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build python38Packages.matplotlib python39Packages.matplotlib

This won't build, the build system got changed again, so matplotlib-specific options in setup.cfg need to be in mplsetup.cfg now.

Hmm, yeah I'll close this for now. It looks like this upgrade will require a little more human oversight.


Ignores NaturalRegen setting in Minecraft

Minecraft: 1.18.1 Forge: 39.0.64 It ignores NaturalRegen: False. Furthermore it tries to heal even when healingPerSecond is set to 0 in the configs causing hunger to decrease despite no regen occurring.

Please provide a pastebin of your configuration file.
Thanks!
MacTso

Sorry it took so long to get this. I wasn't at my PC when I noticed the message. https://pastebin.com/RsZgLNGq

It's okay.  I had two other issues tonight.   I'll look at this tomorrow.
It might be minecraft is doing it if you are wounded.
Thanks for the config.  How many hit points was your man at (roughly)?
Cheers,
MacTso

Okay so it is currently adding 0.0 extra exhaustion once per second when you are hurt.
This is mostly cosmetic (since it's 0.0) but it is a small performance drain so I can  I can make a change so it doesn't do the operation unless the extra exhaustion is greater than 0.
It's also "healing 0.0 damage" once per second.   I can also add a check for 0 on that so it only runs if the hardernaturalhealing amount is over 0.0.

I put in a fix for this but realized later that it is intended to cause extra exhaustion when you are wounded.  So later I'll be putting in a fix that if that is non-zero, it will apply it once per second if you are wounded.  If it is zero it will skip over the code silently.


Make all pattern matches exhaustive

[warn] /vagrant/schema-guru/src/main/scala/com.snowplowanalytics/schemaguru/generators/JsonSchemaGenerator.scala:63: match may not be exhaustive.
[warn] It would fail on the following inputs: JBool(_), JDecimal(_), JDouble(_), JInt(_), JNothing, JNull, JString(_)
[warn]     json match {
[warn]     ^
[warn] /vagrant/schema-guru/src/main/scala/com.snowplowanalytics/schemaguru/generators/JsonSchemaGenerator.scala:82: match may not be exhaustive.
[warn] It would fail on the following inputs: (_, JBool(_)), (_, JDecimal(_)), (_, JDouble(_)), (_, JInt(_)), (_, JNothing), (_, JNull), (_, JString(_))
[warn]         val jSchema: List[(String, JValue)] = x match {
[warn]                                               ^
[warn] /vagrant/schema-guru/src/main/scala/com.snowplowanalytics/schemaguru/generators/JsonSchemaGenerator.scala:110: match may not be exhaustive.
[warn] It would fail on the following input: JNothing
[warn]         val jType = x match {
[warn]                     ^
[warn] /vagrant/schema-guru/src/main/scala/com.snowplowanalytics/schemaguru/generators/JsonSchemaGenerator.scala:145: match may not be exhaustive.
[warn] It would fail on the following inputs: JArray(_), JNothing, JObject(_)
[warn]         val jType = x match {
[warn]                     ^
[warn] four warnings found

This is done


Update code quality tools: ruff etc.

Would be good to check for updates for ruff, isort, black and mypy. Also could check if ruff can replace isort and black.

Decided not to migrate from black to ruff format because:

That action takes non-zero time and there are other more important things to do
Black works currently without problems, and I'm happy with the VS Code integration and don't have time to check how that's done with ruff format.


route redirects?

I'm trying to figure out how to add a redirect route (301).
For instance ... I want to add an alias for /sign-in so that users that try to go to /login will be forwarded to the correct page.
Usually I would just add a <Redirect /> to the router.. but I'm not sure how to handle it in this code structure, as I can't seem to find any documentation about it.

onEnter: (_nextState, replace, next) {
  replace('/something');
 next();
}


[FEATURE] A5e System Support (specifically HP rolling feature)

The HP roll feature is currently not available for the A5e system, presumably because the module cannot determine how to roll hit points.
The A5e system does not record a hit die formula.  Rather, it stores separate hit dice and CON mod.
actor.data.data.attributes.hitDice (e.g., hitDice.d10.total)
actor.data.data.abilities.con.check.mod
Formula: (roll each set of hitDice) + (CON check * hitDice.total)
Check for non-zero hitDice, roll each and sum total, add Con bonus.

I'll look into adding this in in the next major version; I'd put it in the next minor but due to the way the hit dice are stored separately with this system it does require a little more custom work.

Wasn't sure if it was worth making a new post for this, but are there any plans to implement rolling of Pathfinder 1e hit dice?

I would make a new post with the request and I can see about doing it!


"Syncing slider" infinite loop  issue

With "slider Syncing" and infinite loop do not restart from first
====================================================================
http://codepen.io/alessioferrara/pen/WRZRaO
====================================================================
Setup a Sync slider as explained on codepen
====================================================================
After last image restart from first
====================================================================
After last image revert loop from last to first
====================================================================

I don't understand what is the issue you are having here...?? Do you mean that after the first loop is completed, when "infinite: true" it only shows slide 1 and it only loads the rest of the slides after it focuses on the slide 1 again??
Check my fork of your codepen, "slidesToShow: 4" option fixed it, and "centerMode: true" made it look better when the loop goes back and forth as opposed to infinite.
http://codepen.io/Varin/pen/YNrLBV

And if you have random thumb? or a responsive layout? or different thumb width according to the page?
I will expect that with "infinite loop" true I am not forced to set slidesToShow...
Take a look http://codepen.io/alessioferrara/pen/EZwzwN


Report

Builds off #1. Let's merge that first. Adds functionality to write reports to disk.
Pretty sure the formatting code can be a bunch nicer. Ideas welcome on how to improve probably through #3.
Thanks!

Closing in favor of #5.


setState Pathing, Ability to Evaluate Expression on Filter Results

The syntax of setState is really awesome... However I've run into a bit of a hole, or maybe I'm just not using this correctly...
In a contrived but still related example, let's say I have
setState('path', 'to', 'array', x => x.startsWith('abc'), ...

and then I want to update only the first result of that filter. Currently, it doesn't appear that there's any way to do this, as the filter function will then evaluate the next expression in the chain against each result, so trying to do something like
setState('path', 'to', 'array', x => x.startsWith('abc'), 0, 'changed');

will result in the thing setting the key '0' on every result to be 'changed'... Maybe, without breaking the prexisting functionality which is more useful in like every other circumstance, something could be implemented, like maybe an object with a where key or something, that would evaluate the next expression on the results of the filter rather than on each result?
Or is this actually possible currently and I'm just not seeing how?

Hmm.. yeah fair I guess because it turns everything downstream into an iteration. I didn't think this through as much there is syntax where you can check the current path in the setter. I was thinking if you wanted only a single index you'd filter on that index as well. But I get you intend to act on the first filtered child and not index 0. Even my path would show the original index I believe. I think the challenge here is it becomes like an intermediate result. I almost would rather make the filter smarter. But the only way I can think of that right now is to store a temporary variable outside of the setter call. Even as a composable helper.
let found;
setState('path', 'to', 'array', x => !found && x.startsWith('abc') ? (found = true) : false, 'changed');

or like:
function first(predicate) {
  let found;
  return (...args) => {
    if (found) return false;
    return found = predicate(...args);
  }
}

setState('path', 'to', 'array', first(x => x.startsWith('abc')), 'changed');

Not built in but just spitballing. I feel it is more that the filter is failing rather than needing to have intermediate results. Let me know what you think.

Well, that isn't really what I was going for... In reality, I'm essentially trying to update a dynamically assigned index, so the actual call looks something like
setState('path', 'to', 'array', x => x.startsWith('abc'), index, 'changed');

where index is a prop, but in a more generic sense I'd imagine the from-to object could also be useful here... I'm picturing something like {where: fn(), at: 0} or {where: fn(), from: 0, to: 5} or something, that you could just shove in there to fill the gap without changing anything that's there already, granted I haven't actually looked at the source for this so maybe that's not possible...

To me it becomes less obvious what the behavior is especially since I reference things in paths (second argument to the setter function if used to the original location. I mean this is to streamline most setup. It isn't designed to handle every scenario (including many multi update ones).
This case is particularly strange in that without using ids you can look up you have to somehow map back to the original index after filtering. Especially if you are doing a full replacement at that index and not just modify something that is there. Because ultimately in state while you have say index 2 of the filtered results it might be actually index 47 you have to replace. That's really hard to do without IDs in almost any system.
It's:

Filter list
Find item at requested index
Find index of item in original array
Set newValue at that index

You can also just do the work outside:
const itemToBeReplacedOrUpdated = state.path.to.array.filter(x => x.startsWith('abc'))[index];
const updateIndex = state.path.to.array.indexOf(itemToBeReplacedOrUpdated);
setState('path', 'to', 'array', updateIndex, changed);

I see your edit now:

why even use the filter if we're just passing indexes?
Yes I'm wondering that myself. I think this behavior could be wrapped in a nice way to generate a list of indexes to traverse but the mapping complexity is just nasty as the general purpose behavior. I'm sure this is solveable in a nice to wrap up way it's ok to do the work on the outside or do multiple set state calls in a loop (wrap them in freeze so they notify together). Truthfully I was pretty happy to have these short cuts but I'm already conscious of the code size it adds to everyone who doesn't even use these features.

In summary, the setState modes are extra helpers and not designed to solve every problem. There is always a way of solving these problems without having a baked-in syntax. I will leave this in userland for now.


Intermittent "invalid point" error when signing a transaction

I'm getting frequent yet intermittent "invalid point" errors when using v1.1.2 to sign a transaction.
The signing algorithm for the asymmetric signing key in GCP KMS is Elliptic Curve P-256 / SHA256 -- using either version 1 or 2 here (version 3 was just to test, not being used):

The code derived from the example in the README:
require("dotenv").config();
const { KeyManagementServiceClient } = require("@google-cloud/kms");
const { ethers } = require("ethers");
const { GcpKmsSigner } = require("ethers-gcp-kms-signer");

const bignum = ethers.BigNumber.from;

const { GOOGLE_APPLICATION_CREDENTIALS, PROJECT_ID, LOCATION_ID, KEYRING_ID, INFURA_URL } =
  process.env;
...
async function main(id = "eth-signing-key-1") {
  // const client = new KeyManagementServiceClient();

  const kmsCredentials = {
    projectId: PROJECT_ID,
    locationId: LOCATION_ID,
    keyRingId: KEYRING_ID,
    keyId: id,
    keyVersion: "1",
  };

  const tx = {
    to:
      "0xE94E130546485b928C9C9b9A5e69EB787172952e", // from example in README at https://github.com/johanneskares/ethers-gcp-kms-signer
    value: ethers.utils.parseEther("0.01").toString(),
    gasPrice:<PHONE_NUMBER>,
    gasLimit: 500000,
  };
  console.log("tx to sign:", tx);

  const popTx = await signer.populateTransaction(tx);
  console.log("populated tx:", popTx);
  console.log("balance required (ETH):", ethers.utils.formatEther(bignum(popTx.gasLimit).mul(popTx.maxFeePerGas).add(popTx.value)));

  console.log("signing tx...");
  let signedTx;
  for (let i = 0; i < 10; ++i) {
    try {
      signedTx = await signer.signTransaction(popTx);
      break
    } catch (err) {
      console.error(`Error in signTransaction on attempt ${i+1}`, err);
      if (err == 9) {
        throw err;
      }
    }
  }
  console.log("signed tx:", signedTx);

  console.log("sending signed tx...");
  const sentTx = await provider.sendTransaction(signedTx);
  console.log("sentTx:", sentTx);

  const receipt = await sentTx.wait();
  console.log("receipt:", receipt);
}
...

When it fails, the stack is:
Error: invalid point
at ShortCurve.pointFromX (/Users/nedgar/src/my-first-project/node_modules/elliptic/lib/elliptic/curve/short.js:195:11)
at EC.recoverPubKey (/Users/nedgar/src/my-first-project/node_modules/elliptic/lib/elliptic/ec/index.js:215:20)
at recoverPublicKey (/Users/nedgar/src/my-first-project/node_modules/@ethersproject/signing-key/lib/index.js:61:30)
at Object.recoverAddress (/Users/nedgar/src/my-first-project/node_modules/@ethersproject/transactions/lib/index.js:72:62)
at recoverPubKeyFromSig (/Users/nedgar/src/my-first-project/node_modules/ethers-gcp-kms-signer/dist/util/gcp-kms-utils.js:163:31)
at determineCorrectV (/Users/nedgar/src/my-first-project/node_modules/ethers-gcp-kms-signer/dist/util/gcp-kms-utils.js:176:16)
at /Users/nedgar/src/my-first-project/node_modules/ethers-gcp-kms-signer/dist/signer.js:68:69
at Generator.next (<anonymous>)
at asyncGeneratorStep (/Users/nedgar/src/my-first-project/node_modules/ethers-gcp-kms-signer/dist/signer.js:22:103)
at _next (/Users/nedgar/src/my-first-project/node_modules/ethers-gcp-kms-signer/dist/signer.js:24:194)

Yesterday this was happening 80-90% of the time. Today I haven't been able to reproduce it. Very odd.

The package dependencies are as follows. I restricted ethers and kms to the versions ethers-gcp-kms-signer 1.1.2 specifies, but that didn't make any difference.
"@google-cloud/kms": "2.10.0",
"dotenv": "^16.0.1",
"ethers": "5.5.1",
"ethers-gcp-kms-signer": "1.1.2"

Yesterday this was happening 80-90% of the time. Today I haven't been able to reproduce it. Very odd.

I had switched to 1.1.1, but now it's failing with that too, in the same way, about 50% of the time.

I'm running Node v14.20.0

I was able to reproduce the problem in the current repository, by adding this to src/signer.test.ts as the first test:
  test("should sign a transaction", async () => {
    const provider = ethers.providers.InfuraProvider.getWebSocketProvider("rinkeby", process.env.INFURA_KEY);

    const signer = new GcpKmsSigner(kmsCredentials).connect(provider);

    const tx = await signer.signTransaction({
      to: "0xEd7B3f2902f2E1B17B027bD0c125B674d293bDA0",
      value: ethers.utils.parseEther("0.001"),
    });

    expect(tx).not.toBeNull();

    /* eslint-disable no-console */
    console.log(tx);
  });

It's basically the "should send a signed transaction" test but with sendTransaction changed to signTransaction.

@fforbeck Thanks, the secp256k1 algo works much better, lol. I don't know how I missed that option. Do you think the signer could be made to "fail fast" if the incorrect algorithm is chosen (without extra round trips for the happy path)? I notice the response includes the protection level, e.g. I added console.log("requestKmsSignature - response:", response) in requestKmsSignature:

Or perhaps we can just add an API function that checks whether the algorithm for a given key is compatible?

@nedgar yeah, that's the algo Ethereum uses. Good point, I believe if we implement your suggestion from #6 (instantiating the kms client only once) we reduce the leak, and we can execute an additional call to get the configs (kms.getCryptoKeyVersion) to verify if it is using the correct algorithm. If I remember correctly, the kms.getPublicKey also returns the algo, but we are not checking that. Feel free to submit a PR with these changes, happy to review that.

That sounds good, I’ll work on a PR in the coming week. For now, I just moved the kms const assignment outside the functions.
On Aug 10, 2022, 9:26 AM -0400, Felipe Forbeck @.***>, wrote:

@nedgar yeah, that's the algo Ethereum uses. Good point, I believe if we implement your suggestion from #6 (instantiating the kms client only once) we reduce the leak, and we can execute an additional call to get the configs (kms.getCryptoKeyVersion) to verify if it is using the correct algorithm. If I remember correctly, the kms.getPublicKey also returns the algo, but we are not checking that. Feel free to submit a PR with these changes, happy to review that.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>


Possibility to fetch pom file

As discussed on Gitter, it seems currently not possible to fetch the corresponding .pom file of an artifact. Trying with specifying Type.pom does not work. A work-around is using an artifact transformer, but that currently requires a lot of heuristics and guess work, because the rewrite depends on the type of repository (maven vs ivy). MavenRepository has some of this logic internally as metadataArtifact parsing. Would be great to have this as public function. (Background: I am trying to read the <properties> second of the POM).
For example, my intuition was to use
Resolve().addDependencies(
  appDep.withTransitive(false).clearExclusions.withPublication(artifactId, Type.pom, Extension.pom)
)

but then resolve doesn't return any artifact.

I managed to do it by combining .withPublication(..., Type.pom) and Fetch().withArtifactTypes(Set(Type.pom))
val dep2 = Dependency(
    Module(
      Organization("org.typelevel"),
      ModuleName("cats-core_3"),
    ),
    "2.6.1"
  ).withPublication("cats-core_3", Type.pom)

  val res = Fetch()
    .withArtifactTypes(Set(Type.pom))
    .addDependencies(dep2)
    .run

But I agree the API is not really intuitive here.

I'm looking for a way to get all the files in the artifact (including POM file, which is how I found this bug).
I initially tried Fetch().allArtifactTypes() but it did not return the POM file until I added the .withPublication("cats-core_3", Type.pom) as per above.
There were/are a couple of hacky approaches I'm contemplating, including setting a cache directory and then just walking the cache to find the files I'm looking for, but that sounds super sketchy.
Instead of returning a flat list of files, I wish it returned a list of maven artifacts which we could query to get information about the artifact including the maven model (or pom file, which I can parse with Pom.project) and get all the jars and hashes and signatures.

I don't think there is a way to actually get all transitive poms, right?


ENH: TubeTK should support 2D images by default - used in tests

ENH: Changed 2D support to default to ON.  This will also fix several failing tests.
STYLE: Fixed spacing issues in CMakeLists.txt file (needed spaces between parens and their content.

Should these tests be disabled when compiling with 2D OFF since it would be
the expected behavior?
On Sat, Feb 27, 2016, 17:50 Stephen R. Aylward<EMAIL_ADDRESS>wrote:

ENH: Changed 2D support to default to ON. This will also fix several
failing tests.
STYLE: Fixed spacing issues in CMakeLists.txt file (needed spaces between
parens and their content.
You can view, comment on, or merge this pull request online at:
https://github.com/KitwareMedical/TubeTK/pull/618
Commit Summary

ENH: TubeTK should support 2D images by default - used in tests

File Changes

M CMakeLists.txt
https://github.com/KitwareMedical/TubeTK/pull/618/files#diff-0 (63)

Patch Links:

https://github.com/KitwareMedical/TubeTK/pull/618.patch
https://github.com/KitwareMedical/TubeTK/pull/618.diff

—
Reply to this email directly or view it on GitHub
https://github.com/KitwareMedical/TubeTK/pull/618.

How about requiring 2D turned on if testing is turned on?
s
On Mon, Feb 29, 2016 at 9:56 AM, Francois Budin<EMAIL_ADDRESS>wrote:

Should these tests be disabled when compiling with 2D OFF since it would be
the expected behavior?
On Sat, Feb 27, 2016, 17:50 Stephen R. Aylward<EMAIL_ADDRESS>wrote:

ENH: Changed 2D support to default to ON. This will also fix several
failing tests.
STYLE: Fixed spacing issues in CMakeLists.txt file (needed spaces between
parens and their content.
You can view, comment on, or merge this pull request online at:
https://github.com/KitwareMedical/TubeTK/pull/618
Commit Summary

ENH: TubeTK should support 2D images by default - used in tests

File Changes

M CMakeLists.txt
https://github.com/KitwareMedical/TubeTK/pull/618/files#diff-0 (63)

Patch Links:

https://github.com/KitwareMedical/TubeTK/pull/618.patch
https://github.com/KitwareMedical/TubeTK/pull/618.diff

—
Reply to this email directly or view it on GitHub
https://github.com/KitwareMedical/TubeTK/pull/618.

—
Reply to this email directly or view it on GitHub
https://github.com/KitwareMedical/TubeTK/pull/618#issuecomment-190245967
.

--
Stephen R. Aylward, Ph.D.
Senior Director of Operations, North Carolina, Kitware, Inc.
http://www.kitware.com and http://www.aylward.org
(919) 969-6990 x300

@jcfr , what do you think it the cleanest? turning OFF the tests that fail when 2D is deactivated, or requiring 2D to be turned ON when the TESTING is ON?

Hi
My thoughts...
Coverage would be very low if we only ran the 3d tests.
As an itk module, we need to test 2d and 3d.
We should probably make turning 2d support off be an advanced option.  It
should not be recommended.
S
On Feb 29, 2016 8:27 AM, "Francois Budin"<EMAIL_ADDRESS>wrote:

@jcfr https://github.com/jcfr , what do you think it the cleanest?
turning OFF the tests that fail when 2D is deactivated, or requiring 2D to
be turned ON when the TESTING is ON?
—
Reply to this email directly or view it on GitHub
https://github.com/KitwareMedical/TubeTK/pull/618#issuecomment-190276850
.

Independently of your choice, just make sure that cases with TubeTK_Support_2D_Images disabled and enabled are tested.
Ideally, as a user, if I call a program that could be compiled with option either enabled or disabled, appropriate error message and outputs should be reported.

Hi,
If testing is on, let's require 2D to be on.   I will make this change and
submit a pull request as part of test fixes I am generating now.
s
On Mon, Feb 29, 2016 at 1:31 PM, Jean-Christophe Fillion-Robin <
<EMAIL_ADDRESS>wrote:

Independently of your choice, just make sure that cases with
TubeTK_Support_2D_Images disabled and enabled are tested.
Ideally, as a user, if I call a program that could be compiled with option
either enabled or disabled, appropriate error message and outputs should be
reported.
—
Reply to this email directly or view it on GitHub
https://github.com/KitwareMedical/TubeTK/pull/618#issuecomment-190323158
.

--
Stephen R. Aylward, Ph.D.
Senior Director of Operations, North Carolina, Kitware, Inc.
http://www.kitware.com and http://www.aylward.org
(919) 969-6990 x300

That sounds good since adding 2D support doesn't break anything.


auto-publish snapshots

Original issue created by adrian.f.cole on 2013-08-07 at 03:18 PM

As this is an OSS project, we should be able to get a CloudBees jenkins config setup and prevent snapshots from going stale.  https://oss.sonatype.org/content/repositories/snapshots/com/google/errorprone/

I set up travis to publish snapshots: https://oss.sonatype.org/content/repositories/snapshots/com/google/errorprone/


Is Nuclear energy climate friendly ?

Author

Name: Oliver Zeilerbauer

Affiliation: FH Kufstein

Keywords
Nuclear Energy, Nuclear Fission, Small Modular Reactor’s (SMR’s), IAEA (International Atomic Energy Agency), IEA (International Energy Agency)
Abstract
A noticeable amount of the global total energy is supplied by nuclear energy. A Chart from the IEA (International Energy Agency) shows that it increased from 0.9% in 1973 to 5.0% in 2019.[1] Although not a renewable energy source, nuclear energy counts as a low-carbon energy, since during the process the CO2-emissions are near zero. For a comparison of the CO2-emissions the lifecycle of the energy source is tracked, namely manufacturing, transportation and production processes. While Renewable Energies like wind and solar are heavily influenced by weather conditions which limits the places where you can build them, nuclear energy has less restrictions and can be built in a lot more spaces, safety measures uphold. Since some communities cannot use or store as much energy as a big powerplant produces, there are smaller and thus cheaper architectures in research so called SMR’s (Small Modular Reactors). Small is self-explanatory, they are smaller than big power plants. Modular in the sense that you can stack them together to make a big power plant.
Nuclear_Energy_oliver_zeilerbauer.pdf
Full PDF: DOI, [Zenodo],
Github Repo.
Github Release
Zenodo WholeTale
Zenodo Github
..

The author Oliver Zeilerbauer has dealt intensively with the topic of nuclear energy in relation to its future application. In doing so, the author addressed the questions of whether nuclear energy is climate-friendly or not.
Global, political decisions and agreements were taken into consideration, among other things. Furthermore, the damage and the disposal of nuclear waste are discussed in detail.
In conclusion, one can read very well from the article that in the future very good alternatives like Small Modular Reactors (SMRs) would be a good alternative to produce climate-friendly energy. In time, it might be possible to patent these small modular reactors. One of the big advantages according to studies in the article are among others high cost reductions and offers high safety compared to classical reactors.
This article is a valuable contribution for future decisions and discussions on nuclear energy climate-friendly useful or not. The article is very well structured and the language is very easy to understand.
Points (20/20)

The author Oliver Zeilerbauer has summarized sustainability and safety aspects of nuclear power plants in comparison with non-renewable energy sources.
The author presents an interesting view on the topic and concludes that nuclear energy is at least way more sustainable than fossil fuels. He supports his conclusion with several numbers and analyses the topic from different perspectives. Regarding the novelty, the paper reports about new technologies and findings. No own research is conducted which is acceptable for such a short student work. The topic is extremely relevant and will remain a topic of discussion for a very long time.
Since the paper is created for a data science conference, I expected to find information on the connection of the topic with data science. The lack of such a connection is a shortcoming of the paper.
Regarding the reference, the author presents links which mainly include scientific papers and websites or reports from official agencies. These sources might be scientifically valuable but need to be cited according to the standards. An example would be:
Krall, L. M., Macfarlane, A. M., & Ewing, R. C. (2022). Nuclear waste from small modular reactors. Proceedings of the National Academy of Sciences, 119(23), e2111833119.
Direct quotes should also contain the page number where the sentence can be found.
The style of the paper does not yet totally match the ACM style guide (https://www.acm.org/publications/proceedings-template). Images should be moved in order to close gaps in the text and should carry a separate number and caption that can be referenced in the text. The abstract is more a introduction than a summary hence the title of the section should be changed.
Regarding spelling and writing style I would advise to be aware of uppercase and lowercase letters and verbforms (in regard to singular/plural forms). In scientific writing I would also prefer a more passive style such as ‘As can be seen’ instead of ‘As we can see’.
In conclusion, the paper presents a very interesting topic and an overview of recent literature. In terms of style and scientific representation several points need to be revised as described above.
Points (12/20)


Update JNI repo to use common signoff action [skip ci]

as pull_request_target event trigger only affect after merge.
This has been verified in my run,
no signoff: https://github.com/NVIDIA/spark-rapids-jni/actions/runs/10695554079/job/29649185254
signoff: https://github.com/NVIDIA/spark-rapids-jni/actions/runs/10695574548/job/29649238635

convert to draft.
please help review~ Allow me to merge and do the following verifications, thanks

build


Permissions documentation is wrong for mac

this is what we have in the readme.md:

chmod o+w docroot/user/config
chmod o+w -R docroot/cache
chmod o+w -R docroot/logs
chmod o+w -R docroot/images
chmod o+w -R docroot/assets
chmod o+w -R docroot/user/data
chmod o+w -R docroot/backup
chmod o+w -R docroot/tmp
chmod o+w -R docroot/user/accounts

For macs this doesn't work, should be:

chmod -R o+w docroot/user/accounts

Im not unix versed. Should there be platform specific options?

Actually that should work for both platforms. Let me know if you want to create a PR


Use instance profile if created

what

Use instance profile if created

why

It creates the instance profile but does not associate it with the ec2 instance

references
N/A

/test all


Update dependencies to latest stable versions and Go version to 1.17

Signed-off-by: Mike Ng<EMAIL_ADDRESS>

Trying to resolve the lint issue in the other PR https://github.com/kubernetes-sigs/work-api/pull/18 but it doesn't look like updating the dependencies help.

Let me see if I can help with the lint issue.

Let me see if I can help with the lint issue.

Thanks @RainbowMango I tried on my local fork with this change it should work https://github.com/kubernetes-sigs/work-api/pull/20 but I am not sure why it's not trigger the GitHub action job now in the PR.


Chat bot addition.

What feature?
To add a chat bot to provide with basic site info to the users.
Add screenshots
No response
Record

[X] I agree to follow this project's Code of Conduct
[X] I want to work on this issue

Hi there, how do you plan on implementing it?

Ya, sure. I'll do it as soon as I can.

Ya, sure. I'll do it as soon as I can.

Hi, it's been 5 days, can you share the workflow soon, thanks.

this is my approach. To be very honest, I haven't built one before but, I really intend to learn how to make a functional chatbot and it's altogether the only reason I raised the issue.

An what chatbot responds to?


Linux platform support

It'd be great if the emoji picker could also support the Linux platform.
There is a native GTK chooser that could be used, but a Flutter-based emoji picker would be alright as well.

Hey @12people let me check if we can add support for Linux. I haven't checked if there would be anything that would block it.


Expression syntax checking not working

The syntax checking subroutine is not working as expected.
Using the test_cpp example source:
~$ ./test_cpp '1 2'
Too many arguments
~$ ./test_cpp '1 )( 2'
Parenthesis mismatch

While the expected behavior should be:
~$ ./test_cpp '1 2'
Syntax error
~$ ./test_cpp '1 )( 2'
Syntax error

Fixed on #21!


Scheduler.process: apply directly to program unit corresponding to Item

This is part 2 to #136 (and filed against that PR branch to allow consolidating the fix if acceptable).
The extended fix in this PR is more invasive than the minimum workaround implemented in #136 by applying transformations directly to the program unit corresponding to an item instead of relying on recursion to eventually end up at the right object. This also removes the need for the check of item.name == routine.name before applying transformations, because now we do actually apply transformations only directly to the subroutines that are meant to be transformed.
This highlighted also a flaw in the current scheduler design which effectively preempts processing contained member routines entirely, because we can't represent contained member routines as scheduler graph nodes (the discovery mechanism is unable to find member routines), and the above mentioned name check preempts recursion into the member routine. The implementation in this PR partially resolves this by getting rid of the name check. Proper representation of contained member routines requires more changes, though, and I will create a separate issue for that.
As this change is more invasive in the scheduler, it may have unintended side-effects and therefore this fix is optional.

Waiting for CI to confirm but I think I fixed the issue that was flagged by the ecwam regression test: The DependencyTransformation had an implicit dependency on the recursion behaviour of the Transformation class - both in terms of requiring the recursion to always start from the source file level, and trusting that recursion never actually reaches contained member procedures...
I added some safe guards to the transformation that ensure existing behaviour is retained.
@mlange05: Please let me know if you would like to review this as a diff to #136, or want me to merge this PR into the other and review them together?

As requested, merged into #136 for further review.


Get cloud provider resource - DescribeRepositories

Overview
Get new cloud provider resource - DescribeRepositories.
Additional Information
DescribeRepositories is a resource that will be used in upcoming implementations of CIS benchmarks in regolibrary.
How to Test
Once CIS-EKS benchmark will be release, can be tested by running: kubescape scan control C-0221 (or: kubescape scan framework cis-eks-t1.2.0)
Checklist before requesting a review
put an [x] in the box to get it checked

[x] My code follows the style guidelines of this project
[x] I have commented on my code, particularly in hard-to-understand areas
[x] I have performed a self-review of my code
[x] If it is a core feature, I have added thorough tests.
[x] New and existing unit tests pass locally with my changes

Please open the PR against the dev branch (Unless the PR contains only documentation changes)
-->

So this is related to the CIS-EKS epic.
Will we need to develop anything else related to the CIS-EKS story? If so, we might want to create a "feature branch" that will be dedicated to this purpose. Then, we will merge the feature branch once we complete all related development.

/cc @yuleib

@dwertent Yes, we probably will.
Sure I'll open a separate branch for now


chore: run ci deploy step only on release

Summary:
We create a separate github action which runs only after a release is published. We also modify the original ci github action to remove the deploy step so we don't deploy on push to main
Issue Reference(s):
Fixes #490
Build & Testing:

[x] I ran cargo test successfully.
[x] I have run ./lint.sh --mode=fix to fix all linting issues raised by ./lint.sh --mode=check.

Checklist:

[ ] I have added relevant unit & integration tests.
[ ] I have updated the documentation accordingly (if applicable).
[x] I have performed a self-review of my own code.

@amitksingh1490 Can you take a look at this PR? I've tested out the pipelines on my work. But if some unknown issues do come up, I'll be available to help and debug.

@amitksingh1490 This looks good to me. What do you think?

LGTM


fix for fd bug + fox for infinite waitpid

Summary: Bugfixes:
1. Fix for fd close bug - Due to parent/child process race, sometimes wrong FDs were closed by
parent, which caused problems with rialto ipc
2. When rialto server is stuck, ServerManager will kill it to avoid infinite waitpid.
Type: Fix
Test Plan: App launch/kill tests with AI
Jira: RIALTO-4

https://jenkins.code.rdkcentral.com/job/github-triggered/32494/ started

https://jenkins.code.rdkcentral.com/job/github-triggered/32496/ started

https://jenkins.code.rdkcentral.com/job/build-component/69303/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/github-triggered/1457/ started

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/github-triggered/1458/ started

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/build-component-platform/2589/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/build-component-platform/2590/ started.

Sanity tests for ['RPI3 Refapp2'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/6169/

Sanity tests for ['RPI3 Hybrid/MC'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/6170/

Sanity tests for ['BCM Reference Refapp2'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/6179/

Sanity tests for ['BCM Reference Refapp2'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/6180/

https://jenkins.code.rdkcentral.com/job/github-triggered/32506/ started

https://jenkins.code.rdkcentral.com/job/build-component/69353/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/github-triggered/1464/ started

Sanity tests for ['RPI3 Refapp2'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/6311/

Sanity tests for ['RPI3 Hybrid/MC'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/6312/

Sanity tests for ['BCM Reference Refapp2'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/6314/


Update rbenv Ruby and Bundler versions

Add missing versions of Ruby to rbenv list
Update rbenv aliases to appropriate Ruby version
Upgrade bundler version to latest version (v1.15.1) across the board (mostly from v1.14.5)

I've tried to explain why I think it should be safe to make these changes in the relevant commit notes, but I'm willing to be persuaded the changes should be made in smaller increments.

I agree with the bundler upgrade, it makes total sense to upgrade this regularly! Thanks for doing that.
I'm not 100% sure we should allow all those ruby versions, though. I think as much as possible we should limit the rubies we can use to the latest major versions (and within each major version, the latest minor and patch versions).
By quickly looking into all the repos I have checked out on my machine, these are the versions we have:
(carlosvilhena) ~/govuk » find . -type f -name '.ruby-version' | xargs cat | sort | uniq                                   ruby-
1.9.3
1.9.3-p550
2.1
2.1.4
2.1.8
2.2
2.2.2
2.2.3
2.2.4
2.3.0
2.3.1
2.3.3
2.4.0
system

I could see us, with not too much effort, reducing that list even further to a handful of ruby versions.
What do you think of this @floehopper ?

@carvil:
I agree that it would be good to reduce the number of Ruby versions, however that feels like a separate problem. I think the right way to tackle that would be to work through the existing apps which do not meet the Ruby version requirements you mention and upgrade them. Then as particular versions of Ruby are no longer used by any apps, they can be removed from here.
I'd be happy to change this PR to not add any new versions of Ruby other than the latest ones for each minor release, i.e. only add v2.1.10, v2.2.7, v2.3.4 & v2.4.1, if you'd prefer. It just seemed odd to miss out intermediate patch versions. What do you think?
Also, given that the Bundler upgrade doesn't seem so controversial, maybe I should split this PR into two PRs...?

If you're ok with that, I would probably only add the latest of each minor release and then separately I will look into upgrading some of the ruby apps to reduce the number of rubies we use.
Happy for this to be on the same PR 👍

@carvil: No problem. Force-pushing now.

If we're adding new Ruby versions someone will have to package them and make them available using this repo. Puppet will most likely complain otherwise.

Just saw this. Sorry. My bad.


There may be a conflict with the shortcut keys of the screenshot tool

Microsoft PowerToys version
0.82.1
Installation method
GitHub, Microsoft Store
Running as admin
Yes
Area(s) with issue?
General
Steps to reproduce
Start Powertoys and then try taking screenshots of the key presses
✔ Expected Behavior
I hope to be able to start the screenshot tool normally. The screenshot tool in Windows 11 is very useful.
❌ Actual Behavior
There may be a conflict with the screenshot shortcut keys (Windows+shift+s) in the system, and I have found that I am currently unable to trigger the screenshot tool through the shortcut keys.
Other Software
No response

What happen when you press WIN+SHIFT+S?
Does the issue persists after closing PowerToys from the tray icon?

/needinfo


docs/meeting-minutes: Add notes from January TrenchBoot AEM meeting

Signed-off-by: Michał Żygowski<EMAIL_ADDRESS>

@krystian-hebel you review IMO is not mendatory I just wanted to make sure you get notifications with @andyhhp  comments.

@andyhhp any chance you could look at @miczyg1 fixes and if we can merge this PR?

Cleanup: this PR is stuck for a long time.  @andyhhp, ping.


Add spotlight support in Environment

Hello,
This is my first Pull Request.
This Pull Request add support of spotlight in environment. It doesn't modify the shader so spotlight can't be used with default shader. But it allows to use spotlight in custom shader.

I had no answer until now so if something is wrong don't hesitate to tell me.

Thanks! See also #1936. I guess it doesn't harm to have this class for the time being. Will fix it up a bit after merging.


cargo make hangs if there is a bad internet connection

Describe The Bug
Running cargo make when the internet connection is weak (e.g., long ping time / lost packets) causes the command to hang for an indefinite amount of time.
Suggested Fix

Add a command-line flag to cargo make to prevent it from phoning home to check for updates.
If the request hangs for more than ~3 seconds, skip the update check.

by default, updates are checked no more than once per week and you can turn it off via configuration:
https://github.com/sagiegurari/cargo-make#cargo-make-global-config
or via cli --disable-check-for-updates param
however, there are many other things that cause network checks for example if you invoke some cargo plugin, and its not there i install it.

@sffc did you check the disabling the update via config/cli?

closing due to lack of feedback and existing config


InApp Messages dismissal leaves app unresposive

In app messages work correctly until dismissed, they go away correctly but the app becomes unresponsive to touch events after. Not even the expo inspector is clickable after dismissing the inApp message and to make it work again we have to close and open the app.
We are using the following versions:
 "customerio-expo-plugin": "^1.0.0-beta.15",
 "customerio-reactnative": "^3.7.0",

with expo sdk-51.
I've tested with versions beta-16 of the plugin and also tried previous versions of the main package, as well as 3.9.1. So it seems this issue isn't version specific.
Any thoughts on what could be going on here?

Hey @rafael-urena-yoke, thank you for reaching out.
Can you please share the logs to<EMAIL_ADDRESS>along with a link to the in-app message in Customer.io that you're using to test.