Segmentation fault while running examples/recurrent-language-model.lua

I am trying to run this example recurrent-language-model.lua.
When I train it with cuda flag as false it runs perfectly file.
But on trying to run with cuda it gets a segmentation fault on trying to execute this step.
local outputs = lm:forward(inputs)
This is the output log from the run. I printed the inputs variable.
{
   batchSize : 32
   batchsize : 32
   cuda : true
   cutoff : -1
   device : 4
   dropout : 0
   earlystop : 50
   gru : false
   hiddensize : {200}
   id : "test"
   lstm : true
   maxepoch : 10
   maxnormout : -1
   minlr : 1e-05
   momentum : 0.9
   progress : true
   saturate : 400
   savepath : "/home/nilesh/save/rnnlm"
   seqlen : 5
   silent : false
   startlr : 0.05
   trainsize : -1
   uniform : 0.1
   validsize : -1
}
Vocabulary size : 10000
Train set split into 32 sequences of length 29048
Language Model:
nn.Sequential {
  [input -> (1) -> (2) -> (3) -> output]
  (1): nn.LookupTable
  (2): nn.SplitTable
  (3): nn.Sequencer @ nn.Recursor @ nn.Sequential {
    [input -> (1) -> (2) -> (3) -> output]
    (1): nn.FastLSTM(200 -> 200)
    (2): nn.Linear(200 -> 10000)
    (3): nn.LogSoftMax
  }
}

Epoch #1 :
Columns 1 to 13
  238  9013  2523  9120  4935   346  6844   425  8237  1292  7805    46  9049
  808  1817  9120  9013    45  6143  5503    49  6447  9060    45    46  1417
  951  9839  3054  7956    49  4771  6058  3757    45  6143  3569  7576  9013
 1326   903  6189  9011    45  6168  4156  1884  5134  4266  9583  2160  5564
 1477  5364  9346  9013  9583   425  5424    44  9013  8772  6844   477    45

Columns 14 to 26
 3826  9934    45  3973  2542  4547  7481  4471  6203    49  9013  3670  3291
 5111    44   425    44  9013  6874  9011  9013  4404     2  6962  7408  9120
  103  9030  5268  1292  3344  4246    46  7844  9030    46  6081  1795   874
 9120   556  9120  2059  6143  9706  6492  1230   556   988  9911  6186    46
 9453    45  8456   414  9013  7481  4082   610    46  1274  6186  3460  9120

Columns 27 to 32
 3040  9120   988  1817  3395  6143
 4471  1955  4471  6158  9780  7962
 9013  9013  9013  9780   759  3911
 8201  4436  9754  5861  4471  3773
 9534  6143  3062   730  9013  4266
[torch.IntTensor of size 5x32]

Segmentation fault (core dumped)

Any possible issues that might cause this.
Also, I checked that I had all the dependencies.
cunn, cunnx, cutroch
Thanks,
Nilesh

@nileshkulkarni I had a similar problem with a different script which was solved by importing cunn before allocating any large memory chunks. I just updated the script with this change : https://github.com/Element-Research/rnn/commit/9dbcb6889796c7730db780f9bad6c456322cbbb5 . Update rnn and let me know if it helps. Otherwise, I wasn't able to reproduce your error on my end.

@nicholas-leonard  I tried to run with your fix but I still get the same Seg fault.
Any other way I could show you the problem? Probably the output of core file?, but I don't how to get a detailed log of the core.
Any ideas/ suggestions would be great.
Thanks

@nicholas-leonard Solved the problem.
I was using lua instead of luajit to run the examples.
luajit examples/recurrent-language-model.lua  works perfectly fine with cuda.
This issue can be closed now.

@nileshkulkarni Ok sounds good.


History.js and its plugins crash when combined into a single JavaScript file.

On websites that combine multiple JavaScript files into one, history.js crashes with "undefined method" errors.
I consider this a bug because:

Their should (theoretically) be no difference between running the same javascript code as one file or a series of separate files, as each line of code is executed sequentially.
Combining multiple files of the same type to reduce the number of HTTP requests is a common and widely accepted practice in web optimization. (ref: http://developer.yahoo.com/performance/rules.html)

Details:

It can be reproduced on any site using history.js and its plugins by replacing the separate script tags with a single script tag referencing a file with the code from history.js and its plugins combined.
I've reproduced it in Firefox 5, Safari 5, and Chrome, so believe the bug is browser independent

Quick and dirty fix:
Add a millisecond delay to each script file after the first one.
// contents of history.adapter.jquery.js
setTimeout(function(){
    // contents of history.js
}, 1);
setTimeout(function(){
    // contents of history.html4.js
}, 1);

This is clearly too hacky to be a permanent fix, but it illustrates the problem well:
History.js is dependent on the delay normally caused by loading each script with a separate HTTP request.

Still not working in 2017...


iohook.node is not a valid Win32 application.

Current Behavior
When you start the program
App threw an error during load
Error: C:\iohook-test\node_modules\iohook\builds\electron-v89-win32-x64\build\Release\iohook.node is not a valid Win32 application.
C:\iohook-test\node_modules\iohook\builds\electron-v89-win32-x64\build\Release\iohook.node
    at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1846)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1138:18)
    at Object.func [as .node] (electron/js2c/asar_bundle.js:5:1846)
    at Module.load (internal/modules/cjs/loader.js:935:32)
    at Module._load (internal/modules/cjs/loader.js:776:14)
    at Function.f._load (electron/js2c/asar_bundle.js:5:12913)
    at Module.require (internal/modules/cjs/loader.js:959:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (C:\iohook-test\node_modules\iohook\index.js:24:21)
    at Module._compile (internal/modules/cjs/loader.js:1078:30)

It will be displayed.
The package.json contains the correct Node/Electron ABI version
Steps to Reproduce (for bugs)

Clone https://github.com/Kazuy1/iohook-test
Run script/cleanup (run in the script folder)
Start electron (electron main.js)

Context
The source code uses the same as the sample code  of iohook
Your Environment

Microsoft Windows 10 Pro  v10.0.19042
IOHook Version: 0.9.3
Environment name and version (e.g. Chrome 39, node.js 5.4, electron 11.2): node.js 14.17.3, electron 13.1.9
Operating System and version (desktop or mobile):desktop
Optional Link to your project: https://github.com/Kazuy1/iohook-test

PS: Running abi.js will change the iohook abi in package.json to the Node/electron abi

Same issue - any update?

Any update on this ?
I am using electron  : "15.3.0" abi 98
Do we have to manually do the build for win32?

Still no updates in a month. I want to ditch iohook entirely, but there's nothing better to use.


fix: checkTargets check for duplicate target

The checkTargets function introduced in 4a0f8bf2 as
  checkTargets (targets : Array Expr) : MetaM Unit := do
    let mut foundFVars : FVarIdSet := {}
    for target in targets do
      unless target.isFVar do
        throwError "index in target's type is not a variable (consider using the `cases` tactic instead){indentExpr target}"
      if foundFVars.contains target.fvarId! then
        throwError "target (or one of its indices) occurs more than once{indentExpr target}"

looks like it tries to check for duplicate indices, but it doesn’t
actually, as foundFVars is never written to.
This adds
      foundFVars := foundFVars.insert target.fvarId!

and a test case.
Maybe a linter that warns about let mut that are never writen to would
be useful?

If I read the lean code in RecursorInfo correctly, then this attribute stores the position of the major premise, and runs mkRecursorInfoCore, but discards the result of that.
Maybe it is the case that running mkRecursorInfoCore when the attribute is useful in case it throws errors, so that the user knows that the function is unsuitable as a recursor early on, and not just when trying to use it?

Maybe a linter that warns about let mut that are never writen to would be useful?

I would implement this, but I'm pretty sure that would involve more changes to Elab/Do.lean than is currently considered acceptable.


mousemove event is not triggered while dragging element

Here I dragged li element with id then mouse move event is not triggered for the  li elements id 1 and 2 when dragged element is hovered
[contrib]: https://github.com/bevacqua/dragula/blob/master/.github/contributing.markdown
[slack]: https://dragula-slackin.herokuapp.com/

In the first line of your code you assigned the div to "drag-fodlers". If this is a typo in your HTML from other documents that use the name "drag-folders" that may explain your bug.

Hey @SheW0lf that is typo, it is directive name but in my code that was proper just edited the above syntax


serviceofferings and serviceplans service manager endpoints not  exposed

/apis/services.cloud.sap.com/v1/ does not expose serviceofferings and serviceplans endpoints of the service manager API;
as a result service offerings names and their respective plans must be manually looked up ; that's very tedious and error prone; and  not that much user friendly either.
For instance Service Manager service offering name is service-manager and it has several plans available:

Plan
Description
Environment

subaccount-admin
Allows management of resources in the subaccount in which the service instance of this plan was created. This includes managing service instances, bindings and subaccount-scoped platforms.
Cloud Foundry, Kyma, Kubernetes, Other

subaccount-audit
Allows read-only access to the resources in the subaccount in which the service instance was created. This includes reading service instances, bindings and subaccount-scoped platforms.
Cloud Foundry, Kyma, Kubernetes, Other

container
Allows management of service instances and bindings in a reduced scope. Instances created in a container are not visible when using credentials of other container instances
Cloud Foundry, Kyma, Kubernetes, Other

service-operator-access
Provides credentials for SAP BTP service operator to access SAP BTP from a Kubernetes cluster.
Other

The service plans could be nicely populated for each service offering using the environment (kubernetes) as a filter.

checkout https://github.com/SAP/sap-btp-service-operator/blob/809b58c4ba5ed01a3153e7ae86434b9c129703ae/README.md#sap-btp-kubectl-plugin-experimental

That's not what we want; we do not want a plugin that requires an intimate knowledge of the btp operator implementation in a cluster ; all we would like to see is these endpoint exposed as resources with /apis/services.cloud.sap.com/v1/
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "services.cloud.sap.com/v1",
  "resources": [
    {
      "name": "serviceinstances",
      "singularName": "serviceinstance",
      "namespaced": true,
      "kind": "ServiceInstance",
      "verbs": [
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "create",
        "update",
        "watch"
      ],
      "storageVersionHash": "********="
    },
    {
      "name": "serviceinstances/status",
      "singularName": "",
      "namespaced": true,
      "kind": "ServiceInstance",
      "verbs": [
        "get",
        "patch",
        "update"
      ]
    },
    {
      "name": "servicebindings",
      "singularName": "servicebinding",
      "namespaced": true,
      "kind": "ServiceBinding",
      "verbs": [
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "create",
        "update",
        "watch"
      ],
      "storageVersionHash": "*********="
    },
    {
      "name": "servicebindings/status",
      "singularName": "",
      "namespaced": true,
      "kind": "ServiceBinding",
      "verbs": [
        "get",
        "patch",
        "update"
      ]
    }
  ]
}

I don't understand the use case, if the need is to see the available offerings and plans then the kubectl extension is the answer, you don't need to have any inside knowledge of the btp operator to use it, just the namespace it is installed.
please elaborate on the use case and the expected output.

I agree that it is not user friendly, but I don't understand your solution proposal, how would you like the BTP operator to expose the offerings and plans?

same way as BTP operator does to expose serviceinstances and servicebindings.
BTP's Service Manager (SM) API offers these offerings and plans endpoints out of the box.
You can look them up in the SM's swagger's definition for instance: https://service-manager.cfapps.{region}.hana.ondemand.com/swaggerui/swagger-ui.html
if region is eu10 that would be: https://service-manager.cfapps.eu10.hana.ondemand.com/swaggerui/swagger-ui.html

When you retrieve the full list of service plans each service plan record has a guid to its service offering. Thus it is easy to pull out the list os the service offerings for kubermetes environment and then provide the sublist of the available plans.

I know these apis, but how do you want the BTP operator to use them? bindings and instances are created by the user, who should create the plans and offerings? in which namespace? who will trigger the initiation? (the offering and plans are not static) how will kyma read them? seems like you have something in mind that i don't see, feel free to schedule a meeting to discuss it.

After our discussion I looked up the following CRD, namely: servicebindings.services.cloud.sap.com ; this CRD has the storage of all the service bindings across the cluster; Actually we would need serviceofferings.services.cloud.sap.com and serviceplans.services.cloud.sap.com CRDs with the storage of all offerings and plans. These 2 CRDs would have to be refreshed either manually on demand or once in a while via for instance a cron job....running in a cluster....until a better mechanism in place.


Build fails under debian

Trying to build under debian (with zstd, libzstd-dev installed) fails with the following:

CMake Error at CMakeLists.txt:32 (find_package):
  By not providing "Findzstd.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "zstd", but
  CMake did not find one.

  Could not find a package configuration file provided by "zstd" with any of
  the following names:

    zstdConfig.cmake
    zstd-config.cmake

  Add the installation prefix of "zstd" to CMAKE_PREFIX_PATH or set
  "zstd_DIR" to a directory containing one of the above files.  If "zstd"
  provides a separate development package or SDK, be sure it has been
  installed.

I have similar issue when building using nix:
building '/nix/store/70sycrygs9y835qnb0asj43h876s9907-ZArchive-0.1.1.drv'...
unpacking sources
unpacking source archive /nix/store/qpmq7ma7nsi86n3dkq7fxhs99nfclcii-source
source root is source
patching sources
configuring
fixing cmake files...
cmake flags: -DCMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_SKIP_BUILD_RPATH=ON -DBUILD_TESTING=OFF -DCMAKE_INSTALL_LOCALEDIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/share/locale -DCMAKE_INSTALL_LIBEXECDIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/libexec -DCMAKE_INSTALL_LIBDIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/lib -DCMAKE_INSTALL_DOCDIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/share/doc/ZArchive -DCMAKE_INSTALL_INFODIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/share/info -DCMAKE_INSTALL_MANDIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/share/man -DCMAKE_INSTALL_OLDINCLUDEDIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/include -DCMAKE_INSTALL_INCLUDEDIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/include -DCMAKE_INSTALL_SBINDIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/sbin -DCMAKE_INSTALL_BINDIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/bin -DCMAKE_INSTALL_NAME_DIR=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1/lib -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_OSX_SYSROOT= -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_STRIP=/nix/store/58pwclg9yr437h0pfgrnbd0jis8fqasd-gcc-wrapper-11.2.0/bin/strip -DCMAKE_RANLIB=/nix/store/m2vh2ny7bqpwij1gpmvl5gxj7y4dgr4f-binutils-2.38/bin/ranlib -DCMAKE_AR=/nix/store/m2vh2ny7bqpwij1gpmvl5gxj7y4dgr4f-binutils-2.38/bin/ar -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_INSTALL_PREFIX=/nix/store/n0fkjpnsca8ax9mf1sbjhksa6qxmy2m0-ZArchive-0.1.1
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /nix/store/58pwclg9yr437h0pfgrnbd0jis8fqasd-gcc-wrapper-11.2.0/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /nix/store/58pwclg9yr437h0pfgrnbd0jis8fqasd-gcc-wrapper-11.2.0/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
CMake Error at CMakeLists.txt:18 (add_library):
  Target "zarchive" links to target "zstd::libzstd_static" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

CMake Error at CMakeLists.txt:36 (add_executable):
  Target "zarchiveTool" links to target "zstd::libzstd_static" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_TESTING
    CMAKE_EXPORT_NO_PACKAGE_REGISTRY
    CMAKE_POLICY_DEFAULT_CMP0025

CMake Generate step failed.  Build files cannot be regenerated correctly.
error: builder for '/nix/store/70sycrygs9y835qnb0asj43h876s9907-ZArchive-0.1.1.drv' failed with exit code 1;

Am I using the wrong version of zstd library? Here is the nix derivation:
{ stdenv, lib, fetchFromGitHub, cmake, zstd }:

stdenv.mkDerivation rec {
  pname = "ZArchive";
  version = "0.1.1";

  src = fetchFromGitHub {
    owner = "Exzap";
    repo = pname;
    rev = "v${version}";
    sha256 = "sha256-qsUn2aOeMeGJKmxJ2Hf9jDbfwvS3REUes1eNkQFq62I=";
  };

  nativeBuildInputs = [ cmake ];

  buildInputs = [ zstd ];

  meta = with lib; {
    description = "Library for creating and reading zstd-compressed file archives (.zar)";
    homepage = "https://github.com/Exzap/ZArchive";
    maintainers = with maintainers; [ misuzu ];
    platforms = platforms.unix;
    license = licenses.mit;
  };
}

I created an RPM for openSUSE ( https://build.opensuse.org/package/show/home:jaimeMF/zarchive ) and I had to modify the RPM of zstd ( https://build.opensuse.org/package/show/home:jaimeMF:branches:Archiving/zstd ) to use cmake for building and installing. With cmake the files needed for building ZArchive are correctly installed.
@misuzu I had to explicitly add the dependency on libzstd-devel-static, ¿is the static library available on nix?

@misuzu I had to explicitly add the dependency on libzstd-devel-static, ¿is the static library available on nix?

Makes sense, thanks! This nix derivation worked for me:
{ stdenv, lib, fetchFromGitHub, fetchpatch, cmake, zstd }:

stdenv.mkDerivation rec {
  pname = "zarchive";
  version = "0.1.1";

  src = fetchFromGitHub {
    owner = "Exzap";
    repo = "ZArchive";
    rev = "v${version}";
    sha256 = "sha256-qsUn2aOeMeGJKmxJ2Hf9jDbfwvS3REUes1eNkQFq62I=";
  };

  patches = [
    (fetchpatch {
      url = "https://github.com/Exzap/ZArchive/commit/bbe67b9b21e5f6f41fcbbadee4fada53bcadebf1.patch";
      sha256 = "sha256-6KzxvtaaCdCULW6ZMR6wkrhprgm4AuNswKUJ9phjqvc=";
    })
    (fetchpatch {
      url = "https://github.com/Exzap/ZArchive/commit/d1bcb5ac9f31a4a94db92a4e3f45ba58dc7cc1db.patch";
      sha256 = "sha256-hoO3Yap6s7YdjbfnXUFKFE/A1IGHLHo9yO6lU8ZkZ+g=";
    })
  ];

  nativeBuildInputs = [ cmake ];

  buildInputs = [
    (zstd.override { static = true; })
  ];

  meta = with lib; {
    description = "Library for creating and reading zstd-compressed file archives (.zar)";
    homepage = "https://github.com/Exzap/ZArchive";
    maintainers = with maintainers; [ misuzu ];
    platforms = platforms.unix;
    license = licenses.mit;
  };
}

While it works for Linux, it fails to build on macOS, but I guess that's an issue with the clang version:
building '/nix/store/6d3pb1w3d0hnpf7w8xs03sb9a8q8frgw-zarchive-0.1.1.drv'...
unpacking sources
unpacking source archive /nix/store/qpmq7ma7nsi86n3dkq7fxhs99nfclcii-source
source root is source
patching sources
applying patch /nix/store/2aidh733i8c1sblkzyi3m2lhzgbshqnn-bbe67b9b21e5f6f41fcbbadee4fada53bcadebf1.patch
patching file CMakeLists.txt
applying patch /nix/store/jl9yz6kh5fl0z585fnrldjp4mpzx8x16-d1bcb5ac9f31a4a94db92a4e3f45ba58dc7cc1db.patch
patching file CMakeLists.txt
updateAutotoolsGnuConfigScriptsPhase
configuring
fixing cmake files...
cmake flags: -DCMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_SKIP_BUILD_RPATH=ON -DBUILD_TESTING=OFF -DCMAKE_INSTALL_LOCALEDIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/share/locale -DCMAKE_INSTALL_LIBEXECDIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/libexec -DCMAKE_INSTALL_LIBDIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/lib -DCMAKE_INSTALL_DOCDIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/share/doc/ZArchive -DCMAKE_INSTALL_INFODIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/share/info -DCMAKE_INSTALL_MANDIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/share/man -DCMAKE_INSTALL_OLDINCLUDEDIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/include -DCMAKE_INSTALL_INCLUDEDIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/include -DCMAKE_INSTALL_SBINDIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/sbin -DCMAKE_INSTALL_BINDIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/bin -DCMAKE_INSTALL_NAME_DIR=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1/lib -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_OSX_SYSROOT= -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_STRIP=/nix/store/nwfcj1p4l74krm4n6szrb0c534p4ai2s-clang-wrapper-11.1.0/bin/strip -DCMAKE_RANLIB=/nix/store/baplgma04mfrvivyg7i25py9wz9nr446-cctools-binutils-darwin-949.0.1/bin/ranlib -DCMAKE_AR=/nix/store/baplgma04mfrvivyg7i25py9wz9nr446-cctools-binutils-darwin-949.0.1/bin/ar -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_INSTALL_PREFIX=/nix/store/8kaqpwymfmixxy7l8h202hqmzm445hwh-zarchive-0.1.1
-- The C compiler identification is Clang 11.1.0
-- The CXX compiler identification is Clang 11.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /nix/store/nwfcj1p4l74krm4n6szrb0c534p4ai2s-clang-wrapper-11.1.0/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /nix/store/nwfcj1p4l74krm4n6szrb0c534p4ai2s-clang-wrapper-11.1.0/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_TESTING
    CMAKE_EXPORT_NO_PACKAGE_REGISTRY
    CMAKE_POLICY_DEFAULT_CMP0025

-- Build files have been written to: /tmp/nix-build-zarchive-0.1.1.drv-0/source/build
cmake: enabled parallel building
building
build flags: -j10 -l10 SHELL=/nix/store/cmcl1jichs33ynwv5apzs8r8ndx2w2pi-bash-5.1-p16/bin/bash
[ 50%] Building CXX object CMakeFiles/zarchive.dir/src/zarchivereader.cpp.o
[ 50%] Building CXX object CMakeFiles/zarchive.dir/src/zarchivewriter.cpp.o
[ 50%] Building C object CMakeFiles/zarchive.dir/src/sha_256.c.o
/tmp/nix-build-zarchive-0.1.1.drv-0/source/src/zarchivereader.cpp:238:23: error: no matching function for call to 'min'
                uint32_t stepSize = std::min(remainingBytes, _ZARCHIVE::COMPRESSED_BLOCK_SIZE - blockOffset);
                                    ^~~~~~~~
/nix/store/1r3mrri4afdhshaibaamb3rafvy4ngv9-libcxx-11.1.0-dev/include/c++/v1/algorithm:2560:1: note: candidate template ignored: deduced conflicting types for parameter '_Tp' ('unsigned long long' vs. 'unsigned long')
min(const _Tp& __a, const _Tp& __b)
^
/nix/store/1r3mrri4afdhshaibaamb3rafvy4ngv9-libcxx-11.1.0-dev/include/c++/v1/algorithm:2571:1: note: candidate template ignored: could not match 'initializer_list<type-parameter-0-0>' against 'unsigned long long'
min(initializer_list<_Tp> __t, _Compare __comp)
^
/nix/store/1r3mrri4afdhshaibaamb3rafvy4ngv9-libcxx-11.1.0-dev/include/c++/v1/algorithm:2580:1: note: candidate function template not viable: requires single argument '__t', but 2 arguments were provided
min(initializer_list<_Tp> __t)
^
/nix/store/1r3mrri4afdhshaibaamb3rafvy4ngv9-libcxx-11.1.0-dev/include/c++/v1/algorithm:2551:1: note: candidate function template not viable: requires 3 arguments, but 2 were provided
min(const _Tp& __a, const _Tp& __b, _Compare __comp)
^
1 error generated.
make[2]: *** [CMakeFiles/zarchive.dir/build.make:90: CMakeFiles/zarchive.dir/src/zarchivereader.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:85: CMakeFiles/zarchive.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
error: builder for '/nix/store/6d3pb1w3d0hnpf7w8xs03sb9a8q8frgw-zarchive-0.1.1.drv' failed with exit code 2;

it fails to build on macOS

https://github.com/Exzap/ZArchive/pull/5 fixes the macOS issue for me. Final nix derivation now looks like this:
{ stdenv, lib, fetchFromGitHub, fetchpatch, cmake, zstd }:

stdenv.mkDerivation rec {
  pname = "zarchive";
  version = "0.1.1";

  src = fetchFromGitHub {
    owner = "Exzap";
    repo = "ZArchive";
    rev = "v${version}";
    sha256 = "sha256-qsUn2aOeMeGJKmxJ2Hf9jDbfwvS3REUes1eNkQFq62I=";
  };

  patches = [
    (fetchpatch {
      url = "https://github.com/Exzap/ZArchive/commit/bbe67b9b21e5f6f41fcbbadee4fada53bcadebf1.patch";
      sha256 = "sha256-6KzxvtaaCdCULW6ZMR6wkrhprgm4AuNswKUJ9phjqvc=";
    })
    (fetchpatch {
      url = "https://github.com/Exzap/ZArchive/commit/d1bcb5ac9f31a4a94db92a4e3f45ba58dc7cc1db.patch";
      sha256 = "sha256-hoO3Yap6s7YdjbfnXUFKFE/A1IGHLHo9yO6lU8ZkZ+g=";
    })
    (fetchpatch {
      url = "https://github.com/Exzap/ZArchive/commit/9a1c6723fe5449de6e2cc7da4a24e76b172bbda9.patch";
      sha256 = "sha256-k83cBEMhfjcpymFYX8R7NB96th5VjwEFcTnG4O9w4pQ=";
    })
  ];

  nativeBuildInputs = [ cmake ];

  buildInputs = [
    (zstd.override { static = true; })
  ];

  meta = with lib; {
    description = "Library for creating and reading zstd-compressed file archives (.zar)";
    homepage = "https://github.com/Exzap/ZArchive";
    maintainers = with maintainers; [ misuzu ];
    platforms = platforms.unix;
    license = licenses.mit;
  };
}

@misuzu what changes do I need to make to the code to build it under debian? Thanks.

I haven't used Debian for years, but you could try replacing zstd::libzstd_static to zstd::libzstd_shared in CMakeLists.txt, maybe that helps.

It builds for me with ubuntu 22.04 using this:
cmake_minimum_required (VERSION 3.15)

set(CMAKE_CXX_STANDARD 20)

cmake_policy(SET CMP0091 NEW) # for MSVC_RUNTIME_LIBRARY

set(VCPKG_TARGET_TRIPLET "x64-windows-static" CACHE STRING "VCPKG Target Triplet to use")

project ("ZArchive")

set(SOURCE_FILES_LIB
src/zarchivewriter.cpp
src/zarchivereader.cpp
src/sha_256.c
)

# build static library
add_library (zarchive STATIC ${SOURCE_FILES_LIB})
set_property(TARGET zarchive PROPERTY MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

target_include_directories(zarchive
    PUBLIC
        $<INSTALL_INTERFACE:include>
        $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
)

include_directories(PRIVATE
${CMAKE_CURRENT_SOURCE_DIR}/include
)

find_path(/usr/include/ zstd.h)
TARGET_LINK_LIBRARIES(zarchive PRIVATE /usr/lib/x86_64-linux-gnu/libzstd.so)

# standalone executable
add_executable (zarchiveTool src/main.cpp)
set_property(TARGET zarchiveTool PROPERTY MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")
set_target_properties(zarchiveTool PROPERTIES OUTPUT_NAME "zarchive")
target_link_libraries(zarchiveTool PRIVATE zarchive)

# install
include(GNUInstallDirs)

install(DIRECTORY ${CMAKE_SOURCE_DIR}/include/zarchive/ DESTINATION "include/zarchive" FILES_MATCHING PATTERN "zarchive*.h")
INSTALL(TARGETS zarchive LIBRARY)
INSTALL(TARGETS zarchiveTool)

The solution is likely to include a Findzstd.cmake module that uses pkg-config to locate the library.
You can use the following code under the terms of the ISC license:
# SPDX-FileCopyrightText: 2022 Andrea Pappacoda <andrea at pappacoda dot it>
# SPDX-License-Identifier: ISC

find_package(PkgConfig)

if (PKG_CONFIG_FOUND)
	pkg_search_module(libzstd IMPORTED_TARGET GLOBAL libzstd)
	if (libzstd_FOUND)
		add_library(zstd::zstd ALIAS PkgConfig::libzstd)

		# pkg_search_module() only creates an imported target for the shared one
		if (NOT TARGET zstd::libzstd_static)
			add_library(zstd::libzstd_static INTERFACE IMPORTED GLOBAL)
			target_compile_options(zstd::libzstd_static INTERFACE
				${libzstd_STATIC_CFLAGS}
				${libzstd_STATIC_CFLAGS_OTHER}
			)
			target_include_directories(zstd::libzstd_static INTERFACE
				${libzstd_STATIC_INCLUDE_DIRS}
			)
			target_link_directories(zstd::libzstd_static INTERFACE
				${libzstd_STATIC_LIBRARY_DIRS}
			)
			target_link_libraries(zstd::libzstd_static INTERFACE
				${libzstd_STATIC_LIBRARIES}
				${libzstd_STATIC_LINK_LIBRARIES}
			)
			target_link_options(zstd::libzstd_static INTERFACE
				${libzstd_STATIC_LDFLAGS}
				${libzstd_STATIC_LDFLAGS_OTHER}
			)
		endif()
	endif()
endif()

include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(zstd
	REQUIRED_VARS
		libzstd_LINK_LIBRARIES
		libzstd_FOUND
	VERSION_VAR libzstd_VERSION
)

Should be fixed with #7


imports fixed

@h1alexbel take a look, please
we're got some mess with imports

Codecov Report
Patch and project coverage have no change.

Comparison is base (3aeef86) 68.18% compared to head (d5cbfb4) 68.18%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff            @@
##             master     #114   +/-   ##
=========================================
  Coverage     68.18%   68.18%
  Complexity       18       18
=========================================
  Files             9        9
  Lines            66       66
=========================================
  Hits             45       45
  Misses           21       21

Impacted Files
Coverage Δ

...va/io/github/eocqrs/kafka/consumer/KfConsumer.java
25.00% <ø> (ø)

...thub/eocqrs/kafka/consumer/KfConsumerSettings.java
100.00% <ø> (ø)

...n/java/io/github/eocqrs/kafka/fake/FkConsumer.java
0.00% <ø> (ø)

...thub/eocqrs/kafka/producer/KfProducerSettings.java
100.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@rultor merge

@rultor merge

@h1alexbel OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@h1alexbel Done! FYI, the full log is here (took me 1min)

@l3r8yJ thanks!


Adding prometheus endpoint options negates custom configuration

Maybe I am just doing this wrong :) I have a setup with a custom configuration. With just the default JSON metrics endpoint the default context is named (although I cant get the appdex to not be 1 all the time). When I add config to make the formatter be prometheus plain text everything reverts back to the default config.
public static IHostBuilder CreateHostBuilder(string[] args)
        {
            Metrics = AppMetrics.CreateDefaultBuilder()
                .Configuration.Configure(opts => {
                    opts.DefaultContextLabel = "MyCustomService"; // doesnt apply
                })
                .OutputMetrics.AsPrometheusPlainText()
                .Build();

            return Host.CreateDefaultBuilder(args)
                .UseMetrics(opts => {
                    opts.EndpointOptions = eo =>
                    {
                        eo.MetricsEndpointOutputFormatter = new MetricsPrometheusTextOutputFormatter();
                    };
                })
                .ConfigureMetrics(Metrics)
                .UseMetricsWebTracking(opts => {
                    opts.ApdexTSeconds = 0.1;   // doesnt apply
                    opts.ApdexTrackingEnabled = true; // doesnt apply
                    opts.OAuth2TrackingEnabled = true; // doesnt apply
                })
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>().UseSerilog();
                });
        }

I the docs have individual sections on how to achieve part of the puzzle, but Im not having the results I need glueing them together :)

@pshort Just ran into a similar issue - in particular trying to apply ApdexTSeconds (albeit I am doing this via Startup.cs). Given that you closed the issue, does that mean you figured out why settings weren't getting applied?

@pshort Just ran into a similar issue - in particular trying to apply ApdexTSeconds (albeit I am doing this via Startup.cs). Given that you closed the issue, does that mean you figured out why settings weren't getting applied?


[feature] Support English Version

版本号
~ Latest
什么问题
~ I like YAPI, but I am not Chinese. please support for English.
如何复现此问题
~ None
什么浏览器
~ None
什么系统（Linux, Windows, macOS）
~ ALL

I am very sorry that I have been maintaining the project by myself on a part-time basis and have no energy to translate

@hellosean1025 do you have a tutorial on how to add the translation to make it support English? so maybe we can translate and make a PR for that. Thanks.


[BUG] Updating Upload_Validator file size spelling

Changing all cases of "filesize" spelling to "file size" and related translatable files, so spelling correct in the error messages

The change looks good to me, and I think the wording is an improvement, but I can't confirm whether this will persist into transifex properly. @chillu?

The en master strings will be pushed as part of the normal release process. The translations (e.g. en_GB) won't update automatically, unless we specifically push them up. So some of these strings in the commit will eventually be reverted, but every translator sees the master string as changed in transifex and has the option to update their respective translation anyway.


Shorten CLI field names

As to keep CLI calls shorter, we should prefer shorter names for CLI options, corresponding to what we do with API fields, too. So "sensor" rather than "sensor-id" and "source" rather than "source-id".
Adapted from https://github.com/FlexMeasures/flexmeasures/pull/818#discussion_r1293158770

Note that part of this ticket is to nicely deprecate the old CLI options, as not to introduce breaking changes on production servers.

Should I work on this issue?


support eslint_d 2

https://github.com/mantoni/eslint_d.js/issues/2#issuecomment-141712485

Works in background mode but I don't see any differences in lint time could be the 'poll' value?

can you make a new release?

done https://github.com/roadhump/SublimeLinter-eslint/releases/tag/1.8.0
it seems still not possible to make it works as eslint itself on unsaved files :frowning: . I'll try later this week.

@roadhump Thanks! I guess you would need support to lint stdin, right? That needs a little more work on eslint_d. Any help on this would be greatly appreciated.

I'd happily send a PR to eslint_d. @roadhump what would we need?

@sonnyp :+1:

@sonnyp We need support of --stdin and --stdin-filename options of eslint.

Ok, I've made a decision to move eslint_d to separate SublimeLinter plugin here https://github.com/roadhump/SublimeLinter-contrib-eslint_d. It seems SublimeLinter is not intended to run two different programs from one plugin and it can create a huge mess with current eslint plugin. I'll ready to sync relevant code of eslint and eslint_d plugins, or probably find a way to share it somehow.
I've created an issue to add eslint_d plugin to SublimeLinter packages and I will publish version of this plugin without eslint_d as soon as eslint_d plugin is published.


validate: advisory: add new validation for file and package name matching

This PR adds a new validation step for advisory. Package name should also reflect the actual file name to work as expected. For example; package name should reflect the version stream in the advisories. foo-1.2.advisories.yaml's package.name MUST be foo-1.2 rather than foo.

Thank you, @luhring, for your PR and enlightening my way here! The new solution is simpler and nicer now. PTAL when possible! 💜


Save dark mode status in realm and update the me page

Related Issue

Fixes #368
Checklist:

[x] I have read the contributor's guide.
[x] I linked an issue in the previous section
[x] I have commented on the linked issue
[x] I was assigned the linked issue (not required)
[x] I have tested the change to the best of my ability against the sandbox or a local build.

Optional items:

[ ] My change adds new text and requires a change to translations.
[x] My change requires a change to the documentation.
[ ] I have submitted a PR to the documentation repo.
[ ] I was not able to test... (explain below, e.g. you did not have permissions to test a specific feature)
[ ] This change depends O-FISH Realm repository changes (explain below)
[ ] This change depends O-FISH Web repository changes (explain below)

Optional: Add any explanations here

Optional: Add any relevant screenshots here

If we want the same value to apply across all devices (multiple Android phones/tablets and an iPhone) then we should ideally store the state in the ‘User’ doc, but that isn’t currently sync’d with the mobile apps. Probably better to just store it as local state in the device, whether outside of Realm or in a non-sync’d realm, as it’s reasonable that someone would want different values on say their phone and tablet.
On 6 Oct 2020, 20:46 +0100, Sheeri<EMAIL_ADDRESS>wrote:

@Sheeri commented on this pull request.
@am-MongoDB This adds an entry to a new collection called DarkMode, and currently is not working with Realm Sync as that collection does not exist.
If it's something to be stored in the database, I think a darkMode field in the User collection makes the most sense.
But - does it have to be stored in Realm?
(and yes, I understand this is one of the difficulties of having an extra parameter on top of just using the system status.... :-\ )
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

 Review PRs

The logout modal is unusable in dark mode, as you can't see the buttons

Hi @am-MongoDB I have fixed the dialog colors in dark mode

@thearavind you did a TON of great work here.....
Congratulations! 🎉 🙌 🎆 ㊗
This PR is great and has been merged into the code. Thanks so much for contributing! If you'd like, you can request to work on another issue. We really appreciate your effort!

Thanks a lot, @Sheeri and @am-MongoDB 🙂. Sure would love to contribute more 👍

@thearavind - There are plenty of dark mode issues at https://github.com/WildAid/o-fish-android/issues - you would be great for those!


[Remoto] Vue.Js Developer @ Jobsity

Hi GitHub community!
At Jobsity we´re looking for Vue.Js Senior developers (+3 years of experience) with a good English level.
We offer 100% remote positions, very good salaries in USD and some more benefits:
-15 working days of paid vacations
-3 extra off days per year
-Paid and off local holidays
-Paid time off
-Budget for e-learning courses
-Financing program for equipment
-Bonuses for referrals
If you´re interested, don´t hesitate to contact me via email at<EMAIL_ADDRESS>or LinkedIn :)

Hi I am a vue.js developer and I feel comfortable to take the job


Ensure examples are runnable in the ide

Motivation:
It seems like intellij / idea is confused because of shading of jctools.
Modifications:
Add jctools as dependency with scope runtime to the examples as workaround
Result:
Its possible again to run the examples in the ide.

lgtm ... shading is never as easy as it should be :(


cascade delete entities with a delete_option parameter.

fix for #266
@cben @zeroDivisible @simon3z @moolitayer

@cben changed to named params

@cben @moolitayer @ilackarms PTAL

I don't get why the example is passing a Kubeclient::Resource?
Can we use a hash in the example?
I think the client and not the user should add apiVersion and  kind: 'DeleteOptions' to the options.
We set apiVersion in several other places.
:+1: for always using payload instead of query parameters for a DELETE request

@moolitayer I get your point. The example make clear it consume a resource and you (as the user) can change it. If we are going to keep that away from the user and set apiVersion and so on in the client we need to maintain this. IMO this is the way to keep up with the fast-moving changes in Kubernetes.
@abonas What is needed more to merge this puppy?

@simon3z done

@simon3z done

@kamerblauwlicht thanks! I was about to merge and then I noticed that it has some redundant commits. Do you think you can squash all in a single commit? (After all it's just one feature addition)

please squash redundant commits so this can be merged. thanks!

I would love to see this feature merged.

sorry for the late response (on holiday). will squash the commits today ;-)

@abonas squashed the commits. please merge.

great to see this getting fixed ... atm I'm manually deleting the pods ... which is a bit annoying :D


Proposal: allow type arguments of generic being named

TypeScript Version:  2.7.0-dev.201xxxxx

Search Terms: named generic type parameters / arguments
Code
interface UserInfo { }
var usersMap: Map<sessionId: string, info: UserInfo>;

Expected behavior:
No error, Map<sessionId: string, info: UserInfo> should be equivalent to Map<string, UserInfo> .
Actual behavior:
Syntax error: Generic type 'Map<K, V>' requires 2 type argument(s).
Playground Link:
https://www.typescriptlang.org/play/#src=interface UserInfo { }
var usersMap%3A Map<sessionId%3A string%2C info%3A UserInfo>%3B
Rationale:
Without a name, it is not often immediately clear what a type argument really mean. Take Map<string, UserInfo> as an example, is the first argument a sessionId, a userId or something else? In contrast,  Map<sessionId: string, info: UserInfo> or  Map<sessionId: string, UserInfo> is very clear.
The name of a type argument doesn't affect the actual type, just like the name of argument of a function type.

When would the name sessionId ever get used by the compiler? It seems to me that this is better left to a comment.

It's the same with normal function calls:
let result = doStuff('foo', true, 3.14, 42); // what do all these mean?

The usual solutions are to either (a) place comments labeling each argument, or (b) pass an options object so callers have to specify key/value pairs, which is both extensible and self-documenting.
You could take both of these approaches with generics too. For example:
// Option A:
interface UserInfo { }
var usersMap: Map</*sessionId:*/ string, /*info:*/ UserInfo>;

// Option B:
interface UserInfo { }
type MyMap<T extends {sessionId: any, info: any}, U = T['sessionId'], V = T['info']> = Map<U, V>;

let usersMap: MyMap<{sessionId: string, info: UserInfo}>;

This seems to introduce much more complexity than it produces in value.

This is super useful when you have a function that takes multiple generic arguments and you only want to assert one. This is a example of what the feature could be like: sandbox

@RyanCavanaugh Please reopen this. Clearly nobody agrees with your estimation that this doesn't add value.

This proposal has at least two very big advantages:

if you edit or change something it is less risky since you won't screw your types if you pass your params in a wrong position by mistake
it is way more readable when you have multiple parameters

It's the same with normal function calls:
let result = doStuff('foo', true, 3.14, 42); // what do all these mean?

The usual solutions are to either (a) place comments labeling each argument, or (b) pass an options object so callers have to specify key/value pairs, which is both extensible and self-documenting.
You could take both of these approaches with generics too. For example:
// Option A:
interface UserInfo { }
var usersMap: Map</*sessionId:*/ string, /*info:*/ UserInfo>;

// Option B:
interface UserInfo { }
type MyMap<T extends {sessionId: any, info: any}, U = T['sessionId'], V = T['info']> = Map<U, V>;

let usersMap: MyMap<{sessionId: string, info: UserInfo}>;

That's a proper JavaScript-like solution.


feature request: please provide a way to "opt-outing" openssl

Hello maintainers,
First of all, thank you for maintaing this crate!
I've used this crate via reqwest in my applications.
I've been built them mostly with rustls-backend. However, it falls back for native-tls because ring (one of rustls dependency) does not build for M1 Mac yet.
According to docs.rs top, native-tls uses security-framework crate and does not depend on openssl crate.
However, GitHub Security Advisory said my application is vulnerable because there's a path to openssl:
my-app 0.1.0
└ reqwest 0.11.22
  └ native-tls 0.2.11
    └ openssl 0.10.55

I don't want to drop M1 mac support.
Proposed change
I'm not sure if this approach will work...

Add check_openssl to default features
Add __buildscript_enable_openssl to features: __buildscript_enable_openssl = ["openssl", "openssl-sys", "openssl-probe"]
make openssl-related to be optional = true
Check std::env::var("CARGO_FEATURE_CHECK_OPENSSL") existence and cfg(not(any(/* windows, mac, ios */))) in build.rs.
println!(r#"cargo:rustc-cfg=feature="__buildscript_enable_openssl""#); if all conditions are met.
Add something like compile_error!("This target requires OpenSSL, but it is not enabled!"); to lib.rs in case  of it was actually necessary but is disabled by accidentally.

How to enable/disable

enable: down-stream user doesn't have to do anything. It should continue to be work.
disble: no-default-features = true on down-stream side. This disables check on build.rs, so openssl should not appear in the dependency tree.

Run cargo update.

Run cargo update

No, it isn't a point. Please reopen this.
dependabot has done same thing to my repo in this case, but I don't want to handle "vulnelability" that is not actually vulnerable due to not linked on any case, so I want it to not include them on dependency tree.


Update Node to version 18 & document usage of fnm

fnm is faster and has better Windows support
node 18 is about to become the next LTS
required webpack upgrade to support node 18 (crypto library change)
resolves #187

ok not really sure on the problem here - may need some deeper investigation.

Setting to draft for now.

Since Netlify uses nvm to manage node versions, I wondered what was wrong with the build environment. As can be seen in the logs, the build environment was still running Ubuntu Xenial (16.04), which is no longer actively maintained.
Thankfully, Netlify allows you to select Ubuntu Focal (20.04). To do so, navigate to Site settings > Build & deploy > Continuous Deployment > Build image selection.
I cleared the cache and it built and deployed perfectly this time.

https://lavaux.lv/2022/04/26/fix-netlify-build-errors-with-node-18.html

Thanks @allcaps - should I reach out on the core team for access to the Netlify instance? Or could you do this update?

@lb- Netlify is updated. See core Slack. Can you give this PR a little kick?

Pushed but Vercel failed - not sure why (requested access on core team to view logs).

@allcaps  sorry the invite did not work - not sure what I am doing wrong with these computer things. I accepted the invite from the notification email but it kept saying 404 error.
I have just requested access to the Wagtail team in my Vercel account so maybe that will come up when you log in next.

Will mark as draft, not sure how to solve the Deployment issue.


Release Google.Cloud.CloudDms.V1 version 2.2.0

Changes in this release:
Breaking change
The resource annotation for CreateConnectionProfileRequest.Parent has changed from referring to a ConnectionProfileName to a LocationName. This means CreateConnectionProfileRequest.ParentAsConnectionProfileName has been removed, and CreateConnectionProfileRequest.ParentAsLocationName has replaced it.
Although this is clearly a breaking change (as removing a public property always is), we have not taken a major version bump as any customers whose source code is broken by this would already have been broken when making a request. Customers whose code is already working will not be affected.
New features

Adding GenerateTcpProxyScript API (commit 8c998c6)
Add MappingRule resource and CRUD operations (commit 8c998c6)
Support for PostgreSQL 15 (commit 8c998c6)
Add support for CloudSQL editions (commit 8c998c6)
Add support for VLDB migrations (commit 8c998c6)
Add SSL config to Oracle Connection Profile (commit 8c998c6)
Change CreateConnectionProfileRequest resource reference (commit 8c998c6)
Change ImportMappingRulesRequest and DescribeDatabaseEntitiesRequest fields to required (commit 8c998c6)

Closing and re-opening to allow breaking changes.

Created release for Google.Cloud.CloudDms.V1-2.2.0


InputBar: fix selection above input bar

This pt-16 was here before so I thiiiink it was already broken. We moved the Stop generation inside the AssistantInputBar where it belongs and this pt-16 has no reason to exist here.
"Don't complain. Act."

@spolu i did test by checking out, pretty convinced it wasnt broken

The explanation is that the input bar had a smaller height which reduced the overlap of that padding with text but I think it existed since we went pb-32 to pb-44 to not touch text and removed pt-16 so it probably did exist on 4px explaining why it was not too perceivable


Error:(2, 8) TS2440: Import declaration conflicts with local declaration of 'stream'

IDEA is pointing out that you have:
import * as stream from 'stream';
export declare function stream(uri: string, options?: RequestOptions, content?: any): Request<void>;

Thanks for the issue. Personally I'm not familiar with IDEA, can you provide more info on the problem? Is it a blocker or a warning? Do you have a suggestion for how to address it?

This has nothing to do with idea. You've got two things named 'stream'. It
should be a compile error. Rename the import to something else.
On Wednesday, September 14, 2016, Dave Templin<EMAIL_ADDRESS>wrote:

Thanks for the issue. Personally I'm not familiar with IDEA, can you
provide more info on the problem? Is it a blocker or a warning? Do you have
a suggestion for how to address it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/davetemplin/web-request/issues/5#issuecomment-247048033,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFNayhuuokozGE2wbzEOqosTDyYEUjAks5qqA_7gaJpZM4J8H_b
.

Fixed in 1.0.6.


Add login timestamps to collaborator

Scope of changes
This adds two new metadata timestamps to the collaborator record. The purpose of this is to better inform the frontend about when collaborators have accepted invitations.
Type of change

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

Acceptance criteria
Timestamps make sense and I didn't miss any spots where they need to be updated.
Author checklist

[x] I have manually tested the change and/or added automation in the form of unit tests or integration tests
[ ]  I have updated the dependencies list
[x]  I have recompiled and included new protocol buffers to reflect changes I made
[ ]  I have added new test fixtures as needed to support added tests
[x]   Check this box if a reviewer can merge this pull request after approval (leave it unchecked if you want to do it yourself)
[x]  I have moved the associated Shortcut story to "Ready for Review"

Reviewer(s) checklist

[ ] Any new user-facing content that has been added for this PR has been QA'ed to ensure correct grammar, spelling, and understandability.

Codecov Report
Base: 44.51% // Head: 44.51% // Decreases project coverage by -0.00% :warning:

Coverage data is based on head (8604fdf) compared to base (6507ff4).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #893      +/-   ##
==========================================
- Coverage   44.51%   44.51%   -0.01%
==========================================
  Files         658      658
  Lines       23850    23866      +16
  Branches     1498     1498
==========================================
+ Hits        10618    10624       +6
- Misses      11873    11883      +10
  Partials     1359     1359

Flag
Coverage Δ

unittests
44.51% <ø> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...isacrypto/directory/pkg/bff/models/v1/models.pb.go
10.37% <0.00%> (-0.18%)
:arrow_down:

.../github.com/trisacrypto/directory/pkg/bff/users.go
54.50% <0.00%> (+1.33%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


refactor: use enum to distinguish transaction signature types

This PR introduces a way to statically distinguish between a fake signature and an ECDSA signature with recoverable address.
The introduced signature::Fakeable<SignatureT> also handles caching of the address to ensure that it only will be recovered once.
These changes allow the future removal of the ExecutableTransaction, as the caller address will now always be part of transaction::Signed

EcdsaWithYParity struct
The EcdsaWithYParity struct is a bit weird from a conceptual perspective, because the y parity can be always recovered from the v value which the Ecdsa struct has. As I understand the distinction comes from the fact that EIP-2930 and later transactions only include the r and s values and an odd_y_parity flag, as opposed to r, s and v values. For the internal library of an Ethereum specific tool I think it's ok if this leaks into the signature types, but ideally we'd only have a signature::Ecdsa struct where we set the v value based on the odd_y_parity and chain_id from the transaction.

I agree that the odd_y_parity can be calculated from the v value. However, the RLP-encoding and -decoding of EIP-2930 and later transactions is different as well, given that the odd_y_parity is only 1 byte, as opposed to the 8-bytes that legacy and EIP-155 transactions RLP-encode/-decode.
As this distinction is known at compile-time, I expressed that with two different types: Ecdsa and EcdsaWithYParity. Previously this was achieved by having the r, s,, and odd_y_parity fields listed separately in the Eip2930 and later transactions, whereas the Legacy and Eip155 transactions included the Signature.

Signature trait
My understanding is that the purpose of the Signature trait is to provide a sum type over certain types in the edr_eth crate. I tend to prefer designs where sum types are represented with enums as this brings more conceptual clarity and prevents type erasure and dynamic dispatch.

I'm not trying to achieve a sum type (unless you consider polymorphism a form of sum type). Given that there are two compile-time types Ecdsa and EcdsaWithYParity (see above argumentation) that contain the r, s, and v or odd_y_parity values, to achieve both compile-time and runtime polymorphism, I introduced the trait that returns those values.
It's hard to say whether dynamic dispatch would be faster or slower than having a sum type as the compiler will potentially apply optimisations in both cases.
Given that there is only one location at which I'm using the trait, I can easily remove it by exposing the r, s, v, and odd_y_parity values directly on the transaction::Signed. I'm happy to do that to simplify the code.

As this distinction needs to happen at compile-time, I expressed that with two different types: Ecdsa and EcdsaWithYParity. Previously this was achieved by having the r, s,, and odd_y_parity fields listed separately in the Eip2930 and later transactions, whereas the Legacy and Eip155 transactions included the Signature.

Ok makes sense!

I'm not trying to achieve a sum type, as the signature type that a transaction needs to receive is mutually exclusive (unless you consider polymorphism a form of sum type). Given that there are two compile-time types Ecdsa and EcdsaWithYParity (see above argumentation) that contain the r, s, and v or odd_y_parity values, to achieve both compile-time and runtime polymorphism, I introduced the trait that returns those values.

Ok so we want to abstract over different (data) types here. This is often done with polymorphism in object-oriented languages, but in languages that support sum types I prefer to do that as I find that it's easier to work with. In any case, I think it's ok to merge as is, so not a change request.


Support update container resources

Depends on https://github.com/kubernetes-incubator/cri-containerd/pull/148.
Fixes https://github.com/kubernetes-incubator/cri-containerd/issues/149.
Will rebase after https://github.com/kubernetes-incubator/cri-containerd/pull/148 is merged.

LGTM

Apply LGTM based on https://github.com/kubernetes-incubator/cri-containerd/pull/150#issuecomment-324224487.


[DCOS-44443] Remove the deprecated DCOS_PACKAGE_METADATA label

Address DCOS-44443
We have deprecated the DCOS_PACKAGE_METADATA label from 1.11 onwards. DC/OS Frontend was the only component that was using this label. They switched to use /service/describe instead of this label (And that was needed for package-registry to work anyway). Since this label is deprecated, we can remove the code to encode/decode this label.
This should not require any changes to cosmos-enterprise (CI passes for fwiw and I have tested manually in an enterprise cluster that few basic flows work as expected).

FYI @nLight
This is happening as discussed in this jira comment


Relax constraints on decryption keys to improve interop with broken producers

Apparently there are broken legacy apps around which erroneously encrypt messages to primary keys not marked as encryption capable (e.g. RSA primary keys with [SC] key flags, see #372).
PGPainless currently takes key-flags into consideration and refuses to decrypt messages using keys that lack encryption keyflags. As a result, messages produced by broken clients fail to decrypt.
This PR relaxes these constraints and limits validity checks on decryption keys to only check if subkeys have been valid at some point and if the public key algorithm they are based on is capable of encryption (no point in trying to decrypt with an ECDSA key).
This comes with the added benefit, that we should be able to decrypt messages using expired or revoked subkeys as well.
Addresses #373

TODO: Should we add a config flag for this and default to current behaviour?

Obviously, this PR fails this test:
https://github.com/pgpainless/pgpainless/blob/main/pgpainless-core/src/test/java/org/pgpainless/decryption_verification/PreventDecryptionUsingNonEncryptionKeyTest.java#L192

@vanitasvitae thank you again for your help with my issue earlier on and for creating this PR so quickly!
Any chance for this to be released soon? Please let me know if there is anything I can help.

I will think a bit more about this patch and decide about it later today or maybe tomorrow.
Then, drafting a release can be done in no time :)


Review usage of slave_ok flag according to the driver spec

This PR directly addresses the inconsistencies uncovered in #250, where the usage of a read preference allowing reads from secondaries would not play well with the value of slave_ok, which in the driver defaults to false (not setting the flag).
It follows directions in https://github.com/mongodb/specifications/blob/master/source/server-selection/server-selection.rst#use-of-slaveok and tackles the following issues:

Inconsistencies regarding slave_ok's implicit behavior
findAndModify operations relying on a read server selection (instead of write)

Moreover, for cursor-based queries the slave_ok option is already implicitly set (and reused for further getmore invocations) but commands such as count would fail with a non-primary read preference (because slave_ok would be set to false).
The way to workaround this limitation would be to use the deprecated and undocumented behaviour of passing slave_ok: true as a query option, so that it would override the default and allow some commands to go through on secondaries. A side-effect of this would be all the findAndModify operations (find_one_and_update, find_one_and_replace and find_one_and_delete) to also go through secondaries, which the default slave_ok prevented, but should never be possible (as these are equivalent to write operations).
The driver specification goes even further and mentions this combination of options used for the workaround as an error:

If a driver API allows users to potentially set both the legacy slaveOK configuration option and a default read preference configuration option, passing a value for both MUST be an error. (See Use of slaveOk for the two uses of slaveOK.)

This PR removes the need for the workaround by having slave_ok consistent with the server selection algorithm but doesn't prohibit the combination of options as the backwards compatibility for this option is not totally clear.

Thanks for this. If you can make that quick change, I will merge this.

@ankhers Pushed the change you've requested. Thanks for looking at this.

Thanks again!


ConfirmReplyController persist the dto

ConfirmReplyData#getComment returns an instance of CommentData. ATM the action try to persist the dto instead of the entity.
Thanks for the article!

Ah nice catch! I forgot to assign the entity when writing the new controller

Fixed via https://github.com/iltar/blog-articles/commit/1ff8d03943ae901becbe64a25c3378e8687c59a9, thanks!


Fix LLVM feature check

Fixes #1580

Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 70.40%. Comparing base (91083c1) to head (a6d19af).

Files
Patch %
Lines

src/compiler/optimize.jl
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1581      +/-   ##
==========================================
- Coverage   71.56%   70.40%   -1.16%
==========================================
  Files          30       30
  Lines       12799    12765      -34
==========================================
- Hits         9159     8987     -172
- Misses       3640     3778     +138

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


Fix Flex jsdoc warnings: the Private tag does not permit a value

The following warnings need to get fixed:

jsdoc -c .jsdoc.json
WARNING: The @private tag does not permit a value; the value will be ignored. File: index.js, line: 9
WARNING: The @private tag does not permit a value; the value will be ignored. File: index.js, line: 16
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 315
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 321
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 356
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 362
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 428
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 434
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 448
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 453
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 466
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 481
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 537
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 546
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 699
WARNING: The @private tag does not permit a value; the value will be ignored. File: ReleaseManager.js, line: 709

Recommended steps:

Fork flex repository https://github.com/inexorgame/inexor-flex and clone your fork
Make sure you have the Yarn package manager installed
Execute yarn install in a terminal within the flex repository
Locate the file and understand the warning
Fix the warnings, verify that it's fixed by running yarn run docs
Create a pull requests with your changes here: https://github.com/inexorgame/inexor-flex/pulls

Let us know if you are having any questions or troubles 😄

This warning can be safely ignored.
jsdoc intends private values or methods not to be documented.  The resulting warning is this.

Please add the org:wontfix label if you are closing issues as wontfix.


Convert another use of isSameDay to use London comparisons, not UTC

In this function, we're building up a list of all the dates when we have exceptional opening hours, e.g. if we had two venues
library.exceptionalOpeningHours = [3 Jan, 2 Jan, 1 Jan]
gallery.exceptionalOpeningHours = [3 Jan, 4 Jan, 5 Feb]

then this would return
[1 Jan, 2 Jan, 3 Jan, 4 Jan, 5 Feb]

I expect these dates to be consistent for each batch that's entered (e.g. if somebody enters five dates, they'll have the same UTC offset), so we're comparing like-for-like in this function.
This means that if somebody enters the same override date in library and gallery, I expect it would be an identical date, not merely a different time on the same day.
In practice this means we could actually replace this with the even stronger check (ignoring any weirdness around comparing dates in JS):
const isAlreadyInResult = result.some(t =>
  t.overrideDate === thisOverride.overrideDate
);

and we'd get the same results.
We only care about them being the same day, but for this check I don't think the London/UTC distinction will make any difference and so we can switch to the default of London-based comparisons.
Continuing to chip away at https://github.com/wellcomecollection/wellcomecollection.org/issues/9874

Are there more datetime refactors to come before your departure?

Nothing major, I hope!
But Raphaëlle was asking about the London/UTC ticket a few days ago, and I said I'd get it over the line rather than leave it in an incomplete state. 🤞 I get it all done today.


Any plans for maximum session size property?

Are there any plans for a property that sets a maximum size for total user session, and throws an exception if its exceeded? Any recommendations on how I can simply accomplish this? (currently using redis distributed cache)

No plans for this yet, but it's an interesting idea.
Some workarounds:

You have full access to the data from ISession so it would not be difficult to enforce your own limit via a helper method, middleware, etc.. e.g. enumerate the session and total the size of the elements.
It should not be hard to copy and override the ISessionStore implementation to enforce this.
https://github.com/aspnet/Session/blob/dev/src/Microsoft.AspNetCore.Session/SessionServiceCollectionExtensions.cs#L27

This issue was moved to aspnet/Home#2398


Adding Prompt Template Making Guide

To assist Subject Matter Experts with creation of new prompt templates

Prompt Template Making Guide added


Suggestion to Add DateFns Support

Hello,
After reviewing your valuable project, I found that it currently utilizes a native-datetime-adapter as well as a moment-datetime-adapter for MatDatetimepicker configuration. While these have served us excellently, I'd like to propose adding support for DateFns, as it can provide more versatility and efficiency in handling JavaScript dates.
I plan to submit a PR with some proposed implementations if there are no objections.

no objections. 😉

@jagipas hey, have you managed to create the adapter?


Create facimp.txt

Add Facimp again to apply.
Please we need to apply to students here.

@agenteph Thank you for the update! Pull request merged.
FTR: domain ownership proof: https://www.wyden.com.br/facimp/formas-ingresso/vestibular/vestibular-em-imperatriz


Docker invoke update error

Deployment Method

[ ] Installer
[x] Docker Development
[ ] Docker Production
[ ] Bare metal Development
[ ] Bare metal Production
[ ] Digital Ocean image
[ ] Other (please provide a link Steps to Reproduce

Describe the problem*
When i run the first step in the docker installation manual, i get an error. I have tried completely clearing the INVENTREE_EXT_VOLUME folder and clearing the docker images/containers, but to no avail.
$ docker compose run --rm inventree-server invoke update
[+] Creating 1/0
 ✔ Container inventree-db  Running                                                                               0.0s
Creating directory /home/inventree/data/static
Creating directory /home/inventree/data/media
Creating directory /home/inventree/data/backup
Copying config file from /home/inventree/src/backend/InvenTree/config_template.yml to /home/inventree/data/config.yaml
Installing required python packages from 'src/backend/requirements.txt'
Requirement already satisfied: pip in /usr/local/lib/python3.11/site-packages (24.0)
Collecting pip
  Downloading pip-24.2-py3-none-any.whl.metadata (3.6 kB)
Requirement already satisfied: setuptools in /root/.local/lib/python3.11/site-packages (72.1.0)
Collecting setuptools
  Downloading setuptools-75.2.0-py3-none-any.whl.metadata (6.9 kB)
Downloading pip-24.2-py3-none-any.whl (1.8 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 4.7 MB/s eta 0:00:00
Downloading setuptools-75.2.0-py3-none-any.whl (1.2 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2/1.2 MB 5.8 MB/s eta 0:00:00
Installing collected packages: setuptools, pip
  Attempting uninstall: setuptools
    Found existing installation: setuptools 72.1.0
    Uninstalling setuptools-72.1.0:
      Successfully uninstalled setuptools-72.1.0
  Attempting uninstall: pip
    Found existing installation: pip 24.0
    Uninstalling pip-24.0:
ERROR: Could not install packages due to an OSError: [Errno 39] Directory not empty: 'platformdirs'

Here is my .env file:
# InvenTree environment variables for docker compose deployment

# Specify the location of the external data volume
# By default, placed in local directory 'inventree-data'
INVENTREE_EXT_VOLUME=./inventree-data

# Ensure debug is false for a production setup
INVENTREE_DEBUG=False
INVENTREE_LOG_LEVEL=WARNING

# InvenTree admin account details
# Un-comment (and complete) these lines to auto-create an admin acount
INVENTREE_ADMIN_USER=admin
INVENTREE_ADMIN_PASSWORD=1Aujvw2YyxJHN1tGIQ2uQpzhtwh5GjX1yXOnS8V
<EMAIL_ADDRESS>
# Database configuration options
INVENTREE_DB_ENGINE=postgresql
INVENTREE_DB_NAME=inventree
INVENTREE_DB_HOST=inventree-db
INVENTREE_DB_PORT=5432

# Database credentials - These should be changed from the default values!
INVENTREE_DB_USER=inventree-pg
INVENTREE_DB_PASSWORD=99HGvVSsm54gwuYx2CLPCjq28F9MUZvVr4qChs6

# Redis cache setup (disabled by default)
# Un-comment the following lines to enable Redis cache
# Note that you will also have to run docker-compose with the --profile redis command
# Refer to settings.py for other cache options
#INVENTREE_CACHE_ENABLED=True
#INVENTREE_CACHE_HOST=inventree-cache
#INVENTREE_CACHE_PORT=6379

# Options for gunicorn server
INVENTREE_GUNICORN_TIMEOUT=90

# Enable custom plugins?
INVENTREE_PLUGINS_ENABLED=True

# Run migrations automatically?
INVENTREE_AUTO_UPDATE=True

# Image tag that should be used
INVENTREE_TAG=stable

# Site URL - update this to match your host
INVENTREE_SITE_URL="http://<IP_ADDRESS>"

COMPOSE_PROJECT_NAME=inventree

Steps to Reproduce

Download docker-compose.yml and related files from the set-up guide
Set parameters in .env file
Run docker compose run --rm inventree-server invoke update

Relevant log output
No response

I re-pulled the images one more time, using the docker-compose.yml from the stable branch (same .env config), and it doesn't give this error anymore.


Tuya Thermostat some times disappear

Home Assistant release with the issue:

0.97.2
Last working Home Assistant release (if known):
0.97.1
Operating environment (Hass.io/Docker/Windows/etc.):

hassbian
Component/platform:

https://www.home-assistant.io/components/tuya/
Description of problem:
Sometimes tuya thermostat disappear from gui without any log entry
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

Hi,
now seems to be solved. Thanks


BLD: handle concurrent requests

From the initial implementation spec:

Your server should be able to handle concurrent user requests. Hint: you may want to use a connection pooling library if you’re using JDBC and Java. We will NOT be load testing your server at this stage however.

@luster would you suggest Apache DBCP as a suitable connection pooling library for us? AFAICT there isn't an example of connection pooling in the bookstore example, so I'm trying to understand what needs to be done.

DBCP looks fine. Use whatever looks easiest to implement


Threading fails

Running a query on macOS, installed via pip, starts okay:
Validating arguments...
Fetching query data and calculating requirements...
Found 7398 results, they would be split over 15 requests/files
This program might use all the systems available CPUs(8)!
Would you like to proceed with the download? y/n

But then results in the following error when answering 'y':
Traceback (most recent call last):
  File "/Users/marcus/.pyenv/versions/3.6.7/bin/soch-download", line 186, in <module>
    start()
  File "/Users/marcus/.pyenv/versions/3.6.7/lib/python3.6/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/Users/marcus/.pyenv/versions/3.6.7/lib/python3.6/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/Users/marcus/.pyenv/versions/3.6.7/lib/python3.6/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/marcus/.pyenv/versions/3.6.7/lib/python3.6/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/Users/marcus/.pyenv/versions/3.6.7/bin/soch-download", line 179, in start
    confirm(query, outdir)
  File "/Users/marcus/.pyenv/versions/3.6.7/bin/soch-download", line 91, in confirm
    return pre_fetch(query, required_n_requests, outdir)
  File "/Users/marcus/.pyenv/versions/3.6.7/bin/soch-download", line 62, in pre_fetch
    fetch(build_query(query, 500, start_record), start_record, outdir)
TypeError: do_task() takes 0 positional arguments but 3 were given

Tested with Python 3.6.7 and 3.7.1.

@carwash could you share the command you are trying to execute?

Any and all queries I've tried result in the same error, but let's say for example:
soch-download --action=query --query='serviceName="bbrp"' --outdir=xml --key=test
…where the ./xml directory definitely exists and is writeable, and python -V returns Python 3.6.7 or Python 3.7.1. Starts fine, but when you hit 'y' to proceed, it dies.

I see that you've changed the title of this bug to something (presumably) more descriptive. With that in mind, is it possible that this isn't a bug at all, but that the versions of Python I have installed have simply been compiled without threading support?


Add VTK output

Hi,
I found your project useful for some tests of mine, thanks for making it available!
Postprocessing with paraview is sth that I like to do, so I decided to implement it
Please let me know if this is a contribution you are interested in. I can of course also make it optional, via feature or input argument.
Attached is the example in vtk-files so that you can take a look
Thanks!
vtk_output.zip

@cmccomb

Thanks for opening this PR @philbucher! I should be able to look into the failed check in the next few days but please feel free to act on it before I do.
What do you think about adding a test for VTK output? It would also be great to have a usage example for cookbook.rs and examples/!

I should be able to look into the failed check in the next few days but please feel free to act on it before I do.

I think the tokio::Runtime is outdated, does not seem to be related to my changes

What do you think about adding a test for VTK output? It would also be great to have a usage example for cookbook.rs and examples/!

sure that makes sense. I will have a look after the holidays. I can most probably also update the tokio failures, if you havent done it already


importing pascalprecht.translate with webpack

I currently have the following imports in my index.js .
import angular from 'angular';
import ngAnimate from 'angular-animate';
import ngCookies from 'angular-cookies';
import ngSanitize from 'angular-sanitize';
import ngMessages from 'angular-messages';
import ngResource from 'angular-resource';
import ngRoute from 'angular-route';
import uiBootstrap from  'angular-bootstrap';
import uiRouter from 'angular-ui-router';
import ngDragDrop from 'angular-dragdrop';
import 'angular-translate';
import 'angular-translate-loader-static-files';
import 'angular-translate-once';

const requires = [
        'pascalprecht.translate',
]

When loading my page I get the following error:

Error: [$injector:modulerr] Failed to instantiate module pascalprecht.translate due to:
Error: [$injector:nomod] Module 'pascalprecht.translate' is not available! You either misspelled the module name or forgot to load it. If registering a module ensure that you specify the dependencies as the second argument.
http://errors.angularjs.org/1.6.6/$injector/nomod?p0=pascalprecht.translate

I think the import statement is correct but maybe something else is missing. Any suggestions?

I'm facing the same problem right now. Did you find a solution ?

Because the libraries do not specify the requirement (there are no modules), the correct order is important. Therefor, this looks ok.
Given the error message, I cannot say more without details.
Maybe the error "module not available" is produced by your own code because of a missing/too late dependency requirement on the module pascalprecht.translate.

Hello,
I'm closing this issue due inactivity. We have asked for additional details, but you could not helped us. Therefore we close this issue as not reproducible.
If you still have an issue, please create a new issue because we cannot be sure to track closed issues.


⚠ AGEG website (prod) has degraded performance

In e9ce9f2, AGEG website (prod) (https://www.ageg.ca/) experienced degraded performance:

HTTP code: 200
Response time: 2722 ms

Resolved: AGEG website (prod) performance has improved in f79c8ee.


Upgrade to actions v3

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (master@1581307). Learn more about missing BASE report.

Additional details and impacted files
@@            Coverage Diff            @@
##             master      #48   +/-   ##
=========================================
  Coverage          ?   92.15%
=========================================
  Files             ?        3
  Lines             ?       51
  Branches          ?        4
=========================================
  Hits              ?       47
  Misses            ?        0
  Partials          ?        4

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


Deletion rules for targets

Terminology
1. Confirmation prompt: This is a dialogue that warns you of a destructive action and prompts you for confirmation that you want to proceed.
2. Rationale prompt: This is a dialogue that warns you that changes are being logged and prompts you to type text into a rationale field.
Summary

We have always had confirmation prompts when you delete just about anything.

With Partner Access, we've introduced rationale prompts that replace some of the old confirmation prompts.

We do NOT require a rationale for every type of deletion.

However, for any deletion that does NOT require a rationale, we still need a confirmation prompt.

Some of these confirmation prompts seem to have gone missing, allowing deletions to proceed with no warning. This epic documents expected behaviors for deleting targets in a variety of scenarios. Other tickets cover other types of deletions.

To keep the UX consistent with what's been built for Partner Access, we can apply the same style of notification even when we're only confirming and not prompting for a rationale.

Deleting individual event targets is an action that needs a lot of attention -- it's totally non-functional at the moment.

Acceptance criteria
Scenario 1: Indicator with no targets / no results
As specified in the PA wiki, if results have not yet been associated with the indicator, deletion of the existing targets is NOT logged. However, we still need a confirmation prompt. If I complete all required fields, click Create targets, and then immediately click Remove all targets before saving the targets, the following things are true:

[x] 1. I see a red PNotify warning in the lower left corner of the indicator setup form with the following text:
Warning
This action cannot be undone.
Are you sure you want to remove all targets?

[x]  2. There are two buttons on this notification: OK and Cancel.

[x] 3. If I click Cancel or click the "X" in the upper right corner of the notification, it closes and nothing happens.

[x] 4. If I click OK, the following things happen:

[x] 4.1. The notification closes.

[x] 4.2. The "Target frequency" menu is reset to "--------".

[x] 4.3. We do NOT display a success message in this scenario.

[x] 5. All of the above is true for all target frequencies except LoP only.

[x] 6. All of the above is true regardless of whether you're adding a brand new indicator in the full page indicator setup form, or you're using the modal.(In the case of the full page version, "the lower left corner of the form" just means the lower left corner of the page -- as it's not in a modal.)

[x] 7. All of the above is true regardless of whether you're accessing the modal from the program page or the IPTT.

Scenario 2: Indicator with saved targets / no results
As specified in the PA wiki, if results have not yet been associated with the indicator, deletion of the existing targets is NOT logged. However, we still need a confirmation prompt. The difference between Scenario 1 and this one, is that in this case you've actually saved the targets.
Following is the desired behavior if you click "Remove all targets" for an indicator that has saved targets but no results.

[x] 1. I see a red PNotify warning in the lower left corner of the indicator setup form with the following text:
Warning
This action cannot be undone.
Are you sure you want to remove all targets?

[x]  2. There are two buttons on this notification: OK and Cancel.

[x] 3. If I click Cancel or click the "X" in the upper right corner of the notification, it closes and nothing happens.

[x] 4. If I click OK, the following things happen:

[x] 4.1. The notification closes.

[x] 4.2. The "Target frequency" menu is reset to "--------".

[x] 4.3. We do NOT display a success message in this scenario.

[x] 5. All of the above is true for all target frequencies except LoP only.

[x] 6. All of the above is true whether I'm accessing the modal from the program page or the IPTT.

Scenario 3: Indicator with saved targets / with results
As specified in the PA wiki, when an indicator has results linked to it, we must always prompt for a rationale if you click "Remove all targets." The interaction details all look good here. Just capturing here for completeness:

We prompt for a rationale.

The rationale field is required, and I get an error message if I submit without typing anything in.

If I type something in and click OK, the rationale prompt closes and the "Target frequency" menu is reset to "--------". We do NOT display a success message in this scenario.

All of this is true whether I'm accessing the modal from the program page or IPTT.

Scenario 4: Deleting an UNSAVED Event target without results linked to it
Event targets are unique in that they can be manually deleted, one by one. Prior to an event target having results linked to it, we do not prompt at all -- no confirmation, no rationale.
Right now, in the case of an unsaved event target -- deletion is not working for me on Dev2 the way it is on Production. If I click the red "X" box to the left of the Event target row, I get bounced to the top of the page and the event row just sits there.
Acceptance criteria

[x] 1. If there are no linked results, I can delete an unsaved event target with no confirmation prompt and no rationale prompt.

Scenario 5: Deleting a SAVED Event target with NO results linked to it.
Again, prior to an event target having results linked to it, we do not prompt at all -- no confirmation, no rationale. In the case of a saved event target without results, I get this error page:

[x] 1. If there are no linked results, I can delete a saved event target with no confirmation prompt and no rationale prompt.

Scenario 6: Deleting a SAVED Event target WITH results linked to it.
On Production, we have some pretty sophisticated logic where it checks to see how many results are linked to each event target.

If there are no results linked to a specific event, you can delete the target without any confirmation prompt.

If there are results linked to a specific event, you see the following confirmation prompt, where it tells you exactly how many results will be affected if you delete the event.

Right now on Dev2, I get an error page if I delete an event with results linked to it.

Now, with Partner Access, we are supposed to prompt you for a rationale whenever an indicator has results linked to it. So we need to preserve today's logic and warning message and incorporate a rationale prompt.
Acceptance criteria

[x] 1. If I delete an individual event that has one or more results linked to it, I get a rationale prompt with the following text. (Note the variable for quantity of results and the singular or plural of the word "result" depending on whether it's 1 or multiple.)
Warning
This action cannot be undone. Removing this target means that [#results] result[s] will no longer have targets associated with it.
For future reference, please provide a rationale for deleting this target.

[x] 2. If I attempt to submit without typing in text, I get the same error message I get in Scenario 3.

[x] 3. If I click Cancel or the "X" button, the prompt closes and nothing else happens.

[x] 4. If I type in the rationale box, the following things happen:

[x] 4.1. The prompt closes.
[x] 4.2. The event is deleted.
[x] 4.3. We do NOT display any success message.
[x] 4.4. The deletion action and rationale are logged in the change log.

Housekeeping

[ ]  Unit test/s written wherever applicable
[ ]  i18n tags included wherever applicable
[ ]  Functionality is accessible to people using screen readers

@hannalcamp Tagging you so that you can review and let us know if you have any questions or concerns, or have any Parthenon historical context to share.
In particular, please check out the gaps around event deletion -- just in case it requires any updates to documentation, training materials, etc.

Accidentally closed the ticket instead of opening it... Because I'm talented like that.

@camgnostic When I try to delete an Event target without existing results linked I get the following screen

QA - FAILED

The message displayed when attempting to remove an event with linked evidence does not meet the required message in the criteria for this ticket, which should read: "Warning
This action cannot be undone. Removing this target means that [#results] result[s] will no longer have targets associated with it.
For future reference, please provide a rationale for deleting this target."

That's what I'm seeing on dev2 (screenshot attached) . Are you positive in your test case you had results attached?  Can you give me a step-by-step recreate so I can find the edge case you bumped into?

QA - PASSED

Scenario 6 is now passing, additionally, with the rest of the scenarios in this ticket. Moving to deploy ready


Still submit successfully in case do not select account when unstake

To reproduce the bug
Version test: v1.0.2(150)
Devices test: IP 11
Steps:

Go to the Unstake detail in All account mode
Input Amount valid
Click on Submit button

Actual: Still unstake succsessfully
Expect: Disable button Submit when do not select account

Version test: v1.0.2(153)
Devices test: IP 11
Validation passed.


Feature: GitHub action for common tasks

Across reusable workflows, we need:

[ ] Checkout the repo at the right ref
[ ] Build the builder
[ ] Download-verify the builder
[ ] Push assets to a release

We need common GitHub actions to perform these task, to avoid copy/paste of the same code.
The actions can be hosted in this repo and called by reusable workflows:
uses: slsa-framework/slsa-github-generator/actions/checkout-builder // Note: may just be hidden inside build-builder, I think
...
uses: slsa-framework/slsa-github-generator/actions/build-builder
  with:
    ref: needs.detect-env.outputs.ref
    repo: needs.detect-env.outputs.repo

...

uses: slsa-framework/slsa-github-generator/actions/download-builder
  with:
    name: ...
    sha256: ${{ needs.builder.outputs.sha256 }}

I LOVE THIS IDEA. This would make it foolproof to setup trusted builders. Which is more important than distributing builders :)

Is this achieving the same thing as #22 ?

No. https://github.com/slsa-framework/slsa-github-generator/issues/22 suggest we have an action to install a CLI.
This issue suggest we create actions for the building blocks used within the reusable workflow.
I think https://github.com/slsa-framework/slsa-github-generator/issues/22 is a subset of this issue, since it's an action to help install the builder as a CLI (and it would need to perform the checkout as well)

/cc @bcoe who is working on a PoC for the npm ecosystem. If you have a further thought, let us know

@laurentsimon @MarkLodato I'm looking to move the detect-workflow action to a separate repo so it's easier to invoke in our workflows and we can avoid the chicken-and-egg problem we get when actions are in the same repo.
Are you able to create new repos under slsa-framework and could you create it for me? Since our reusable workflows will be the primary users I think it's best created here instead of another org.

For my information, could you describe the chicken-and-egg problem? I would have thought that having it in the same repo is easier because then the whole workflow is hermetic.

The action needs to be called by the re-usable workflow to determine at which ref it must checkout itself, but to call itself it needs to know a ref to itself. That's the chicken-and-egg problem. @ianlewis confirmed?
I think this means any other Action we create will go into this separate repo, e.g. the Action that compares hashes, the Action that upload assets, etc

The action needs to be called by the re-usable workflow to determine at which ref it must checkout itself, but to call itself it needs to know a ref to itself. That's the chicken-and-egg problem. @ianlewis confirmed?

Yeah, when you run an action in the same repo as the workflow, just like the workflow, you need to check out the repo beforehand.
See: https://docs.github.com/en/actions/learn-github-actions/finding-and-customizing-actions#adding-an-action-from-the-same-repository
So in our case we could reference it like:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # This checks out the user workflow by default (listed in github context)
      # but we need the reusable workflow repo & ref.
      # So we need to specify the repo and ref here ourselves...
      - uses: actions/checkout@v3
      # ... but we don't know that until after this action runs!
      - uses: ./.github/actions/detect-workflow

But this won't work until we've checked out the repo already. We need to know the right ref in order to do that and the action is what's supposed to tell us the right ref!
Also, If we want to use this action in workflows outside of slsa-github-generator (e.g. slsa-github-generator-go, or slsa-github-generator-ko) or allow folk who make their own builders to use it, then it will need to be in it's own repo as well. This is because  the options for referencing an action in a different repo require that repo to be dedicated to the action ({owner}/{repo}@{ref}).
Right now we have some inlined bash code in the yaml but it's ugly, doesn't do any verification of the OIDC token, and will need to be copied to any reusable workflow that needs to use it.

Ah, thanks for the explanation! Could you put that in the new README for documentation?
I added you to the slsa-framework organization so you can create the repo yourself once you accept the invite. That name sounds good to me. Thanks!

After playing with this again it seems I was pretty mistaken. As @laurentsimon alluded to at the top, you can reference actions in another repo with a path so they don't need to be in a dedicated repo (Its not important but I had trouble doing this and misunderstood the reason why)
We just need to statically pick a good revision that we can use to run actions.
 - id: detect-workflow
   uses: slsa-framework/slsa-github-generator/.github/actions/detect-workflow@8d0cdc6af66f20f62b5a58df634077cb421b68fd
 - id: print
    shell: bash
    env:
      REPO: "${{ steps.detect-workflow.outputs.repository }}"
      REF: "${{ steps.detect-workflow.outputs.ref }}"
    run: |
      echo $REPO
      echo $REF

This is essentially what we would have to do if it was hosted externally in a different repo anyway. It's just potentially a bit more confusing for workflows in this repo because we're running actions at a previous version in this repo, while building with later versions of the same repo.
So I think an external repo is unnecessary. Sorry about the confusion.

I really like the idea of factoring out common pieces of the reusable workflows, however the GitHub documentation on Reusing workflows states, in the Limitations section that:

Reusable workflows can't call other reusable workflows.

I really like the idea of factoring out common pieces of the reusable workflows, however the GitHub documentation on Reusing workflows states, in the Limitations section that:

Reusable workflows can't call other reusable workflows.

Yeah, It's one reason we've so far gone with actions to hold reusable code, but it may become more of an issue as we have larger multi-step logic that needs to be reused.

@naveensrinivasan the item Push assets to a release is the one where we re-write the upload ourselves, instead of relying on a 3P action.

I'm going to take a stab at the artifact download/upload and builder action


scipy no attribute 'tril' - need specific version

The install script does not specify versions for anything except flax and numpy. This results in scipy 1.13.1 being installed in my case. This version of scipy is too new apparently and no longer includes 'tril':
@_wraps(scipy.linalg.tril)

AttributeError: module 'scipy.linalg' has no attribute 'tril'
print(scipy.version)'
1.13.1
Can you please provide a complete environment.yml file with versions specified from a working install?

Scipy should be 1.12.x or lower


OVDB-68: Add an error directive if using a deprecated version of the OpenVDB ABI

I looked at adding deprecations around all functions and classes, but it didn't seem all that useful. Most of the ABI macro branching is to add new functions which is obviously not going to trigger deprecated warnings. In addition, many of the ABI changes are subtly changing the existing function signature (adding a const for example). I think this might not be a particularly obvious way of alerting the user.
Instead I've gone with the following, simply making a compile error with a clear error message. A compiler flag can then optionally suppress the error. I considered using #warning or pragma warnings to achieve the same thing, but this is not very portable, so this approach seemed less problematic.
Looking for some input on the mechanism that the user could use to provide the OPENVDB_USE_DEPRECATED_ABI flag?

many of the ABI changes are subtly changing the existing function signature (adding a const for example). I think [deprecation] might not be a particularly obvious way of alerting the user.

I see only a handful of functions, all in Grid.h, that would need to be deprecated (in addition to the CopyPolicy enum in Types.h), and making a const argument non-const, as in the shallow copy constructors, is indeed the kind of change we want to alert users to, since it will likely necessitate changes to their code.

@pcucka - I just updated the PR with those changes (ignore the circle and appveyor failures for the time being)

Would you mind to add a Doxygen comment to each of those deprecated functions?  Something simple like this would do:
/// @deprecated ABI versions older than 4 are deprecated.