Invalid ES6 module rewrite

I was just trying to upgrade our compiler to head (To test out https://github.com/google/closure-compiler/commit/96dbbf6820d1e9ae862cf91a83116c391ba08519) and ran into the following issue:
The compiler throws an error on the first global let it sees in the first module it compiles.
Error: The nameNode for Var ModeDef$$module$src$mode must be a descendant of one of: [118, 162, 149, 105, 158, 120, 83]
This is triggered by the first line in a file that is just: let mode;
More info:
Command failed: java -jar -XX:+TieredCompilation build-system/runner/dist/runner.jar --flagfile="/var/folders/jk/j0ymfl3j6nj3w3k6_ngj7gfh003p7j/T/b57bfc05-be08-4697-ba20-9ea6a1d88227" --compilation_level=SIMPLE_OPTIMIZATIONS --assume_function_wrapper=true --language_in=ECMASCRIPT6 --language_out=ECMASCRIPT5 --externs=build-system/amp.extern.js --js_module_root=node_modules/ --js_module_root=build/fake-module/ --entry_point=./3p/integration.js --only_closure_dependencies=true --output_wrapper=(function(){var process={env:{NODE_ENV:"production"}};%output%})();
//# sourceMappingURL=f.js.map
 --create_source_map=build/cc/_3p_integration.js.map --source_map_location_mapping=|http://localhost:8000/ --warning_level=DEFAULT --js_output_file="build/cc/_3p_integration.js"
java.lang.RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.

The nameNode for Var ModeDef$$module$src$mode must be a descendant of one of: [118, 162, 149, 105, 158, 120, 83]
  Node(BLOCK): [source unknown]
  Parent(BLOCK): [source unknown]

	at com.google.javascript.jscomp.Var.declarationType(Var.java:225)

Does anyone have an idea what is going on?

I, uh, recompiled (adding some debug info) and the problem went away.
Closing for now.


Round-trip failure with #keyPath expression

Issue Kind
Round-Trip Failure
Source Code
#keyPath((b:)

Description
No response

rdar://99430606


Docker volumes on macOS

If you are using a mac machine to run your server the following won't work in most cases:
 volumes:
      - ./redis_slave:/data

because in mac only some folders are allowed for mounting docker volumes.  I propose to add something like this to the documentation
For macOS users
If yor server is macOs you are limited to specific folders to mount docker volumes, so for example
the volume on "./redis_master:/data" may not be mounted and produce an error since the relative path "./" is not likely to be included in the inclusion list.
In order set up the volumes properly refer to:
https://docs.docker.com/docker-for-mac/osxfs/#namespaces

Thanks for the proposal, I will add this to the readme


[FLINK-4693][tableApi] Add session group-windows for batch tables

Thanks for contributing to Apache Flink. Before you open your pull request, please take the following check list into consideration.
If your changes take all of the items into account, feel free to open your pull request. For more information and/or questions please refer to the How To Contribute guide.
In addition to going through the list, please provide a meaningful description of your changes.

[×] General

The pull request references the related JIRA issue ("[FLINK-4693][tableApi] Add session group-windows for batch tables")
The pull request addresses only one issue
Each commit in the PR has a meaningful commit message (including the JIRA id)

[ ] Documentation

Documentation has been added for new functionality
Old documentation affected by the pull request has been updated
JavaDoc for public methods has been added

[×] Tests & Build

Functionality added by the pull request is covered by tests
mvn clean verify has been executed successfully locally or a Travis build has passed

@fhueske @twalthr  I reopened the PR and propose the design doc.
https://docs.google.com/document/d/1WIOKNwfTW8nMZsRVL-ANIzxIiuXqVNGxwjiPj7go7hg/edit

Thanks for updating the PR @sunjincheng121. I will shepherd this.

Btw it is not necessary to close and open a new PR after rebasing. You can simply perform a force push.

Hi, @twalthr  thanks a lot for the review. I have updated the PR according to your comments. Let me know if  I  miss something，thanks again!!

Thanks for updating the PR. +1 to merge.

The PR looks good to me, +1 to merge

@fhueske Thank you very much for your detailed review, your optimization suggestion is that I should be concerned, I will update the PR as soon as possible. Thanks again!!!

@fhueske I have updated the PR according to your comments.The change information is as follows：

Fix "remember and read input objects across method calls".
Amend some code format.
thanks again. SunJincheng.

Thanks for the update @sunjincheng121. The changes look good. I will merge this.


feature request (take off warnings in android*-arm dnscrypt-proxy)

@jedisct1,
can you, please, in next releases take off two lines of warnings that appears on every call of dnscrypt-proxy from the shell script? it's very annoying and may spoil script's logic in some circumstances (in my  setup of afwall+dnscrypt-proxy script afwall.on analyzes the flow of itself and calls afwall.off in case of emergency to drop all traffic).
# /system/xbin/dnscrypt-proxy -resolve intel.com
WARNING: linker: /system/xbin/dnscrypt-proxy: unused DT entry: type 0x6ffffffe arg 0xe24
WARNING: linker: /system/xbin/dnscrypt-proxy: unused DT entry: type 0x6fffffff arg 0x1
Resolving [intel.com]

Domain exists:  yes, 4 name servers found

Google returns some useful information about this:
https://stackoverflow.com/questions/33206409/unused-dt-entry-type-0x1d-arg
And maybe one thing you can do is use what they call a "cleaner" such as that one: https://github.com/kost/android-elf-cleaner

@jedisct1 ,
thanks, it works.


Update bcsd path

Renamed bcsd.py to core.py and moved into methods/bcsd/core.py

closed in favor of #118


Unmaintained and overly complex

It seems to me that this project is not a good choice at all for anybody to use aside from as an example and PoC.  There are multiple reasons I say this:

JSON Cloudformation, with over 2,000 lines meaning a maintenance nightmare if things go wrong or wish to be updated.
Overly complex design - lambdas triggering rules etc.
Lambdas are in more than one language (Python and NodeJS).
Lambdas are huge for small tasks (600+ lines for something to get IP lists?!)
A growing backlog of PRs and Issues.
Very few commits and commitors since it's original push in 2016.

It is a good example of what could be done with AWS WAF, however I have found myself on more than one occasional dealing with clients who believe that this repo is the best choice for them to roll out AWS WAF simply based off AWS blog promoting it. I believe that this is creating a maintenance risk in these organisations, who also end up spending significant time patching in their own changes to this repo instead of starting from a clean slate.
The point of submitting this Issue is to see if AWS will alter their Blog and/or README to clearly state this this is an example only and to recommend that customers use something a bit more fit for purpose based on their actual needs.

Hi d-j-c,
Thanks for your comment. Based on the previous feedbacks, we're working on an update .. the main focus is to clean up all repo's contributions. This includes:

https://github.com/awslabs/aws-waf-security-automations/pull/64
https://github.com/awslabs/aws-waf-security-automations/issues/57
https://github.com/awslabs/aws-waf-security-automations/issues/62
https://github.com/awslabs/aws-waf-security-automations/issues/63
https://github.com/awslabs/aws-waf-security-automations/issues/44
https://github.com/awslabs/aws-waf-security-automations/issues/60

As for the template complexity, cfn-lint might help to remove implicit dependencies and I'm still considering translate it o YAML.
Please, feel free to open as many issues you consider that it's important to be included ... we will answer them all (and try to address as much as possible in this upcoming version).
Many thanks!

do you have a timeframe in mind for when we can expect the update? that would be very helpful in deciding if we should wait to see that work vs use what is currently here. also, is that work being done publicly? i don't see it avail in the repo; but if possible, please do this in the open so we can follow along and offer proactive feedback on the new direction. in particular, with these sort of security related features, transparency is super helpful. thank you for all the work here.

Hi @simplycloud
We just pushed a new version. I'm adding a comment to all impacted contributions.
Many thanks.

Hi @simplycloud
We just pushed a new version. I'm adding a comment to all impacted contributions.
Many thanks.

Hi @hvital, was about to open a new issue with a few questions but found this thread...
We had implemented WAFs in our organization's accounts using the template provided in the docs to get started. There are a couple things we've done that I'm wondering if they'd be merged into this repo if I opened a PR:

Using pipenv to install the awscli and cfn-lint lint packages
Used cfn-lint on the Cloudformation templates
Added a Cloudformation Export so we could use Fn::ImportValue in our Cloudfront stacks
Added IPSets via the CLI for Whitelists and Blacklists, but it would be nice to pass this in as a parameter to the stack

Please let me know and I can open PRs in the next couple weeks.

Hi @jbabe
Thanks for your contact!!
We review all PR before pushing new updates. Actually, I'm currently working one and it might cover most of the already opened Issues/PR.
If you want to take a look at this new version before sending the PR, we can share a pre-beta version. Please open a Support Case referring this repo so I can get the ticket with your contact.
Regards,
Heitor

Hi @jbabe
Thanks for your contact!!
We review all PR before pushing new updates. Actually, I'm currently working one and it might cover most of the already opened Issues/PR.
If you want to take a look at this new version before sending the PR, we can share a pre-beta version. Please open a Support Case referring this repo so I can get the ticket with your contact.
Regards,
Heitor

Hi Heitor, I just opened a support case requesting access. Thanks Again! Jordan

hi @hvital, support has provided me with access. I haven't had a chance to test it out but will before opening any PRs here. Thanks!

Great. Thanks for all your help!


Clear fields and update lookup values - documentation unclear

Would be helpful if the sample showed how to clear different fields (e.g. lookups and date fields).
Additionally, the sample for creating a data object seems not to work for custom entities
Instead of:
var data =
{
<EMAIL_ADDRESS>"/contacts(61a0e5b9-88df-e311-b8e5-6c3be5a8b200)"
}
It would be:
var data =
{
<EMAIL_ADDRESS>"/LOOKUP_ENTITY_PLURAL(guid)"
}
Really would be helpful to have some of these examples.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: df263407-7cf0-b113-35f8-5a7c81c06a11
Version Independent ID: 8929ca5e-4354-be1d-6823-d894a0ef9b9d
Content: updateRecord (Client API reference) in Dynamics 365 Customer Engagement
Content Source: ce/developer/clientapi/reference/Xrm-WebApi/updateRecord.md
Service: crm-online
GitHub Login: @KumarVivek
Microsoft Alias: kvivek

I just tried in v<IP_ADDRESS>32
var data = { _[LookupFieldName]_value : null } is working for me.
var data =
{
"statecode": 1,
"_myprefix_mylookupfieldname_value": null
}
Xrm.WebApi.updateRecord("entityName", recordId, data);

I'm guessing you're using the unified interface? Doesn't work for me on 9.1.0000.4824

I'm guessing you're using the unified interface? Doesn't work for me on 9.1.0000.4824

Yes, I am in Hub. Current version is 9.1.0000.4824.
But I believe it should work in traditional one.
If this clear does not work, then you have to go with delete record.

Deleting the record isn't an option.


Run rollup

The compiled files were out of date

npm run prepublishOnly

I wonder if these files should be committed at all though


Is there a way to send a URL to the player via ADB?

Something similar to this but specifiying com.brouken.player too
adb shell am start -a android.intent.action.VIEW 'https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_adv_example_hevc/master.m3u8'
Thanks

Figured it out
adb shell am start -n com.brouken.player/.PlayerActivity -d 'https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_adv_example_hevc/master.m3u8'


Glitch when moving the camera

Hi, I'm using your lib, and it's really great, with a static camera, but when I need to move the camera to follow my character, a "glitch" occurs, it can be seen when I have many objects, it seems like each object can't move at same time, and sometimes they shake... have you seen it before?

It doesn't sound familiar. If you could try to reproduce it and attach a simple project that shows the issue I may be able to take a look at it.

I just added this code to camera, to move it, in your scene Main.unity, you will see the fallen tile moving weird
public class MoveCamera: MonoBehaviour { 	void Update () { 		float velocity = 0.2f 		Vector3 newPosition = new Vector3 (transform.position.x + velocity, transform.position.y, transform.position.z); 		transform.position = Vector3.Lerp (transform.position, newPosition, Time.deltaTime); 	} }

May your texture size does not match the screen size,
I have 32*32 tiles, and I set PixelCamera2D.BaseHeight = 384 (which is 12 * 32), and set the MainCamera.Size = 1.92 (the texture assets is 100 pixels per unit). It will move smoothly

i`m gonna try it, but why 1.92? and I tested and saw this problem in your project... you tried it?

MainCamera.Size = 1.92, this means the Camera.Height is 1.922 = 3.84 unit,
and all my textures are (100 pixels per unit),  so, the height is exactly 384 pixels,
and this can exactly contains 12 tiles in my project (which uses 3232 tiles).
You must calculate this value for your own project
notice:

check it when the game is running.
keep the  size bigger than you project screen size(otherwise, the pixel size will be changed), or you can enable  directly.

forgive my awful English o(╯□╰)o ..................


Debug output: encoding generator object 😅

Running a simple client using h2 with log level DEBUG:
DEBUG:hpack.hpack:Adding (b'foo', b'bar') to the header table
DEBUG:hpack.hpack:Encoding 2 with 7 bits
DEBUG:hpack.hpack:Encoding 3 with 7 bits
DEBUG:hpack.hpack:Encoded header block to b'\x83\x87A\x8a\xa0\xe4\x1d\x13\x9d\t\xb8 \xbe\xefD\x8ba\x96$/s\x10\xac\x0ccX_@\x82\x94\xe7\x83\x8cv\x7f'
DEBUG:hpack.hpack:HPACK encoding <generator object _check_path_header.<locals>.inner at 0x7fda203e94a0>

The last debug line looks odd.
I'm guessing that data is [probably] sent correctly on the line.
In that case it's only the hpack debug that's funky.
Code in question is here: https://github.com/python-hyper/hyper-h2/blob/13005074d14c7d32f8eaf1683b854446a09d09d3/h2/utilities.py#L490-L513

I faulty debug message is actually part of hpack itself - not h2:
https://github.com/python-hyper/hpack/blob/master/hpack/hpack.py#L233

Indeed. The API explicitly allows passing a generator. I wonder what's easier to wrap what h2 passed in a tuple(...) or ask hpack to update their debug...

Except now, if it's a generator, it's consumed in logging and never readers for header in headers...


[feature] Custom config; support custom currency, auto-select only exchange, auto-select all markets.

I too wanted EUR instead of USD as requested in issue #2. Here is a PR that:

adds -c, --config, to specify custom configuration. Change markets and currency symbol to use any currency supported by the exchange. If the configuration contains only one exchange, it is selected automatically.
adds -a, --all, to select all markets from the selected exchange.

With these two combined one can start Whale directly without having to always choose an exchange or markets.
To achieve this I have removed the require of the built-in config file everywhere but bin/cli.js, and instantiated Whale with only the selected exchange configuration, which is passed around to whoever needs it. This makes sense IMO, since one Whale instance can not (and should not?) switch exchanges at run time. Whale is now instantiated with everything it needs to function.
Cheers, and thanks for this lib.

Already merged ni #5


Switch to UEFI booting also in standard images

This would allow to unify the boot, make sure that non-volatile efivars and dmi information will eventually be available and will hopefully simplify things.
One blocker: We either need to add multi device-tree support to systemd-boot's UKI (Unified Kernel Image) stub, analogously to EFI Boot Guard (https://github.com/siemens/efibootguard/commit/d0c7afd0c2cf3b19adaac20a83bd4e87c172129b). Or we need to enhance isar recipes to generate a UKI from EFI Boot Guard while using a different boot loader (systemd) or booting directly a UKI. The first option appears nicer but requires upstream work.
@stormc

I think we should strive to eventually settle on one EFI Stub, wherever that is hosted. So, given systemd's ubiquity, it would make sense to approach "upstream", also lowering maintenance efforts in the EFI Boot Guard project. In addition, it should/would be in systemd's interest to support a broader range of use cases like this.
That said, there's the question of release / development speed to be discussed: For new / board-enabling scenarios -- assuming systemd would be the upstream of the EFI Stub -- and given that Distributions do not always ship the latest greatest version, a backport of systemd may have to be used to benefit from the latest enabling features. While intermittent, this may not be acceptable as getting other features / bugs as by-catch. Accounting for this, it would probably make sense to create a new upstream for the EFI Stub used by different projects or a stand-alone packaging of systemd's EFI Stub having decoupled release cycles...
Short-term and technically speaking, I guess it's faster to use EFI Boot Guard's EFI Stub while settling the topic with the systemd project for a long-term nicer solution.

The implementation of a stub extension in systemd-boot is only one aspect. First, we will have to get the new UKI spec extended: https://uapi-group.org/specifications/specs/unified_kernel_image. We will look into that soon.


Module aliases override updates

Use alias value defined upstream as a key downstream for overriding and chain them
Add pre-chained aliases to targets when needed and show diags
Resolves rdar://93445417, rdar://93218209

@swift-ci smoke test

@swift-ci  smoke test

@swift-ci smoke test


ForkingPickler(file, protocol).dump(obj) __there is a error

i wonder if you have this problem ?
OverflowError: cannot serialize a bytes object larger than 4 GiB
I do as you ask,and then ,find  it limit the size of  the object.
this problem is in reduction.py line 68, in dump.

ok，this problem have solved.

Excuse me, how did you solve this problem, I also met


Create separate gameserver

A dedicated server is introduced. Formerly, a host was both a server and (local) client. Now there is a clearer separation, which allows to run a dedicated central server which clients can connect to.
The distinction between DirectoryPath and FilePath has been removed. Now there is only a DataPath subsuming both.
DataPath now supports URLs, too. The content of a DataPath can be retrieved as a stream. XZ compression is supported for every kind of DataPath. Wherever possible we prefer DataPaths over plain filenames.
Our former home-grown Network action framework has been replaced by Unity RPCs. This saves us a TCP port, too. We no  longer have a dependency on NetworkCommsDotNet.
Even though the work in this branch is not yet complete, I would like to merge the changes so far as soon as possible into the master branch to avoid future conflicts. There are many changes in this branch effecting the graph providers.
Note to the reviewers: The Java code and docker scripts do not need to be reviewed for now. Only the C# code is relevant for the review.

@falko17 would you be able to review the changes in the C# code in this pull request? Just ignore the Java and docker code for now. This branch is intended to be continued by @tinxx who is currently working the Java code. I just want to get the C# changes into the master as soon as possible. Thanks.

@falko17 would you be able to review the changes in the C# code in this pull request? Just ignore the Java and docker code for now. This branch is intended to be continued by @tinxx who is currently working the Java code. I just want to get the C# changes into the master as soon as possible. Thanks.

Sure, I'll try to do a review today, or tomorrow at the latest if today doesn't work

@falko17 If you are happy with the implementation of your suggestion, please approve this PR.


call vimscript complete only when there are items in completion list

Hi @hrsh7th, in Completion._show function, vimscript complete function
is called every time even if there are no elements in items.
When items are empty, we get a Pattern not found error message. This is classic
with vim's completion mechanism. However, this can be so distracting for users
many times.
This pull request adds a condition around the complete function to be called only
when there are some elements in the items table.
This removes the Pattern not found error message significantly while typing.

Good catch.
But compe will use empty completion explicitly.
So I left a few comments.

Good catch.
But compe will use empty completion explicitly.
So I left a few comments.

LGTM!

LGTM!


[SPARK-41559][INFRA] Recover Codecov report in the scheduled job

What changes were proposed in this pull request?
This PR is a kind of a followup of https://github.com/apache/spark/pull/36940 which fixes a mistake of replacing inputs.type.
This PR changes it to use PYSPARK_CODECOV that's defined from https://github.com/apache/spark/blob/353df517f4d37aabbf807638385b0ab92dd95397/.github/workflows/build_coverage.yml#L39.
Similar approach is being used in https://github.com/apache/spark/blob/353df517f4d37aabbf807638385b0ab92dd95397/.github/workflows/build_ansi.yml#L39 with https://github.com/apache/spark/blob/919e556d182f86b3e1e22cd05a546e0f2fc3e307/.github/workflows/build_and_test.yml#L797
Why are the changes needed?
To recover the Codecov site. It stopped working for few months (https://app.codecov.io/gh/apache/spark).
Does this PR introduce any user-facing change?
No, dev-only.
How was this patch tested?
Will monitor the test cases. I am sure it works :-)

cc @Yikun mind taking a quick look please?

LGTM thanks!

Thanks guys.
Merged to master.


User gets a permisison denied error after submitted a pre-approved proposal

Needs further diagnosing;
A user reported that they got the infamous 'permission denied' page after submitting a pre-approved proposal. They did get a confirmation e-mail and the application was properly sent for review. So I'm guessing that something went wrong when redirecting to the 'proposal submitted' page.
Sadly they didn't provide the exact URL of the page they were sent to, so the above is pure speculation.
It's probably another 'we didn't test the pre-approved track' issue....

I was doing some testing surrounding this issue, and what I think happened was, the user pressed the back button on the submit page. This, i guess because the back button is also a submit button, just triggers start_review from the view's form_valid and updates the status to Proposal.Statuses.SUBMITTED. This actually also happens with regular proposals. This then raises this permission denied:
main/views.py, line 384:
        if proposal.status >= Proposal.Statuses.SUBMITTED:
            if self.request.user not in commission:
                raise PermissionDenied

So basically ... If you press either the '<< save and back', 'return to start of application' or 'submit application' buttons, the proposal always gets submitted. Not just for pre-approved proposals. Any idea on how to fix this? Maybe just make another exception for this in form_buttons.html?

No, that cannot be what happened. What you're describing is a bug that's currently only in develop. (And is fixed in #603)
If you look at the code in master (and thus running on the server), you'll see we protect against that happening:
https://github.com/DH-IT-Portal-Development/ethics/blob/master/proposals/views/proposal_views.py#L435

I'm closing this as not reproducible. I've tried a variety of things, and discovered a new issue along the way: #663
However, no success with this issue.
Might have been a freak mail sending accident, which could cause this error upon refresh (I think).


Running on iOS device is fine but Android shows some gradle error

Steps to Reproduce
Fully working project on one machine, clone to different machine and run on iOS working fine but running on Android device it fails and gives the error

Logs
Flutter crash report; please file at https://github.com/flutter/flutter/issues.
command
flutter run -d 00dc63d161c691c1
exception
String: Exit code 1 from: /Users/ankush/BitBucket/debut_assets/android/gradlew -v:
Error: Could not find or load main class org.gradle.wrapper.GradleWrapperMain
#0      runCheckedAsync (package:flutter_tools/src/base/process.dart:249)
<asynchronous suspension>
#1      _initializeGradle (package:flutter_tools/src/android/gradle.dart:179)
<asynchronous suspension>
#2      _ensureGradle (package:flutter_tools/src/android/gradle.dart:161)
<asynchronous suspension>
#3      _readGradleProject (package:flutter_tools/src/android/gradle.dart:96)
<asynchronous suspension>
#4      _gradleProject (package:flutter_tools/src/android/gradle.dart:89)
<asynchronous suspension>
#5      getGradleAppOut (package:flutter_tools/src/android/gradle.dart:83)
<asynchronous suspension>
#6      AndroidApk.fromCurrentDirectory (package:flutter_tools/src/application_package.dart:89)
<asynchronous suspension>
#7      getApplicationPackageForPlatform (package:flutter_tools/src/application_package.dart:306)
<asynchronous suspension>
#8      FlutterDevice.runHot (package:flutter_tools/src/resident_runner.dart:272)
<asynchronous suspension>
#9      HotRunner.run (package:flutter_tools/src/run_hot.dart:236)
<asynchronous suspension>
#10     RunCommand.runCommand (package:flutter_tools/src/commands/run.dart:395)
<asynchronous suspension>
#11     FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:344)
<asynchronous suspension>
#12     FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:279)
<asynchronous suspension>
#13     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:142)
<asynchronous suspension>
#14     _rootRun (dart:async/zone.dart:1126)
#15     _CustomZone.run (dart:async/zone.dart:1023)
#16     _runZoned (dart:async/zone.dart:1518)
#17     runZoned (dart:async/zone.dart:1465)
#18     AppContext.run (package:flutter_tools/src/base/context.dart:141)
<asynchronous suspension>
#19     FlutterCommand.run (package:flutter_tools/src/runner/flutter_command.dart:270)
#20     CommandRunner.runCommand (package:args/command_runner.dart:194)
<asynchronous suspension>
#21     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:314)
<asynchronous suspension>
#22     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:142)
<asynchronous suspension>
#23     _rootRun (dart:async/zone.dart:1126)
#24     _CustomZone.run (dart:async/zone.dart:1023)
#25     _runZoned (dart:async/zone.dart:1518)
#26     runZoned (dart:async/zone.dart:1465)
#27     AppContext.run (package:flutter_tools/src/base/context.dart:141)
<asynchronous suspension>
#28     FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:270)
<asynchronous suspension>
#29     CommandRunner.run.<anonymous closure> (package:args/command_runner.dart:109)
#30     new Future.sync (dart:async/future.dart:222)
#31     CommandRunner.run (package:args/command_runner.dart:109)
#32     FlutterCommandRunner.run (package:flutter_tools/src/runner/flutter_command_runner.dart:179)
#33     run.<anonymous closure> (package:flutter_tools/runner.dart:59)
<asynchronous suspension>
#34     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:142)
<asynchronous suspension>
#35     _rootRun (dart:async/zone.dart:1126)
#36     _CustomZone.run (dart:async/zone.dart:1023)
#37     _runZoned (dart:async/zone.dart:1518)
#38     runZoned (dart:async/zone.dart:1465)
#39     AppContext.run (package:flutter_tools/src/base/context.dart:141)
<asynchronous suspension>
#40     runInContext (package:flutter_tools/src/context_runner.dart:43)
<asynchronous suspension>
#41     run (package:flutter_tools/runner.dart:50)
#42     main (package:flutter_tools/executable.dart:49)
<asynchronous suspension>
#43     main (file:///Users/ankush/flutter/packages/flutter_tools/bin/flutter_tools.dart:8)
#44     _startIsolate.<anonymous closure> (dart:isolate-patch/dart:isolate/isolate_patch.dart:277)
#45     _RawReceivePortImpl._handleMessage (dart:isolate-patch/dart:isolate/isolate_patch.dart:165)

flutter doctor
[✓] Flutter (Channel dev, v0.5.2, on Mac OS X 10.13.3 17D47, locale en-IN)
    • Flutter version 0.5.2 at /Users/ankush/flutter
    • Framework revision 0a26ac0970 (6 days ago), 2018-06-06 15:28:20 -0700
    • Engine revision a83b37d35a
    • Dart version 2.0.0-dev.60.0.flutter-a5e41681e5

[✓] Android toolchain - develop for Android devices (Android SDK 28.0.0)
    • Android SDK at /Users/ankush/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b08)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 9.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 9.3, Build version 9E145
    • ios-deploy 1.9.2
    • CocoaPods version 1.5.2

[✓] Android Studio (version 3.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 22.2.1
    • Dart plugin version 171.4424
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b08)

[✓] Connected devices (3 available)
    • Nexus 5X     • 00dc63d161c691c1                         • android-arm64 • Android 8.1.0 (API 27)
    • Debut 6 Plus • f116f9636a5702885e7afcedafa2de2925eb1ca4 • ios           • iOS 11.3.1
    • iPhone X     • B062A68D-6897-4BE1-98D7-BC56ADA8092C     • ios           • iOS 11.3 (simulator)

• No issues found!

Do you still see that?

Closing as dup of #17280


Update CODING_MANIFEST.md

killed some typos

DO keep pull requests small so they can be easily reviewed.
DO make sure your contribution fits the openess and scaleability for future extensions
DO make sure unit tests pass.
DO make sure any public APIs are XML documented.
DO make sure not to introduce any compiler warnings.
AVOID making significant changes to the driver's overall architecture.
Delete the above section and the instructions in the sections below before submitting.
Type of request

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

Related Issue(s)

Concept

Description of the change

Description of current state
Description of target state
Estimated investment / approximate investment

Initiator
name / company / position / created at
Technical information
Platform / target area

DB Changes
Technical information
known side-effects
other
DB Changes (if so: incl. scripts with definitions and testdata)
How has this Tested?

Screenshots, Uploads, other documents (if appropriate):

Checklist:

[x] My code follows the code style of this project.

[x] I have read the CONTRIBUTING docs.
[ ] I have added/updated necessary documentation (if appropriate).

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

This is my first pull request. I hope I did it the right way.

for #2


rocksdb: 9.1.1 -> 9.2.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/facebook/rocksdb/releases.
meta.description for rocksdb is: A library that provides an embeddable, persistent key-value store for fast storage
meta.homepage for rocksdb is: https://rocksdb.org
meta.changelog for rocksdb is: https://github.com/facebook/rocksdb/raw/v9.2.1/HISTORY.md
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 9.2.1 with grep in /nix/store/s744qw6lxy79g04bgjq27fkdm9gj9i4a-rocksdb-9.2.1
found 9.2.1 in filename of file in /nix/store/s744qw6lxy79g04bgjq27fkdm9gj9i4a-rocksdb-9.2.1

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath

haskellPackages.rocksdb-haskell
haskellPackages.rocksdb-haskell-jprupp
haskellPackages.rocksdb-query
rocksdb

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/s744qw6lxy79g04bgjq27fkdm9gj9i4a-rocksdb-9.2.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rocksdb https://github.com/r-ryantm/nixpkgs/archive/24576e85fa38128bc139e13a16a60fd846399d07.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/24576e85fa38128bc139e13a16a60fd846399d07#rocksdb

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/s744qw6lxy79g04bgjq27fkdm9gj9i4a-rocksdb-9.2.1
ls -la /nix/store/s744qw6lxy79g04bgjq27fkdm9gj9i4a-rocksdb-9.2.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

2 packages built:

rocksdb
rocksdb.tools

Maintainer pings
cc @adevress @magenbluten for testing.

Result of nixpkgs-review pr 314159 run on x86_64-linux 1

8 packages built:

haskellPackages.rocksdb-haskell
haskellPackages.rocksdb-haskell-jprupp
haskellPackages.rocksdb-haskell-jprupp.doc
haskellPackages.rocksdb-haskell.doc
haskellPackages.rocksdb-query
haskellPackages.rocksdb-query.doc
rocksdb
rocksdb.tools

:pie:


Add keywords to index for searching

https://unicode.org/emoji/charts/emoji-list.html
This can also be used as the source for reference images since the one used there is from Google, same as was being scraped from full-emoji-list.html.

Fixed in e6dfffe.


Add themed scrollbars

Scroll bars, using dark theme, in particular, stands out from the rest of the theme.

Thanks @gMatas, found a way to make it work in both Chrome/Edge and Firefox, here are the results:

Plan to release this tonight, let me know if you have any further suggestions!

Just released it version 3.0.1 with the fix

Looks really nice! However, I've noticed that not all scroll bars were affected as seen here:

As for other similar suggestions, one that comes to mind is making dividers (white lines) not stand out as much from the rest of the theme as seen here


blockchain headers fail to download

I downloaded LBRY on my sister's MAC and it failed to download blockchain headers. When this happens, the wallet needs to sync from scratch which takes a long time.
The only other time this happened to me was on MAC vm, so I'm not sure if its specific to Mac or maybe some connection issues (but why can it download the blocks manually, but not the headers from S3?)
https://github.com/lbryio/lbryum/blob/d2a4f7492fc3413291b67e4d1cdec2dfcf058355/lbryum/blockchain.py#L156
Update: Had this happen on a Windows PC today at my other sister's house. The experience of having to sync from scratch is painful.

I suggest retrying at least once.
Also Today I enabled cloudfront for the the bucket used for the headers.
I'd suggest setting http://lbry-blockchain-headers.s3-accelerate.amazonaws.com/blockchain_headers_latest instead of https://s3.amazonaws.com/lbry-blockchain-headers/blockchain_headers_latest, falling back to this one if it fails and retrying both before giving up.

Jack's recent changes to the re-download of headers should fix this issue. It did on my Mac at least. It makes the connection to the server in a slightly different way.

@nikooo777 it looks like you turned on transfer acceleration, not cloudfront. how does that help us here? It looks like it only speeds up uploads. It doesn't affect download speed or reliability, which is what we actually want.
From https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html:

Why Use Amazon S3 Transfer Acceleration?
You might want to use Transfer Acceleration on a bucket for various reasons, including the following:

You have customers that upload to a centralized bucket from all over the world.
You transfer gigabytes to terabytes of data on a regular basis across continents.
You underutilize the available bandwidth over the Internet when uploading to Amazon S3.

For the record, I don't think cloudfront itself helps us much too. It's only intended for static assets, whereas our headers change every block.

I indeed got confused there. What I meant to do was use ClourFront.
Here is why: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/MigrateS3ToCloudFront.html
Using CloudFront can be more cost effective if your users access your objects frequently because, at higher usage,
the price for CloudFront data transfer is lower than the price for Amazon S3 data transfer.
In addition, downloads are faster with CloudFront than with Amazon S3 alone because your objects are stored closer to your users.

Perhaps it's worth trying?

Yep, let's close it!


[SPARK-12833][SQL] Initial import of spark-csv

CSV is the most common data format in the "small data" world. It is often the first format people want to try when they see Spark on a single node. Having to rely on a 3rd party component for this leads to poor user experience for new users. This PR merges the popular spark-csv data source package (https://github.com/databricks/spark-csv) with SparkSQL.
This is a first PR to bring the functionality to spark 2.0 master. We will complete items outlines in the design document (see JIRA attachment) in follow up pull requests.

This pull request is based on https://github.com/apache/spark/pull/10615 and simply fixed the scala style violations.

Test build #49446 has started for PR 10766 at commit ff22a2c.

Thanks for updating the license file.

Test build #49446 has finished for PR 10766 at commit ff22a2c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49446/
Test PASSed.

I'm going to merge this and create follow-up JIRAs to improve the csv reader.

@rxin Please let me know of the follow up JIRAs you file. I can work on some of them.

I will create more here https://issues.apache.org/jira/browse/SPARK-12420


Create checklist for event

The event details page should either:

link to the Google Docs spreadsheet being used as a checklist for the event, or
host the checklist itself.

In the former case, there should be a single-button way to create the required doc if it doesn't exist, and a single-button way to send the link to the event's instructors and hosts.  The latter design would have fewer moving parts, but would mean giving instructors and hosts access to the application.

Do any admins use the Google checklists? I haven't been lately.
If we do house checklists on AMY (which would be my preference for usability) we'd want to associate checklist items with particular admins, and (ideally) show the user a list of all their open checklist items in one place (rather than having them only visible on Event pages).
Too feature-creepy?

I don't think anyone's using the Google checklists...

Replaced with TODOS in #561.


Expected all tensors to be on the same device, but found at least two devices, cpu and cuda:0!

Notebook to reproduce
Please use GPU runtime and setup accelerate config
When I use a quantize models, it has this error:
Traceback (most recent call last):
File "/content/./lighteval/run_evals_accelerate.py", line 82, in
main(args)
File "/usr/local/lib/python3.10/dist-packages/lighteval/logging/hierarchical_logger.py", line 166, in wrapper
return fn(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/lighteval/main_accelerate.py", line 111, in main
evaluation_tracker = evaluate(
File "/usr/local/lib/python3.10/dist-packages/lighteval/evaluator.py", line 86, in evaluate
full_resps = lm.greedy_until(requests, override_bs=override_bs)
File "/usr/local/lib/python3.10/dist-packages/lighteval/models/base_model.py", line 594, in greedy_until
cur_reponses = self._generate(
File "/usr/local/lib/python3.10/dist-packages/lighteval/models/base_model.py", line 617, in _generate
outputs = self.model.generate(
File "/usr/local/lib/python3.10/dist-packages/torch/utils/_contextlib.py", line 115, in decorate_context
return func(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/transformers/generation/utils.py", line 1576, in generate
result = self._greedy_search(
File "/usr/local/lib/python3.10/dist-packages/transformers/generation/utils.py", line 2494, in _greedy_search
outputs = self(
File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
return forward_call(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/transformers/models/mistral/modeling_mistral.py", line 1158, in forward
outputs = self.model(
File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
return forward_call(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/transformers/models/mistral/modeling_mistral.py", line 987, in forward
inputs_embeds = self.embed_tokens(input_ids)
File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
return forward_call(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/sparse.py", line 163, in forward
return F.embedding(
File "/usr/local/lib/python3.10/dist-packages/torch/nn/functional.py", line 2237, in embedding
return torch.embedding(weight, input, padding_idx, scale_grad_by_freq, sparse)
RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cpu and cuda:0! (when checking argument for argument index in method wrapper_CUDA__index_select)
Traceback (most recent call last):
File "/usr/local/bin/accelerate", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.10/dist-packages/accelerate/commands/accelerate_cli.py", line 46, in main
args.func(args)
File "/usr/local/lib/python3.10/dist-packages/accelerate/commands/launch.py", line 1075, in launch_command
simple_launcher(args)
File "/usr/local/lib/python3.10/dist-packages/accelerate/commands/launch.py", line 681, in simple_launcher
raise subprocess.CalledProcessError(returncode=process.returncode, cmd=cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3', './lighteval/run_evals_accelerate.py', '--model_args', 'pretrained=TheBloke/Mistral-7B-Instruct-v0.2-GPTQ', '--tasks', 'leaderboard|gsm8k|0|0', '--override_batch_size', '1', '--output_dir=./evals/']' returned non-zero exit status 1.
Anything I did wrong?
Thanks for your help

I can resolve the issue for GPTQ model by adding .cuda() in
main_accelerate.py (77) after load_model()
with htrack_block("Model loading"):         with accelerator.main_process_first() if accelerator is not None else nullcontext():             model, model_info = load_model(config=model_config, env_config=env_config)             # for i in model.model.named_parameters():                 # print(f"{i[0]} -> {i[1].device}")             # import ipdb; from pprint import pprint as pp; ipdb.set_trace();             **model.model.cuda()**             evaluation_tracker.general_config_logger.log_model_info(model_info)
But I don't think its a proper way to resolve this issue,
If anyone can have a look why quantized model is stayed on CPU, not moved to GPU during load_model procedure
That will be very helpful
The models passed using above fix:
TechxGenus/Meta-Llama-3-8B-GPTQ
TheBloke/Mistral-7B-Instruct-v0.2-GPTQ
The models doesn't pass:
01-ai/Yi-6B-Chat-4bits

hi ! thanks for your interest in the lighteval and sorry for the delayed answer ! just to be sure, the model that does not pass usually does but does not work anymore when uadding your fix ?
For the reason, i would guess that GPTQ models are loaded differenlty and there is a bug where they are simply not loaded to GPU.
also, how many GPUs do you have available in your collab notebook ?

Hi NathanHB
Thanks for the reply,

NO, I don't have any problem with normal models, as the added code simply push model into GPU
I only have single GPU, and collab is single GPU(T4) setting

Hi @gody7334 ! I managed to reproduce this while working on a fix for #200, I'll investigate what's happening

Hi! This was just fixed on main! :)


Deploy Checklist: New Expensify 2023-05-09

Release Version: 1.3.12-0
Compare Changes: https://github.com/Expensify/App/compare/production...staging
This release contains changes from the following pull requests:

[ ] https://github.com/Expensify/App/pull/17400
[ ] https://github.com/Expensify/App/pull/17992
[ ] https://github.com/Expensify/App/pull/18143
[ ] https://github.com/Expensify/App/pull/18189
[ ] https://github.com/Expensify/App/pull/18251
[ ] https://github.com/Expensify/App/pull/18399
[ ] https://github.com/Expensify/App/pull/18406
[x] https://github.com/Expensify/App/pull/18467
[ ] https://github.com/Expensify/App/pull/18468
[ ] https://github.com/Expensify/App/pull/18484
[ ] https://github.com/Expensify/App/pull/18491
[x] https://github.com/Expensify/App/pull/18495
[ ] https://github.com/Expensify/App/pull/18520
[ ] https://github.com/Expensify/App/pull/18536
[ ] https://github.com/Expensify/App/pull/18568
[ ] https://github.com/Expensify/App/pull/18599
[x] https://github.com/Expensify/App/pull/18600
[ ] https://github.com/Expensify/App/pull/18611
[x] https://github.com/Expensify/App/pull/18619

Deploy Blockers:

[ ] https://github.com/Expensify/App/issues/18650
[ ] https://github.com/Expensify/App/issues/18682
[x] https://github.com/Expensify/App/issues/18696

Deployer verifications:

[ ] I checked the App Timing Dashboard and verified this release does not cause a noticeable performance regression.
[ ] I checked Firebase Crashlytics and verified that this release does not introduce any new crashes. More detailed instructions on this verification can be found here.
[ ] I checked GitHub Status and verified there is no reported incident with Actions.

cc @Expensify/applauseleads

:rocket: All staging deploys are complete, @Expensify/applauseleads please begin QA on version https://github.com/Expensify/App/releases/tag/1.3.12-0 :rocket:

Lots of very important context in slack:

https://expensify.slack.com/archives/C07J32337/p1683606295702069?thread_ts=1683598557.487459&cid=C07J32337
https://expensify.slack.com/archives/C9YU7BX5M/p1683607242187009
https://expensify.slack.com/archives/C9YU7BX5M/p1683607291217059

TL;DR 1.3.12-0 was already deployed to prod on web + desktop. The correct diff between our last intentional prod deploy and the current production branch (i.e: all the code in this checklist) is here: https://github.com/Expensify/App/compare/1.3.11-5...1.3.12-0

Checking off #18696 because we have a tight deadline to get some iteration of Manual Requests out the door as per https://github.com/Expensify/App/issues/18696#issuecomment-1541186892

@marcaaron we are almost done, getting summary in a few

@roryabraham @marcaaron
Regression is completed
PR https://github.com/Expensify/App/pull/17992 is failing with multiple issues https://github.com/Expensify/App/issues/18649, https://github.com/Expensify/App/issues/18647, https://github.com/Expensify/App/issues/18660, https://github.com/Expensify/App/issues/18659
PR https://github.com/Expensify/App/pull/18468 seem failing, https://github.com/Expensify/App/pull/18468#issuecomment-1541249987
PR https://github.com/Expensify/App/pull/18143 pass on all but Desktop. Can you double check the Desktop?

Ok so it seems like https://github.com/Expensify/App/issues/18650 was marked as not a deploy blocker so I'll check that off the list

Similar with https://github.com/Expensify/App/issues/18682, it looks like it is also reproducible in production so i'll check that off as well

@mvtglobally to be clear, is the issue with https://github.com/Expensify/App/pull/18468 the part where the form changes size slightly when data populates the fields? I don't see the labels shifting left like in the bug report (here) but maybe I'm missing something?

I didn't see https://github.com/Expensify/App/pull/18143 failing when I tested on Desktop, 1.3.11-5 - but @mvtglobally can you specify what exactly wasn't passing in the tests on that PR?

:clap: Heads up @Expensify/applauseleads :clap:
A new pull request has been :cherries: cherry-picked :cherries: to staging, and will be deployed to staging in version 1.3.12-1 :rocket:

@Beamanator sorry, I didn't mean to say it's failing on Desktop, we just didn't finish testing it on Desktop. It is pass checking off
PR #18468 more details here #18714

Aah that's great! Thanks @mvtglobally 👍 👍
I'm currently waiting for the latest iOS staging build & deploy, then I plan to ship this version 💪

:tada: All set?…You bet! @Expensify/applauseleads https://github.com/Expensify/App/releases/tag/1.3.12-1 has been deployed to staging :tada:

Alright here we go!

:shipit:

Checked off https://github.com/Expensify/App/pull/17992 and https://github.com/Expensify/App/pull/18468 so we could hopefully get the deploy out

:shipit:

This issue either has unchecked items or has not yet been marked with the :shipit: emoji of approval.
Reopening!

:shipit:


Where should I set a different $d$ for the Single Adapter?

Hi there, thanks a lot for your great work!
I am wondering where I can set a different $d$ for Single Adapter. In Table 11 of the paper, you listed several results from different $d$, but I didn't find this argument in the script file. Could you please tell me the right place?
Thanks again and looking forward to your reply ❤🔥

well, I think I found it, the corresponding argument is reduction_factor


Add support for changing default date/time parameter formatting

Note that I didn't push the generated template CS file because it replaces all paths in #line statements with my project location!

Thank you for the PR.

Note that I didn't push the generated template CS file because it replaces all paths in #line statements with my project location!

This is good, this way I can check all changes introduced by the PR...

Instead of checking invalidChars, we should use a regex to check if its a valid property literal, eg
Regex.Match("[a-zA-Z][a-zA-Z0-9_]*")

I think this one is fine:
https://stackoverflow.com/a/6671856/876814
^[a-zA-Z_$][0-9a-zA-Z_$]*$

Sorry, i posted the comments in the wrong PR :)


Update ERC-1363: ERC1363-updating grammar to be more simpler and understandable.

In the Abstract & motivation section, certain sentences are not properly constructed and can be harder to comprehend.
made slight changes to the grammar

I've already proposed an updated version of the EIP but it was rejected during the EIP -> ERC repo migration.
I've proposed it again, so please refer to #403 for my reviewed version.

I've already proposed an updated version of the EIP but it was rejected during the EIP -> ERC repo migration.
I've proposed it again, so please refer to #403 for my reviewed version.

ok i will do just that, thanks for the update

Dunno why the stale not didn't close this, but it certainly seems stale.


Submit/edit layout causes calendar to be off screen, preventing me from changing months.

Describe the bug

When attempting to edit my event and change it to the month of May instead of june, the calendar widget is cut off, preventing me from clicking the button to change to may.
To Reproduce

Open the website
Open the edit/submit page for an event
Click the calendar
Attempt to change the month

Expected behavior

I expected the calendar to drop downwards, allowing me access to all the buttons.
Screenshots

Desktop (please complete the following information):

OS: Windows 10
Browser: Edge Chromium
Version: Latest

Fixed by the native date picker


Worst idea ever of misusing comments inside source code to specify code paths

The only thing about TypeScript that I really, really do not like is misuse of comments to specify reference paths. I.e. ///
This is a very bad idea because:

Comments are meant for humans - not the compiler. Making some comments have an effect is surprising for the developer and against the very idea of comments. Yes, documentation tools often use formatted comments as well but here the effect is for documentation only so it is less of a problem.
Specific code paths should be specified outside the source files - not in the source files themselves.
Looks extremely ugly.
Looks like uncommented code so it is surprising for the casual non-expert developer.
etc.

FWIW you don't need to use them anymore : https://github.com/TypeStrong/atom-typescript/blob/master/docs/tsconfig.md
Also atom typescript tokenized these as "keyword" not comment. But you don't need to use them anyways 🌹

Feel free to continue discussion, but a) I don't see a proposed alternative and b) it's too late to remove the feature now.


Tracking issue: Delendum benchmarks project

Goal(s)

complete any work needed to run the benchmarks for the Delendum benchmarks comparisons

Details
Must have

[ ]

Nice to have

[ ]

Working group:
@Dominik1999 @itzmeanjan

Workflow

Discussion should happen here or in the related sub-issues.
PRs should only be merged by the coordinator, to ensure everyone is able to review.
Aim to complete reviews within 24 hours.
When a related sub-issue is opened:

add it to the list of sub-issues in this tracking issue

When opening a related PR:

request review from everyone in this working group

When a sub-issue is completed:

close the related issue with a comment that links to the PR where the work was completed

Coordinator: @Dominik1999

Workflow
The working group coordinator ensures scope & progress tracking are transparent and accurate. They will:

Merge approved PRs after all working group members have completed their reviews.

add the PR # to the relevant section of the current tracking PR.
close any completed sub-issue(s) with a comment that links to the PR where the work was completed

Monitor workflow items and complete anything that slips through the cracks.
Monitor scope to see if anything is untracked or unclear. Create missing sub-issues or initiate discussion as required.
Monitor progress to see if there's anything which isn't moving forward. Initiate discussion as required.
Identify PRs with especially significant changes and add @grjte and @bobbinth for review.

This is more relevant for the examples repo. So, I'll move it there.


Delete a few more unused imports in the old precog

Arg apparently test:compile didn't compile the world. I'm going to rebase this and try again.

Wow is this branch in a broken state locally. It's compiling. That is deeply annoying.


Update KSM

What this PR does / why we need it
Checklist

[ ] Update changelog in CHANGELOG.md.

Trigger e2e tests
/test create

Can you merge this @QuentinBisson ?


English suggestion on this line of the README

https://github.com/mugan86/ng-leaflet/blob/0b021b1ba77785aa3063ad8da48bd725eab23b31/README.md?plain=1#L33
If I were you I would change "Use references" to "References", I think is cleaner and clearer. 😊

I totally agree with what you say, Jesus, although this document is a draft. I will update and take that point into account, although I am considering not putting those sources and having them for myself and people that I think are appropriate, as would be your case. Thanks machine ;)

It will be our secret 🤫😁

👍  Thanks!

I add this info in next URL: https://github.com/mugan86/ng-leaflet/wiki/Interesting-References after remove from start README.md. Close issue, thanks Jesus!


Choice fields are not copied correctly (from on-prem to online)

See last comments in #253 for the details. Seems like choice fields are not handled correctly during publishing page transform from on-prem to online

Hi @KVSolutions, In my testing I can copy choice fields from on-prem to online and also from online to online without any issue. Tested with the September release. Can you cross check you have configured the fields correctly in your page layout mapping file?

hey @jansenbe , i was kinda able to reproduce this issue. This boils down to the field being present in the list but not in the content type. In this scenario, even though the mapping is correct, the field will not be copied over because we are checking the content type fields and not list fields here:
https://github.com/SharePoint/sp-dev-modernization/blob/4e46ce50b3352082cc8e12cb4d1d2e035cccfb4c/Tools/SharePoint.Modernization/SharePointPnP.Modernization.Framework/Cache/CacheManager.cs#L250-L259
Would suggest that instead of content type fields, we check the fields present in the list. Might be a minor performance hit, but will be more robust while migrating.
Thoughts ? Happy to submit a PR for the same, in fact already wrote some part of it, but wanted to run by you first :)

That makes sense, thanks for the additional research here @gautamdsheth . Yes, a PR would be really helpful, looking forward to it :-)

Thanks for the fix @gautamdsheth !
@KVSolutions: this should fix your issue. Fix will be part of the October release. I'll close this issue now, but if you still see issues when using the October release then please open a new issue.


Update jpyutil.py

Allow jvm_properties and jvm_options to be passed to the method write_config_files method in jpyutil.py.

I looked at the two errors above and they have nothing to do with my proposed change so I'm not sure how to correct them.


User feedback - solved / not solved

Get user feedback 'solved/not solved'
#96
Description
Added functionality for users to provide feedback back to GA. Whether a guide solved their problem or not
Checklist for Pull Requests

[x] Supplied as many details as possible on this change
[x] Included the link to the associated issue in the Issue section above
[x] The code conforms to the general development guidelines.
[ ] The code has unit tests where applicable and is easily unit-testable
[x] This branch is appropriately named for the associated issue

Thanks for the review @Klaus-Keller. All changes you suggested have been made. They also increased sonar coverage 🤣


[Proposal] Support define/override context assigns for slots

There are cases when we want to allow a value of a context assign to be set dynamically by the component defining the slot. For instance, the InputsFor component, which will be a wrapper around inputs_for, could work like this without any changes in the API:
defmodule InputsFor do
  use Surface.Component

  import Phoenix.HTML.Form
  alias Surface.Components.Form

  property form, :form

  property field, :atom

  slot default, props: [:form]

  context get form, from: Form, as: :context_form

  def render(assigns) do
    form = get_form(assigns)

    ~H"""
    <div :for={{ f <- inputs_for(form, @field) }}>
      <slot :props={{ form: f }}/>
    </div>
    """
  end
end

Usage:
<Form for={{ :data }}>
  <InputsFor field={{ :children }} :let={{ form: f }}>
    <TextInput form={{ f }} field="name" />
    <TextInput form={{ f }} field="email" />
  </InputsFor>
</Form>

It would be nice to have a way to override the value of the context's form assign with the value dynamically generated by InputsFor so we could achieve the same behaviour using contexts, writing only:
<Form for={{ :data }}>
  <InputsFor field={{ :children }}>
    <TextInput field="name" />
    <TextInput field="email" />
  </InputsFor>
</Form>

Proposal
Add a new context option for slot where we can declare which assigns will be overridden along with its configuration.
Example
The InputsFor would look something like:
defmodule InputsFor do
  use Surface.Component

  import Phoenix.HTML.Form
  alias Surface.Components.Form

  property form, :form

  property field, :atom

  # New option `context` in action
  slot default, props: [:form], context: [form: [to: Form]]

  context get form, from: Form, as: :context_form

  def render(assigns) do
    form = get_form(assigns)

    ~H"""
    <div :for={{ f <- inputs_for(form, @field) }}>
      <slot :props={{ form: f }} :context={{ form: f } }}/>
    </div>
    """
  end
end

The context: [form: [to: Form]] looks kind of ugly but I can't think of any other better way to do that. Suggestions are welcome.

Since InputsFor (listed in https://github.com/msaraiva/surface/issues/32) depends on this feature, I added it to milestone v0.1.0.

what would you think about something like:
  slot default, props: [form: [override_context: {Form, :form}]]

where each item in props is either an atom, or a key: value tuple that allows you to specify options for the slot prop? It would currently only accept a single option of override_context that has a value of the context variable that should be overridden.
it's a bit verbose. We could also use context_set instead of override_context.

@lnr0626 thanks for the suggestion.
One thing that concerns me about using :props for both cases is that we would have less flexibility. For instance, keeping them separated would allow us to add/override context assigns without necessarily creating :props vars. It also makes easier to add new options without forcing us to name them using some kind of prefix, e.g. context_ and prop_ to indicate that the option applies to the property or to the context. The idea behind having a separate keywod list like [to: Form] is that it could/should accept the same options as context set. Currently, it's just :to but it might be more as we improve contexts usage.

ohhh, I completely missed the :context={{ form: f } }} in your example, I thought it was automatically overriding context based on the prop of the same name. after seeing that, I also see where the to: comes from
yes, I agree that having them separate makes sense

I have a branch with a partially working version of InputsFor using the suggested approach. I'll rebase it and try to make it work with the new compiler.

After working for a while on this issue yesterday, I got the feeling that the :context directive solution might not be the best way to implement this. One thing that concerns me is that contexts are becoming too complex. Going in this direction would give two different ways to define/initialize context assigns, one using context set + init_context and another one using the :context directive. It's starting to get confusing and the implementation is reflecting that. I think maybe we should try to take a step back and rethink the whole context thing.
As an initial thought, what if we had a single generic way to set/get context assigns using a built-in component or macro. Something like this (using a new component <Context>):
defmodule Form do
  use Surface.Component

  @doc "Atom or changeset to inform the form data"
  property for, :any, required: true

  @doc "URL to where the form is submitted"
  property action, :string, default: "#"

  slot default, props: [:form]

  ...

  def render(assigns) do
    ~H"""
    {{ f = form_for(@for, @action, ...) }}
      <Context set={{ form: f }}>
        <slot/>
      </Context>
    <#Raw></form></#Raw>
    """
  end
end

defmodule Field do
  use Surface.Component

  @doc "The field name"
  property name, :string, required: true

  slot default, required: true

  ...

  def render(assigns) do
    ~H"""
    <div class=...>
      <Context set={{ field: @name }}>
        <slot/>
      </Context>
    </div>
    """
  end
end

defmodule TextInput do
  use Surface.Component

  @doc "An identifier for the form"
  property form, :form

  @doc "An identifier for the input"
  property field, :string

  ...

  def render(assigns) do
    ...

    ~H"""
    <Context get={{ Form, form: context_form }} get={{ Field, field: context_field }}>
      {{ text_input(@form || context_form, @field || context_field, ...) }}
    </Context>
    """
  end
end

defmodule InputsFor do
  use Surface.Component

  ...

  @doc "An identifier for the form"
  property form, :form

  @doc "An identifier for the input"
  property field, :string

  slot default, props: [:form]

  def render(assigns) do
    form = get_form(assigns)

    ~H"""
    <div :for={{ f <- inputs_for(form, @field) }}>
      <Context set={{ Form, form: f }}>
        <slot/>
      </Context>
    </div>
    """
  end
end

Some benefits of the proposed solution:

A single way to define contexts.
No need to declare context set nor context get.
No need to implement init_context.
No clash between context assigns and props. In fact, we don't have "context assigns" anymore. Anything from the context will be available as named variables, just like slot props. They will even be passed using the same mechanism. The difference is that all context variables will be automatically passed wrapped as something like __context_vars__, which should only be unwrapped using <Context get={{...}}>.
Variables are scoped, i.e. context vars will be only available inside a <Context>...</Context>
Simpler implementation. To be confirmed, for sure, but since we don't have to set the values as assigns anymore, I believe some of the complexity we have today will just disappear.

@lnr0626 WDYT?

At first glance I like this proposal - i definitely see how that could simplify the context handling, and like that it would support both the current use case for contexts as well as this new requirement.
WIth the get={{...}} and set={{...}} syntax, is the intention for the first element to be the module that variable is associated with and the second a key: value pair of either context var name -> binding name (similar to :let), or context var name -> value (similar to :props)? Would the module still make sense to be associated with the context var name? I'd expect so, but something to consider.
I've taken a look through where I've used context, and the one use case I have that I don't think fits super cleanly into this computed assigns. A few components I have take advantage of the ability to add assigns through context to compute some values from the properties. Using the named assign in the template is a bit clearer to me in some cases than calling a method with a few parameters, and I didn't want to create vars in the render function based on the recommendations in live view's docs. The init_context function also allows returning {:error, message} which is convenient. That being said, I think I could still accomplish the same thing with this new proposal, it would just bit a bit more syntactically involved.
I think this would simplify allowing context values to be overridden, but I'm unsure if it'll drastically simplify what we currently have. I do think it would isolate that complexity to within this Context component, which would still be a benefit, and it does also make the context scoping a bit clearer/more explicit.

A thought just occurred to me - what's the purpose for name spacing context vars with the module - i.e. {Form, :form} instead of just using the var name :form to identify it? I see the benefit of being explicit, but if we're talking about adding a capability to override context vars, another option could be to remove that module from the context var identifier. An equivalent solution would require an additional component, but should look something like this (with better naming needed):
defmodule InputsForContextUpdater do
  use Surface.Component

  property form, :form

  slot default

  context set form, :form, scope: :only_children

  def init_context(assigns) do
    {:ok, form: assigns.form}
  end

  def render(assigns) do
  ~H"""
  <slot />
  """
  end
end

defmodule InputsFor do
  use Surface.Component

  import Phoenix.HTML.Form

  property form, :form

  property field, :atom

  # New option `context` in action
  slot default, props: [:form], context: [form: [to: Form]]

  context get form, as: :context_form

  def render(assigns) do
    form = get_form(assigns)

    ~H"""
    <div :for={{ f <- inputs_for(form, @field) }}>
      <InputsForContextUpdater form={{ f }}>
        <slot :props={{ form: f }} />
      </InputsForContextUpdater>
    </div>
    """
  end
end

The difference here is context get no longer accepts from: <module>, and context set would no longer associate the variable with the module. This maintains a single way to define contexts, however wouldn't change the context get/set or init_context (though I don't dislike those as i like being able to scan the top of the module to see all of those things). We'd still have the assign name clash, and the scoping would be less configurable, but the variables are all already passed along via @__surface__.context. I think this might also simplify some of the current implementation, though wouldn't isolate that code.
If there's still a strong reason to keep that context var -> module association this solution wouldn't be ideal.
Thoughts?

Another similar option that would allow us to keep the context var -> module association is allowing users to set the module name in context set within the module itself. i.e.:
defmodule InputsForContextUpdater do
  use Surface.Component

  alias Surface.Components.Form

  property form, :form

  slot default

  context set form, {Form, :form}, scope: :only_children

  def init_context(assigns) do
    {:ok, form: assigns.form}
  end

  def render(assigns) do
  ~H"""
  <slot />
  """
  end
end

@lnr0626 I agree. I think we could just stop grouping the values per module. That would simplify things not only regarding implementation but the syntax as well. The initial idea was to avoid conflicts between components, however, I think the best approach is to give the user ways to rename the generated variable/assign instead of scoping grouping it per module. We could still handle conflicts by printing a warning when we find one. If the component's intention is to override the value, like in InputsFor, we can then add an option override: true to make it explicit and suppress the warning.
There are other changes we need to discuss due to the way change tracking works. Currently, the generated code for slots disables it. I'll give you more details soon. The good news is that there's a way to make it work nicely but it requires a change in the API, for instance, instead of using the passed props as variables, we'll need to use them as assigns.

I've been playing around with the <Context> component and I think the best approach is to represent the context as a map where the key could be either an atom (default) or a tuple (for scoped values) as suggested by @lnr0626.
Regarding the syntax, I believe we should keep a way to add options to individual assigns. If we restrict the input of set to a :map or :keywork we'll lose that ability.
One way to achieve that would be to allow multiple set and get attributes. For instance:
Setting values:
  <Context
    set={{ :foo, "some value" }}
    set={{ :form, form, into: __MODULE__ }}
    >
    ...
  </Context>

Retrieving values:
  <Context
    get={{ :foo }}
    get={{ :form, from: Form }}
    get={{ :field, from: Field, as: my_field }}
    get={{ :current_user, as: :user }}
>
    ...
  </Context>

Keeping a way to customize each assign will allow us to extend the API in the future. For instance, we could have something like:
  <Context set={{ :inputs, accumulate: true }}
    >
    ...
  </Context>

So instead of overriding the value when using set we could accumulate all values (similar to module attributes with accumulate: true).
I think we currently don't allow multiple attributes with the same name but I guess it would be not that hard to add this feature. Maybe we'll need to add an option property like property set, ..., multiple: true

I'm on board with this proposal and I like the idea of repeating set/get - i think it'll make it easier to see what's being used within a component, and agree with your point about allowing us to extend the api down the road.
As an alternative syntax for the :form, from: Form, we could also just expose the fact that it's a tuple to the user by having them specify {Form, :form} for get/set. your examples would then look like:
  <Context
    set={{ :foo, "some value" }}
    set={{ {__MODULE__, :form}, form }}
    >
    ...
  </Context>

and
  <Context
    get={{ :foo }}
    get={{ {Form, :form} }}
    get={{ {Field, :field}, as: my_field }}
    get={{ :current_user, as: :user }}
>
    ...
  </Context>

After typing those out, I'm not really a fan though - your suggestion of :atom, from:  module makes it a bit clearer which assign would be created, and feels a bit cleaner.

I think we currently don't allow multiple attributes with the same name but I guess it would not be that hard to add this feature. Maybe we'll need to add an option property like property set, ..., multiple: true

That seems reasonable, and wouldn't be a large lift at all. I would expect that a property with multiple: true would be exposed as a list(:prop_type) - i.e. property value, :map, multiple: true would show up in the component as a list(:map).
One thing to note that's more of an implementation detail, it would be convenient to be able to set and get a value on the same <Context>. i.e.:
<Context
  set={{ :value, some_complicated_calculation(...) }}
  get={{ :value }}
>
   <!-- something using @value a few times -->
</Context>

After typing those out, I'm not really a fan though - your suggestion of :atom, from: module makes it a bit clearer which assign would be created, and feels a bit cleaner.

Yeah, maybe it would be even more intuitive if instead of into/from, we had something like scope for both, set and get, for instance:
<Context set={{ :value, scope: Mod }}>
...
</Context>

<Context get={{ :value, scope: Mod }}>
...
</Context>

Not sure if scope is the best word though :)

I would expect that a property with multiple: true would be exposed as a list(:prop_type) - i.e. property value, :map, multiple: true would show up in the component as a list(:map).

Yup. That's what I have in mind. We could also use accumulate: true instead of multiple: true if you prefer.

it would be convenient to be able to set and get a value on the same

Totally agree! This is much more intuitive and powerful than the old API using:
context set foo, :string, scope: :self_and_children

I never felt comfortable with that thing. I think the new API is much more consistent and allow us to do much more in a better, more natural, intuitive way.

Yeah, maybe it would be even more intuitive if instead of into/from, we had something like scope for both, set and get, for instance
...
Not sure if scope is the best word though :)

I like the idea of having the same option name for set and get, I'll see if I can come up with some other suggestions beyond scope

We could also use accumulate: true instead of multiple: true if you prefer

Let's do that - that would be consistent with module attributes, so shouldn't be surprising to users

Resolved in #129


Unrecognized font family error

This error occurs for every bundle. Running React Native 0.14.1

ios or android?

Awesome @knot123, I'll try that tonight. Thanks!

That did it! Thanks.

Never mind, that didn't work. Still getting the same error after copying over the font file and adding it to the build phase.

@michaelwschultz: Did you add the folder as a group? Also did you edit your Info.plist?

Closing for inactivity. 99% sure this is because you didn't follow installations instructions properly.


docs(certificate-management-kit):icon format changed to SVG

Description
In this pull request, I have changed the format of icon's image in architecture view, software deployment view  of the Certificate management  kit from .PNG to .SVG.

Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review:

[X] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
[X] Copyright and license header are present on all affected files

@Unsharm, Kindly make changes to Adaption view, changelog and for operartion view pages as well. As these pages also containing broken svg image.

@SujitMBRDI okay, i am making the changes.

@Unsharm, Kindly make changes to Adaption view, changelog and for operartion view pages as well. As these pages also containing broken svg image.

@SujitMBRDI I have updated the icon image from previous image to the new one as requested, but I have already changed the format of the icon's image in adoption view, changelog, and operations view and these changes have already been merged. It should be work.

Hi @Unsharm,
are the .png versions of the images still in use somewhere? If so, consider replacing this usage by the .svg file as well an delete the .png files afterwards, if they are no longer used

Hi @Unsharm,
are the .png versions of the images still in use somewhere? If so, consider replacing this usage by the .svg file as well an delete the .png files afterwards, if they are no longer used

Hi @SebastianBezold,I have updated all the kits' icons from PNG TO SVG format. This changes will be implemented in the Next version. I will double-check to ensure no kits' icons are left in PNG format.

Hi @Unsharm,
are the .png versions of the images still in use somewhere? If so, consider replacing this usage by the .svg file as well an delete the .png files afterwards, if they are no longer used

Hi @SebastianBezold,I have updated all the kits' icons from PNG TO SVG format. This changes will be implemented in the Next version. I will double-check to ensure no kits' icons are left in PNG format.

Hi @Unsharm,
I'm not sure, if I understand you correctly. Will you remove the .png files? If so, I would prefer to have it in this PR and not an additional one

Hi @SebastianBezold
I wanted to inform you that i have created a separate folder named "kit-icons" where all images are now in SVG format. please note that i am not deleting any existing PNG images. This change will only apply to the next version.

Hi @Unsharm,
Ok understood. My point was, that you actually should delete the .png files if they are not used anymore. No need to keep them around in this case

Hi @Unsharm, Ok understood. My point was, that you actually should delete the .png files if they are not used anymore. No need to keep them around in this case

Hi @SebastianBezold Yes, we kept the .png files that are in use.

Hi @Unsharm, Ok understood. My point was, that you actually should delete the .png files if they are not used anymore. No need to keep them around in this case

Jup - that's our next step. Cleaning ..


Delete .bif files when movies are deleted

Is there an option to remove the .bif files generated by the plugin when removing movies from Jellyfin?

Not at the moment, though I'm not sure how Jellyfin treats stored metadata when media gets removed. It might already delete the .bif files if you don't have save to media folder enabled.

.bif files are stored alongside the metadata of a movie. When you delete a movie (or even replace it with the same title but of a better quality) and rescan your library, the whole folder is deleted.
So I'd say that everything works pretty flawlessly!


Decrease speed

My take at decreasing the speed. Might be too slow. For basis, we want the speedMultiplier to be 0.7 at ground and the speedTurnMultiplier to be 0.5 at ground. I can figure out better constants tomorrow

@derrell Agreed. I ended up doing the math out with @djwalker200 and we were able to get the speed to be 0.1 when the elevator is fully up and the desired previous multipliers when the elevator is at the bottom. I'll commit the changes later.

y = 0.5 - 0.0008x
y= 0.7 - 0.00012x
y=speed multiplier output
x= Math.abs(elevator Position)

@TechplexEngineer @ashwinc12 @jasonbishop11 if this is desired for Reading, this should be tested by tomorrow. I don't know if Ashwin and I will there for extended periods of time before 8:00 though, just a heads up.


CL Error when trying to read halted e2

Erroring opening file: generic

[wire] Erroring opening file: (generic)
    1. LoadFile - addons/wire/lua/wire/client/text_editor/wire_expression2_editor.lua:1909
        2. Open - addons/wire/lua/wire/client/text_editor/wire_expression2_editor.lua:1816
            3. func - addons/wire/lua/wire/stools/expression2.lua:800
                4. unknown - lua/includes/extensions/net.lua:33

To Reproduce

Spawn e2 chip with contents test
Open chip with rightclick using the e2 editor
Error happens

I used latest wire master to test this.

Not sure what the intended behavior is for this, I'm not sure if compile-errored chips store their code on them.


Installed xdebug with PHP 8.3.0

When support for PHP 8.3.0beta1 was added in #91, PHP 8.3 was excluded from the xdebug installation.
So we have made sure to install xdebug with PHP 8.3.0.

Awesome, xdebug supports 8.3 now?

Awesome, xdebug supports 8.3 now?

Yes, Supported in Xdebug 3.3.0.
https://xdebug.org/announcements/2023-11-30
https://xdebug.org/docs/compat


[Bug]:     SyntaxError: Unexpected token ':'        at Runtime.loadEsmModule (node_modules/jest-runtime/build/index.js:516:20)

Version
^29.7.0
Steps to reproduce
Can't share a repo because of confidential reasons.
Expected behavior
I expected that test will run.
Actual behavior
ReferenceError: You are trying to import a file after the Jest environment has been torn down. From test/api/agents/index.test.ts.
ReferenceError: You are trying to import a file after the Jest environment has been torn down. From test/api/agents/index.test.ts.
FAIL  test/api/agents/index.test.ts
● Test suite failed to run
SyntaxError: Unexpected token ':'

  at Runtime.loadEsmModule (node_modules/jest-runtime/build/index.js:516:20)

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total
Time:        1.668 s
Ran all test suites.
(node:6932) ExperimentalWarning: VM Modules is an experimental feature and might change at any time
(Use node --trace-warnings ... to show where the warning was created)
Additional context
import { NextApiResponse } from "next";
import { createMocks } from "node-mocks-http";
import { AppNextApiRequest } from "@app/types";
import { getAgents } from "@app/pages/api/agents";
import { respond } from "@app/utils/createa-api-handler";
import { expect, describe, it, jest } from "@jest/globals";

const session = {...}

describe("/api/agents", () => {
  it("should get the list of agents.", async () => {
    const { req, res } = createMocks<AppNextApiRequest, NextApiResponse>({
      session,
      method: "GET",
      headers: {
        "Content-Type": "application/json",
      },
    });
    await respond(getAgents)(req, res);

    expect(res._getStatusCode).toBe(200);
  }, 6000);
});

jest.config.ts

import type { Config } from "jest";
import nextJest from "next/jest";

const createJestConfig = nextJest({
  dir: "./",
});

const config: Config = {
  verbose: true,
  preset: "ts-jest",
  coverageProvider: "v8",
  testEnvironment: "node",
  moduleDirectories: ["node_modules", "<rootDir>"],
  testPathIgnorePatterns: ["/node_modules/", "/.next/", "/packages/"],
  fakeTimers: {
    enableGlobally: true,
  },
  transform: {
    "^.+\\.(ts|tsx)$": [
      "ts-jest",
      {
        useESM: true,
        isolatedModules: true,
      },
    ],
  },
  extensionsToTreatAsEsm: [".ts", ".tsx"],
  transformIgnorePatterns: ["/emailer/"],
  moduleNameMapper: {
    "^@app/(.*)$": "<rootDir>/$1",
  },
};

export default createJestConfig(config);

Environment
System:
    OS: Windows 10 10.0.19045
    CPU: (8) x64 Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
  Binaries:
    Node: 18.19.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 9.4.1 - C:\Program Files\nodejs\npm.CMD
    pnpm: 8.15.4 - ~\AppData\Roaming\npm\pnpm.CMD
  npmPackages:
    jest: ^29.7.0 => 29.7.0

@maxbisesi
I think you may added ; at the place of : but In my case I was getting error related to : in jest-runtime/build.
The same code I had run with Vitest it was working with Vitest. I don't know why it wasn't working with Jest.

@znarf
What could be way to avoid this error ?


Automated cherry pick of #6516: fix: system privileges user cannot access system console

Cherry pick of #6516 on release/3.0.
#6516: fix: system privileges user cannot access system console

Codecov Report

Merging #6523 into release/3.0 will increase coverage by 0.05%.
The diff coverage is 12.52%.

@@              Coverage Diff               @@
##           release/3.0   #6523      +/-   ##
==============================================
+ Coverage         6.85%   6.90%   +0.05%
==============================================
  Files              540     541       +1
  Lines            91509   91753     +244
==============================================
+ Hits              6270    6338      +68
- Misses           84719   84893     +174
- Partials           520     522       +2

Flag
Coverage Δ

#aFlag
6.90% <12.52%> (+0.05%)
:arrow_up:

Impacted Files
Coverage Δ

pkg/appsrv/workers.go
65.46% <ø> (-0.25%)
:arrow_down:

pkg/baremetal/manager.go
0.50% <0.00%> (-0.01%)
:arrow_down:

pkg/baremetal/tasks/base.go
13.59% <0.00%> (-0.41%)
:arrow_down:

pkg/cloudcommon/db/db_dispatcher.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/modelbase.go
1.44% <ø> (+0.02%)
:arrow_up:

pkg/cloudcommon/db/rbac.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/tenantcache.go
1.31% <0.00%> (ø)

pkg/cloudcommon/policy/policy.go
1.58% <0.00%> (+0.04%)
:arrow_up:

pkg/cloudprovider/cloudprovider.go
1.57% <0.00%> (ø)

pkg/compute/baremetal/diskconfig.go
60.14% <0.00%> (ø)

... and 49 more

Continue to review full report at Codecov.

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


Windows XR Plugin 2.6.x broke XRSDK eye gaze

Overview
It's not clear who/how I should file a but on the Windows XR Plugin package.  I realize it's not actually MRTK code, so feel free to triage this to the appropriate team (or over to Unity if they own this stuff).  Its all "Microsoft stuff" as far as I can tell...
The issue is that eye gaze has been regressed between Windows XR Plugin 2.5.2 and  Windows XR Plugin 2.6.0, and is still regressed in the latest version 2.6.1.
Specifically, in holographic remoting this use to return true, and now it returns false.
InputDevice.TryGetFeatureValue(WindowsMRUsages.EyeGazeAvailable, out var gazeAvailable)
As a side note, the api was always buggy and returned a Quaternion in the wrong coordinate system, however we were able to workaround for that by converting to a unity quaternion like so:
                    gazeRotation.Set(-gazeRotation.x, -gazeRotation.y, gazeRotation.z, gazeRotation.w);
                    gazeRotation = gazeRotation * Quaternion.Euler(0, 180, 0);

However, after upgrading to Windows XR Plugin 2.6.1, we can't even get the buggy eye gaze out of the XRSDK, so we're temporarily downgrading to 2.5.2 until you fix this bug.
Expected behavior
TryGetFeatureValue(WindowsMRUsages.EyeGazeAvailable...) returns true on holographic remoting with HoloLens 2.
the gaze rotation has the workaround above already applied before returning from TryGetFeatureValue(WindowsMRUsages.EyeGazeRotation...)
Actual behavior
TryGetFeatureValue(WindowsMRUsages.EyeGazeAvailable...) returns false on holographic remoting with HoloLens 2.
Steps to reproduce

Using latest Unity 2019.4 LTS, XR Plugin Management 4.0.1, and Windows XR Plugin 2.6.1

Gaze didn't work.

Downgraded to Windows XR Plugin 2.5.2, rebooted unity

Gaze work.

Upgraded to Windows XR Plugin 2.6.0, rebooted unity

Gaze doesn't work. (sanity check part 1)

Downgraded to Windows XR Plugin 2.5.2, rebooted unity

Gaze works again (sanity check part 2)

Unity editor version
2019.4.21f1

Update!
Unity has just merged fixes for:

Eye gaze position not in world space
Eye gaze rotation in wrong coordinate system
Eye gaze stopped working over remoting

I don't yet have an ETA on the next package drops, but these fixes are now in the pipeline.

Even on the older Windows XR plugin where we were getting eye gaze while remoting, it only ever seems to work the first time you run in the editor after starting unity.

I was unable to repro this issue when testing the above fixes. I'm not sure if something that changed with these fixes or has changed recently fixed things. I was also testing Unity 2021, so I wonder if this is something off with 2019.

Windows XR Plugin 2.7.0 has just shipped for Unity 2019.4.24+. Eye gaze should be working over remoting again and is now properly in an expected world coordinate system! Let me know if you run into any issues.


Quick Accent Hyphen options are broken

Microsoft PowerToys version
0.74.0
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
Quick Accent
Steps to reproduce

Place cursor in a text entry field (I used Word).
Press hyphen key followed quickly by the quick accent activation key (left/right arrow in my case)

✔ Expected Behavior
Quick accent should display a menu with a number of selectable hyphen related symbols such as en dash, em dash, minus sign, etc.

❌ Actual Behavior
Quick accent shows a broken menu of options with only two that can be selected. The other options are blank.

Other Software
No response

/dup #28785


build error

Hello! I've just installed this, but when building it, I get the following warnings:
warning: unexpected 'cfg' condition value: 'a11y'
 --> src/widget_copy/scrollable.rs:6:7
  |
6 | #[cfg(feature = "a11y")]
  |       ^^^^^^^^^^^^^^^^ help: remove the condition
  |
  = note: no expected values for 'feature'
  = help: consider adding 'a11y' as a feature in 'Cargo.toml'
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: '#[warn(unexpected_cfgs)]' on by default

warning: unexpected 'cfg' condition value: 'a11y'
  --> src/widget_copy/scrollable.rs:39:11
   |
39 |     #[cfg(feature = "a11y")]
   |           ^^^^^^^^^^^^^^^^ help: remove the condition
   |
   = note: no expected values for 'feature'
   = help: consider adding 'a11y' as a feature in 'Cargo.toml'
   = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
  --> src/widget_copy/scrollable.rs:41:11
   |
41 |     #[cfg(feature = "a11y")]
   |           ^^^^^^^^^^^^^^^^ help: remove the condition
   |
   = note: no expected values for 'feature'
   = help: consider adding 'a11y' as a feature in 'Cargo.toml'
   = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
  --> src/widget_copy/scrollable.rs:43:11
   |
43 |     #[cfg(feature = "a11y")]
   |           ^^^^^^^^^^^^^^^^ help: remove the condition
   |
   = note: no expected values for 'feature'
   = help: consider adding 'a11y' as a feature in 'Cargo.toml'
   = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
   --> src/widget_copy/scrollable.rs:115:11
    |
115 |     #[cfg(feature = "a11y")]
    |           ^^^^^^^^^^^^^^^^ help: remove the condition
    |
    = note: no expected values for 'feature'
    = help: consider adding 'a11y' as a feature in 'Cargo.toml'
    = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
   --> src/widget_copy/scrollable.rs:122:11
    |
122 |     #[cfg(feature = "a11y")]
    |           ^^^^^^^^^^^^^^^^ help: remove the condition
    |
    = note: no expected values for 'feature'
    = help: consider adding 'a11y' as a feature in 'Cargo.toml'
    = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
   --> src/widget_copy/scrollable.rs:131:11
    |
131 |     #[cfg(feature = "a11y")]
    |           ^^^^^^^^^^^^^^^^ help: remove the condition
    |
    = note: no expected values for 'feature'
    = help: consider adding 'a11y' as a feature in 'Cargo.toml'
    = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
   --> src/widget_copy/scrollable.rs:138:11
    |
138 |     #[cfg(feature = "a11y")]
    |           ^^^^^^^^^^^^^^^^ help: remove the condition
    |
    = note: no expected values for 'feature'
    = help: consider adding 'a11y' as a feature in 'Cargo.toml'
    = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
  --> src/widget_copy/scrollable.rs:63:19
   |
63 |             #[cfg(feature = "a11y")]
   |                   ^^^^^^^^^^^^^^^^ help: remove the condition
   |
   = note: no expected values for 'feature'
   = help: consider adding 'a11y' as a feature in 'Cargo.toml'
   = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
  --> src/widget_copy/scrollable.rs:65:19
   |
65 |             #[cfg(feature = "a11y")]
   |                   ^^^^^^^^^^^^^^^^ help: remove the condition
   |
   = note: no expected values for 'feature'
   = help: consider adding 'a11y' as a feature in 'Cargo.toml'
   = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
  --> src/widget_copy/scrollable.rs:67:19
   |
67 |             #[cfg(feature = "a11y")]
   |                   ^^^^^^^^^^^^^^^^ help: remove the condition
   |
   = note: no expected values for 'feature'
   = help: consider adding 'a11y' as a feature in 'Cargo.toml'
   = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'a11y'
   --> src/widget_copy/scrollable.rs:443:11
    |
443 |     #[cfg(feature = "a11y")]
    |           ^^^^^^^^^^^^^^^^ help: remove the condition
    |
    = note: no expected values for 'feature'
    = help: consider adding 'a11y' as a feature in 'Cargo.toml'
    = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: unexpected 'cfg' condition value: 'wayland'
   --> src/widget_copy/scrollable.rs:706:15
    |
706 |         #[cfg(feature = "wayland")]
    |               ^^^^^^^^^^^^^^^^^^^ help: remove the condition
    |
    = note: no expected values for 'feature'
    = help: consider adding 'wayland' as a feature in 'Cargo.toml'
    = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration

warning: 'cosmic-applet-emoji-selector' (bin "cosmic-applet-emoji-selector") generated 13 warnings
    Finished 'release' profile [optimized] target(s) in 9.47s

I was wondering if I can ignore this or if it'll impact my use of the app? Thanks! :)

These are just warnings, which will be fixed when the latest branch is merged into main, but the build is fine.