feat: Use new hashing

This uses the new Hasher based implementation, that should be faster
(avoids re-allocating the buffer) and supports structs.
This closes #211.
This closes #462.
This closes #525.

@epinzur looks like this is failing some of the wren integration tests for slicing. My best guess is that it's similar to the Rust test changes -- since we use the hash to determine which entities are in a slice, changing the hash changes the slices. I can take a look, but you can probably knock that out quicker than I can. Any thoughts here?

@bjchambers I added a commit to fix the slicing test.  The issue was that with the new hashing function, a 0.3% slice returns  no results.  I changed the test to a 1% slice and it now passes.


iOS build fails with yarn install

In my setup, I required to perform pod install as well in order to get npx react-native run-ios running successfully.
Xcode 11.3.1
yarn 1.2.4
Catalina 10.15.3
Build fail log -
info Found Xcode workspace "PrivateKit.xcworkspace"
info Building (using "xcodebuild -workspace PrivateKit.xcworkspace -configuration Debug -scheme PrivateKit -destination id=2B640F2E-4BE8-4FEC-9D36-4B3D0E9EF7AA")
............
error Failed to build iOS project. We ran "xcodebuild" command but it exited with error code 65. To debug build logs further, consider building your app with Xcode.app, by opening PrivateKit.xcworkspace. Run CLI with --verbose flag for more details.
note: Using new build system
note: Planning build
note: Constructing build description
error: /Users/safepath/Workspace/private-kit/ios/Pods/Target Support Files/Pods-PrivateKit/Pods-PrivateKit.debug.xcconfig: unable to open file (in target "PrivateKit" in project "PrivateKit") (in target 'PrivateKit' from project 'PrivateKit')
error: /Users/safepath/Workspace/private-kit/ios/Pods/Target Support Files/Pods-PrivateKit/Pods-PrivateKit.debug.xcconfig: unable to open file (in target "PrivateKit" in project "PrivateKit") (in target 'PrivateKit' from project 'PrivateKit')
error: /Users/safepath/Workspace/private-kit/ios/Pods/Target Support Files/Pods-PrivateKit/Pods-PrivateKit.debug.xcconfig: unable to open file (in target "PrivateKit" in project "PrivateKit") (in target 'PrivateKit' from project 'PrivateKit')
error: /Users/safepath/Workspace/private-kit/ios/Pods/Target Support Files/Pods-PrivateKit/Pods-PrivateKit.debug.xcconfig: unable to open file (in target "PrivateKit" in project "PrivateKit") (in target 'PrivateKit' from project 'PrivateKit')
error: /Users/safepath/Workspace/private-kit/ios/Pods/Target Support Files/Pods-PrivateKitTests/Pods-PrivateKitTests.debug.xcconfig: unable to open file (in target "PrivateKitTests" in project "PrivateKit") (in target 'PrivateKitTests' from project 'PrivateKit')
error: /Users/safepath/Workspace/private-kit/ios/Pods/Target Support Files/Pods-PrivateKitTests/Pods-PrivateKitTests.debug.xcconfig: unable to open file (in target "PrivateKitTests" in project "PrivateKit") (in target 'PrivateKitTests' from project 'PrivateKit')
error: /Users/safepath/Workspace/private-kit/ios/Pods/Target Support Files/Pods-PrivateKitTests/Pods-PrivateKitTests.debug.xcconfig: unable to open file (in target "PrivateKitTests" in project "PrivateKit") (in target 'PrivateKitTests' from project 'PrivateKit')
error: /Users/safepath/Workspace/private-kit/ios/Pods/Target Support Files/Pods-PrivateKitTests/Pods-PrivateKitTests.debug.xcconfig: unable to open file (in target "PrivateKitTests" in project "PrivateKit") (in target 'PrivateKitTests' from project 'PrivateKit')

** BUILD FAILED **

I cannot reproduce your issues, my install works fine.
Xcode 11.3.1
yarn 1.22.4
macOs 10.15.3
One note though, other than updating yarn: on a different machine I had to unset the LDFLAGS and CPPFLAGS from the environment to make the pod install work, otherwise it would fail during the install of glog.

I have tested the current build on two different macs with same macOS, yarn (1.22.4) and Xcode. One manages to compile the app, but the app is unstable when logging GPS info.
The other reproduces your mistake and building with Xcode instead of react-native, locates the error on the missing library @mauron85_react-native-background-geolocation. I believe the issue is the compiler that runs beneath yarn in the different machines, but I haven't been able so far to understand what's the problem.

I haven't been able to replicate this.

I have tested the current build on two different macs with same macOS, yarn (1.22.4) and Xcode. One manages to compile the app, but the app is unstable when logging GPS info.
The other reproduces your mistake and building with Xcode instead of react-native, locates the error on the missing library @mauron85_react-native-background-geolocation. I believe the issue is the compiler that runs beneath yarn in the different machines, but I haven't been able so far to understand what's the problem.

What is the difference between the two machines? I am able to fix the problem by running pod install in the ios folder, which basically installs the required dependencies.
Also what is it you found unstable in gps logging.

One is a 2012 MBPr, the other a 2016 MBP. Same macOS and Xcode, but they have different software on it (brew vs macports, etc.).
The 2012 builds, the 2016 does not.
Regarding GPS logging, the 2012 was having trouble refreshing the app, went on a refresh loop. It is not happening anymore and it is running fine, so far, not sure what's changed. Please disregard the previous claim.

Fixed build install, but does not fix GPS.
https://github.com/andreanuzzo/private-kit/tree/andynuzzo/fix_ios_build

Docs now say pod install and then npx so closing.


docs(FAQ): add a FAQ item on shutting down wsgiref.simple_server

Fixes #1559

Hm, good idea, it doesn't hurt to reiterate this.


First add for minizip

Minizip 4.0.3
Destination channel:
main
Links

3669
Upstream repository

Explanation of changes:

added gtest to avoid code from downloading from source and building
added gtest to ignore_run_exports as it is a test dependency and not a run dependency

A few comments for where I couldn't put comments in the code:

probably better to explicitly state the build optionsthat are being used, for documentation purposes. I mean the ones that are default on and are already being used because the dependencies are there in the host environment
you could build tests and unit tests for windows too
do you know why the static library is included in the package for windows but not unix?
also why CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS is on?

That's a good idea on being explicit.  I will flesh those out.

I will try adding tests for windows.

I do not know why static libs are included in the package for windows and not unix.

I am not sure why Windows Export all symbols was chosen as well.


Fix material property setters not reflecting changes in editor viewport

Fix #98661
Several setters in the class Material do not call notify_property_list_changed(). Therefore, changes to some material properties will not be visible immediately in the viewport. To see the changes, the user has to unselect the node with the changed material and the reselect the node.
This pull request adds calls to notify_property_list_changed() to all setters which did not have such calls before and also to some helper methods used by several setters to set the properties. This makes changes to material properties immediately reflect in the editor viewport.
Before fix: changing cull mode for a material does not immediately change the cull mode in the editor viewport.
https://github.com/user-attachments/assets/1af50884-df00-4799-b109-dc84420616f5
After fix: changing cull mode immediately shows the change.
https://github.com/user-attachments/assets/9116932a-ea1d-4ca2-ac5e-512b6594e850
Do please take a look to see if I have missed some setter or helper method or if I have added an unnecessary call to notify_property_list_changed(). Thanks!

Have you tested with this PR first? I'm not sure all of the notifications are actually necessary.
https://github.com/godotengine/godot/pull/99716

#99716 Does seem to fix the setters. I have not tested all of them yet, but it does indeed work for the cull mode. #99716 adds _queue_shader_change() to all places where I have added _notify_property_list_changed() which suggests that this PR is unnecessary in favour of #99716.

#99716 Does seem to fix the setters. I have not tested all of them yet, but it does indeed work for the cull mode. #99716 adds _queue_shader_change() to all places where I have added _notify_property_list_changed() which suggests that this PR is unnecessary in favour of #99716.

Alright, sorry for the trouble, it's just that I caused the regression myself in a previous PR so the simpler solution is for me to undo that particular change instead of adding more notifications to the class.

No worries, I totally get that :) If anything I felt that I learnt from your PR! I will go ahead and close this PR unless you have some closing thoughts. It is probably a good idea to mention issue #98661 in your PR. Also, thank you very much for the quick replies!


[VL]Support map_entries function in Gluten

What changes were proposed in this pull request?
Support map_entries function in Gluten)
How was this patch tested?
UT

===== Performance report for TPCH SF2000 with Velox backend, for reference only ====

query
log/native_4595_time.csv
log/native_master_02_03_2024_75285bcb8_time.csv
difference
percentage

q1
33.18
33.28
0.098
100.30%

q2
22.58
24.26
1.680
107.44%

q3
37.95
38.78
0.830
102.19%

q4
38.28
37.64
-0.642
98.32%

q5
70.56
70.97
0.404
100.57%

q6
6.94
8.56
1.622
123.38%

q7
84.81
84.29
-0.512
99.40%

q8
87.74
84.63
-3.111
96.45%

q9
119.15
121.75
2.608
102.19%

q10
44.20
43.29
-0.917
97.93%

q11
20.44
20.58
0.144
100.71%

q12
27.55
26.43
-1.121
95.93%

q13
44.53
45.82
1.286
102.89%

q14
17.14
21.75
4.608
126.89%

q15
28.52
29.07
0.553
101.94%

q16
14.26
14.30
0.034
100.24%

q17
101.37
103.31
1.936
101.91%

q18
148.36
149.45
1.086
100.73%

q19
12.54
13.09
0.551
104.39%

q20
27.67
26.67
-0.998
96.39%

q21
223.11
222.74
-0.365
99.84%

q22
13.65
13.69
0.039
100.29%

total
1224.53
1234.34
9.814
100.80%


Fix license quotes

What changes are proposed in this pull request?
Fix license quotes.
Why are the changes needed?
I copied the license header from one of these files and encountered the following exception while testing
Some files do not have the expected license header

And it cost me some time to figure the cause out. So I think it's better to fix all of them to avoid similar cases.
There is already a similar pull: https://github.com/Alluxio/alluxio/pull/3360, but it only fixed one file.
Does this PR introduce any user facing changes?
No

alluxio-bot, merge this please


KB974524 ("Windows Installer reconfigured all applications") suggests non-standard WMI class

KB 974524 suggests discontinuing use of the Win32_Product WMI class (due to query side-effects) in favor of Win32Reg_AddRemovePrograms.
However, this class is only present on computers with an SMS/SCCM client installed. Querying this class on a machine not under SCCM management will throw an Invalid Class error.
This document should be updated to include one or more of the following:

A warning that Win32Reg_AddRemovePrograms (and related classes) requires an SCCM client to be installed
Alternative WMI-based methods for querying the registry (StdRegProv class methods, for instance) in the event an SCCM client is not installed

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

ID: 2b1fe51b-6ccd-c186-fc69-f0dd2ed93a8d
Version Independent ID: 2a4db90e-7c69-68b2-5421-541b0ec3e829
Content: Event log message indicates that the Windows Installer reconfigured all installed applications
Content Source: support/windows-server/admin-development/windows-installer-reconfigured-all-applications.md
Product: windows-server
GitHub Login: @Deland-Han
Microsoft Alias: delhan

Hi @sewillia-msft. Thank you for the suggestion. I will update the article.

Hi, this article was updated as you requested. Thanks.


ci: fix tag workflow

The tag workflow is failing due to some missing parameter: https://github.com/cloudnative-pg/charts/actions/runs/4771923594/jobs/8484163898#step:5:1
Error: Parameter token or opts.auth is required

Closed as completed as part of the new release process.


Failing to create volume 'Opts' unexpected keyword.

I'm getting the same error referenced in FLOC-3258 with the latest installs of everything.
$ flocker-docker-plugin --version
1.5.0

$ docker version
Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:54:53 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:54:53 UTC 2015
 OS/Arch:      linux/amd64

Hi @7imbrook, yes we are aware of this :+1: Our docker plugin does work 1.9, however wasn't included in 1.5.0. You should see and update to the flocker-docker-plugin soon to support this. I will update this issue when it is released and you can verify and we can close. thanks

:+1:
On Wed, Nov 4, 2015 at 5:39 AM Ryan Wallner<EMAIL_ADDRESS>wrote:

Hi @7imbrook https://github.com/7imbrook, yes we are aware of this [image:
:+1:] Our docker plugin does work 1.9, however wasn't included in 1.5.0.
You should see and update to the flocker-docker-plugin soon to support
this. I will update this issue when it is released and you can verify and
we can close. thanks
—
Reply to this email directly or view it on GitHub
https://github.com/ClusterHQ/flocker/issues/2122#issuecomment-153721888.

Hi, we just released 1.6.1 which should fix this problem - give it a try. Thanks again for the bug report, and let us know if you have more problems, questions or suggestions.

Curious as to when this will be released in apt or yum repositories?


Hotfix: Too many clicks to download IPFS

"In 2017, to get from ipfs.io to the ‘Download’ button, it took 4 clicks through redundant pages. This number has been reduced to 3." - https://macwright.org/2019/06/08/ipfs-again.html

Would be rad to see "ipfs desktop" pushed as the way to get started with ipfs as discussed in https://github.com/ipfs/docs/issues/188
...and if the user is determined to just use the command line tool only, point them to all of the popular package managers that they can use to install ipfs as in https://github.com/ipfs/website/pull/299#issuecomment-475694596

This is probably going to get rolled into ipfs/docs/#188, but leaving it as its own issue for now for purposes of discussion.

Closing this issue on the understanding that it's not perfect yet, but that we've streamlined the process of helping the user decide which flavor of IPFS they might like to download, and sending them directly to that flavor's appropriate page. We'll also be doing some further work along these lines in https://github.com/ipfs/docs/issues/188.


Prototype of dialog with state

Not intended to be merged. This is a prototype for the discussion in #95.

Since this a proof of concept and hasn't been updated for a while, I'm going to go ahead and close it.
If you think that's a mistake and that it should be merged into the latest slapp branch (or master branch), feel free to reopen the PR.


Make it so fallback fonts can be added easily

Builds on #160, closes #126 by allowing the user to set their own fallback fonts.

On second thought, this isn't the best way of doing it.


Improve error message for uninitialized configurable

Description:
configurable string name;
public function main() {
    panic error("good");
}

ERROR [main.bal:(1:25,1:25)] configurable variable must be initialized

Describe your problem
Above error can be misleading. User will think variable has to be initialized.
Describe your solution
We should have a message that indicate users can put ? or initialize.

Fixed in #29273, merged with #29119.


January 1st proof of concept demo

In my opinion, it needs to:

Functional display driver
Apps loaded from filesystem
PoC userland with a couple syscalls
Display driven from an app

I have created a label PoC (Proof of Concept).
Issues with this label need to be resolved before the proof of concept.
If you want to help with any of these, message me:

robotman2412 on telegram
Badge.team telegram group


Service Bus - Update Client Builders to Leverage HttpPipelinePosition

Update client builders to leverage HttpPipelinePosition.
See #15630 for guidance.

This is a change that can be done additively without breaking backwards compatability.


mingw32

It would be nice to be able to override g++ with mingw32 for compiling windows specific headers.
This is useful for compiling windows specific headers that caused this error:
fatal error: windows.h: No such file or directory
#include <windows.h>

What do you mean by "override g++ with mingw32"? On what platform?

On linux, you can get the windows.h headers for free by using mingw32 compiler ie. /usr/bin/i586-mingw32msvc-g++

I see. Is there any advantage to using that specific compiler over MinGW-w64? I know vanilla MinGW still doesn't support Windows XP APIs and newer (at least not fully). Right now, using -os windows looks for MinGW-w64; in your case, it would be /usr/bin/i686-w64-mingw32-g++.
I forget if I added a $CC and $CXX override environment variable. If I didn't, I'll do so later.

Nope that works great, I didn't know how to activate mingw thanks!
I'm still confused why these headers are being loaded. https://github.com/sass/libsass/blob/master/file.cpp#L20-L22 guards the inclusion of the headers behind these sentinel flags, but qo includes them regardless of what -os I specify. Is there a piece I'm missing to build this?

Can you paste the output of qo -x? That is, a native Linux build?

Sure can,
Ubuntu 14.04 LTS
$ qo -x
[  0%] Beginning build
gcc libsass-src/cencode.c -c --std=c99 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_cencode.c.o
g++ libsass-src/base64vlq.cpp -c --std=c++11 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_base64vlq.cpp.o
g++ libsass-src/ast.cpp -c --std=c++11 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_ast.cpp.o
gcc libsass-src/posix/getopt.c -c --std=c99 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_posix_getopt.c.o
g++ libsass-src/bind.cpp -c --std=c++11 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_bind.cpp.o
[  1%] Compiled libsass-src/cencode.c
g++ libsass-src/constants.cpp -c --std=c++11 -Wall -Wextra -Wno-unused-parameter -m64 -o .qoobj/libsass-src_constants.cpp.o
libsass-src/posix/getopt.c:58:21: fatal error: windows.h: No such file or directory
 #include <windows.h>
                     ^
compilation terminated.
[FAIL] Step "Compiled libsass-src/posix/getopt.c" failed with error: exit status 1

It auto fails on OS X with llvm/clang message.

What happens if you put an #error before the second line of that file?
#ifdef _WIN32
#error _WIN32 defined here
#include <direct.h>
#define getcwd _getcwd

And what's the OS X error?

OS X auto dies with error about clang not supporting cross compilation.
-> % qo -os "darwin"
[FAIL] LLVM/clang does not come with a Windows resource compiler (if this message appears in other situations in error, contact andlabs)

You're trying to build a .rc file, which qo hardcodes to mean "Windows resource". What's your directory structure? Is this .rc file not a Windows resource? If I'm wrong I can fix it...

I think it's finding an rc file because qo scrapes the directory
recursively. It appears the makefile specifies certain files to compile and
other files are loaded conditionally based on architecture and other
requirements. This makes building a little bit of a headache since you have
to read the headers to figure out what files are necessary.
Is there perhaps, and I realize this is a lot to ask, a way to whitelist
only certain files to be built?
On Mon, Apr 20, 2015 at 9:15 PM Pietro Gagliardi<EMAIL_ADDRESS>wrote:

You're trying to build a .rc file, which qo hardcodes to mean "Windows
resource". What's your directory structure? Is this .rc file not a Windows
resource? If I'm wrong I can fix it...
—
Reply to this email directly or view it on GitHub
https://github.com/andlabs/qo/issues/6#issuecomment-94614819.

Can't you just put it in the Windows folder?

As an example, these files are passed to g++: https://github.com/sass/libsass/blob/master/Makefile#L114-L153 and these headers are only passed when using MinGW: https://github.com/sass/libsass/blob/master/Makefile#L161-L172

The rc file in question (res/resource.rc) is indeed a Windows resource file. I can definitely add conditional compilation in a similar way as the go tool does it, but libsass as it stands isn't compatible with qo's directory name expectations...

Ahh duh, go build conventions! I'll rework the file structure and try again.

Another little caveat with a file.cpp:
file.cpp
#include <header.h>

Then a file structure like:
header.h
subdir/file.cpp

This is throwing errors with qo, but seems to work fine with libsass's make tools. Should this work as is?

No; what errors does it throw up? What is the difference between qo -x and make?

Glad you asked, that's what I've been looking at. https://gist.github.com/drewwells/5819cbba45ac6e0aa626

I moved more files around, then failed on
plugins.cpp:(.text+0xd1): undefined reference to `dlopen'
plugins.cpp:(.text+0xf1): undefined reference to `dlsym'
plugins.cpp:(.text+0x130): undefined reference to `dlsym'
plugins.cpp:(.text+0x187): undefined reference to `dlsym'
plugins.cpp:(.text+0x1de): undefined reference to `dlsym'
plugins.cpp:(.text+0x267): undefined reference to `dlerror'
plugins.cpp:(.text+0x29c): undefined reference to `dlclose'
plugins.cpp:(.text+0x2db): undefined reference to `dlerror'

This is resolved by passing -ldl, how do you specify build flags?

// #qo LIBS: dl

Thanks that worked great! Is there anyway to specify ignoring certain files? IGNORE: contrib/ or similar?

@drewwells Not that I know of, though that would be a nice feature.


Roll engine 67aadb62068a..7bb5b9aea51c (1 commits)

https://github.com/flutter/engine/compare/67aadb62068a...7bb5b9aea51c
git log 67aadb62068ad251c79affa2ae68d6579d8e2d93..7bb5b9aea51c66645407903ec55004a40a35c65f --no-merges --oneline
7bb5b9aea Wire up Swiftshader based OpenGL ES unit-tests on hosts. (flutter/engine#9264)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (liyuqian@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/5417570199404544

Commit queue failed; closing this roll.


Enable source maps in Karma

By changing the polyfill.js redirect to being served out of /base/ and including .min.js.map files in the Karma server we can make use of source maps when inspecting minified code.
This change builds upon https://github.com/web-animations/web-animations-next/pull/468.

lgtm


React Native: Store enhancer is not a function

Code..

The store enhancer just landed in master this morning.  A build hasn't been cut yet though.  It'll be 0.5.0 later tonight or early tomorrow.
Can you verify you're installing 0.4.0?  Or are you indeed off master here?

 I was in 0.4.0 :)

Alrighty, 0.5.0 is on its way to the press.  This contains the new store enhancer.  Lemme know if you have any problems at all!


Update data from Zurich 2025

Hi. My Home Assistant integration of OpenERZ stopped working mid of December 2024 (Zurich). Is the data for 2025 just missing, or did the API change? – Thanks in advance.

@maxbie The data is currently missing, I'm planning to work on it this week, so that hopefully it'll work again soon. Thanks for your understanding!
This integration looks super nice. Is there any code .ou could share or that I could link to (as a usage example of OpenERZ).

@metaodi Thank you for your response. No hurry; it’s enough for me to know that I don’t need to make any changes. There’s no collection scheduled for us during these days anyway.
I’m happy to share my code, but I should mention that I’m not a programmer, and professionals will probably shake their heads at it.
P.S. Cargo and E-Tram are intentionally crossed out because they don’t provide information about my specific local collection point. They only indicate that there’s a collection day somewhere nearby.
Code.zip


A question

Hi,
I was reading https://research.arcadiascience.com/pub/resource-protein-cartography/release/5
I have a question. How do you know that most of your "outliers" aren't incorrect gene structure predictions? This seems the most likely explanation. There are up to 50% gene structure errors in genomes that have not had the gene structures manually reviewed.
See for example PMID: 31787936

Hi Val, thanks for pointing this out! This is an important consideration. We don't have a quick way of knowing whether gene structure prediction errors are responsible for outlier proteins in our analyses. We rely on retrieving protein sequences from UniProt, some of which may be derived from transcriptomic data, while others might be derived from predicted gene models. For individual proteins, we can't guarantee that the sequences are correct.
However, given that our analyses are focused primarily on clusters of proteins that originate from different organisms, I would be surprised if outlier clusters were completely driven by gene structure prediction error. I would not expect gene structure predictions to fail in a way that generates similarly unusual proteins across different genomes from different organisms, which may have been generated by different groups of researchers and using different methods.
Ultimately, our tool is focused on providing users the ability to rapidly explore proteins similar to their proteins of interest. Downstream analyses, such as validation of protein sequence, would still be necessary for definitively assigning protein function.

OK, that would be unlikely if they are clusters of outliers!
v


Virus detection

Description
The releases are detected as virus on 17/71 tests
Can you reliably reproduce the issue?
https://www.virustotal.com/gui/file/dc8cd7efd1318b293c473fbe4ab5aac994e78b9e379aa03fb166cee352f06e28/detection/f-dc8cd7efd1318b293c473fbe4ab5aac994e78b9e379aa03fb166cee352f06e28-1596319959
Expected behaviour
Not detected
Screenshots.
https://www.virustotal.com/gui/file/dc8cd7efd1318b293c473fbe4ab5aac994e78b9e379aa03fb166cee352f06e28/detection/f-dc8cd7efd1318b293c473fbe4ab5aac994e78b9e379aa03fb166cee352f06e28-1596319959

If you read the report, it's saying it contains a cryptocurrency miner. There's not really a lot we can do about VirusTotal deciding that cryptocurrency miners are virii

Thank you for your answer, i'll add it to the description


Spreadsheet commands with special characters result in errors

If I have a command with a special character in the spreadsheet, pressing Ctrl + L will generate a script with incorrect character.
For example, the command revisão will produce this line of code:
if ((input == "revis㯢) and (UsingAnyWorkcomputer)) ;
{
close_lngui()

return
}

Does the cord work or no? I think this depends on the type of encoding you view your code in.
I tried:

Which generates the following when viewed on notepad++ with ANSI encoding:

But switching to UTF-8:

Maybe something like this will help: https://www.mrexcel.com/board/threads/vba-create-text-file-in-utf-8-rather-then-ansi.1204545/

Does the code work or no?

It doesn't. Sometimes it throws me an error message and prevents me from reloading the script. Other times, the script reloads, but the command fails every time. These behavior seem to be related to the kind of special character I use.

I think this depends on the type of encoding you view your code in.
I tried:  Which generates the following when viewed on notepad++ with ANSI encoding:  But switching to UTF-8:

Yes, opening the code with notepad shows me the correct characters, but on Scite4AutoHotkey, it shows the weird character I posted in the OP.
How should I approach this? I'm thinking that since the macro recreates the script everytime it runs, then the solution should be in the macro, no? Or could I just change the encoding in LNCHR-Commands.ahk?

Sweet, it worked and was far easier than I thought!
Sorry for opening so many issues, but I'm in the process of adopting your code as my daily driver and so many questions have been appearing so far. Thanks for your support!


map not loaded when usung ng show

Hi, there I just define a ng show variable to show a when click a button, but the map is not loaded , But I can see only the border of wapper div

Please provide me a plunker example

Closing. if you can reproduce issue with a plunker example, it will be reopened.

I ran into the same problem.
I've created a tab system using ng-show. When the map is in tab 2, for example and I start on tab 1, when i change to tab 2, the map only show as a grey screen. Only works normal when starting direct at tab 2.
See this plunkr: http://plnkr.co/edit/iJRAgrMpSsme1aKuOz4v?p=preview
Using ng-if instead of  ng-show works.

It's simple.
Google maps were rendered within hidden element, which is 0px width and 0px height, and you are hiding and hiding those. ng-if works because it recreates the DOM element and rerender the map.
You need to resize the map if you want to start it as hidden element.


Limit HTTP request method cardinality: original_method (option A)

Moving in https://github.com/open-telemetry/opentelemetry-specification/pull/3478.
Changes

restricts http.request.method values to well-known names
requires to use other for unknown methods to prevent cardinality explosion if a malicious (or buggy) client sends custom and dynamic methods.
allows recording actual method value in the http.request.original_method

There was a discussion on the original PR and at HTTP SIG meeting, the summary and options are in the comments.

Option A
http.request.method represents the canonical method, values are restricted on all signals. (currently implemented in this PR)
Example:

Invalid method:

http.request.method = other
http.request.original_method = XYZZ (only if different from method)

Valid method:

http.request.method = GET

Cons:

breaking for existing ECS users who populate it on logs.
it's necessary to check two fields to find the method: http.request.original_method first and if missing, check  http.request.method

Possible solution:  Different requirement levels for different signals

Logs:  http.request.original_method could be required
Traces http.request.original_method could be conditionally required only if different from http.request.method

I.e. example of a valid request would be

http.request.method = GET
http.request.original_method id empty on traces and is GET on logs

Option B
http.request.method represents original method.
Invalid method:

http.request.method = XYZZ
http.request.canonical_method = other

Valid method:

http.request.method = GET
http.request.canonical_method = GET

Cons: duplication (otherwise http.request.method would capture invalid methods only).

Option C
Single attribute http.request.method, but special rules for span names and metrics
Invalid method:

Traces:

http.request.method = XYZZZ
span name: HTTP other

Metrics:

http.request.method = other

Logs:

http.request.method = XYZZZ

Valid method:

Traces:

http.request.method = GET
span name: HTTP GET

Metrics:

http.request.method = GET

Logs:

http.request.method = GET

Cons:

Slightly different attribute semantics for metrics
Harder to do traces/logs-to-metrics aggregation

Different requirement levels for different signals

I picked this from A but was thinking of option C when I first read this. I agree, different signals have potentially different requirements but still the same field should be used. For a trace, only valid fields should be accepted / are part of the standard. For logs the same fields is more lenient but it is still encouraged, to be strict.
With the above, we could get the best of both worlds. There is a way to express in the schema requirements for different signals but still optimise for bringing all the different signals together. It is then up to the storage engine / query engine of the different implementations to see how they deal with the mixed data if signals should be brought together.
The part I'm most worried about A is:

it's necessary to check two fields to find the method: http.request.original_method first and if missing, check http.request.method

I expect if we go with A, we will apply this solution in many different places. I'm not against having an additional field to store the original or canonical one if needed, but there must be a field where everything can be queried together.

HTTP SIG meeting,

@lmolkova I unfortunately couldn't join, so hopefully the above does not just repeat what was already discussed, otherwise please ignore.

Discussed during Semconv SIG meeting:

we should preserve attribute semantics consistency across signals (eliminating option C)
we can make orinigal_method required on HTTP logs semconv (or perhaps security events semconv?) once they are added

based on this, I updated the PR to make original_method conditionally required for traces. Once we have a log convention that should reference it, we can move the attribute to a common yaml.
@ruflin do you think the following approach could work:

a specific semconv for HTTP access/security log would define a set of required attributes
it can require http.request.original_method to always be present

I understand it's still a breaking change for ECS users since the attribute is being renamed. It seems the alternatives listed above would not work in the long term once we take other signals, cardinality, and minimal duplication into consideration.

I'm thinking of the sem-conv like an onion. In the center, we have the shared semconv across all signals. It is the most lenient version of it. Each layer of the onion can become more strict (but not more lenient). What this means, http.request.method would be specified as SHOULD use GET etc. and not MUST. Then traces or metrics could use MUST. I tried to create a quick (ugly) diagram for this:

For me this adheres to the base principle mentioned above: "we should preserve attribute semantics consistency across signals".
The main lines in the PR we are discussing are the following. The discussion is if it should be MUST or SHOULD.
If the HTTP request method is not known to the instrumentation, it MUST set the `http.request.method` attribute to `other` and SHOULD populate the exact method passed by client on `http.request.original_method` attribute.

HTTP method names are case-sensitive and `http.request.method` attribute value MUST match a standard (or documented elsewhere) HTTP method name exactly.

If there is agreement in the group to proceed with the proposal, I don't want to block it. One of the reason is, that from my perspective the schema can become more lenient without a breaking change but not the other way around. So my proposed change could still be made later on.

@ruflin I think there's a few points maybe not getting across from the semconv WG here.
There are two MAIN uses cases in OTEL that need to be addressed here, and are different than ECS.

X-Signal joins.  If signals have different meaning/values for the SAME attributes between logs/metrics/traces it makes cross signal queries and dashboarding much harder.  This is one of the big "wins" for using OTEL over individual instrumentation is that we offer signals that can be joined and understood in unison.
Instrumentation.  When you go to produce metrics,traces,logs it can be MUCH easier to write a common set of signals to Context in OpenTelemetry and the pull those attributes as you generate each signal.  For this, signals MUST have the same value wherever they're used

As such, in terms of design space, we CAN play with the following:

Some signals have more attributes than others. E .g. metrics require low cardinality, so we expect their attribute set to always be a subset of similar logs/events/spans.
We CAN specify having multiple attributes with nuanced meaning, e.g. http.method vs. http.raw_method

But the "layer of the onion" with strictness analogy doesn't really work here.  I like the layer of the onion, but think about it in terms of common key-value that can be shared across signals, with each signal being ALLOWED to have more attributes if needed, and each "layer" of your o11y pipeline being able to add more attributes (e.g. otel collector enhancing telemetry with extra information).
Given the need for metric cardinality concerns, I think http.method needs to be the core in the onion with low-cardinality restrictions (what @lmolkova has in this PR).  We can then add additional attributes to Logs (where higher cardinality is acceptable) without breaking metric<->log correlation.

I would be OK with XYZ becoming other but Get I'm not sure. Putting myself in a OTel user shoes, I would rather expect the library/backend to figure this out for me and "map" Get to GET or something standard.

I think somebody else has mentioned this already but it depends on the particular HTTP implementation if Get is treated like GET or like an unknown method. In the latter case, it would be extremely confusing if instrumentations mapped it to GET. However, if the instrumentation has the knowledge whether the instrumented server maps it itself, or ideally even has access to a pre-normalized method, then it could do some sort of "smart" mapping.

I'm strongly in favor of Option D. This addresses the concerns I raised in the previous PR about unexpected behavior for security users, but most critically I think it's also the ideal user experience when consuming this data. I hate the idea of users having to make decisions about which fields they query based on the value of other fields, so I like that if a user wants to query the original value then they use the base field, and if they want to accept some context loss in order to benefit from low cardinality, they do use that field. In both cases, they just use the one field that makes sense and it just works.
This does mean that we're duplicating data, but I think that should be acceptable if it's truly in the best interests of the overall user experience of consuming the data. Storage mechanisms like Elasticsearch could implement solutions to ensuring duplicate data like this does not incur twice the storage requirements overall - that many don't should be a factor to consider, but it shouldn't be the deciding factor IMO.

As a comparison, I have implemented option B (which seems to be option D from @joaopgrassi proposal, but canonical method stays case-sensitive) in https://github.com/open-telemetry/semantic-conventions/pull/34. PTAL and provide feedback or approve if you're onboard.

Option E: not doing anything special - if we get a weird HTTP method "XYZ", just keep it.

Option E: not doing anything special - if we get a weird HTTP method "XYZ", just keep it.

@reyang it's probably fine for clients, but makes it easy to create some form of ddos attack on metrics when server does not sanitize it. Anyone can send unauthorized requests with random methods. Presumably, there are just a few points for an invalid method and they're not really interesting to anyone (i.e. do not skew any other data), how bad would it be?

@reyang it's probably fine for clients, but makes it easy to create some form of ddos attack on metrics when server does not sanitize it. Anyone can send unauthorized requests with random methods. Presumably, there are just a few points for an invalid method and they're not really interesting to anyone (i.e. do not skew any other data), how bad would it be to have a lot of (but quite short) time series?

Like I explained in https://github.com/open-telemetry/semantic-conventions/pull/17#issuecomment-1550023143, metrics cardinality is a general problem - nothing specific to HTTP methods. I think we should tackle this issue in the metrics API/SDK space so it can lift all boats.

For logs/traces, keeping the original value would help the user to understand what's going on, if they see something like "OTHER" / "other" / "INVALID" - it'll be hard to dig deeper unless the information is stored somewhere else (e.g. another key-value pair).
For metrics, cardinality problem would exist for any metrics and dimensions, it'll be better to have a generic solution instead of special solutions for each type of data or dimensions (e.g. SQL "INSERT" / "UPDATE" / "DELETE"). I don't think semantic conventions should mandate the cardinality (we can encourage best practices).

@reyang essentially what you're saying is Option C, but generalized beyond this specific attribute with solution postponed till after HTTP semconv stability? correct?
The proposal might look like "Metric instrumentations SHOULD populate canonical method and populate unknown methods as 'other'" Correct?
Without it, cardinality limits would protect from DDOS attacks, but can make time series that got through less useful.

@reyang essentially what you're saying is Option C, but generalized beyond this specific attribute with solution postponed till after HTTP semconv stability? correct?

Yes. I think this is how semantic conventions should be positioned:

HTTP method has a preferred list of values - e.g. "GET", "POST", "PUT", etc.
The typical cardinality is around 10.
The semconv should not say something like "values not listed here MUST be converted to ..." or "values not listed here MUST be dropped" or anything strong (with "MUST" wording).
In the future we might say "instrumentations should provide hint/advice about the preferred list of values".

The API/SDK spec should be positioned to solve the cardinality/reliability problem:

The API should provide a way (e.g. hint/advice) to indicate the cardinality of certain attributes, and what are the preferred values vs. noise.
The SDK should provide mechanisms to control how to deal with noise and cardinality pressure (e.g. dim-capping).
THe SDK should provide a reasonable default behavior.

@reyang essentially what you're saying is Option C, but generalized beyond this specific attribute with solution postponed till after HTTP semconv stability? correct?

Yes. I think this is how semantic conventions should be positioned:

HTTP method has a preferred list of values - e.g. "GET", "POST", "PUT", etc.
The typical cardinality is around 10.
The semconv should not say something like "values not listed here MUST be converted to ..." or "values not listed here MUST be dropped" or anything strong (with "MUST" wording).
In the future we might say "instrumentations should provide hint/advice about the preferred list of values".

The API/SDK spec should be positioned to solve the cardinality/reliability problem:

The API should provide a way (e.g. hint/advice) to indicate the cardinality of certain attributes, and what are the preferred values vs. noise.
The SDK should provide mechanisms to control how to deal with noise and cardinality pressure (e.g. dim-capping).
THe SDK should provide a reasonable default behavior.

There was a general push-back to have different semantics for different signals. Dim-capping on metrics can be considered as such inconsistency.  cc @jsuereth @arminru
Still, I drafted it here: #35 with the caveat that I don't believe instrumentation should provide hints on HTTP methods since we have a standard and common 10 methods that are used in the absolute majority of requests.
the drawback of this change is that span name is not quite as specific as it was before, but I don't see a huge harm even if the span name is of high cardinality for invalid requests. group-by, top-N queries should still work great

fwiw as it stands today this breaks instrumentation for anyone using Fastly purging, which uses a custom PURGE method https://docs.fastly.com/en/guides/soft-purges
In general, while I agree often unforseen cardinality bomb in waiting for many otel users metric backends, this feels like a bit of solution engineering rather than a thoughtful approach to a general problem in the opentelemetry, as @reyang already pointed out. For example, a processor within an otel collector pipeline already can solve this issue with potentially thousands of fewer lines of code needed to be added and maintained within the opentelemetry instrumentation ecosystem.

Option E: not doing anything special - if we get a weird HTTP method "XYZ", just keep it.

I'm not sure not doing anything is a good approach. I believe we can all agree that there is a problem at the moment.
Metric and span names are affected, metrics being the most affected, as it can be exploited by a malicious actor to either 1. blow up the metric cardinality/increase storage costs and 2. blow up memory usage of the app, if the SDK is keeping all the time series in memory (this one I agree the SDK should have protections for).
What concerns me with option A as it stands is (emphasis on the concern):

If the HTTP request method is not known to the instrumentation, it MUST set the http.request.method attribute to other and SHOULD populate the exact method passed by client on http.request.original_method attribute.

So, let's say an instrumentation/http framework receives Get. With the above wording, Get can either be:

Get: The instrumentation/http framework understands this value and sees it as valid
GET: The instrumentation/http framework knows Get is mapping to GET so it also understands it and uses GET to report metrics/spans
other The instrumentation/http framework does not understand this, nor has an internal "mapping" for normalized values

Now, let's see if I have something like the OTel demo app, composed of services in different languages/frameworks. Some will report Get, some will report GET others other. I honestly don't think this is good.

For example, a processor within an otel collector pipeline already can solve this issue with potentially thousands of fewer lines of code needed to be added and maintained within the opentelemetry instrumentation ecosystem.

We have to remember that we can't rely on people having the collector deployed in their infrastructure.

In general, while I agree often unforseen cardinality bomb in waiting for many otel users metric backends, this feels like a bit of solution engineering rather than a thoughtful approach to a general problem in the opentelemetry, as @reyang already pointed out

As an exercise, I just went through all metric semantic conventions we had, looking at the defined attributes and if any of those suffer from the same problem as http.request.method today:

possibly unbounded value
Its value can be manipulated from the outside
Has a "normalized" counterpart that can be mapped and used instead

and I couldn't find any that suffer from point 2 and 3 above. The ones I found that may be problematic just on the first point are:

ht.type
`hw.error.type
`logical_addresses

I wonder if anyone else has also done this exercise and has different results/opinions?

@joaopgrassi wouldn't grpc span names be subject to the same potential for cardinality issues given bad inputs? This is just one  example off the top of my
head, haven't done a survey of the ecosystem or anything
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/rpc.md#span-name

The span name MUST be the full RPC method name formatted as:

$package.$service/$method
(where $service MUST NOT contain dots and $method MUST NOT contain slashes)
If there is no package name or if it is unknown, the $package. part (including the period) is omitted.
Examples of span names:
grpc.test.EchoService/Echo
com.example.ExampleRmiService/exampleMethod
MyCalcService.Calculator/Add reported by the server and MyServiceReference.ICalculator/Add reported by the client for .NET WCF calls
MyServiceWithNoPackage/theMethod

@joaopgrassi I'll try to address your other comments when i have some time, but tldr I think this a general problem that is better served by a general solution. the 3 criteria you've used above aren't really appropriate (note my original comment wrt fastly PURGE, there are valid values to http method that are not necessarily documented in some canonical place) rather than the current whack a mole approach (which is maybe ok but should be done out of process imo, rather than trying to stuff it into otel instrumentation across all langs)

@ericmustin I think the rpc method name should be stable enough and not cause problems, thinking on gRPC service definition/method names those are fixed and are not subject to a external user modifying its value so those should be fine I think.
I get your point, that's why I tried to look if we had something very obvious like http.request.method today in Metrics but seems we don't. I commented out in the other PR (Option D) that I agree we may have this situation with other attributes so I'm also torn on accepting any of the options here because of it.

As an exercise, I just went through all metric semantic conventions we had, looking at the defined attributes and if any of those suffer from the same problem as http.request.method today:

Thank you for the research! Would you mind creating an issue so we won't forget about it when it's the time for the corresponding semconv to stabilize?

Trying to summarize:
General

Important: Correlation of signals! We want to have the same values on an attribute when queried across different signals.

Spans

Strong requirement to have low cardinality on the span names
For non-standard methods (or casing) still we want to be able to see the actual HTTP method. Example use cases are:

see @ericmustin's example
detection of techniques like HTTP verb tampering

Metrics

Strong requirement to have low cardinality on metric dimensions.

Logs

Logs should contain the original HTTP method (same reasoning as with spans, as otherwise certain logging and security use cases are not possible) and for correlation reasons the canonical method.

Technically, both options (Option A and Option B/D) satisfy the above-mentioned requirements.
So, the pros and cons for A vs. B are rather of lower significance:
Pros for Option A

Less data duplication. (How strong is this argument in practice, considering that we are talking about a value that typically has a few characters?)
@jsuereth, you mentioned (in the Spec SIG meeting this week) that for users looking into http.request.method (as the sanitized) value is more intuitive than looking into http.request.canonical_method. (Not sure if that's an objective argument. I personally wouldn't agree that it's more intuitive because there is an implicit / hidden aspect that the value of http.request.method might have been sanitized to become canonical. So, it's not the observed value.)

Pros for Option B/D

The attribute names describe more clearly what is the value:

http.request.canonical_method explicitly makes clear that the value might have been altered to be canonical.
http.request.method is the HTTP method (as observed)

It aligns with ECS. (Not a strong argument when weighing breaking ECS vs. breaking Semconv. BUT, with the HTTP method we already broke Semconv anyways. If not strongly required, breaking both sides feels bad.)
For individual use cases it's not necessary to check two fields (as it is the case with option A, because http.request.original_method would be optional and finding out the original method potentially requires if ... else ... logic when querying).

So, while both options above would meet the strong requirements, I'd clearly prefer Option B.
Related: WDYT about thinking about and maybe write down general guidelines for similar cases, so we can apply it to similar discussions / cases next time when considering other fields with corresponding challenges?

For individual use cases it's not necessary to check two fields (as it is the case with option A, because http.request.original_method would be optional and finding out the original method potentially requires if ... else ... logic when querying).

@AlexanderWert  I think this can happen with option A as well.
Let's say we have a semconv for HTTP access/security event and it will require http.request.original_method to be present. It would also have other attributes related to access.
If you're interested in a security, you'd query this event specifically. It'd be wasteful to query all data (traces and logs of all kinds) to find HTTP method.
TLDR: In Option A, original_method  is conditionally required only when different, but other conventions we define can have different level and eliminate this concern.
Please let me know if I miss something here.

if a dedicated event(s) with the required original method would resolve inconvenience when querying, and if we agree that duplication costs are not justified, it seems to leave us with following points:

different personal preferences
Option B/D without duplication where http.request.method is almost never populated on spans and where it is, it's populated with invalid data.

If we agree that duplication is not justified, I think that eliminates Option B/D, since as @lmolkova mentions, that would then mean only populating http.request.method on spans for invalid http methods which I don't think anyone wants(?)
One option I don't recall if we've discussed:

http.request.canonical_method (always populated on spans)
http.request.original_method (only populated on spans if different than http.request.canonical_method)

(this is basically the same as Option A, with http.request.method renamed to http.request.canonical_method)
This might give ECS a better deprecation path since we wouldn't be altering the definition of http.request.method.

I think renaming method to canonical_method would be nice to avoid surprises.

My apologies for being dense here: if Option A is accepted, for what events will method be modified but original_method not be present?

My understanding is that this must never happen

My preference is on Option A because:

we keep the door open for future general configuration improvements (for metrics, traces, and logs)
we do not rush one-off advice API implementation to solve a specific problem on metrics only

db.operation?

If high-cardinality, then you have bigger problems (SQL injection attack)

Note that db.operation is in fact very different from the HTTP method:

It's not just standard SQL SELECT/INSERT/..., this attribute also stores operations for non-SQL DBs, e.g. Redis (HGET), MongoDB, and lots of others. Producing a set of acceptable values for this attribute would be quite a challenge (even various SQL dialects may have very different operation sets)
Even in the case of SQL/query injection, usually something (either the instrumented library itself, or a query lexer in the instrumentation) has to recognize the given operation. Usually (in the case of Java instrumentation even always) when you query inject complete rubbish as the statement the db.operation just won't be set.

I'm also in favor of the option A, the HTTP method seems to be the only case of an attribute provided directly by the users of the instrumented application, and option A seems like the simplest (and most effective) solution to that problem.

How general a problem is this?
https://github.com/open-telemetry/semantic-conventions/pull/17#issuecomment-1561026446

@trask  We discussed this within my team and actually we found others, also in HTTP that might also be problematic and open to user changes. server.address and server.port because the semconv says to use the values of the Host  header
There's also an issue related to this in the JS repo https://github.com/open-telemetry/opentelemetry-js/pull/3880. Could even be an attack vector https://crashtest-security.com/invalid-host-header/

server.address and server.port because the semconv says to use the values of the Host header

Even if they don't use the Host header, they are problematic. Consider a client that implements a web crawler contacting a huge number of different servers. Consider a server that extensively uses subdomains e.g. <companyname>.zoom.us https://support.zoom.us/hc/en-us/articles/215062646-Guidelines-for-Vanity-URL-requests

For the HTTP status code, someone actually already created an issue to introduce status_class opentelemetry-specification#2947

@Oberon00 @reyang let's keep crawler scenarios separate there is no external attack problem here - this is a client choice to contact multiple servers. The cardinality issues are known in advance and mitigating it is fully in the hands of crawler service owners. We can recommend them to drop corresponding attributes or come up with their own conventions.

@Oberon00 do you have any remaining concerns that you'd like to see addressed before merging?

I guess we are aware that this will basically pre-determine the general "_original" naming convention and the "_OTHER" value that #117 asks for, as soon as HTTP is marked stable + a release is cut. I think that's fine from a priority perspective.


Implement Anonymous/Guest Sign-In Functionality

Description:
The application currently supports sign-in with email and password. We aim to enhance user accessibility by introducing an anonymous or guest sign-in option. This feature will allow users to explore the game without creating an account, providing them with immediate access to gameplay while still preserving the option to sign in or sign up for a more personalized experience later.
Acceptance Criteria:

Implement an anonymous sign-in method using Firebase Authentication.
Ensure that users who choose to sign in anonymously can access the game's features similar to signed-in users.
Provide an option for anonymous users to convert their account into a permanent account (email/password) without losing game progress.
Update the SignInScreen UI to include a button or option for users to continue as a guest.
Ensure that the game state is properly managed and loaded for anonymous users, similar to authenticated users.
Conduct thorough testing to verify that anonymous users can sign in, play the game, and optionally convert to a full account seamlessly.

Separating "Provide an option for anonymous users to convert their account into a permanent account (email/password) without losing game progress." into a separate issue: ##53


Fix date_picker and color form fields not working in settings

This won't work properly when using translations (date field is not set to be translatable but Twill saves settings in all locales I see). I get:
htmlspecialchars() expects parameter 1 to be string, array given (View: /Users/mbratkovic/Sites/dsrc/resources/views/vendor/twill/partials/form/_date_picker.blade.php)


Changing the pdf source does not render the canvas.

First of all, thank you for the awesome package. with that said I am having trouble with it when I am changing the source of the viewer on run time.
the first load of the viewer shows the pdf perfectly, but once the source has
this is my code.
wrapper component
<PDFViewer v-if="!loading" :preview="filePath" :key="rerender"/>
filePath is change when i click a button to supply the updated file path
PDFViewer component template
<template>
        <div class="app-content grey">
            <vue-pdf-embed ref="pdfRef" :source="pdfSource" :key="pdfSource" :page="page"
                @password-requested="handlePasswordRequest" @rendered="handleDocumentRender" :disableTextLayer="true"
                :disableAnnotationLayer="true"/>
        </div>
</template>

the script
import Config from '@/services/config';
import _ from 'lodash';
import { defineComponent, ref } from 'vue';
import VuePdfEmbed from 'vue-pdf-embed'

export default defineComponent({
    name: 'PDFViewer',
    inject: ['emitter'],
    props: {
        preview: { type: String }
    },
    components: {
        VuePdfEmbed
    },
    data() {
        return {
            isLoading: true,
            page: 1,
            pageCount: 1,
            showAllPages: true
        }
    },
    computed: {
        pdfSource() {
            const filePath = Config.APISettings.hostUrl + '/' + this.preview;
            return filePath
        }
    },
    watch: {
        showAllPages() {
            this.page = this.showAllPages ? null : 1
        },
    },
    methods: {
        startCase(str) {
            return _.startCase(str);
        },
        handleDocumentRender(args) {
            console.log(this.$refs.pdfRef);
            this.isLoading = false
            this.pageCount = this.$refs.pdfRef.pageCount
        },
        handlePasswordRequest(callback, retry) {
            callback(prompt(retry ? 'Enter password again' : 'Enter password'))
        }
    }
});

I have solved the issue by doing this work around
        updatePreview(previewPath: string) {
            this.filtToPreview = previewPath;
            setTimeout(() => {
                this.rerender++;
            }, 100);
        },

if anyone has a more elegant solution please show me.

I have solved the issue by doing this work around
        updatePreview(previewPath: string) {
            this.filtToPreview = previewPath;
            setTimeout(() => {
                this.rerender++;
            }, 100);
        },

if anyone has a more elegant solution please show me.

Hi, you found a more elegant solution?. Its work for me too, but I prefer a better "solution" @Conrekatsu


get rid of shared const (close #68)

/cc @inikulin @churkin

\r-

FPR

lgtm

@miherlosev What was changed after my review?

as say @churkin
we need to change order for import as follow:
at first - constants
at second - classes
then utils and separate methods (import as {...} from)

@miherlosev Guys don't do this, let's not complicate rules. Currently the rule is simple, let's keep it:
at first external or built-in deps, then internal deps.

lgtm


devicetree.h: Rework DT_ANY_INST_HAS_PROP_STATUS_OKAY

The macro is searching for all instances of specific device that contain specific property and evaluates to true (1) if any device does.
The macro used to do that by generating, using
DT_ANY_INST_HAS_PROP_STATUS_OKAY, a logical expression like (0 || 1 || 0), where each digit represented existence of property (1) or lack of it (0).
Unfortunately other util macros, like IS_ENABLED, were not able to evaluate such expression, as they often simply expect something they can evaluate to 0 or 1.
The commit here changes DT_ANY_INST_HAS_PROP_STATUS_OKAY to generate a list of tokens (1) where token is added to list only for instance of a device that has the property; then such list is processed using IS_EMPTY() macro and in the end 0 or 1 is generated, depending on whether any enabled instance of a device has the property or not. This change allows result of DT_ANY_INST_HAS_PROP_STATUS_OKAY to be used with macros like IS_ENABLED, IF_ENABLED or COND_CODE_x.

It would be nice if you could add a test case to tests/lib/devicetree/api.

It would be nice if you could add a test case to tests/lib/devicetree/api.

There is a test case. It should run on the PR, I have run it locally.
Or you mean the testcase that would check if IS_ENABLED and IF_ENABLED work? In such case, you are right, that should be done.

tests/lib/devicetree/api.

Done


[Feature Request]: example for LocalAI

Feature Description
LocalAI has an OpenAI compatible API.  So one can game an OpenAI wrapper to work with LocalAI. In fact, that's how langchain does it.
I think to support LocalAI, one just needs to use llama_index.llms.OpenAI(api_base="http://localhost:8080/v1", api_key="stub") or OPENAI_API_BASE environment variable.
It would be cool if there was a brief demo IPython Notebook for this, somewhere in LlamaIndex.
Reason
LocalAI is a nice alternative to Ollama or Llama.cpp for running models from Hugging Face.
Value of Feature
Lots of people use LocalAI. It was also previously requested here.

Actually trying this out, I am getting denied by openai_modelname_to_contextsize lookup.  Will need to make a backdoor for this

@logan-markewich do you mind re-opening this one until I get an example created for LocalAI?

@jamesbraza open!

Closing this since it seems that PR #7913 resolved this.

@nerdai no this is blocked by https://github.com/run-llama/llama_index/pull/8241, there's not a LocalAI demo yet


syntax checking does not work

The syntax checking does not work. A few symptoms:

When a file is edited, the on-the-fly syntax checking does not get triggered;
When a file is edited then saved, the checked results seem based on the old checking results. Maybe the syntax checking is cached yet not properly?
I didn't some simple debug, and found b:fsharp_buffer_changed is not updated correctly. Even the file is edited, its value is kept as 0.

I am using neovim 0.2.0, and python3. Thanks.

I don't really test with neovim. Does it work with normal vim?

The check is only done once you enter normal mode + a short interval.

That can happen if the check is very slow and doesn't update a field within some timeout. At some point the whole checking should be changed to use the job api so we don't have to hack around it. Perhaps using ALE.

Could be a neovim issue.

Just tried on a fresh installation of normal vim (debian vim v8.0) with only Synastic and vim-fsharp plugins. Same there. The syntax checking does not work properly.

the checking is correct if reloading the file;
I tried to call fsharpbinding#python#OnTextChanged() directly, yet it has no effect.

did you install mono and run make? you also need pathogen.

Yes, mono etc are installed, and the installation seems okay. For example, if I reload the .fs file using :e, the syntax checking works correctly. If there is any error, the plugin would show them.

I will try to look into this but you could create a Vagrantfile or similar with a repro it would allow me to investigate it more quickly.

Bump

@mudrasone I have issues with python3 and normal vim atm. Perhaps the same applies to neovim. Are you able to run neovim with python2 as a test?

@kjnilsson The error I experienced was with VIM - Vi IMproved 8.1 (2018 May 18, compiled Jul 22 2018 05:24:30). I'm using MacOS Mojave and have a feeling Python 2 and 3 could be causing issues because after installing nvim and the vim-fsharp plugin, I get this error:
Error detected while processing /Users/ptah/.vim/plugged/vim-fsharp/ftplugin/fsharp.vim:
line   37:
Python environment not found
Press ENTER or type command to continue

How is Python supposed to be setup?

Looks like python support isn't installed: see https://github.com/fsharp/vim-fsharp#troubleshooting
for help on how to check it.

I installed the required pip neovim package so the Neovim reports python 2 and 2 are "had", but I'm still experiencing the same issue I with vim.
The Fsi commands run properly, I'm wondering if the issue could just be with Syntastic?

It may be, it can be very hard to tell sometimes, it works ok for me with vim with python2 support. At some point I will consider removing Syntastic in favour of Ale and at the same time remove the python requirement all together.

Today I decided to try rewriting my Elm app w/ Bolero to see if Bolero could ease some of the troubles of having to go between Servant+Haskell & Elm.
Plus just some of the things that seem so well solved by the framework like routing, hot-reloading, isomorphic front/back end code are the things of my dreams!
Ran into issues with the plugin. Went through the troubleshooting steps and made sure I :echo has('python') and :echo has('python3') and both returned 1.
I'm pretty turned off by the fact that there's no ALE support for fsharp so I reluctantly installed Syntastic hoping I'd be good to go from there.
Then I ran into an error about FileOrDirectoryNotFound: 'fsharpi' something something about mono, so I installed mono with sudo apt install mono-devel and now I'm here...
Error detected while processing function provider#python3#Call:
  line   18:
Traceback (most recent call last):
  File "/home/erlandsona/.config/nvim/plugged/vim-fsharp/ftplugin/fsi.py", line 26, in __init__
    self.p = Popen(command, **opts)
  File "/usr/lib/python3.7/subprocess.py", line 800, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.7/subprocess.py", line 1551, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'fsharpi': 'fsharpi'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<string>", line 28, in <module>
  File "/home/erlandsona/.config/nvim/plugged/vim-fsharp/ftplugin/fsi.py", line 28, in __init__
    raise Exception ('Error executing fsi.  g:fsharp_interactive_bin="' + fsi_path + '" ' + str(e))
Exception: Error executing fsi.  g:fsharp_interactive_bin="fsharpi" [Errno 2] No such file or directory: 'fsharpi': 'fsharpi'
Traceback (most recent call last):
  File "/home/erlandsona/.config/nvim/plugged/vim-fsharp/ftplugin/fsi.py", line 26, in __init__
    self.p = Popen(command, **opts)
  File "/usr/lib/python3.7/subprocess.py", line 800, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.7/subprocess.py", line 1551, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'fsharpi': 'fsharpi'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<string>", line 28, in <module>
  File "/home/erlandsona/.config/nvim/plugged/vim-fsharp/ftplugin/fsi.py", line 28, in __init__
    raise Exception ('Error executing fsi.  g:fsharp_interactive_bin="' + fsi_path + '" ' + str(e))
Exception: Error executing fsi.  g:fsharp_interactive_bin="fsharpi" [Errno 2] No such file or directory: 'fsharpi': 'fsharpi'

I'm reluctantly installing VSCode to see if it'll "just work" but it's a bummer not to be able to use my favorite editor to try out the language :/

@erlandsona try https://github.com/ionide/Ionide-vim - it works really well.


Find My Mouse -> Esc don't terminate overlay in RDP

Microsoft PowerToys version
0.65.0
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
Mouse Utilities
Steps to reproduce

Place the mouse cursor on a RDP window
Press Left Control twice
Press Esc

✔ Expected Behavior
The overlay should disappear
❌ Actual Behavior
The overlay doesn't disappear
Other Software
mstsc

Are you still experiencing this issue? /needinfo

Now the overlay disappears by a mouse click, but not by pressing the Esc key.
Current version: 0.85.1


Option /app-cmd: does not accept multiple parameters delimited by space

Describe the bug
I'm trying to connect to server "guarded"  by CyberArk Privileged Session Manager.
I know nothing about it. They send me a command that should be executed on remote server during connect.
psm /u<EMAIL_ADDRESS>/a server.company.com /c PSM-RDP-HTML
So I split it between /app and /app-cmd parameters:
xfreerdp +clipboard +fonts /size:1800x1000  /drive:share,/tmp /bpp:16 /cert:ignore /sec:tls /app:'||psm' /app-cmd:'/u<EMAIL_ADDRESS>/a server.company.com' /d:domain /u:user /p:######## /v:rdp_server

But it does not works, xfreerdp fails with:
[15:04:14:217] [13331:13331] [ERROR][com.winpr.commandline] - Failed at index 1 [+clipboard]: Invalid sigil

The error message is confusing as the issue is not with first parameter but with /app-cmd. There can't be any space in the string. If I remove '/app-cmd' parameter or remove spaces, xfreerdp does not fail, but also does not login to the server as important parameters are not entered.
To Reproduce
Steps to reproduce the behavior:

start xfreerdp with parameter /app-cmd with more values delimited by space inside string
xfreerdp fails with error Invalid sigil

Expected behavior
xfreerdp connect to the remote server, start given program there and passes all parameters
Application details

FreeRDP version (xfreerdp /version) - This is FreeRDP version 2.3.2 (2.3.2)

Command line used
xfreerdp +clipboard +fonts /size:1800x1000  /drive:share,/tmp /bpp:16 /cert:ignore /sec:tls /app:'||psm' /app-cmd:'/u<EMAIL_ADDRESS>/a server.company.com' /d:domain /u:user /p:######## /v:rdp_server

Output of xfreerdp /buildconfig

This is FreeRDP version 2.3.2 (2.3.2)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=1 HAVE_INTTYPES_H=1 HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CAIRO=OFF WITH_CCACHE=OFF WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=ON WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_1_0=ON WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=ON WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=OFF WITH_MBEDTLS=OFF WITH_NEON=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PCSC=OFF WITH_PROFILER=OFF WITH_PULSE=OFF WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_SWSCALE=ON WITH_THIRD_PARTY=OFF WITH_VAAPI=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_WAYLAND=OFF WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          Gentoo
CFLAGS:              -march=native -O2 -pipe -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g -fno-omit-frame-pointer -DWINPR_DLL
Compiler:            GNU, 10.3.0
Target architecture: x64

Environment (please complete the following information):
Gentoo Linux x64

which shell are you using? this looks more like a problem with using the wrong syntax required for your shell.
Try " instead of '
can use the exact same command here on ubuntu 20.04 using default bash.