Add Marlowe DivValue (division)

Pre-submit checklist:

Branch

[x] Tests are provided (if possible)
[x] Commit sequence broadly makes sense
[x] Key commits have useful messages
[ ] Relevant tickets are mentioned in commit messages
[x] Formatting, materialized Nix files, PNG optimization, etc. are updated

PR

[x] Self-reviewed the diff
[x] Useful pull request description
[x] Reviewer requested

I meant my original suggestion could produce an exception maybe, not sure.
In that case let's do it with the nested ifs, you are right


Design the devices list page

Description
Design the devices list page.
Acceptance Criteria

[x] A list of all the devices, including revoked
[x] Explore how revoked devices can be distinguished from active ones
[x] Each device should contain the name, icon, status, added at, last seen date, last seen at (location), used X times
[x] A CTA to revoke an active device

All points from the acceptance criteria already covered, I've included the "cards component" variations depending the number of devices, with this already predicted we can reuse them on the apps page as well.


Add chatrooms support

chatrooms:1234564:UUID already contain IDs in all cases, so returning them as-is should be fine.
This has the effect of allowing chatrooms logs access via /channel/chatrooms:12345:UUID/user/asd and via the /channelid endpoints too.

Gotta test this myself on the weekend

https://twitter.com/SirStendec/status/1180215928233041920?s=19

FeelsDankMan


polymer doesn't work with babel-loader in webpack?

I use polymer 3.0 preview , and bundle custom elements with webpack & babel. When I doesn't transpile .js with babel-loader. it works normally in chrome 61. However, if I use babel-loader to transpile class statement, it throws error as below
Uncaught TypeError: Class constructor PolymerElement cannot be invoked without 'new'
    at new MyApp (app.js:10656)
    at Object.window.WebComponents (app.js:10677)
    at __webpack_require__ (app.js:678)
    at fn (app.js:88)
    at Object.<anonymous> (app.js:4653)
    at __webpack_require__ (app.js:678)
    at module.exports.ctor.super_ (app.js:724)
    at app.js:727

my components.js to define custom elements:
import<EMAIL_ADDRESS>import {Element as PolymerElement} from<EMAIL_ADDRESS>import * as view from './aaa.html';

export class MyApp extends PolymerElement {

  // Define a string template instead of a `<template>` element.
  static get template() {
    return view;
  }

  constructor() {
    super();
    this.name = '3.0 adaa11dpreview';
  }

  // properties, observers, etc. are identical to 2.x
  static get properties() {
    name: {
      Type: String
    }
  }
}
customElements.define('my-app', MyApp);

my webpack.conf.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const webpack = require('webpack');

module.exports = {
  entry: {
    app: [
        './src/my-app'
    ]
  },
  devtool: 'eval-source-map',
  devServer: {
    contentBase: path.resolve(__dirname, '..', 'dist'),
    hot: true
  },
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, '..', 'dist')
  },
  module: {
    rules: [
      {
        test: /\.(html)$/,
        use: {
          loader: 'html-loader'
        }
      },
      {
        test: /\.js$/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['env']
          }
        },
        exclude: /node_modules/
      }
    ]
  },
  resolve: {
    extensions: ['.js']
  },
  plugins: [

    new HtmlWebpackPlugin({
      template: './index.html'
    }),

    new webpack.HotModuleReplacementPlugin(),
  ]
};

Does Polymer not  support babel transpile?

When transpiling to ES5, you have to include custom-elements-es5-adapter.js for browsers supporting native Custom Elements (Chrome and Safari 10.1+)

@web-padawan is correct. Please load the custom elements es5 adapter as well and you can load ES5 transpiled code in Chrome and Safari.

@fanyer Did the include of custom-elements-es5-adapter.js fix the problem for you?
I have a pretty close configuration except that I use babel-loader 8 and @babel/preset-env. With and without the ES5 polyfill I get the error message:
custom-component.js:14 Uncaught TypeError: Class constructor PolymerElement cannot be invoked without 'new'
    at HTMLElement.CustomComponent (custom-component.js:14)
    at new j (custom-elements-es5-adapter.js:4)
    at CustomElementRegistry.value (custom-elements-es5-adapter.js:4)
    at Object.defineProperty.value (custom-component.js:26)
    at __webpack_require__ (bootstrap 6c5b87648fe743e36ebc:19)
    at window.JSCompiler_renameProperty (bootstrap 6c5b87648fe743e36ebc:62)

If you use @babel/preset-env try out this .babelrc config, it worked for me.
{
  "presets": [
    ["@babel/preset-env", {
      "targets": {
        "browsers": ["last 2 versions", "ie >= 11"]
      },
      "exclude": ["transform-classes"]
    }
    ],
    ["@babel/typescript"]
  ],
  "plugins": [
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"
  ]
}

@fanyer Have you solved this problem? I tried the above solution and it didn't solve it.


[StreamAnalytics] Update sdk to 2020-03-01-preview version

swagger pr: https://github.com/Azure/azure-rest-api-specs/pull/10673
tag: package-2020-03-preview

Add missing features for ASA streaming job
Add ASA cluster and private endpoint related sdk

@allenjzhang  addressed comments, could you help us to re-review that, thank you a lot.

Thank you for your recent update. Can you make two minor changes, and we will be all good.

Update the version number in assemblyinfo.cs
Add some meaning release notes in the csproj. They will show up front and center on nuget to give user context on the new release of libraries. It is particularly helpful since the major version has changed.

Thanks for your comments. Updated.

@allenjzhang addressed comments, could you help us to re-review that, thank you a lot.


Validate tails file hashes with revocation

When presenting proof of non revocation we need to fetch tails files and we want to validate the hash of downloaded tails files against the hash recorded in the revocation registry definition on the ledger to ensure the tails file hasn't been tampered with.
As part of AFJ's current process for downloading the tails files the revocation registry definition hash is supplied as an argument, but we need to generate the hash of the downloaded file and compare the two.
ACA-Py implementation: https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/revocation/models/revocation_registry.py#L189

This has been added now


789 slider styling improvements

Styles sliders on image manipulation controls so they appear underneath the caret of their respective icons. Displays the percentage represented by the slider to the right of the handle. Updates on reset.

Coverage decreased (-0.9%) to 44.092% when pulling 451615a7ec740ef2e1fbc512b9f7c5cde6c08719 on 789-slider-styling-improvements into 2688f8cbf47f4bc695dc3edcbfccd91b5b0a3578 on release2.1.

Hm. I need to write some tests for this.

Coverage decreased (-1.0%) to 44.082% when pulling ef61a86ecb515a75f9272f1dc39041afc88b6362 on 789-slider-styling-improvements into 2688f8cbf47f4bc695dc3edcbfccd91b5b0a3578 on release2.1.

Yes, we need to write tests, but we changed different widgets, which will get significantly modified by iiifManifestLayouts, which is why we haven't added tests yet.


Mekanism Energy Cube recipe conflict

The recipe for the elite cube unlike the other two improved ones doesn't require the tier below, as there is no NBT requirement. In addition the recipe for the elite cube is duplicated with the advanced cube as output from one of those, untested which one is produced due to the identical recipes.

the elite is meant to take the basic cube to craft, problem is some people made an advanced and then were upset they could no longer upgrade so I added the second recipe so they could upgrade the advanced. I may just redo both of these recipes soon to avoid this confusion.

Oops, it seems that referencing the issue number in the commit message closes the issue.
Reopening till the next update with the fix is released.


Referneces to api.kustomize.io

This repo references api.kustomize.io which seems to do the main work of this app, is that endpoint eventually also available somewhere?
Eventually @marccampbell? ;)

Oops: https://github.com/replicatedhq/kustomize-demo-api. (it's now public).
This repo will be Apache2, working with our team to add appropriate licenses to these repos.

Thx! I'll dig deeper ^^


help???when Assert.assertEquals() fails, the rest robotuim code can not run?????

From<EMAIL_ADDRESS>on July 18, 2012 23:32:45
the following code is:
Assert.assertEquals();
solo.goBackToActivity();
when Assert.assertEquals() fails, the next function does not run, why?
who knows the reason????
Original issue: http://code.google.com/p/robotium/issues/detail?id=295

From<EMAIL_ADDRESS>on July 18, 2012 23:48:13
Assert.assertEquals() true,run the next function.

From<EMAIL_ADDRESS>on July 19, 2012 10:16:26
That is how asserts work. You can save the result and use the assert last in your test case:
boolean saveResult = solo.searchtext();
...
...
...
Assert.assertTrue(saveResult);
Status: Invalid


backend: Remove folders first in CLI

Thank you for contributing to the Cohere Toolkit!

[ ] PR title: "area: description"

Where "area" is whichever of interface, frontend, model, tools, backend, etc. is being modified. Use "docs: ..."  for CI changes.
Example: "deployment: add Azure model option"

[ ] PR message: Delete this entire checklist and replace with

Description: a description of the change
Issue: the issue # it fixes, if applicable
Dependencies: any dependencies required for this change

[ ] Add tests and docs: Please include testing and documentation for your changes

[ ] Lint and test: Run make lint and make run-tests

AI Description

The pull request introduces a new function, delete_config_folders, to handle an edge case where pre-existing configuration and secrets folders are present in the config folder.
Changes:

Adds the delete_config_folders function to src/backend/cli/setters.py.
Calls the delete_config_folders function in src/backend/cli/main.py before writing template and configuration files.

Codecov Report
Attention: Patch coverage is 16.66667% with 5 lines in your changes missing coverage. Please review.

Project coverage is 75.47%. Comparing base (95d5639) to head (292e122).

Files
Patch %
Lines

src/backend/cli/setters.py
20.00%
4 Missing :warning:

src/backend/cli/main.py
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #738      +/-   ##
==========================================
- Coverage   75.50%   75.47%   -0.04%
==========================================
  Files         263      263
  Lines       11728    11734       +6
==========================================
+ Hits         8855     8856       +1
- Misses       2873     2878       +5

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Navigation leads user to the elixir stdlib but user can't navigate the stdlib

Environment

Elixir & Erlang versions (elixir --version):  1.13.4
Elixir Language Server version: v0.11.0
Operating system: macOS 12.4
Editor or IDE name (e.g. Emacs/VSCode):  VSCode
Editor Plugin/LSP Client name and version: ElixirLS v0.11.0

Current behavior

Open file containing IO.puts("")
ctrl-click on puts, navigate to the io.ex file from the stdlib

...
  def puts(device \\ :stdio, item) when is_device(device) do
    :io.put_chars(map_dev(device), [to_chardata(item), ?\n])
  end
...

Try to ctrl-click on :io.put_chars or map_dev but it does nothing

Expected behavior

Open file containing IO.puts("")
ctrl-click on puts, navigate to the io.ex file from the stdlib

...
  def puts(device \\ :stdio, item) when is_device(device) do
    :io.put_chars(map_dev(device), [to_chardata(item), ?\n])
  end
...

ctrl-click on :io.put_chars should lead to the erlang implementation; ctrl-click on map_dev should lead you to the implementation on io.ex

I can confirm that the issue is that vscode is not sending requests to the server at all


s3fs not installing properly

What happened: s3fs does not install properly. ModuleNotFoundError when I import s3fs in python. The error seems to have to do with bootcore: ERROR: awscli 1.18.130 has requirement botocore==1.17.53, but you'll have botocore 1.17.54 which is incompatible.
What you expected to happen: install s3fs successfully without any errors when I try pip install s3fs.
Minimal Complete Verifiable Example: pip install s3fs
import s3fs

Anything else we need to know?:
Environment:

Dask version:
Python version: 2.7.13
Operating System: Linux
Install method (conda, pip, source): pip

s3fs has not been released for py2 for a while now. You may be able to pin to specific old versions to make it work.

Thanks! Loading python3 made it work.


Add shrink action to Index Management

Signed-off-by: Naarcha-AWS<EMAIL_ADDRESS>Description
Adds the new shard action to Index State Management.
Issues Resolved
Fixes #444
Check List

[x] Commits are signed per the DCO using --signoff

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

I made a comment on the documentation issue providing more information on the alias object, sorry I should have commented here as well. I think it would be difficult for a user to figure out without documentation on the exact fields which can be included in that.
I know I am bringing this up late in the release process, if you do not have the time I am happy to revise the PR with more information on the template field and alias object and then you could provide additional technical language review?


Fix decompiler simplification

It looks like the use of generators was problematic for the simplification of code.
This PR should resolve #262

#262 looks fixed for what I was using.  #235 is still there, I'll look into it when I can.


Refactor tests and increase coverage

Besides login and model creation, we now also have tests for the models' view (for edition, duplication, and deletion.)
For details on all the changes, read each specific commit.
For the results of the tests, see the following videos.
https://user-images.githubusercontent.com/2768415/143379961-3317e13e-44a0-4a88-9cb2-d7f832d40b14.mp4
https://user-images.githubusercontent.com/2768415/143379965-92b2fc32-3461-49d9-8dac-46adb77815f1.mp4
https://user-images.githubusercontent.com/2768415/143379966-5251ad3a-f134-444a-b55e-dbde225b585f.mp4

Can anyone review this for me, please?

Can anyone review this for me, please?

@wlsf82 We just merged #263  to development branch.
I think it worth to merge development into your branch to check for conflicts and adjust the tests.

Can anyone review this for me, please?

@wlsf82 We just merged #263 to development branch. I think it worth to merge development into your branch to check for conflicts and adjust the tests.

@idmarjr I'm going to merge and fix the conflicts.

@idmarjr and @ArthurMota9, I've fixed it all and updated the PR description.
Can you review it, please?

@idmarjr and @ArthurMota9, I've fixed it all and updated the PR description.
Can you review it, please?

I recommend reading my commits (not only the title but also their descriptions.)


Remove image spec fork that was added to support ArgsEscaped non-OCI docker field

Root Cause:
Image-spec fork was added to our CRI branch to support the non-OCI docker image-spec field called 'ArgsEscaped'. ArgsEscaped is used by docker to determine how the image command should be interpreted. If ArgsEscaped is set, then the first element of the command array will be used as-is.
We would like to get rid of the dependency on the image-fork spec while we work on a cleaner fix that can be pushed upstream as well.
Fix:
Instead of relying on the image-fork spec and adding the ArgsEscaped field to our image spec, we try to read the ArgsEscaped value by making an extra json.Unmarshal call during getImage()
Testing
Manually tested the changes to make sure that the fix does not regress any behavior that the original fix was made for. I will be adding regression tests to the upcoming PR that has the complete upstream fix.

Since this is only a temporary fix that will very soon be replaced by the cleaner upstream fix, I will be adding regression tests to the upcoming PR instead of this one.

Does this refer to the fact that once https://github.com/opencontainers/image-spec/pull/892 gets in, we can remove this change?

Since this is only a temporary fix that will very soon be replaced by the cleaner upstream fix, I will be adding regression tests to the upcoming PR instead of this one.

Does this refer to the fact that once opencontainers/image-spec#892 gets in, we can remove this change?

I was referring more to your WIP changes that I am looking into as your changes seem to handle all cases and I was wondering if we just wanted to have the upstream fix in our fork too and that's why I mentioned it. But after giving this a second thought, it should not be a problem to leave these changes as is since we longer have dependency on image-spec fork.

Since this is only a temporary fix that will very soon be replaced by the cleaner upstream fix, I will be adding regression tests to the upcoming PR instead of this one.

Does this refer to the fact that once opencontainers/image-spec#892 gets in, we can remove this change?

I was referring more to your WIP changes that I am looking into as your changes seem to handle all cases and I was wondering if we just wanted to have the upstream fix in our fork too and that's why I mentioned it. But after giving this a second thought, it should not be a problem to leave these changes as is since we longer have dependency on image-spec fork.

I think even with my WIP changes, we still need a way to determine if ArgsEscaped is set on the image config, so we will still need this change (or ArgsEscaped added to image-spec). IIRC this same change was part of my WIP.

Since this is only a temporary fix that will very soon be replaced by the cleaner upstream fix, I will be adding regression tests to the upcoming PR instead of this one.

Does this refer to the fact that once opencontainers/image-spec#892 gets in, we can remove this change?

I was referring more to your WIP changes that I am looking into as your changes seem to handle all cases and I was wondering if we just wanted to have the upstream fix in our fork too and that's why I mentioned it. But after giving this a second thought, it should not be a problem to leave these changes as is since we longer have dependency on image-spec fork.

I think even with my WIP changes, we still need a way to determine if ArgsEscaped is set on the image config, so we will still need this change (or ArgsEscaped added to image-spec). IIRC this same change was part of my WIP.

I updated the description. Since I am in the process of adding regression tests to your WIP code changes, I'll check them in as part of that PR.

If I am understanding correctly, the blob data in the content store is set by docker, so we don't need to set that when pulling an image, right?

That is right. We are only trying to read argsEscaped from the blob data we got in


Loading circle appearing in chapter

Steps to reproduce

Open any chapter
Leave Neko by changeing app, locking phone, etc.
Go back to Neko, chapter should still be open
Loading circle appears in the middle of the screen

Expected behavior
Loading circle shouldn't appear
Actual behavior
Loading circle appears.
Disappears when going back out of the chapter and opening it again or when changing the chapter (e.g. ch. 2 -> ch. 3)
Crash logs
No response
Neko version
2.13
Android version
Android 12
Device
Fairphone 4
Other details
Started happening after last update
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have tried the troubleshooting guide.
[X] I have updated the app to the newest version Latest.
[X] I have filled out all of the requested information in this form.

Bug still persists when switching between Neko and other apps in newest version

@philippgaida let me know if this is still an issue for scenario 2


Leaks

was testing the app for leaks, most of them are from flurry :cry:

@hamdullahshah which version of the SDK are you using?

7.5.1 as i'm using it using pod

@hamdullahshah so, in looking at this, this is actually the result of a native C library that we include, not necessarily the code we've written.  In terms of fixing it up, the jury is still out, but the library may just be removed a some point.
Sorry for the inconvenience.

This was taken care of in the latest release.  Let us know if you see anymore.


How can I add Frontend routes

I have tried but didn't work, may be am missing something.

vue router

@mayunhai  I know about Vue Router am just wanna know is there any simple flow where I can add frontend routes(I have put asyncroute which does not work) without changing Route Logic.

@Faizanq Do you add roles to  meta? This is my code.
{         path: 'partner',         name: 'partner',         meta: { title: 'partner', icon: '', roles: ['admin'] },         component: () => import('@/views/clientManage/partner/index')   },

Thanks, @Harry-qi   Will check


The prompt after creating a scheduled backup is inappropriate

Describe the Bug
When create a scheduled backup successfully,the prompt is inappropriate

/assign @lysign

/milestone v1.1.0

/assign @moweiwei


adding new resources to cicd script

Adding new resources as mentioned here: https://github.com/aws-ia/cloudformation-github-resource-providers/issues/18
Let me know if I have missed anything and this is the right format, also one thing I was unsure of is the GITHUB_REPO_ID value as this needs to be a number not a string, if this has to be as string and fails, this would mean it would have to be changed on the resource side.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@lukiwlosek Where do I find the numeric github repo id? I'm used to referring to repos by name.

I think I found it: https://stackoverflow.com/questions/13902593/how-does-one-find-out-ones-own-repo-id


Dependencies not specified

All I get is a dist folder with a build file in it but the dependencies it needs aren't present

The dependencies for this project are declared within the bower.json and package.json file. How are you installing this library?

Please see the note on your other ticket (#4).

Please see comment in #4 for gratitude :)


The font size is too small in Macosx Monterey

Godot version
4.0 alpha 12
System information
Macosx Monterey 12.4 on Macbook Air M1
Issue description
When I used Godot 3.4 and reopen Godot 4.0 alpha 12, I found the font is too small to see it clearly.
Steps to reproduce
Open Godot 3.4, close godot 3.4 and open Godot 4.0, the bug will appear.
Minimal reproduction project
No response

Can you take comparison screenshots between 3.4 and 4.0?

This is the screenshot of Godot 3.4:

and this is the screenshot of Godot 4.0:

The font size of the Godot UI is too small relative to Godot 3.4.

It looks like something related to seamless display scaling isn't working as expected. Are you using a multi-monitor display by any chance?
cc @bruvzg

I use both Godot 4.0 and Godot 3.4.
When I set  Interface > Editor > Display Scale to 200% in the Editor Settings, the UI of editor seems good now.

but when I play the scene, it seems that all nodes in the scene was scaled to 50%:

Open Godot 3.4, close godot 3.4 and open Godot 4.0, the bug will appear.

What's your display configuration (single/multiple, scaling mode of each display)? Also, how exactly multiple copies of Godot are installed (locations, bundle names).

You can see that the text of the label "Hello world" was too small.

This is expected, we do not have auto DPI scaling implemented for the project UI, it's only done for the editor, so you should track DPI changes and adjust UI scaling yourself. Or you can disable hiDPI support in the project settings (it was disabled by default in 3.x).

I use a single display in my Macbook air.
When I disable my hiDPI setting for my project, all things seems good now, thank you @bruvzg .

Or you can disable hiDPI support in the project settings (it was disabled by default in 3.x).

Note that doing this is not recommended for production games, as lowDPI fallbacks suffer from all kinds of issues. Instead, follow the advice outlined in Multiple resolutions so your game can correctly display at any resolution.

I've been using Godot 4.0.beta 2-8 on macOS 13.0.1 with two hiDPI monitors (with different scales even) and apart from some rare instances (like the color picker visualization icon) I've not seen any issues with retina interface scaling in the editor. So perhaps this is fixed for you as well @pingzh1215 and can be closed?

Closing per the above comment. Please comment if you can still reproduce this on the latest Godot version.


Failed to convert

Trying to convert my model from TF to Onnx, i keep getting the following error:
"Cannot infer shape for xxxxx"
should i somehow set the shape for the tensor? or is this a bug?

This repo has changed significantly since this issue was first raised, and further changes are upcoming. As such, I'm going through and closing many of these stale issues which sat unassigned for a long while.


Reference levels - trophic level biomass ratios

At the end of the Reference values, thresholds for defining good ecological condition, minimum and/or maximum values sub-chapter it says "The choice of 40% is arbitary". Consider changing this to something a bit stronger worded, although it for sure is somewhat arbitrary. What about: "The choice of 40% is somewhat arbitary and based on the best guess, or intuitive understanding or the authors, and reflects the point where there are either too many or too few consumers to maintain important resilent ecosystem functions over time, such as avoiding excessive growth or depletion of one of the trophic levels with possible cascading effects through the ecosystems".

The lower reference value is not directly stated in the text I think, but it is introduced when truncating the %difference to 100%|-100%, i.e. a doubling or halfing of the expected biomass for the highest trophic level as compared to the expected biomass will translate to worst possible condition. This is perhaps a bit strict?
For example, an NPP of 5-10^6 kg C km-2 y-1 predicts a herbivore biomass of
(5-10^6)^0.47*0.643 = 905 kg km-2
Perhaps this is something like 6 reindeer. Having 12 or 3 reindeer instead does not sound like such a big deal...

The %difference valiable is not normalised to the [0-1] scale, and probably this is why +-40% and -+100% were chosen as the reference values, but as I argue above, this excact truncation is perhaps not needed and we could have a wider tolerance for what is the worst possible condition, and then the 40% threshold value would ease up as well, cause now it is probably way to strict.


Should unit tests live outside of the package?

We are shipping our the tests folder inside of the pymmmc package. I don't think is is necessary or desirable. I propose that we move the tests folder to the root directory instead.
Current organization:
root/
└─> pymmmc/
└─> tests/
Proposed:
root/
├─> pymmmc/
└─> tests/

Agree. I believe this means that the tests are not packaged up into the pypi build, which is good.
Probably want a clear split (with folders?) between mmm and clv tests.

Closed by #116 (there was a typo)


Remove command-line flags page from query UI

This PR closes #248
Changes
I removed the command line flags panel from the query UI. Since there is now only one section to the Status drop-down, I removed it to only keep the Runtime & Build Information panel in the global menu

Awesome, thanks for this! I think it makes sense but I would vote for not changing the Status page more.
The reason is that we copy the UI from Prometheus and it easier if we do as small number of our changes as possible.
Can we just remove command line flags? (:

Ok i will leave the status page as it is in master

@bwplotka status dropdown is back


How to fix such bug about workbench core

Issue Type: Bug
The thing is, the VS code pop up a message saying disable some features, I clicked yes. Then when I did local compile for my Photon, the message below is shown. I don't know how to fix it.
"Could not find task: Compile application (local) for /t:/OfficeSoft/EE1301_IoT_VS/IoTlab3/111"
Extension version: 1.10.0
VS Code version: Code 1.40.1 (8795a9889db74563ddd43eb0a897a2384129a619, 2019-11-13T16:49:35.976Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2808)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.89GB (0.42GB free)

Process Argv

Screen Reader
no

VM
0%

Sorry, more information is needed. What language is that? What extension do you use?


feature: add architecture for security

Replaces #216
Adding a way for developers to add authentication/authorization to node server via a special security plugin.

This looks good, but needs

[ ] documentation (minimum)
[ ] a sample implementation (preferably)

For the sample implementation is the sk-simple-token-security enough? Or you want something else?

That's enough for now I think.

Fixed some typos, added a few words to the doc, squashed and merged in f16111ccd05901651ce6986743c59a9f49a1381b and 3802519d5039b3305f0061380f97c876534c8f1b.
Yay!!!!


Make a docker image

https://github.com/LiberTEM/LiberTEM/packages?package_type=Docker
The GitHub "packages" feature is now generally available, which means we can easily publish docker images of LiberTEM directly into the GitHub docker registry. A possible starting point would be the AppImage build script, which could easily be converted to a Dockerfile. Good thing is we can skip the miniconda setup and directly start with the miniconda:alpine image, for example.

The Dockerfile in #528 contains a commonly used "hack" to enable faster building by first installing all dependencies and then installing LiberTEM itself in a separate layer. That means the dependencies are cached and don't need to be installed on each build. But it also means we need to have a requirements.txt file, which I currently manually generate using pip-compile from pip-tools. Needs to be run in the CI pipeline to make sure the requirements are always up to date!

Needs to be run in the CI pipeline to make sure the requirements are always up to date!

This is now also implemented.

Now that we have #1070 and integration in web services becomes more prominent, we could think if publishing a Docker image would make sense. We could analyze what kind of image would help people. I'll put it in 0.9 for discussion, together with #1085

As a side note, the current image contains a custom ipyparallel version, which we likely don't need in a released Docker image.

As a side note, the current image contains a custom ipyparallel version, which we likely don't need in a released Docker image.

Agreed - the docker image also installs all testing dependencies, which should not be present in a release docker image.
Also, there is a new ipyparallel release out that should include our fixes - the custom version is no longer needed. I'll quickly update the Dockerfile.

Hm, so does it make sense to support two independent docker images, one published for "latest release", and one internal for the CI pipeline? Or is it better to base our internal CI image on the external one? In most cases it will share the same base dependencies minus the testing ones, but with some notable exceptions like pinning in the release for incompatibilities.
How do we test a "latest release" public Docker image, by the way? I am a bit wary that installing the "latest master" plus testing requirements over a base image might hide issues with package compatibility in the base image, so it would be advisable to run some simple scripts on a few test files by just copying them onto the image, instead of using a package manager to install test requirements etc. What are your thoughts on that? How often should we validate the public image against latest PyPI and distribution releases? Daily, only with RCs, with each run of the pipeline, when sth changes upstream, ...?

Hm, so does it make sense to support two independent docker images, one published for "latest release", and one internal for the CI pipeline? Or is it better to base our internal CI image on the external one? In most cases it will share the same base dependencies minus the testing ones, but with some notable exceptions like pinning in the release for incompatibilities.

Currently, the CI docker image is only used for the "dist" and ipyparallel tests. So whatever is in there is not thoroughly tested, and our tests do not test the actual interface that will be exported by the production docker image, which is libertem-server and the web API.
One possibility to test the production image would be to run the integration tests against it, in CI. So everything currently under tests/server/ could, in theory, be run against an instance of the production container.
For the non-ipyparallel dist tests, we could also use the production image for the scheduler and worker containers. The test requirements are only needed in the tests container, where we actually run pytest etc., and ipyparallel is needed in the tests container and in the ipyparallel engine / controller containers.
So the whole CI process would be:

In a new CI stage, before testing, build the libertem/libertem image and tag it with the revision, so an image called libertem/libertem:21fd74df will be pushed to docker hub. Let's call this new job docker_build. We can also build the "dev" image here, which contains both ipyparallel and test requirements, to easily share layers without having to pull the image again in another job. We can figure out what layers we want to share - theoretically we can share most of the layers of the build container - just before installation of LiberTEM itself.

The distributed_tests job depends on the docker_build job (if possible by dependencies, like gitlab supports; otherwise we have to run docker_build before all other jobs) and uses both the "dev" and the production image libertem/libertem:21fd74df.

Add a new test job, which runs the web API integration tests against libertem/libertem:21fd74df

In the deploy stage, if all tests succeeded, pull the libertem/libertem:21fd74df image and tag it appropriately, for example as libertem/libertem:continuous, libertem/libertem:latest, libertem/libertem:v0.8.1rc1, libertem/libertem:stable etc. (one or more of these tags could be used - depending on the git tag / branch etc.)

I am a bit wary that installing the "latest master" plus testing requirements over a base image might hide issues with package compatibility in the base image, so it would be advisable to run some simple scripts on a few test files by just copying them onto the image, instead of using a package manager to install test requirements etc. What are your thoughts on that?

Hm, I would prefer running "real" tests - copying over test files etc. means we won't have pytest, so it will either suck to write tests, get results etc. or we will end up re-inventing pytest as we go along... :(

How often should we validate the public image against latest PyPI and distribution releases? Daily, only with RCs, with each run of the pipeline, when sth changes upstream, ...?

What exactly do you mean? The production image is static - it doesn't need to be re-validated. Only on a rebuild of the image, it needs to be validated. Would you be happy with the CI approach outlined above?
Btw. I had already started on the "production container" work in a local branch, let me know if you want to work on any of these aspects, and also if you think these are a good idea!

Ah OK that clears it up! So if I pull libertem/libertem:v0.8.1 I will always have exactly the same image  and not re-baked with the most recent PyPI releases etc?
The concept sounds great! Running the server and dist tests against a production container would be perfect, as you write it really tests the endpoints we care about. This really mimicks the actual use since someone also might want to fire up LiberTEM workers and the scheduler on a cluster using a Docker image.
Maybe providing a Singularity container that kicks off a libertem-worker or dask-scheduler would also help with the mess on HPC systems regarding module activation vs Python environments, in the future?

@shabihsherjeel this Issue is probably also relevant for you?

Ah OK that clears it up! So if I pull libertem/libertem:v0.8.1 I will always have exactly the same image and not re-baked with the most recent PyPI releases etc?

Yup - good for reproducibility and compatibility, kind of bad for security (i.e.: don't expose containers using the old images to the internet!)

The concept sounds great! Running the server and dist tests against a production container would be perfect, as you write it really tests the endpoints we care about. This really mimicks the actual use since someone also might want to fire up LiberTEM workers and the scheduler on a cluster using a Docker image.

:+1:

Maybe providing a Singularity container that kicks off a libertem-worker or dask-scheduler would also help with the mess on HPC systems regarding module activation vs Python environments, in the future?

Yeah - although IIRC you can trivially create a singularity container from an existing docker container, so I don't know if we even have to publish one. That would be something to look into - is there a singularity registry we can use freely, or do we need to use FZJ resources for this?
I don't think there is a need to create separate images for workers / schedulers and libertem-server though - they are all available from the same venv anyway, so you can run things like this:
docker run --rm -it libertem/libertem:latest /venv/bin/dask-scheduler
docker run --rm -it libertem/libertem:latest /venv/bin/libertem-worker <scheduler-ip>
# etc.

The same should be possible with the singularity container IIRC.

Maybe providing a Singularity container that kicks off a libertem-worker or dask-scheduler would also help with the mess on HPC systems regarding module activation vs Python environments, in the future?

Yeah - although IIRC you can trivially create a singularity container from an existing docker container, so I don't know if we even have to publish one. That would be something to look into - is there a singularity registry we can use freely, or do we need to use FZJ resources for this?

Ok, probably a good time would be if some user or us get annoyed enough with modules to look into Singularity. :-)

I don't think there is a need to create separate images for workers / schedulers and libertem-server though - they are all available from the same venv anyway, so you can run things like this:
docker run --rm -it libertem/libertem:latest /venv/bin/dask-scheduler
docker run --rm -it libertem/libertem:latest /venv/bin/libertem-worker <scheduler-ip>
# etc.

The same should be possible with the singularity container IIRC.

Yes, perfect! An easy way to guarantee the same Python environment for all components. :-)

Yeah - although IIRC you can trivially create a singularity container from an existing docker container, so I don't know if we even have to publish one. That would be something to look into - is there a singularity registry we can use freely, or do we need to use FZJ resources for this?

Ok, probably a good time would be if some user or us get annoyed enough with modules to look into Singularity. :-)

https://sylabs.io/guides/2.6/user-guide/singularity_and_docker.html
Also, this is how to use GPUs in the image: https://sylabs.io/guides/2.6/user-guide/singularity_and_docker.html
Probably doesn't hurt to just include it in the image since we are using GPUs increasingly often?


Deleting Icepak Surface Plot Fails

This command fails:
ipk.post.delete_field_plot("Surface_Temps_Chassis")
But this one works just fine:
ipk.post.field_plots["Surface_Temps_Chassis"].delete()
Any test model should do, please let me know if you have any questions.

@ansys-icepak Fixed in #800

@maxcapodi78 working great now, thanks!


add Api test for adding space managers

Description

[x] Add Api Tests for space managers

Problem
the currentl logic parsing the json file and using specific key -> values breaks when we have unsorted lists.
We need to refactor this @phil-davis @ScharfViktor
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[x] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[x] Acceptance tests added
[ ] Documentation ticket raised:

:boom: Acceptance test localApiTests-apiSpaces-ocis failed. Further test are cancelled...

Thanks for bringing it up. I'll try to fix it in this PR

We can't share space with the manager's role. It still doesn't work for me:

this is broken in ocis master but already fixed in reva https://github.com/cs3org/reva/pull/2533/commits/6ac2dfaa17c16cb246668250147aaaeae3b2cc9a

I liked it because I could see the answer structure in the test

but I don't like 0 and 1. I could do something like this:  https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiCapabilities/capabilities.feature#L86 but it wouldn't make much difference.
I added a check that user has role in response. I tried combining these checks, but it didn't work for me

LGTM, I cannot approve because I created it. Feel free to approve and merge.

LGTM, I cannot approve because I created it. Feel free to approve and merge.

I cannot also because there is no "Approve button" available

Needed a rebase.

Thank @micbar for rebase. I merged it


Convert solid.js to use JS Standard coding style

LDNode has been recently converted to use the JS Standard coding style.
Convert solid.js to match.

Implemented with PR #10 and PR #11. Closing.


Port 3000-3001 bei wireshark and homepage konflikt?

HI
i install portainer via ADD template ... assign the ports from the free area via 50000-50001 and after creating it the only thing this template does... is to continue hammering on the 3000 port? what is going wrong here?

nginx: [emerg] bind() to [::]:3000 failed (98: Address in use)
nginx: [emerg] bind() to <IP_ADDRESS>:3000 failed (98: Address in use)
nginx: [emerg] bind() to [::]:3000 failed (98: Address in use)
nginx: [emerg] still could not bind()
nginx: [emerg] bind() to <IP_ADDRESS>:3000 failed (98: Address in use)
nginx: [emerg] bind() to [::]:3000 failed (98: Address in use)

Hey @sk2eu - You need to raise this upstream, I don't write the individual templates, just curate them into a single source.
https://github.com/Lissy93/portainer-templates#raising-issues


Limit entities per user

** Which Category is your question related to? **
Auth, API
** What AWS Services are you utilizing? **
Cognito, AppSync
** Provide additional details e.g. code snippets **
Is there a way to limit the amount of entities a user can create?
Example 1.
Let's say I want to maintain a settings object that has information about the users choices:
type UserSettings @model @auth(rules: [{allow: owner}]) {
  improvesApp: Bool!
  acceptedPrivacyPolicy: Bool!
  preferredTheme: String!
}

Is there a way to ensure that only one of these entities can be created per user?
Example 2:
I created a SaaS software that limits the usage of the owner based on their tier. Let's say its a Todo app startup. Is there a way to limit the models the user can create?
Preferred solution:
A great way would be if there was a @limit directive for this. Basically for example 1:
type UserSettings @model @auth(rules: [{allow: owner}]) @limit(field: owner, amount: 1) {
  improvesApp: Bool!
  acceptedPrivacyPolicy: Bool!
  preferredTheme: String!
}

And for example 2 (using Cognito groups).
type Todo @model @auth(rules: [{allow: owner}])
  @limit(field: owner, limit: 10)
  @limit(field: owner, group: 'Paidtier', limit: 1000)
  @limit(field: owner, group: 'Premiumtier', limit: null)
{
  id: ID!
  title: String!
}

Example two could result in every user having a limit of 10 Todos, except if they are in the paid tier, then they can create 1000 except when they are in the premium tier, then they could create infinitely many.

What is the current suggested way of doing this right now? Custom resolvers?

Any suggestions on this? @rodripf did you came out with a solution?

This would be amazing..... since this is not implemented yet, can you recommend an alternative solution?  Thank you


UI: watch3 segfault on WSL2 ubuntu 20

Describe the bug
Freshly pulled and built openpilot. Attempted to run ./selfdrive/ui/watch3 to view a replay alongside plotjuggler's data causes a segfault.
ui and _ui both encounter the same issue. spinner works just fine.
OS Version
Ubuntu 20.04.5 LTS WSL2
openpilot version or commit
98cac3578b2d0d2e4db283a728f647bc71825bfb
Additional info
No response

We don't target Windows, and ui especially is well tested on Ubuntu. If you can reproduce on Ubuntu, feel free to re-open.

FYI there seem to be frequent/intermittent issues with WSL2 and many GUI apps not limited to openpilot. I myself have this trouble with UI and plotjuggler from time to time. Try launching as LIBGL_ALWAYS_SOFTWARE=1 ./watch3


salt_apt_repo in provisioner/salt_solo.rb does not exist

Hello,
in kitchen/provisioner/salt_solo.rb, we can see
        salt_apt_repo: 'http://apt.mccartney.ie',
        salt_apt_repo_key: 'http://apt.mccartney.ie/KEY',

which does not exist.
I think we can use http://repo.saltstack.com/

I did a PR ( #89 ) that would address this.

Seems good to me if Ubuntu is the default image used, this apt repo is the good one.


Suggestion: Reorganization of Middleware Logic and Structure

Midlewares work great already in Redux.
However, as pertains this issue we all discover that there are edge cases to the way it is works as implemented via nested closures (2 of them). I do understand why this is necessary owing to the way Redux works. However, this level of composed functions does unsettle some devs who would like to use Redux extensively and i was wondering if the code structure and logic (applying the middleware as some sort of decorator around the store.dispatch method) can be reorganized a bit to look like the middleware implementation in this project.
Here is the Radixx README file which contains example code.
This is just a suggestion... any takers ?

If you're proposing that we change the middleware signature to be a single function with multiple args instead of the current nested/curried function structure, then no, we're not going to change that.  See the "Design Decisions" FAQ entry on why middleware are written as curried functions for links to prior discussion.


Invalid check response error

I changed my password today and forgot to update my related .env variable, then ran into the following issue.
The HTTP response body was...
{"error":{"message":"User Not Authenticated","detail":"Required to provide Auth information"},"status":"failure"}
Which led to...
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "/...project-path.../hello.py", line 58, in main
    incidents = await unresolved(app)
  File "/...project-path.../hello.py", line 43, in unresolved
    incidents = await r.get(selection)
  File "/...project-path.../venv/lib/python3.8/site-packages/snow/resource/__init__.py", line 170, in get
    return await self.reader.collect(
  File "/...project-path.../venv/lib/python3.8/site-packages/snow/request/helpers/read.py", line 21, in collect
    _, content = await GetRequest(self.resource, query=selection, **kwargs).send()
  File "/...project-path.../venv/lib/python3.8/site-packages/snow/request/core/get.py", line 16, in send
    return await self._send(**kwargs)
  File "/...project-path.../venv/lib/python3.8/site-packages/snow/request/core/base.py", line 102, in _send
    content = await response.get_content()
  File "/...project-path.../venv/lib/python3.8/site-packages/snow/request/core/base.py", line 36, in get_content
    if "error" in content:
TypeError: argument of type 'NoneType' is not iterable

It appears the async def get_content(self) method of the Response class is checking for "error" in the content variable, which is None because the content = ujson.loads(body).get("result") just before it is selecting the "result" key -- not "error" key.

I submitted pull request #43 for this issue. I am not experienced with Git/Github, so please point out if I have not done something correctly.

Cool, thanks. I'll take a look shortly.


Allow inline comments

Looks like inline comments in .env aren't handled?
e.g a .env containing the following:
LIMITER_MAX_CALL=50 # limit number of calls to this value per LIMITER_TIME_INTERVAL
returns in env
{
  ...
  LIMITER_MAX_CALL="50 # limit number of calls to this value per LIMITER_TIME_INTERVAL"
  ...
}

Ideally everything from "#" onward should be stripped when parsing.

sure I'll add this, one sec

actually I don't want it to be breaking, so not going to add it for now.
PR welcome if you want to do it in a way that's super clean


Issue in FOR Iteration expression

Hi,
While doing the ABAP week  2 challenge, I realized that the interpretation of the statement INDEX INTO <var_index> is wrong when using this same index variable in a nested FOR Loop.
For example in execism the table combined_data got 9 rows.

Then I used the same method in my dev environment and it worked:

Could you please explain to me what is the problem?
Many Thanks!
Idriss Mançour-Billah

Many thanks, now it works.
Idriss


Use latest release

Update to use the latest release which most folks have pulled.

@jordansissel, do you think you could merge this?


HiveD: intra-vc preemption after restart

If a restarted scheduler finds that the quota of a certain type of cell is insufficient, it will try to preempt (downgrade) pods with lower priority from the VC.
Tested on the 15 testbed.

Add an unit test for this issue?

Refers to: subprojects/GOPATH/src/github.com/microsoft/hivedscheduler/pkg/algorithm/hived_algorithm.go:24 in db176df. [](commit_id = db176df94965cafa106096557bf7924e31a85620, deletion_comment = False)


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


🕸 Implement a Glue Crawler to Recreate CaDeT Metadata from Replicated Bucket

User Story
While we are replicating the bucket data across accounts to allow CaDeT data to be visualised via QS, we also need to replicate the Glue metadata in order to make the data usable and allow access management via LF.
The metadata should be identical to the Glue information held in the origin account.
Value / Purpose
Replication of metadata rather than doing a bulk extract and copy would ensure greater fidelity, and allow more regular synchronisation when new data is added or old is removed. While copying metadata could be a viable backup plan, CaDeT was partially selected because its structure makes recreation of metadata via crawling a quicker and more robust approach.
Useful Contacts
Jacob Hamblyn-Pike, Julia Lawrence
User Types
Data Engineers, AP Customers
Hypothesis
Regularly running the crawler would allow us to maintain the best level of parity with the orgin bucket for QS users.
Proposal

Using terraform, design and implement a glue crawler which replicates CaDeT metadata in the Analytical Platform Compute Ireland region.
Validate the output against the original metadata
Agree crawling schedule

Additional Information
This story is hinging on the assumption that a crawler is all that is needed to recreate the metadata. If this turns out to not be the case, we will need to pivot to a different approach. Two backup options are extracting and coping metadata and running CaDeT workflows twice. Once against the origin bucket and once against the new bucket.
Definition of Done

[ ] Implement proposal
[ ] Code reviewed
[ ] Team reviewed
[ ] Follow-on stories captured

#5958 adds CaDeT replication to the analytical-platform-compute-development account to allow manual / more flexible changes within the account for testing out crawler / metadata setups.
This requires minor changes to the AP-compute MP environments to account for this change. After that we will be testing out crawler setups (see doc and discussion)

Requirements for setting up crawlers:

[ ] IAM role set up with adequate glue permissions. Default (set up via console) is:

AWSGlueServiceRole
and a policy granting "s3:GetObject" and "s3:PutObject" within database directory

[ ] IAM role is added as a Lake Formation Administrator
[ ] Databases are created in Glue

(naming convention? {domain}_{database_name}?)

Initial results of setting up the crawlers:

Unpartitioned Hive tables were successfully crawled and tables were created
Partitioned Hive tables were not able to be crawled properly
Iceberg tables were also not able to be crawled properly

Testing scripts were set up to pull the Glue metadata for data sources in APDP and push the metadata to the Glue catalog in APC-development. Testing was:

successful when creating a partitioned Hive table in APC-development, after running MSCK REPAIR TABLE <table_name> to handle the partitions in the new table
unsuccessful when creating Iceberg table.

Next step will be to revisit Glue crawlers for Iceberg data sources by referring to this documentation.

Crawling Iceberg Tables:

Crawling delius (contains Iceberg tables):

Default set up: generated 1000 tables, with metadata files and partitions becoming distinct tables
Explicitly setting the table level to 6 (level in bucket for the table_name={} directory) led to failures because files at level 8 (actual file level) are not consistently named or structured. This is because level 7 has data/ and metadata/ folders containing different structured files.

Iceberg ingestion via API may be the only way to resolve the presence of different file structures with a Glue crawler, as this allows glob pattern exclusion from crawling
Using the API still won't resolve the issue of the metadata files pointing at the source location in the data account

JHP found that there are references in plaintext JSON files as well as in the snappy compressed AVRO files to the original S3 location of the metadata files (in the source account)

LakeFormation Notes:

Setting up permissions for adding Data Lake Location required adding Trust Policy assumption by the lakeformation.amazonaws.com service to the IAM policy we wanted to use.
Granted lake formation permission to the manual glue role set up for database / table / lakeformation location registration
Creating iceberg table via the Lake Formation console (AWS Lake Formation > Tables > Create table) in APC-dev didn't work. It gives the following error: AccessDeniedException (status: 400): Access denied while creating metadata file in s3. This happens when trying to register the table from S3 location in APC-dev or in APDP.

The same error is encountered when trying to register the Table through the Glue console (AWS Glue > Tables > Add table)
Note: 'Compaction', 'Snapshot retention', and 'Orphan file deletion'  were disabled when attempting to register the table as they may cause file changes not reflective of the tables registered via CaDeT.
Note: I didn't grant s3:DeleteObject permission on the mojap-derived-tables bucket policy of the role used to register the Data Lake Location, even though this is recommended.

It looks like a 'resource share' might be a viable option (sharing the Glue Table from the source catalogue to the destination Lake Formation), but that may require Lake Formation in the source (APDP) account.

We gave up on using crawlers and using replicated data within the destination account (analytical-platform-compute-dev, aka APC-dev). Instead we went back to exporting Glue catalog metadata from the source account (analytical-platform-data-production, aka APDP) and creating tables using this metadata within the destination account. Prototype python scripts are used to iterate over databases, and repair hive tables to restore their partitions in the new catalog (not necessary for Iceberg tables).
We managed to get this working with same-region catalog copy (Ireland -> Ireland), and also cross-region catalog copy (Ireland -> London). After Granting QuickSight user query permission via LakeFormation, we were able to query data via QuickSight in either destination region.


Disable for certain type of files

Currently, the virtual column is shown on every window. It would be nice to disable certain windows like Telescope, NerdTree, the terminal etc...

You can already do this with filetype plugins.
Just turn of colorcolumn in ftplugin/foo.lua were foo is the filetype you want.
Just like vanilla Neovim

I am running into this with markdown files and I had to completely uninstall virt-column 😢
I love this plugin, but reaaaaally need my highlighting in markdown files to not break. I'm happy to help troubleshoot, @lukas-reineke , if you ever wanted to tackle this.

Sorry, I forgot to comment here. Since 1.5.0 there is a setup_buffer function that you can use to configure a buffer. If you are using the virtcolumn argument instead, use an autocmd or ftplugin with setup_buffer to overwrite the settings for specific filetypes.

Thanks for the response Lukas! I feel really bone-headed; I'm not seeing how to actually "disable" everything about virt-column for markdown files, for instance; using setup_buffer().  Any thoughts around that type of a use-case?

There are 2 cases

You are using vim.opt.colorcolumn
In this case, you want to do vim.opt_local.colorcolumn = "" in the markdown ftplugin
You are using the virtcolumn argument in the setup function
In this case, you want to do require("virt-column").setup_buffer { virtcolumn = "" } in the markdown ftplugin


fixes: upgrade dependencies based on dependabot recommendations.

We are going to close this merge-request and open a new one with a different configuration.


Duplicate headers error

In a document like:
# Changelog

## [14.0]
### Breaking
- foo

## [13.0]
### Breaking
- bar

The second Breaking header is reported as duplicate. I think it doesn't make sense since it's under different parent header.

@rchl thanks for reporting. This is a known problem but the solution is not obvious to me. The gist of the issue is that when you have an anchor link xxx the heading is not qualified by its path but only by its name. This is in particular what GitHub expects.
GH internally deals with this by adding a -1, -2, -n suffix but then it's super easy to mess up the links when you add yet another heading.
Perhaps the severity should be downgraded to a warning or maybe we need a way to turn off this diagnostics for a file.
Anyhow, I'm open to more ideas.

One potential solution could be to turn "duplicate heading" error into an "ambiguous link" error. This way when there are no links to the heading, no diagnostics will be raised.

That sounds good to me.
But I also want to point you at https://raw.githubusercontent.com/rust-lang/rust-analyzer/bd7dfac5ebbd8ba3bd63384000759fb4bb49b329/docs/dev/README.md which also reports duplicate headers even though those don't seem to be duplicated.

But I also want to point you at https://raw.githubusercontent.com/rust-lang/rust-analyzer/bd7dfac5ebbd8ba3bd63384000759fb4bb49b329/docs/dev/README.md which also reports duplicate headers even though those don't seem to be duplicated.

@rchl the problem there is a "duplicate title". The expectation is that there should be just one H1 header aka the title that names the document and then the rest of the headings are H2 -- H5. When there are multiple titles in the document you can't unambiguously use e.g. wiki-links.
But then again, this problem seems to have the same treatment  -- just redo heading diagnostics as "ambiguous link" diagnostics. The side-effect is that if you're unaware of the requirements on headings, wiki-link- and cross-doc completion can act really weirdly. But perhaps this is a better UX anyway then expecting random markdown document to conform to the ideal document structure.

I'm not the best person to discuss that with as I'm not really that familiar with this stuff and frankly those issues don't typically matter in markdown files that I'm working with.
That said, would it make sense for the "duplicate title" error to be a bit more descriptive? If it would say, for example, "Duplicate first-level header"

Yeah, that's fine. I think high-level ask is clear. I'll look into improving diagnostics UX.

Resolved in https://github.com/artempyanykh/marksman/releases/tag/2022-09-03


Update docs for sameSite option

Description

Just updated docs for sameSite option.
Ref: https://github.com/Shopify/hydrogen/blob/ee370be6d74b330db78d95b85f1733c8ca3eb2d7/packages/hydrogen/src/foundation/Cookie/Cookie.ts#L16

Before submitting the PR, please make sure you do the following:

[x] Read the Contributing Guidelines
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
[x] Update docs in this repository according to your change

@rennyG Do we need to update other files?

I did a search on this key/value in the shopify-dev repo, and it looks like no manual changes required there. When this PR is merged, though, we'll want the changes ported to shopify-dev. Let me know if you need a hand with that.


Mapping of interface types for search

I'm not sure I am following the configuration needed to allow searching via interface types.
I want separation of concerns between domain and data models, thus I have an IProduct interface defined and Product implementation with various ES attributes.
ElasticClient is created and I am using:
MapDefaultTypeIndices(m => m.Add(typeof(IProduct), "product")

This gets me the correct index in the request url, but not the correct ES type when searching via:
client.Search<IProduct>

Request url: POST product/iproduct/_search
I see we have MapDefaultTypeNames, and when I add
MapDefaultTypeNames(m => m.Add(typeof(IProduct), "product"))

I get the Json.Net error:
Could not create an instance of type IProduct. Type is an interface or abstract class and cannot be instantiated. Path 'hits.hits[0]._source.type'

However the request url looks to be correctly formed with ES type: POST product/product/_search.
Is the expectation that all concrete types be added to Search methods via:
ConcreteTypeSelector((o,h) => typeof(Product))

This seems like a basic use case and I'm not understanding how to wire up the mappings.

@ddisalvo free day here today, will reply with in detail tomorrow of what kinda tactics you can take here.

the built-in way to handle interfaces is to simply index into multiple elasticsearch types.
e.g:
client.Index<Book>();
client.Index<Dvd>();
client.Index<Couch>();
client.Index<Sandwich>();
client.Index<Lager>();

Each of them implementing IProduct.
Then when you do a search use:
var search = client.Search<IProduct>(s=>s
    .Types(typeof(Book), typeof(Dvd), ... )

Note: Types() also takes an IEnumerable<Type>
which will do a search on /products/book,dvd,.../_search nest can then deserialize all hits to actual instances taking advantage of C# covariant enumerable. e.g search.Documents.OfType<Book>() will work here.
If you wish to use a single ES type you can use
ConcreteTypeSelector((o,h) => typeof(Product))

But even better would be to register a custom json converter for IProduct and making it part of the cached json contract:
var settings = new ConnectionSettings(new Uri("http://localhost:9200"))
	.AddContractJsonConverters(
		t => typeof(IProduct).IsAssignableFrom(t) ? new ProductJsonConverter() : null
	);

We use a similar (more generalized) pattern internally for reading interfaces using ReadAsTypeConverter as attributes on the interface itself.
[JsonConverter(typeof(ReadAsTypeConverter<MaxAggregator>))]
public interface IMaxAggregator : IMetricAggregator

This converter can only read, relying on the default json writer. If we need a specialized writer we use CompositeJsonConverter
[JsonConverter(typeof(CompositeJsonConverter<ReadAsTypeConverter<QueryContainer>, CustomJsonConverter>))]
IQueryContainer Query { get; set; }


[bug] Handle variant protocol types in fsspec destination

https://github.com/dlt-hub/dlt/blob/9ca5e0d7d8bf76f57c824e243b49760294569b2e/dlt/destinations/filesystem/configuration.py#L45
Protocol typing in the wild is str | tuple[str]. The easiest example is gcsfs which you will run into. Hence the extra check in the transactional file implementation PR. We should do the same here.
For reference, here is the tuple for the .protocol property in gcsfs
https://github.com/fsspec/gcsfs/blob/main/gcsfs/core.py#L263

Nvm this comes from the bucket url, not the filesystem implementation I think.


[tests] numpydantic.testing - exposing helpers for 3rd-party interface development & combinatoric testing

Currently
we have fixtures for specifying a number of test cases for dtypes and shapes, and then each interface validates against those test cases.
To make that work,  we..

have a ValidationCase model that takes an annotation and a specification for an array to test against it.
The ValidationCase model can generates a model with an annotation that matches the spec in the validation case
each interface then has helper methods to generate an array from the spec and then to validate it.

The shape/dtype cases look something like this:
@pytest.fixture(
    scope="module",
    params=[
        ValidationCase(annotation=RGB_UNION, shape=(5, 5), passes=True),
        ValidationCase(annotation=RGB_UNION, shape=(5, 5, 3), passes=True),
        ValidationCase(annotation=RGB_UNION, shape=(5, 5, 3, 6), passes=False),
        ValidationCase(annotation=RGB_UNION, shape=(5, 5, 4, 6), passes=False),
        # ...
    ])
def shape_cases(request) -> ValidationCase:
    return request.param

The numpy interface tests are like this
def numpy_array(case: ValidationCase) -> np.ndarray:
    if issubclass(case.dtype, BaseModel):
        return np.full(shape=case.shape, fill_value=case.dtype(x=1))
    else:
        return np.zeros(shape=case.shape, dtype=case.dtype)

def _test_np_case(case: ValidationCase):
    array = numpy_array(case)
    if case.passes:
        case.model(array=array)
    else:
        with pytest.raises((ValidationError, DtypeError, ShapeError)):
            case.model(array=array)

@pytest.mark.shape
def test_numpy_shape(shape_cases):
    _test_np_case(shape_cases)

@pytest.mark.dtype
def test_numpy_dtype(dtype_cases):
    _test_np_case(dtype_cases)

Problem
this is proving to be a little bit brittle, and we don't test against, eg, the product of the dtype and shape cases even though we should.
we also want to test behaviors that should be true for all generators, all dtypes, and all shapes, but currently we can only run those tests against a fixed model and array pair for each interface.
we also want to make it possible for people to develop their own interfaces, and so it would be nice if we could facilitate that by providing structure for testing them and a set of tests that need to pass in order for an interface to be added to the package. (or not if they don't want to idrc)
So this PR...

Creates a new model InterfaceTestHelper that provides classmethods for generating an array from a ValidationCase and for validating the array against it
Creates a new numpydantic.testing module that contains the testing classes as well as the test cases as tuples and product iterators.
Expands the ValidationCase to take an InterfaceTestHelper which generalizes what is currently repeated for each of the interfaces with a lot of boilerplate.
Adds combinatoric test fixtures for combinations of shape, dtype, and interface

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.757%

Totals

Change from base Build<PHONE_NUMBER>4:
0.0%

Covered Lines:
1192

Relevant Lines:
1207

💛  - Coveralls


Removed an unnecessary requirement

This removes the contributing guideline that requires development to
happen within the rpc-openstack repo which does nothing but limit
contributions.
Signed-off-by: Kevin Carter<EMAIL_ADDRESS>

@claco Surely this is a RPC engineering specific workflow. Being exclusive in this requirement completely excludes anyone that does not have the rights to branch in this repo, which means pretty much anyone outside of RPC engineering.
Considering the need to cater for other teams within RAX and possibly outside contributors I would think that this does need a revision and that perhaps the current documentation should be specific to RPC engineering only.

We shouldn't tell external contributers that their contributions aren't valid until they follow our way(which requires write access to our repo). I'm okay with loosening the leash for people outside our team. If they want to use their own fork and make a PR off that, fine. They will have no other way of contributing otherwise until someone gives them write access to rpc-openstack.
However, as a team(rpc dev team), we need to have the understanding that we indeed have rules, processes, and regulations that need to be followed (i.e. make a branch within RPCO then make a PR off that branch so we can take over the work need be). So long as that is communicated internally, I'm okay with removing these bits from CONTRIBUTING.

Looking at the perms, everyone from the outside teams are added into contributors, w/ RW perms, so aside from specifically protected branches, anyone in these teams contributing shouldn't have any problems pushing a bug fix, or feature branch into the repo. In fact, to me, this doubles the need as an organization. Their team will need to solve the same problem, or worst case, we can move a PR of theirs along as well.
I'm open to a discussion around the change, but it doesn't appear we're chatted about this in email, nor is there an associated github issue that has gone through the triage/prioritization process for a wider audience to weigh in on.
The PR description should reference the original issue.
I'll leave it up to @alextricity25 on that front for what to do next.

I don't think it's fair to ask external contributers(feature teams, or even one-off PRs from support to fix a small bug) to conform to our work flow.
Yes, we prefer that they do, but my hunch is that they won't care enough to use the "Connects" keyword on their PRs, or will most likely not know about it. They also won't care about our labels, waffle board, or u-suk-dev agendas.
Let's make it as easy as possible for external folks to contribute, but still hold our team accountable for the processes we have in place.

Let's make it as easy as possible for external folks to contribute, _but still hold our team accountable for the processes we have in place_.
I can get behind that sentiment. I'm here only to point out the irony that we just let our team push a PR, from a fork, without an issue.


Update polymarket extension

Description
This is an extension to quickly search and view stats and market prices for Polymarket.com prediction markets. It uses their public API and I flagged this usage to their official account with no concerns.
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi 👋
Looks good to me, approved 🔥


Chinese Localization

Chinese Localization ，menu, settings and basic operations
For the time being to upload, continue to improve more

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


allow for csi tolerations configuration in values.yaml

Description
I have the operator 0.5.0 configured using applicationMonitoring: true and useCSIDriver: true. Due to how we setup our cluster with 2 node groups (1 for app workloads, 1 for ops workload) the CSI pods are only scheduled in the app due to taints in ops. This caused a problem when enabling the monitoring on ingress (https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-container-platforms/kubernetes/instrument-ingress-nginx) as the ingress daemonset is configured to have ops affinity. Below is the error thrown:
MountVolume.SetUp failed for volume "oneagent-bin" : kubernetes.io/csi: mounter.SetUpAt failed to get CSI client: driver name csi.oneagent.dynatrace.com not found in the list of registered
CSI drivers

The update is to allow for CSI tolerations configurations in values.yaml
How can this be tested?

Tested in EKS 1.21 on operator and chart 0.5.0 with activegate <IP_ADDRESS>20204-172150
Also with enabling applicationMonitoring: true and useCSIDriver: true then running helm template test . --set apiToken=abc

When is this going to be included, its causing an issue with my test deployment not being able to include the CSI in multiple node groups

requested changes 24 days ago, no response, closing it
will be done by the team


Setup up for unit test for bazelisk.go

Add a unit test for the migration issue scanner.
This PR adds no new behavior. It just refactors getIncompatibleFlags
so we can add a test for new behavior to be added for https://github.com/bazelbuild/bazelisk/issues/118

friendly ping

Merged in https://github.com/bazelbuild/bazelisk/commit/4785093280595f6f35bcb7bf6ba68585798d2c28.


asyncio: move to own directory

Motivation for this change
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build python36Packages.ws4py

Success on x86_64-linux (full log)
Partial log (click to expand)
test/test_logger.py ....                                                 [ 39%]
test/test_manager.py ..............                                      [ 51%]
test/test_messaging.py ........                                          [ 58%]
test/test_stream.py ................................                     [ 85%]
test/test_utils.py .                                                     [ 86%]
test/test_websocket.py ................                                  [100%]

============================== 3 tests deselected ==============================
=================== 118 passed, 3 deselected in 4.11 seconds ===================
/nix/store/8nrk6q345xsys7x4jwaz9y1c1r5kiz4a-python3.6-ws4py-0.4.3

Success on aarch64-linux (full log)
Partial log (click to expand)
test/test_logger.py ....                                                 [ 39%]
test/test_manager.py ..............                                      [ 51%]
test/test_messaging.py ........                                          [ 58%]
test/test_stream.py ................................                     [ 85%]
test/test_utils.py .                                                     [ 86%]
test/test_websocket.py ................                                  [100%]

============================== 3 tests deselected ==============================
=================== 118 passed, 3 deselected in 6.83 seconds ===================
/nix/store/ssi4r0l3qlbis74sxy6dhv1zxj56krn0-python3.6-ws4py-0.4.3

Failure on x86_64-darwin (full log)
Attempted: python36Packages.ws4py
Partial log (click to expand)
reading manifest file 'asyncio.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'asyncio.egg-info/SOURCES.txt'
running build_ext
Run tests in release mode
Skipping 'test_windows_events': Windows only
Skipping 'test_windows_utils': Windows only
building of '/nix/store/fhphgjfza21maylvfyawwmk35d5j91dy-python3.6-asyncio-3.4.3.drv' timed out after 1800 seconds
cannot build derivation '/nix/store/w68dxbxwaawrgw440wvzdg0f23x909x7-python3.6-ws4py-0.4.3.drv': 1 dependencies couldn't be built
error: build of '/nix/store/w68dxbxwaawrgw440wvzdg0f23x909x7-python3.6-ws4py-0.4.3.drv' failed


Create README-GM.md

Added german translation for hacktoberfest guide 2023

@phyleria please review this

@uchibeke please review this

@HarshMN2345 please fix conflict

@uchibeke  done


Renames

This should be merged before #12.
google-cloudstorage should really be gcs or google-cloud-storage.
Since google container registry is gcr, I renamed this to gcs.
TODO:

[x] rename repository on github
[x] reconnect CI in beta.drone.io (including adding secrets)
[x] reconnect AppVeyor (including adding secrets)

Also, trying to clarify between:

https://hub.docker.com/r/plugins/gcs/
https://hub.docker.com/r/plugins/drone-gcs/ (assuming this one is outdated, should it be deleted? Not sure what the source of that is.)

@tboerger do you have the credentials for https://beta.drone.io/drone-plugins/drone-google-cloudstorage/settings/secrets that you can put into drone-plugins/drone-gcs after we rename the repo?

I have updated appveyor and beta.drone.io, should build fine now.

Thank you!


feat: allow themes to add a custom style for file extensions

Request for comments

This is a draft PR, and I'm looking for feedback on the feature itself, the implementation, and the API.

This adds a feature that allows

(optionally) specifying a custom style for file extensions.

by default, the extension is styled the same as the filename, so the user has to opt in to this feature.
this can help to visually distinguish between different file types.
an extension is defined as rust defines it, i.e. the part of the file name after the last ..
directories don't have extensions, so they are not affected by this feature.

(possible in the future) solving https://github.com/sxyazi/yazi/pull/1036

instead of displaying a single filename, could now split the filename into two parts, the name (stem) and the extension. Then could truncate the stem to fit the screen.
this PR can help applying search highlights to these two parts separately.

(possible in the future) allowing different styling for different types of extensions.

this PR can help applying search highlights while maintaining the custom style.

Example: a custom style for file extensions

Example: highlights are displayed correctly when highlighting searches

Example: the way to configure the style in theme.toml

diff --git a/.config/yazi/theme.toml b/.config/yazi/theme.toml
index b6392db..63d24ed 100644
--- a/.config/yazi/theme.toml
+++ b/.config/yazi/theme.toml
@@ -7,6 +7,7 @@

 syntect_theme = "~/dotfiles/.config/bat/themes/catppuccin-bat/themes/Catppuccin Macchiato.tmTheme"
 cwd = { fg = "#8bd5ca" }
+extension = { fg = "#6e738d", italic = true }

 # Hovered
 hovered = { fg = "#24273a", bg = "#8aadf4" }

Open questions

do you think this feature is useful? I can finish it if you think it is.
currently, some multibyte unicode characters position the extension highlight incorrectly.

I think this is possible to solve, but I'm not sure it might behave on different platforms.
I noticed searching uses regex on the byte level, so maybe this could be a good way to try to solve this.

Sorry, I can't accept this PR.
Its implementation is too complex and contradicts Yazi's design principles - features related to UI and insensitive to performance should be prioritized to be implemented on the Lua side, allowing users the ability to rewrite them to customize their own interactive experience.

features related to UI and insensitive to performance should be prioritized to be implemented on the Lua side, allowing users the ability to rewrite them to customize their own interactive experience

Do you think it would be a good idea to rework this idea a little bit, and allow plugins to add arbitrary highlights? I could see this enabling a lot of features for plugins to write.
I actually started writing this in lua, but had the following issues:

no testing framework is available for lua code

very difficult to maintain without tests

support for type checking is limited

difficult to get the implementation right

Do you think it would be a good idea to rework this idea a little bit, and allow plugins to add arbitrary highlights? I could see this enabling a lot of features for plugins to write.

Yes, I absolutely love the idea. It's just that I don't like its current implementation - implementing it in Rust almost bids farewell to scalability.

I actually started writing this in lua, but had the following issues:

Yeah this is a long-standing issue with the plugin system. But I can't afford to spend too much time on it right now, there are more pressing matters at hand - I'm planning to redesign some of the plugin system's APIs, and these will all be breaking changes, so I need to get them in place by Yazi v0.3. Perhaps we can look into addressing them after Yazi v0.3, it should be soon.


BUG - Dialogs need better & tighter implementation

Hey folks,
I've just checked the dialogs, and they aren't really as per designs.

Target design →

I suppose they are using some default Fluent dialog, or some similar centralised component, but this lacks our look & feel.
1. Fonts
All fonts are wrong. They should be var(--vscode-font-family)

2. Rounded corners
Buttons should not have rounded corners. So this property should be removed:

Same goes for the entire dialog box itself, it also has a 2px rounded corner, which should be removed:

3. Shadow:
Box shadow should not be a hard-coded value. It should, like all other colours, be a variable.

box-shadow: 0 6px 12px 0 var(--vscode-widget-shadow);
4. Paddings
Our designs have a 25px top and bottom padding - so from the top to the title, and then from the buttons down to the edge of the popup. And 45px left/right padding.

At the moment the dialogs don't have it like that, so that should be tightened.
5. Width of dialogs
Width should be 380px. Currently it's 340px.

This dialog as well. It's very elusive, as it disappears too quickly, but same stuff (fonts are wrong, etc.)

This issue has been fixed, closing this ticket.


Pipeable does not seem to be working in all situations

In the feat/system-next branch of the Effect-TS codebase, the Pipeable global helper method is working, but only in certain circumstances.
For example, it seems to work fine in the Effect module:

But in the Metric module, it seems to be failing to generate the correct type:

Here's the error that is generated when I try to compile:


[py2py3] WMCore/Algorithms - migration

Fixes #10009
Status

src: ready
test: not necessary

Description
Run futurize on WMCore/Algorithms
Changes:
str: from builtins import str used in

src/python/WMCore/Algorithms/MathAlgos.py: used in decimal.Decimal(str(stdDev)).is_finite()
src/python/WMCore/Algorithms/SubprocessAlgos.py

list and iterators: range

src/python/WMCore/Algorithms/MathAlgos.py

Iterate over dictionariy keys used in:

src/python/WMCore/Algorithms/MiscAlgos.py

iterate over dictionary items used in:

src/python/WMCore/Algorithms/ParseXMLFile.py

oct: from builtins import oct

src/python/WMCore/Algorithms/Permissions.py

Is it backward compatible (if not, which system it affects?)
It should be. However, any bug would affect directly,
'WMCore_Algorithms': ['WMComponent_TaskArchiver',
                       'WMCore_DataStructs',
                       'WMComponent_DBS3Buffer',
                       'WMCore_FwkJobReport',
                       'WMCore_WorkQueue',
                       'WMCore_ACDC',
                       'WMCore_Algorithms',
                       'WMCore_WMSpec',
                       'WMCore_Services',
                       'WMCore_Storage',
                       'WMCore_WMRuntime'],

External dependencies / deployment changes
requires python-future

The suggested fix for newer python3 idioms, instead of pre-py2.6 ones, is the usual check with type() and not isinstance.
--- src/python/WMCore/Algorithms/SubprocessAlgos.py	(original)
+++ src/python/WMCore/Algorithms/SubprocessAlgos.py	(refactored)
@@ -100,7 +100,7 @@
     if timeout:
-        if type(timeout) != int:
+        if not isinstance(timeout, int):

I can try and change it, it seems safe enough

(Pushed the submit button before writing my final comments, sorry).
@mapellidario I have made some minor comments that would be useful to be taken into account.
I know it's out of the scope of these python3 changes, but could you please also fix those warnings (bold) reported in the jenkins summary (only the simple and safe ones), like:
src/python/WMCore/Algorithms/MathAlgos.py
 W1201, line 56 in getAverageStdDev: Specify string format arguments as logging function parameters
 W0622, line 141 in createHistogram: Redefining built-in 'bin'
...

I know it's out of the scope of these python3 changes, but could you please also fix those warnings (bold) reported in the jenkins summary (only the simple and safe ones), like:

I addressed all the warnings from pylint in bold but one: it complains that the process defined at this line is not assigned to anything. It does not seem that we are using any information coming from that process, nor we check its status, so I did not change that line. Would you prefer a different solution?

...It does not seem that we are using any information coming from that process, nor we check its status, so I did not change that line. Would you prefer a different solution?

No, we can leave it alone. Thanks Dario.

Perfect, thanks! Then I consider this ready to be merged (with absolutely no hurry at all!).

test this please

test this please

test this please

Thanks Dario!


kubernetes-helmPlugins.helm-secrets: depends on non-free vault package

Describe the bug
Updating my falke to latest nixpkgs unstable gives an error that vault is non-free.
But my package doesn't use or need vault.
My package at https://github.com/electronicarts/helmci/ has:
        helm = pkgs.wrapHelm pkgs.kubernetes-helm {
          plugins = [
            pkgs.kubernetes-helmPlugins.helm-diff
            pkgs.kubernetes-helmPlugins.helm-secrets
          ];
          extraMakeWrapperArgs =
            "--set HELM_SECRETS_SOPS_PATH ${sops}/bin/sops --set HELM_SECRETS_VALS_PATH ${vals}/bin/vals";
        };

This gives the error:
$ nix build
warning: Git tree '/home/brian/tree/ea/cloudcell/helmci' is dirty
error:
       … while calling the 'derivationStrict' builtin

         at /builtin/derivation.nix:9:12: (source not available)

       … while evaluating derivation 'helmci-all'
         whose name attribute is located at /nix/store/3pif36ks3f56py4wb1dkq6sh0nkf3ygj-source/pkgs/stdenv/generic/make-derivation.nix:331:7

       … while evaluating attribute 'buildCommand' of derivation 'helmci-all'

         at /nix/store/3pif36ks3f56py4wb1dkq6sh0nkf3ygj-source/pkgs/build-support/trivial-builders/default.nix:68:16:

           67|         enableParallelBuilding = true;
           68|         inherit buildCommand name;
             |                ^
           69|         passAsFile = [ "buildCommand" ]

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: Package ‘vault-1.16.2’ in /nix/store/3pif36ks3f56py4wb1dkq6sh0nkf3ygj-source/pkgs/tools/security/vault/default.nix:47 has an unfree license (‘bsl11’), refusing to evaluate.

       a) To temporarily allow unfree packages, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNFREE=1

          Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
                then pass `--impure` in order to allow use of environment variables.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnfree = true; }
       in configuration.nix to override this.

       Alternatively you can configure a predicate to allow specific packages:
         { nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
             "vault"
           ];
         }

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnfree = true; }
       to ~/.config/nixpkgs/config.nix.

If I comment out the helm-secrets it works.
Steps To Reproduce
Steps to reproduce the behavior:

git clone https://github.com/electronicarts/helmci.git
cd helmci
Modify flake.nix to use nixpkgs-unstable instead of nixpkgs 23.11
nix flake update
nix build

Expected behavior
Should build without errors.
Screenshots
As above.
Notify maintainers
@yurrriq
Metadata
$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.81, NixOS, 23.11 (Tapir), 23.11.20240308.2be119a`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(brian): `""`
 - channels(root): `"nixos-23.11"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos````

---

Add a :+1: [reaction] to [issues you find important].

[reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
[issues you find important]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

helm-secrets depends on vault

What happened to vault? It use to be open source I thought. Did the license change?

Does helm-secrets really depend on vault? From the About section it says:

Store your secrets a cloud native secret manager like AWS SecretManager, Azure KeyVault or HashiCorp Vault and inject them inside value files or templates.

Which seems to indicate that it should be able to use any secret manager, not just vault.

the vault license change, which sparked quite the outrage.

Does helm-secrets really depend on vault? From the About section ...

you ask a question and follow with the answer, that's both rare and impressive ^^''
You can see it here:
https://github.com/NixOS/nixpkgs/blob/a10842c7f0343bad733d039c72cf15a6ca0d1eb4/pkgs/applications/networking/cluster/helm/plugins/helm-secrets.nix#L32
I suggest you follow the recommendation and accept the new license for vault. If you dont need it, you can remove support for it as well from helm-secrets (but will require some nix skills though you can search the web for plenty of examples)

How about switching the dependency from vault to OpenBAO - would that be possible?

How about switching the dependency from vault to OpenBAO - would that be possible?

Heh, I didn't realize LF forked Vault too. :popcorn:
It's certainly possible, but might have unintended side effects for Nix users. (I realize how annoying that might sound, given your recent experience.)
By default, helm-secrets supports vals and sops. After a quick glance, it looks like both sops and vals use the Vault Go library, so maybe we don't even need vault at runtime anyway...
I wonder if sops and vals will have to alter their licenses...

I've just tried a modified helm-secrets derivation, removing all references to vault, against a repo that uses helm-secrets (with AWS KMS backend) and it worked fine. I then switched the config to point use a Vault backend, and that also worked. Note that I used nix run nixpkgs-unfree#vault login to get a token, but assuming ~/.vault-token exists or the env var VAULT_TOKEN is set somehow, it seems helm-secrets doesn't need a vault binary at runtime at all. So, I suggest we drop the dependency.

@brianmay, might you be able to test https://github.com/NixOS/nixpkgs/pull/322750? It Works on my Machine™, and I'm fairly confident, but I'd love some additional verification.

It seems to work OK on my system, so far. Don't have a good test case for vault though.
Will think about additional ways to test this.


Update to Azure OpenAI version 2024-02-01

Closes #554, closes #197, closes #552, closes #413
Purpose

This PR updates to the latest stable version of Azure OpenAI API version, 2024-02-01.

There are no changes required to the /api/conversation/custom endpoint, but all the changes are to the /api/conversation/azure_byod endpoint. This endpoint is not called by the frontend at all (and was not currently working anyway)

Update unit tests to more closely match streamed response
Fix issues regarding RBAC and unimplemented GET methods

Does this introduce a breaking change?

[ ] Yes
[x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Update code here to use conversationApi() function
Experiment with RBAC/non-RBAC, streaming/non-streaming, use data/no data

What to Check
Verify that the following are valid

Response back from the API are displayed correctly in the frontend

I havent looked over these changes in detail but we are actually using the azure_byod route. We switched away from the custom to the azure_byod route as it was simpler to make changes to the openAI call and passing data source details and a filter string.
Should we assume this route will no longer functional or be updated when moving to the new api versions?

Hey @andrewwiebe - both routes should be functional. We needed to update the OpenApi versions but this change only effected the byod route. If you think something is broken with the byod route then please raise a bug and we will prioritise. In summary - both routes are supported.


Script for Dataset Preprocessing

HI @xymou, I am quite curious about how to extract the social networks with the following&follower lists from the datasets in README. It seems that these datasets only have the tweets themselves.
May I ask if you could share the script for preprocessing the raw dataset or provide the processed dataset?
Thanks in advance.

I have the same problem as above, how to get the relationship between users? Thank you!

我也遇到了同样的问题，能否分享一下，万分感谢。

Hi! Since we can not directly publish the info & relationships of users constrained by Twitter’s terms of service, we have provided the ids of users through this link

For user list we used in our paper, we can only provide the ids id_link.

You can crawl the following list or follower list of the users through some open-source tools, such as twscrape
Once you have obtained the following list for each user, you can further filter it to identify which users in the current set are being followed, thereby constructing their social relationships.


installation problem on window

while i install ttsmms it show error.

Finded solution from google

Closing issues, I already find problem.

I faced same problem on my windows machine, how did you solve this problem?


Hive - Custom Fields no longer works

After Pulling the most recent update for Apps, the Hive App no longer adds Custom Fields to Hive cases
In app

After execution  (showing now custom fields added to the case)

For the create case issue, I believe issues start around line 175
https://github.com/Shuffle/python-apps/blob/db1a1ad056e5f872481ed22e83e3be53b2798614/thehive/1.1.3/src/app.py#L175
This code in the except block used to always run, and now will only trigger if there is an issue

@shalin24999 could you check this out?
Thanks

@shalin24999 create a case with the custom field "unique-phish-id" (as seen in the original photo), and then try to update it via API, either in a new case OR in an updated case
Manage custom fields: https://docs.thehive-project.org/thehive/user-guides/administrators/custom-fields/

what is the goal of this  try/catch?   I can confirm that without it, the app was working.  I think there is an indent issue
        try:
            custom_fields = json.loads(custom_fields) if custom_fields else {}
        except json.decoder.JSONDecodeError:

my guess is it is a check like the  tlp / severity
        if tlp > 3 or tlp < 0:
            return f"TLP needs to be a number from 0-3, not {tlp}"
        if severity > 4 or severity < 1:
            return f"Severity needs to be a number from 1-4, not {severity}"

I haven't tested this exactly, but this is my assumption for a fix
        # Prepare the customfields
        customfields = CustomFieldHelper()
        try:
            custom_fields = json.loads(custom_fields) if custom_fields else {}
        except json.decoder.JSONDecodeError:
            return "Custom fields need to be valid json"
        for key, value in custom_fields.items():
            if type(value) == int:
                customfields.add_integer(key, value)
            elif type(value) == str:
                customfields.add_string(key, value)
            elif type(value) == bool:
                customfields.add_boolean(key, value)
            elif type(value) == float:
                customfields.add_float(key, value)
            else:
                print(
                    f'The value type "{value}" of the field {key} is not suported by the function.'
                )

@chasx003 You were right. Have updated the code.

awesome!  FYI, the same code block is in the update_case function as well :)

Hey @chasx003! Is this sorted?
Thanks @shalin24999! :)

Looks like it! (I'm using a local version now, but, the changes are the same as what is working on mine)