Fix 161 via assets version module

Implementing what we discussed on Monday.
This change introduces checking of the user's local worker assets version using the version property in their project.json file and comparing it to the default worker assets version. If the values are the same, we continue with the command, otherwise, we emit an error message, e.g.:

Your local worker project assets in /Users/wxyz/sa161/version0 implements a different
version (0.0.0) than expected by this version of Serverless Artillery (0.0.1).

To continue to use this version of SA, please run the "configure" command
in a clean directory and then customize your worker's assets.

Here's the testing steps I've performed:

Install legacy version of SA (what's currently published to NPM)
Run slsart configure in a clean directory to unpack the worker assets
Uninstall SA globally (not strictly necessary)
Install candidate version of SA (from my local repo)
Run slsart invoke in the same directory where the legacy worker assets were unpacked and verify that we see the error above.
Run slsart monitor and verify the same.
In a clean directory run slsart configure to unpack the newer worker assets
Run slsart invoke in the same directory where the newer worker assets were unpacked and verify that SA invokes.
Run slsart monitor and verify monitor assets are unpacked.

Removing WIP from PR title, because I believe this is a good working MVP to prevent disaster and could be merged today without harm to the future objectives associated with worker assets integrity and upgrade capabilities.
This change introduces checking of the user's local worker assets version using the version property in their project.json file and comparing it to the default worker assets version. If the values are the same, we continue with the command, otherwise, we emit an error message, e.g.:

Your local worker project assets in /Users/a09y/sa161/version0 implements a different
version (0.0.0) than expected by this version of Serverless Artillery (0.0.1).

To continue to use this version of SA, please run the "configure" command
in a clean directory and then customize your worker's assets.

Here's the testing steps I've performed:

Install legacy version of SA (what's currently published to NPM)
Run slsart configure in a clean directory to unpack the worker assets
Uninstall SA globally (not strictly necessary)
Install candidate version of SA (from my local repo)
Run slsart invoke in the same directory where the legacy worker assets were unpacked and verify that we see the error above.
Run slsart monitor and verify the same.
In a clean directory run slsart configure to unpack the newer worker assets
Run slsart invoke in the same directory where the newer worker assets were unpacked and verify that SA invokes.
Run slsart monitor and verify monitor assets are unpacked.

So much code and change for a check whether two package.json files have the same version.

You're the one insisting on constructing for a future-proof feature, so I'm introducing a module, outside of index.js to codify our version handling. Or should I add to the monolith problem we have with that file?

I was overly grumpy in my response.  It's true.  I don't imagine an apology will go too far but...  I'm sorry for not doing better.

So much code and change for a check whether two package.json files have the same version.

You're the one insisting on constructing for a future-proof feature, so I'm introducing a module, outside of index.js to codify our version handling. index.js is a monolith and we need to start breaking it up.

We have agreed for a while that it needs breaking up.  The following implements this while making the guard rail also targeted to the scenario (invocation with -m) that risks the bad experience.  If it's worth anything, I wrote it after our slack communications because those stoked my curiosity.
validateServiceForInvocation: (options, script, cwd = process.cwd) => {
  let toss = false
  try {
    const localService = require(path.join(cwd(), 'package.json')) // eslint-disable-line global-require import/no-dynamic-require
    toss = !('version' in localService) &&
      (
        options.monitoring ||
        script.mode === task.def.modes.MON ||
        script.mode === task.def.modes.MONITORING
      )
  } catch (ex) {
    // can't be found.  that's okay, we could be using the default service
  }
  if (toss) {
    throw new Error([
      `${os.EOL}\tYour local function project assets in ${cwd()} implements a service`,
      `${os.EOL}\tversion that does not support invocation with the monitoring flag.`,
      `${os.EOL}\t`,
      `${os.EOL}\tTo use monitoring mode, please run the "configure" command`,
      `${os.EOL}\tin a clean directory and then customize your worker's assets.`,
    ].join(''))
  }
},

This implements the most reductive, bad UX possible.

I'd argue that the experience we're preventing the user from having is worse.

The negative outcome of invoking a function that doesn't support monitoring mode with the mode set to monitoring would be an unexpected performance test execution.  That is negative and we agree.  However, as you've coded this, a dedicated user that hears about and is excited to try out monitoring mode might update the tool and find themselves unable to use it against their prior assets.  Which means that they are rewarded for upgrading by having a schism applied to them where they must choose between their existing investment or the new functionality.  That seems like a really unfriendly choice for us to make (particularly prior to upgrade) and it is easy to be targeted at avoiding the negative experience, as per the above snippet.
None of this yet addresses the scenario where they are trying invoke -m against the deployed but not updated default function or a scenario where they have updated the local assets (perhaps by hand) but not the remote function.  I don't think this was part of the original scope in the discussion so just calling it out to make sure we maintain awareness.


feat: Add Ralph Rosael to the list

Added Ralph Rosael to the list. Thank you! :)

The PR is getting blocked from getting merged due to conflicting files, please sync the repository @coder-ralph


Fix recommended deny rule for BGInfo

The current recommended (template) rule for denying vulnerable versions of BGInfo.exe is incorrectly set to MinimumFileVersion="<IP_ADDRESS>" even though all versions up to and including 4.21 are the vulnerable ones.
This pull requests fixes these by replacing it with MaximumFileVersion="<IP_ADDRESS>", therefore no longer blocking the fixed versions of BGInfo.
Reference:
"1 A vulnerability in bginfo.exe was fixed in version 4.22. If you use BGInfo, for security, make sure to download and run the latest version of BGInfo. BGInfo versions earlier than 4.22 are still vulnerable and should be blocked."
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/applications-that-can-bypass-appcontrol
Fixed in v4.22:
"This release of Bginfo honors Device Guard policy for VB scripts specified as the source of field data."
https://techcommunity.microsoft.com/blog/sysinternals-blog/sysinternals-update-procdump-v9-autoruns-v13-71-bginfo-v4-22-livekd-v5-62-proces/726072

@microsoft-github-policy-service agree


balanced classes and iter_data

Thanks Nikki.
Minor request before merging: can you reformat so that there are 80 - 90 columns per line?


installed node-notifier in services

Added node-notifier in services.
Without it we had to install node-notifier explicitly in services (nmp I wouldn't install it).
And tests wouldn't pass if you generate the app not in main root folder.

@all-contributors please add @shanizlo  for code


Add support of methods with varargs and #{options.option ...}

There 2 issues:

Current code can not resolve the code with varargs e.g. Options.option
Options does not have option method with String varargs which is implied by FakeValuesService

This PR adds check if there is varargs in method args and supports it, also adds Options.option with String varargs to make it working like
#{options.option '12','345','89','54321'}

the PR is same as https://github.com/DiUS/java-faker/pull/703

Hi @snuyanzin , thanks again. It took me a bit longer to review this one, since I've added similar code recently, though I added it to Faker itself. I'll move my code also to Options.


Remove the hardcoded base_url for webpack asset package

As stated in the doc in AppKernel.php there is a conditional/hardcoded value for the base_url as stated in the issue title, this is not ideal if we want to develop using virtualhosts like in a virtualized environment, it will be better to handle this during the bundle configuration and leave the user to set the base_url in the config.yml file

Thanks @robertodormepoco! I have included your suggestion.


🔨 Fix docker dav1d shared library linking

Adding explicit linking to the process appears to fix the error that I was experiencing in Docker builds that I mentioned in #406:
stump  | /app/stump: error while loading shared libraries: libdav1d.so.7: cannot open shared object file: No such file or directory
stump exited with code 0

The Dockerfile still does not build locally despite adding a step to generate prisma.rs because of this error but that seems to be a separate issue:
                                                      ^^^^^^^^^^^^ help: a static with a similar name exists: `DATAMODEL_STR`
175.6
175.6 error[E0425]: cannot find value `MIGRATIONS_DIR` in module `super`
175.6  --> core/src/prisma.rs:3:3446816
175.6   |
175.6 3 | ...igrate_deploy (super :: DATAMODEL_STR , super :: MIGRATIONS_DIR , & self . 0 . url ()) . await ; :: prisma_client_rust :: tokio :: tim...
175.6   |                                                     ^^^^^^^^^^^^^^ not found in `super`
175.6
175.6 error[E0425]: cannot find value `MIGRATIONS_DIR` in module `super`
175.6  --> core/src/prisma.rs:3:3447215
175.6   |
175.6 3 | ...e (migration , super :: DATAMODEL_STR , super :: MIGRATIONS_DIR , & self . 0 . url () ,) . await } pub fn _db_push (& self) -> :: pris...
175.6   |                                                     ^^^^^^^^^^^^^^ not found in `super`
175.6
175.6 For more information about this error, try `rustc --explain E0425`.
175.6 error: could not compile `stump_core` (lib) due to 5 previous errors

I had to overwrite the entrypoint on my docker compose to get this to successfully run: entrypoint: ["/bin/sh", "-c", "echo '/usr/local/lib' >> /etc/ld.so.conf.d/mylibs.conf && ldconfig && /entrypoint.sh"] but I did get it to work with this branch!

The change that I just pushed allowed me to just run the image without changing the entrypoint in my compose.yml and it appears to be up and running a-okay now

@wolffshots I made a few changes, since nightly is broken I wanted to make sure at the very least a working image goes out sooner rather than later. I appreciate your fixes! I translated them slightly to work for the arm64 build and then tweaked the ldconfig to the final layer in order to omit having to add it in the entrypoint exec. I left your change to generate the prisma client in the docker file, mostly because I am curious how it performs. If it winds up having to download the engines each time, I'll likely revert it. Best case scenario, though, it makes it easier for folks like you to build the images locally without needing a rust environment setup 🙂
After some discussions on Discord, once this fix is merged I will likely revert the AVIF-specific additions until another time when a more batteries-included solution can be put together.

Great stuff! Glad to have been able to help and thanks for all the hard work

I left your change to generate the prisma client in the docker file, mostly because I am curious how it performs. If it winds up having to download the engines each time, I'll likely revert it. Best case scenario, though, it makes it easier for folks like you to build the images locally without needing a rust environment setup 🙂

I had to remove it, with prisma generation it stalled after 4+ hours on the arm64 build. The build without it completed both amd64 and arm64 in just over an hour 😅
But I added some parameters you can use to generate it in the docker build. You can do something like:
PLATFORMS='linux/amd64' TAG='local' RUN_PRISMA_GENERATE=true ./docker/build.sh

I had to remove it, with prisma generation it stalled after 4+ hours on the arm64 build. The build without it completed both amd64 and arm64 in just under 2 😅

Fair that makes sense

But I added some parameters you can use to generate it in the docker build. You can do something like:
PLATFORMS='linux/amd64' TAG='local' RUN_PRISMA_GENERATE=true ./docker/build.sh

Great stuff, that's all good by me


Ho

I assume you missed to add content. I'll give you 3 days to correct his, otherwise I have to report the issue to github to prevent bot content.

Good


Strided GEMM Failing

Platform: macOS and some Linux
Problem: multiplying A & B with at least one side generically-strided (e.g. A = view(Abase, 1:Mst:M, ...) | Mst>1) yields all-0 results.
Possible cause: upstream (reproduced in C).
Status: investigating.
Workaround: as is stated in README.jl, failed methods can be blacklisted to block from the LinearAlgebra interface:
echo "gemm" > ~/.blis_jlbla_blacklist
# Trigger JIT reload.
touch $(find ~/.julia/packages/ -name "BLIS.jl" | tail -n 1)

Maybe this is the cause: flame/blis#484


Allow incrementing/decreasing by custom number

Hi,
would be great if we could be able to set a counter to be able to increase/decrease a counter by a custom value, which is a use-case I often have a need for.
E.g. in other counting apps, I often create a counter that I use for general counting and name them something like +10, +20, etc. and then set the default value for increasing the counter to e.g. +10, +20, etc. So when I tap the + button it increments the value by 10, which can be quicker (and less likely that I miss to increment the counter) instead of tapping the + button for every single item I count. Then I keep the value for decreasing at -1 in case the final number is not rounded.

Closed as duplicate of #13.
Math operation functionality was added recently, does that fit your use case?


TypeError: 'NoneType' object is not subscriptable

Hi, during training, I got an error as below.
2021-06-09 14:10:21.451241: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
2021-06-09 14:10:22.281671: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcuda.so.1
2021-06-09 14:10:22.294018: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-06-09 14:10:22.294396: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1716] Found device 0 with properties:
pciBusID: 0000:01:00.0 name: TITAN Xp computeCapability: 6.1
coreClock: 1.582GHz coreCount: 30 deviceMemorySize: 11.91GiB deviceMemoryBandwidth: 510.07GiB/s
2021-06-09 14:10:22.294418: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
2021-06-09 14:10:22.295529: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcublas.so.10
2021-06-09 14:10:22.296210: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcufft.so.10
2021-06-09 14:10:22.296353: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcurand.so.10
2021-06-09 14:10:22.297998: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusolver.so.10
2021-06-09 14:10:22.298682: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusparse.so.10
2021-06-09 14:10:22.301049: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudnn.so.7
2021-06-09 14:10:22.301142: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-06-09 14:10:22.301557: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-06-09 14:10:22.301903: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1858] Adding visible gpu devices: 0
2021-06-09 14:10:22.302099: I tensorflow/core/platform/cpu_feature_guard.cc:142] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN)to use the following CPU instructions in performance-critical operations:  AVX2 FMA
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2021-06-09 14:10:22.306142: I tensorflow/core/platform/profile_utils/cpu_utils.cc:104] CPU Frequency:<PHONE_NUMBER> Hz
2021-06-09 14:10:22.306447: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0xa167020 initialized for platform Host (this does not guarantee that XLA will be used). Devices:
2021-06-09 14:10:22.306458: I tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): Host, Default Version
2021-06-09 14:10:22.469818: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-06-09 14:10:22.470282: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0xa1d2ae0 initialized for platform CUDA (this does not guarantee that XLA will be used). Devices:
2021-06-09 14:10:22.470300: I tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): TITAN Xp, Compute Capability 6.1
2021-06-09 14:10:22.470446: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-06-09 14:10:22.470815: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1716] Found device 0 with properties:
pciBusID: 0000:01:00.0 name: TITAN Xp computeCapability: 6.1
coreClock: 1.582GHz coreCount: 30 deviceMemorySize: 11.91GiB deviceMemoryBandwidth: 510.07GiB/s
2021-06-09 14:10:22.470844: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
2021-06-09 14:10:22.470862: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcublas.so.10
2021-06-09 14:10:22.470874: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcufft.so.10
2021-06-09 14:10:22.470886: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcurand.so.10
2021-06-09 14:10:22.470897: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusolver.so.10
2021-06-09 14:10:22.470909: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusparse.so.10
2021-06-09 14:10:22.470921: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudnn.so.7
2021-06-09 14:10:22.470962: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-06-09 14:10:22.471343: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-06-09 14:10:22.471692: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1858] Adding visible gpu devices: 0
2021-06-09 14:10:22.471718: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
2021-06-09 14:10:22.786787: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1257] Device interconnect StreamExecutor with strength 1 edge matrix:
2021-06-09 14:10:22.786817: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1263]      0
2021-06-09 14:10:22.786824: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1276] 0:   N
2021-06-09 14:10:22.786984: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-06-09 14:10:22.787437: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-06-09 14:10:22.787818: W tensorflow/core/common_runtime/gpu/gpu_bfc_allocator.cc:39] Overriding allow_growth setting because the TF_FORCE_GPU_ALLOW_GROWTH environment variable is set. Original config value was 0.
2021-06-09 14:10:22.787842: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1402] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 11210 MB memory) -> physical GPU (device: 0, name: TITAN Xp, pci bus id: 0000:01:00.0, compute capability: 6.1)
Total Params 2559576
Img Model 2405676
Text Model 153900
Loading Saved Model
  0%|                                                                                | 0/2527 [00:00<?, ?it/s]2021-06-09 14:10:38.988999: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcublas.so.10
  5%|█████                                                                                | 116/2527 [07:03<2:11:06,  3.26s/it]
Error in  train/104298.jpg
Traceback (most recent call last):
  File "trainer_scipt.py", line 232, in <module>
    train_joint_model()
  File "trainer_scipt.py", line 156, in train_joint_model
    train_model(epoch)
  File "trainer_scipt.py", line 80, in train_model
    for batch_idx, (img, text_match, text_diff, seq_len_match, seq_len_diff, bboxes, bbox_classes) in enumerate(
  File "/home/mimiliaogo/MMFinal/COSMOS/env/lib/python3.8/site-packages/tqdm/_tqdm.py", line 1000, in __iter__
    for obj in iterable:
  File "/home/mimiliaogo/MMFinal/COSMOS/env/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 363, in __next__
    data = self._next_data()
  File "/home/mimiliaogo/MMFinal/COSMOS/env/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 403, in _next_data
    data = self._dataset_fetcher.fetch(index)  # may raise StopIteration
  File "/home/mimiliaogo/MMFinal/COSMOS/env/lib/python3.8/site-packages/torch/utils/data/_utils/fetch.py", line 47, in fetch
    return self.collate_fn(data)
  File "/home/mimiliaogo/MMFinal/COSMOS/utils/dataset_utils.py", line 96, in __call__
    return self.pad_collate(batch)
  File "/home/mimiliaogo/MMFinal/COSMOS/utils/dataset_utils.py", line 73, in pad_collate
    t1 = list(map(lambda x: x[self.embed_dim1], batch))
  File "/home/mimiliaogo/MMFinal/COSMOS/utils/dataset_utils.py", line 73, in <lambda>
    t1 = list(map(lambda x: x[self.embed_dim1], batch))
TypeError: 'NoneType' object is not subscriptable

It shows that there is an error in the training image.

I could replicate the issue, turns out that this is happening due to an error in external flip/rotate augmentations that we were using. I have fixed the issue by simply bypassing the error for time being. This should get your code up and running. Git pull the utils/dataset.py file and it should work. Will be uploading a proper workaround soon. :)

Could reproduce the issue as well, but the patch does not seem to solve the issue for us. Getting the following error now:
File "trainer_scipt.py", line 232, in
train_joint_model()
File "trainer_scipt.py", line 156, in train_joint_model
train_model(epoch)
File "trainer_scipt.py", line 86, in train_model
bboxes, bbox_classes)
File "/home/ubuntu/anaconda3/envs/cosmos/lib/python3.7/site-packages/torch/nn/modules/module.py", line 889, in _call_impl
result = self.forward(*input, **kwargs)
File "/home/ubuntu/COSMOS/model_archs/models.py", line 51, in forward
img = self.maskrcnn_extractor(img, bboxes, bbox_classes)
File "/home/ubuntu/anaconda3/envs/cosmos/lib/python3.7/site-packages/torch/nn/modules/module.py", line 889, in _call_impl
result = self.forward(*input, **kwargs)
File "/home/ubuntu/COSMOS/model_archs/image/image_models.py", line 45, in forward
zip(bboxes, bbox_classes, img_shapes)]
File "/home/ubuntu/COSMOS/model_archs/image/image_models.py", line 44, in
bbox, bbox_class, img_shape in
File "/home/ubuntu/COSMOS/utils/img_model_utils.py", line 23, in annotations_to_instances
target.classes = classes
File "/home/ubuntu/COSMOS/detectron2/detectron2/structures/instances.py", line 61, in setattr
self.set(name, val)
File "/home/ubuntu/COSMOS/detectron2/detectron2/structures/instances.py", line 78, in set
), "Adding a field of length {} to a Instances of length {}".format(data_len, len(self))
AssertionError: Adding a field of length 11 to a Instances of length 1

Could you share the complete stacktrace. A similar issue was raised in #2 . This issue seems related to detectron not working properly.

This is actually the complete stack trace. Prior to this, there is tensorflow initialization log same as reported in https://github.com/shivangi-aneja/COSMOS/issues/2
By the way, when augmentation is completely removed (flip rotate transformation code commented out), this issue does not happen.

I have tested the current augmentation patch and it seems to work. Not sure why it throws an error for your setup. Could you please recheck your utils/dataset.py and compare it with one on github.

I am working with this issue right now.
It is in RandomScale. clipbox function drops all the bounding boxes. I am trying to figure out how it works, could you please double check it, at least its 2nd input [0, 0, 1 + img_shape[1], img_shape[0]] looks strange, it's assymetric.

I am working with this issue right now.
It is in RandomScale. clipbox function drops all the bounding boxes. I am trying to figure out how it works, could you please double check it, at least its 2nd input [0, 0, 1 + img_shape[1], img_shape[0]] looks strange, it's asymmetrical.

Further investigation shows that there are quite a few images for which almost all blackboxes are on the border and, thus, they are removed.


Adds support of NonBlankStringType

Usually string-based fields have two possible values for “no data”: NULL, and the empty (blank) string.
In most cases, it’s redundant and can lead to mistakes.
This PR adds support for NonBlankStringType, which helps to avoid two possible values for “no data” by replacing blank lines with NULLs.

Why not use the @NotEmpty annotation instead? I don't think that input validation should be done by the Hibernate Type. Bean Validation already covers this responsibility.

Sure. It is possible to resolve the problem of two "no data" values of string based fields via validation, but:

Your application can be not the only source of data in your database (I know that it's not a good practice, but unfortunately I've seen quite a lot of projects where some data synchronisation between services was made via database).
Solving it through validation may lead you to multiple validation checks of DTOs cause there maybe quite a lot of API versions.

The philosophy of this solution is, that client sends "no data" string value to the application not caring about the format of this "no data" value (just like date and time values which can be accepted in any reasonable format).

Validation is needed on every layer boundary. So, you have it in the UI, Web Controllers, DAO layer and the DB. This will ensure that the failure happens as soon as possible and will allow reusing base layers on newer UI models like Mobile clients.
However, I don't see the value in having the Hibernate Types do validation. That sopuld be done way prior to flushing the entities. Hence, I'm closing this issue.


Make description fields unicode string

In test_tender_data_limited

This change is

:)

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from the review on Reviewable.io


feat: #536 update esbuild version to 0.21.0

update esbuild

Attempts a solution for https://github.com/floydspace/serverless-esbuild/issues/536

It seems as though @aws-sdk/client-cloudformation is no longer compatible with Node <16. Do the checks need to be updated to remove 14 and this be declared a breaking change? Or is there some other path for this to proceed?

@johnsonps08
Thanks for confirming.
First, the fact that the test fails with Node 14 has nothing to do with the esbuild version update.
The cause is the end of support for Node.js 14.x in aws-sdk-js-3 issue #6034.
Therefore, since the release of aws-sdk-js-3 v3.567.0 which includes #6034, tests for Node.js 14 will fail.

Do the checks need to be updated to remove 14 and this be declared a breaking change?

Since Node.js 14 is not listed in the supported runtimes, I think supporting Node.js 16 and 18 is sufficient.

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

Should we create an issue for end support for Node.js 14.x?

@johnsonps08
Thanks. issue and PR created.

Should we create an issue for end support for Node.js 14.x?

issue: https://github.com/floydspace/serverless-esbuild/issues/543
PR: https://github.com/floydspace/serverless-esbuild/pull/544


mini.surround: respect_selection_type doesn't work in blockwise mode

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md
[X] I have updated 'mini.nvim' to latest version

Module(s)
mini.surround
Description
When using blockwise mode and respect_selection_type, multiline selections aren't properly highlighted
Neovim version
NVIM v0.10.0-dev-2539+ga69c7206
Steps to reproduce

nvim -nu minimal.lua

--- minimal.lua
local path_package = vim.fn.stdpath("data") .. "/site/"
local mini_path = path_package .. "pack/deps/start/mini.nvim"
if not vim.loop.fs_stat(mini_path) then
  vim.cmd('echo "Installing `mini.nvim`" | redraw')
  local clone_cmd = {
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/echasnovski/mini.nvim",
    mini_path,
  }
  vim.fn.system(clone_cmd)
  vim.cmd("packadd mini.nvim | helptags ALL")
  vim.cmd('echo "Installed `mini.nvim`" | redraw')
end

require("mini.surround").setup({
  respect_selection_type = true,
  mappings = { add = "gza" },
})

Create file with this content:

line1
longline2
line3
longerline4
line5

gg go to first line
<c-q> enter blockwise
G select to last line
$ Select to end of lines
gza" Surround selection with "

Expected behavior
all lines are surrounded
"line1"
"longline2"
"line3"
"longerline4"
"line5"

Actual behavior
Lines are surrounded at the last line's length
"line1"
"longl"ine2
"line3"
"longe"rline4
"line5"

Note that if this is done on the 4th line instead longerline4, then shorter lines are not even properly surrounded.
"line1
"longline2
"line3
"longerline4"

Thanks for the issue!
Yes, this (block selected with $) is indeed the edge case that can be made better. However, it won't be done in 'mini.surround' for the following reasons:

Combination of respect_selection_type = true and blockwise selection until the end of line seems to be quite rare in practice. It can also be replicated by using macro. For example, 10| to navigate to the target column followed by sa$".
Actual implementation of this edge case is not trivial while 'mini.surround' is already quite a big and complicated module.

Closing as not planned.


mysql client v14 results in EOF error

MySQL client distributed with Centos6 connecting to secretless-broker v1.1.0 running on localhost:
# mysql --version
mysql  Ver 14.14 Distrib 5.1.73, for redhat-linux-gnu (x86_64) using readline 5.1

# mysql -h <IP_ADDRESS>
ERROR 2000 (HY000): EOF

From another host running Centos7, connecting back to the first host:
# mysql --version
mysql  Ver 15.1 Distrib 5.5.64-MariaDB, for Linux (x86_64) using readline 5.1

#  mysql -h <IP_ADDRESS>
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 12794395
Server version: 5.6.10 MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]>

secretless-broker console output:
# AWS_REGION=ap-southeast-2 ./secretless-broker
2019/10/11 01:13:38 Secretless v1.1.0-7f978b3 starting up...
2019/10/11 01:13:38 Loading internal plugins...
2019/10/11 01:13:38 - ConfigurationManagers: [configfile k8s/crd]
2019/10/11 01:13:38 - ConnectionManagers: []
2019/10/11 01:13:38 - Providers: [keychain kubernetes literal vault aws conjur env file]
2019/10/11 01:13:38 - Handlers: [mysql pg ssh sshagent http/aws http/basic_auth http/conjur]
2019/10/11 01:13:38 - Listeners: [ssh ssh-agent http mysql pg]
2019/10/11 01:13:38 Completed loading internal plugins.
2019/10/11 01:13:38 Loading external library plugins...
2019/10/11 01:13:38 open /usr/local/lib/secretless: no such file or directory
2019/10/11 01:13:38 Registering shutdown signal listeners...
2019/10/11 01:13:38 Initializing configuration manager 'configfile'...
2019/10/11 01:13:38 Trying to load ./secretless.yml...
2019/10/11 01:13:38 Configuration file ./secretless.yml loaded
2019/10/11 01:13:38 Configuration manager 'configfile' initialized (configSpec: '').
2019/10/11 01:13:38 Initializing connection managers...
2019/10/11 01:13:38 Initialization of plugins done.
2019/10/11 01:13:38 Initializing the proxy...
2019/10/11 01:13:38 Initializing health check on :5335...
2019/10/11 01:13:38 Initialization of health check done. You can access the endpoint at `/live` and `/ready`.
2019/10/11 01:13:38 Waiting for valid configuration to be provided...
2019/10/11 01:13:38 Configuration manager 'configfile' provided new configuration...
2019/10/11 01:13:38 Reloading...
2019/10/11 01:13:38 ----------------------------
2019/10/11 01:13:38 Registering reload signal listeners...
2019/10/11 01:13:38 Starting all listeners and handlers...
2019/10/11 01:13:38 mysql listener 'mysql_tcp' listening at: [::]:3306
2019/10/11 01:14:20 Instantiating provider 'literal'
2019/10/11 01:14:20 Instantiating provider 'aws'
2019/10/11 01:14:20 Instantiating provider 'file'
2019/10/11 01:20:14 source <IP_ADDRESS>:39384 closed for destination <IP_ADDRESS>:3306

@doodlesbykumbi have you used the connector with MySQL 5.6? Based on the troubleshooting page this looks like the type of error you get for using an unsupported MySQL version.
@porjo right now the versions of MySQL we support are much more limited than we'd like, and we have some ideas to support many more versions soon. According to our docs we only technically support 5.7 right now.
It looks like we don't currently have an issue for supporting more MySQL versions, but I'm looking into adding one with more details about our planned path forward here. I'll update when I have it.

@porjo please note we've added an issue to track the work that would be needed here: https://github.com/cyberark/secretless-broker/issues/930
since this issue appears to result from using an unsupported version of MySQL as documented, I'm going to close it now. please follow #930 for updates to this in the future.

It looks like we don't currently have an issue for supporting more MySQL versions, but I'm looking into adding one with more details about our planned path forward here. I'll update when I have it.

Sounds good.

According to our docs we only technically support 5.7 right now.

I've just tried connecting to a MySQL 5.7 server using the v14 client and get the same error when going through secretless-broker. Going direct works fine.

Are you disabling SSL on the client-to-secretless connection? From our current troubleshooting

Are you disabling SSL on the client-to-secretless connection?

SSL is disabled by default. AFAIK, the only way to enable it with the v14 client is with --ssl-ca=<file>  flag (which I'm not passing). Connecting direct to the MySQL server and running mysql command status says Not in use
mysql> status
--------------
mysql  Ver 14.14 Distrib 5.1.73, for redhat-linux-gnu (x86_64) using readline 5.1

Connection id:		84482848
Current database:
Current user<EMAIL_ADDRESS>SSL:			Not in use
Current pager:		stdout
Using outfile:		''
Using delimiter:	;
Server version:		5.7.19-log MySQL Community Server (GPL)

Hmm. I'm going to reopen this issue in that case. The team won't be back online until Tuesday, but we'll dig into this once we're able. Thanks for raising it!

@porjo the mysql service connector requires the client to connect with no SSL. Off the top  of my head I think the client should receive a meaningful error from secretless when trying to connect with SSL.
The mysql service connector currently forces the connection to use the mysql_native_password authentication plug in without any negotiation. That's the cause of any limitations the service connector might have. If the mysql server tries to negotiate anything other than mysql_native_password then the bahviour isn't great. We're working on improving this.

thanks @doodlesbykumbi - searching the backlog it looks like #556 is on adding support for alternate MySQL auth plugins.
I'm also curious whether a more recent version of the client would help - based on this thread it looks like the version of the client you're using is quite old.

@porjo To update you on the status so far, there are two distinct problems and I'm working on trying to figure out how difficult it would be to fix them:

(Bug) MySQL plugin does not seem to honor sslmode: disabled to override server-side lack of SSL support
(Unimplemented feature) MySQL plugin does not support that version of MySQL authentication plugin

I'll try to see what I can do about these - maybe it's not a lot of work.

@porjo Can you provide us your configuration stripped of any private info? We may have found the cause that is much more benign that we originally thought if you are using version: 2 of the configuration.

Here's the config I was using:
version: "2"
services:
  mysql_tcp:
    protocol: mysql
    listenOn: tcp://<IP_ADDRESS>:3306
    credentials:
      host: devdb1
      port: 3306
      username: webaccess
      password:
        from: aws
        get: MYSQL_WEBACCESS_PASSWORD
      sslmode: verify-ca
      sslrootcert:
        from: file
        get: rds-combined-ca-bundle.pem

@porjo Apologies for the delay in response - the team is all traveling to the main office this week so we have been a bit short on available time. I don't have the capabilities to test your configuration until next week but we have fixed one of the critical blockers that would prevent it from working in this PR. Do you have the capabilities to test this newer code or would you need some deliverable (container, executable, something else?) to try it out?

@porjo I finally managed to verify it and the fix pushed in the latest version (which should get tagged as v1.3.0 soon) should work for your use case!
I'm including some of my test notes below:
Secretless Git Hash: 5f12d39bd29beb7e9bed000fd5f9c7593f5c832f
MariaDB container:
docker run -it \
  -p <IP_ADDRESS>:3306:3306 \
  -v $(pwd)/maria_ssl.conf:/etc/mysql/docker-default.d/test.cnf
  -v $(pwd)/maria_certs:/etc/my.cnf.d/certificates \
  -v /tmp/mysql-log:/var/log/mysql \
  -e MYSQL_ROOT_PASSWORD=mypassword \
  -e MYSQL_GENERAL_LOG=1 \
  cytopia/mariadb-5.5

maria_ssl.conf
[mysqld]

ssl_cert = /etc/my.cnf.d/certificates/server-cert.pem
ssl_key = /etc/my.cnf.d/certificates/server-key.pem
ssl_ca = /etc/my.cnf.d/certificates/ca.pem

secretless.yml
version: 2
services:
  mysql-socket:
    protocol: mysql
    listenOn: tcp://<IP_ADDRESS>:3307
    credentials:
      username: root
      password: mypassword
      host: <IP_ADDRESS>
      port: 3306
      sslmode: verify-ca
      sslrootcert:
        from: file
        get: ./maria_certs/ca.pem

maria_certs/ca.pem
-----BEGIN CERTIFICATE-----
MIIFszCCA5ugAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwWzELMAkGA1UEBhMCVVMx
FjAUBgNVBAgMDU1hc3NhY2h1c2V0dHMxETAPBgNVBAoMCEN5YmVyQXJrMQ8wDQYD
VQQLDAZDb25qdXIxEDAOBgNVBAMMB1Jvb3QgQ0EwHhcNMTkxMTE5MTc1MDU4WhcN
MjkxMTE2MTc1MDU4WjB2MQswCQYDVQQGEwJVUzEWMBQGA1UECAwNTWFzc2FjaHVz
ZXR0czEPMA0GA1UEBwwGTmV3dG9uMREwDwYDVQQKDAhDeWJlckFyazEPMA0GA1UE
CwwGQ29uanVyMRowGAYDVQQDDBFJbnRlcm1lZGlhdGUgQ0EgMTCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAJMzqeJUFqNbl9n5mGBRs2bHD2aOFDiflaYy
8RVNN6SjsomvRllfLTNPi0oOYAoAYRn5gX1RyqGrU8jCzCcVeMFxs2CRKBxVD/ym
ItYPEUa/hgk/aOslhP8l1SspQBnbGtzQId0a2+qC4GSU0OeJ7WF8zH4p8CLc258W
zAgA6y2T8npszqBWnh+7G99c4QXTtU81dv2/7ZkyFcLXN53W6DkmylhyN2NJLcPR
yUOiknBElWORb9XKgrHGcbzlqleQMRaNd7krj9M+gQK7sh1gaCmcfaQFDUZtplJC
hXOgFHOAq1pEYf4w4Kt1LkIYHOyEeO74xc7t3fAWam97yWLApk1Y5DRnB47OySSx
WHMKPq5R6sth+XYL5yfCfmoQsp8Vw79aUlnxuAGxzR1rB2bKA4QcZVy0/uDC9yIn
ZageTHYX9KFVgRDHBdhwBjEgmJjNBcgnBsnLp7MHiCBsnD3SPKQ592AzWpUXAx0I
WP3d7/2zqE6IKUrz7V2mz3GXCqnFhzcEsU6PzTgs56wPs5mV5391ggB9Gtmdfk+0
NppYV1sCood7ZiCyG/poR7BIErenXV15e8dGP6gj5znfBtSrKo80TT2+B9qk8uNt
qJcI8n958jYdlWGDN5r8pLeoA8vmaM/6pPbFlJKQd1XZMyS/PLoolzCoRWj1zr6s
iRoR6ox/AgMBAAGjZjBkMB0GA1UdDgQWBBSjoUiphKz09GDH6mLhH3Bn0lQ2/DAf
BgNVHSMEGDAWgBRmY+mnf/xEVIofZc1FdhYxHbjzkTASBgNVHRMBAf8ECDAGAQH/
AgEUMA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOCAgEALUQp0aScT6/a
HtvEEPJtmm6tQAbZaT3aYoFLPNxu2rmZOLoE072uUIPXSICzqSW1ODV2gjz/TeI1
G5OL2DRipqPy3jbgra6v1+cxEhT7Yem/rzYFDFjSuwmE5ApmVMJdI7ikvJegCOQy
qyHsfF2In1BU23LEsQtvxK4m8UlkhiSbRNR2ZzzarDWDMe+L7liHTKWHvO+xBK59
0Bd68JwqhLn7I+3Jpwb2ajJpwZjngZJ7oqMFaW7ihUJGhYnfNmW6CzR8ZM0JrNBZ
o9WnFR+yQR0NsnWj1VZ0RW5szHomzxoyhHPgpOAizeM3G/50vSYGMinkmBwKrUK0
l6mTWEm/Z2bqBn1aGWHRxFsDtG3++1Q284avpAQiWUrFybUf7esMdSaPzI13jmWU
YJvOA3yw0NmuowS15dVkh4tpW4klL9LmC0auct5wfBL5dvcJILeZCxj8kBEL3oVF
VgZjB7SCPOkkyx5zmTFtutZzO3paqPbYKEaldd0cxsik7acrks98fPRgefJyRmJI
dQetuyGIiiVFIw90OPBNIiDe0gfS3AR3eE0W3kt8n4T+wtwwapYPCZ815uxz1Mdh
jxg0sjiz90uETNW8bFRJyQV4XV04KfPMSLhzyE0K97ydGsXELjsMXIYHpzdF10iO
830bYL3hsmDE+UrIOVJQ0sO2xJ7q4QY=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFpzCCA4+gAwIBAgIUB0Cf6M8SVXXGgCrgRq3bgHqHYJMwDQYJKoZIhvcNAQEL
BQAwWzELMAkGA1UEBhMCVVMxFjAUBgNVBAgMDU1hc3NhY2h1c2V0dHMxETAPBgNV
BAoMCEN5YmVyQXJrMQ8wDQYDVQQLDAZDb25qdXIxEDAOBgNVBAMMB1Jvb3QgQ0Ew
HhcNMTkxMTE5MTc1MDQ4WhcNMzkxMTE0MTc1MDQ4WjBbMQswCQYDVQQGEwJVUzEW
MBQGA1UECAwNTWFzc2FjaHVzZXR0czERMA8GA1UECgwIQ3liZXJBcmsxDzANBgNV
BAsMBkNvbmp1cjEQMA4GA1UEAwwHUm9vdCBDQTCCAiIwDQYJKoZIhvcNAQEBBQAD
ggIPADCCAgoCggIBAKKJnlxF3FXrAB43YugBVxFpu95hwxq4PNt1Pfpp6wF1tXPE
IDqmqKfjaLohA2XxUvuIC0BQlp7EASg4FHufaqQuw6+vbO/u4qJHxNk6NW+cJ3qP
otYnpgO6Bc7CGSDselFkoRXnMc/VW314CKHhQIyHEhHtjgtF79FjoW72FPx/OQlv
bm1t2hbznxFIMZd7haumftHiNbeKoLL9WisjouBiojLI8T8790hoFuyL+gTcgf9k
xJi7RbFGki6uABsC3Y5HkSS7uNNwcOYo129gSVus2WRvYNNIMicfwuhAPJEJyiNA
XRfuQ7x5R4DTbnqunIEskVcy+wU/b6EvN21AalfLAkoGLrUVEVpesJvwtkgzSbSS
VdqCA0havieR85vx7oX7dsfrQvgW8Cp1lCSPPUDm/4STmQblwVQW6gRrt7AONVLM
xm70i+RBNfQ1pjk0xc8R1gYRiF8YaHES1RWWA5urhTnMRxKCimkgDt3AiS2EAR2z
JAqSGXoizNtm5K2pCU99XDbCTDfkRpvP6YI8y2ffilXBwEVzIhY+y1UKX/QNDbJJ
upHiQ4hMEtiQ83TcJF+ap61KMFYMDSOMK+9rDAY9ZSkbmHSxiHwhoPle4VKbPuiv
qVm80pgMOrXUCd7drFG/sixFZVp9asJlC+BLVdrUZsp4zf+bvJ5KxyyXv+IjAgMB
AAGjYzBhMB0GA1UdDgQWBBRmY+mnf/xEVIofZc1FdhYxHbjzkTAfBgNVHSMEGDAW
gBRmY+mnf/xEVIofZc1FdhYxHbjzkTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB
/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOCAgEASIi+8vzxWhnj+BScqNB2iMbGwYii
6oIADUbete1XCdWPZPxVoApe+wbD61ERvGEPRTnPppxqZkvxKifSVVBDj6FazKK8
nQWhYZDbOaTZ/YrnuADTHXy0y5HpURZGE9YxZp2bVYxC3nHgVxYsT4f1QNQEeqU+
aHNsE6/QuRGKsZH5uE1C9xAYqWV5omP+2TKuXDsMFvxxtqEs4V7fkhZvWtlvZzfW
UJTdclkJ5gbz8cmoEKQn5/F9U4HIfHvRWEnQ4x+zX5Y5fmxNKJQU/nelNljX2jAc
IAvhg0mguk+BJejgtWMKo7rq9Vrt4yozdyqElhbgZKM2bqgqIA9C/g4Tg158m7Xi
G1r1DwFRmh2KGBaSSXtbLF9Vncg1gJFPFZJPyCqJUrDwkETwple+r5z77QXNPmnl
jTJMp2j+d4QTMxQcrTAKn2Whkz7Sz1ljiaJKZ2tQcILNUHbs4np6eqUhbtnZogCJ
RlbOZJRtAQ5N85Qc6y7l/4A/reNj6YMnuVQpnqdbEnh+6+ZBjwL/QjMqEjY0et3A
Hn3kNCnJIWF5prBZdugxKjSv1OM2K1+uUlujAzn0uhUV+q9h1VYXAdREs23WP80O
7w3Foa3YQ17z7dx7sMTezTR4YGdq5Zc4kAkZ9Lq/MNSTKleoLy7VO50A4w6l2H5K
tkRc0YgHDnRiWio=
-----END CERTIFICATE-----

maria_certs/server-cert.pem
-----BEGIN CERTIFICATE-----
MIIFgzCCA2ugAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwdjELMAkGA1UEBhMCVVMx
FjAUBgNVBAgMDU1hc3NhY2h1c2V0dHMxDzANBgNVBAcMBk5ld3RvbjERMA8GA1UE
CgwIQ3liZXJBcmsxDzANBgNVBAsMBkNvbmp1cjEaMBgGA1UEAwwRSW50ZXJtZWRp
YXRlIENBIDEwHhcNMTkxMTE5MTc1MTA4WhcNMjAxMTE4MTc1MTA4WjBuMQswCQYD
VQQGEwJVUzEWMBQGA1UECAwNTWFzc2FjaHVzZXR0czEPMA0GA1UEBwwGTmV3dG9u
MREwDwYDVQQKDAhDeWJlckFyazEPMA0GA1UECwwGQ29uanVyMRIwEAYDVQQDDAls
b2NhbGhvc3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDWH/fNYmFY
Ri9ZL0EKYZieyKzCBOOsprBz9FhIh7Xa46ioeyRYfMYs9btXvpSes1Qxne7/6Re1
hJfylpDdkJAjZYAF/8rdktwmyr/wCTTVHDI6fbGMNcon/FjTuhcWxZNToq0nA57C
+gc63X8COdJCtiIRM/U+aYi+1TFJzwbaGsbGr8HS6hQawuwgm8uFxD2yMt8S+bmS
zD+FntRd9hbyCuej9Qu17Q1OrRZ0fhyV1Ki1JTXtK5l86Kgz30Hb8fr8Ir4o4uEV
ZCsh5u3nc//OsBzX2CoJc+iuDkAdsOBxbQgkORwF7vBjspTg6BNA83Mo/gRSSpzO
6O8/e5q/oOcofxWG1wyuuzYup57zUjezyP+tqHDlNAKResC0w6CX2EEt6VoKTDhh
AvjVbt+tYYi3gFlAHMh3YNr/ZT1wdZDO72rzPP0/hEutZESQBdqer55XlBNUs72P
Gl/EMpvUilc52PQEQ3EyleBDWPVQghB/NTb02HICd3ieywL/zfJMpuPHmX41EdR+
BggOjKXwIWjFRHZKqbeWD9WjJRBPrOSaMLJl9IZFJmklY3UZ1N2WfynMpWyrE5Ii
yPkn3EzieZvaNoBpDtSn4s67GBsjybUci+QJQ5p/C7AX2bZ+L89vcCI3ApzuebsE
OKU6xtsh7cWOeapHrOeIrqZlLqm9hwApzQIDAQABoyMwITAfBgNVHREEGDAWggls
b2NhbGhvc3SCCWxvY2FsaG9zdDANBgkqhkiG9w0BAQsFAAOCAgEAKmFLrlvI9EQe
6NapAFu6IkK3HdmplQNK+GDvnASDu2tW128xA7gywtSy9ucNY3pKHYCYHxySAIq2
DpiwXGuEphomLwnK0i2o6AfB/tXijQkUwLagg/65X526GvHhxd+6wzPcg1QM/MpF
Ei6skfImiZMlAoO/0HQM+yOhCH7se20tv3u2lpVhzCbEfnDWjJacaQIHp99A7Q4O
Q9Pg7oiH7IqD+DlkXMEdg+2dCmcYgl++l36LgeIPo1eOq0VugFha04SPSEg3Vw7f
6OeiRycRIsR4MJXHPxnjhv7h5O3qjtbD4+Tre/a1+llwVdHwpO4uFULunr9UOmnI
mY5fphS5KrYmTy2hNhWT/bztYOFLJK1QSKtna5UZr2twcdzqiUex5qCMP6xnyyvK
4tXWbLOAdvLDxl8syXaNGzPtQnDnmtMtdczexj+3QtylTAsuW40YM7AKav09gzrD
4PoZTpBYBxGeLCL3m1WkE9FijytWgohSohvZvb0v4/wHe6gcpofe/8D0CZHvGakz
1PjNAbkHy5ZMZB7pBGRGVkouEUheIv7KRrH1yQpwcxhfvkDn9GZcU4wyyzF0KDiz
zgppSHJLOrPJengSaptQ81IPHXqzCnhKe9V051wXKQWcgrP2XtoJ0RCiIUNSXdi4
OotdDiGgxhO9N1XwWJx68MoJE9tifRM=
-----END CERTIFICATE-----

maria_certs/server-key.pem
-----BEGIN RSA PRIVATE KEY-----
MIIJKgIBAAKCAgEA1h/3zWJhWEYvWS9BCmGYnsiswgTjrKawc/RYSIe12uOoqHsk
WHzGLPW7V76UnrNUMZ3u/+kXtYSX8paQ3ZCQI2WABf/K3ZLcJsq/8Ak01RwyOn2x
jDXKJ/xY07oXFsWTU6KtJwOewvoHOt1/AjnSQrYiETP1PmmIvtUxSc8G2hrGxq/B
0uoUGsLsIJvLhcQ9sjLfEvm5ksw/hZ7UXfYW8grno/ULte0NTq0WdH4cldSotSU1
7SuZfOioM99B2/H6/CK+KOLhFWQrIebt53P/zrAc19gqCXPorg5AHbDgcW0IJDkc
Be7wY7KU4OgTQPNzKP4EUkqczujvP3uav6DnKH8VhtcMrrs2Lqee81I3s8j/rahw
5TQCkXrAtMOgl9hBLelaCkw4YQL41W7frWGIt4BZQBzId2Da/2U9cHWQzu9q8zz9
P4RLrWREkAXanq+eV5QTVLO9jxpfxDKb1IpXOdj0BENxMpXgQ1j1UIIQfzU29Nhy
And4nssC/83yTKbjx5l+NRHUfgYIDoyl8CFoxUR2Sqm3lg/VoyUQT6zkmjCyZfSG
RSZpJWN1GdTdln8pzKVsqxOSIsj5J9xM4nmb2jaAaQ7Up+LOuxgbI8m1HIvkCUOa
fwuwF9m2fi/Pb3AiNwKc7nm7BDilOsbbIe3FjnmqR6zniK6mZS6pvYcAKc0CAwEA
AQKCAgEAotAb9CdiLWTwi7fKlMIw8ktUURK2q4jzkrewiTXnqVCB5dn8gOwfJACV
OtrG1wU0d6XHHP9376Wqg+LItDA/6So8dlNRRbltfHGeED5v1bti1ebNIfekh1Lx
l8xf0gjZRTbkwk2WYlsLNE9HS8H7ho5GyR3g1FwahkBFAgJRC3ZgvqLVljI2p0Kf
mQvdbRESeHUF+b+4w05a3pcuk2OTfuebyqeBCAv/mlsyP9HEmojg3xw0LOqCAuBF
RWv0//C3DxC71wrsav+HbHfTXbJuSBLRW64aCKYBvpdHWUws3RIypphmHnzYfHZF
jd3pBfIXFoxPbOMe6JVllbe+qwcFu/itgE+AkZ81fZDz418P8bt4cjCefmvgH6Ym
MZw153HDZUOKDmHvvJrAFGLaJEmVaMzjZvUDdZgpJ2A85y3ILM349ratf2pnZZLg
hPe/lRE10iDD5trRyH0XmxzhXgLu45KMWpD5wCmjHd7sUh1DPoOwRFzw4kGwtewO
voAtiCGaNfCUA0j9k6T3SeTgDcvfJEHqCpVzgT+SFcKXdLSq1OaquCSDkBV2o6Ls
kgA2iITCYRdMftkvN4GLYIui2BR0JQWhFOfhsUAquZByaJAef+eZwufZkKP2ykc4
b1qFskLk3LQbLs2mfbPSrt88CvjWwpXCmHx7NWXLdvlzRRHv2QECggEBAPXDpoGc
IXKzVUU/6cEnte/68d/Jq62N7wWDyiRWhAYFsllekF/idAkUPbM3eP45jibeHjj4
eypR0Cw3pmL3QmtKphxZfSf6PEOdmtDMZvO86NEMQ7z0Di0QjnELKcjv7DSz9XVJ
KJ574FCk6cI6zgyHNfj6Y8fr2P1GkpNw8x3bnPjkuljFkmiBl+IcGqlmpxk5KqL3
4f08Uo6cS/0jqSinYo1JKQHldT+mRwMuSZsN5jfqy/UVwvGu6MC7qAKSTkFrod+B
zHSJu6xIz29/3KeMJ/BqZcsm5TnGGSPm8hLvyHr3wzOWcMnvQvW+BvW4+Ec7xq2o
OwSrbdICvu7a1qkCggEBAN8K+h4d+uSbMh9/RvO40YbFIC5Tjc4jXZYgpGoR4Kfj
AOPd9TzwTDAJQbMdv+WU2gS3EyIv2oj8LeaEStG1kIMcNV/ou0rRAq9vzhSbE8Td
wf4jA9G2n2LugU/88hRlgK2UcnDXcJImk+3A4aplJWPKtKdh7Jgw4RwBAZkiKjxf
NvFD2isE09j6p1iULUZ1r1zvYrCofVr0m3xJumMwuGP7PNzCnS9z+6EIYGskbRhU
a8hOLf+MhbrAzcOkHUn42nIR+GpZBBu5YO4/HGem4rt7tHAECfnurY8yu/6wkly1
VMwoAqowhKqWuDpu4RPnnzchnk4Dae8vYgb+DEDUBIUCggEBAMRnJOuzcG+PrXd4
CkDYkWdFLoLfUhmSsg/AMI01rrB5YPxWvB5EhOK0kFJm5ISWTmn1XEW/Hf7F/w03
M/snCqdfsrw5L/IA4qROkWiH0Ua8E3rsyD169NFCx/LDLxNr2WKM5n5ihtmQucT4
5e7Yu837SEC/KXqdmn1eJsk5nLChzyKA+AL1cXmfB1gliZETfjqEGvS+EJYl3Pwn
H/sewpLAoduzOdhQHZFOOrXqCdymEPNi6rfkOjSWyV8tGKllbrCNaYGK42/Gmnqm
fU/n6NjlAw34mXzuioXPMEwmxhIoGhlbY14Yve5DDUoCIOHCfne+55nkNbYXod4R
X7DWpnECggEAKY+uE7aabcbNjDj3S6sAwBAzcu522haU9ciXWnyCVEZkgBF4BSbx
y3GuIGZGv80A4ygKFLC+FBCJrQ6xsmoWx5eWCo0feU2BJpe62vQatvBrmaOErqtM
/+5ZgkIsCcjwNWgX+xbqDxHJNuBeLJY0ZWf8ScRhhep1x/YYCiTnoeBMKKDwIlv/
7cqnLEZQOXTsfHDO/wQmd7Bk2MAUTy9g7KCAMtLA33rJRLR+4vgirAnvG6AVyiyx
Lp+GuBH4szP/4ImgtJBpx5C/kyWHcXkTfsQKV2UpRr1G8gwOI+NbIpNXfcNm27e2
wOLc6WaH4mGitW86RGc2ci9uIMduGRZo0QKCAQEAu25B04OOosn7rlVD6XUogLYY
PxRS8Iz3WRLUUzBx74xYcPdk+E79BY1ubjVBBKwRyAELVsVbNGEcuSW7QDg6n0ku
sc1egQ5mcXhHVvE1ZuNEDaNJOe0XbR+7o6fX0TKyOVM798O/f9mR0S3Qz8FuvHbu
bOt2Z2NrT64AccflGHrDKhVYJP4l0bqjykVpEaen7vUeMjDyGfmzJ6mOd0hDI1wk
Hoslx/cc55wDVpAap5xDVAmaETBnO+s7OW3FS6rZHk94gVlMaXqAWrcrjmNljqxQ
taz2Wy6vm/zAguvS79/3uR4ZBUU7SszzgPHlHdArLxDvogQwvAsFyILUr6olTw==
-----END RSA PRIVATE KEY-----

Closing as the fix will get released in v.1.3.0

@porjo Can you try your configuration with the latest version of secretless now that we have released it? It should fix this issue.
v1.3.0 can be found as a container here or in binary form here.

Why is mysql8.x not supported? Is it because of caching_sha2_password? I modified some code of mysql plugin so that secretless can pass cahcing_sha2_password authentication and connect to mysql8, but I don't know if there is any application problem

@cmlcmlcml-eng I believe the issues you're facing are likely to do with missing authentication strategies. I'm happy to walk you through resolving the issue. I'll need a bit more context around your setup. Do you have a branch/repo with the modified code and your setup ?


Market PoS Blocks as STORED If Block Timestamp Drift Check Fails

Current dependencies on/for this PR:

feature/proof-of-stake

PR #1040   👈

This stack of pull requests is managed by Graphite.


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target_1be60ed2-861b-4195-b84c-573874777cb9/pull/1 is merged into live branch.
Auto archive content to https://github.com/VSC-Service-Account/docs-archive-test-target_1be60ed2-861b-4195-b84c-573874777cb9.git

Docs Build status updates of commit 9209781:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-UserAccountBuildPermissionInsufficientError] Owner v-alji no longer has Read permission of the repository https://github.com/VSC-Service-Account/docs-archive-test-source. It might be due to recent GitHub changes on SSO. Please ask the owner v-alji to logon to Docs Portal https://ops.microsoft.com once again. If it is not the case, please ask anyone of Admin permission of the repo to assign a new owner via Docs Portal https://ops.microsoft.com

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 9209781:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-UserAccountBuildPermissionInsufficientError] Owner v-alji no longer has Read permission of the repository https://github.com/VSC-Service-Account/docs-archive-test-source. It might be due to recent GitHub changes on SSO. Please ask the owner v-alji to logon to Docs Portal https://ops.microsoft.com once again. If it is not the case, please ask anyone of Admin permission of the repo to assign a new owner via Docs Portal https://ops.microsoft.com

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Issue 1433 4

Codecov Report

Merging #24 into issue-1433-3 will decrease coverage by 0.91%.
The diff coverage is 50%.

@@                Coverage Diff                 @@
##             issue-1433-3      #24      +/-   ##
==================================================
- Coverage           45.19%   44.27%   -0.92%
- Complexity            748      762      +14
==================================================
  Files                1542     1550       +8
  Lines               53215    53207       -8
  Branches            21245    21245
==================================================
- Hits                24050    23558     -492
- Misses              29165    29649     +484

Flag
Coverage Δ
Complexity Δ

#full
39.79% <50%> (ø)
0 <0> (ø)
:arrow_down:

#lite
1.76% <0%> (ø)
0 <0> (ø)
:arrow_down:

#standard
23.39% <50%> (+0.09%)
0 <0> (ø)
:arrow_down:

Impacted Files
Coverage Δ
Complexity Δ

...rowsers/2345-browser/2345-explorer-3-2-to-5-0.json
55.55% <ø> (ø)
0 <0> (ø)
:arrow_down:

...es/user-agents/apps/yandex/ya-app-ios-generic.json
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...wsers/access-netfront/access-netfront-2-0-3-5.json
40% <ø> (ø)
0 <0> (ø)
:arrow_down:

resources/user-agents/apps/alibaba/ali-app.json
55.26% <ø> (ø)
0 <0> (ø)
:arrow_down:

...es/user-agents/apps/uc-browser-hd/uc-web-hd-2.json
14.28% <ø> (ø)
0 <0> (ø)
:arrow_down:

...ources/user-agents/apps/cfnetwork/vanillasurf.json
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...ents/apps/sohu-news-app/sohu-news-app-android.json
100% <ø> (ø)
0 <0> (ø)
:arrow_down:

...er-agents/apps/microsoft/windows-update-agent.json
50% <ø> (ø)
0 <0> (ø)
:arrow_down:

...r-agents/apps/facebook/facebook-messenger-app.json
95.33% <ø> (ø)
0 <0> (ø)
:arrow_down:

resources/user-agents/apps/rebelmouse.json
100% <ø> (ø)
0 <0> (ø)
:arrow_down:

... and 1454 more

Continue to review full report at Codecov.

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


fix: moved color to last prop

Motivation
For tabbar labels I want to add styles and either active or inactive color.  The assumption is that the color prop would override the style prop.

Not sure if it was really the "recommended" way to use it, but this will break for people using <TabBar labelStyle={{ color: 'black' }} />.
You now have to set both activeColor and inactiveColor, which I don't mind at all, just letting know people.


CHAOS-6907 Add note about permission required

Add note about permission required for Byteman agent to execute JVM faults

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://67120b90657e766be96906b4--harness-developer.netlify.app


unable to run private relayer without a block-engine

Is there a way to run local relayer without specifying a block-engine?
If I don't specify the relay exit with a panic (when getting a packet)
thread 'forwarder_thread_0' panicked at transaction-relayer/src/forwarder.rs:92:45:
error sending packet batch to block engine handler

Att: @buffalu

It's meant to be optional.  I will look into the implementation.
In the meantime, setting the following flag should work:
    /// Disable Mempool forwarding
    #[arg(long, env, default_value_t = false)]
    disable_mempool: bool,

yep, I confirm the workaround - thank you


Could not parse coloured lef

Hi trimcao,
Am able to parse normal lef with this module without any issues,  but it is not able to parse coloured lef,
While parcing coloured lef , I am getting the following error.
It is an enhancement changes in lef.
ERROR:
Start parsing LEF file...
Traceback (most recent call last):
File "lef_parser.py", line 125, in
lef_parser.parse()
File "lef_parser.py", line 52, in parse
nextState = curState.parse_next(info)
File "/proj/ipqa_dev/sw/play/tmp_rel/lef-parser-master/lef_util.py", line 197, in parse_next
self.info["LAYER"][-1].add_rect(data)
File "/proj/ipqa_dev/sw/play/tmp_rel/lef-parser-master/lef_util.py", line 271, in add_rect
x0 = float(data[1])
ValueError: could not convert string to float: MASK
Whats new in coloured lef ..?

MASK is a new attribute in RECT class

Example:
PORT
LAYER M1 ;
RECT MASK 1 0.038 0.035 0.074 0.205 ;
END
How to fix this issue ..?
File : lef_utils.py
The following block has to be update to resolve this issue.
def add_rect(self, data):
    x0 = float(data[1])
    y0 = float(data[2])
    x1 = float(data[3])
    y1 = float(data[4])
    points = [(x0, y0), (x1, y1)]
    rect = Rect(points)
    self.shapes.append(rect)``

Regards,
Devarajulu.

Hi Devarajulu,
I have abandoned this project long time ago. This is only a short-term project for me to understand the LEF and DEF file. Of course stuffs like colored LEF cannot work. You are welcome to use this code and improve upon it.
Cheers.


every line of code is just an error in Tensor flow  2.0

how to edit
and which version is suitable for this code

I'm using Python 3.6 and tensorflow-gpu 1.15.0 for this model.

Did you hae any error related to "tensorflow._api.v2.train' has no attribute 'slice_input_producer'"? If you encounter this, may you tell me is there any solution for this? Thanks!


fix hardcoded AUTH_USER_MODEL in migrations

Hi there 👋
Great project! I wanted to contribute to fixing a "bug" I realized in the migrations. When you set USER_MODEL  as such in your settings.py:
PUSH_NOTIFICATIONS_SETTINGS = {
    "USER_MODEL": "user_management.User",
   ...
}

the migrations still create a foreign key reference to the value of AUTH_USER_MODEL.
This PR would update that to use the value of settings.PUSH_NOTIFICATION_SETTINGS["USER_MODEL"]

It seems like this may be a duplicate of #572 .. but any way one of these can be merged in and released? 😄

closing in favour of #572


HOTT-3119 Use leaf where available for Single Table Inheritance

Jira link
HOTT-3119
What?
I have added/removed/altered:

[x] Reintroduce the Single Table Inheritance change
[x] Fixed a bug discovered where a check for Commodity was introduced in a separate branch concurrently with this change

Why?
I am doing this because:

The functionality is desirable but was reverted in a hotfix after discover of the bug

Deployment risks (optional)

Medium - its been deployed once already, and we know it doesn't trigger any outright problems. The origin of how the bug crept in has been established - multiple concurrent branches, and a new check for instances of is_a?(Commodity) has been done. Specs have also been introduced checking the ancestors behaviour from the problematic presenter.

Sorry didn't think to take one but it was the commodity tree was missing the subheadings - only occurred on the commodities page
Most of 'todays' pages had cached data so suspect it only really showed up for users looking at different dates


✨ [CW-19091] feat: coin-ton signTransaction support sendMode

Checklist:

README.md includes:

[ ] The details of signing data and transaction data, this includes parameters.
[ ] Official docs or white paper.
[ ] Website or api can query assets and broadcast transaction.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Task linked: CW-19091 Pro - SDK implementation


Asynchronously loaded column definitions not displayed, if data grid is empty

Describe the bug
In our project we have an Angular component which renderes a data grid based on asynchronously loaded meta information (e.g. columns for the data grid). This works fine, if there are rows to display.
If the data grid is empty and the column definitions have been loaded from the service, the additional columns will not be displayed.
How to reproduce
This Stackblitz reproduces the error using a JavaScript timeout.
As shown in the example above the empty table does not display the additionally loaded columns. Columns which are not loaded asynchronously will be shown (see "Fixed Column" in example).
Expected behavior
The columns should also be visible in the empty table. The behavior should be consistent and not depend on the loaded rows.
Versions
App

Angular: 7.2.5
Node: I don't know on which node version the StackBlitz runs, but in our project we use 10.15.3
Clarity: 1.1.2

Device:

Type: Desktop PC
OS: Windows 10
Browser: Tested on Chrome, Firefox, Edge
Version: Chrome (73.0.3683.103), Firefox(57.0), Edge (41.16299.1004.0)

Additional notes
The columns will be displayed, if *clrDgItems is used instead of *ngFor for column iteration. But I don't think this is the intended way, as it is reserved for row iteration (I think). Furthermore the "data grid empty image" will not be displayed, which may be a separate issue, if both ways should offer consistent behavior in that regard.

This issue is about a version of Clarity that is out of support. In an effort to better manage our backlog, we are closing this issue. We recognize that some of these issues may remain problematic for you, but to help us to be able to prioritize it we ask for a new GitHub issue with an updated demo with a recent supported version of Clarity.

This issue is about a version of Clarity that is out of support. In an effort to better manage our backlog, we are closing this issue. We recognize that some of these issues may remain problematic for you, but to help us to be able to prioritize it we ask for a new GitHub issue with an updated demo with a recent supported version of Clarity.


BootstrapAll & TeardownAll hooks inside plugins for run-multiple

What are you trying to achieve?
We want to start the server and stop the server via codeceptjs custom plugin but there is not event hook currently available for bootstrapAll and teardownAll methods.
What do you get instead?
No event hook currently exposed resulting in multiple spawning of servers for each child process.
Details

CodeceptJS version: 3.3.7
NodeJS Version: v14.17.2
Operating System: OS X
puppeteer || webdriverio || testcafe version (if related) webdriverio
Configuration file:

Related PR - https://github.com/codeceptjs/CodeceptJS/pull/3487

There are https://codecept.io/bootstrap/#bootstrapall-teardownall


adding restart-required flag to default-authentication-context attribute

https://issues.jboss.org/browse/JBEAP-9307
https://issues.jboss.org/browse/WFCORE-2475

Core - Full Integration Build 4730 outcome was FAILURE using a merge of ce9d886725f69251e4bb1f715e64b7b48ab946ec
Summary: Tests passed: 3740, ignored: 159; exit code 1 (new) Build time: 00:55:47


Changing 'checked' property does not affect MenuItem icon

MenuItem which type is radio button or check box always has unchecked icon.

fixed in 8a7fec4


2.54.1

and a rerender

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

The recipe license should not include the word "License".

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

This cannot work until the new compilers


Installed Python - but after zopen-config can't find it ???

I just installed the zopen python and after running zopen-config my system still reports that python is /usr/lpp/IBM/cyp/v3r12/pyz/bin/python -- it appears the python .appenv is not being run ???

We should change the name of that to comp_python to follow comp_clang and comp_go. It's used by the build process to determine if you have the right version of python, but it doesnt actually install python for you. We probably should also omit it from zopen install

please do rename as it is confusing - at least to me


Indicate where "Buffer" is undefined inside of node_modules

💡 Feature request

Describe the feature
A clear and concise description of the feature. What problem does it solve for you?
Cloudflare workers will throw errors about buffer being undefined. That makes sense since the workers env doesn't support buffer, but I'd like to know in which node_module my app is requiring buffer is being used. This would make it significantly easier to debug.
Describe the alternatives
Are there any alternatives to solving this problem? If so, what was your experience with them?
Manually searching through node_modules. Takes forever.
Also throw error if config file is missing.

Thanks for suggesting this feature! Wrangler v1 is now deprecated and support is only being provided for critical updates or security concerns. As such, we are closing this issue.
New versions of Wrangler are maintained in the workers-sdk repo. If this is a feature you’d like to see in wrangler v2+, please feel free to report it in the workers-sdk repo. For more info about wrangler v1 deprecation, please check out our blog post.
Nodejs compat is improving, and we'll soon have an implementation of Buffer you can use from within workers!


view

so i got the model and i am using on a origins server where my player size is set to 0.40 (1 = normal size) and whenever i scale the model smaller with eye view locked on it the view point always goes way to far either up or down. could this please be fixed? its really ruining my experience.

Do you mean that when the position of the first person camera position is changed, the position of the cross hairs on the screen and the selected block are misaligned?

This is a Figura specification. Any avatar creater, including myself, cannot change this.

Please keep in mind that this change does not affect where the crosshair really is, so if you move the camera, and try to break a block, the block will still break in the same place it would usually do
From Figura wiki

The latest version of this avatar does not support resizing. However, the version for a request previously created supports resizing. It is not compatible with the latest version.
https://github.com/Gakuto1112/CatMaid/tree/Request-Felicia

i can send you a few screenshots of what i mean in a few hours, cause i get that the crosshair is misaligned cause of it not being able to change hitbox

カメラの位置を移動させても、クロスヘアの位置が変化しないのはFiguraの仕様です。

Please keep in mind that this change does not affect where the crosshair really is, so if you move the camera, and try to break a block, the block will still break in the same place it would usually do
From Figura wiki

カメラの位置を移動させても、クロスヘアの位置が変化しないのはFiguraの仕様です。

Please keep in mind that this change does not affect where the crosshair really is, so if you move the camera, and try to break a block, the block will still break in the same place it would usually do
From Figura wiki


fix for #925

new line is now being added to the end of the toml file

Hey @Dreamersoul, it looks like you've included some unrelated tests in this PR. While we'd love to have those, can you please move them to a separate PR?
Also getting a test for the newline case so this doesn't break again would be great. Thanks!

Concur with @nateprewitt.  If you can split the tests into another PR that'd be great!

done 👍  currently writing a test for the new line case

This looks good to me, thanks @Dreamersoul! We'll merge once the tests finish.

awesome! thank you for keeping up with me 😄  you guys are awesome collaborators @nateprewitt @erinxocon

Sorry @Dreamersoul, looks like there's a conflict now due to another merge. Would you mind rebasing onto the current master branch?

thanks for merging 👍

Thanks @Dreamersoul!


Bug: Duplicate usernames are possible

This is a simple fix, the server needs to make sure there is not an .ilike username in the database already, if so then reject it with a duplicate username message.

Nope, not anymore.


more buttons

Turbo A
Turbo B
Turbo R
Turbo L
Brighten Solar Sensor
Darken Solar Sensor

I added keybinds for these as part of: https://github.com/skylersaleh/SkyEmu/commit/8609065fd6adcaa8145672c116e790a29dd5da7e
Which is now in the v3 branch


How to handle new DOM elements?

Say I have a bunch of "li" list item, then I set things up using New Droppables. Everything works.
Now what happens if I add another "li" list item to the container? How do I make sure that will drag too?
What's the best way of doing this

Do I re-setup New Droppables?
Do I need to droppables.destroy() first?
Or do I use .addContainer?

Appreciate your help!

Hi,
You just need to use addContainer method to add it to the current draggable instance 😄

And if you want to add some items to an existing container, you need wrap them in the dropzone separately.

Wow thanks for the quick responses. So if I have:

// I need to do

// And then call .add Container?

Did I get that right?

It seems you don't need addContainer if you just want to add some items, there is a simple demo https://codepen.io/1010543618/pen/BaKjJPZ  . You can edit it and send a link here so that we can communicate more easily.

Thank you that was very helpful! I've made edits to your codepen to do what I was trying to do (in case anyone else has this question).
https://codepen.io/pumpknhd/pen/rNexJwN


Feature/add covers to tests

@Maks3w
Added covers annotation to unit tests.  Unit test coverage is coming up lower.

Reverted.

Thanks, @levelfivehub


Error when entering activity - date cant be before start of challenge

Describe the bug
The start date of the challenge was April 1st.  When the user tries to enter an activity on April 1st they go an error that it was too early.  I am sure it is just due to the time component of the date so it should be an easy fix.  I tried to convert dates to beginning and end of day for comparison to start and finish but I must have done something wrong.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Screenshots
Additional context

Easy fix using moment - startofDay()


Link is wrong for GPO

Link is wrong for GPO Shortcut. Currently pointing to:
https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/create-a-group-policy-object
Is this supposed to be a link covering specific details on the FSLOgix ADMX?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 734788a0-bfe6-1916-7300-1fea39127604
Version Independent ID: 254293a7-3f94-d1b8-50f4-4eda0f20552d
Content: Configure Profile Container Tutorial - FSLogix
Content Source: fslogix-docs/configure-profile-container-tutorial.md
Product: fslogix
GitHub Login: @DougCoombs
Microsoft Alias: docoombs

incorrect link removed.


Basic Types not registried correctly if it only nested in other Object type

Hi, guys, I currently fond an issue with the type registry in the stitching lib.
The bug is if some basic type(Float i tested)  are not used in the root of Query type, but used only in some nested my own Object Type, then during the stitching there would have a problem of Error: No such type: Float. You can test it out or I will add some code to reproduction this bug later.
Maybe I can make some PR as well if I got time.
Looking for this bug fixed.

A small runnable reproduction here would be greatly appreciated. Thanks!

@hwillson I have created such a reproduction and linked it in https://github.com/apollographql/graphql-tools/issues/847, where it seems like some investigative work has already been done.  Should we consolidate there?

mergeSchemas does not merge typedefs (!), it stitches them together by proxying. Merging can be done within makeExecutableSchema by just using an array of strings for typeDefs.
See #443 (comment)
Not sure if this addresses your issue. Please reopen with minimal reproducing repository if still relevant.


Go-langserver

Hi
Could you implement the golang server at https://github.com/sourcegraph/go-langserver/ ?
I for some reason cannot make it run. I copied the Omnisharp extension replaced the references to cs/omnisharp-server to go/go-langserver but it does not work. I open a go file it states Successfully activated but literally nothing happens. No autocomplete, no defs on hover, no linting, nothing.

Thanks for the issue! Broadening the language server support is on the roadmap for the 0.3 release, so this fits into that. I haven't used go yet but would be fun to try it out.
Sounds like you've already tried to give a shot - feel free to create a PR and I can help you troubleshoot a bit as well.

https://github.com/fasa123/oni
https://i.imgur.com/vwzIcJX.png

Started making some of the fixes for this in PR #445 . #379 tracks syntax highlighting, and #446 tracks specifying go-langserver path via config.


DataTable function cannot be called

Thanks a lot for the wonderful template. I have a quick question. My dataTable function cannot b called when add the following script in the html file.
$(document).ready(function() {
    $('#example').DataTable();
} );

Anyone has suggestions? Thanks a lot!

I have change the name "example" to the ID name of my table.

This looks like it's solved, right? If it is can you please close the ticket? thanks

Oh, sorry for the confuse, it's not solved. I changed it, but it's still not working....

Hi, does it throws any console error or can you show me the structure of the table and the script you're using:
just as a reminder for the plugin to work must have the structure of

...

...

We're gonna close this for now @jywu90  but feel free to reopen it or create another one whenever you want.


Flight Software Datalog Trigger

Need to create a trigger to begin the data log.

Added a trigger, datalog now starts after the pilot initially switches into auto mode. The upper left light illuminates when data is logging.


LXD appears to have a broken /etc/resolv.conf

Required information

Distribution: openSUSE
Distribution version: Tumbleweed
The output of "lxc info" or if that fails:

Kernel version: 5.1.10-1-default
LXC version: lxc-3.1.0-4.2.x86_64
LXD version: 3.14
Storage backend in use: btrfs

Issue description
LXD incorrectly queries localhost for dns names.
location: none
metadata:
  context: {}
  level: dbug
  message: 'Failure for task operation: fbb64d76-ba10-4382-b4f3-3bbb9cf939a6: Get
    https://images.linuxcontainers.org:8443/1.0: lookup images.linuxcontainers.org
    on [::1]:53: read udp [::1]:40439->[::1]:53: read: connection refused'
timestamp: "2019-07-01T12:57:21.843719456-04:00"
type: logging

Steps to reproduce

lxc image copy images:centos/6/amd64 local:

Actual result
Error: Failed remote image download: Get https://images.linuxcontainers.org/streams/v1/index.json: lookup images.linuxcontainers.org on [::1]:53: read udp [::1]:44916->[::1]:53: read: connection refused

Expected result
Download image
Notes:
I distro-hopped to openSUSE and did in-place move of LXD files. I'm not sure if that broken anything but further investigation. LXD snap has a broken resolv.conf
lrwxrwxrwx 1 root root  35 Jun 30 23:24 alternatives -> /snap/core/current/etc/alternatives
lrwxrwxrwx 1 root root  31 Jun 30 23:24 apparmor -> /snap/core/current/etc/apparmor
lrwxrwxrwx 1 root root  33 Jun 30 23:24 apparmor.d -> /snap/core/current/etc/apparmor.d
lrwxrwxrwx 1 root root  30 Jun 30 23:24 ceph -> /var/lib/snapd/hostfs/etc/ceph
lrwxrwxrwx 1 root root  31 Jun 30 23:24 group -> /var/lib/snapd/hostfs/etc/group
lrwxrwxrwx 1 root root  34 Jun 30 23:24 hostname -> /var/lib/snapd/hostfs/etc/hostname
lrwxrwxrwx 1 root root  31 Jun 30 23:24 hosts -> /var/lib/snapd/hostfs/etc/hosts
-rw-r--r-- 1 root root 14K Jun 30 23:24 ld.so.cache
lrwxrwxrwx 1 root root  35 Jun 30 23:24 localtime -> /var/lib/snapd/hostfs/etc/localtime
-rw-r--r-- 1 root root  87 Jun 30 23:24 logrotate.status
drwxr-xr-x 2 root root  60 Jun 30 23:24 lvm
lrwxrwxrwx 1 root root  12 Jun 30 23:24 mtab -> /proc/mounts
lrwxrwxrwx 1 root root  39 Jun 30 23:24 nsswitch.conf -> /var/lib/snapd/hostfs/etc/nsswitch.conf
lrwxrwxrwx 1 root root  36 Jun 30 23:24 os-release -> /var/lib/snapd/hostfs/etc/os-release
lrwxrwxrwx 1 root root  32 Jun 30 23:24 passwd -> /var/lib/snapd/hostfs/etc/passwd
-rw-r--r-- 1 root root   0 Jun 30 23:24 resolv.conf
lrwxrwxrwx 1 root root  26 Jun 30 23:24 ssl -> /snap/core/current/etc/ssl
lrwxrwxrwx 1 root root  26 Jun 30 23:24 vim -> /snap/core/current/etc/vim

# cat /proc/2141/root/etc/resolv.conf
#

I was able to narrow the problem down:
ls -l /var/lib/snapd/hostfs/etc/resolv.conf
lrwxrwxrwx 1 root root 30 Jun 27 06:28 /var/lib/snapd/hostfs/etc/resolv.conf -> /var/run/netconfig/resolv.conf

/var/run/netconfig/resolv.conf is non-existent insider the container.

Ah, I'll need to look at what we do for netconfig. resolv.conf handling is always a bit funny

The change I made will remain after restart?

Nope, /etc is a tmpfs in the snap environment, a restart will reset it.

This will likely take a day or so before we release it into the stable channel, hopefully that will fix your issue.

Will that bump the version, how will I know I receive that change?

It should be in the stable channel by now, you can check if your local copy has it with:
grep netconfig /snap/lxd/current/commands/daemon.start

Huh, it's there but it doesn't appear to be working as expected, earlier I had to manually add the DNS entry into /etc/resolv.conf again.

On a broken system, can you show:

ls -lh /proc/$(pgrep daemon.start)/root/etc
ls -lh /proc/$(pgrep daemon.start)/root/run/netconfig

lrwxrwxrwx 1 root root  35 Jul  8 08:58 alternatives -> /snap/core/current/etc/alternatives
lrwxrwxrwx 1 root root  31 Jul  8 08:58 apparmor -> /snap/core/current/etc/apparmor
lrwxrwxrwx 1 root root  33 Jul  8 08:58 apparmor.d -> /snap/core/current/etc/apparmor.d
lrwxrwxrwx 1 root root  30 Jul  8 08:58 ceph -> /var/lib/snapd/hostfs/etc/ceph
lrwxrwxrwx 1 root root  31 Jul  8 08:58 group -> /var/lib/snapd/hostfs/etc/group
lrwxrwxrwx 1 root root  34 Jul  8 08:58 hostname -> /var/lib/snapd/hostfs/etc/hostname
lrwxrwxrwx 1 root root  31 Jul  8 08:58 hosts -> /var/lib/snapd/hostfs/etc/hosts
-rw-r--r-- 1 root root 14K Jul  8 08:58 ld.so.cache
lrwxrwxrwx 1 root root  35 Jul  8 08:58 localtime -> /var/lib/snapd/hostfs/etc/localtime
-rw-r--r-- 1 root root  86 Jul  8 08:58 logrotate.status
drwxr-xr-x 2 root root  60 Jul  8 08:58 lvm
lrwxrwxrwx 1 root root  12 Jul  8 08:58 mtab -> /proc/mounts
lrwxrwxrwx 1 root root  39 Jul  8 08:58 nsswitch.conf -> /var/lib/snapd/hostfs/etc/nsswitch.conf
lrwxrwxrwx 1 root root  36 Jul  8 08:58 os-release -> /var/lib/snapd/hostfs/etc/os-release
lrwxrwxrwx 1 root root  32 Jul  8 08:58 passwd -> /var/lib/snapd/hostfs/etc/passwd
-rw-r--r-- 1 root root  20 Jul  8 15:50 resolv.conf
lrwxrwxrwx 1 root root  26 Jul  8 08:58 ssl -> /snap/core/current/etc/ssl
lrwxrwxrwx 1 root root  26 Jul  8 08:58 vim -> /snap/core/current/etc/vim

s -lh /proc/$(pgrep daemon.start)/root/run/netconfig
ls: cannot access '/proc/2138/root/run/netconfig': No such file or directory

Hmm, that's the broken setup? Odd that resolv.conf isn't a symlink.
What's in cat /proc/$(pgrep daemon.start)/root/etc/resolv.conf?

I manually added a nameserver there, I could restart LXD, lose the changes I made and verify?

Yeah, that'd be nice, I need to see exactly how it is broken

lrwxrwxrwx 1 root root  35 Jul  9 06:34 alternatives -> /snap/core/current/etc/alternatives
lrwxrwxrwx 1 root root  31 Jul  9 06:34 apparmor -> /snap/core/current/etc/apparmor
lrwxrwxrwx 1 root root  33 Jul  9 06:34 apparmor.d -> /snap/core/current/etc/apparmor.d
lrwxrwxrwx 1 root root  30 Jul  9 06:34 ceph -> /var/lib/snapd/hostfs/etc/ceph
lrwxrwxrwx 1 root root  31 Jul  9 06:34 group -> /var/lib/snapd/hostfs/etc/group
lrwxrwxrwx 1 root root  34 Jul  9 06:34 hostname -> /var/lib/snapd/hostfs/etc/hostname
lrwxrwxrwx 1 root root  31 Jul  9 06:34 hosts -> /var/lib/snapd/hostfs/etc/hosts
-rw-r--r-- 1 root root 14K Jul  9 06:34 ld.so.cache
lrwxrwxrwx 1 root root  35 Jul  9 06:34 localtime -> /var/lib/snapd/hostfs/etc/localtime
-rw-r--r-- 1 root root  86 Jul  9 06:34 logrotate.status
drwxr-xr-x 2 root root  60 Jul  9 06:34 lvm
lrwxrwxrwx 1 root root  12 Jul  9 06:34 mtab -> /proc/mounts
lrwxrwxrwx 1 root root  39 Jul  9 06:34 nsswitch.conf -> /var/lib/snapd/hostfs/etc/nsswitch.conf
lrwxrwxrwx 1 root root  36 Jul  9 06:34 os-release -> /var/lib/snapd/hostfs/etc/os-release
lrwxrwxrwx 1 root root  32 Jul  9 06:34 passwd -> /var/lib/snapd/hostfs/etc/passwd
lrwxrwxrwx 1 root root  37 Jul  9 06:34 resolv.conf -> /var/lib/snapd/hostfs/etc/resolv.conf
lrwxrwxrwx 1 root root  26 Jul  9 06:34 ssl -> /snap/core/current/etc/ssl
lrwxrwxrwx 1 root root  26 Jul  9 06:34 vim -> /snap/core/current/etc/vim

ls -lh /proc/$(pgrep daemon.start)/root/run/netconfig
lrwxrwxrwx 1 root root 35 Jul  9 06:34 /proc/30790/root/run/netconfig -> /var/lib/snapd/hostfs/run/netconfig

cat /proc/$(pgrep daemon.start)/root/etc/resolv.conf
cat: /proc/30790/root/etc/resolv.conf: No such file or directory

Huh, everything seems to be set up properly this time, dunno why it was problematic yesterday. Perhaps it was a race between when it was updated after LXD was running. To explain the situation earlier.


use pytest in run_tests()

The run_tests() utility has been updated so that it is now designed specifically to run the complete build tests.  It can still be used for development testing but it will be relatively slow compared to python setup.py build_ext --inplace.

run_tests() now uses pytest to run the build tests.  Fortunately the unit tests scripts do not need to be changed for this (although they should eventually be converted from the unittest approach).
A new requirements-test.txt file has been created for the necessary build test packages.  This is currently just pytest.
run_tests() now uses whatever pyodbc package is currently available (typically installed into a venv by tox).  run_tests() doesn't look for any .pyd file anymore.  For build testing, I'm hoping we can move away from the .pyd approach.
tox has been enhanced so it can now retrieve database connection string info from a local configuration file set up by the user (default tmp/database.cfg although it can be overridden by PYODBC_DATABASE_CFG).  Note, this is different from the existing default config file tmp/setup.cfg as mentioned in the unit test scripts.  However, I do think it's better to use "setup.cfg" only for project configuration, not for any local development stuff.

Lastly, I'm very keen to move the unit test scripts into database-specific folders, in order to make test discovery easy.  However, this will be tricky for Python 2.7 (which pytest doesn't support).  I am creating a draft PR for that, which will act as a placeholder until we have dropped Python 2.7.

As an illustration of the output from tox now, here's an example:
C:\Users\toast\Documents\GitHub\forks\pyodbc>tox -- --sqlserver "DSN=localhost18;DATABASE=pyodbc"
unit_tests installed: attrs==22.1.0,colorama==0.4.6,exceptiongroup==1.0.4,iniconfig==1.1.1,packaging==21.3,pluggy==1.0.0,pyodbc @ file:///C:/Users/toast/Documents/GitHub/forks/pyodbc,pyparsing==3.0.9,pytest==7.2.0,tomli==2.0.1
unit_tests run-test-pre: PYTHONHASHSEED='170'
unit_tests run-test: commands[0] | python -m pip install --force-reinstall --no-deps .
Processing c:\users\toast\documents\github\forks\pyodbc
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: pyodbc
  Building wheel for pyodbc (pyproject.toml) ... done
  Created wheel for pyodbc: filename=pyodbc-4.0.36b13+updaterun.tests.pytousepytest-cp310-cp310-win_amd64.whl size=66645 sha256=e3a5264987f23919e4f6a1992082c507d517c124bcb8bdb63dff8ea090b0c097
  Stored in directory: C:\Users\toast\AppData\Local\Temp\pip-ephem-wheel-cache-_zd2z1ef\wheels\6f\d5\25\c6588d92de4ca95e18a9938696a87dd94d6679b16bcbcc1f4f
Successfully built pyodbc
Installing collected packages: pyodbc
  Attempting uninstall: pyodbc
    Found existing installation: pyodbc 4.0.36b13+updaterun.tests.pytousepytest
    Uninstalling pyodbc-4.0.36b13+updaterun.tests.pytousepytest:
      Successfully uninstalled pyodbc-4.0.36b13+updaterun.tests.pytousepytest
Successfully installed pyodbc-4.0.36b13+updaterun.tests.pytousepytest
unit_tests run-test: commands[1] | python '.\tests3\run_tests.py' --sqlserver 'DSN=localhost18;DATABASE=pyodbc'
Running tests against SQL Server with connection string: DSN=localhost18;DATABASE=pyodbc
====================================================================================== test session starts ======================================================================================
platform win32 -- Python 3.10.8, pytest-7.2.0, pluggy-1.0.0
cachedir: .tox\unit_tests\.pytest_cache
rootdir: C:\Users\toast\Documents\GitHub\forks\pyodbc
collected 252 items

tests3\sqlservertests.py ................................................................................................................................................................. [ 63%]
...........................................................................................                                                                                [100%]

====================================================================================== 252 passed in 3.04s ======================================================================================
____________________________________________________________________________________________ summary ____________________________________________________________________________________________
  unit_tests: commands succeeded
  congratulations :)

C:\Users\toast\Documents\GitHub\forks\pyodbc>


Set v7.1.0

What does this PR do?
Sets the version to 7.1.0.
How should it be tested manually?
yarn test
# or
npm test

Pull Request Test Coverage Report for Build 329

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

Totals

Change from base Build 327:
0.0%

Covered Lines:
2219

Relevant Lines:
2219

💛  - Coveralls


Update the Kubernetes frameworks

We're currently building against a very old Kubernetes framework version: 1.15.2
The project is already at 1.19, with 1.20 in alpha.
Update all frameworks to the latest stable version and keep them up to date.
This may require fixing incompatibilities and should be thoroughly tested on different cluster versions.
Automated testing may be very useful, see also #4 .

@rhtyd Please add this to the 1.0 milestone.


Enhanced Graphics and content for website

I've made some changes in the layout to make the content readable and more attractive. Also corrected few grammatical errors and one spelling error. If there are any mistakes or suggestions or changes kindly let me know as I am a beginner and will do the needful.

These are minor changes, I can do major ones if you wish so.

@Girlwithasmile You can design Custom graphics for this issue. Don't change the UI.


fix: do not require manyToOne to be defined on the relationship field

With the current shape of relationships, graphback is really confusing with validation failing with errors that should not happen.

ManyToOne is not documented yet it is required and validated to be present

Using ManyToOne in model is causing validation issues (despite usage being valid)

Using only OneToMany will not work with model - client-side generation plugin is not seeing changes and breaks when generating client side queries. (that can be a separate issue but is also a sign of problem)

Validation for relationships is clearly broken (Specifying the same key value on both sides still ends up with the validation error.

Model itself is a little bit confusing as we are forced to remove fields that should stay.

Solution
I have tested this only for mongo by I think we should have short and long term discussions on this.
For short I think we need to disable validation and require manyToOne annotation for the fields that are already covered with OneToMany. This is the fix in this PR.
Long term plan
I think we need some small refactor on relationships to be able to get them aligned.
We can use target schema in the client side plugin as well - that will also fix the problem I see with not being able to generate queries when field is missing, but other problems with persist.

@machi1990 [Offtopic] Website build is triggered for the change that did not affected website

@machi1990 [Offtopic] Website build is triggered for the change that did not affected website

I think we already covered this many times. The change affects the API (source code) hence potentially affecting the generated API code - e.g https://graphback.dev/docs/api/graphback/modules/buildgraphbackapi, thus we need to run the website build to make sure that the links are not broken.

Website Problem fixed in separate PR with explanation:
https://github.com/aerogear/graphback/pull/2021
OVP branch to replicate issue
https://github.com/aerogear/OpenVolunteerPlatform/pull/153

OVP branch to replicate issue
aerogear/OpenVolunteerPlatform#153

Thanks. Checking.

Before
  """@manyToOne(field: 'actions', key: 'volunteerId')"""
  volunteer: Volunteer

  """@manyToOne(field: 'actions', key: 'recipientId')"""
  recipient: Recipient

After this fix:
type VolunteerAction {
  volunteer: Volunteer
  recipient: Recipient
}

Generation successful!


Import 03be6db0e1: Renderable is nullptr segfaults fixes (by Maki)

This is an automated proposal to look at a commit made by Maki and import it into Overte

Commit:
03be6db0e11124a8af7137e0e896e0a9d0f7be8c

Author:
Maki

Date:
Thu, 19 Mar 2020 00:01

Renderable is nullptr segfaults fixes

Stats:

Filename
Stats
Lines
Added
Removed
Lines in blame

libraries/entities-renderer/src/EntityTreeRenderer.cpp

6
3
3
⚠ 0

1 files
-
6
3
3
0

To work on this, please assign the issue to yourself, then look at the commit and decide whether this would be a good addition to Overte.

If the commit is useful, tag it with "Tivoli: Keep", and keep it open until it's merged.
If the commit is not useful, tag it with "Tivoli: Discard", and close it.
If the commit is not useful right now, but might be later, tag it with "Tivoli: Maybe later", and close it.
If it's hard to decide, tag it with "Tivoli: Discuss", and keep it open.

Useful commits should be submitted as a PR against Overte. Tag this issue in PR, so that it's automatically closed once the PR is merged.
You can cherry-pick this issue with this command:
git cherry-pick 03be6db0e11124a8af7137e0e896e0a9d0f7be8c

Looks like a bad fix


Area vision not working when area == 0

https://ptb.discord.com/channels/170995199584108546/513918036919713802/1028087432224194580

Fixed in v0.1.3.


Add doc/user-guide/glossary page

creates a template called doc-jsx.jsx for creating documentation pages with jsx instead of markdown
creates a doc/user-guide/glossary page that lists all tooltip data in this format:

# Glossary

<b id="bold-term">Bold term</b>: description text

see finished page at https://dvc-org-add-glossary-pa-jxqnju.herokuapp.com/doc/user-guide/glossary

Fixes #1395
@jorgeorpinel @casperdcl @iesahin

One thing - let's try to generate 3rd or 2nd level titles? This way items will have links? @iterative/docs WDYT?

Nice work @julieg18 Thank you.
If I open the glossary link directly, it's like this:

Link is: https://dvc-org-add-glossary-pa-jxqnju.herokuapp.com/doc/user-guide/glossary
if I navigate the page from the sidebar, it's like this:

This is with Firefox 89 on macOS 11.4
In the first version, there is a sudden collapse after loading the page.

let's try to generate 3rd or 2nd level titles? This way items will have links?

All entries already have #ids but I guess you mean there should be an on-hover link icon appear on the left of entries

This is with Firefox 89 on macOS 11.4
In the first version, there is a sudden collapse after loading the page.

Hmmmmm, I'm on macOS 11.2.3 and firefox 89.0.2 but I when I click on the link, the sidebar is showing. I tried safari and chrome as well.

I also tried on my windows laptop, but still can't seem to replicate the bug. @iesahin, are you able to see the bug on a different browser? Also are the other documentation links broken as well or just the glossary page?

That's not the sidebar, the content after File Linking is not shown if I click the link.

That's not the sidebar, the content after File Linking is not shown if I click the link.

Oh, I see. Thanks for the clarification!

Hyperlink is now added to heading(and can be added to any other headings on the page if we decide to do so) and all the glossary elements should be rendering properly!

and can be added to any other headings on the page if we decide to do so

yes please (as in hovering on a term will show a link icon :link: on the left of it)

yes please (as in hovering on a term will show a link icon :link: on the left of it)

Do we want to convert the terms into h2s or mimic a headers link behavior while keeping the terms how they look now?

The "look" should be the same as now. Whether internally they are somehow h2s without line breaks or (probably easier) mimic link behaviour is up to you.

The terms' names are now hyperlinks, acting like Header hyperlinks!

I never noticed the Codeclimate check failing in docs repo PRs. Is it an issue?

src/components/Documentation/Markdown/inde/Main/ folder was created with 2 pre-existing files but unfortunately GH didn't pick up the move, so it's hard to tell what changed.

@jorgeorpinel Markdown/index.tsx originally took in htmlAst as props and rendered most of the documentation page. We needed to be able render that part of the documentation page with JSX or htmlAst so I took the majority of Markdown/index.tsx and placed it in a separate component called Markdown/Main. The Main component is used to render part of documentation page whether you want to render JSX or htmlAST.

What is src/components/Documentation/WithJSX/AutoLinkElement/ ? (index.tsx:67 looks fun)

We have a gatsby-plugin that converted our markdown headings into hyper-links. To render hyper-links with JSX, I created the AutoLinkElement. It already has access to the needed css, so all I needed to do was create the html and add the right classes.

Same for src/templates/doc-jsx.tsx . Where is IJSXDocPageProps used?

Whoops, that's a typo. I'll delete the export. Thanks for spotting that!

Are we sure we're not going to want to move this into there? Because that would require a permanent redirect at that point

I don't understand. Is this related to this confusion?

Thanks for the explanations @julieg18! Seems like the code has been peer reviewed so 👌

Are we sure we're not going to want to move this into there? Because that would require a permanent redirect at that point

I don't understand. Is this related to this confusion?

It's related to the naming somewhat, yes. But there's a reason we have glossary tests in basic-concepts/ right? They're closely related. So what will we have as index for Basic Concetps? I know it's beyond the scope here technically but not addressing it now may mean having to do a redirect later, which we can do (I'm not trying to block this merge) but its not ideal.
I'll mention it in tomorrow's meeting.

Are we good to merge this, or is there is more to discuss?

I still don't know what @jorgeorpinel means by "redirect" (i.e. redirect what to what?) but I suspect by "redirect" he is referring to people bookmarking the "edit on GH" URL rather than any dvc.org URL.

Not something anyone does
Not something we need to care about
The source folder layouts are absolutely irrelevant, the only thing which matters is dvc.org URLs never changing or redirecting.

I also don't know what @jorgeorpinel means by "index" but I suspect that once again he means where in source code does a different issue (#550) get addressed, and the answer as repeatedly stated in both issues & meetings is in the same folder. The yml/md source files each will contain 2 keys (short & long descriptions: the short ones are rendered to Glossary, the long ones to BC #550).
Definite immediate merge to me unless @jorgeorpinel is envisioning a different source layout.

UPDATE: OK, we discussed this in the meeting and we agreed to keep the glossary page where it is since it may take a while to get to #550 anyway. Also we can use it initially as the "Basic Concepts index" if we only have a few BCs (e.g. #2453) by linking them from this glossary page.

Thanks again @ju0gri ! 🎉

By redirect I mean https://github.com/iterative/dvc.org/blob/master/redirects-list.json i.e. an actual HTTP 301/303 redirect.

But neither glossary nor basic-concepts currently and in future will ever appear in that file?

dvc.org URLs never changing or redirecting

Exactly. I'm trying to prevent it from changing and redirecting if we have to move the glossary/ to basic-concepts/ (index) soon after this is merged.

completely lost

By index I mean index.md, which is shown for parent nav entries e.g. dvc.org/doc/start (content/doc/start/index.md)

https://github.com/iterative/dvc.org/pull/2595#discussion_r667363616:

Wait no I see. I think it could default to /content/docs/user-guide/glossary/index.md too? Again, this is merged so np but I was thinking what does it take to decouple it completely from basic-concepts/

There is no such thing as /content/docs/user-guide/glossary/index.md.
There is no such thing as /content/docs/user-guide/glossary/.
There is no such thing as /content/docs/user-guide/basic-concepts/index.md.

And none of the above 3 things will ever exist.