Fixed bug when reading gps coordinates in the southern and eastern hemispheres

I found a bug while using the library. The Teltonika docs are worded poorly, you must not read the gps coordinates as an unsigned 32 bit integer and than check the first bit but rather interpret it from the start as a signed 32 bit integer.

I searched for other implementations and that seems to be the case, just to be sure can you write a test case against this yourself or, in alternative, give me a packet dump (hex string or binary file should be fine) so i can add the test myself before publishing.
In any case thank you very much for pointing out the issue.

I will do so, I have one done internal testing so far at my company and it seems to be giving the correct coordinates but when I have a chance I will send you a test case


Half CPU usage

I'm not sure if this is an issue or not, but a guy introduced me this program and it works really great. However, the program only uses half of my CPU, an I7 4770k. He told me that the program constantly uses 100% of his CPU (i5-3570K). So, problem with Hyper Threading? I don't know, just submit the problem here.

CPUの使用率が約50%に見えるのは表示だけで、実際の使用率は約100%近くだと思います。
CaffeやOpenBLASの内部を詳しく見たわけではないので推測ですが、計算の並列化は論理コア数ではなく物理コア数に対応するように行っていると思われます。（Hyper Threadingを有効にすると計算速度が遅くなるらしいので）
Core i7-4770Kは物理コア数4、 論理コア数8なので、プログラム実行時に「リソース　モニター」で各CPUの使用率を見ると、4つのCPUの使用率が約100%、残り4つのCPUの使用率が約0%になっていると思います。(プログラムのCPU使用率はこれらの平均の約50%と表示される)

I think Task Manager read the CPU usage correctly. When running 1x Waifu x2, I was able to do various task easily, and the fan is not loud, due to 50% CPU not being used. Also, I was able to get CPU usage to 75% by running 2x Waifu x2 at the same time. :smile: Anyway, nice program. Much better in upscaling than Photoshop. :+1:

すいません、CPUを使い切れていないのはCaffeの仕様か、僕の使い方が悪いせいのようですね…
現状では仕様ということにしておいてください。

Ok. I will provide an update if I can buy an i7 6900k (not even out yet) later :D

@ffleader1 it's a hyperthreading quirk. The CPU of your friend doesn't support hyperthreading at all (I checked the specs) so the Windows task manager shows all of his 4 CPU cores in use (100%). On your hyperthreading-capable CPU, however, it doesn't differentiate between the 4 cores and the 4 ht extensions (8 in total), so it looks like you're only using 50%.

Ok. After using the program for a while, I have some feedback.

The %CPU use for **Hyper Threading **depends on the number of Window of Waifu x2.

1 Wifefu x2 Running: 50% CPU usage
2 Wifefu X2 Running at the same time: 75% CPU usage (37.5% each)
3 Wifefu X2 Running at the same tine:  87.5% CPU usage (29.2% each)
So I guess there is a formula to this. Check below.

The program works well with common resolution image like 480p, 720p, 1080p; however, for big images, it doesn't work really well. Denoise still leaves atrifact and Magnify is not very sharp, compared to upscaling from lower resolution,

^Looks good I might try your method of upscaling then downscaling and then upscaling again to look better but you said that the sharpness decreases as you upscale so what I do is go increase the (upscaled image) sharpness in Photoshop


Add swizzlean

This pull request adds Swizzlean, an Objective-C swizzle helper class.  I wasn't sure if Tools was the best place to put this.  If you'd like me to place it in another category, let me know =)
Project URL
awesome-ios Fork URL
Swizzlean
Description
This Swizzlean class can help with dynamic replacement of methods and properties that can help with testing or "monkey patching."
Why it should be included to awesome-ios (optional)
This tool helps encapsulate some of the boilerplate code that is used when "swizzling" methods or properties that can help others with testing or "monkey patching."
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[ ] Supports Swift 3 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Error

:no_entry_sign:
Found 2 link issues

Link issues by awesome_bot

Line
Status
Link

2245
301
https://github.com/zwaldowski/BlocksKit redirects tohttps://github.com/BlocksKit/BlocksKit

2635
Error
http://swiftsandbox.io  getaddrinfo: Name or service not known

  Generated by :no_entry_sign: Danger

Hey @rbaumbach, thanks for contributing 👍 🎉


Remove required option for type_url in MessageId

In some cases we have to put TypeUrl.of(Empty.class).value() into this field, which is meaningless. See #1188 for more details on this issue.
It would be good to remove the field requirement.

More work than just addressing the type_url being non-required is needed. Closing this issue in favour of #1320 to be addressed in v2.


Httpsender doesn't work for uploading files to microsoft sharepoint

❗ please do not add sensitive information in issues, you can provide extra information via email using issue number as reference ❗
Describe the issue
We have an ibis app which uploads files to sharepoint. But with the normal http sender configured for a POST method with multipartxml doesn't work and gets the following error:
nl.nn.adapterframework.core.SenderException: HttpSender [Send_To_Sharepoint-sender] httpstatus [500] reason [Internal Server Error] body [<?xml version="1.0" encoding="utf-8"?><m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"><m:code>-1, System.IO.IOException</m:code><m:message xml:lang="en-US">I/O error occurred.</m:message></m:error>]
	at nl.nn.adapterframework.http.HttpSender.extractResult(HttpSender.java:535)
	at nl.nn.adapterframework.http.HttpSenderBase.sendMessage(HttpSenderBase.java:692)
	at nl.nn.adapterframework.http.HttpSenderBase$$FastClassBySpringCGLIB$$f73d91f3.invoke(<generated>)
	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:783)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:753)
	at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:102)
	at nl.nn.ibistesttool.IbisDebuggerAdvice.debugSenderInputOutputAbort(IbisDebuggerAdvice.java:221)
	at nl.nn.ibistesttool.IbisDebuggerAdvice.debugSenderInputOutputAbort(IbisDebuggerAdvice.java:254)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

response from sharepoint
<?xml version="1.0" encoding="utf-8"?>
<m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
	<m:code>-1, System.IO.IOException</m:code>
	<m:message xml:lang="en-US">I/O error occurred.</m:message>
</m:error>

It does work with the attached custom httpsender
SharePointHttpSender.zip
Reporter
Vinh

To Reproduce
Steps to reproduce the behavior:

Configure attached adapter configuration
Configuration_Test.zip

Contact me for property values of the adapter

Test this adapter via test a pipeline, input can be dummy string

See error

Replace pipe Send_To_Sharepoint with aforementioned custom SharePointHttpSender and then it will work

Note: please test from an NN workstation
Environment
FF! 7.7.3: Ibis4Scan
Running on LPZWNL000033000 using Apache Tomcat/8.5.40
Java Version: Java(TM) SE Runtime Environment (1.8.0_172-b11)
Heap size: 325M, total JVM memory: 729M
Free disk space: 13GB, total disk space: 236GB
Up since: 2022-09-06 09:04:07 (1h)

It appears the following configuration works in 7.8-RC1:
	<sender
		allowSelfSignedCertificates="true"
		className="nl.nn.adapterframework.http.HttpSender"
		timeout="120000"
		urlParam="sharepointUrl"
		verifyHostname="false"
		headersParams="Authorization"
		contentType=""
		methodType="POST"
		postType="BINARY"
	>

yes files can be send to sharepoint using httpsender with the configuration Gerrit mentioned


Remove babelfish formdata structures

Description
[Describe what this change achieves - Guidelines below (please delete the guidelines after writing the PR description)]

What is the change? This is best described in terms of “Currently, Babelfish does X. With this change it now does Y.” Think of “What did it used to do?” and “What does it do now?”

Why was the change made? What drove our desire to put effort into the change?
How was the code changed should only appear for large commits. This can serve as a rough roadmap to what’s contained in the commit. It should be very high level; if it’s directly referencing code it’s probably too detailed. It’s also critical that this section of a commit message does not try to replace proper code documentation (ie, block comments or README files). Generally, this section should only appear if the commit itself is large enough that it’s helpful to provide a roadmap to someone looking at the commit.
The last descriptive piece is the “title” for the commit: the very first line of the commit message, which should typically be less than 80 characters. A good title is critical, because it’s the only thing that shows up in places like the Github commit listing. No one’s got time to read through full commit messages when trying to find a single commit out of dozens.

Issues Resolved
[List any issues this PR will resolve]
Test Scenarios Covered

Use case based -

Boundary conditions -

Arbitrary inputs -

Negative test cases -

Minor version upgrade tests -

Major version upgrade tests -

Performance tests -

Tooling impact -

Client tests -

Check List

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

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

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

48 of 54 (88.89%)  changed or added relevant lines in 5 files are covered.
7 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.02%) to 74.511%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

contrib/babelfishpg_tsql/src/catalog.c
29
31
93.55%

contrib/babelfishpg_tsql/src/dbcmds.c
5
7
71.43%

contrib/babelfishpg_tsql/src/rolecmds.c
2
4
50.0%

Files with Coverage Reduction
New Missed Lines
%

contrib/babelfishpg_tsql/src/pltsql_utils.c
7
91.16%

Totals

Change from base Build<PHONE_NUMBER>8:
-0.02%

Covered Lines:
45228

Relevant Lines:
60700

💛  - Coveralls


Keep symlink when uncompressing archive

I've found that usiing Zippy to uncompress archive & tarball doesn't preserve symlink (which breaks some libraries package as archive)

Hello again. I've done more work on zip and tar stuff in zippy lately and wanted to look at adding symlink support for extracting tarballs.
Do you have a real-world tarball with symlinks in it that I could use for testing? I can make a fake one but I prefer testing with something "real" when I can (for example, I test with the Nim GitHub tarball and have also done the csources tarball).
If you do have a good test file to share that'd be great. Np if not I can just make or find one.
Also, I see on https://nim-lang.org/docs/os.html#createSymlink%2Cstring%2Cstring that creating a symlink, at least on Windows, is going to fail often due to lack of Administrator privilege. Is there something smarter I should do than just failing on error here?
Finally, there are also hard links. I'm not familiar with much use of them. Are they something I should be concerned with?

I had the issue with tarballs of Julia you can download at : https://julialang.org/downloads/ ;
I haven't tried on Windows and I don't know what it should do. I think a Windows archive simply shouldn't have symlink so returning an error should be fine ?
I've rarely seen hard links in archive. My use case case downloading library archive to distribute them with Nim code and it's mostly soft symlink for those.

Thanks for replying, your info was very helpful. The zippy/tarballs proc extractAll now supports symlinks in release >= 0.9.4. I am also using a tarball of Julia as my test file.
If you notice any issues with tarballs or symlinks just let me know. Once I have a test file for things they should not be hard to fix. Closing this issue for now but re-open if needed.


docker build and docker-compose build will not reuse their caches

Imagine that we build the same image on the same machine but multiple times. You would expect layer cache to be fully reused, so second identical build will pull everything from cache.
Interstingly docker build and docker-compose build will create unique layers (won't reuse cache from each other) every time a file is added (ADD/COPY)
Imagine simple Dockerfile:
FROM alpine

RUN  du -s /
COPY important.txt /
RUN  du -s /

All build methods will reuse cache on 1st and second entry. But COPY (the 3rd layer) will trigger a layers to fork.
See example test output
                              FROM             RUN            COPY            RUN
docker_py-context-build: ['d6ead20d5571', 'b013f23d740f', '00fc5abc7d11', '14f4a6a4048a']
        docker_py-build: ['d6ead20d5571', 'b013f23d740f', '9a9fabca5004', '1204cd88e5ad']
   docker-compose-build: ['d6ead20d5571', 'b013f23d740f', '9a9fabca5004', '1204cd88e5ad']
   docker-context-build: ['d6ead20d5571', 'b013f23d740f', '5e34ecab6b3e', '2f5ed38e8b40']
           docker-build: ['d6ead20d5571', 'b013f23d740f', '5e34ecab6b3e', '2f5ed38e8b40']

You can see that 1st two layers are identical across all build methods. But the moment we introduce COPY builds divert.
Versions used
> docker info
Containers: 5
Images: 10
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 20
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-53-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 1
Total Memory: 1.954 GiB
Name: mateusz.build
ID: EEQH:2YPB:QJC3:VVZQ:Q5SJ:4FJ5:HYSE:SZD7:37KE:2ABD:SMDX:ZILP
Debug mode (server): true
 File Descriptors: 14
 Goroutines: 22
 System Time: 2015-12-11T19:22:43.413412544Z
 EventsListeners: 0
 Init SHA1: 4fc7c03a06c675f115b39958c13486d53df10a14
 Init Path: /usr/lib/docker/dockerinit
 Docker Root Dir: /var/lib/docker
Username: munhitsu
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
 provider=amazonec2

> docker -v
Docker version 1.9.1, build a34a1d5

> pip freeze
appnope==0.1.0
decorator==4.0.6
docker-compose==1.5.2
docker-py==1.6.0
dockerpty==0.3.4
docopt==0.6.2
enum34==1.1.1
functools32==3.2.3.post2
gnureadline==6.3.3
ipython==4.0.1
ipython-genutils==0.1.0
jsonschema==2.5.1
path.py==8.1.2
pexpect==4.0.1
pickleshare==0.5
ptyprocess==0.5
PyYAML==3.11
requests==2.7.0
simplegeneric==0.8.1
six==1.10.0
texttable==0.8.4
traitlets==4.0.0
websocket-client==0.34.0
wheel==0.24.0

full scenario:
https://github.com/munhitsu/docker-caching-test

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
 Most likely cause is a different implementation of the tar all generated by docker-py versus docker-client; https://github.com/docker/compose/issues/883#issuecomment-73271778

@thaJeztah - yes - that's exactly the same issue.
Interestingly docker build always gives the same output. Irrespectively whether you build directory or provide tarred context.
On the contrary, the docker-py build will create two different checksums.

9a9fabca5004 when tarring itself
'00fc5abc7d11` when using pre-tarred thing

I'm tempted to say that it should be docker daemon guaranteeing consistency here. Not docker-py or any other potential client.

The tarball is created on the client, so I don't think the daemon can do much about it. I think any variation in the tarball will lead to this problem.

x-posting a comment from https://github.com/docker/compose/issues/883#issuecomment-179388150 -

docker will be using content addressable ids in 1.10 which should resolve this issue.

@dnephin @tonistiigi was this issue resolved? Thanks!

It was not resolved. docker-py doesn't always create the same tarball, for example https://github.com/docker/docker-py/issues/1206, and there may be other metadata that isn't stripped the same way.
This is being tracked here: https://github.com/docker/compose/issues/883 so I think we can close this issue.


Do not pass both BlockOffset and PlaneOffset

In motion estimation, several functions received both the offset expressed in blocks and in pixels for the luma plane. This information is redundant: a block offset is trivially convertible to a luma plane offset.
With tiling, we need to manage both absolute offsets (relative to the frame) and offsets relative to the current tile. This will be more simple without duplication.

Coverage increased (+3.2%) to 85.336% when pulling b9ba2e18d4f16bcbcdb3c4a5fc44922b2b815f27 on rom1v:blockplaneoffset into bec5484384505feab0dc93135efac21b7c48da9c on xiph:master.


Adobe Sign Connector

Hi, I'm in need for a connector or product for Adobe Sign
Customer
Implemented for one of our customer project
Use Cases
Sign Documents (PDF) using the Adobe Sign
Integration
https://www.adobe.com/de/sign.html
Open API: https://secure.eu1.echosign.com/public/docs/restapi/v6#!/transientDocuments/createTransientDocument

juergeplohn is already building this

Let's go ahead with the approval and market integration of https://github.com/axonivy-market/adobe-esign-connector/tree/master

⚠ do not remove this section, but leave it to track the reviewer's work.
Review Tasks
Product Domain

[ ] product successfully installs into the Axon Ivy Designer
[ ] product parts are marked as Connector or Demo
[ ] the product projects contains documentation to explain the functionality or use-case:
e.g. Process-Notes, Input-Parameter descriptions, Meta-Comments on variables.yaml definitions ...
[ ] the product readme fits into the market landscape @andreasbalsiger
[ ] all mandatory setup steps to run the Demo are documented in the setup section of the [myProduct]/product/Readme.md .

Technical Solution
Coherent

[ ] Common group-id for all artifacts <groupId>[org.arcme|com.axonivy].[util|connector].[product-name]<groupId>
[ ] Common artifact-id prefix: <artifactId>msgraph[-product|test|demo]</artifactId>
[ ] Html-Dalogs depend on suggested 'frame' template
[ ] Github actions + maven-build runs as outlined in market-product template

Maintainable

[ ] Dependent third-party infrastructure (e.g. Database, MavenRepos) is available: public accessible instance or shared as code (e.g. Docker, docker-compose)
[ ] Tests are implemented that verify, that the product actually runs
[ ] Additional libraries (e.g. Maven dependencies) are lightweight: not duplicating libaries of the Axon.ivy Classpath Container.
[ ] Depends on standard Axon Ivy features and does not light-heartedly re-introduce forks of existing solutions (e.g. Job-Framework). Our goal is to integrate also third-parties into existing: Enginge-Cockpit-View, Log-Channels, Monitoring features, ...
[ ] Uses latest ivy-environment: e.g. process-files and used project-build-plugin match the ivyProject version.
[ ] Product is re-usable without the need to unpack and customize it for standard use-cases: crucial settings can be overriden with well documented config/variables.yaml


Support returning scalars in DP

Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure to update the docs?
[x] Did you write any new necessary tests?
[ ] If you made a notable change (that affects users), did you update the CHANGELOG?

What does this PR do?
Fixes #1861 and #1904.
I'm not sure if this fix is the right approach. In the docs it's mentioned that training_step must return Tensor (even for the progress_bar dict). But with this PR it'll also work with scalars. Were there other reasons (besides the issues above) to force users to stick with tensors?
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

@nsarang good addition. Can you write a test for this?

Could you then also update the docs, since you mention there are wrong informations on the return type?

@nsarang how is it going here? :rabbit:

@Borda  Sorry I've been busy lately. I'll finish it today 🙂

Hello @nsarang! Thanks for updating this PR.

In the file tests/base/model_train_steps.py:

Line 33:1: W293 blank line contains whitespace
Line 39:13: E123 closing bracket does not match indentation of opening bracket's line

@Borda
I tested this on 2 GPUs using DP and it was OK. But it gave the following warning:
/nsarang/env-python3.6/lib/python3.6/site-packages/torch/nn/parallel/_functions.py:61: UserWarning: Was asked to gather along dimension 0, but all input tensors were scalars; will instead unsqueeze and return a vector.
This warning is supposed to be silenced in ignored_warnings.py but It seems the text doesn't match 🤔
I could add this line to the gather method to avoid this warning.

@awaelchli how is this one? :rabbit:

@awaelchli I've made some changes. Can you take a look?

looks good!

@nsarang mind check the tests, pls

mind checking the failing test? @nsarang

@Borda @williamFalcon
Seems to be working for all tests now except tests/core/test_datamodules.py::test_full_loop_ddp_spawn. The final assertion fails.
I'm not sure how LightningDataParallel is related to ddp_spwan.
Is it because of the way I added alternating batches in TrainingStepVariations and ValidationEpochEndVariations?

@nateraw mind have look? 🐰


The Controller compatibilities dose not work the only thing that works are the right and left trigger

Legacy4J Version
1.20.4
Mod Loader Version
Current version
Bug/Glitch Occurrence Context
The Controller compatibilities dose not work the only thing that works are the right and left trigger
Crash Report
No response
What happened wrong?
The Controller compatibilities dose not work the only thing that works are the right and left trigger

There is no way I can help you without you informing your system, its version, if you have Steam installed or any other software that interferes with the controller input.
And it is incorrect to say that controller support "dose not work", for most people it works fine, your case is an exception


Unblock CI

Remove MarkerForExternalDebugStep
This was previously used in the hybrid debugging scenario (VS would
set a breakpoint on this function, which was hard to inline). Since
this is no longer supported, we can remove this function.
Add analysis asserts to silence false positives
Prefast started warning on some false positives. This silences them.
Pull in Jimmy's changes to fix xplat CI
Xplat build machines now have clang3.9, we need to support that.

The ubuntu shared_ubuntu_linux_debug failure is due to the libclang-3.9-dev package missing on the machines, and @mmitche is updating that for us.

@mmitche is there a known timeline for the package addition? If it's going to be a bit, I'd like to send this set in and temporarily disable the failing flavor.

@Penguinwizzard At least another hour or two.

@mmitche Ok, I'll disable the flavor then, and open a PR to re-enable it.


[v2] route params not updated

It seems that my route.params are not updated when I navigate back on an already loaded page with different parameters.
Indeed, here we can see that if page has already a route we don't use new route with new params.
https://github.com/framework7io/framework7/blob/2c949dbc01d9285daf9fa02a763174fd80b6c9a5/src/modules/router/router-class.js#L904
I don't know if it is done on purpose and why we are not using new route but I think at least we should merge route.params inside currentPage.route.params here.
Am I right?

This is by design, since page was created it was created acoording to some specific and unique combination of route, its params and query

As well as calling navigate or back to same route but with different url params creates new page. You probably need to use something else instead for your logic

Do you mean that we cannot use pageName to target pre-loaded generic page using dynamic params in route path?
I mean what is the point to use old route object if we access this page with different path, especially different params?
I don't understand in which case we want to ignore new generated route object in the line I linked.
Some context on my project: I use Aurelia framework and specially to generate all my pages at app start (because I cannot use both f7 router and aurelia router). Then I create routes with pageName targeting all my generated pages and use page:init and page:reinit in order to do my pages (re)initialization.
The problem occurs when having routes like:
{
  path: '/main/',
  pageName: 'main-page'
}, {
  path: '/myroute/:id/',
  pageName: 'my-page-name'
}

Start at /main/
Navigate to /myroute/01234/, it triggers page:init with e.detail.route.params.id === "01234"
Navigate to /main/ (or any other route)
Navigate to /myroute/56789/, it triggers page:reinit with e.detail.route.params.id === "01234"

And this is due to the line I linked before. It uses first computed route instead of new one.
I don't know how to get rid of this behavior in my case or how to setup a workaround... I expect that route.params are updated when I get back on my page with different url an so different params.

I will think about. But by design, each page is designed to be used with unique route. So reusing one page element for different routes is not supported. It was done intentionally, because in reactive frameworks like Vue.js or React there could be problems, they use Vue/React components for (or instead) pages and having route be changed for already rendered page could bring unexpected behavior.
As a workaround you may just use page.router.currentRoute

Oh great! I didn't realized... Thanks I will try this!


$firebaseStorage inject Provider Error

I am currently having the issue where I'm using $firebaseStorage as an injection dependency in my ionic project, however it returns the following error message:
Error: [$injector:unpr] Unknown provider: $firebaseStorageProvider <- $firebaseStorage <- UploadCtrl
Would you be able to assist me in this matter please?

Please open up a new issue which follows the issue template. Thanks!


Add shorthand to filter probe type

Closes #2236

I'm not sure if we should merge this, the solution I probably want for my problem is a way to just list cmsisdap probes.

So, something like CmsisDapFactors::list_probes()?


Cannot call service on turn_on/off smart_charging()

I am unable to use the Switch entity to turn on or off the Smart Charging.
When using the Easee-app, I see the change instantly in HA, but using the switch returns the following:
"Failed to call service switch/turn_on/off. smart_charging() takes 1 positional argument but 2 were given"

Hi, which version of the integration are you using? This should have been fixed in one of the latest releases, and I don't get this error message in my installation anymore. Please check if you have the latest version (0.9.8).

Reinstalled the plugin, and it worked. Seems I was not getting any HACS updates.
But the current version I see is 0.9.29, not 0.9.8.

Yes, 0.9.29 was released yesterday (and I've got a typo in my message, should say 0.9.28 at the time of writing). Please close issue if it seems to be working well in your end now.

You got it.
cheers.


New Search function

Who wants a good search bar? lol instead you get this. Fixed/roundabout solution #105

Here's a pic


response-ratelimiting response-ratelimiting redis will get unexpected results

Summary
If user configure response-ratelimiting、response-ratelimiting use same redis instance with db0 and other will get unexpected results.
Steps To Reproduce
configure 2 api add response-ratelimiting plugin use same redis instance with db0 and other .
Additional Details & Logs

Kong version (0.12.3)

Fixed with #3293 being merged. Thanks for reporting!


Intrinsic append: isn't this a redundant double-evaluation?

In this line:
https://github.com/cryptocode/bio/blob/e525af48db08bd4fcc58f6a7f072b4350089fd64/src/intrinsics.zig#L1316
Couldn't it be replaced by const expr = evaled;?

Yeah this might be vestigial code from a refactor, or just a bug. If the first evaluation doesn't yield a list, it's evaluated again, and I don't recall if there ever was a valid case for that.
Note that Bio will be rewritten as a vm interpreter/JIT, so this part will be completely rewritten too. That's longer term though.
If tests pass with your change, feel free to PR!

Note that Bio will be rewritten as a vm interpreter/JIT

Too cool, looking forward to seeing how that'll be implemented!

Yeah this might be vestigial code from a refactor

Been there since the first commit — I know since I'm going through the repo's past commits one by one for my own study-ish purposes :grin: finding the code-base very well-done, to my taste :+1:

Thank you for the kind words! If it's been there since the start, I've long forgotten why 😅  I'll do the change as I think you're right it's redundant.


bundle exec for rubocop

Hey,
I had to override ruby linter command to 'bundle exec rubocop...' but maybe it should be available in configuration.

This is similar to what was done for Haskell and "stack." This can be done eventually.

Replaced by #257


Template class with overloaded operator()

I'm trying to wrap a templated class (thanks for the suggestion to use 'template') with an overloaded operator(). I'm using 'find' for the method name on the julia side. If you know of a better convention, please let me know. The wrapping code is this:
    lciowrap.add_type<Parametric<TypeVar<1>>>("CellIDDecoder")
      .apply<UTIL::CellIDDecoder<EVENT::SimCalorimeterHit>>([](auto wrapped)
    {
      typedef typename decltype(wrapped)::type WrappedT;
      wrapped.template constructor<const string&>();
      wrapped.template constructor<const EVENT::LCCollection*>();
      wrapped.method("find", &WrappedT::operator());
    });

Unfortunately, the compiler complains about some sizeof(T) == 0 assert failing, but I don't understand where this is coming from. I think all relevant types are wrapped. I don't need to wrap pointers separately from value types, do I? (side question: how do I pass a pointer to a C++ function, when I only have the value on the julia side?)
In file included from /home/jstrube/.julia/v0.4/CxxWrap/deps/usr/include/array.hpp:9:0,
                 from /home/jstrube/.julia/v0.4/CxxWrap/deps/usr/include/cxx_wrap.hpp:13,
                 from /home/jstrube/.julia/v0.4/LCIO/deps/src/lciowrap/lciowrap.cc:1:
/home/jstrube/.julia/v0.4/CxxWrap/deps/usr/include/type_conversion.hpp: In instantiation of ‘jl_value_t* cxx_wrap::ConvertToJulia<T, Fundamental, Immutable, Bits>::operator()(CppT&&) const [with CppT = UTIL::BitField64; T = UTIL::BitField64; bool Fundamental = false; bool Immutable = false; bool Bits = false; jl_value_t = _jl_value_t]’:
/home/jstrube/.julia/v0.4/CxxWrap/deps/usr/include/type_conversion.hpp:657:35:   required from ‘decltype (cxx_wrap::julia_converter_type<T>()(cpp_val)) cxx_wrap::convert_to_julia(T&&) [with T = UTIL::BitField64; decltype (cxx_wrap::julia_converter_type<T>()(cpp_val)) = _jl_value_t*; cxx_wrap::julia_converter_type<T> = cxx_wrap::ConvertToJulia<UTIL::BitField64, false, false, false>; typename std::remove_const<typename std::remove_reference< <template-parameter-1-1> >::type>::type = UTIL::BitField64]’
/home/jstrube/.julia/v0.4/CxxWrap/deps/usr/include/cxx_wrap.hpp:31:28:   required from ‘cxx_wrap::mapped_julia_type<typename std::remove_const<typename std::remove_reference< <template-parameter-1-1> >::type>::type> cxx_wrap::detail::ReturnTypeAdapter<R, Args>::operator()(const void*, cxx_wrap::mapped_julia_type<typename cxx_wrap::static_type_mapping<typename std::remove_const<typename std::remove_reference<Args>::type>::type>::remove_const_ref<Args> >...) [with R = UTIL::BitField64; Args = {UTIL::CellIDDecoder<EVENT::SimCalorimeterHit>&, const EVENT::SimCalorimeterHit*}; cxx_wrap::mapped_julia_type<typename std::remove_const<typename std::remove_reference< <template-parameter-1-1> >::type>::type> = _jl_value_t*]’
/home/jstrube/.julia/v0.4/CxxWrap/deps/usr/include/cxx_wrap.hpp:52:43:   required from ‘cxx_wrap::mapped_julia_type<typename std::remove_const<typename std::remove_reference< <template-parameter-1-1> >::type>::type> cxx_wrap::detail::call_functor(const void*, cxx_wrap::mapped_julia_type<typename std::remove_const<typename std::remove_reference<Args>::type>::type>...) [with R = UTIL::BitField64; Args = {UTIL::CellIDDecoder<EVENT::SimCalorimeterHit>&, const EVENT::SimCalorimeterHit*}; cxx_wrap::mapped_julia_type<typename std::remove_const<typename std::remove_reference< <template-parameter-1-1> >::type>::type> = _jl_value_t*]’
/home/jstrube/.julia/v0.4/CxxWrap/deps/usr/include/cxx_wrap.hpp:190:12:   required from ‘void* cxx_wrap::FunctionWrapper<R, Args>::pointer() [with R = UTIL::BitField64; Args = {UTIL::CellIDDecoder<EVENT::SimCalorimeterHit>&, const EVENT::SimCalorimeterHit*}]’
/home/jstrube/.julia/v0.4/LCIO/deps/src/lciowrap/lciowrap.cc:50:1:   required from here
/home/jstrube/.julia/v0.4/CxxWrap/deps/usr/include/type_conversion.hpp:549:5: error: static assertion failed: No appropriate specialization for ConvertToJulia
     static_assert(sizeof(T)==0, "No appropriate specialization for ConvertToJulia");
     ^~~~~~~~~~~~~

This was actually a pretty bad bug in CxxWrap, which caused reference return types not to work. Julia actually supports overloading operator(), I'll have to experiment with how we can translate that.
What do you mean with passing a pointer to C++? You could use jl_value_t*, or if the type is wrapped the C++ type directly.

Thanks for the fix.
What I mean by passing the pointer is that the methods I'm using return things like Particle*, but I'm wrapping Particle, not Particle*. Is that a problem with translating access from . to -> ?
Also, once I have this Particle from a C++ function in Julia, I want to pass it on to another (wrapped) C++ function which expects a const Particle*. Do I need to do anything about this? Or is that handled transparently.
In other words, I have a function Particle* getParticle() on the C++ side. I want to use the returned value in Julia, and then pass it back to something like printParticle(const Particle*) on the C++ side again. My question was if wrapping Particle does that transparently, or if I need to call s.th. like a pointer() helper function.
I think your reply indicates that everything's handled transparently, so that already answered my question. Thanks!

Actually, this still doesn't quite work.
It compiles now, but when I run it, it complains about the classes for the template specialization not having been compiled. So when I try to wrap the constructor taking a const LCCollection*, it complains about LCCollection not having been wrapped.
 I figured it out: It complains about using the const:
This one works: wrapped.template constructor<EVENT::LCCollection*>();
This one doesn't: wrapped.template constructor<const EVENT::LCCollection*>();
Wrapping the operator() method always leads to a complaint about one of the classes in the template specialization not having a julia wrapper, but they are all there. For example:
terminate called after throwing an instance of 'std::runtime_error'
  what():  Type PKN5EVENT14CalorimeterHitE has no Julia wrapper

signal (6): Aborted
gsignal at /lib64/libc.so.6 (unknown line)
abort at /lib64/libc.so.6 (unknown line)
_ZN9__gnu_cxx27__verbose_terminate_handlerEv at /usr/lib64/libstdc++.so.6 (unknown line)
unknown function (ip: 0x7fb935d8f576)
unknown function (ip: 0x7fb935d8f5c1)
unknown function (ip: 0x7fb935d8f7d8)
_ZNK8cxx_wrap15FunctionWrapperIRKN4UTIL10BitField64EJRNS1_13CellIDDecoderIN5EVENT14CalorimeterHitEEEPKS7_EE14argument_typesEv at /home/jstrube/.julia/v0.4/LCIO/deps/usr/lib/liblciowrap.so (unknown line)

PS: I don't need this to be mapped to the operator() in Julia. The class is not used as a functor, so using the operator() in place of a regular function is a design choice I don't want to copy in my julia bindings.

OK, there was still a bug when using const pointers as arguments, should be fixed now.

I'll need more thorough testing, but for now, it compiles and runs.
Thank you!

Added the call operator overload anyway, it's a nice feature to have.


GoogleLogin errors - is it possible to support this extension?

Name of extension
GoogleLogin
MediaWiki.org page (if it exists)
https://www.mediawiki.org/wiki/Extension:GoogleLogin
Justification
This allows google authentication to work. The extension says it should support:-
MediaWiki 1.36+
MySQL/MariaDB (no PostgreSQL or SQLite support)
PHP 7.3+
However after downloading the Mediawiki 1.39 version of the extension, I see this error when logging in:-
[60245817afd463888e4de1d8] /w/index.php?title=Special:UserLogin&returnto=Main+Page ParseError: syntax error, unexpected 'private' (T_PRIVATE), expecting variable (T_VARIABLE)
I believe this may have something to do with PHP version changes.
How often is this extension/skin updated?
With media wiki versions I believe.
How many people contribute to this extension regularly?
Not sure.
How many consistent maintainers are there (i.e. those who would be capable of continuing the extension's development in the other maintainers' absence)? Do not include people who make one-time or occasional contributions.
Are you the author of this extension/skin?
No
I tried using a newer version of the plugin, and I can get GoogleLogin to work and accept logins, however this then breaks file uploading with errors.

It seems to me that the GoogleLogin extension simply does not work (yet) with MW 1.39 - judging by both what you wrote, and the messages on that extension's talk page. Have you tried using the OpenID Connect extension instead to log in with Google? That works, as far as I know - and it's in Canasta.

I think I have it working with an older release of GoogleLogin now (Release 1.38) which I found on github. I can log in, and I can file upload again. I'm not sure how to configure OpenID Connect, but may give that a go, as I do prefer to be running newer versions of plugins. Thanks.


What if the user denies the push notification permissions request?

Hi, is there any way to tell if the user has specifically denied the push notification permission (iOS or Android)?
So far I have been unable to find a way to tell whether a user has denied the permission or a general registration error has occurred. Is there a way or is this feature missing from the plugin?
Thank you!

I think this is a duplicate of #202

@tyronedougherty please add comments +1 to #202


[GHA - release] Bump chart version when merging master back to dev

Submitted against master for immediate effect, addresses #4920.
An issue we've been having is at https://github.com/DefectDojo/django-DefectDojo/runs/3173934689?check_suite_focus=true
This PR will check the current chart version with
CURRENT_CHART_VERSION=$(grep -oP 'version: (\K\S*)?' helm/defectdojo/Chart.yaml)

and then smartly increment it and also adding a -dev suffix (per @valentijnscholten's feedback)
sed -r "s/version: \S+/$(echo "version: $CURRENT_CHART_VERSION" | awk -F. -v OFS=. 'NF==1{print ++$NF}; NF>1{$NF=sprintf("%0*d", length($NF), ($NF+1)); print}')/" helm/defectdojo/Chart.yaml

(I did not come up with that last regex, some people are smarter than me)
Since we're now adding a -dev suffix to the chart's version, that suffix is removed automatically when we submit the first PR from dev->master.

I don't understand the wild regex/sed/awks so probably just merge it so we can do some test runs?

Sure, I am good in testing it for real. The stuff worked manually on my branch but you know…


[Bug] Navigate to issues 3125

Description
When selecting navigateTo the ui says that one can only navigate to a page name and does not mention external url
The action selector does not add an undefined directly when skipping the query params argument. This PR fixes these issues.
Fixes #3125
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?
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, particularly in hard-to-understand areas
[x] 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

Test coverage results :test_tube:
:red_circle: Total coverage has decreased
// Code coverage diff between base branch:release and head branch: bug/navigate-to-issue-3125

Status
File
% Stmts
% Branch
% Funcs
% Lines

:red_circle:
total
51.71 (-0.01)
32.95 (-0.02)
29.66 (0)
52.2 (0)

:red_circle:
app/client/src/components/editorComponents/ActionCreator.tsx
34.25 (-0.17)
23 (-0.22)
21.11 (0)
33.5 (-0.18)

:red_circle:
app/client/src/components/editorComponents/GlobalSearch/index.tsx
62.7 (0)
14.84 (-2.32)
42.5 (0)
62.13 (-0.22)

This fix is not working

Browser metadata
Path:      /applications/60067b0a65f65e25ea829159/pages/60067b0a65f65e25ea82915b/edit
Browser:   Chrome 91.0.4472.101 on Mac OS 10.15.7
Viewport:  1680 x 946 @2x
Language:  en-GB
Cookies:   Enabled

View on BrowserStack

Open Deploy Preview · Mark as Resolved

PR is too old, causing breaking changes when merging. New PR with the same changes with the latest release raised.
https://github.com/appsmithorg/appsmith/pull/5532


[Bug Report] CSS not fully applied (to fonts at least)

Element UI version
2.5.4
OS/Browsers version
Chrome 72
Vue version
2.6.6
Reproduction Link
https://jsfiddle.net/WoJWoJ/x37ksar2/
Steps to reproduce
The basic app linked above displays a named input field
What is Expected?
That the font used in the description (label) follows the typography of Element
What is actually happening?
The font used is the fallback serif font of the browser

the typography in Element is just a design suggestion instead of a provided font.

@iamkun ok I understand, thanks. Is there a way to force a font-family globally, then?


pgcluu's sysinfo.txt is mostly Linux-only

I imported a port of pgcluu into OpenBSD ports earlier today. It generally works fine (the PostgreSQL part that is), however there are two issues:

there's no sar binary for sysstat is effectively a wrapper for cat /proc/*
the other sysinfo related parts of pgcluu rely heavily on /proc too, or other Linuxisms such as swap or filesystem information.

Has it been considered to use a more widely supported library to grab the information? Such as libstatgrab or the like? That way sysinfo.txt's os-related content can be replaced with library calls and therefore making it more portable and as a bonus, preventing the need to shell-out.

Hi,
Sorry for responding so late, I was traveling. One of the main feature
of pgcluu is that it doesn't not require anything to be installed, other
than Perl, to be able to collect PostgreSQL metrics. The use of sar is
optional and doesn't prevent us to use pgcluu if it is not installed. If
you keep in mind this feature I will be pleased to apply your pull
requests for OpenBSD support. You can use the Unix::Statgrab Perl
Module, we will included it later into the pgcluu_collectd script.
Best regards,

Alright, then let's close this issue and I'll open PRs or more separate issues when I need to discuss specifics.


Drag & Drop in the '2d View' should add a new data file

This is NOT a bug, but a suggested improvement.
Similarly to other GIS apps, the drag & drop of data file should also work in the '2d View'. Currently, it only works in the 'Project Tree'.

I think I looked at this a long time ago, and did not find a great way forward.  I'll take another look though.

Closing this issue.  Resolved in 0.7.6.


Make MathSat available as an available-solver

We should also include mathsat in the .torxakis.yaml file as a possible solver.
MathSat of course can not be part of the installer, since we are not allowed to distribute it.
From: Alberto Griggio <griggio AT fbk.eu>
Re: [mathsat] License question

Dear Pierre,

first of all, my apologies for the long delay in replying. For some reason your email went into my spam folder (I don't know why) and I noticed it only now.

> We are developing TorXakis under the BSD3 license (see
> https://github.com/TorXakis/TorXakis for more info).
>
> TorXakis uses a problem solver under the hood.
>
> Currently, we test TorXakis with cvc4 and z3 (and z3str3).
>
> We would like to test TorXakis with more problem solvers including
> MathSAT 5.
>
>
>
> Based on the license text we have doubt whether this usage is within
> the research and evaluation purposes as mentioned in the license.
>
> Could you please clarify whether we are allowed to download MathSAT 5
> and test TorXakis with MathSAT 5?

I am not a lawyer, but I think that as long as you do not use MathSAT for commercial purposes you should be ok. Just adding support for MathSAT in your tool, without actually distributing the MathSAT binary and/or library itself, should be fine I think. In other words, if TorXakis is extended to be able to talk to MathSAT, but people who want to use the solver still have to download it themselves from its webpage at FBK, everything should be ok.

Best,
Alberto

I don't know if it is a good idea to include these emails here ;)
Do we need to do something at all for this issue? Any TorXakis user should be able to edit the configuration file and choose the solver she likes the most. Or am I missing something?

I want to have proof that our BSD3 license is not at risk -> that's why the email is captured.
Indeed any user could do it.
Yet for robustness we need to test ourselves.
Furthermore, finding out what the relevant flags etc are for TorXakis might be our responsibilities

Yet for robustness we need to test ourselves.

I would not put this in our plate. If an issue comes in as a consequence of TorXakis not working with whatever SMT solver, then we take it. I think it is unrealistic to expect that we're gonna test all SMT solvers out there.
But if you want to keep this open feel free to remove the "needs-more-information" label, and assign the labels you consider appropriate.

Communication with Mathsat solver is not stable.
The communication get lost (at some point):
see e.g.
C:\TorXakis>torxakis 59401 examps\Echo\Echo.txs

TXS >>  TorXakis :: Model-Based Testing

TXS >>  txsserver starting: "NLYBSTQVP4NB77Y.code1.emi.philips.com" : 59401
TXS >>  Solver "mathsat" initialized : MathSAT5 [MathSAT5 version 5.5.1 (5a0ab3b
56ce0) (Dec 11 2017 10:52:28, gmp 5.1.3/mpir 2.7.0, msvc 18.00, 64-bit)]
TXS >>  TxsCore initialized
TXS >>  input files parsed:
TXS >>  examps\Echo\Echo.txs
TXS >> stepper Model
TXS >>  Stepper started
TXS >> step 10
TXS >>  .....1: Act { { ( In, [ -4658918826359910401 ] ) } }

with server:
C:\TorXakis>txsserver --smt-log
Found configuration file at `.torxakis.yaml`.
59401

TXSSERVER >>  Starting  .....

TXSSERVER CMD >>  START
TXSSERVER RSP <<  MACK txsserver starting:  "NLYBSTQVP4NB77Y.code1.emi.philips.c
om" : 59401
TXSSERVER RSP <<  PACK START
TXSSERVER CMD >>  INIT examps\Echo\Echo.txs
TXSSERVER RSP <<  MACK Solver "mathsat" initialized : MathSAT5 [MathSAT5 version
 5.5.1 (5a0ab3b56ce0) (Dec 11 2017 10:52:28, gmp 5.1.3/mpir 2.7.0, msvc 18.00, 6
4-bit)]
TXSSERVER RSP <<  MACK TxsCore initialized
TXSSERVER RSP <<  MACK input files parsed:
TXSSERVER RSP <<  MACK examps\Echo\Echo.txs
TXSSERVER RSP <<  PACK INIT
TXSSERVER CMD >>  STEPPER Model
TXSSERVER RSP <<  MACK Stepper started
TXSSERVER RSP <<  PACK STEPPER
TXSSERVER CMD >>  STEP 10
TXSSERVER RSP <<  MACK .....1: Act    { { ( In, [ -4658918826359910401 ] ) } }

Yet the smt-log contains more steps:
(get-info :name)
(get-info :version)
(set-logic ALL)
(set-option :produce-models true)
(set-info :smt-lib-version 2.5)

(push 1)

(push 1)
(declare-fun $In$1012$0$1$() Int)

(check-sat)
(get-value ($In$1012$0$1$))
(push 1)
(assert (not (<= 0 (+<PHONE_NUMBER>359910400 $In$1012$0$1$))))
(check-sat)
(get-value ($In$1012$0$1$))
(pop 1)
(assert (= (-<PHONE_NUMBER>359910401) $In$1012$0$1$))
(check-sat)
(get-value ($In$1012$0$1$))
(pop 1)
(push 1)
(declare-fun $Out$1013$0$1$() Int)
(assert (= (-<PHONE_NUMBER>359910401) $Out$1013$0$1$))
(check-sat)
(pop 1)
(push 1)
(declare-fun $Out$1013$0$1$() Int)
(assert (= (-<PHONE_NUMBER>359910401) $Out$1013$0$1$))
(check-sat)
(get-value ($Out$1013$0$1$))
(push 1)
(assert (<= 0 (+ (-<PHONE_NUMBER>919796015) $Out$1013$0$1$)))
(check-sat)
(pop 1)
(assert (= (-<PHONE_NUMBER>359910401) $Out$1013$0$1$))
(check-sat)

Unclear why only MathSat communication fails: Z3, cvc4 and Yices seem to work fine.

In the refactor All branch, we seem to be able to use MathSat just fine with the new Solve implementation.

Moved refactoring from RefactorAll to development.
Doesn't seem to solve the problem:
MathSAT hangs after some steps.
See e.g. (include response on killing of mathsat):
PS C:\experiments> torxakis C:\temp\TorXakis\examps\Echo\Echo.txs

TXS >>  TorXakis :: Model-Based Testing

TXS >>  txsserver starting: "PC-17716.tsn.tno.nl" : 54653
TXS >>  Solver "mathsat" initialized : MathSAT5 [MathSAT5 version 5.5.4 (cb2aadea7102) (Feb 22 2019 09:16:37, gmp 5.1.3/mpir 2.7.0, msvc 18.00, 64-bit)]
TXS >>  TxsCore initialized
TXS >>  input files parsed:
TXS >>  ["C:\\temp\\TorXakis\\examps\\Echo\\Echo.txs"]
TXS >> stepper Model
TXS >>  Stepper started
TXS >> step 10
getSMTresponse: SMT exited with status: Nothing
torxakis.exe: <socket: 712>: hGetLine: does not exist (No such file or directory)

and
PS C:\experiments> torxakis C:\temp\TorXakis\examps\Echo\Echo.txs

TXS >>  TorXakis :: Model-Based Testing

TXS >>  txsserver starting: "PC-17716.tsn.tno.nl" : 54657
TXS >>  Solver "mathsat" initialized : MathSAT5 [MathSAT5 version 5.5.4 (cb2aadea7102) (Feb 22 2019 09:16:37, gmp 5.1.3/mpir 2.7.0, msvc 18.00, 64-bit)]
TXS >>  TxsCore initialized
TXS >>  input files parsed:
TXS >>  ["C:\\temp\\TorXakis\\examps\\Echo\\Echo.txs"]
TXS >> stepper Model
TXS >>  Stepper started
TXS >> step 10
TXS >>  .....1: Act { { ( In, [ 4 ] ) } }
TXS >>  .....2: Act { { ( Out, [ 4 ] ) } }
TXS >>  .....3: Act { { ( In, [ 36 ] ) } }
getSMTresponse: SMT exited with status: Just (ExitFailure 1)
torxakis.exe: <socket: 588>: hGetLine: does not exist (No such file or directory)

Note that mathSAT can handle the smt-log file generated with another problem solver without any problems!


Blackbox tests are failing on california branch for both x86 and arm servers.

https://jenkins.edgexfoundry.org/view/blackbox-testing/job/blackbox-testing-centos7-blackbox-4c-2g-california/45/
and
https://jenkins.edgexfoundry.org/view/blackbox-testing/job/blackbox-testing-cavium-arm64-california/51/consoleText
@tsconn23 has some initial thoughts on the origins of the failure.  Specifically the use of mongoimport
[INFO] Init postman test data .
Info: Initiating EdgeX Test
tee: ./postman-test/scriptLogs/edgex31-07-2018_150014.log: No such file or directory
/bin/bash: mongoimport: command not found
Info: /etc/newman/DataDumps/coredata/eventDb.json data imported
/bin/bash: mongoimport: command not found
Info: /etc/newman/DataDumps/coredata/readingDb.json data imported
/bin/bash: mongoimport: command not found
Info: /etc/newman/DataDumps/coredata/valueDescriptorDb.json data imported
Info: Initiating Coredata Test.```

@JPWKU I'm working on this issue.

tee: ./postman-test/scriptLogs/edgex31-07-2018_150014.log: No such file or directory

This error can be solved by create a scriptLogs folder.

/bin/bash: mongoimport: command not found

We found mongoimport is work fine on centos7, but it's fail on arm64 environment. So we will survey the problem with the image docker-edgex-mongo-arm64:0.6.0

Basically, the MongoDB version and installation way are different between docker-edgex-mongo-arm64:0.6.0 and docker-edgex-mongo:0.6.0, and we will see how to make mongoimport work in docker-edgex-mongo-arm64

@JPWKU @tsconn23

This PR https://github.com/edgexfoundry/blackbox-testing/pull/59 is used to fix below error:

tee: ./postman-test/scriptLogs/edgex31-07-2018_150014.log: No such file or directory

And We can add
mv mongodb-linux-aarch64-ubuntu1604-3.4.7/bin/mongoimport /usr/local/bin && \ in
https://github.com/edgexfoundry/docker-edgex-mongo/blob/master/Dockerfile.aarch64
to fix below error:

/bin/bash: mongoimport: command not found

I created a branch https://github.com/weichou1229/docker-edgex-mongo/blob/add-mongoimport/Dockerfile.aarch64#L35 to test, and it's work fine.

Now docker-edgex-mongo-arm64:0.6.0 mongodb version is 3.4.7 and docker-edgex-mongo:0.6.0 mongodb version is 3.4.9.  Is it need consistent?
I also build mongo-arm64 with 3.4.9, and it's work too.

issue fixed by https://github.com/IOTechSystems/postman-integration-test/pull/22

@JPWKU
please help review the PR https://github.com/edgexfoundry/blackbox-testing/pull/59

https://github.com/edgexfoundry/blackbox-testing/pull/59 merged, closing this issue


Request for your paper

Hi
I'm a Ph.D candidate in China
I‘m very interested in this ksss work, I think this idea is so brilliant
And I want to read your paper in detail while I found this paper is not available through Google
So may I ask for your manuscript for this "ksss" work to get a deeper understanding of it
Thank you !
Best wishes !
Yuan

@John2016 Thanks for your interest. I will release it on arxiv and reply again when it is uploaded.

@John2016 Here you go https://arxiv.org/abs/1704.03958

@sjtrny Thank you!


Integrate GitHub Action for creating security issues

In https://github.com/exasol/python-toolbox/pull/88 we created an action for creating issues for vulnerabilities.
### Tasks
- [x] Try out the action in a Java project
- [x] Replace dependency check action in PK with new action

Tried out security-issue action, it successfully created https://github.com/exasol/project-keeper/issues/491


Add powershell script equivalents of test scripts and add windows to the test matrix for the test pipeline

I think there are some issues with windows that might be catchable via automated testing. This PR takes a stab at adding windows to the test pipeline so that we can avoid these issues in the future

@Olical I don't have permissions to run the test pipeline, or maybe its not setup to run on PRs? When running locally on my windows machine using the instructions in the readme I get some interesting failures. I will work on addressing them now

Ok I'm running into test failures largely because the .nfnl.fnl file is not trusted. Is the trust system not an issue on linux builds?

These failures in particular seem extremely relevant:
Testing:        C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua
Success ||      basename removes the last segment of a path
Success ||      basename happily lets nils flow back out
Fail    ||      path-sep returns the OS path separator (test assumes Linux)
            Expected objects to be equal.
            Passed in:
            (string) '\'
            Expected:
            (string) '/'

            stack traceback:
                C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:26: in function 'loaded'
                ...\pack\nfnl-tests\start\fennel.vim/lua/plenary/busted.lua:239: in function <...\pack\nfnl-tests\start\fennel.vim/lua/plenary/busted.lua:238>
Success ||      replace-extension replaces extensions
Fail    ||      split-path splits a path into parts
            C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:36: Expected objects to be the same.
            Passed in:
            (table: 0x021cd2f461b0) {
             *[1] = 'foo/bar/baz' }
            Expected:
            (table: 0x021cd2f9f488) {
             *[1] = 'foo'
              [2] = 'bar'
              [3] = 'baz' }

            stack traceback:
                C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:36: in function <C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:35>

Fail    ||      join-path joins a path together
            C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:44: Expected objects to be equal.
            Passed in:
            (string) 'foo\bar\baz'
            Expected:
            (string) 'foo/bar/baz'

            stack traceback:
                C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:44: in function <C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:43>

Fail    ||      replace-dirs replaces directories in a path that match a string with another string
            C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:52: Expected objects to be equal.
            Passed in:
            (string) 'foo/fnl/bar'
            Expected:
            (string) 'foo/lua/bar'

            stack traceback:
                C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:52: in function <C:/dev/Projects/nfnl/lua/spec/nfnl/fs_spec.lua:51>

Success:        3
Failed :        4
Errors :        0

Obviously some are just failing because the path separator is incorrect for windows and should be an easy fix, but the failure due to fnl instead of lua in the path and the incorrectly split paths seem like possible candidates explaining windows issues with autocompiling

Ok I fixed the fs_spec issues and moved on to config. I think there are some real issues here. At this point me stumbling around has hit diminishing returns. Is there a way to get this into the pipeline so that we can work on the remaining issues together? I think they are real failures now

As far as trust goes, I think in my scripts that run the tests I have a line that adds trust for the file in a headless way. Maybe you worked that out but thought I'd mention it.

If so, I'll probably make the changes I suggested about porting over Aniseed and Conjure's FS / path related code that abstracts paths away into something OS agnostic. Then we can have one test that supports all OS paths.
If you want to port that code over into nfnl.fs that's cool, if not I'll get to it as well. As long as you have a branch that works for you right now I'm happy and I'll add my changes on top and get it merged ASAP, hopefully this weekend since I finally have some time at home (it's been weeks!).

It does not work yet. I'm suspicious that some of the path changes are causing the issues I encountered with finding the .nfnl.fnl file properly. I've got some time now so I'll take a stab at the changes you outlined in aniseed and conjure.
I did see your automated line for trusting, but for some reason I still get messages about not trusting in the logs still. I just noticed a typo in the runner line which is causing the actions to fail, so I'll fix that and link the exact issue.

Ok I've got the tests running. So at least now you can see the actual failures: https://github.com/Kethku/nfnl/actions/runs/9618182719/job/26531523272#step:5:49

I swapped to the neovim installer action that we use for Neovide which works well cross platform.

Ok I've tracked all this down to what I believe is a bug in the secure read code in neovim. If I add print(contents:len()) to https://github.com/neovim/neovim/blob/d82efeccc7e89230ba6673da0fdf62c09fa38c17/runtime/lua/vim/secure.lua#L73 and https://github.com/neovim/neovim/blob/d82efeccc7e89230ba6673da0fdf62c09fa38c17/runtime/lua/vim/secure.lua#L182
and then also print out a table comparing the trusted hash and the expected hash when doing the secure read, and then run the tests I get this extremely suspicious line in the test output:
4
3
{
  hash = "ca3d163bab055381827226140568f3bef7eaac187cebd76878e0b63e9e442356",
  trusted_hash = "e3566b3a06430868d71e9287dfd6c6c520a3da027aabea01951d407ee131dc2f"
}

I think what might be going on is that the code to create the contents which get hashed on the read side: https://github.com/neovim/neovim/blob/d82efeccc7e89230ba6673da0fdf62c09fa38c17/runtime/lua/vim/secure.lua#L64-L72
is different from the code that gets the contents to get hashed on the write side:
https://github.com/neovim/neovim/blob/d82efeccc7e89230ba6673da0fdf62c09fa38c17/runtime/lua/vim/secure.lua#L176-L181
Given that the length is different by only one byte and the write side is doing some new line check by buffer format I guess, it seems like somehow either the buffer format isn't getting set correctly or the file doesn't have the expected newline or some similar issue.
I'm pretty dang confident at this point that the issue is upstream, but I'd like your opinion or thoughts before I report it in the neovim repo. Maybe we could write a failing test on their side to repro the issue? Idk

Encouragingly, if we can figure out how to get the trusted read working I'm guessing that all of these issues will be resolved. I believe this because the config file that was written by you into the repository (and which has unix newlines rather than the silly windows ones) works perfectly. I can edit files in the repo, save them and auto compile just fine. Its only files that were created on my machine that run into this issue.
So if we can fix this upstream the problem should be solved for good

The tests for this code are here: https://github.com/neovim/neovim/blob/master/test/functional/lua/secure_spec.lua but on a quick glance, I don't really understand them. I'm getting a bit tired, so I'm gonna pause work on this for now, but think this is the next step if you're up for it, or I'll get back to it sometime soonish:
Add a test to secure_spec.lua which demonstrates adding a file with non windows newlines to the trust database and then being unable to trust said file afterwards due to the newline mismatch. If we can write that test, I expect the issue will get resolved quickly

I've got your branch locally and I'm taking a look + will push it so we can run the CI.

Oh! :h vim.fs.normalize()! That's what we want for always converting paths to / no matter what. Going the other way then is a little easier because we KNOW we're going from / to \. So I think we pass paths through normalize before we work with them then do a whole "backslashify" when absolutely required.

Oh and one more note that you might find useful!
			*'shellslash'* *'ssl'* *'noshellslash'* *'nossl'*
'shellslash' 'ssl'	boolean	(default off)
			global
			only for MS-Windows
	When set, a forward slash is used when expanding file names.  This is
	useful when a Unix-like shell is used instead of cmd.exe.  Backward
	slashes can still be typed, but they are changed to forward slashes by
	Vim.
	Note that setting or resetting this option has no effect for some
	existing file names, thus this option needs to be set before opening
	any file for best results.  This might change in the future.
	'shellslash' only works when a backslash can be used as a path
	separator.  To test if this is so use: >vim
		if exists('+shellslash')
<	Also see 'completeslash'.

I have some local changes that basically perform the path normalisation as we glob for paths, so ALL paths in memory should be /, then as we go to use those paths to do things Windows specific (like write to a file) we can "localize" that specific path as late as possible to avoid littering the code with conversion calls.

Pushed my current work to windows-paths branch in this repo. I have everything working on Linux again and will now use your work to get the suite running in CI on Windows to work out the Windows side. I still need to add some more tests and I don't think this will work on Windows right now but my general idea is coming together:

Anywhere a path enters the system (getting the cwd, globbing paths) we normalize those paths to all be / since that's what Neovim as a whole seems to mostly use and normalize towards, regardless of OS.
At the few points where we NEED \ we can localize those paths to the OS specific paths, but we do it as late as possible.

I want to avoid mixed slashes in the project, I want it to ALL be one style so everything is fairly easy to reason about and at the boundaries we think about what the OS cares about. I think that'll be much easier to maintain and harder to break going forward. I have avoided rebasing your commits and have tried to merge to make sure shas stay stable between our efforts.

WOAH! The tests actually ran under Windows in CI! They failed, but still, I can work with that!

Thank you for getting that working, it's amazing stuff and super helpful for the future. Not only will this help with preventing regressions in nfnl on Windows in the future (when we fix it...) but I can copy this format to other repos easily now I have a working example! Thank you!

So I'm pretty happy with the windows-tests branch right now. It exhibits the behaviour you describe around trust files, on Linux mine outputs the following into .test-config/state/nvim/trust
ca3d163bab055381827226140568f3bef7eaac187cebd76878e0b63e9e442356 /tmp/nvim.olical/D8hm4P/0/.nfnl.fnl
b8d37f0eae599447a076553deabddf848a034cae33938bfc7382e17b7d5959ab /home/olical/repos/Olical/nfnl/.nfnl.fnl

I guess the paths are part of that hash so we can't compare them between each other 🤔 so how do we go about proving this is a bug in Neovim (or not). Does it mean you basically can't use secure read in ANY way on Windows? Unrelated to nfnl entirely? Because if so that should be a fairly quick and small repro I hope?

take a look at this comment again https://github.com/Olical/nfnl/pull/42#issuecomment-2183541411
its extremely possible im missing something stupid here but to me this means the actual content is different. the file name isnt used in the hash so the difference has to be something to do with the newlines being different lengths. to me this is a straightforward bug in their lua code that i linked. if we are comparing file contents before and after, we should read the file the same exact way both times. but thats not what they do.
in one way they read the file and hash it directly. the other, they read the buffer and try to recreate the file contents by joining the lines with newlines. i dont understand how it fails but im pretty sure the failure is in the newlines selection. i think it might assume that all files on windows systems use carriage return + new lines which is for sure not always the case.
so in summary, the failure only shows up when you have a mismatch of newline kinds with the expected newline on the os. i thiiiink 😅

OH! OH WOW! Yeah that sounds plausible! It's maybe \r\n on Windows and \n
on Unixy systems. It'd be interesting to see if a file with 10 new lines is
10 bytes off.
Amazing find!
On Sat, 22 Jun 2024, 22:21 Kaylee Simmons, @.***> wrote:

take a look at this comment again #42 (comment)
https://github.com/Olical/nfnl/pull/42#issuecomment-2183541411
its extremely possible im missing something stupid here but to me this
means the actual content is different. the file name isnt used in the hash
so the difference has to be something to do with the newlines being
different lengths. to me this is a straightforward bug in their lua code
that i linked. if we are comparing file contents before and after, we
should read the file the same exact way both times. but thats not what they
do.
in one way they read the file and hash it directly. the other, they read
the buffer and try to recreate the file contents by joining the lines with
newlines. i dont understand how it fails but im pretty sure the failure is
in the newlines selection. i think it might assume that all files on
windows systems use carriage return + new lines which is for sure not
always the case.
so in summary, the failure only shows up when you have a mismatch of
newline kinds with the expected newline on the os. i thiiiink 😅
—
Reply to this email directly, view it on GitHub
https://github.com/Olical/nfnl/pull/42#issuecomment-2184193287, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACM6XNVWDVMZRBEKD6Y5LLZIXTDXAVCNFSM6AAAAABJNAACISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBUGE4TGMRYG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

So I did some research into the environment when the CI tests run. Looks like autoclrf is ON in the Windows git, which is expected. So all \n will be converted to \r\n on checkout (in theory unless something else is up).
I've also checked some Neovim settings after .nfnl.fnl is opened, looks like the buffer is not modified, fixendofline is enabled and fileformat is dos. So my theory of Neovim going into a modified state every time we open a files doesn't really hold.
fixendofline should only apply on write, but I wonder if some passive thing is modifying the buffer as it loads in :edit to give it a different sha to on disk.
I'm trying to find some config I can set that keeps the line endings and file ending consistent on disk and in memory for Neovim on Windows without breaking anything else. All of my attempts are against this branch which is rebased on main if you'd like to try anything as well: https://github.com/Olical/nfnl/tree/windows-tests
One thought I have is to use editor config + autocrlf=false in git so we keep the files as they are on Unix at all times. Basically try to keep the files byte for byte identical between Windows and Unix I guess other than the ps1 scripts which I think NEED to be CRLF encoded? Which if they are encoded like dos in git it means I can set a flag in git on the CI host to keep those as CLRF on checkout but keep every other file as unixy which might be good.

I added a special env var that disables the use of secure read and trust calls in the Windows tests. That gets us a little further but now the error is that the Lua output isn't being written!
My test code tries to check for the C:/Users/RUNNER~1/AppData/Local/Temp/nvim.0/Qu4ICF/0/lua directory which should be written to after writing to a .fnl file but it isn't there. So either that path is wrong and should be something else on Windows or maybe it's an async thing that only manifests on Windows?
If you can run the tests now on your own Windows machine and see if you see the same thing that'd be amazing. Then maybe we can inspect the file system and see if that path is wrong. Maybe it needs to be backslashes for this particular isdirectory call?
I'll leave it here for today though, another afternoon lost to Windows things 😭 I'm so bad at getting anything working on this OS.


standard

Hi,
Very nice boilerplate.
I would recommend thought replace eslint with standard :
http://standardjs.com/

Hahaha, well yeah, this is all a matter of opinion I guess.
I did actually start this project using standard, but then decided to swap out with airbnb's eslint config.  I just had a nagging feature that ";" user count dominates those without.
It's a case of we can't make everyone happy here, but I am trying to base my decision on code standards based on what I feel the majority of developers would already be doing.  I wonder if there are actual metrics for this?

Hmm.
I actually prefer standard because it is cleaner and regarding the ;,
I think it's better without because of chaining and jsx and a lot of stuff that makes it look weird...

Completely opinionated, but I like standard better as well. I made a standard fork if you want to use it @giltig React Universally - Standard.  I'll keep it up to date.

I'll add this to the docs, thanks @rlindskog !


LGP support is retired?

Hi,
It seems current version of code does not support LGP? related code is either annotated or in retired directory. Is there any plan to add it back? or how can we use the LGP? with C++ only?
Thanks!

Yes, currently the LGP methods are only maintained in C++. It the python bindings for these were too unstable, given the continuous work we do on this.


MVC sugar

I think this is a better approach to providing before/after callbacks on commands. A command is really just a controller in MVC-speak. This PR provides explicit Model, View, and Controller classes so a programmer may properly apply their business logic (using SOLID principles perhaps) and spec/test that logic separately from the bot.
We can also leverage ActiveSupport::Callbacks to provide before, after, and around hooks for any method on the models, views, or controllers. This is about as fine-grained control as we will ever have. Use the power if you need it. Ignore it if you don't (but it's there!).
This is all built on top of the existing command class method handling. The controller builds a list of its methods and produces a command 'verb' for each one. The block called by the command passes the client, data, and match args into the controller. Easy-peasy.
BTW, while developing this I ran into an issue where anonymous classes that subclassed SlackRubyBot::Command::Base did not work correctly. Anonymous classes have no name, so finalize_routes! was failing when the default_command_name was nil. Anyway, small fix for that is included.

I like it! It needs some README work to document the whole shabang, please.

@dblock I think the docs in the README are in fairly good shape. I'd appreciate it if you would give them a "once over" to make sure I didn't say anything boneheaded.
I also created a full-featured example in examples/inventory to show off the MVC classes and all of the callback hooks. The hardest part of the example was figuring out the terrible sqlite3 API... I should have just used sequel. :)

I made some minor comments. I am ready to merge this after. Maybe squash too?

Btw, with this maybe we should document how to do callbacks?

I made your suggested edits to the Changelog and Readme.
I didn't add any text on the callback mechanism. There is a LOT of documentation available from Rails sources on how this library works. I think those are sufficient. Plus, my working code at examples/inventory shows how to use each kind of callback in the MVC classes.
If you want more docs, would it be okay to put links to some of the useful sites that I used? There are some decent callback tutorials out there.
As for squash, that's a personal preference so I'll follow your lead. For my personal projects, I rarely squash. If you'd like me to squash, let me know and I'll do it.
Otherwise, this baby is ready for a merge!

Hmm, last push failed on one CI (and passed all others) but there is no useful error message here (https://travis-ci.org/slack-ruby/slack-ruby-bot/jobs/235837216). Can you kick it again to see if it will pass a second time?

I merged this squashed. Nice work.
Would you like to join the collaborators group for this project @chuckremes, maybe make the next release when we have your PRs merged?

Sure, I'll be a collaborator. My ruby gems email is git - at - chuckremes.com.

Invited here/added. Welcome Chuck! Feel free to review/merge other people's PRs and keep making your own for other maintainers (@accessd and myself) to review.

You can make a release if you have a moment, follow https://github.com/slack-ruby/slack-ruby-bot/blob/master/RELEASING.md.


Add a --universal-strategy-like setting to the resolver

In the universal resolver, we prioritize solving for as few versions as possible. Sometimes, users instead want to get the newest possible version for every fork (e.g., they'd prefer getting the newest versions of foo for Python 3.10+, even if it means they have two versions of foo in the lockfile, one for Python 3.9 and earlier, and one for Python 3.10 and later).
(--universal-strategy is obviously a bad name.)
One implementation of this would be to ignore preferences from other forks.

I'd even think this might be a nice default. Currently, the following simple example:
$ mkdir example
$ cd example
$ cat > pyproject.toml << EOL
[project]
name = "example"
version = "0.1"
requires-python = ">=3.8"
dependencies = ["numpy"]
EOL
$ uv run python
Resolved 2 packages in 7ms
error: Failed to prepare distributions
  Caused by: Failed to download and build `numpy==1.24.4`
  Caused by: Build backend failed to determine requirements with `build_wheel()` (exit status: 1)

[stderr]
Traceback (most recent call last):
  File "<string>", line 8, in <module>
  File "/Users/henryschreiner/.cache/uv/builds-v0/.tmpjYjj2d/lib/python3.12/site-packages/setuptools/__init__.py", line 10, in <module>
    import distutils.core
ModuleNotFoundError: No module named 'distutils'
  Caused by: distutils was removed from the standard library in Python 3.12. Consider adding a constraint (like `numpy >1.24.4`) to avoid building a version of numpy that depends on distutils.

will break on Python 3.12 and newer. Any package that supports a narrower range than you do (and packages should be allowed to stop supporting old Python versions) will cause you do never get updates, and updates are often required for new Python versions.
This is one of the biggest drawbacks of a universal solver, as most users starting out don't realize that "dependencies = ["numpy"]` isn't going to give them the latest version on the version of Python they are running. I think this would really reduce the friction when starting out.


fix/surge-errors-safe-check

My app saw a KeyError on errors.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

What's the .idea/vcs.xml file for?

@Subzidion that was an accidental PyCharm thing. I've rebased it out.
I have the error check just in case the API decides to return only 1 error. For instance, in HTTPError it can include a error key in the response. So, just in case.

Ah, ok. I was getting mixed up with errors versus error. The variable on line 717 should probably be called errors instead since it's a list, just to make it clearer when you're grabbing the first element on line 719. Just my two cents. Looks good to me, though.

@Subzidion did as you suggested (agreed), and then made the code a little smaller with a ternary if, for getting error set.

Looks good to me. All the tests are still passing on my machine after those changes. :+1:

So what is the next step toward this being merged?

Not sure. I'll tag @dustinwhittle and @christinekim to give them a notification about it.

Thanks for your contributions!


UseAzureKeyVault has been removed

The UseAzureKeyVault method was removed in the following commit: https://github.com/Azure/AppConfiguration-DotnetProvider/commit/d0da5dcc500c9e1edfcfddf38893102fc8c34061#diff-3be003e0f55525c62cbeec2d6654e63f
There is no example now showing how to properly setup Key Vault to use a Managed Identity as well.

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

ID: e0b5a566-084c-d77f-9d78-3bfd72b01080
Version Independent ID: b22f2729-2f31-a0cd-fc61-0ead183b0aab
Content: Integrate with Azure managed identities
Content Source: articles/azure-app-configuration/howto-integrate-azure-managed-service-identity.md
Service: azure-app-configuration
GitHub Login: @lisaguthrie
Microsoft Alias: lcozzens

@jeremytcorp Thank you for the feedback!  We are investigating this and will get back to you shortly.

@jeremytcorp I'm going to assign this to the doc author to address.
In the meantime, you can use DefaultAzureCredential() for managed identity with Key Vault, just as you do with App Config:
config.AddAzureAppConfiguration(options =>
{
	options.Connect(new Uri(Environment.GetEnvironmentVariable("AppConfigEndpoint")), new DefaultAzureCredential())
	.ConfigureKeyVault(kv => {
		kv.SetCredential(new DefaultAzureCredential());
	});
});

@jpconnock doc enhancement request FYI

I just updated the documentation to use the new ConfigureKeyVault method instead. Should be live in the next few days.

This has been published. Closing out this issue since it is now resolved.
#please-close.


first commit to make_quantile

Current dependencies on/for this PR:

main

PR #763

PR #765

PR #767

PR #769

PR #771

PR #774

PR #795

PR #819

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#854  👈
#829 : 2 other dependent PRs (#888 , #890 )
#1515
#819
#868 : 1 other dependent PR (#864 )
#797 : 1 other dependent PR (#824 )
#847
#1454
#795
#1167
#769 : 1 other dependent PR (#771 )
#767
#765
#763
#917 : 1 other dependent PR (#921 )
#916
#907
#874
#705
#754
#704
#703
#753
#702
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @PaulineMauryL and the rest of your teammates on  Graphite


Unable to create bottlerocket profile even when I mention it in the eks_managed_groups_defaults

Description
I am trying to create a bottle rocket based EKS Managed Node group, my cluster is created, the node groups are created, but it always ends up with Amazon Linux, rather than Bottlerocket.
I did notice one weird thing though if in the eks_managed_node_group_defaults map I don't include the platform and ami_id, the bottlerocket based nodes are created.  But the issue is, although AWS has issued a newer version of the bottlerocket OS terraform never recognizes a new version is out and doesn't upgrade the OS hence I tried to introduce ami_id.
If your request is for a new feature, please use the Feature request template.

[x ] ✋ I have searched the open/closed issues and my issue is not listed.

⚠ Note
Versions

Module version [Required]:
18.30.2
Terraform version:

Terraform v1.3.3

Provider version(s):
AWS 4.37.0

Reproduction Code [Required]
data "aws_ami" "eks_default_bottlerocket" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["bottlerocket-aws-k8s-${local.cluster_version}-x86_64-*"]
  }
}

module "eks_cluster" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 18.0"
  ##version = "18.30.0"

  cluster_name                    = "${var.cluster_prefix}-${var.cluster_inst}-eks-${local.region}"
  cluster_version                 = var.eks_version
  cluster_endpoint_private_access = false
  cluster_endpoint_public_access  = true
  enable_irsa                     = true
  vpc_id                          = var.eks_vpc_id
  subnet_ids                      = data.aws_subnets.this_eks_subnets.ids

  eks_managed_node_group_defaults = {
    ami_type = "BOTTLEROCKET_x86_64"
    platform = "bottlerocket"
    ami_id                                = data.aws_ami.eks_default_bottlerocket.image_id
    attach_cluster_primary_security_group = true
    create_security_group                 = false
    iam_role_attach_cni_policy            = true

    ## We do the additional policies so that SSM starts working and is reporting crap into CloudWatch
    iam_role_additional_policies = [
      "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore",
      "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
    ]
  }

  eks_managed_node_groups = {
    first_ng = {
      create_launch_template = false
      launch_template_name   = ""
      name                   = local.node_group
      instance_types         = var.instance_types
      min_size               = var.min_size
      max_size               = var.max_size
      desired_size           = var.desired_size
      ami_type               = var.ami_type
      platform               = "bottlerocket"
      ami_id                 = data.aws_ami.eks_default_bottlerocket.image_id
    }

    bottlerocket_default = {
      # By default, the module creates a launch template to ensure tags are propagated to instances, etc.,
      # so we need to disable it to use the default template provided by the AWS EKS managed node group service
      create_launch_template = false
      launch_template_name   = ""
      ami_type               = "BOTTLEROCKET_x86_64"
      platform               = "bottlerocket"
      ami_id                 = data.aws_ami.eks_default_bottlerocket.image_id
      instance_types         = var.instance_types
      min_size               = var.min_size
      max_size               = var.max_size
      desired_size           = var.desired_size
    }
  }
}

terraform init
terraform plan
terraform apply

I am using workspaces

I have cleared local cache.

Expected behavior
I expect a bottlerocket OS based EKS managed node group created in my EKS cluster.

Actual behavior
Amazon Linux based EKS managed node group is created.

Terminal Output Screenshot(s)

Additional context

You don't need to specify the AMI ID - this will pin to whichever AMI you are providing. You only need to set
    ami_type = "BOTTLEROCKET_x86_64"
    platform = "bottlerocket"

Hi Bryan,
Thanks for your response, I do have those parameters, when I query the SSM parameters for bottlerocket, I get a newer AMI than what my existing cluster is running, but terraform never sees the latest recommended ami is different hence says nothing has changed in the environment.
Hence I am trying to set the ami_id  to get the module to see there is a difference and then allow me to upgrade.
Is there a different way to go about this?
Thank you!

that is down to the managed node group service and when they update the service to use the newer AMI


Add WITHSCORES option to ZRANGE command

Description

The ZRANGE command has WITHSCORES option.
But, current node-redis package doesn't support WITHSCORES option
So, i added.

Checklist

[x] Does npm test pass with this change (including linting)?
[x] Is the new or changed code fully tested?
[ ] Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

@stories2 use ZRANGE_WITHSCORES instead. The reason it's implemented as a different commands is that the reply type is different.

@stories2 use ZRANGE_WITHSCORES instead. The reason it's implemented as a different commands is that the reply type is different.

My bad. Thanks for your help.

@stories2 thanks for trying to fix it yourself :)

Thank you! There are a lot of wrong examples out there showing that you can pass "WITHSCORES" to client.zRange as a plain string option and it was causing me a lot of confusion.

@SnowdenWintermute can you please share some links?

I guess I was exaggerating when I said "a lot", but here are the two I found. They use zrevrange which is deprecated now, and since it was replaced by zrange I assumed zrange could do what zrevrange could do and get the scores via passing an option. I eventually found this thread by searching something like "node redis zrange withscores option not included" or "doesn't exist".
https://stackoverflow.com/questions/24157632/node-redis-get-zrange-withscores
https://gist.github.com/danielrvt/91765654445006bb28e2

@SnowdenWintermute thanks for the links, I'll check them later and see if I can comment there to help others.. :)


local OpenROAD GUI crashes when loading an .odb file made by OpenROAD docker image

Describe the bug
Run a flow from Docker to create a .odb file, load with local OpenROAD GUI in Ubuntu 22, crash:
Signal 11 received
Stack trace:
 0# 0x000055F5B1B2BAD5 in openroad
 1# 0x00007FF80DA3BCF0 in /lib/x86_64-linux-gnu/libc.so.6
 2# 0x00007FF80DB71DB7 in /lib/x86_64-linux-gnu/libc.so.6
 3# 0x00007FF80DA86DAE in /lib/x86_64-linux-gnu/libc.so.6
 4# fread in /lib/x86_64-linux-gnu/libc.so.6
 5# 0x000055F5B3D643EA in openroad
 6# odb::operator>>(odb::dbIStream&, odb::_dbTechLayer&) in openroad
 7# odb::operator>>(odb::dbIStream&, odb::_dbTech&) in openroad
 8# odb::operator>>(odb::dbIStream&, odb::_dbDatabase&) in openroad
 9# odb::dbDatabase::read(_IO_FILE*) in openroad
10# ord::OpenRoad::readDb(char const*) in openroad
11# gui::MainWindow::openDesign() in openroad
12# 0x00007FF80EAF372C in /lib/x86_64-linux-gnu/libQt5Core.so.5
13# QAction::triggered(bool) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
14# QAction::activate(QAction::ActionEvent) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
15# 0x00007FF80F8F0FE2 in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
16# 0x00007FF80F8F8EEC in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
17# QWidget::event(QEvent*) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
18# QApplicationPrivate::notify_helper(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
19# QApplication::notify(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
20# QCoreApplication::notifyInternal2(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Core.so.5
21# QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
22# 0x00007FF80F7C8535 in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
23# 0x00007FF80F7CB4A0 in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
24# QApplicationPrivate::notify_helper(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Widgets.so.5
25# QCoreApplication::notifyInternal2(QObject*, QEvent*) in /lib/x86_64-linux-gnu/libQt5Core.so.5
26# QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) in /lib/x86_64-linux-gnu/libQt5Gui.so.5
27# QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) in /lib/x86_64-linux-gnu/libQt5Gui.so.5
28# 0x00007FF80A70278E in /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
29# g_main_context_dispatch in /lib/x86_64-linux-gnu/libglib-2.0.so.0
30# 0x00007FF80D5713C8 in /lib/x86_64-linux-gnu/libglib-2.0.so.0
31# g_main_context_iteration in /lib/x86_64-linux-gnu/libglib-2.0.so.0
32# QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) in /lib/x86_64-linux-gnu/libQt5Core.so.5
33# QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) in /lib/x86_64-linux-gnu/libQt5Core.so.5
34# QCoreApplication::exec() in /lib/x86_64-linux-gnu/libQt5Core.so.5
35# gui::startGui(int&, char**, Tcl_Interp*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) in openroad
36# ord::tclAppInit(Tcl_Interp*) in openroad
37# Tcl_MainEx in /lib/x86_64-linux-gnu/libtcl8.6.so
38# main in openroad
39# 0x00007FF80DA23510 in /lib/x86_64-linux-gnu/libc.so.6
40# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
41# _start in openroad
Segmentation fault (core dumped)

Expected Behavior
This used to work.
Environment
master

To Reproduce
As above
Relevant log output
No response
Screenshots
No response
Additional Context
No response

@maliberty Strange. After this fix, which I wouldn't expect to fix the error in parsing the file, I no longer get an error, nor a crash: https://github.com/The-OpenROAD-Project/OpenROAD/pull/3206

@maliberty Does .odb files have version numbers? I rebased this fix on master and then tried against the .odb file from the docker image. So if .odb files are not compatible, but do not have a version number check, that would explain the segfault.

https://github.com/The-OpenROAD-Project/OpenROAD/pull/3207

Coverity just flagged an issue related to dbIStream this morning that is likely to be the cause:
*** CID 1508956:  Memory - illegal accesses  (STRING_NULL)
/src/odb/src/db/dbProperty.cpp: 187 in odb::operator >>(odb::dbIStream &, odb::_dbProperty &)()
181         }
182         case DB_STRING_PROP: {
183           char* char_string;
184           stream >> char_string;
185           prop._value = "";
186           if (char_string != nullptr) {
>>>     CID 1508956:  Memory - illegal accesses  (STRING_NULL)
>>>     Passing unterminated string "char_string" to "basic_string", which expects a null-terminated string. [Note: The source code implementation of the function has been overridden by a builtin model.]
187             prop._value = std::string(char_string);
188             free(char_string);
189           }
190           break;
191         }
192         case DB_DOUBLE_PROP: {

I've asked @QuantamHD to fix it as it comes from his recent change.

Looks like this isn't related to the coverity as all the strings are read and serialized with a null termination.

@oharboe can you provide a specific set of steps to reproduce this issue.

@oharboe can you provide a specific set of steps to reproduce this issue.

@maliberty I provided a confidential example, not being able to reproduce with public information. Hopefully that will be enough to move this forward.

@maliberty I'll reopen a github issue if this problem persists after the sanatizer cleanups.


docker exec /bin/bash or logs error

command enter docker output the following error
OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "exec: "/bin/bash": stat /bin/bash: no such file or directory": unknown

can only use /bin/sh enter docker
2.Through docker view log is empty, enter the container content view has log

Are you trying to shell in with bash? Alpine images don't have bash installed by default, just sh.


Migrate to toolforge (and avoid 404 errors)

Tools are expected to migrate to their own subdomains: https://wikitech.wikimedia.org/wiki/News/Toolforge.org and I intend to do this soon.

The new URL (https://whois.toolforge.org) seems to be working. I try to redirect old URLs to new URLs, but if something stopped working, please report below.

This seems to be running on gridengine, migrate this tool to Python 3 and run on Kubernetes?
Also https://tools.wmflabs.org/whois/ does not redirect to https://whois.toolforge.org you seem to be running two instances of the tool or serving both sites.

Yes, the redirect from https://tools.wmflabs.org/whois/<IP_ADDRESS> works, but https://tools.wmflabs.org/whois/ doesn't.
I thought both are covered by https://github.com/whym/whois-gateway/blob/f7e7e608bc87f0c4f9789ffdf711f08aa62ca7ff/.lighttpd.conf#L10
... do you know what I'm missing?

Yes, the redirect from https://tools.wmflabs.org/whois/<IP_ADDRESS> works, but https://tools.wmflabs.org/whois/ doesn't.
I thought both are covered by
https://github.com/whym/whois-gateway/blob/f7e7e608bc87f0c4f9789ffdf711f08aa62ca7ff/.lighttpd.conf#L10
... do you know what I'm missing?

The parsed regex needs to contain something to meet the condition for redirecting. Since the regex is not matching, it will simply skip the redirect condition and move on to the next.
Try accessing http://tools.wmflabs.org/whois/gateway.py? and you will see that it gives a 404 because it skips the first redirect condition and hits the second.

What I don't understand is that /whois/(.*)$ should match against "/whois/" because '*' includes 0 repetition. But apparently it doesn't. (Or it might be in conflict with something else?)

What I don't understand is that /whois/(.)$ should match against "/whois/" because '' includes 0 repetition. But apparently it doesn't. (Or it might be in conflict with something else?)

On an unrelated note, I added a 404 page with a link to here to help finding possible issues. https://github.com/whym/whois-gateway/commit/257acd88d24693c39526f88300ef27888f1d7899#diff-2c9edf1bc06432b9b752b0d83ffbd405

Oh sorry, I didn't see this before. I made #17 proposing fixes for two URLs.