enable android build

Fix #271, tested with android ndk r19b.
I don't use build.sh but only cmake
cmake -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK/build/cmake/android.toolchain.cmake -DANDROID_CPP_FEATURES=exceptions -DANDROID_PLATFORM=android-28 -DANDROID_ABI=arm64-v8a -DCMAKE_BUILD_TYPE=Release -Donnxruntime_CROSS_COMPILING=ON -Donnxruntime_BUILD_x86=OFF -DONNX_CUSTOM_PROTOC_EXECUTABLE=/usr/bin/protoc ../cmake

My changes:

Android NDK (at least for r19b) always output x86_64-unknown-linux-gnu for -dumpmachine on my PC, so the arch should be determined by the cmake official way
Android NDK doesn't support filesystem so far (https://github.com/android-ndk/ndk/issues/609), so I set the two flags explicitly for Android. What's more, the header_files_test should be disabled if filesystem is not supported. Filesystem is not needed since fb2a44f6423ac5d4f8af9105af82f00c99ae3a46.

The result of onnxruntime_test_all on Android:

[----------] Global test environment tear-down
[==========] 957 tests from 104 test cases ran. (3713 ms total)
[  PASSED  ] 918 tests.
[  FAILED  ] 39 tests, listed below:
[  FAILED  ] GraphTransformationTests.IdentityElimination
[  FAILED  ] GraphTransformationTests.SliceElimination
[  FAILED  ] GraphTransformationTests.ConstantFolding1
[  FAILED  ] GraphTransformationTests.FuseConvBNMulAddUnsqueeze
[  FAILED  ] GraphTransformationTests.FuseConvActivation
[  FAILED  ] GraphTransformationTests.FuseConvBNNoBias
[  FAILED  ] GraphTransformationTests.FuseConvMulNoBias
[  FAILED  ] GraphTransformationTests.FuseConvAddNoBias
[  FAILED  ] GraphTransformationTests.FuseConvBNMulAddUnsqueezeNoBias
[  FAILED  ] GraphTransformationTests.FuseConvAddMul3D
[  FAILED  ] GraphTransformationTests.MatMulAddFusion_two_input
[  FAILED  ] GraphTransformationTests.MatMulAddFusion_three_input
[  FAILED  ] GraphTransformationTests.Gemm_Relu_three_input
[  FAILED  ] GraphTransformationTests.FuseConvBnAddMulFloat16
[  FAILED  ] Float16_Tests.Mul_16_Test
[  FAILED  ] InferenceSessionTests.NoTimeout
[  FAILED  ] InferenceSessionTests.DisableCPUArena
[  FAILED  ] InferenceSessionTests.CheckRunLogger
[  FAILED  ] InferenceSessionTests.CheckRunProfilerWithSessionOptions
[  FAILED  ] InferenceSessionTests.CheckRunProfilerWithStartProfile
[  FAILED  ] InferenceSessionTests.MultipleSessionsNoTimeout
[  FAILED  ] InferenceSessionTests.PreAllocateOutputVector
[  FAILED  ] InferenceSessionTests.ConfigureVerbosityLevel
[  FAILED  ] InferenceSessionTests.TestWithIstream
[  FAILED  ] InferenceSessionTests.TestRegisterExecutionProvider
[  FAILED  ] InferenceSessionTests.InvalidInputTypeOfTensorElement
[  FAILED  ] InferenceSessionTests.ModelWithoutOpset
[  FAILED  ] InferenceSessionTests.TestTruncatedSequence
[  FAILED  ] InferenceSessionTests.TestCopyToFromDevices
[  FAILED  ] InferenceSessionTests.TestL1Transformers
[  FAILED  ] InferenceSessionTests.TestL1AndL2Transformers
[  FAILED  ] InferenceSessionTests.TestCustomTransformers
[  FAILED  ] InferenceSessionTests.DisableAllTransformers
[  FAILED  ] CustomKernelTests.CustomKernelWithBuildInSchema
[  FAILED  ] CustomKernelTests.CustomKernelWithCustomSchema
[  FAILED  ] CustomKernelTests.CustomKernelWithOptionalOutput
[  FAILED  ] MemcpyTest.copy1
[  FAILED  ] Random.MultinomialGoodCase
[  FAILED  ] Random.MultinomialDefaultDType

 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.:x: daquexian sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Note: The test compiles for android only if I add
find_library(log-lib log)
target_link_libraries(libprotobuf-lite ${log-lib})

in libprotobuf-lite.cmake due to https://github.com/protocolbuffers/protobuf/issues/2719
However, libprotobuf-lite.cmake is from protobuf repo. So what is the elegant way to make this edition?

libprotobuf-lite is a static lib, you don't need to call target_link_libraries on it. Therefore, I don't think you need to change protobuf's source code.

@snnn  Thanks for your review. Even though protobuf-lite is a static lib, the compiler flag will be spread to the executable by cmake.
And what is your opinion on https://github.com/protocolbuffers/protobuf/issues/2719? -llog should be added somewhere to solve the undefined reference.

@snnn I have rebased this branch on master. However I believe -llog should be added somewhere to solve the undefined reference caused by https://github.com/protocolbuffers/protobuf/issues/2719

In CMakeLists.txt, you may add "log" to onnxruntime_EXTERNAL_LIBRARIES.

Hi @manashgoswami, could you find someone verifying this PR? Thanks

@snnn Thanks! I have updated my PR according to your advice. Now the tests compiles

Are you doing cross-compiling or native ?

@snnn cross-compiling via android ndk.

the arch should be determined by the cmake official way

Any suggestion?

@snnn My PR determines the architecture by CMAKE_ANDROID_ARCH_ABI, which is the variable set by CMake or the toolchain file. Please see the cmake manual about CMAKE_ANDROID_ARCH_ABI.

Hi @snnn @yufenglee , is there still something I need to do for this PR? :)

@daquexian can you please check-in a CI yaml file to ensure future changes don't break the Android build?

@pranavsharma Hi, I have uploaded the new ci pipeline, however, I haven't tested it and I don't know how to enable it.
I build binary directly by cmake instead of build.py, so the python part is not needed. If you approve this way, I will remove all the code about python in android pipeline.

I have tested this PR using my own azure account and verified the CI works(log: https://dev.azure.com/daquexian/onnxruntime/_build/results?buildId=14 for commit 1acfb67. I have reverted two commits which are only for my own azure pipeline). Now it can be tested in this Microsoft repo as long as an admin starts the CI. @linkerzhang @snnn @pranavsharma
And @linkerzhang , could I get the privilege to start the CI of this repo?

/AzurePipelines run

@pranavsharma Thanks! Could you please enable the new Android CI for this PR? The yaml is tools/ci_build/github/azure-pipelines/android-arm64-crosscompile-ci-pipeline.yml

@linkerzhang Thanks!


Error in console when user clicks an atom in the Atom Palette/ Periodic Table while a bond is selected

Steps to Reproduce

Launch Ketcher.
Create a structure on the canvas.
Select any bond in the created structure.
Click any atom from the Atom Palette.

Expected behavior
Nothing happens - there is no change on the canvas and no error is shown in the console.
Actual behavior
An error in the console is displayed.
Screenshots

https://user-images.githubusercontent.com/80695128/174005929-ff06644b-5e03-4c03-9b93-3b2885854112.mp4
Desktop :

OS: Windows 10
Browser: Chrome
Version: 102.0.5005.63

Ketcher version
Ketcher v2.5.0-7-gfdc516cf

Verified in Ketcher v2.5.0-9-gb32b559a


yii-bootstrap4.

Q
A

Is bugfix?
yes

New feature?
no

Breaks BC?
yes

Tests pass?
yes

the yii-core dependency of all packages must be removed.

Done.

Sync with yiisoft/yii2-bootstrap4. https://github.com/yiisoft/yii-jquery/blob/master/composer.json remove yii-core.

@terabytesoftw restarted.

we must separate all data widgets, to independent repositories, we should create yii-forms-boostrap4, yii-form-widgets and place the abstraction interface to work with any orm by default cyrcle orm.

I sincerely believe that this discussion has left the subject, simply Yii 3 will not be equal to Yii 2, and understanding what @samdark says, everything will be migrated, everything will also depend on the help of the community.

Yes but can we start in this repository?

Yes but can we start in this repository?

Ok no problem.

Already finished widgets that do not need data, we will polish them well to start with the data.

Comments describing properties should be moved from private properties to public setters.

Tests could avoid using output buffering if we'll call render() explicitly.

Comments describing properties should be moved from private properties to public setters.

In progress.

Tests could avoid using output buffering if we'll call render() explicitly.

Done.

@terabytesoftw your forgot to push ;)

Merged. Let's continue further enhancements in separate pull requests.

Thank you 👍


Fix bug dropping CEL in launcher attestations

We inadvertently dropped the launcher's canonical event log when refactoring in #419. This fix adds back the launcher CEL and adds a unit test that checks for CEL measurements in the MachineState.
Failing Unit Test Before Fix:
2024/04/12 18:01:17 Refreshed container image signature cache: [0xc00030e260 0xc00030e280]
2024/04/12 18:01:17 Found container image signatures: [0xc00030e260 0xc00030e280]
--- FAIL: TestAttest (0.00s)
--- FAIL: TestAttest/all_experiment_flags_disabled (0.17s)
/Users/wuale/Projects/go-tpm-tools/launcher/agent/agent_test.go:389: got image ref , want image ref gcr.io/fakeRepo/fakeTestImage:latest
/Users/wuale/Projects/go-tpm-tools/launcher/agent/agent_test.go:392: got image digest , want image digest sha256:adb591795f9e9047f9117163b83c2ebcd5edc4503644d59a98cf911aef0367f8
/Users/wuale/Projects/go-tpm-tools/launcher/agent/agent_test.go:398: got args [], want length 1
--- FAIL: TestAttest/enable_signed_container (0.40s)
/Users/wuale/Projects/go-tpm-tools/launcher/agent/agent_test.go:389: got image ref , want image ref gcr.io/fakeRepo/fakeTestImage:latest
/Users/wuale/Projects/go-tpm-tools/launcher/agent/agent_test.go:392: got image digest , want image digest sha256:adb591795f9e9047f9117163b83c2ebcd5edc4503644d59a98cf911aef0367f8
/Users/wuale/Projects/go-tpm-tools/launcher/agent/agent_test.go:398: got args [], want length 1
FAIL
FAIL    github.com/google/go-tpm-tools/launcher/agent   0.926s
FAIL

/gcbrun

/gcbrun

/gcbrun


early emit trigger confuse me - CH6 - customWindow

the OneSecondIntervalTrigger in customWindow CH6 which aims to early emits result on one second interval has onElement and onEventTime method. I can understand the code in onElement method,i.e. when the first event arrived in ths window,it will register this window's first event-time callback function which will fire at most one second after.
if (!firstSeen.value()) {
  // compute time for next early firing by rounding watermark to second
  val t = ctx.getCurrentWatermark + (1000 - (ctx.getCurrentWatermark % 1000))
  ctx.registerEventTimeTimer(t)
  // register timer for the window end
  ctx.registerEventTimeTimer(window.getEnd)
  firstSeen.update(true)
}

However,in onEventTime(timestamp,widnow,context) method, the following trigger confuse me.
   } else {
  // register next early firing timer
  val t = ctx.getCurrentWatermark + (1000 - (ctx.getCurrentWatermark % 1000))
  if (t < window.getEnd) {
    ctx.registerEventTimeTimer(t)
  }
  // fire trigger to evaluate window
  TriggerResult.FIRE
}

the new trigger's fire time seams like is the same as the first trigger when the new next watermark has not arrived. In my opinion, this will fire subsequent triggers as soon as possible but not one second interval until new watermark arrived or the trigger which register time is window.getEnd fired.
I'm a beginner in Flink, as I understand it, the following trigger should register like this:
 val t = timestamp + (1000 - (timestamp % 1000))

I'm not sure whether you have other intentions to do that. I'm pleasure to discuss this issue with any one look this.
And wish the author finish this book soon. This is a great book though it is only a Early Release version. I'm benefit from it a lot. I will buy one on Amazon once it releases.

I understant it. The value of ctx.getCurrentWatermark between onElement and onEventTime is defferent. The onEventTime method only execute when the watermark's timestamp pass by the callback function's register time.Thus ,when onEventTime method execute means new watermark arrived which timestamp pass by the trigger's time. So, the ctx.getCurrentWatermark in onEventTime is a new value. And thus,the trigger fires at most one second depend on the rate that watermark created. The default interval which watermark is auto created is 200ms, when the interval is less than 1 second,the trigger fire one second, and when the interval is larger than 1000 ms,i.e. 1 second,the interval trigger fired is  the watermark interval. e.g. when create watermark every 2500ms,the trigger fired interval is 2500ms,i.e. 2.5 second.
For example,the first watermark's timestamp is 0,the second watermark's time is 2500,the third watermark'time is 5000.
And, thus, the first trigger's register time is 1000. When second watermark arrived in 2500,the onEventTime execute,the first trigger fired in 2500. And then new trigger with new register time created.
The secode trigger's register time is upper bound of 2500,i.e. 3000. When the third watermark arrived in 5000,the onEventTime execute again,and the second trigger fired in 5000.
So the interval trigger fired between first trigger and secode trigger is 5000 - 2500 = 2500. Equals to watermark's interval.


[FLINK-28334][table-planner] Fix PushProjectIntoTableSourceScanRule: covers the case when table source SupportsReadingMetadata and not SupportsProjectionPushDown

What is the purpose of the change
To fix the error when a table source SupportsReadingMetadata and not SupportsProjectionPushDown in PushProjectIntoTableSourceScanRule.
Brief change log
fix the logic of rewriteProjects in PushProjectIntoTableSourceScanRule
Verifying this change
Add new cases into TableSourceTest
Does this pull request potentially affect one of the following parts:

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

Documentation

Does this pull request introduce a new feature? (no)

@flinkbot run azure

@flinkbot run azure


Tweak darkmode tagline color to match the "grayness" of the light mode tagline

I think #555 reduces the text contrast, and hence makes it unreadable for some people.
You can check it with the contrast ratio in devtools accessibility.


instructs travis-ci to use JDK8, adds gitattributes for line ending enforcement

Readme updates and failure testing on javadoc

@JigarJoshi @YuriKap JDK8 makes the javadoc fail as expected :)


Creating TPFs from FFIs

This PR intends to add a feature that lets users cutout a TargetPixelFile from a series of images (e.g. FFIs), inspired by @amcody's TPFMaker.
Example use
    >>> import glob
    >>> import numpy as np
    >>> from astropy.coordinates import SkyCoord
    >>> from lightkurve.targetpixelfile import create_tpf_hdu, KeplerTargetPixelFile

    >>> images = np.sort(glob.glob("/home/gb/proj/k2superstamp/lagoon/*fits"))[0:50]
    >>> position = SkyCoord('18h04m10.10s -24d24m10.4s', frame='icrs')
    >>> hdu = create_tpf_hdu(images, position, size=(10, 10))

    >>> tpf = KeplerTargetPixelFile(hdu)
    >>> lc = tpf.to_lightcurve()

Known issues

[ ] WCS is incorrect
[ ] TIME values are incorrect (not in BKJD)

Codecov Report

Merging #41 into master will decrease coverage by 5.64%.
The diff coverage is 14.4%.

@@            Coverage Diff             @@
##           master      #41      +/-   ##
==========================================
- Coverage   94.07%   88.42%   -5.65%
==========================================
  Files          17       17
  Lines        1552     1667     +115
==========================================
+ Hits         1460     1474      +14
- Misses         92      193     +101

Impacted Files
Coverage Δ

lightkurve/targetpixelfile.py
61.92% <14.4%> (-30.6%)
:arrow_down:

Continue to review full report at Codecov.

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

I cleaned up the implementation and added both from_fits_images() and to_fits() methods to KeplerTargetPixelFile.  This PR now allows you to cut out TPFs from both K2superstamp and TESS FFI data!!
K2SUPERSTAMP example
import glob
import numpy as np
from astropy.coordinates import SkyCoord
from lightkurve.targetpixelfile import KeplerTargetPixelFile

images = np.sort(glob.glob("/home/gb/proj/k2superstamp/lagoon/*fits"))[0:20]
position = SkyCoord('18h04m10.10s -24d24m10.4s', frame='icrs')
tpf = KeplerTargetPixelFile.from_fits_images(images, position=position, size=(10, 10))
tpf.to_fits("/tmp/my-lagoon-tpf.fits", overwrite=True)

TESS FFI example
images = np.sort(glob.glob("/home/gb/proj/tess-simulations/data/ete-6/ffi/2019/132/1-1/*ffic.fits"))[0:20]
position = SkyCoord(254.45420833, 3.35275000, frame='icrs', unit='deg')
tpf = KeplerTargetPixelFile.from_fits_images(images, position=position)
tpf.to_fits("/tmp/my-tess-tpf.fits")

TODO

[ ] We're not writing the correct WCS to the TPF yet.
[ ] The TESS example should really produce a TessTargetPixelFile.
[ ] Time is not written in units BKJD.

However none of this is particularly important -- this PR should now be good enough for us to start preparing a notebook to show how TESS FFI images can be mined using lightkurve!

The TESS example should really produce a TessTargetPixelFile

I have yet to code up the TessTargetPixelFile class, but I wanted to wait for this to get in first =D

Do we support errors in TPF maker? It would be great to keep them if possible.

Also could we please support fitsio instead of astropy? It's taking ages to read in all the fits images.

Most of the Keplre cluster images had the  "'Cosmic ray in optimal aperture'" flag set, and were being masked out by the DEFAULT_BITMASK being applied in KeplerTargetPixelFile.
I have updated this PR to move the "'Cosmic ray in optimal aperture'" flag from DEFAULT_BITMASK to HARD_BITMASK.  This is a bit risky because I don't fully understand how frequent or important this flag is in non-cluster data, so we may want to revise this decision in the future.

I addded a few more improvements and unit test.  I think the basic functionality is now ready to be merged in time for tess.ninja! Thanks @christinahedges & @gully for testing today.
There are some outstanding improvements for which I am going to open a separate issue:

The WCS is not carried through yet.
The performance is slow; using fitsio may be better.
The unit test coverage is not complete.


Remove version constraints as the errors were fixed upstream

Codecov Report

Merging #170 (cba93b4) into main (e1a155b) will decrease coverage by 0.09%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##              main     #170      +/-   ##
===========================================
- Coverage   100.00%   99.90%   -0.10%
===========================================
  Files           57       57
  Lines         2147     2145       -2
  Branches       286      286
===========================================
- Hits          2147     2143       -4
- Misses           0        2       +2

Impacted Files
Coverage Δ

dask_sql/input_utils/hive.py
90.00% <0.00%> (-10.00%)
:arrow_down:

dask_sql/utils.py
100.00% <0.00%> (ø)

dask_sql/context.py
100.00% <0.00%> (ø)

dask_sql/physical/rel/custom/predict.py
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Enhancements in Repo-to-PDF: TypeScript Transition & New PDF Options

Hello @BankkRoll,
This pull request incorporates a significant number of changes and improvements to the Repo-to-PDF package. Our primary aim is to make the package more flexible and user-friendly.
Key changes include:

Transition from JavaScript to TypeScript: To enhance code quality and dev ex, we've converted the existing JavaScript codebase to TypeScript.

More Options for PDF Generation: We have added several options for the PDF generation process, providing users with increased customization. Now, users can:

Include or exclude line numbers in the PDF.
Choose whether to include code highlighting in the PDF.
Decide whether to remove comments from the code.
Opt to remove empty lines from the code.
Decide between a single large PDF file or individual PDFs per file in the repo.
When choosing a single large file, users can decide to add page numbers and a table of contents.

Customizable Ignore Settings: Users can now create a repo2pdf.ignore file in their repository root to specify file types and directories to ignore during the PDF generation.

README Update: We've updated the README to reflect these changes, including new usage instructions.

As a result of these major changes and improvements, we have proposed to update the version from 1.2.1 to 2.0.0.
We believe that these changes will greatly enhance the Repo-to-PDF package and its utility for users. We hope you'll consider merging these improvements into the main project and publishing a new version on NPM.
Best Regards,
malpou & LucasionGS

While the bulk of the improvements have been completed and are ready for review, we are still in the process of refining a couple of features:

Table of Contents: We are actively working on the 'table of contents' feature. We want to ensure that it accurately reflects the repository's structure and provides a helpful navigation aid for larger PDFs.

Page Numbers: We've encountered a specific issue with the page numbering where the first-page number is being appended to a new page at the end of the PDF. This is clearly not intended behavior, and we are currently debugging to resolve this issue to ensure that page numbers consistently appear in their correct locations.

We aim to have these updates completed soon. We'll push our changes and provide a status update once they are ready.

Wow! I apologize for the delay in responding to your message. It has come to my attention rather late in the evening, and I shall make it a priority to thoroughly review and address the requests you have made tomorrow. Your dedication and expertise has surpassed my expectations, and I am truly impressed by the progress you all have achieved thus far. I've never had contributions to my projects to this extent, so I'm blown away! The project, originally started as a small AI conversion task. I extend my sincerest gratitude to both @malpou and @LucasionGS for your exceptional work. Again,  I apologize for the delay. I will provide further updates and insights on the matter when I revisit this tomorrow.

On vacation at the moment, i'll take a look at the last things sometime next week.

Hey no rush at all, just checking to see if there was any updates on this PR @malpou ? Just getting some new forks and downloads and would love to have your updated version. Thanks!

Have had some work to take care of, i'll clean up a branch with What is working right now.
And then we'll fix the last few things when time allows it.

Hi @BankkRoll , it should be ready now.
I skipped the table of contents for now since it was still causing some issues.
Best regards
Malthe

Hey @malpou,
I've done testing on the proposed changes with a variety of repositories and the results have been consistently excellent. However, when applying the changes to certain specific repositories, notably the freeCodeCamp repository, I've encountered a couple of distinct errors.

The error message Could not find the language '', did you forget to load/include a language module? occurred. The fix for this should involve verifying the language before attempting to apply highlighting.
A Fatal JavaScript invalid size error was also triggered.

These changes you have made will be merged into V2.0.0, and I will implement a patch (2.0.1) to address the first issue. The fatal error might be indicative of a need for further code optimization or could point towards a memory leak.
I would like to express my appreciation for both of your valuable contributions once again!

Thanks for the merge.
When the time comes around, I'll make a PR for the table of contents.
Have a good one until then 😄


Add gcc printf format attribute to yara_yywarning

This attribute helps catching issues related to printf-like format string when yara_yywarning is called. As it only exists in gcc and clang (not MSVC), add a suitable macro in utils.h.
Fixes: https://github.com/VirusTotal/yara/issues/913

Thanks for your review. I have updated my commit.


Should be able to change/set label color on textField, textarea, etc.

not sure how we want to solve this if label is a prop instead of a component.  we probably don't want to add labelStyle prop


Create an intro

Add an intro about yourself: who are you, what is your strength, why are you here.

Completed!


Updated index.html

Added a popular code editors under "What Code Editor Are You Using?"
UltraEdit
I think it will balance the 3rd column 4*4

Great :)


perf: Add build logic, and upgrade it

Based on https://github.com/Granulate/gprofiler/pull/68
Description
Dockerfile stuff are based on https://github.com/Granulate/linux/blob/granulate-perf/tools/perf/Dockerfile.
@DanielShaulov note - bringing back the process comm & not thread.
Motivation and Context
For the build logic - see #68.
For the upgrade - it's a revert of the revert https://github.com/Granulate/gprofiler/pull/14.
How Has This Been Tested?

[ ] On <3.16 kernel - where there's no PERF_RECORD_MISC_COMM_EXEC, what happens
[x] Post 3.16 - do we really get the process comm instead of thread?

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] I have updated the relevant documentation.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Rebased post https://github.com/Granulate/gprofiler/pull/68

I used this snippet:
import ctypes
from threading import Thread

def burner():
    libc = ctypes.CDLL("libc.so.6")
    libc.prctl(15, "blabla")
    while True:
       pass

t = Thread(target=burner)
t.start()

On my machine:

Testing gProfiler 1.0.4 with --no-python, the bottom stack ends up as blabla.
Testing this build with --no-python, the bottom stack ends up as python2 (I ran it with python2 ...)

@DanielShaulov testing on CentOS 6 with these details:
[2021-05-16 13:32:49,008] INFO: gprofiler.utils: gProfiler Python version: 3.6.8 (default, Nov 16 2020, 16:55:22)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)]
[2021-05-16 13:32:49,008] INFO: gprofiler.utils: gProfiler run mode: standalone_executable
[2021-05-16 13:32:49,008] INFO: gprofiler.utils: Kernel uname release: 2.6.32-754.27.1.el6.x86_64
[2021-05-16 13:32:49,008] INFO: gprofiler.utils: Kernel uname version: #1 SMP Tue Jan 28 14:11:45 UTC 2020
[2021-05-16 13:32:49,008] INFO: gprofiler.utils: Total CPUs: 1
[2021-05-16 13:32:49,009] INFO: gprofiler.utils: Total RAM: 0.97 GB
[2021-05-16 13:32:49,025] DEBUG: gprofiler.utils: Running command: (ldd --version)
[2021-05-16 13:32:49,032] DEBUG: gprofiler.utils: (['ldd', '--version']) exit code: 0
[2021-05-16 13:32:49,033] INFO: gprofiler.utils: Linux distribution: ('CentOS', '6.10', 'Final')
[2021-05-16 13:32:49,033] INFO: gprofiler.utils: libc version: ('glibc', b'2.12')

1.0.4 gives me the following collapsed file (running the above burner):
blabla;PyEval_EvalFrameEx 70
blabla;[/usr/lib64/libpython2.6.so.1.0] 28
blabla;PyThreadState_Swap@plt 1
flush-202:0;blk_queue_bio_[k] 1

and this build gives:
python2;[/usr/lib64/libpython2.6.so.1.0] 100

Perhaps perf fills in the missing values despite PERF_RECORD_MISC_COMM_EXEC missing? I ran the Python script prior to running perf, which means it generates those events "delayed".
Alternatively, maybe CentOS backported this perf event? I'll check

Appears to be backported...
$ perf script --show-task-events
...
python   590<PHONE_NUMBER>74: PERF_RECORD_COMM exec: python:590/590
....

The  exec parts tells the source.
	if (event->header.misc & PERF_RECORD_MISC_COMM_EXEC)
		s = " exec";
	else
		s = "";

I see PERF_RECORD_MISC_COMM_EXEC in /usr/src/kernels/2.6.32-754.27.1.el6.x86_64/include/linux/perf_event.h so I assume they backported it.

@guybortnikov looks like the Docker cache fails for whatever reason - https://github.com/Granulate/gprofiler/pull/69/checks?check_run_id=2604047740. I'll look into it tmrw. Might make sense to make it "allow failure" tho.

Tested on Ubuntu 14.04 (the same script). 3.13.0-170-generic. I checked its /usr for existence of PERF_RECORD_MISC_COMM_EXEC - none.
This is the result, for both gProfiler 1.0.5 and this branch
b;[unknown];[unknown];PyEval_EvalFrameEx 100

(funny that b is not blabla but it does show the point)

(also signals something bad, no symbols in this case? will check)

I downgraded libunwind & elfutils back to the version we'd used earlier. Will upgrade them in another PR, not mixing stuff here.

@guybortnikov when CRing - can double-check me and compare this Dockerfile to https://github.com/Granulate/linux/blob/granulate-perf/tools/perf/Dockerfile.


[prettier-plugin-sql] doesn't support esmodule out of box ?

I write a demo in index.mjs, which looks like:
const sourceCode = `
select * from s_table;select * from g_table;`

import * as prettier from "prettier"
import SqlPlugin from "prettier-plugin-sql";

let result = prettier.format(sourceCode, { plugins: [SqlPlugin], parser: 'sql'});

result.then(v => console.log(v))

then I execute node index.mjs, there is an error:
node:internal/errors:478
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/xxxxx/Project/prismjs-demo/node_modules/prettier-plugin-sql/lib/languages' imported from /Users/xxxxx/Project/prismjs-demo/node_modules/prettier-plugin-sql/lib/index.js

Are you going to support esmodule out of box ?

I cannot reproduce it, it likes you're using an old version of prettier-plugin-sql.

OK,I will check it later.
发自我的iPhone
------------------ Original ------------------
From: JounQin @.>
Date: Wed,Jun 12,2024 9:29 PM
To: un-ts/prettier @.>
Cc: JasonZhang @.>, Author @.>
Subject: Re: [un-ts/prettier] [prettier-plugin-sql] doesn't support esmoduleout of box ? (Issue #370)

I cannot reproduce it, it likes you're using an old version of `prettier-plugin-sql`.

You're right, my local version of this plugin is 0.4.1, I'll try new version instead,  thanks.


[Question] Adding an Example Demo File

Would it be possible to add a demo file you've been using for testing for those of us who also don't have the beta?

I don't have beta myself either :smile: . Markus hosted some, see this issue: https://github.com/markus-wa/demoinfocs-golang/pull/384. Also not sure if all of them work or what type of demos they even are. At least some of them should work :laughing:

See this :laughing: https://github.com/markus-wa/demoinfocs-golang/pull/384. (sorry Markus if you didn't want me to share this 😬)


Add some android methods

Hi, thanks for the PR.
I've been arguing with myself what should be the default values for:
enableVibrate - battery drain when true?
enableInAppAlertNotification - UX wise annoying, default to false according to OneSignal.
Can you change those to false?

Do you think that we need to override default OneSignal settings? enableVibrate is true by default and it's OK, I think. It will be confusing for the users if the behaviour of the lib will not be as same as described in OneSignal documentation.

OK, agreed with enableVibrate, but enableInAppNotification should set to false.

It's false by default. As describer in documentation here: https://documentation.onesignal.com/docs/android-sdk-api#section-enableinappalertnotification "By default this is false and notifications will not be shown when the user is in your app, instead the NotificationOpenedHandler is fired."

My bad, just now noticed that you haven't override anything...
Testing and merging.

@avishayil thanks! can you please also update the npm version?

Done


Drone CI

The Drone CI tests aren't yet building successfully.      Still, this could be merged and then continue to debug.

Merged, thanks. I'm working on the errors.


Feat/flutter osm

These changes have already been merged to main, as far as i can tell.
@iAlanx3 can you verify this?

No file changes anymore


Add examples/play-h264-from-disk

Description
It doesn't work in Chrome. Only Firefox has been tested successfully.

Also tried something similar with the RaspberryPi as it outputs raw h264. Also just worked for firefox and safari.
The only big differences I noticed are in the SDP generated by Chrome and the others. The one from chrome is much larger and detailed it seems, not sure the issue relies there though.
Looking at chrome://webrtc-internals it seems to be getting all the data, just drops all frames it receives. Might be something that pion is doing wrong internally

I just checked this and it works on chrome on windows. I read somewhere that h264 on chrome on mac is not very well supported.

Hey @chertov
Sorry it took so long to review this, I have been really pulled into /v3. Would it be possible to rework this as a H264Reader ? This is a fantastic implementation, just hard to use since all the code is in the examples directory
When that is merged people will start being able to use it today! I also plan on making a ffmpeg example in example-webrtc-applications that shows how to use ffmpeg via stdin :)
thanks

@Sean-Der hi! Sorry for late answer!
I can try to move a h264 parsing code to https://github.com/pion/webrtc/tree/master/pkg/media/h264reader and add some tests for nal parsing process from my rust code. Will it be a good solution?

@chertov yes that would be amazing!
It doesn't have to be perfect either. Happy to merge with some TODOs :)

@chertov just checking in here :) any chance you have bandwidth to make the suggested changes? would love to land this!

Hello, I have tried to run the example. I have following output:
Connection State has changed checking
<SDP here>
Connection State has changed failed

How can I debug this? Are there log files?

Closing for #1502 thanks for starting this @chertov !


I have a problem after training is complete

Hello, thank you very much for your open source code. I am currently encountering a problem. When I train image registration at a large angle, the configuration file is as follows:
data:
name: homographies
data_dir: revisitop1m
train_size: 150000
val_size: 2000
batch_size: 128
num_workers: 14
homography:
difficulty: 0.7
max_angle: 180
photometric:
name: lg
After I trained and fine-tuned, I loaded the generated trained model into lightglue. Even if I ran the code with the same image, the effect of the generated image was as

Hello, could you please share the parameters of the pre-trained model after training with the homography dataset? Thank you very much


Path is decoded in createLocation

This results in an invalid URL being pushed to the HTML5 history element when there are encoded percent signs in the pathname.
E.g.:
history.push({
  pathname: `randomlocation/${ encodeURIComponent("AB%C") }/furthermore`
});

results in "randomlocation/AB%C/futhermore" being pushed to the HTML5 history.

Alright, so just to be clear, the reasoning behind decoding in createLocation is that it allows us to have location object's whose pathname is decoded. That means that React Router users can use decoded strings in their route paths.
// with decoding
<Route path='/역사' />
// without decoding
<Route path='/%EC%97%AD%EC%82%AC' />

Another effect of this is that params will be automatically decoded.
<Route path='/greeting/:word' />
// user visits /greeting/안녕하세요
match === {
  ...,
  params: { word: '안녕하세요' }
  // without decoding this would be %EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94
}

History then relies on the browser to automatically encode the pathname when we push to the browser. This appears to work for all characters except for the percent sign.
There are a few thought I have on possible ways to deal with this:
Stop all decoding
I don't think that this is desirable, but I'll at least throw it out there. We could leave the decoding to the program that is using history's locations. location.pathname would just be what the user provides. Of course, this would lead to to inconsistencies between the locations created from window.location and locations created from values passed by the user.
// URI = '/역사'
// window.location.pathname = '/%EC%97%AD%EC%82%AC'
{ pathname: '/%EC%97%AD%EC%82%AC', ...}

history.push('/역사')
{ pathname: '/역사', ...}

Add a raw property
Before we decode the pathname, we can store the original value as location.raw (or maybe rawPathname, name isn't important here). Then, when we create a URI, we would concatenate using location.raw instead of location.pathname.
Prevent decoding of %25
Instead of just calling location.pathname = decodeURI(location.pathname), we could modify that to skip decoding the character string %25, which is % encoded.
const decodeButSkipPercent = pathname => (
  pathname.split('%25')
    .map(decodeURI)
    .join('%25')
)

That would work, but we would also end up with location's whose pathname is not necessarily fully decoded. The exception should only apply to the encoded percent sign, but it is still an exception.

I'm not sure which of these is the best choice (or maybe there is a better alternative that I did not think of?) :woman_shrugging:

Of course, this would lead to to inconsistencies between the locations created from window.location and locations created from values passed by the user.

I'm sorry, I'm not familiar with the code, but is it not possible to decodeURI only and only when creating a location from window.location? I'd assume the apps/devs would never read the location directly from there, because they access it via this lib? This is the place where history does know the context and can behave accordingly?

what is the recommended workaround for this? in components, the route params are only partially decoded, see referenced issue. we have file names that are coming from users, and sometimes they have ? in the name.

I have the same problem.
I try to push this to the history:
history.push('/data/Amazing%20Example')
and history converts this to the url: http://localhost:3000/data/Amazing Example
History removes my empty space! But why :)

I guess I have a similar issue as @janhoeck
I want to encode part of my link because it contains stringified object
to={ /123/${encodeURIComponent(JSON.stringify({ encode: "me" }))} }
But when I now click on the link, it ends up being
#/123/{"encode"%3A"me"}
this on the url...it kinda works but what dies for me is when someone pastes such URL to slack or some other location. Clicking on that does another set of encoding magic and then the url does not work anymore.
How can I work around it? ( 2x encodeURIComponent is not really a nice fix...but would kinda help right now :D )

I patched our local copy of history to remove all decoding of location.pathname. It fixes all my issues and I'm yet to see any side effects. Is there anything I could watch out for?

@pshrmn @mjackson How do you think we should move forward? I would be happy to help implement the solution, whatever we think is best. This is quite a common issue so I'm keen to get it solved.

Is perhaps a reasonable solution to do the re-encoding manually instead of relying on the browser? The browser can't encode % because it doesn't know if the provided value is already encoded or not, but we know our value is not because we've already decoded it. Seems like making the result of createHref here a URL with an encoded path should work:
https://github.com/ReactTraining/history/blob/master/modules/createBrowserHistory.js#L175-L179

What we ended up doing is:

Imagine a scenario where we have links like #dashboard/:name.

We add full real links to these a elements after manually encoding strings like:
<a href={`#dashboard/${encodeURIComponent(name)}`}>{name}

A sample name is:
'~`!1@2#% 3$45^6&7*8()-_+={}[]\\;"\'<,>.?'

The link turns out to be:
#dashboard/'~%60!1%402%23%25%203%2445%5E6%267*8()-_%2B%3D%7B%7D%5B%5D%5C%5C%3B%22%5C'%3C%2C%3E.%3F'

This means we are not relying on manual history.push(...); action.

When a user clicks on the link, the router detects this, since this is the native History API action.

The underlying react-router match returns us an incorrectly, partially decoded name like:
'~`!1%402%23% 3%2445^6%267*8()-_%2B%3D{}[]\\%3B"\'<%2C>.%3F'

So, we ignore this value and instead read the real URL directly from the URL like:
// The underlying `History` module has an unexpected behavior where it incorrectly handles URLs with percentage `%` sign.
// At the time of writing this is still an open issue       https://github.com/ReactTraining/history/issues/505.
// Therefore, we fall back to reading the properly encoded URL directly from the browser URL.
// The forward slash is excluded from the scaling plan names, so the below is safe for our use case.
const nameEncoded = location.hash.match(/[^\/]+\/([^\/]+)(\/.*)?/)[1];
const name = decodeURIComponent(planNameEncoded);

This became our workaround.

I'd like to see a permanent resolution on this that would not require the hacks listed above to safe decode values. The difference in behavior between a in-app routing and sharing a URL is a deterrent to my team upgrading to RR4.
@pshrmn your option of Add a raw property looks to be the best option so far IMO. It doesn't interfere with anyone's application and is handled completely by RR. It allows teams using RR3 and below to migrate to RR4 without another breaking change.
We heavily rely on URL encoded values in our routes because we have lots of special characters and spaces in our target resources. I don't want to base64 encode these names because the routes then become much less readable and not as "share-friendly"

+1 for the vote of raw properties -- but honestly, any solution to this, which is a real pain to deal with for anyone using special characters in identifiers, would be better than nothing.

IIUC, here's a summary of the problems caused by history's decoding of the pathname:

pathname (and thereby also params) is decoded using decodeURI, and browsers do not re-encode percent (%) characters, resulting in invalid URLs: see original post in this issue
pathname (and thereby also params) is not fully decoded (characters such as space are decoded, but characters such as & are not) because decoding uses decodeURI, which does not decode all characters, instead of decodeURIComponent, which does decode all characters. See https://github.com/ReactTraining/history/issues/505#issuecomment-359550278

I would like to fix 1 by stopping all decoding of pathname. This brings the behaviour inline with the native push API and other frameworks such as Express.
We can then build on that to fix 2 by decoding params using decodeURIComponent instead of the current decodeURI. This brings the behaviour inline with other frameworks such as Express.
I'd like to understand the implications of the suggested fix, to stop all decoding.
Quoting @pshrmn in https://github.com/ReactTraining/history/issues/505#issuecomment-318119540

the reasoning behind decoding in createLocation is that it allows us to have location object's whose pathname is decoded. That means that React Router users can use decoded strings in their route paths.

As an alternative, why can't React Router decode the pathname internally as it matches route paths?

Another effect of this is that params will be automatically decoded.

They are automatically decoded, but only partially so. This is because history uses decodeURI, which does not decode all characters, instead of decodeURIComponent, which does decode all characters. This makes it difficult (impossible?) for users who want the fully decoded param.
We can compare this behaviour with Express, which automatically decodes the values in req.params (using decodeURIComponent). In my opinion this is is favourable.

Of course, this would lead to to inconsistencies between the locations created from window.location and locations created from values passed by the user.

Could you elaborate on this point to help me understand what the problem is?

// 1. start on root
{ pathname: '/' }
// 2. navigate to /역사
{ pathname: '/역사' }
// 3. navigate to /some-other-page
{ pathnamE: '/some-other-page' }
// 4. click browser's back button
{ pathname:  '/%EC%97%AD%EC%82%AC' }

Locations 2 and 4 are the same, but have different pathname values.
history cannot just encode the pathname because it doesn't want to double encode. This means that it would be the onus of the library using history to provide encoded pathnames to create consistent locations.

Locations 2 and 4 are the same, but have different pathname values.

Forgive me but I still don't fully follow you.
If we take the native API as an example, when navigating to /역사, window.location.pathname matches that of 4 (after navigating to some other page and then back). So I don't see the problem?
// 2. navigate to /역사
window.history.pushState(null, '', '/역사')
// => { pathname: "/%EC%97%AD%EC%82%AC" }

history only generates the pathname from window.location.pathname for the initial location and when popping.

I see.

This means that it would be the onus of the library using history to provide encoded pathnames to create consistent locations.

That sounds reasonable to me, but it sounds like you think it's unreasonable?

I like "bytes on the outside, unicode on the inside", so having location.pathname be encoded seems wrong to me. As far as what should happen, I don't really know. I don't think there is a "right" answer. However, pushing the encoding responsibility to React Router and other packages that use history just spreads the pain instead of taking care of it here.
I don't actually use history/React Router (I have my own history/router), so I don't really want to advocate strongly one way or the other for something that doesn't actually affect me. My implementation uses location.rawPathname, which I think works well, but I also don't have a million+ weekly downloads, so I can afford to experiment more.

I think having location.pathname be encoded seems right to me because it mirrors the behaviour of the native window.location.pathname.

However, pushing the encoding responsibility to React Router and other packages that use history just spreads the pain instead of taking care of it here.

IIUC, if location.pathname was encoded, React Router would have to decode it for matching paths of Route components. Can you think of any examples when else would it need to be decoded?
If it's encoded, at least libraries have the choice of using the encoded version or decoding it to use the decoded version. If it's already decoded, they have no way of accessing the encoded version (unless we add another property like rawPathname).
If we were to add a rawPathname to represent the encoded pathname, keeping pathname decoded, which property would then be used to derive params? I'm curious how/if this would help to solve the bug whereby params are not fully decoded.

just to add into this, here's what i've been using as a workaround if I feel like this may affect a certain route:
export function cleanParams(params) {
  // cleans the params and returns a new params object
  const newParams = {}
  Object.keys(params).forEach(param => {
    let newParamValue = params[param]
    newParamValue = newParamValue.replace(/%26/gi, '&')
    newParamValue = newParamValue.replace(/%3F/gi, '?')
    newParamValue = newParamValue.replace(/%23/gi, '#')
    newParamValue = newParamValue.replace(/%2B/gi, '+')
    newParams[param] = newParamValue
  })
  return newParams
}

and I pass it this.props.match.params
seems to be working for my current use cases.

slightly cleaner version:
export function cleanParams(params) {
  // cleans the params and returns a new params object
  return Object.keys(params).reduce((newParams, param) => {
    let newParamValue = params[param]
    newParamValue = newParamValue.replace(/%26/gi, '&')
    newParamValue = newParamValue.replace(/%3F/gi, '?')
    newParamValue = newParamValue.replace(/%23/gi, '#')
    newParamValue = newParamValue.replace(/%2B/gi, '+')
    newParams[param] = newParamValue
    return newParams
  }, {})
}

I think you're right, @OliverJAsh. We should have left the pathname encoded and then only decoded it when we needed to make the match in React Router. This is the way previous versions of the router worked.
Now, the question is how to get there from here w/out breaking everyone's apps. This would be a breaking change, so we would need to push a new major version.

Is it only when using history.push that this happens? Or when using the link component as well? I guess I’m wondering if there is something that can be written on what to do now while the major version solution is being worked on.

@kellyrmilligan: I'd say it can definitely affect the link component if the link component ends up calling history.push under the covers (depends on where you are getting the link component from). In the example scenario I gave above, I am using a custom <Link /> component, so I had to hack it to make things work nicely with the double-encoding workaround (I want the double-encoded URL to be passed to history.push, but I want the browser to see and render a single-encoded URL in case the user inspects it); I made it take two URLs, one for display purposes and one for actually pushing to the history. Not pretty.

Why do you think it is a good idea to change the location irreversibly in the first place? Leave the display for the browser please.

We are approaching a year of this issue being open. Are we at a point where a pull request can be started or are we still deciding on a solution?

Hi!!!
glad to see there is a discussion going on about this.
I'm just here because I need a way to stop the router from crashing.
our QA is making a fuss about it.
can't we just do tap into the window object and clean up the route before it reaches the reactrouter?
a quick, dirty,  unhealthy way of sidestepping the issue?
we don't need any decoding. just to ignore it.
www.ourhomepage.com/% is breaking the site.
It might be an issue  once we actually start parsing every single url. but for now,
anyone have an idea how we can  throw away everything after the  '/' ?

@mjackson  I'm in favor of just adding a note in the react router docs. the same way their is a note about scroll restoration (which totally worked for me btw 🙏 )
"handling special characters: if ever you have an issue with special characters just do this dirty hack " - something like that.
Just a matter of deciding a on the correct hack 🤷♂
This looks promising but I'm not sure how and when to call it
export function cleanParams (params) {   // cleans the params and returns a new params object   return Object.keys(params).reduce((newParams, param) => {     let newParamValue = params[param]     newParamValue = newParamValue.replace(/%26/gi, '&')     newParamValue = newParamValue.replace(/%3F/gi, '?')     newParamValue = newParamValue.replace(/%23/gi, '#')     newParamValue = newParamValue.replace(/%2B/gi, '+')     newParamValue = newParamValue.replace(/%3B/gi, ';')     newParamValue = newParamValue.replace(/%2C/gi, ',')     newParamValue = newParamValue.replace(/%2F/gi, '/')     newParamValue = newParamValue.replace(/%3A/gi, ':')     newParamValue = newParamValue.replace(/%40/gi, '@')     newParamValue = newParamValue.replace(/%3D/gi, '=')     newParamValue = newParamValue.replace(/%24/gi, '$')     newParams[param] = newParamValue     return newParams   }, {}) }
right now i have a blank page in production and this console.log
static-www-ho.27595e071816e19.js:114 Uncaught URIError: Pathname "/%" could not be decoded. This is likely caused by an invalid percent-encoding.     at t.createLocation (static-www-home.0.4.6.e67c127595e071816e19.js:114)     at b (static-www-ho.27595e071816e19.js:114)     at t.default (static-www-ho.27595e071816e19.js:114)     at Object.<anonymous> (static-www-ho27595e071816e19.js:114)     at n (static-www-ho.27595e071816e19.js:1)     at Object.<anonymous> (static-www.ho0.4.6.e67c127595e071816e19.js:114)     at n (static-www.0.4.6.e67c127595e071816e19.js:1)     at static-www-ho.27595e071816e19.js:1     at static-www-ho.27595e071816e19.js:1

👍   this issue needs to be looked into deeper at some point, I manually have to double encode the url parts that  might have percents in them.
The place I run into a problem is when someone clicks on an anchor link it actually decodes the encoded url, which brings me back to the original offending url.

Commenting on this issue to keep it alive as it would a nice to have fix.
To summarize the the current solution/hacks is to selectively  double encodeURIComponent or manually patch components in core.
The problems I see are

Percent symbols cause javascript errors due to decoding and then reuse as a URI requiring the need of additional try / catch
encoding is handled differently in StaticRouter used for server side rendering and BrowserRouter/Link components
There appears to be no documentation missing for this edge case
The issue is spread across more then one component, adding in some coordination required

Hi stan. This seems to be  an invalid url. I can't solve your question but I can tell you that our devops guys ended up deciding it was a non issue
Get Outlook for Androidhttps://aka.ms/ghei36

From: StanislavBerezin<EMAIL_ADDRESS>Sent: Saturday, September 15, 2018 8:19:59 AM
To: ReactTraining/history
Cc: Luis Manuel Suarez; Comment
Subject: Re: [ReactTraining/history] Path is decoded in createLocation (#505)
can somebody pin point to a solution?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/ReactTraining/history/issues/505#issuecomment-421569549, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMWs6UIMldEkmCjsIx12x5Uvr0TElNz4ks5ubP5_gaJpZM4OjeVh.

@luismasg
I fail to see how this is a non issue, unless you’re referring to your specific project. This issue is a bit bigger than a single project. I can tell you that my team can’t move forward with upgrading React Router because of this issue. We MUST use special characters in our routes to uniquely identify entities.
As far as this problem, is there a timeline for a major change that this bug fix can be a part of?

Here's how we're getting around the issue in our project:

Switch your project to use Yarn if necessary.
In package.json, add "history": "4.5.1" to your project's "dependencies".
Also add "history": "4.5.1" to your "resolutions".

Per the library's changelog, the encoding / decoding stuff was first added in v4.6.0, and v4.5.1 is the most recent version published without these changes.
By making history a direct dependency of our project and having any libraries that rely on it resolve to our selective dependency, we get around the encoding / decoding mess. Yes, we do miss out on the benefits this functionality provides - as well as any other upgrades and fixes published to history since 4.5.1 - but we were not using any of those other features anyways.

For me it seems the decodeURI is the culprit.
I tried to visit an url with reserved characters (? # % / ) so I use encodeURIComponent to build the url. /the/path%23%25%3F%2F. But the decodeURI in createLocation, changes it to /the/path/%23%%3F%2F
From random googling, people said the decodeURI/encodeURI should be used on full url's, while decodeURIComponent/encodeURIComponent on parts (component) of the url. The pathname is a component. More info here for the difference between them https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURI#Description
I've wrote a few tests. If you change decodeURI to decodeURIComponent these will pass:
  describe('with a path that can be decoded', () => {
    it('handles encoded path', () => {
      expect(
        createLocation({pathname: '/the/path%23%25%3F%2F'})
      ).toMatchObject({
        pathname: '/the/path#%?/',
        search: '',
        hash: ''
      });
    });

    it('handles not encoded path', () => {
      expect(
        createLocation('/the/path?the=query#the-hash')
      ).toMatchObject({
        pathname: '/the/path',
        search: '?the=query',
        hash: '#the-hash'
      });
    });
  });

There are 3 (well 1 for 3 histories) tests failing, but I think that would be a false negative:
        Expected value to match object:
          {"pathname": "/view/%23abc"}
        Received:
          {"hash": "", "key": "rw3pt0", "pathname": "/view/#abc", "search": "", "state": undefined}

A problem would arise, when you decode %23 as an hash, and later on would re-interpertate the hash as a valid fragment (if this would be possible). Safest way would be to store the original path somewhere.

Invoking decodeURI(location.pathname) on URLs before handling them to the browser's history is a major issue. First of all, it forces the browser to store malformed URLs (i.e. the original url https://mydomain.com/test%25 is modified to be https://mydomain.com/test%). Any browser vendor could disregard such blatant misuse of the API and completely break every user of this library when modifying their API to throw when pushing/replacing invalid URLs. They could also very well silently discard malformed URLs and never allow popping them back.
In this thread, workarounds were suggested as to decode everything except % signs. I would argue that it is a bad idea because you're going to surprise some of your indirect users who are going to have a hard time when their RR matcher doesn't work the same way once the % character is part of the URL (i.e. URLs are partially decoded except %25, which means you need to match against %25 rather than %).
Even though this represents a breaking change for people who came to rely on this implicit decoding, it is also a mandatory bug fix as applications relying directly or indirectly on this library are broken in regards to the % character and there is no reasonable workaround without fixing the root cause.
In conclusion, better figure out a path to make the breaking change at the time of your choosing rather than wait for a browser vendor to force you into it.

We are ditching RR for @reach router because of this massive issue.

Update on https://github.com/ReactTraining/history/issues/505#issuecomment-453175833. We've been waiting for a few weeks now for feedback from a maintainer of this repo. No signs yet. :-(
In the meantime, I thought I'd share how we're working around this at Unsplash. We use patch-package, which lets us modify the contents of node_modules. Using this, we can remove the decoding. This has fixed all of our problems.
patch-package
--- a/node_modules/history/LocationUtils.js
+++ b/node_modules/history/LocationUtils.js
@@ -44,15 +44,9 @@ var createLocation = exports.createLocation = function createLocation(path, stat
     if (state !== undefined && location.state === undefined) location.state = state;
   }

-  try {
-    location.pathname = decodeURI(location.pathname);
-  } catch (e) {
-    if (e instanceof URIError) {
-      throw new URIError('Pathname "' + location.pathname + '" could not be decoded. ' + 'This is likely caused by an invalid percent-encoding.');
-    } else {
-      throw e;
-    }
-  }
+  // Waiting for upstream PR to be merged
+  // https://github.com/ReactTraining/history/issues/505#issuecomment-453175833
+  // https://github.com/ReactTraining/history/pull/656

   if (key) location.key = key;

--- a/node_modules/history/es/LocationUtils.js
+++ b/node_modules/history/es/LocationUtils.js
@@ -31,16 +31,6 @@ export var createLocation = function createLocation(path, state, key, currentLoc
     if (state !== undefined && location.state === undefined) location.state = state;
   }

-  try {
-    location.pathname = decodeURI(location.pathname);
-  } catch (e) {
-    if (e instanceof URIError) {
-      throw new URIError('Pathname "' + location.pathname + '" could not be decoded. ' + 'This is likely caused by an invalid percent-encoding.');
-    } else {
-      throw e;
-    }
-  }
-
   if (key) location.key = key;

   if (currentLocation) {
--- a/node_modules/history/umd/history.js
+++ b/node_modules/history/umd/history.js
@@ -157,16 +157,6 @@ return /******/ (function(modules) { // webpackBootstrap
 	    if (state !== undefined && location.state === undefined) location.state = state;
 	  }

-	  try {
-	    location.pathname = decodeURI(location.pathname);
-	  } catch (e) {
-	    if (e instanceof URIError) {
-	      throw new URIError('Pathname "' + location.pathname + '" could not be decoded. ' + 'This is likely caused by an invalid percent-encoding.');
-	    } else {
-	      throw e;
-	    }
-	  }
-
 	  if (key) location.key = key;

 	  if (currentLocation) {

There's some discussion in https://github.com/ReactTraining/history/pull/656 about what the correct behaviour is (as opposed to decoding pathname). Our options are:

Just use whatever pathname is provided (i.e. leave it to the browser/user to encode).
Try to normalize pathnames so that they are encoded. If the provided pathname is fully encoded, use as is, otherwise (if the pathname is not encoded at all, or some parts are not) encode the parts that are not yet encoded.

What do people here think? Can anyone foresee 2 causing issues?
With 2, I'm worried about bugs in the normalization process. This would be off loaded to encodeurl. Is it a completely safe operation? How likely is it to go wrong?
/cc @pshrmn

Try to normalize pathnames so that they are encoded. If the provided pathname is fully encoded, use as is, otherwise (if the pathname is not encoded at all, or some parts are not) encode the parts that are not yet encoded.

IMHO this is impossible to implement. Let's say I have a path template like /article/:name with the name parameter having the value the best 10%. Since we are all fine developers we encode the value and build the full path. This results in:
$ '/article/' + encodeURIComponent('the best 10%')
'/article/the%20best%2010%25'

A generic piece of code cannot identify that this is already properly encoded. This is the whole reason why this issue here came up. encodeURI is already attempting such an implementation. For completeness:
$ encodeURI('/article/the%20best%2010%25')
/article/the%2520best%252010%2525

Just use whatever pathname is provided (i.e. leave it to the browser/user to encode).

The value is called pathname which translates in my head to path and thus to the way it is defined in the specification. IMHO it is fair to assume / require that developers properly escape when fiddling around with dynamic paths.

@bripkens encodeurl is designed to work with already/partially encoded strings.
With this sandbox you can see that it handles fully encoded, non-encoded, and partially encoded strings.

@bripkens is right when he says it is impossible to implement. In order to correctly encode an URL, you must be able to prove the reverse transformation is always possible without any loss of information. Otherwise you might be causing prejudice to the application that expects to see the same URL that was given to the system originally.
Your sandbox demonstrates this impossibility. Three different source URLs are encoded to the same resulting URL. When you decode the final URL, you cannot possibly retrieve the correct source URL all of the time because you cannot guess the intent of the user. This will inevitably lead to subtle bugs that often go unnoticed.
One final example to demonstrate how encodeurl will screw up some URLs is shown in this sandbox I derived from yours. Assuming I create an article with the following title : %20 is a space %-encoded, the urlencode library sees it as being partially encoded when really, it is not encoded at all. The resulting encoded string is the following : %20%20is%20a%20space%20%25-encoded which then decodes to **  is a space %-encoded**, corrupting the title of my article by decoding the litteral %20 I originally used.

@Dalzhim I'll start out with your final example; please let me know if I am misinterpreting your point.
Let's start out by completely ignoring the encodeurl package.
If we use history.pushState to navigate to this /%20 is a space %-encoded, we end up with the following pathname:
history.pushState(null, "", "/%20 is a space %-encoded")
window.location.pathname === "/%20%20is%20a%20space%20%-encoded"

The browser does not encode percentage signs, so the initial %20 octet is used as provided. We also have an invalid URI because %-e is an invalid octet.
decodeURI(window.location.pathname) // this throws an URIError

To make the URI valid, we can pass it to an encodeURI call. This will encode %-en to %25-en as well as convert %20  to %2520%20. This will result in a pathname that can be decoded to the desired result.
history.pushState(null, "", encodeURI("/%20 is a space %-encoded"))
window.location.pathname === "/%2520%20is%20a%20space%20%25-encoded"
decodeURI(window.location.pathname) // "/%20 is a space %-encoded" CORRECT

Now, getting back to encodeurl, what happens if we wrap the pathnames in encodeurl calls?
history.pushState(null, "", encodeurl("/%20 is a space %-encoded"))
window.location.pathname === "/%20%20is%20a%20space%20%25-encoded"
decodeURI(window.location.pathname) // "/ is a space %-encoded" INCORRECT

history.pushState(null, "", encodeurl(encodeURI("/%20 is a space %-encoded")))
window.location.pathname === "/%2520%20is%20a%20space%20%25-encoded"
decodeURI(window.location.pathname) // "/%20 is a space %-encoded" CORRECT

In the first case, we still have the incorrect pathname, but it is no longer an invalid URI because encodeurl correctly encodes %-en to %25-en. The issue is that encodeurl interpets the initial %20 as a valid octet.
In the second case, we get the same (correct) result as the plain encodeURI result; wrapping an encodeURI call in an encodeurl call does not have any issues with double encoding.
encodeurl offers partial protection, but is not capable of determining the users intent. The conclusion that I draw from this is that the user should always encode percentage signs themselves.

@pshrmn : Your previous message is 100% correct. The user is the only one who has enough information to disambiguate any malformed URL. The first case ended up with a valid, but meaningless URL whereas the second example displays proper construction of the URL by the user, which makes it possible for the library to handle in a generic way. In other words, decodeURI(encodeURI(url)) === url must always be true, otherwise the error is on the user's responsibility.

Someone who knows better than me should raise a PR to encodeurl to mention these caveats…

Can I ask before this issue, maybe rr 3 and below, what were the isssues with how it treated path params and what not?  I don’t remember tbh having an issue until 4.


Plans on updating slf4j to 2.0

Here I propose to discuss plans on migrating slf4j to 2.0. Since this migration isn't binary compatible we can't do this within the current major series. So we pinned its updates for now.
Ross has dropped some thoughts about it:

If I'm understanding that correctly, when we merge this, we're forcing an implementation upgrade on every application. Then I absolutely agree it's a major release for us.
Until we merge it, anybody who upgrades their implementation would have to upgrade the API. Hopefully 2.0 implementations transitively pull in the 2.0 API? And if that's the case, is there any reason libraries shouldn't just stick to 1.x?

So this is a good entry point to start the discussion.

~Another way to avoid major version is to create a slf4j2 module. Then you can choose which one you want.~

Ignore this, a new major version is warranted due to introduction of module system, and incompatible jdks.

@hamnis made this comment, but then retracted. Why? Seems like it could work as a separate artifact.

In a short perspective, bringing a new artifact is worse than doing a new major release. At the moment, we have no plans for a new major release in log4cats (like changing architecture/doing non-binary compatible changes on the whole). So it'd be fine to continue updating several release series, as we do it regularly within Typelevel.
But speaking from the 'real' perspective of updating slf4j in 'real' projects... Users might migrate to Scala 3 earlier than do update the major slf4j version. 😆 So, I'm on the side of bringing the new artifact after some meditation.

Just to throw out one more option:
we could schism the log4cats-slf4j integration from this repository, into its own repository. Then it can have independent versioning, and we can bump the major version there without bumping it for core.

https://www.slf4j.org/faq.html#compatibility

From the clients perspective, the SLF4J API is backward compatible for all versions. ... To date, binary compatibility in slf4j-api has never been broken.

Honestly to me that just suggests we should pin to 1.x and move on. Anyone who wants to use with 2.x should be able to do so (although may require some build hacking), since it did not break bincompat of the slf4j-api artifact.

I haven't seen a compelling argument for libraries to publish for 2.x.  Apps that upgrade their backends will evict 1.x to something binary compatible with us, and apps that haven't won't silently break.  The worst thing I can imagine by pinning is that we might push SBT eviction warnings downstream.

I haven't seen any ill effects of pinning this in multiple downstream libraries.  Can we close this as resolved that we stick to 1.x?


pypi release 7.0.2 is lacking the static files

Describe the bug
Downloading the package from https://pypi.org/project/django-select2/ gives me an archive without the static files.
Thx for this app, btw.

@tuky good catch. Sorry for that. I am working on a patch right now.

oops, just caught this after cleaning out my development environment :|. Luckily, ./manage.py collectstatic doest not delete files in its destination directory, so production still has the version .


Download threads are set to 1. Previously 4, then 2.

I am having the same issue with threads set to 1

Still broken. The issue comes down to not being able to do http auth on download links anymore. It now relies on setting a cookie when browsing the main site and using that cookie to not get a 404 when downloading. I don't see any rate limiting in my testing.

Still broken. The issue comes down to not being able to do http auth on download links anymore. It now relies on setting a cookie when browsing the main site and using that cookie to not get a 404 when downloading. I don't see any rate limiting in my testing.

Any idea on how to fix this?


[Q] How to directly obtain a figure with grey grid background and manually set label name

Hello!
Thank you very much for your excellent work! Have a nice day!
I am writing to ask for help obtaining the figure with formats like a grey grid background and manually setting label names. Could you please give me some suggestions?
Currently, I get the plot like this:

All the settings (smoothing, color, grouping...) in this plot are well-designed, perfect, and right fit. However, I need to obtain figures like this:

I have tried the download button, but the figure goes like this:

I need to fit it in the above format, and I do not know how to do smoothing and grouping using the .csv. Do you have any idea how to handle this problem directly by using wandb? I heard there is a function called a custom chart. Do you think it could achieve this kind of format adaptation without re-running the runs?
Thank you very much!

hey @StaminaTang - My recommendation would be the following:

you can pull the values for a specific metric using run.scan_history() (docs)
once you do that, you can resume the wandb run (documentation here on how to do that), and you can log these points in a wandb Table or as a custom chart directly (documentation)

hey @StaminaTang - due to inactivity, I'll close out this thread, but feel free to write back in whenever


Integrate with httpclient 4.5.2 when provided by WildFly

Cross ref: https://issues.jboss.org/browse/WFLY-7263
Also: https://issues.apache.org/jira/browse/CAMEL-10371

This is not resolved. We're still overriding httpclinet and httpmime.

Ah, my bad. it's fixed on the WF 11.x branch.
We can remove the hard coded dependency overrides on master at least.

Blocked by wildfly-11.0.0


java.net.SocketException: Connection reset?

What should I do?

I'd suggest using StackOverflow for suggestions on this. Let's keep this site for jsoup bug tracking.
You'll want to provide a minimal test case so people can replicate (including environment and URL details.)


Remove travis builds.

They are very unreliable and produce a lot of meaningless noise.

(without commenting on the merits of the PR)
looks like we should also be removing ./maintainers/scripts/travis-nox-review-pr.sh and similar files.

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

Comments from Reviewable

That's a reluctant 👍 from me. In its current state, I think it's worse than useless, but I want something like it to exist that works properly and that we can trust. Wasn't Hydra getting similar functionality at some point?

https://github.com/NixOS/hydra/pull/326

@grahamc Done

I wonder if there is a bit of work which would be useful and Travis could execute. Even a simple check like "does nixpkgs evaluate?" would be better than where we are now.

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

Comments from Reviewable

Maybe, but until that exists IMO it would be better to reduce the noise.

So, I  this because having unreliable testing infra is worse than none at all. I appreciate all the work that's been done to make this more reliable, and wish it had worked out better. I suspect Travis is just not the tool for this job.

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

Comments from Reviewable

Does Travis ever give false positives? I've only ever seen false negatives, which isn't really a huge problem as far as I'm concerned. I think testing that includes false negatives is better than no testing.

How's that? Human trust in the tool is eroded with every false negative they need to investigate. Eventually if the rate gets high enough they stop paying attention, and it just becomes another piece of noise clamoring for a slice of limited free time.

On Sep 6, 2016, at 22:56, Langston Barrett<EMAIL_ADDRESS>wrote:
Does Travis ever give false positives? I've only ever seen false negatives, which isn't really a huge problem as far as I'm concerned. I think testing that includes false negatives is better than no testing.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@copumpkin It saves time. If Travis builds correctly, nobody has to manually check that a given PR builds. If Travis gave half false negatives, it would still prevent humans from building half of the time.
That said, y'all work on this much more than I do and if Travis doesn't save you time, then please disregard my comments.

I find it takes less time to determine that the travis error is spurious than it takes to do all the trivial checking currently performed by travis. I'm sure everybody agrees that Hydra is the future, but why the rush to remove travis before there's a working alternative in place? The travis apostates can safely ignore it, no?

I'm +0 on this. I do think it helps with PRs, because it doesn't give false positives.
Maybe instead we should disable it on all branches and leave it for PRs?

I don't know, newcomers don't know that most of travis's failures are false. But anyway, disabling it on branches would hit 80% of what I care about personally here.

@siddharthist I guess I just value my time more than my computer's time 😄
But yes, disabling it on branches is my main issue too. If people want it on PRs, that's fine.

I've pushed 9ba3d37 that should address the failures on commits outside PRs.

Travis-CI does generate false-positives: https://github.com/NixOS/nixpkgs/issues/7304.

Still getting annoying emails... @domenkozar

Every time we have a mass rebuild it happens, Travis can't rebuild ghc8 to build the NixOS manual (pandoc).
I think travis-ci does some good for us at the moment, but hopefully we'll have https://github.com/expipiplus1/hercules usable soon as new Hydra API that will allow us to add PRing functionality.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/18376#issuecomment-258614984, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHtg6skdRDPkS0Td0Gp6EX6g4ZTfZuJks5q7JIlgaJpZM4J2WJU
.


Add Flatlogic Web App Generator to paid examples

Signed-off-by: Eugene Stepnov<EMAIL_ADDRESS>

[x] I have followed (at least) the PR section of the contributing guide.

@stepnov Thanks for the proposal but the templates on the destination conflict with the interests of http://mui.com/store/.


Optimize algorithm

[x] Find hotspots using a python profiler
[x] Explore multithreading

See package documentation of trajectory_planner package description for an example on how to profile algorithm

All profiling must be done using performance.py for repeatability

Algo hotspots

agent.check_collisions: norm was replaced by sqrt but it's still slow -> high number of call (~8000)
solve_qp
build_optimization_matrices

Multiprocessing and multithreading tests
I tried to add multiprocessing for collision_check and solve_qp. However these functions take time because of the high number of calls. It was actually slower with mp because of it's overhead.
More tests would have to be done to see if mp is faster for a high number of CF.
Ran into a lot of problems with adding mp because the methods were in a class.


Plots sections is not responsive when exp push is happening

Experiments pushing should not be blocking any operations

Can you please give some more context. Was the webview open before you started pushing the experiment? Did it previously contain plots? What is going on?

Yes, it was open. Yes it had some plots on it.
After I initiated push and opened the plots back that what I saw.
I don't have much more details atm. I can try to reproduce and get more details.
Btw, even after push was done, the screen was staying still in that state.

The error is likely unrelated. If it happens again can you please check developer tools for errors:

I've shared the video directly in Slack for this issue (too large to put here): https://iterativeai.slack.com/archives/C01RB7BTG4C/p1701386048xxxx65


Background payload runner

Description
Script that runs a custom payload in the background

time delay can be adjusted
payload can be customized
command line can be selected as needed : cmd or powershell

Fixes #1698
Type of change

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the style guidelines(Clean Code) 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 created a helpful and easy to understand README.md
[x] My documentation follows Template for README.md
[x] I have added the project meta data in the PR template.
[x] I have created the requirements.txt file if needed.

Project Metadata
Requirements:
pip install background

requirements.txt file added

Category:

[ ] OS_Utilities
[ ] Automation
[ ] Others

Title: Background Payload Runner
Folder: Background-Payload-Runner
Requirements: requirements.txt
Script: run-payload.py
Arguments: none
Contributor: sagnik-p
Description: Background payload runner in python

@avinashkranjan
I have submitted the PR
Please review and merge

@avinashkranjan

What?why?
Plz merge or if there is any problem, tell me and I will rectify it

There has been no response from your end
@avinashkranjan
I have already submitted the PR on time
After this was assigned to me
I request you to merge this PR asap, I have been waiting for a long time


Auto-center when cropping

Hello. Not sure if this is the right place to suggest/request but would it be possible, when cropping and selecting dimensions to make it auto-center after choosing the one you want? Right now for example if I choose 9:16 it puts the selection box all the way to the left and its always a guessing game to make it completely in the center again. Thanks!

Crop function is to move the selection where the main object is, this isn't always perfectly in the center. The request is not accepted.


TFLite forcing to run on CPU

Click to expand!
Issue Type
Support
Source
source
Tensorflow Version
tf 2.8
Custom Code
No
OS Platform and Distribution
No response
Mobile device
No response
Python version
No response
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current Behaviour?
Hello!
Can I somehow force the TFLite interpreter to run on my CPU instead of GPU? Now it is running on GPU automatically.
Another question is also if I can use TFLite runtime on GPU? It automatically uses the CPU when I start right now even if it is exactly the same code and computer as when I use TensorFlow complete library.
Best regards
Sara Larsson
Standalone code to reproduce the issue
import tensorflow as tf
interpreter = tf.lite.Interpreter(model_path)

import tflite_runtime.interpreter as tflite
interpreter = tflite.Interpreter(model_path)

Relevant log output
No response

Hi @Sara980710 ! Sorry for the late response.  You can disable GPU usage through below code. Thank you!
import os
os.environ["CUDA_VISIBLE_DEVICES"] = "-1"
gpu_available = tf.test.is_gpu_available() //cross check to see any GPU usage
print(gpu_available)

Thank you!
How do I turn on GPU for tensorflow lite runtime?
import tflite_runtime.interpreter as tflite interpreter = tflite.Interpreter(model_path)

When I test the code you suggested, it shows that it does not have a GPU even if I do not set os.environ["CUDA_VISIBLE_DEVICES"] = "-1",  but it still is as fast as when I run with C++ GPU delegate. Are you sure that it works with  AMD GPU:s as well?
When i use c++:
-GPU: 2 min
-CPU: 5 min
When I use python:

2 min (should be using GPU right? )

@Sara980710 ! GPU time might be 2 min as CPU time is intended higher (C++ implementation has seen faster processing time compared to Python implementation earlier). Could we move this to closed status then.  Thank you!

@Sara980710 ! GPU time might be 2 min as CPU time is intended higher (C++ implementation has seen faster processing time compared to Python implementation earlier). Could we move this to closed status then. Thank you!

I want to be able to measure a comparison between the following:
-C++ tensorflow GPU
-C++ tensorflow CPU
-Python tensorflow GPU
-Python tensorflow CPU
-Python tensorflow lite runtime GPU
-Python tensorflow lite runtime CPU
The C++ code I have already written to be able to measure both CPU and GPU, but I am wondering how to do it in Python (both libraries).

@Sara980710 ! You can use tf.device to force the processes to run either in GPU or CPU? Thank you!

How do i do it with tflite runtime since i do "import tflite_runtime.interpreter as tflite"

It seems like no matter what I do as settings, it still performs the same in time.
if opt.gpuoff:
        tf.device("/device:CPU:0")
        print("using CPU")
    else:
        tf.device("/GPU:0")
        print("using GPU")

It did now however print out " 2022-05-20 12:33:10.555126: I tensorflow/core/common_runtime/process_util.cc:146]   Creating new thread pool with default inter op setting: 2. Tune using inter_op_parallelism_threads for best performance" when i added the device settings. But when i set inter_op_parallelism_threads to 1 it did still measure the same time.

Ok @Sara980710 ! Sorry for the inconvenience . @sachinprasadhs ! Could you please look at this issue? Thank you!

TFLite will use CPU by default on interpreter, to make use of GPU you can use it on your hardware accelerators  Android or IOS device, for more details check the document here. Thanks!

I have checked the links before, I am however using a satellite computer with AMD64 architecture and ubuntu, not android or ios. For C++, I have managed to get the GPU to work, but for Python I cannot find a way to choose a device.

Unassigned myself, because I'm not familiar with the Python code path =/

Hi @Sara980710 !
In Python, You can force the CPU usage through tf.device or by disabling the cuda variable through os.
Ref.
Can you mark it as duplicate to #56148 and comment there  if it is still not resolved .
Thank you!


Slider: thumb-fill desync

I'm submitting a:

[x] bug report

What OS are you using?
macOS10.15.1
What browser(s) is this bug affecting:
Chrome78.0.3904.108

Additional software versions
{
    "@emotion/core": "10.0.22",
    "@material/button": "4.0.0",
    "@material/icon-button": "4.0.0",
    "@material/ripple": "4.0.0",
    "@material/slider": "4.0.0",
    "@rmwc/button": "5.7.0",
    "@rmwc/icon-button": "5.7.0",
    "@rmwc/provider": "5.7.0",
    "@rmwc/ripple": "5.7.0",
    "@rmwc/slider": "5.7.0",
    "react": "16.12.0",
    "react-dom": "16.12.0",
    "react-scripts": "3.2.0"
  }

Behavior:
When

using a Slider with a controlled value, and
updating the controlling state value independently by two functions:

an external function, and
the onInput prop

the slider thumb position does not sync with the fill position.
Steps to reproduce:
Screen recording: https://imgur.com/a/rqxTPls (easter egg: audio)
Related code:
CodeSandbox link
Other information:
I was redirected here. Additional details available at original issue: https://github.com/jamesmfriedman/rmwc/issues/524

Are you actually using the Material Web Components (<mwc-slider>?) It looks like RMWC is probably using Material Components Web (yes our names are very confusing, sorry):
https://github.com/material-components/material-components-web-components (material components as native web components, this repo)
https://github.com/material-components/material-components-web (framework/api-neutral material design implementation, I think this is what RMWC is using).
Mind filing the issue here instead? https://github.com/material-components/material-components-web/issues

@aomarks Oops—thanks. You can close this issue unless it's still needed.

No problem, thanks for filing!


⚠ Avatar API Endpoint has degraded performance

In b3e9c68, Avatar API Endpoint (https://avatar.roblox.com/v1/avatar-rules) experienced degraded performance:

HTTP code: 200
Response time: 1903 ms

Resolved: Avatar API Endpoint performance has improved in 3a41f2f after 5 minutes.


ci: bump to golang1.23.1

crd-ref-docs and controller-gen still keep in golang1.22.7 because the change of types.
tools/bin/controller-gen crd:allowDangerousTypes=true paths="./api/..." output:crd:artifacts:config=charts/gateway-helm/crds/generated
panic: interface conversion: types.Type is *types.Alias, not *types.Named

seems related to https://go.dev/doc/go1.23#gotypespkggotypes, not 100% sure.

ah, always failed on go1.23.x, intresting!
    --- FAIL: TestE2E/CookieBasedSessionPersistence (1.03s)
        --- FAIL: TestE2E/CookieBasedSessionPersistence/traffic_is_routed_based_on_cookie_based_session_persistence (1.01s)


Fix unified auth

[x] update contact us
[x] revert and remove sso form
[ ] check if user exists https://github.com/rilldata/rill-private-issues/issues/919
[ ] fix sign up

@ericpgreen2 @lovincyrus : Is this ready to be merged ?  Are we blocked on something here ?

@ericpgreen2 @lovincyrus : Is this ready to be merged ? Are we blocked on something here ?

https://rilldata.slack.com/archives/C080SHAMZU2/p1733415643892399


Can't select code with mouse

Hey!
I can't select code with mouse drag. I tried everything I could.

Disable extensions
Reinstall
Different version

Does anyone know what to do?

/needsMoreInfo


rules-check doesn't accept globs as described in the documentation

The example rules-check command states that rules-check takes a glob of rules files
./thanos tools rules-check --rules cmd/thanos/testdata/rules-files/*.yaml

https://thanos.io/v0.19/components/tools.md/#rules-check
But this does not work for me.
You either get shell expansion of the glob, resulting in:
./thanos tools rules-check --rules config/rules/*.yaml
error parsing commandline arguments: [/bin/thanos tools rules-check --rules config/rules/file1.yaml config/rules/file2.yaml]: unexpected config/rules/file2.yaml
thanos: error: unexpected config/rules/file2.yaml

Or without shell expansion:
./thanos tools rules-check --rules=config/rules/*.yaml
error parsing commandline arguments: [/bin/thanos tools rules-check --rules=config/rules/*.yaml]: path 'config/rules/*.yaml' does not exist
usage: thanos tools rules-check --rules=RULES

The only form that does work is
./thanos tools rules-check --rules config/rules/file1.yaml --rules config/rules/file2.yaml

This is either a documentation error or the glob handling is not working.

Which version is this fixed in? I just ran into it in both v0.20.1 and v0.20.2.


Handle string overflow for small components

Description

Some places in the app we have very limited space for text. We need to make sure that when there is text overflow, it looks normal
Acceptance Criteria

[ ] All text overflow is handled
[ ] This includes PersonCards and EncounterCards
[ ] Includes PersonCardSummary and EncounterCardSummary componetsn

Implementation details

n/a
Testing notes

n/a

Issue lgtm!


How to save a document / image in OrientDB

Hello,
I'm trying to add a file in a vertex BINARY property but I get next error:
{   "errors": [     {       "code": 500,       "reason": 500,       "content": "com.orientechnologies.orient.core.exception.OSerializationException: Error on unmarshalling JSON content for record: \"@class\":\"Ofertas\",\"@version\":0,\"@rid\":\"#-1:-1\",\"nombre\":\"ddd\",\"imagen\":null,\"fecha_fin\":null,\"descripcion\":null,\"pruebas\":null,\"fecha_inicio\":null,\"{{ header }}\":\"$file\"\r\n--> java.lang.IllegalArgumentException: Invalid field name '{{ header }}'. Character ' ' is invalid"     }   ] }

hi @jfernandezrico
are you uploading file with http api?

I'm uploading the file through Orientdb studio

similar issue. In 2.2 add binary field and upload image in studio. Creates record with image:null, and the image file is not actually uploaded.


Bad folder-path displayed when using subfolders

When including a subfolder by adding users/*.log (for example) to the include_files-config, the folder-item displays the full path as title for the directory, which I don't think is the correct behaviour. Also this is not the full-path, since it only points to the root of the Laravel-Application. The log-files are still displayed correctly though.

Correct path in this case would be: C:\Users\matthias.thalmann\Work\splus-dashboard-new-re\api\storage\logs\users
Edit: The sub-folder is not included automatically, if that should be the case. Therefore I had to add it manually.

Hey @m-thalmann , thanks for the report!
Should be fixed in v1.6.4 :)

@arukompas thanks! Great work!


Speed up packfile reading

By adding a bufio to the trackingReader, otherwise most of the time
is spent in syscalls for small reads to the packfile.

Current coverage is 69.65%

Merging #16 into master will increase coverage by +0.09% as of 1116255

@@            master     #16   diff @@
======================================
  Files           17      17
  Stmts         1255    1259     +4
  Branches       199     199
  Methods          0       0
======================================
+ Hit            873     877     +4
  Partial         93      93
  Missed         289     289

Review entire Coverage Diff as of 1116255

Powered by Codecov. Updated on successful CI builds.


Ux implementation 2nd

Minor changes in InsuranceV2-Design.rp
added event to update visibility and text of status- and toolbar
added dummy navigationHistory for prev and next button

Guess we can close this after 2years ;)


Feature: Allow user to show/hide Completed tasks.

Is your feature request related to a problem? Please describe.
Using Show Completed button now triggers nothing.
Describe the solution you'd like
Displayed test setting:

When displaying all tasks (default setting), show text on button: Hide Completed,
When displaying not completed tasks, show text on button: Show Completed,

Automatically refresh tasks list when button is clicked.
Describe alternatives you've considered
Additional context
Web Frontend.

Blocked by #90

Unblocked

Blocked - mockup needed

Unblocked


start server and keep running

I'm simply trying to use remoteSession to start a vertx server application and connect to it using curl.
These commands work when I ssh into the vagrant vm but not using a sshoogr remote command.
I have a standard vagrant vm running on my machine.
code used to test:
import com.aestasit.infrastructure.ssh.dsl.SshDslEngine
import com.aestasit.infrastructure.ssh.SshOptions

def engine = new SshDslEngine(new SshOptions(defaultHost: '<IP_ADDRESS>',
        trustUnknownHosts: true,
        defaultUser: 'vagrant',
        defaultKeyFile: new File('C:/Users/rosso/.vagrant/machines/default/virtualbox/private_key'),
        defaultPort: 2222))

engine.remoteSession {
    //> /dev/null 2>&1 &
    exec('cd /opt/apps/vertx-apps && sudo /home/vagrant/.sdkman/candidates/vertx/current/bin/vertx start hello.groovy -id hello')
    exec('curl <IP_ADDRESS>:8080')
}

The vertx application is started successfully, however in the second execute block, the application is not running and curl can't connect. Here is the log output:
14:40:46.311 [main] INFO  c.a.i.ssh.log.Slf4JEventLogger - > cd /opt/apps/vertx-apps && sudo /home/vagrant/.sdkman/candidates/vertx/current/bin/vertx start hello.groovy -id hello
14:40:47.367 [main] INFO  c.a.i.ssh.log.Slf4JEventLogger - Starting vert.x application...
hello

14:40:47.381 [main] INFO  c.a.i.ssh.log.Slf4JEventLogger - > curl <IP_ADDRESS>:8080
14:40:48.386 [main] INFO  c.a.i.ssh.log.Slf4JEventLogger - curl: (7) couldn't connect to host

And here is the output when I actually ssh into the vagrant vm:
vagrant@precise64:/opt/apps/vertx-apps$ cd /opt/apps/vertx-apps && sudo /home/vagrant/.sdkman/candidates/vertx/current/bin/vertx start hello.groovy -id hello
Starting vert.x application...
hello
vagrant@precise64:/opt/apps/vertx-apps$ curl localhost:8080
Hello from Vert.x!vagrant@precise64:/opt/apps/vertx-apps$

I've also tried starting the vertx application in the background using > /dev/null 2>&1 & even though the vertx start command already starts the app in the background.

After I discovered the SshOption reuseConnection and set it to true the code works and the vertx app keeps running after the remote session. Code is now:
def engine = new SshDslEngine(new SshOptions(defaultHost: '<IP_ADDRESS>',
        trustUnknownHosts: true,
        defaultUser: 'vagrant',
        defaultKeyFile: new File('C:/Users/rosso/.vagrant/machines/default/virtualbox/private_key'),
        defaultPort: 2222,
        reuseConnection: true
))

However this relates to the issue #77 because the application never exits when that property is set to true. So I just added a System.exit(0) to the end.
engine.remoteSession {
    exec('cd /opt/apps/vertx-apps && sudo /home/vagrant/.sdkman/candidates/vertx/current/bin/vertx start hello.groovy -id hello')
    exec('curl <IP_ADDRESS>:8080')
}
println("exiting")
System.exit(0)

Okay finally solved this..... I tried a number of ways to keep command processes open after the shell closes using the & operator and redirecting standard in, err, etc.. Nothing seemed to work until I used setsid before the command:
engine.remoteSession {
    //> /dev/null 2>&1 &
    exec('cd /opt/apps/vertx-apps && setsid sudo /home/vagrant/.sdkman/candidates/vertx/current/bin/vertx start hello.groovy -id hello')
    exec('curl <IP_ADDRESS>:8080')
}


ktlint:check requires binary dependencies to be present

Running mvn ktlint:check on a clean multi-module projects fails, if there are inter-module dependencies, because it needs the dependencies being built.
Imagine a setup, where there is a module-1 and module-2, module-2 depends on module-1.
If you run : mvn ktlint:check -pl :module-2, maven tries to download module-1-SNAPSHOT.jar (from maven central), which fails.
It's unclear, why ktlint-maven-plugin needs the compiled dependencies, as I would assume, that it only checks the source code.
The issue comes from the fact, that our multi-module setup is pretty big, to compile all the modules, we need ~20 minutes, but we would like to have a quick, ktlint check to catch the problems, without the slower compile process.

@gzsombor thanks for reporting this issue, sorry it took me so long to respond (my day job hasn't left much time for OSS recently). I don't recall the reason for requiring binary dependencies, but the current version of the plugin doesn't seem to need them, so I've removed the requirement. You can find the fix in version 1.12.0 of the plugin.

Thank you for the fix! (It seems, that it's only part of the 1.12.1 release)


chore(package): update tap to version 10.3.0

Closes #41
https://greenkeeper.io/

Coverage remained the same at 100.0% when pulling abda4a21877c530d5e745f55dd295bd094a091b2 on greenkeeper/tap-10.3.0 into 0306f0aab0b4fd93db62661dcdd2c833817aef70 on master.