Water at the end of the Gobline Sled course is dark

The sled course at the Gobline Village left from last years Xmas event has a waterfall room at the end after you complete the course. Everything looks good except the water which is chocolatey.
https://i.imgur.com/bQyCUMV.png

Can you still get into this area, if not should be closed I think.

Can you still get into this area, if not should be closed I think.

yes it's been left open permanently now :3

Can you take a look on the current version? I think it's almost certainly fixed under some other changes


Add option to only use single line breaks when converting

I've only experienced this when converting from Notion.
There's an option in Obsidian to not use strict line breaks in reader view, it'd be nice if this option was also added to the importer. Without this option in the importer, there ends up being lots of extra new lines in Obsidian after a conversion that aren't needed with "Use strict line breaks" disabled

In my upcoming pull request I've added a "single line breaks" option in the Notion importer.

Closed via 1.5.5


Virtual Node does not get created after following guidance step by step

I have followed guidance on how to enable virtual node on ACI using Azure CLI approach. After activating addon the virtual node is not present. I am only able to create it thru portal, during the cluster creation process. This is major problem since scaling to container instances cannot be enabled for existing cluster.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 916ac90f-8a94-5f3d-eb99-fe06c39eb6cf
Version Independent ID: 2aad2e47-7fde-8d24-f824-236a26e5d887
Content: Create virtual nodes using Azure CLI - Azure Kubernetes Service
Content Source: articles/aks/virtual-nodes-cli.md
Service: azure-kubernetes-service
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

@MarekLani
Thanks for your feedback! We will investigate and update as appropriate.

Thank you @AjayBathini-MSFT , please I would very appreciate if this can be prioritized, since the feature needs to be presented to customer on Friday.

@MarekLani
I'm going to assign this to the document author so they can take a look at it accordingly.
@MGoedtel
Can you please check and add your comments on this doc update request as applicable.

#reassign:schaffererin
Hi @MarekLani, thank you for your feedback. I tested the deployment on both a new cluster and an existing cluster using Azure CLI and both deployments were successful. I have a few questions for you:

Did the existing cluster use the azure network plugin?
Did you make sure the Microsoft.ContainerInstance service provider was registered?
Can you provide more details as to where exactly you experienced an issue?

Your responses will help me further understand and troubleshoot the issue. From there, I can make any necessary doc updates. Thanks!

@schaffererin thanks for response. To your questions, yes provider was registered, and azure network plugin was setup for the cluster. Problem appeared when I ran aks enable addon command specifying the virtual nodes addon to be installed. Command ran successfully, nevertheless when connecting to the cluster I didn't see the virtual node when running kubectl get nodes command. I was running my cluster in North Europe. As I was mentioning everything worked well when I used configuration thru portal.

@MarekLani, of course! Thank you for the prompt response and the additional information. The situation is strange - you definitely should have seen the virtual node when you ran kubectl get nodes.
My thought is maybe there was an error somewhere when creating the initial subnet (myAKSSubnet) and the second subnet (myVirtualNodeSubnet) using the initial subnet (myAKSSubnet) to create the cluster with the vnet subnet ID, and then enabling the virtual nodes add-on to the second subnet (myVirtualNodeSubnet) you created. There's a bit of back and forth between the two subnets... maybe something got mixed up.
I followed the deployment step-by-step and did see the virtual node, however, it did take a few moments to show in the output of kubectl get nodes. From the context, I assume this may have been due to user error since I've successfully deployed the resources.

@MarekLani, because this doesn't seem to be an issue with the doc, I'm going to close this GitHub issue. Thank you again for your feedback and for providing the additional context here. Have a great day!
#please-close


Async/Await in tests?

I've been following this project as a good baseline for testing my Koa2 API, and was wondering what you all think about using async/await with Mocha/Chai/Supertest.
It seems fitting considering the entire API uses async/await as well.

@hoodsy You make a good point, actually. We could use something like supertest-as-promised.
We then could write tests like
try {
  const res = await request
    .post('/auth')
    .set('Accept', 'application/json')
    .send({ username: 'test', password: 'pass' })
    .expect(200)

  res.body.user.should.have.property('username')
  res.body.user.username.should.equal('test')
  expect(res.body.user.password).to.not.exist

  context.user = res.body.user
  context.token = res.body.token

  done()
} catch (err) { done(err) }

Drawback being that we have to surround everything in a try/catch block and manually call done so the tests don't hang.

@adrianObel Hmm.. the consistency is nice. As you say though, having to wrap everything in try/catch may be a bit tedious.
Maybe I'll experiment with this in my own project. Thanks for sharing 😁


Fail to download the trained model

Hello author, I am very interested in your work and I want to have a try, but there may be some error with the Google Drive Folder link of the trained model which cannot be downloaded. Could you please share it again?
Thanks!

Hi there, sorry that the previous google GSuite account has been closed. I just switched to another google account. It should be fixed now.


Removed accidentally committed code

Some code used to gain understanding of the problem was accidentally
committed.  It has now been removed.

Thank you!


Bug report: Magic - InternalError

Describe the bug
Magic - InternalError in blob:https://gchq.github.io/046e0d7d-7a80-4ef3-8030-33cdb25808c3 on line 533.

Message: too much recursion
To Reproduce

Input:
5dba5fecf67f427e4a719475da9fe35d17e1a13b-1609923927-1800-AZbQK4QhO/e3fp49fGeY/sOy6TrMN0e3SJW/O2mf7RESKmgx3kBcFS/9Ias37ZAJB0cO3cSEr3v2sGXJ6OSRulznpC55ObNiSTurm1pKJP/jE9OD2xDN4uNMjGL+oqFzqA==
Add Magic Recipe
Set Depth to 1, 2, or 3. Set Intensive Mode.
See error

Expected behaviour
Something similar when not using Intensive Mode. eg-

Screenshots

Desktop (if relevant, please complete the following information):

Browser: Firefox 84.0.1 (64-bit)

Additional context
None

I wasn't able to reproduce this error on Chrome. Could you try it on Chrome and let me know if you still get the error or if it is specific to Firefox?

I wasn't able to reproduce this error on Chrome. Could you try it on Chrome and let me know if you still get the error or if it is specific to Firefox?

Yes, Chrome works fine, it is specific to firefox.

Yes, Chrome works fine, it is specific to firefox.

+1


Add J2ME Loader for Java ME

Since Squireljme is expected in 2023 (as the core says) and Freej2me works only with the OS java implementation (making the core completely useless if the phone isn't rooted), could you please add J2ME Loader for running Java ME and J2ME games? Thanks

Have tried J2ME Loader and no luck. :(

You didn't manage ti make j2me loader work or you didn't managed to implement it?

I didn't make it launch from Dai previously. But I've tried again today with different parameters. It launches the game to dialog. But not open it directly.

You can redownload the java me platform to try.


Fix cookie_remap / cookie_remap autest

After merging PR #4964 TSRemapRequestInfo::reqiestUrl from the Remap API will always contain the remapped URI (more info in the PR #4964) which may lead to changes in the cookie_remap plugin  or its autest (tests disabled to be able to merge the incompatible API change)

This issue was addressed with PR #5653


admindebug.cpp: #1580: Enforce need of TTY to turn on debug mode

Prevents a crash from happening, but does not apply a workaround (e.g. opening a new file for stdout)

Fixed now.


is:issue is:open when I run cd external/YOLOX/ pip install -r requirements.txt && python setup.py develop，ImportError: cannot import name '_C' from 'yolox' (/TOPICTrack-main/external/YOLOX/yolox/init.py)

@-V2:~/TOPICTrack-main/external/YOLOX$ python setup.py develop
Traceback (most recent call last):
File "setup.py", line 79, in
ext_modules=get_ext_modules(),
File "setup.py", line 52, in get_ext_modules
from yolox.layers import FastCOCOEvalOp
File "/TOPICTrack-main/external/YOLOX/yolox/layers/init.py", line 5, in
from .fast_coco_eval_api import COCOeval_opt
File "/TOPICTrack-main/external/YOLOX/yolox/layers/fast_coco_eval_api.py", line 13, in
from yolox import _C
ImportError: cannot import name '_C' from 'yolox' (/TOPICTrack-main/external/YOLOX/yolox/init.py)

We have fixed the YOLOX installation problem, and please try again. Please do not hesitate to ask again if you have any problems.


target_find_dependencies and pkg-config

I'm trying to use target_find_dependencies to add the dependencies for a STATIC library that depends on some libraries that can be found via pkg-config, I'm able to pass the PkgConfig package to target_find_dependencies but there doesn't seem to be an easy way to add the pkg_check_modules calls to the CMake package config, is there any way I can solve this situation?
My old Config.cmake.in file used to look like this:
@PACKAGE_INIT@

include(CMakeFindDependencyMacro)

find_dependency(Threads)
find_dependency(PkgConfig)

if(NOT TARGET PkgConfig::gio)
    pkg_check_modules(gio REQUIRED IMPORTED_TARGET gio-2.0)
endif()

if(NOT TARGET PkgConfig::dbus)
    pkg_check_modules(dbus REQUIRED IMPORTED_TARGET dbus-1)
endif()

include("${CMAKE_CURRENT_LIST_DIR}/<EMAIL_ADDRESS>
check_required_components(@TARGET_NAME@)

Upvote & Fund
@aminya is using Polar.sh so you can upvote and help fund this issue. The funding is received once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog!

There is a official way for cmake to custom find_pacakge, which might be helpful in your case.
You can see an actual example here, which is the CMake dependency provider for the Conan C and C++ package manager.

I’m not quite sure what your question is. Are you trying to target_find_dependencies(<target> PUBLIC gio) in which gio is a library that should be found by pkg_check_modules?
If that's the case, there is an official way for cmake to custom find_pacakge, which might be helpful. You can see an actual example here, which is the CMake dependency provider for the Conan C and C++ package manager.

Sure, so is there a way to inject a custom dependency provider into the project_options target_find_dependencies call?
Or does the custom provider have to be implemented on the users of the package instead of the provider? And in that case, won't it break conan?

The situation is that PkgConfig dosen't provide one, so you have to. I think this won't break conan as both cmake-conan and vcpkg use this approach and project_options works well while enabling both run_conan() and run_vcpkg().
What target_find_dependencies actually do is to

call find_package for the specified packages;
register them as a part of installation.

When running cmake --install, the corresponding cmake config file will insert a find_package(<package> [args]) for all the packages specifed in target_find_dependencies. That's how the function works.
To install pkg_check_modules dependency, you can

either pkg_check_modules by manual, and insert the code into cmake config file yourself at the same time.
or write a find_package provider which allows find_package to handle pkg_check_modules, and install the find_package provider file.

Is this fixed after #257

Is this fixed after #257?

@aminya Possibly not. Instead of allowing custom find_package args like #257, this issue is about extending target_find_dependencies to be able to find dependencies that are imported by functions other than find_pacakge, and install such a dependency when the target is required to install.
Without modifying the target_find_dependencies, this could be done by:

either pkg_check_modules by manual, and inserting the code into cmake config file yourself at the same time.
or writing a find_package provider which allows find_package to handle pkg_check_modules, and installing the find_package provider file.

Another option could be extending target_find_dependencies to have a custom mode:
target_find_dependencies(target
  PUBLIC
    # Syntax option 1
    CUSTOM "pkg_check_modules(gio REQUIRED IMPORTED_TARGET gio-2.0)"
    # Or syntax option 2?
    CUSTOM pkg_check_modules gio REQUIRED IMPORTED_TARGET gio-2.0
)

Please let me know if this is acceptable. If it is, which is the best syntax?

I think the most versatile solution would be to add a way to provide a CMake script as an extension point (maybe allow multiple files?), eg: target_find_dependencies(<target> CUSTOM MyInjectedDep.cmake), then it can be installed as part of the package and included after the other 'find_dependency()' calls.

add a way to provide a CMake script as an extension point (maybe allow multiple files?), eg: target_find_dependencies(<target> CUSTOM MyInjectedDep.cmake)

After setting cmake_language(SET_DEPENDENCY_PROVIDER...), all find_package will try to use the provider, so this seems like a dependency for the whole project instead of the <target>, which violets the purpose of using target_find_dependencies (that is, bind the dependency to the target).
If setting the MyInjectedDep.cmake is the preferable way than CUSTOM pkg_check_modules gio REQUIRED IMPORTED_TARGET gio-2.0, I would prefer add a function like set_dependency_provider(<provider.cmake>) to both call cmake_language(SET_DEPENDENCY_PROVIDER...) and install it. But it is almost just a wrapper for a cmake_language(SET_DEPENDENCY_PROVIDER...) command and a install(FILES...) command, which is the solution describe before:

writing a find_package provider which allows find_package to handle pkg_check_modules, and installing the find_package provider file.

Another difference between setting dependency provider and just allowing CUSTOM any_function args is that you have to adapt the call to find_package style. For example, for pkg_check_modules(gio REQUIRED IMPORTED_TARGET gio-2.0), you have to adapt it to be find_package(gio) or something else, which is not implementable for some functions.

I'm also unsure about what will happen if a user has a custom Findgio.cmake module and a dependency provider is added, my idea with the MyInjectedDep.cmake was just so you could more easily write complex logic to find dependencies if needed, without dealing with a long string.

You could have MyInjectedDep.cmake without modifying target_find_dependencies , just by include(MyInjectedDep.cmake) and install(FILES MyInjectedDep.cmake).
My question here is that target_find_dependencies is to set dependencies for a single target, so maybe a function like set_dependency_provider(<provider.cmake>) is more suitable than allowing target_find_dependencies to set a file
(and possibly global) dependency.

Is this fixed after #257?

@aminya Possibly not. Instead of allowing custom find_package args like #257, this issue is about extending target_find_dependencies to be able to find dependencies that are imported by functions other than find_package, and install such a dependency when the target is required to install.
Without modifying the target_find_dependencies, this could be done by:
* either pkg_check_modules by manual, and inserting the code into cmake config file yourself at the same time.

* or writing a find_package provider which allows find_package to handle pkg_check_modules, and installing the find_package provider file.

Another option could be extending target_find_dependencies to have a custom mode:
target_find_dependencies(target
  PUBLIC
    # Syntax option 1
    CUSTOM "pkg_check_modules(gio REQUIRED IMPORTED_TARGET gio-2.0)"
    # Or syntax option 2?
    CUSTOM pkg_check_modules gio REQUIRED IMPORTED_TARGET gio-2.0
)

Please let me know if this is acceptable. If it is, which is the best syntax?

I guess the syntax on option 2 would be the best in this case than.


PyInstaller 5.8.0 broke flet pack command on Windows

Discussed in https://github.com/flet-dev/flet/discussions/1028

Originally posted by Ben2022-cell February 12, 2023
The packaging-desktop-app docs talk about packaging a desktop app into an executable using flet pack command as follows -
flet pack your_program.py
But wen i execute there code , there is presenting an error, see that:
$ flet pack jartual_frame_flet.py
Please install PyInstaller module to use flet pack command: cannot import name 'decode' from 'PyInstaller.utils.win32.versioninfo' (D:\Python39\lib\site-packages\PyInstaller\utils\win32\versioninfo.py)
the PyInstaller packing i has setup finish, and updated to the lastest version.

same issue

A workaround is to downgrade PyInstaller to 5.7.0:
pip uninstall pyinstaller
pip install pyinstaller==5.7.0


Add Intel Distribution of Modin AI Kit Instructions to Modin Installation Documentation

Add information on how to install, download Intel Distribution of Modin and its OmniSci backend to the Modin documentation installation section, This way, users have information on all types of Modin installs. Also provide other resources such as the Intel Distribution of Modin page for more information: https://software.intel.com/content/www/us/en/develop/tools/oneapi/components/distribution-of-modin.html#gs.1wcine
@aregm

Closing as it is covered by #3098


Getting "No compatible source was found for this media error" when used "this.player.ima.changeAdTag"

Hi,We are using video js ima with hls. Player is set to autoplay so we deliver multiple videos and ads in single session, when the first video gets completed the second video starts and the preroll ads starts (we are changing the source of ad  during video ended event) and plays when the ad ends. However we are getting "VIDEOJS: ERROR: (CODE:4 MEDIA_ERR_SRC_NOT_SUPPORTED) No compatible source was found for this media error"
when used  "this.player.ima.changeAdTag("https://pubads.g.doubleclick.net/gampad/ads?sz=640x480&iu=/124319096/external/single_ad_samples&ciu_szs=300x250&impl=s&gdfp_req=1&env=vp&output=vast&unviewed_position_start=1&cust_params=deployment%3Ddevsite%26sample_ct%3Dlinear&correlator="); "
demo : https://console.ex8.io/vast_mediation/test.html
Is there something we are doing wrong?

Hi,
The issue you reported does not seem to be with the IMA SDK. Given the error message received, the VideoJS part if the plugin is telling you that the media type passed to the videojs src is not supported. This is not an issue with Videojs-IMA, it's an issue with the media type of your video content not being supported.

I’m closing this issue because it has been inactive for a few months. Please reopen if you still encounter this issue with the latest stable version
Thank you!


R2.1 pip install failed to find a correct tensorflow-estimator

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 18.04
TensorFlow installed from (source or binary): source code build and then pip install
TensorFlow version: R2.1 (b2474d99ae962ce66d6db896606488797152dc4d)
Python version: 2.7
Installed using virtualenv? pip? conda?: pip
Bazel version (if compiling from source): 0.29.1
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version: CPU(MKL)

ERROR: No matching distribution found for tensorflow-estimator<2.2.0,>=2.1.0 (from tensorflow==2.1.0rc1)
Provide the exact sequence of commands / steps that you executed before running into the problem
Any other info / logs
Target //tensorflow/tools/pip_package:build_pip_package up-to-date:
  bazel-bin/tensorflow/tools/pip_package/build_pip_package
INFO: Elapsed time: 1088.439s, Critical Path: 237.61s
INFO: 19007 processes: 19007 local.
INFO: Build completed successfully, 19988 total actions
INFO: Build completed successfully, 19988 total actions
Mon Dec 9 09:18:14 UTC 2019 : === Preparing sources in dir: /tmp/tmp.fqqQwu5J91
/tensorflow /tensorflow
/tensorflow
/tmp/tmp.fqqQwu5J91/tensorflow/include /tensorflow
/tensorflow
Mon Dec 9 09:18:21 UTC 2019 : === Building wheel
warning: no files found matching 'README'
warning: no files found matching '*.pyd' under directory '*'
warning: no files found matching '*.pd' under directory '*'
warning: no files found matching '*.dylib' under directory '*'
warning: no files found matching '*.dll' under directory '*'
warning: no files found matching '*.lib' under directory '*'
warning: no files found matching '*.csv' under directory '*'
warning: no files found matching '*.h' under directory 'tensorflow_core/include/tensorflow'
warning: no files found matching '*' under directory 'tensorflow_core/include/third_party'
Mon Dec 9 09:18:57 UTC 2019 : === Output wheel file is in: /tmp/pip
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Processing /tmp/pip/tensorflow-2.1.0rc1-cp27-cp27mu-linux_x86_64.whl
Collecting gast==0.2.2
  Downloading https://files.pythonhosted.org/packages/4e/35/11749bf99b2d4e3cceb4d55ca22590b0d7c2c62b9de38ac4a4a7f4687421/gast-0.2.2.tar.gz
Collecting grpcio>=1.8.6
  Downloading https://files.pythonhosted.org/packages/0c/47/35cc9f6fd43f8e5ed74fcc6dd8a0cb2e89c118dd3ef7a8ff25e65bf0909f/grpcio-1.25.0-cp27-cp27mu-manylinux2010_x86_64.whl (2.4MB)
Requirement already satisfied, skipping upgrade: numpy<2.0,>=1.16.0 in /usr/local/lib/python2.7/dist-packages (from tensorflow==2.1.0rc1) (1.16.5)
Collecting protobuf>=3.8.0
  Downloading https://files.pythonhosted.org/packages/a3/27/9a375cc85b90c93ab847370c31fe1302a763b6cd57d54daee20171d720ff/protobuf-3.11.1-cp27-cp27mu-manylinux1_x86_64.whl (1.3MB)
Requirement already satisfied, skipping upgrade: wheel; python_version < "3" in /usr/lib/python2.7/dist-packages (from tensorflow==2.1.0rc1) (0.30.0)
Collecting wrapt>=1.11.1
  Downloading https://files.pythonhosted.org/packages/23/84/323c2415280bc4fc880ac5050dddfb3c8062c2552b34c2e512eb4aa68f79/wrapt-1.11.2.tar.gz
Requirement already satisfied, skipping upgrade: keras-preprocessing>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from tensorflow==2.1.0rc1) (1.1.0)
Collecting backports.weakref>=1.0rc1; python_version < "3.4"
  Downloading https://files.pythonhosted.org/packages/88/ec/f598b633c3d5ffe267aaada57d961c94fdfa183c5c3ebda2b6d151943db6/backports.weakref-1.0.post1-py2.py3-none-any.whl
Collecting six>=1.12.0
  Downloading https://files.pythonhosted.org/packages/65/26/32b8464df2a97e6dd1b656ed26b2c194606c16fe163c695a992b36c11cdf/six-1.13.0-py2.py3-none-any.whl
Requirement already satisfied, skipping upgrade: keras-applications>=1.0.8 in /usr/local/lib/python2.7/dist-packages (from tensorflow==2.1.0rc1) (1.0.8)
Collecting functools32>=3.2.3; python_version < "3"
  Downloading https://files.pythonhosted.org/packages/c5/60/6ac26ad05857c601308d8fb9e87fa36d0ebf889423f47c3502ef034365db/functools32-3.2.3-2.tar.gz
Collecting termcolor>=1.1.0
  Downloading https://files.pythonhosted.org/packages/8a/48/a76be51647d0eb9f10e2a4511bf3ffb8cc1e6b14e9e4fab46173aa79f981/termcolor-1.1.0.tar.gz
Collecting absl-py>=0.7.0
  Downloading https://files.pythonhosted.org/packages/3b/72/e6e483e2db953c11efa44ee21c5fdb6505c4dffa447b4263ca8af6676b62/absl-py-0.8.1.tar.gz (103kB)
Collecting opt-einsum>=2.3.2
  Downloading https://files.pythonhosted.org/packages/f6/d6/44792ec668bcda7d91913c75237314e688f70415ab2acd7172c845f0b24f/opt_einsum-2.3.2.tar.gz (59kB)
Collecting tensorboard<2.2.0,>=2.1.0
  Downloading https://files.pythonhosted.org/packages/e4/c5/94a66686b86adfb3ef6f34837d0a7cc2efdc995bc39cad64a9b3e103f0d5/tensorboard-2.1.0-py2-none-any.whl (3.8MB)
ERROR: Could not find a version that satisfies the requirement tensorflow-estimator<2.2.0,>=2.1.0 (from tensorflow==2.1.0rc1) (from versions: 1.10.6, 1.10.7, 1.10.8, 1.10.9, 1.10.10, 1.10.11, 1.10.12, 1.13.0rc0, 1.13.0, 1.14.0rc0, 1.14.0rc1, 1.14.0, 1.15.0, 1.15.1, 2.0.0, 2.0.1, 2.1.0rc0)
ERROR: No matching distribution found for tensorflow-estimator<2.2.0,>=2.1.0 (from tensorflow==2.1.0rc1)

It is still work-in-progress so please be patient.
Gently ping @mihaimaruseac.

It should get fixed today, sorry about this. I'll ping back here when it gets fixed.

Should be fixed now

fixed. Thanks @mihaimaruseac and @byronyi


go-swagger is generating the wrong validation functions

Problem statement
Swagger command is generating a pair of validation functions that are incorrect, mostly because it's misinterpreting strings as float64 and applying the wrong vaidation function as aresult
Here are the error messages from the go compiler:
simpleHostmap/restapi/operations
restapi\operations\find_cluster_parameters.go:84:50: cannot convert o.ID (type string) to
type float64
restapi\operations\find_host_parameters.go:84:56: cannot convert o.HostName (type string)
to type float64
Here are the actual function signatures from the generated source
// validateID carries on validations for parameter ID
func (o *FindClusterParams) validateID(formats strfmt.Registry) error {
if err := validate.Minimum("id", "path", float64(o.ID), 1, false); err != nil {
return err
}
return nil
}
// validateHostName carries on validations for parameter HostName
func (o *FindHostParams) validateHostName(formats strfmt.Registry) error {
if err := validate.Minimum("hostName", "path", float64(o.HostName), 1, false); err != nil {
return err
}
return nil
}
Swagger specification
Here's how the two affected fields are defied in the paths section of the Swagger 2.0 spec:
/clusters/{id}:
get:
summary: Returns a cluster by ID
operationId: findCluster
parameters:
- in: path
name: id
required: true
type: string
minimum: 1
description: The ID of the cluster to return
and ...
/hosts/{hostName}:
get:
summary: Returns a host object by hostName
operationId: findHost
parameters:
- in: path
name: hostName
required: true
type: string
minimum: 1
description: The name of the host to return
Note: Both of these fields are considered unique record id strings and are being used in the API to find individual records
Steps to reproduce
Generate the code:
swagger generate server -f swagger.yml
Build the project:
$ cat buildSHM.cmd                                                                                @echo off                                                                                setlocal                                                                                cd "C:\Users\eu9195\go\src\simpleHostMap"                                                                                set GOOS=linux                                                                                go build -tags=jsoniter -o "shm" C:\Users\eu9195\go\src\simpleHostmap\cmd\simple-host-map-server
endlocal
This spits out these messages:
Environment
swagger.exe version
dev
go version: 1.12.5
OS: Windows 7

if you quote the minimum values I think it will go away.
YAML tells us those are ints

So it's this:
minimum: 1
that's causing the problem...
It kinda makes sense, actually: I (originally) thought it had to to with
the number of records returned, not the value of the field.  Plus, for both
fields it clearly says the type is "string" .
Regardless, as soon as removed this:
minimum: 1
from both of the entries the errors went away.
Thanks a ton...
-- Paul
Paul Uzee
Cell:<PHONE_NUMBER>
On Fri, May 24, 2019 at 8:45 PM Ivan Porto Carrero<EMAIL_ADDRESS>wrote:

if you quote the minimum values I think it will go away.
YAML tells us those are ints
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/go-swagger/go-swagger/issues/1951?email_source=notifications&email_token=AAXHWRGWTIC5JMXO46JHKATPXCD37A5CNFSM4HPTN4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWG2AGY#issuecomment-495820827,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXHWRBCEXCX5YLM5EC6ALLPXCD37ANCNFSM4HPTN4ZQ
.

To fix your validation you can use minLength, mimimum is for numeric types, minLength is for strings and minItems is for arrays


[hosting] Propose to runTipi

hi @CorentinTh do you know when enclosed will get added to runtipi?

Hi @johnnyq, no idea, the PR is idling on runtipi side :shrug:

They no longer accept new apps for now, see https://github.com/runtipi/runtipi-appstore/pull/4924#issuecomment-2549496581
I'm closing, we'll reopen if their's some changes


Craft 4 compatibility

Kindly let me know if there are plans to upgrade this plugin for Craft CMS version 4.
If yes, is there an ETA?

+1
Hi @engram-design, would be great to know if you’re planning on porting this to Craft 4.

The both of us are colleagues so it is really just one! 😄
This plugin provides a good system to ensure caches as busted whenever a scheduled entry goes live (or expires). That is really the only functionality we’re looking for at the moment. Happy to consider alternate strategies if you have any other suggestions.

Hello @engram-design, any updates for us.

Would love to be able to use this as well


Fix tables with screen readers

Hi the tables don't show up as tables to a screenreader.
EG the table for Active DHCP Leases on the Overview page just reads as text. This is the same for all tables in LUCI. In LEDE 17xx worked with screen readers. Thanks

In 18.06 HTML tables has been changed to div markup (see base commit 067d7dc). Maybe we have to tweak CSS to better support screen readers - but that's just a rough guess.


Is this repo dead?

I've raised a PR some time ago to add more syntax highlighting and it's not been checked.

All - I now have collaborator access.  Please may I ask that you link your issues into this one so I can review the priority in the backlog.
Thanks
Richard


Services are not properly shutdown

Services are not properly shutdown, the task listener seems to always listen and prevent the service to gracefully stop.
We should add a mechanism that stop the listener when the service receive the stop signal from docker.

Do you have a way to reproduce that? I cannot reproduce.

look at the docker container logs of the service when it's being stopped

Could you check that this has been fixed by https://github.com/liteflow-labs/liteflow-js/pull/82

The issue is not fixed.
This issue is related to the @liteflow/service lib, not the cli.
The problem is the library doesn't listen for SIGTERM and so never gracefully stop.
So when the cli stop a container, the cli wait 10sec (default of docker) before killing the container.

With the new architecture of the services, this should be fixed by design. Could you confirm

This has been fixed by stopping the HTTP server of the service:
https://github.com/liteflow-labs/liteflow-js/blob/42a21b0ceef28e47ce3f0c38b508088f17aaa1b8/packages/service/src/index.ts#L115-L122


Fix black-box attribute attack to support 1-hot-encoded and scaled features

Signed-off-by: abigailt<EMAIL_ADDRESS>Description
In addition to the ability to attack 1-hot encoded features, this adds support for 1-hot encoded features that have also undergone scaling (so are represented by arbitrary floating point values instead of 0 and 1).
Type of change
Please check all relevant options.

[X] Improvement (non-breaking)
[ ] Bug fix (non-breaking)
[ ] New feature (non-breaking)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Testing
All unit tests pass
Test Configuration:

OS: MacOS 10.15.7
Python version: 3.7
ART version or commit number
TensorFlow / Keras / PyTorch / MXNet version

Checklist

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code
[ ] I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes

Codecov Report

Merging #927 (95c5d0c) into dev_1.6.0 (4b769ad) will decrease coverage by 40.25%.
The diff coverage is 18.18%.

@@              Coverage Diff               @@
##           dev_1.6.0     #927       +/-   ##
==============================================
- Coverage      65.63%   25.38%   -40.26%
==============================================
  Files            176      205       +29
  Lines          17105    18337     +1232
  Branches        3157     3309      +152
==============================================
- Hits           11227     4654     -6573
- Misses          4635    13291     +8656
+ Partials        1243      392      -851

Impacted Files
Coverage Δ

art/utils.py
35.01% <12.50%> (ø)

...attacks/inference/attribute_inference/black_box.py
58.92% <33.33%> (-30.36%)
:arrow_down:

...rt/defences/detector/poison/clustering_analyzer.py
8.22% <0.00%> (-86.71%)
:arrow_down:

...ces/detector/evasion/subsetscanning/scanningops.py
11.59% <0.00%> (-85.51%)
:arrow_down:

art/attacks/evasion/carlini.py
8.40% <0.00%> (-80.87%)
:arrow_down:

...ient_descent/projected_gradient_descent_pytorch.py
16.93% <0.00%> (-78.23%)
:arrow_down:

...escent/projected_gradient_descent_tensorflow_v2.py
18.33% <0.00%> (-76.67%)
:arrow_down:

art/metrics/verification_decisions_trees.py
13.75% <0.00%> (-73.02%)
:arrow_down:

...defences/preprocessor/spatial_smoothing_pytorch.py
13.41% <0.00%> (-70.74%)
:arrow_down:

art/attacks/evasion/decision_tree_attack.py
22.66% <0.00%> (-69.34%)
:arrow_down:

... and 153 more

@beat-buesser Thanks for the review, I added a unit test and fixed the formatting issue.


feat: blur and focus for other helpers

Motivation/Description of the PR

Resolves #3679

Applicable helpers:

[ ] WebDriver
[ ] Puppeteer
[ ] TestCafe
[ ] Playwright

Type of change

[ ] :bug: Bug fix
[ ] :clipboard: Documentation changes/updates

Checklist:

[ ] Tests have been added
[ ] Documentation has been added (Run npm run docs)
[ ] Lint checking (Run npm run lint)
[ ] Local tests are passed (Run npm test)

Thank you! Should be good!


Sas improvements

Substantial improvements to language-sas syntax highlighting.

Added numerous language elements
Created more granular keyword objects, for finer grained styling if desired
Expanded keyword regex list
Special identification of PROC SQL and the SQL that follows
Test coverage for all added language elements

@cedporter
Why did you close it? There are a lot of good things in here.

@RunDevelopment, just needed to clean up the commit history. It's resubmitted!

You can just force push in this case, although you generally don't need to clean up your commit history. We (well, git(-hub) actually) will squash all of your commits into one before committing to master.


[imgui] Add sfml feature.

Due to imgui-sfml needs to build with imgui source code, it cannot be as a single port to be built.
So I add sfml to imgui as its feature.
Related issue #7333.

ImGui-SFML maintainer here. That doesn't feel right to me, and I feel like ImGui-SFML needs to have an option to build without ImGui's source code. ImGui's vcpkg script should not depend on ImGui-SFML in any way.
Maybe you can suggest how ImGui-SFML can allow fo more flexibility to allow you to get ImGui in some other way? What does vcpkg provide?

@eliasdaler , thanks for your feedback. Sorry for the late reply. I noticed that you and @tntxtnt have talked about this issue in PR #7429. I agree with you that we should add  ImGui-SFML as a single port.
Thanks again for your patience.


Changes to get Net1.inp to run

@LRossman Thanks for the PR! Could you tell us a little about the changes you've made? I guess I didn't realize that Net1.inp wasn't running.

@michaeltryby To get "dev" to compile I had to initialize tankVolumes  in QUALITY:nextqual() to NULL. But I decided instead to rename it to QTempVolumes, make it part of the quality_t structure and only allocate memory for it once in Quality::initqual() instead of each time that nextqual() is called.
Then when trying to run Net1.inp error 305 resulted (could not create hydraulics file), but the error message displayed was "Function call error - Coordinates were not loaded" which of course made no sense. I tracked this down to an incorrect argument passed to geterrmsg() in EPANET:ENgeterror().
Then I discovered that getTmpNam() in EPANET.C was creating an illegal file name and was still using the unsafe tmpnam function. So I replaced the entire getTmpNam() function with the more robust version used in SWMM. After that Net1 ran successfully.
Finally, the compiler also noted that there was no function writeRuleinInp which gets called in the INPFILE.C code. That function actually exists in RULES.C but it is declared locally. So I moved the declaration to the FUNCS.H file.

@LRossman That sounds great. I'm curious, what compiler are you using?

@michaeltryby Microsoft Visual C++ 2017.

@LRossman Oh that's great! We can add Visual Studio 2017 to the Appveyor build matrix.

@michaeltryby Originally built to 32 bit but just compiled it to x64 and it seemed to work OK (at least on net1.inp). With MS VC++ you have to either add #define _CRT_SECURE_NO_WARNINGS to each module that uses the scanf/printffamily of functions or add it to the compiler's pre-processor definitions in the project's settings (which is what I did). Otherwise the compiler flags as errors all lines of code that use those functions.

@LRossman I'm going to push a commit to this PR to get Appveyor building on VS 2017 - 64bit and get the reg tests running so we can see where we are with respect to our benchmark. Sound good?

@LRossman Sorry about cluttering up your PR :flushed:.
I got Appveyor building and reg tests running for Visual Studio 2017 Win64: 41 reg tests pass and 4 fail.
You can see the results here. Or by going to the appveyor badge immediately below this post and clicking "details".

@michaeltryby Good job. So where can one find the suite of test files you are running so that the failed tests can be diagnosed?

@LRossman in the tools folder there is a batch file titled before-test.cmd that goes out and grabs the test files and binary benchmark files and stages everything for reg testing. Assuming you don't want to mess with with Python and nrtest, you can just browse the batch file and get the gist of what its doing or run it in a command prompt with admin privileges and pass it some dummy arguments.
If you do want to mess with nrtest I can send you more detailed instructions. Just let me know.

The input files used for testing can be found here.

@LRossman Were you going to continue working on this PR to resolve the issues with the failing tests or should I go ahead and merge it? What is your preference?

@michaeltryby I would like to, but the Appveyor results are pretty useless in trying to determine where the discrepancies crop up. For example, here is what was reported for Sampltown.inp:
mismatch 14.2857142857%)
x: array([6.825110e+02, 6.825110e+02, 6.025111e+02, 1.500001e+02,
6.416148e-05, 2.025110e+02, 5.000000e+01])
y: array([6.825110e+02, 6.825110e+02, 6.025110e+02, 1.500001e+02,
6.327374e-05, 2.025110e+02, 5.000000e+01])
I have no idea what these numbers refer to. However you can see that the mis-match occurs for the 5th item whose value is very small (~0.00001) suggesting its a flow in a closed link. I take it these were results using the 64-bit build. Did the 32-bit build pass? How are other contributors going about reconciling Appveyor failures?

@LRossman the Appveyor output simply indicates that there is a difference in the Sampletown results. Just like if you ran it as part of your normal testing procedure. I provided the link to the input files so you should have them locally  Run the failing tests locally and dig into the results like you normally would. For engine work it makes sense to run tests locally. That hasn’t changed.

Hi, also encountered similar differences in results between 64bit and 32bit results when compiling EPANET 2.0.12 a few years ago, and was about to start today to revisiting them. So I'm very interested in following your resolution @LRossman.

@lxsinske my understanding is that the shift to 64 bit only affects integer types. We are also porting to a different compiler version which is another potential source of the differences. Reg testing just helps us see these differences more easily.

@michaeltryby Here's what I found regarding the differences in results between various builds of both the current epanet dev branch and my fork, which I'll call dev-1. The latter had only three changes that did not involve any computational portions of the code. (I should note that I had a difficult time using the CMakelists.txt supplied with the dev branch which I will comment on in a separate issue.)

You didn't say what compiler was used to produce the 32-bit version of dev that passed the reg tests. I could not get a MSVC build (either 32 or 64-bit) of dev to run because of the illegal file name it generated for the scratch hydraulics file as I mentioned previously and which was one of the issues I fixed in dev-1.
Compiling both dev and dev-1 for GNU using cmake produced identical results for the wolf-3.inp file (1985 pipes with 4 pumps and 4 PRVs).
Using Makefile.bat to build both a 32- and 64-bit version of dev-1 also produced identical results when each was used to run wolf-3.inp.
Using a file comparison tool to compare the flow results from the GNU build of dev (or dev-1 since they produce the same numerical results) with the MSVC build of dev-1 found over 200 differences. Most of these were for values reported as +/- 0.00. Two were for flows through a pump and its connected PRV (1775.73 gpm v. 1775.66 gpm, or < 0.004%). The remaining flow differences were all no larger than 0.01 gpm. The relative flow change for the first six hydraulic trials between the two looked as follows:

GNU Build
MSVC Build

1.135599
1.135599

2.949463
2.949467

1.017972
1.017972

0.462839
0.462842

0.231009
0.231007

I'm guessing that the slight differences between results from the GNU build versus the MSVC build is due to differences in the floating point options each compiler uses. MSVC offers three options: fp:precise, fp:fast and fp:strict. The Makefile.bat file did not specify an option so fp:precise was used by default. GNU C++ offers similar sounding options: default, relaxed and full, but uses combinations of six different compiler flags to define these. Changing the floating point options can affect numerical results. I tested this by running dev-1 compiled under MSVC first with fp:precise and then with fp:fast on the wolf-3.inp file. The numerical differences, although not large, were quite noticeable.

@LRossman, for some examples on setting compiler flags for cmake, check out how we did it for SWMM: SWMM-cmake

@LRossman, could you clarify which floating point option you were using for GCC? You said there are three but the the configuration is a function of six flags in total. This would be valuable to know for purposes of updating the cmakelists.txt (for swmm too).

@bemcdonnell From https://gcc.gnu.org/wiki/FloatingPointMath it appears that using the "default" floating point model under GNU C++ doesn't require setting any flags (which would be -fno-rounding-math and -fno-signaling-nans). From https://stackoverflow.com/questions/3234042/is-there-a-linux-g-equivalent-to-the-fpprecise-and-fpfast-flags-used-in it appears that there is no way to insure 100% floating point equivalence between GNU and MSVC. What I take away from this is that one needs to make automated regression testing dependent on the compiler being used (or relax the difference criteria that signals a failed test).

@LRossman Our regression testing IS dependent on the platform and compiler being used. Our current benchmark is Visual Studio 10 2010 32 bit. That is the benchmark currently passing on Appveyor. We run a gcc build on Travis, but we have not done the work to establish a proper benchmark there. The failing tests serve to indicate that Linux is currently unsupported. Due diligence suggests that we identify compiler settings on gcc that minimize platform drift of the results. Wouldn't you agree? However, since this PR contains changes to EPANET to get it building on Visual Studio 15 2017, I don't think gcc is the issue here. Lets set it aside for a moment.
The issue is that a migration to Windows 64 bit is long overdue. Which version of Visual Studio should we use to do that migration -- Visual Studio 6, 10, 15?  Since this PR gets EPANET building on Visual Studio 15 2017 that seems like as good a place as any to start. Wouldn't you agree? Do you feel confident that the compiler settings you have chosen minimize benchmark drift going from Visual Studio 6 or 10 32 bit -> Visual Studio 15 2017 64 bit? It would really help move the project forward to got out of Visual Studio 6 and 10 and establish a new benchmark on a modern compiler like Visual Studio 15 2017. So hats off to you for getting the ball rolling!
I will go ahead and create Issues corresponding to the topics raised here to help avoid further confusion.
Also we are all aware of the learning curve associated with git and CMake.

I agree to use Visual Studio 15 2017 as basis for EPANET 64 bit, and then confirming that results are near identical to the 32bit EPANET on the same compiler. Should one compare results to the last 32bit EPANET 2.0.12 as well or will changes/fixes introduced in dev and dev-1 make it incompatible?

@lxsinske Resolving issues #160, #164, and #165 (which I plan to work on in the coming weeks) will definitely cause changes in some numerical results from both v. 2.0 and 2.1. I have no idea how this will affect getting PR's approved when the reg tests on these updates will most likely fail.

@LRossman It's great that you are going to work on issues #160, #164, and #165!  When you break the reg tests, we can reevaluate and update the benchmark. Shouldn't be a problem :smile:

@LRossman fixing the zero flow bug will be great! @michaeltryby, maybe a stupid question, but do you already implement a different reg test for 2.1 vs 2.0, or otherwise put, does 2.1 give different numerical results to 2.0 under all or certain conditions?

@lxsinske you can find benchmarks here The current one is for EPANET v 2.012 VS 10 2010.

Updates were made to the getTmpName() in EPANET.C so that the 5 files that failed the initial regression test now produce identical link flow results with those found using EPANET 2.0.012, at least to the two decimal places displayed in the plain text report file, using a 32-bit build under Visual Studio 2017. Also some housekeeping was made to FUNCS.C so that the comments align nicely.

@LRossman How was it that getTmpName() was causing the regression tests to fail?
Also, from the CI logs it looks like changing MAXFNAME totally broke automated testing.  The output_api I wrote has two harmless looking references to it, but it completely breaks all of the tests. Which is kind of interesting.

@michaeltryby I changed the definition of MAXFNAME to 260 instead of L_tmpnam_s (which isn't really needed here) so please try your automated testing again. Just to repeat, my comparison of flow results with those of 2.0.012 to two decimal places on the 5 files that failed the original test showed no differences using the VS 2017 32-bit compiler.

Changed MAXFNAME back to 259 and Visual Studio 2017 from 32 bit. All tests on Appveyor are in the green. This PR is good for merge.


Added default modulepath to puppet apply

Does this mean that we can't override where modules are?

you can still pass custom puppet_apply command and change conf as well as you like. There are no config options for apply command, you can only provide custom one.


high cpu consume when big sql execute

Please answer these questions before submitting your issue.

Why do you submit this issue?
[ ] Question or discussion
[ ] Bug
[ ] Requirement
[x] Feature or performance improvement

Question

What do you want to know?

Bug

Which version of SkyWalking, OS and JRE?

Which company or project?

What happen?
If possible, provide a way for reproducing the error. e.g. demo application, component version.

Requirement or improvement

Please describe about your requirements or improvement suggestions.
in Production Environment， we set the agent config with the parameter
：plugin.mysql.trace_sql_parameters= true ；
but when  insert batch records ，the skywalking take  high cpu consume，that make our application slower。Why to build the parameter take  high cpu consume？

@yogaling can you please describe how big the SQL is? Better to provide the complete SQL and parameters to help us diagnose the problem

Two things,

Long SQL statements mean more parameters, more parameters mean more interceptions happen, which cause CPU, and more memory means more CPU on GC.
Segment in the preparation stage before sending to the backend, it causes more resources(memory and CPU) and when sending happens, more network used.

People used to keep asking for tracing parameter, we always said, don't do that. But as people kept requesting, we added this as an option parameter. So people should consider why we don't put this as default.


Wrong table repo content on Accordion page

Component status table on the Accordion page still has Tabs component repo information.
https://ux.redhat.com/components/accordion/

This was fixed by commit d96e7ffd463a661ab8b42736e2b76aaa9a06d744.


building <go-1.16 fails with SIGKILL on M1/arm64 chipset

NB: this originated in trying to use moovweb/gvm to install older versions of Go on an M1 mac. If earlier versions of Go are not expected to build for GOOS=darwin GOARCH=arm64, please disregard.
What version of Go are you using (go version)?

$ go version
go version go1.16.2 darwin/arm64

Does this issue reproduce with the latest release?
No.

Completed build of go1.15.10
What did you see instead?

Building Go cmd/dist using /Users/spaetzle/sdk/go1.16.2. (go1.16.2 darwin/arm64)
Building Go toolchain1 using /Users/spaetzle/sdk/go1.16.2.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
warning: unable to find runtime/cgo.a
Building Go toolchain2 using go_bootstrap and Go toolchain1.
# cmd/cgo
ld: warning: -no_pie ignored for arm64
# cmd/asm
ld: warning: -no_pie ignored for arm64
# cmd/link
ld: warning: -no_pie ignored for arm64
# cmd/compile
ld: warning: -no_pie ignored for arm64
Building Go toolchain3 using go_bootstrap and Go toolchain2.
go tool compile: signal: killed
go tool compile: signal: killed
go tool compile: signal: killed
go tool compile: signal: killed
go tool dist: FAILED: /Users/spaetzle/src/go/pkg/tool/darwin_arm64/go_bootstrap install -gcflags=all= -ldflags=all= -a -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 1

Each failure produces a similar (albeit opaque) log in Console.app:
Mar 12 16:15:27 spaetzle com.apple.xpc.launchd[1] (com.apple.mdworker.shared.0E000000-0100-0000-0000-000000000000[57775]) <Notice>: Service exited due to SIGKILL | sent by mds[514]

This does seem similar to some of the details published in #42684, but that seemed to go in a different direction.

If earlier versions of Go are not expected to build for GOOS=darwin GOARCH=arm64, please disregard.

Go 1.16 is the first version of Go that adds support for Apple silicon. Go 1.15 and older versions don’t support it. Back then, GOOS=darwin GOARCH=arm64 was a way of targeting iOS. See https://golang.org/doc/go1.16#ports.
CC @cherrymui, @golang/release.

Thanks for the response. That's going to create increasing tension for developers buying or replacing equipment and still supporting non-bleeding-edge toolchains or libraries with native library CGO dependencies.
This is enough of a compatibility break that I would have expected to see some sort of documentation. Unfortunately, while the 1.16 release notes do mention the darwin->ios shift, they do not indicate that 1.15 and below will not be supported on the chipset, nor does the MinimumRequirements doc in this project's wiki reflect anything post-1.15.


Windows - Wallet doesn't react to GET_HEIGHT mining message after a block got accepted

WIndows, Wallet CLI 5.0.5 (master), Testnet 2
When mining against the wallet there are some rara cases that after establishing a connection the wallet doesn't react to GET_HEIGHT mining messages (the TCP pakets are there, controlled by wireshark). Only a reconnection to wallet solves this
Then there is the case that the wallet reacts normally to GET_HEIGHT with BLOCK_HEIGHT like expected. But after a block got submitted to the wallet (and an ACCEPT message have been received), the wallet doesn't react to GET_HEIGHT anymore (again on network the TCP pakets are there and also the ACK messages).
Only a reconnect to the wallet solves this

Thank you for reporting this, I'm redoing the notifications system currently (Users API is last to finish) so when this is complete I will be sure to let you know


meta-mender-nxp: add kirkstone support for Boundary Devices

Hi @chrisdimich,
Thanks for the integration refresh! Just having given it a quick skim yet, I noticed that the machine specific overrides in the local.conf.template still use the old syntax, and will supposedly not kick in. Is this intentional?
Greetz

@TheYoctoJester I was never managing those machines, so didn't worry about them. I only did this support for Boundary Devices. Is that okay?

Hi @chrisdimich yes I understand. I would like to give this a build check to make sure there are no syntax clashes, and then I'll merge. Is that okay with you? Will take a couple of days, I'm travelling at the moment, or do you have an immediate need to get it included?

No worries thanks! Whenever you get to it is fine. Appreciate the quick response!

@chrisdimich Needed a little sorting out in our repo but looks fine now, thanks. One minor observation:

the u-boot patches apply only with fuzz, a refresh would be good

@chrisdimich sorry to be nagging, but the Readme mentions

nitrogen8m
nitrogen8mm
nitrogen8mm (duplicate!)
nitrogen8mq
whereas in the head of the local.conf.append template and the corresponding/linked Mender Hub article only the nitrogen8m is mentioned.

Can you prepare a follow-up here to get those into a consistent state, maybe?
Greetz,
Josef

The kirkstone branch was indeed created after the PR. I will definitely carry the changes over.

@TheYoctoJester Thanks! Also sorry missed your note -> "the u-boot patches apply only with fuzz, a refresh would be good."
I will look into that.


build: introduce preconstruct

It allows use raw source code between modules without need to build each module (really useful to run verdaccio in debug mode and add break points without pain)
Generate ESM modules out of the box
Compatible with the current setup
Don't need to have script build on each package
Don't need to have .babelrc on each module

Checklist

[x] Integrate preconstruct
[ ] Clean up scripts
[ ] Clean up babelrc
[ ] Update docs contribute and how to use it

https://preconstruct.tools/tutorials/monorepo/

Unfortunately, I just realized preconstruct has few disadvantages for our setup:

In any mode include developer and production builds in the bundle, increasing 100% the current size for each package.
Uses rollup to bundle each module (no customizable)
Uses babel built-in voiding our dependencies
Cannot be customized.

It solves the issue to link development packages, but introduce others. Closing this idea, maybe in the future.


Automated daily update to rustc (to nightly-2024-07-31)

Automated update to Github CI workflow rust.yml by create-pull-request GitHub action

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

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

Totals

Change from base Build<PHONE_NUMBER>8:
0.0%

Covered Lines:
19656

Relevant Lines:
23621

💛  - Coveralls


Question regarding catching error on dispatcher or handling it in reducer with _REJECTED

I asked this question on stackoverflow, figured someone might see it here and may be able to help out.
Stackoverflow question

I just responded on SO. Thanks for asking the question! For future reference, I do get email notifications when people post questions on SO--not necessary to post in both places 😉


Fix changing kernels from kusto to other kernels

This PR addresses #15544.
Ensures that Kusto Notebook with language_info containing kusto still opens up with Kusto kernel properly.
Fixes when a user changes from Kusto (kernel alias) to another kernel by ensuring we update the language_info to use the selectedKernel language_info, and not the current kernelAlias.

@VasuBhog if you haven't already, please add an explicit test case for changing kernels in ADS. Seems like there are a few variables at play:

Changing from a kernel with an alias to one that doesn't have one (and vice versa)
Changing to another kernel in the same notebook provider
Changing to another kernel in a different notebook provider

Pull Request Test Coverage Report for Build 862036033

0 of 3 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.0007%) to 43.354%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql/workbench/services/notebook/browser/models/notebookModel.ts
0
3
0.0%

Totals

Change from base Build 861965722:
-0.0007%

Covered Lines:
26552

Relevant Lines:
55678

💛  - Coveralls

Adding @rajeshka here since he ran into this issue and wants to be notified once the fix is in.


fix: Handle primitive array data types

Relates to https://github.com/springwolf/springwolf-ui/pull/36


az aks check-acr: FAILURE - KeyError: 'serverVersion'

This is autogenerated. Please review and update as needed.
Describe the bug
**az aks check-acr --resource-group ih-aks --name *** --acr *.azurecr.io
Command Name
az aks check-acr
Errors:
The command failed with an unexpected error. Here is the traceback:
'serverVersion'
Traceback (most recent call last):
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 233, in invoke
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 663, in execute
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 726, in _run_jobs_serially
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 697, in _run_job
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 333, in __call__
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/command_operation.py", line 121, in handler
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/acs/custom.py", line 1294, in aks_check_acr
KeyError: 'serverVersion'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az aks check-acr --resource-group {} --name {} --acr {}

Expected Behavior
Environment Summary
Windows-10-10.0.22000-SP0
Python 3.10.5
Installer: MSI

azure-cli 2.41.0

Extensions:
azure-devops 0.22.0
ssh 1.0.0

Dependencies:
msal 1.20.0b1
azure-mgmt-resource 21.1.0b1

Additional Context

@ryanbick The command internally calls kubectl version -o json. Could you run this command and share its output?

What application or tool is the version difference warning referring to?
{
"clientVersion": {
"major": "1",
"minor": "25",
"gitVersion": "v1.25.0",
"gitCommit": "a866cbe2e5bbaa01cfd5e969aa3e033f3282a8a2",
"gitTreeState": "clean",
"buildDate": "2022-08-23T17:44:59Z",
"goVersion": "go1.19",
"compiler": "gc",
"platform": "windows/amd64"
},
"kustomizeVersion": "v4.5.7",
"serverVersion": {
"major": "1",
"minor": "23",
"gitVersion": "v1.23.8",
"gitCommit": "e18a4970ca206398e987600929fec300cb85d0ca",
"gitTreeState": "clean",
"buildDate": "2022-09-16T05:13:38Z",
"goVersion": "go1.17.11",
"compiler": "gc",
"platform": "linux/amd64"
}
}WARNING: version difference between client (1.25) and server (1.23) exceeds the supported minor version skew of +/-1
------- Original Message -------
On Thursday, October 13th, 2022 at 1:42 PM, Pramod Valavala @.***> wrote:

@.***(https://github.com/ryanbick) The command internally calls kubectl version -o json. Could you run this command and share its output?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Also, here is the full output with the first few lines also included.
PS C:\Users\Ryan> kubectl version -o json
W1013 13:57:01.702272 8356 azure.go:92] WARNING: the azure auth plugin is deprecated in v1.22+, unavailable in v1.26+; use https://github.com/Azure/kubelogin instead.
To learn more, consult https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins
{
"clientVersion": {
"major": "1",
"minor": "25",
"gitVersion": "v1.25.0",
"gitCommit": "a866cbe2e5bbaa01cfd5e969aa3e033f3282a8a2",
"gitTreeState": "clean",
"buildDate": "2022-08-23T17:44:59Z",
"goVersion": "go1.19",
"compiler": "gc",
"platform": "windows/amd64"
},
"kustomizeVersion": "v4.5.7",
"serverVersion": {
"major": "1",
"minor": "23",
"gitVersion": "v1.23.8",
"gitCommit": "e18a4970ca206398e987600929fec300cb85d0ca",
"gitTreeState": "clean",
"buildDate": "2022-09-16T05:13:38Z",
"goVersion": "go1.17.11",
"compiler": "gc",
"platform": "linux/amd64"
}
}WARNING: version difference between client (1.25) and server (1.23) exceeds the supported minor version skew of +/-1
------- Original Message -------
On Thursday, October 13th, 2022 at 1:55 PM, Ryan Bick @.***> wrote:

What application or tool is the version difference warning referring to?
{
"clientVersion": {
"major": "1",
"minor": "25",
"gitVersion": "v1.25.0",
"gitCommit": "a866cbe2e5bbaa01cfd5e969aa3e033f3282a8a2",
"gitTreeState": "clean",
"buildDate": "2022-08-23T17:44:59Z",
"goVersion": "go1.19",
"compiler": "gc",
"platform": "windows/amd64"
},
"kustomizeVersion": "v4.5.7",
"serverVersion": {
"major": "1",
"minor": "23",
"gitVersion": "v1.23.8",
"gitCommit": "e18a4970ca206398e987600929fec300cb85d0ca",
"gitTreeState": "clean",
"buildDate": "2022-09-16T05:13:38Z",
"goVersion": "go1.17.11",
"compiler": "gc",
"platform": "linux/amd64"
}
}WARNING: version difference between client (1.25) and server (1.23) exceeds the supported minor version skew of +/-1
------- Original Message -------
On Thursday, October 13th, 2022 at 1:42 PM, Pramod Valavala @.***> wrote:

@.***(https://github.com/ryanbick) The command internally calls kubectl version -o json. Could you run this command and share its output?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

@ryanbick The version difference is between client (kubectl) and server (k8s).
I wasn't able to reproduce this issue locally. Since you are running this on Azure CLI, could you confirm if you are seeing the same locally?


Checkstyle should execute cleanly prior to publish

Ref #80 -  Once checkstyle merges, we need to make sure it runs clean.

See updated workitem in #92


Batches? Chords? Workflows?

Is there anything on the roadmap for a scatter/gather feature? I have tasks that currently use the chord feature of Celery which is where you spin up a bunch of tasks and get a callback with the results of each as an array when they are done.
Is this something you are thinking of or maybe even already done and I just missed it?

You can find a conversation about workflows in #1198.
As you can read from that issue, there is nothing out of the box.
Work is underway to release a new major version but that doesn't include anything related to workflows.

closing in favor of https://github.com/procrastinate-org/procrastinate/issues/1198


documentation typos

Coverage remained the same at 83.189% when pulling 512846cc7b72374e4220ca8445890458867f92d2 on bdrehmer:master into fe6afd10b33a228915701ccc4af786cbdc08d0a9 on maidsafe:master.

Coverage remained the same at 83.189% when pulling 83a1faccfc42362a35ae5f59bf39ddf5dc0d0d25 on bdrehmer:master into bac5b5c4075e86aef23399923ce43449575c86a2 on maidsafe:master.


Use gulp-ng-annotate to auto-annotate dependency names

Closes #85 and fixes #80

@vlandham @domoritz Please give this a shot and let me know whether the minified build works for you. As with #85, this can be tested by

Building vega-lite-ui
Changing the bower.json file in vega-lite-ui to specify "vlui.min.js" as its "main" js file
Restarting voyager (assuming voyager is bower-linked to vlui)
Confirm that vlui.min.js is being loaded in voyager
Confirm that voyager works as expected

Hmm, I'm having some issues with missing vl. Will investigate.
On Oct 1, 2015 09:31, "K.Adam White"<EMAIL_ADDRESS>wrote:

Assigned #86 https://github.com/vega/vega-lite-ui/pull/86 to @domoritz
https://github.com/domoritz.
—
Reply to this email directly or view it on GitHub
https://github.com/vega/vega-lite-ui/pull/86#event-424424629.


ubuntu/openssl needs work

CVE-2022-2097    │ ubuntu/openssl     │                     │ 1.1.1f-1ubuntu2.8          │ 3.0.5-2ubuntu1

║ CVE-2019-1551    │ ubuntu/openssl                 │                     │ 1.1.1f-1ubuntu2.16         │ 1.1.1.e
Image: adoptopenjdk
We need the vulnerability start location or distro detection to reduce these false positives. Range detection is a PITA for ubuntu.

Let's keep this open and live with some percentage of false positives for ubuntu for now.


Unable To Receive Multicast Packets/Join Multicast Group

I am unable to receive UDP packets sent on the default multicast address (<IP_ADDRESS>).
Using the sendto() command - though I receive the Err 2FewArgs error - I am able to send UDP packets to the multicast address and have them received by a Java based client.
The problem comes when receiving multicast packets on the Arduino/WiFly module.
I have looked through the provided doxygen and found no reference - maybe I am missing something - but I think there needs to be some way of joining the multicast group.
For clarity, my Arduino code:
#include <SoftwareSerial.h>
SoftwareSerial wifiSerial(8,9);//RX, TX
#include <WiFlyHQ.h>

WiFly wifly;

const char   mySSID[]         = "SSID";
const char   myPassword[]     = "Pass";

void setup()
{
    char buf[64];
    Serial.begin(115200);
    Serial.println("Starting sketch Proc UDP");

    wifiSerial.begin(9600);
    if (!wifly.begin(&wifiSerial, &Serial))
    {
        Serial.println("Failed to start wifly");
    }

    Serial.println("Joining network");
    wifly.setSSID(mySSID);
    wifly.setPassphrase(myPassword);
    wifly.enableDHCP();

    if (wifly.join())
    {
        Serial.println("Joined wifi network");
    }
    else
    {
        Serial.println("Failed to join wifi network");
    }

    Serial.println("WiFly ready");

    Serial.print("IP: ");
    Serial.println(wifly.getIP(buf, sizeof(buf)));
    Serial.print("Netmask: ");
    Serial.println(wifly.getNetmask(buf, sizeof(buf)));
    Serial.print("Gateway: ");
    Serial.println(wifly.getGateway(buf, sizeof(buf)));

    Serial.println("Set DeviceID");
    wifly.setDeviceID("Wifly-UDP-Rec");
    Serial.print("DeviceID: ");
    Serial.println(wifly.getDeviceID(buf, sizeof(buf)));

    wifly.setIpProtocol(WIFLY_PROTOCOL_UDP);
}

int count = 0;
void loop()
{
    if(wifly.available() > 0)
	{
		int EoL = 0;
		String s;
		while(wifly.available() > 0) //EoL == 0)//while(wifly.available() > 0)
		{
		  if(wifly.available() > 0)
		  {
			  char rec = wifly.read();
			  if(rec != '\n')
				s += rec;
			  else
				EoL = 1;
    		  }
		}
		EoL = 0;
		Serial.println(s);
	}
    Serial.println(wifly.available());
}

UDP packets sent on the local subnet broadcast (in my instance, <IP_ADDRESS>) are received and displayed as exptected.
When sent to <IP_ADDRESS>, however, wifly.available() only returns 0.
Other clients are able to receive the packets when sent on Multicast, so I know that they are being sent.

I can't find any reference to multicast support in the WiFly's data sheet or user guide.  It's possible it does not support it.  I'll try some experiments.

I can't remember where I found clarification but the chips, it turns out, do not support multicast. This issue can now be closed.
Many thanks for the reply after this time.


Idea. Setting classes packable via inheritance/implementation.

Additional to marking class for MemoryPack source generation, it may be handy to do the same with interface implementation or other class inheritance. We mark a class/interface with a, for example, "PackCascade" attribute and then all its heir/implementing types will be treated as though they are marked with the "MemoryPack" attribute.
The reasoning for usefulness of this feature is that:

adding an attribute to a type is somewhat less usual and natural action - compared to inheritting/implementing.
creating hierarchy of types with one root will allow to generalize the types, that are MemoryPackable, giving options to weave logic around that info. Adding extensions, creating wrappers for those types, adding constraints to type arguments - all those capabilities are vital if one ever wants to write abstract code with packable types.

I could help making the thing, but I'm new to community coding, so any guide on how to deliver the code changes to this specific project I'd much appreciate.

Thanks for the suggestion.
I can't really imagine its usefulness, so it would be great if you could show me some pseudo code.

Thanks for the suggestion. I can't really imagine its usefulness, so it would be great if you could show me some pseudo code.

Here you are.
All the idea will work only in .net 7+.
`
class CacheManager // Ability to have something like this class is the main goal of the suggested feature
void PutToCache(byte[] info) => /implementation/
byte[] GetByKey(object key) => /implementation/
public void Put<T>(object key, T item) where T : IPackable // for super-efficient outer-service cache storage this service should accept only MemoryPackable types - and alas we cannot set the requirement like 'HasAttribute<MemoryPackable>'
{
    var infoCached = item.ToByteArray();
    PutToCache(infoCached);
}
public T Get<T>(object key) where T : IPackable<T>
{
    var infoCached = GetByKey(key);
    return T.FromByteArray(infoCached);
}

/*
The two public methods demostrate how elegantly we do the type guessing logic at compile type + have to write less code for it.
*/

[PackCascade]
partial interface IPackable // Interface name here is arbitrary - it will a parameter on the source generation step
// With creating different interfaces we allow ourselves to create different scopes for deserialization.
// For example, here we introduced IPackable and created logic around its types. If we add, say, ISendable the logic will be separate and ISendable and IPackable won't cross.
partial abstract class Entity : IPackable // now we treat the class and its heirs as if they had "[MemoryPackable]" above it.
public long Id { get; }
partial class PersonInfo : Entity
public string FirstName { get; set; }
public string LastName { get; set; }
partial class EmployeeInfo : PersonInfo
public long[] ResponsibleForOrders { get; set; }
partial class Order : Entity
public long ResponsibleEmployeeId { get; set; }

Generated code.
partial interface IPackable
byte[] ToByteArray();
partial interface IPackable : IPackable // new interface with awareness of the implementing type - for deserizliation purposes
static abstract TSelf FromByteArray(byte[] bytes);
partial abstract class Entity
public abstract byte[] ToByteArray(); // if class is abstract then interface implementation has to be abstract too.
byte[] IPackable.ToByteArray() => ToByteArray();
// Generate the standard code for MemoryPackSerializer for PersonInfo here
partial class PersonInfo : IPackable
public static PersonInfo FromByteArray(byte[] bytes) => MemoryPackSerializer.Deserialize(bytes);
public override byte[] ToByteArray() => MemoryPackSerializer.Serialize(this);
// Generate the standard code for MemoryPackSerializer for EmployeeInfo here
partial class EmployeeInfo : IPackable
public static EmployeeInfo FromByteArray(byte[] bytes) => MemoryPackSerializer.Deserialize(bytes);
public override byte[] ToByteArray() => MemoryPackSerializer.Serialize(this);
// Generate the standard code for MemoryPackSerializer for Order here
partial class Order : IPackable
public static EmployeeInfo FromByteArray(byte[] bytes) => MemoryPackSerializer.Deserialize(bytes);
public override byte[] ToByteArray() => MemoryPackSerializer.Serialize(this);`

I have a feeling that this is within the scope of what you can devise on your application side.
If you prefer generics, there is IMemoryPackable<T>.


Support for multi namespace stern

Stern currently supports --all-namespaces, but sometimes it is required to tail logs from multiple namespaces (not all namespaces) in a cluster with a number of namespaces. Support for a comma-separated namespace list for --namespace would be ideal.

Hey @ramesh-tr
This repository is no longer maintained : https://github.com/wercker/stern/issues/148
And we already implemented this in the new one https://github.com/stern/stern/pull/113
👍


Dns documentation is showing even if it's not supported

Documentation site should not show the DNS documentation when the Stork version prior to 1.2.0 is selected in the drop-down menu. Users think that dns is present while it was introduced in 1.2.0 version

Fixed by editing the files manually...


Time difference based on process.uptime()

Hello!
Would be nice to have the time difference be based on process.uptime() so it acts more like the real performance.now on the first call.
With electron I was getting values all over the place because of this difference.
The problem (exaggerate for the sake of it)
Before this require there could be async code, legacy code or just a black box to which you don't have access to require the library earlier.
setTimeout(() => {
    let now = require("performance-now");
    console.log(now());
}, 2000);

The result should be 2000+ ms
Currently that would log, on my machine 19.633549 ms.
The solution
Rewriting it as follows (sorry, no CoffeeScript) I've been able to get the expected output of 2000+ ms
const loadTime = process.hrtime();
const upTime = process.uptime();

// Get elapsed seconds
const seconds = Math.floor(upTime);
// Get the remaining milliseconds and cast to nanoseconds
const nanoseconds = (upTime - seconds) / 1e6;

loadTime[0] -= seconds;
loadTime[1] -= nanoseconds;

const getTime = () => {
    let hr = process.hrtime(loadTime);
    return (hr[0] * 1e9 + hr[1]) / 1e6;
};

module.exports = getTime;

All it actually does is remove the elapsed time between the process.uptime and the process.hrtime call.

N.B. The solution above does not take into consideration the Date fallbacks.
Cheers,
Pupix

Good call on using process.uptime. At the time I wrote this module, I wasn't aware of this function at all.
I've added some extra tests using isolated processes, in order to test the various scenarios in which this module could be used.
I've just published version 2.0.0 which should do exactly what you want. Version 1.0 will keep functioning as before.

Thanks!


Smart Network Type detection logic (for Windows and maybe others)

Unfortunately the API we've been historically using on Windows:
https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetgetconnectedstate
is deprecated, should not be used, and may cause other unintended side-effects..
Thus, it's been removed from code by #288
Alternate recommended approach is Note  Using this API is not recommended, use the INetworkListManager::GetConnectivity method instead. ... However, there are some challenges with that one too:

on a system with multiple network interfaces - it is hard to tell what interface is gonna be used for routing packets to collector. Proper solution has to know what interface is being used for what URL (other OS, like Apple OS, may have API for that already).

it is not always possible to differentiate WiFi (as in AP to internet provider) vs. WiFi Hotspot (as in AP to your WWAN / data plan).

Windows.Networking.Connectivity.NetworkInformation.GetInternetConnectionProfile() is unique to WinRT, and historically had its own challenges.

There is no good answer to how to tackle this issue at this time. Thus, SDK on Win32 is now returning Network Type as UNKNOWN, until we come up with a consistent answer. Keeping this work item as "Enhancement" in our backlog.

Network Detection module?

or maybe it just belongs as part of a PAL module, if that ends up being something that's exposed

#109


[BUG]: Pen Drawing not working after selecting Shapes

Describe the bug
unable to write with pen after we select shapes, even after clicking on pen leads to drawing of previous selected shape only.
To Reproduce
Steps to reproduce the behavior:

Go to 'website'
Click on 'pen' and draw
Now select any 'Shape' use it
Now again try to use pen
See error

Expected behavior
Pen features not lost even after selecting other shapes to draw.
Screenshots
https://github.com/singodiyashubham87/Draw-it-out/assets/115262737/3d812c57-aa0e-4f13-9bdf-70336a2ec061
Desktop (please complete the following information):
-OS : Windows
-Browser: MicrosoftEdge

@Prithwi32 Assigned you the issue, Best of Luck :)

@Prithwi32 Any updates?

@Prithwi32 Any updates?

@singodiyashubham87 hello...I will do that is soon...
I was busy with hackthon

@Prithwi32 Try to resolve it ASAP or else tell me, and I'll assign it to the next interested contributor.

@Prithwi32 Try to resolve it ASAP or else tell me, and I'll assign it to the next interested contributor.

Okay sure
.... sorry for delay 🥲

@Prithwi32 Try to resolve it ASAP or else tell me, and I'll assign it to the next interested contributor.

Okay sure .... sorry for delay 🥲

I will complete by next 2days

@Prithwi32 Good Luck :)

@singodiyashubham87 made PR check it out..Thank You!


Type of successCallback parameter on SignoutCallbackComponent should be SignoutResponse not User

I noticed that SignoutCallbackComponent is setting the type of the successCallback parameter to User when it should be SignoutResponse. The two are similar with the same state key in the object but SignoutResponse has a different shape otherwise.
SignoutReponse: https://github.com/IdentityModel/oidc-client-js/blob/dev/src/SignoutResponse.js
User: https://github.com/IdentityModel/oidc-client-js/blob/dev/src/User.js

Found it: https://github.com/maxmantz/redux-oidc/blob/master/index.d.ts#L21-L34
So problem is CallbackComponentProps is used for both callback types but it has readonly successCallback: (user: User) => void; and for SignoutCallbackComponent it should be readonly successCallback: (response: SignoutResponse) => void;.


Getting an error for posting the plan in the PR

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply \"tfplan\"
" "0"
INFO: Looking for an existing plan PR comment.
curl: (16) Error in the HTTP2 framing layer
INFO: No existing plan PR comment found.
INFO: Adding plan comment to PR.
curl: (16) Error in the HTTP2 framing layer

- name: Post Plan
  if: always() && github.ref != 'refs/heads/master' && (steps.plan.outcome == 'success' || steps.plan.outcome == 'failure')
  uses: robburger/terraform-pr-commenter@v1
  with:
    commenter_type: plan
    commenter_input: ${{ format('{0}{1}', steps.plan.outputs.stdout, steps.plan.outputs.stderr) }}
    commenter_exitcode: ${{ steps.plan.outputs.exitcode }}
  env:
   GITHUB_TOKEN: ${{ secrets.GOOGLE_CREDENTIALS }}

Am I missing something?

@robburger ^


STY: Apply pyupgrade suggestions

Changes proposed in this pull request
pyupgrade --py310-plus
Also manually change a few .format() calls to f-strings.

I want to hold off on this until the full release, then we'll probably just do what we're doing over in smriprep. We can take care of pyupgrade, flake8, and all that in a single PR.

I think this should be covered by ruff now.

Not entirely. For example, switching to f-strings is not covered by ruff (pyupgrade rules).

Ah, do you want to go ahead and re-upgrade? Note that wrapper/ needs to be excluded, since we're still maintaining Python 2.7 compatibility for that package.

Let me have a look first:

exclude wrapper
perhaps add other ruff rules that may be associated to the pyupgrade suggestions


Serializer.deserialize restricted to handling of Integers and Strings

using byte values in CoAP options can lead to conversion errors.
E.g. using the ETAG option which is considered to contain an OPAQUE content, is forced to be converted to a string which ends up in

UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128)

Yes, you are totally right. I have to find a better way for that. If you want to contribute in such sense you are more than welcome :D

Could you provide e an example of such behaviour? Because I think the problem is raised only when you try to print such parameters, but at least for the ETAG option everything works fine in my environment.

This is a minimal testcase that shows the behavoir:
class SimpleTests(unittest.TestCase):

    def test_utf_deserialize(self):
        req = Request()
        req.type = defines.Types["CON"]
        req._mid = 1
        req.etag = bytearray([0xc5])

        serializer = Serializer()
        serialized = serializer.serialize(req)
        received_message = serializer.deserialize(serialized, ("<IP_ADDRESS>", 5683))

        self.assertEqual(req.etag, received_message.etag)

It fails with:
Error
Traceback (most recent call last):
  File "/home/daniel/coapthon/CoAPthon/tests.py", line 94, in test_utf_deserialize
    received_message = serializer.deserialize(serialized, ("<IP_ADDRESS>", 5683))
  File "/home/daniel/coapthon/CoAPthon/coapthon/serializer.py", line 95, in deserialize
    option.value = Serializer.convert_to_raw(current_option, value, option_length)
  File "/home/daniel/coapthon/CoAPthon/coapthon/serializer.py", line 281, in convert_to_raw
    return bytearray(value, "utf-8")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 0: ordinal not in range(128)


Multi-GPU training results in RuntimeError

I am trying to run the example training script run_ppo.sh in order to train a ppo agent on mulitple GPUs. However, I am getting a RuntimeError in line 288, in update_actor_critic loss.backward():
RuntimeError: Expected to mark a variable ready only once. This error is caused by one of the following reasons: 1) Use of a module parameter outside the forward function. Please make sure model parameters are not shared across multiple concurrent forward-backward passes. or try to use _set_static_graph() as a workaround if this module graph does not change during training loop.2) Reused parameters in multiple reentrant backward passes. For example, if you use multiple checkpoint functions to wrap the same part of your model, it would result in the same set of parameters been used by different reentrant backward passes multiple times, and hence marking a variable ready multiple times. DDP does not support such use cases in default. You can try to use _set_static_graph() as a workaround if your module graph does not change over iterations.
arameter at index 14 has been marked as ready twice. This means that multiple autograd engine  hooks have fired for this particular parameter during this iteration. You can set the environment variable TORCH_DISTRIBUTED_DEBUG to either INFO or DETAIL to print parameter names for further debugging.
The code is executed on three GeForce GTX TITAN X GPUs. I have run the training script with --gpu-ids 0 1 2
I am very new to CUDA and multiprocessing in pytorch. I would appreciate assistance in debugging this issue. Let me know if you need further information.

Could you post the command you used here? Are you using a custom implementation?

This is caused by find_unused_parameters=True where the PPO gaussian head's std parameter is unused during agent forward (and thus marked as ready for DDP reduce purposes), but it actually has gradients when performing agent updates, which DDP is not aware of. For now you can remove the find_unused_parameters=True in L302 of maniskill2_learn/utils/torch/module_utils.py to train PPO (though, find_unused_parameters=True is necessary when training SAC).

Now we pushed a fix, should work for PPO

Thank you. With find_unused_parameters=False it works.
I have another question concerning that flag. If I use find_unused_parameters=False with SAC, will it actually change the outcome of the training, meaning the success rate and other KPIs, or will that only affect training performance in terms of training time? I would like to keep the flag set to false for all cases, just to not mess with the inner workings of the library all the time and potentially altering performance without deliberately wanting to.


The Short Explanation Cover more details about R. But i Would Suggest one Thing Please Add Module about how to Integrate with SQL And Asp.Net Website.

[Enter feedback here]

The Short Explanation Cover more details about R.
But i Would Suggest one Thing Please Add Module about how to Integrate with SQL And Asp.Net Website.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: dde63717-000d-d97c-0898-36c005d8541f
Version Independent ID: 4c63fc76-7fac-4e58-cca7-e8476cb1248f
Content: Getting started with R Tutorial - Visual Studio
Content Source: docs/rtvs/getting-started-with-r.md
Product: visual-studio-dev15
Technology: vs-rtvs
GitHub Login: @kraigb
Microsoft Alias: kraigb

Thanks for the suggestion. However, because R Tools for Visual Studio is no longer supported in Visual Studio 2019 (in favor of Azure Notebooks), the R docs for Visual Studio 2017 are no longer being actively updated or improved except for critical fixes. I'm sorry to bear such news, because I appreciate the suggestion, but the reality is that we won't be following up with this issue further.


Process events without second thread to get trid of deadlocks

An attempt to remove threading and complex locking logic when processing events.
Not necessarily a final solution, but want to discuss this way of doing things.

Can one of the admins verify this patch?

I suspect your issue is probably resolved with 9ed32e3b5e48a5da1fc4ba21634d95a1b913457c.

I've been running 1.4.1 over night and it seems to solve the deadlock issue! 👍
I still don't see why we need an extra thread. Very easy to make mistakes on a important piece of software.

I can see that. Another approach could be to put the events on a queue (https://docs.python.org/3.5/library/queue.html) in the main thread, and in a separate thread have simple processing loop that reads from the queue. That would at least get rid of much of the locking logic.
That said, 1.4.1 is still going strong, so the deadlock seem to be gone.

Closing this as I don't have the time to look at it for a couple of weeks.


gitea: 1.14.3 -> 1.14.4

Motivation for this change
ChangeLog: https://github.com/go-gitea/gitea/releases/tag/v1.14.4
Things done

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

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 129446 run on x86_64-darwin 1

1 package built:

gitea

Just a bug fix release and the tests are passing, I think we are good to merge.
If the maintainers feel I'm being too forward here, let me know and I'll wait next time.


Used the function terminategracefully instead of brutally stop a process

I replaced the cmd.Process.Kill() with the function terminateProcessGracefully in order to give the opportunity to the process to do some clean up before closing

That function does not work properly. There is a reason I do not use it

Can you let me know how to test that it is not working? Since I would like to have the possibility to kill gracefully my process and have it in the code without the need to correct the code at every version. I would like to see if I will be able to fix it


Enable opaque backgrounds

Transparent pngs do not work well with image viewers that have a dark background.
Due to the InvertDraw code, we cannot enable it at the original canvas creation time.
Perhaps should there be an option to set the background color as well?

@reportingissue Thank you.
Is it common for people to stack images with transparent background, during label design?

@reportingissue Thank you. Is it common for people to stack images with transparent background, during label design?

@YipingRuan
When you refer to images, I assume you mean pngs, jpgs, etc... created outside Zebra's environment. I can only speak for our use case (shipping & warehousing) and our customer's (retail & food), but the answer to that would be no.
The most common cases of "stacking" happens most often when there is a logo that is not rectangular (ex. circular logo), and people try to take advantage of the empty corners to put in other content. To note, this is almost always done with ZebraDesigner.
The other common case of stacking happens when we have overflowing text due to miscalculations.


Clip path of polygon to screen rect

Clips the path of the polygon to the screen-rect. I couldn't find any negative side-effect of this approach. Note that it only uses the improvement for >= KITKAT due to Path.Op.
For my application, which uses two polygons spanning the whole map, it increases the performance from ~15fps to ~55fps.
Issue: https://github.com/osmdroid/osmdroid/issues/933

Congratulations for improving the performances! I guess I could have used Path.Op in SegmentClipper. Perhaps to be used in #857.
My remarks regarding the code: I would instantiate clipPath once in order to avoid an Object creation in the UI thread (draw).
Could this work also with Polylines?
Unfortunately we have no way to unit test Polygons, and I'm not able to test this push.
My other concerns are that there might be side-effects:

when map orientation is different from 0, as the clip rect you use always has smaller dimensions than the oriented version. A solution would be to consider the clip path to be a circle centered on the clip rect center, with a radius of max(width, height) / 2
with the path outline border, for instance if the path outline border is 10px wide, don't you display it when the path is a rectangle [-101, -101, 601, 1101] and the clip rect is [0, 0, 500, 1000] (expected result: no path border displayed)

We already tried this Path.op clipping solution: see #353 full thread.
We got a working solution, handling properly map rotation by clipping with: mapView.getIntrinsicScreenRect(mClipRect)
But I also got very (very) bad performance when using the emulator, so I gave up.
Before pushing your commit in the main branch, I think it must be tested extensively (HW acc. on and off, devices and emulators, various API levels).

@Maradox Given the recent tremendous improvements of Polygon/Path drawing performances (that also include the notion of "clip rect"), the previous unsuccessful tests in #353 and the code conflicts with the up-to-date version, it makes sense to close this pull request, I'm afraid.
Please feel free to run performance tests on Polygons/Paths with the latest osmdroid code, and, if needed, to create a new pull request that would include code that uses the Path.Op you suggested, but only as an option (that wouldn't be the default mode).


NetSparkleUpdater.UI.Avalonia nuget package not working out of the box

When I add the NetSparkleUpdater.UI.Avalonia nuget package to my project and it tries to open the UpdateAvailableWindow it throws the following exception:

System.IO.FileNotFoundException: 'Could not load file or assembly 'Avalonia.HtmlRenderer, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.'

The workaround is to install the Avalonia.HtmlRenderer nuget package (https://www.nuget.org/packages/Avalonia.HtmlRenderer/).
I would expect that the nuget package has a dependency to the Avalonia.HtmlRenderer nuget package. On the other hand I see a specific version of the library being included in the lib folder. Another option could be to include that library in your nuget package.
Personally I would go for the first option, to keep things inline with the Avalonia project.

Thank you, @FRvanderVeen! The nuget package for Avalonia.HtmlRenderer is new as of 6 days ago, so you're right -- no need for a custom-built version now. I've updated the project to use the NuGet reference.
This is rolling out in CI/CD as a preview version now.


Jetson nano gets power off itself!

Hi @dusty-nv ,
since 2 days my second jetson nano board going to power off itself.
now when I run detectnet-camera app the board suddenly gets power off itself.
I can provide you the logs if you want to run any cmd on the board.
please advise.
kind note:
I didnt face any similar issue in my first jetson nano board.

I also meet the same problem! When I run the detectnet.py, the nano suddenly gets power off itself.

I also meet the same problem! When I run the detectnet.py, the nano suddenly gets power off itself.

Hi @azyslzp , try running your board in 5W mode:   sudo nvpmodel -m 1
If it no longer powers off, it means your power supply isn't consistently delivering enough current for the 10W mode.

Thanks! It is worked after changing the DC power to 5V-4A


[FLINK-11145] Allow for override of HADOOP_VERSION for single variant binary release build

I discovered that when adopting the script for our internal builds.
Also should the Hadoop version numbers be adjusted in the elif [ "$SCALA_VERSION" != none ] && [ "$HADOOP_VERSION" == "none" ] block?

What is the purpose of the change
(For example: This pull request makes task deployment go through the blob server, rather than through RPC. That way we avoid re-transferring them on each deployment (during recovery).)
Brief change log
(for example:)

The TaskInfo is stored in the blob store on job creation time as a persistent artifact
Deployments RPC transmits only the blob storage reference
TaskManagers retrieve the TaskInfo from the blob cache

Verifying this change
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (100MB)
Extended integration test for recovery after master (JobManager) failure
Added test that validates that TaskInfo is transferred only once across recoveries
Manually verified the change by running a 4 node cluser with 2 JobManagers and 4 TaskManagers, a stateful streaming program, and killing one JobManager and two TaskManagers during the execution, verifying that recovery happens correctly.

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

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

Documentation

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

@zentol PTAL - with fix for the version duplication


Compatibility with Ruby 3.2

Ruby 3.2 removes the alias File.exists? in favor of File.exist?

Since I see the old dates of other PRs, is there any chance to get this PR merged? Thank you!

Would love to see this merged.

In the mean time this gem is an easy workaround.
https://github.com/Largo/file_exists

Hi @alexspeller, is there any chance you would merge this and release a new version?

Would love to see this merged as well 🙏

It seems this is a still maintained fork of this that is ruby 3.2 compatible https://github.com/mvz/non-digest-assets


feat: new socket layer

Todo:

[ ] Send notify
[ ] Send Reliable
[x] Pool buffer
[ ] handle invalid packets

Future:

[ ] multithread support
[ ] validate new connections

[ ] key/phrase
[ ] hashcash

Resources:

https://github.com/fholm/StreamTransport/commit/b1279cbda85c8aa6759493b3c3a074b014cec7ea
https://github.com/phodoval/Mirage/commit/7db8f5128119499505b4783511d0b174cfb2dde6
Reliable messages https://gafferongames.com/post/reliable_ordered_messages/
More on handling connections: https://gafferongames.com/post/client_server_connection/

[ ] remove BatchSendQueue
[ ] remove PeerUpdater
[ ] split up acksystem.cs
[ ] doc comments for Connection.cs
[ ] move connection state to enums? or split up enums
[ ] IDataHandler rename to receive packet

[ ] document what a packet is

[ ] ISocket fix doc comment
[ ] ISocket add doc comment for close
[ ] is packet.cs worth it?
[ ] improve comment in SocketCreator
[ ] unit test for bufferpool?
[ ] unit test for ConnectKeyValidator


Add prow postsubmit jobs that run all CI jobs against main + release branches

We have periodics that run every few hours. Probably good enough for now. Can reopen if needed


change cursor drawing to be time based

fixes an issue for the emulator where the cursor rapidly flashed as it runs on hardware faster than an ESP32

Fixes #31