Asp.Net Example

Firstly, been watching this repo to see what 2.0 was going to bring and excited to see the possibilities!  Awesome work.
Second, I didn't see it in the list in the readme, but do you have an example for how this might be used in an ASP.Net 6 project.  This seems like a big chunk of what would need to happen to make it AoT compatible (plus the stuff that's coming in .Net 8).

@jwyza-pi thanks for your interest in this repo! :)
I tried not to add dependencies on any frameworks in v2 or change the concept in any way. But I tried to add enough extension points to make v2 as flexible as possible. To do this, you can change the behavior of the code generator using "Setup hints".
There are many uses for this code generator in ASP.NET. For example, you can use it to build individual compositions of objects. You can then register the corresponding "composition roots" in your Service Collection yourself. In this example, this is done automatically for all roots.
Here is example how to create a Service Provider.
All external dependencies (e.g. logger) can be added to the composition as arguments.
You can use OnCannotResolve hint
If you have a small example of a "template" ASP.NET application that is both simple and shows the essence of ASP.NET, please add it as a zip archive here and describe what you want to get.
I will add this example to this section.

I added sample Web API using Asp Net Core 7. Maybe it will help in some questions. In any case, please send your example. If we can't do anything with it right away, we will try to figure out how to do it well :)

Thanks, it might be a day or 2, but I'll get you an example scenario.

@jwyza-pi regarding AOT - this is an ambitious task in my opinion. Now ServiceCollection for web app contains about 300 registrations, some of which are realized by internal types. To create a composition all objects of these types must be able to be created in the composition class. And I have a feeling that you can try to make a fork of the ASP.NET project and type by type carefully build the composition directly in ASP.NET modules.

But ASP.NET is a lot of different modules and types can be embedded in different modules, which will add complications
Some modules may not satisfy AOT requirements and it may be problematic to finalize them to the necessary requirements.
Some types may be tied to Microsoft DI peculiarities.
And many other things may appear at the most inopportune time.


feat(input): add utilities for custom styling and monitoring state of input autofill

Demo: https://mmalerba-demo5.firebaseapp.com/input

@jelbourn moved everything into MatInputModule PTAL.

comments addressed


Add .try_for_each

Since Try isn't stable yet, this hard codes support to Result.
Unlike Iterator::try_for_each, I implemented this directly rather than
in terms of try_fold.  I left the comment there about try_fold for
when it is implemented.

Looks good! Thank you!


Improve interoperability of asInstanceOf with Set instances

Right now, there is no nice way to call asInstanceOf when a Set instance is expected.
Current solutions:
Object actual = Set.of("first", "second");

assertThat(actual)
  .asInstanceOf(InstanceOfAssertFactories.type(Set.class))
  .satisfies(set -> assertThat(set).containsExactly("first", "second")); // unchecked warning

assertThat(actual)
  .asInstanceOf(InstanceOfAssertFactories.COLLECTION) // no implicit `isInstanceOf(Set.class)`
  .containsExactly("first", "second"));

assertThat(map.get("value"))
  .asInstanceOf(new InstanceOfAssertFactory<>(Set.class, Assertions::<String> assertThat)) // verbose
  .containsExactly("first", "second");

By design, we didn't introduce any InstanceOfAssertFactory for types that don't have more specific assertions, i.e., there is no AbstractSetAssert today because it wouldn't have any added value compared to AbstractCollectionAssert.
We should investigate how to improve such use cases.
Triggered by: https://github.com/spring-projects/spring-framework/blob/2784f6008e97c7283b2e57e98d18a89fe8f530ae/spring-beans/src/test/java/org/springframework/beans/factory/config/YamlProcessorTests.java#L144-L153

This works quite nicely! 👍
See: https://github.com/spring-projects/spring-framework/commit/8feb842df5c55cb5c319cc7cea6af10394c0ce10

Nice! Thanks for the feedback!


chore(examples): bump wit-bindgen-wrpc version for provider-keyvalue-redis-auth

Feature or Problem
The example code was failing to build:
   Compiling wasmcloud-example-auth-kvredis v0.1.0 (.../examples/security/secrets/provider-keyvalue-redis-auth)
error[E0277]: the trait bound `WrpcClient: Serve` is not satisfied
  --> src/provider.rs:70:13
   |
70 |             bindings::serve,
   |             ^^^^^^^^^^^^^^^ the trait `Serve` is not implemented for `WrpcClient`
   |
note: required by a bound in `bindings::serve`
  --> src/provider.rs:19:5
   |
19 | /     wit_bindgen_wrpc::generate!({
20 | |         with: {
21 | |<EMAIL_ADDRESS>generate,
22 | |<EMAIL_ADDRESS>generate,
23 | |         }
24 | |     });
   | |______^ required by this bound in `serve`
   = note: this error originates in the macro `wit_bindgen_wrpc::generate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `WrpcClient: Serve` is not satisfied
  --> src/provider.rs:66:9
   |
66 |         serve_provider_exports(
   |         ^^^^^^^^^^^^^^^^^^^^^^ the trait `Serve` is not implemented for `WrpcClient`
   |
note: required by a bound in `bindings::serve`
  --> src/provider.rs:19:5
   |
19 | /     wit_bindgen_wrpc::generate!({
20 | |         with: {
21 | |<EMAIL_ADDRESS>generate,
22 | |<EMAIL_ADDRESS>generate,
23 | |         }
24 | |     });
   | |______^ required by this bound in `serve`
   = note: this error originates in the macro `wit_bindgen_wrpc::generate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `WrpcClient: Serve` is not satisfied
  --> src/provider.rs:66:9
   |
66 | /         serve_provider_exports(
67 | |             &connection.get_wrpc_client(connection.provider_key()),
68 | |             provider,
69 | |             shutdown,
70 | |             bindings::serve,
71 | |         )
   | |_________^ the trait `Serve` is not implemented for `WrpcClient`
   |
note: required by a bound in `bindings::serve`
  --> src/provider.rs:19:5
   |
19 | /     wit_bindgen_wrpc::generate!({
20 | |         with: {
21 | |<EMAIL_ADDRESS>generate,
22 | |<EMAIL_ADDRESS>generate,
23 | |         }
24 | |     });
   | |______^ required by this bound in `serve`
   = note: this error originates in the macro `wit_bindgen_wrpc::generate` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `WrpcClient: Serve` is not satisfied
  --> src/provider.rs:72:10
   |
72 |         .await
   |          ^^^^^ the trait `Serve` is not implemented for `WrpcClient`
   |
note: required by a bound in `bindings::serve`
  --> src/provider.rs:19:5
   |
19 | /     wit_bindgen_wrpc::generate!({
20 | |         with: {
21 | |<EMAIL_ADDRESS>generate,
22 | |<EMAIL_ADDRESS>generate,
23 | |         }
24 | |     });
   | |______^ required by this bound in `serve`
   = note: this error originates in the macro `wit_bindgen_wrpc::generate` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.
error: could not compile `wasmcloud-example-auth-kvredis` (bin "wasmcloud-example-auth-kvredis") due to 4 previous errors

Related Issues

Release Information

Consumer Impact

Testing

Unit Test(s)

Acceptance or Integration

Manual Verification

@joonas what do you think about covering this example under CI tests similarly to the other ones? Even if we're just checking the build here, would be great if we were forced to fix this quicker

@joonas what do you think about covering this example under CI tests similarly to the other ones? Even if we're just checking the build here, would be great if we were forced to fix this quicker

that seems fine, I can take a look at doing that before merging this in


Add static mirror request monitoring from Grafana

The static mirror dashboard was created manually using the Grafana UI. This PR replicates the dashboard to terraform.
Trello: https://trello.com/c/xrq1YM3B/3359-add-grafana-dashboard-for-monitoring-requests-to-the-mirror-to-govuk-helm-charts-2

Thanks for adding this.
A few little things to improve:

Don't forget the units! I can't be sure what the numbers mean on these graphs. I'm guessing requests per second?
The dashboard doesn't fit on either of my screens (14in hidpi laptop or 1920x1200 16:10) without vertical scrolling, even though there are only three graphs. I'd suggest making the graphs less tall (like on most of our other dashboards) so that they can be seen at a glance.
It would be helpful to call the second graph "requests by HTTP method" rather than just "requests" (since all the graphs show requests).
You can just say "errors" rather than "error requests" (it's also clearer that way).


Shell tests: passing an array

def dotest(k, x, exp)
    test1 = (run_shell args: [k, x])
    expect(test1).to eq(exp)
end

dotest(4, [10175, 10185, 10180, 10197], 3)

Only the 1st element of the array is passed to bash.

I don't think Shell can accept array like that.
Your setup sets the arguments ["4", "[10175, 10185, 10180, 10197]"]:
echo $@
# 4 [10175, 10185, 10180, 10197]
echo $#
# 2

Try
dotest("4", "10175 10185 10180 10197", "3")
# or
dotest("4", [10175, 10185, 10180, 10197].join(' '), "3")

Then
echo $@
# 4 10175 10185 10180 10197
# this is hard to see, but $1="4" and $2="10175 10185 10180 10197"
echo $#
# 2

The solution can use them like this:
n=$1
xs=($2)
echo "$n"
# 4
echo "${xs[@]}"
# 10175 10185 10180 10197

@kazk: I am very sorry to bother you! This is what I have as a try at CW:
fake() {
    echo "All args : $@"
    d=$1
    echo "First arg : $d"
    echo "2nd arg : /$2/"
    xs=( $2 )
    echo "Array : ${xs[@]}"
    arraylength=${#xs[@]}
    echo "Array length : $arraylength"
    for (( i=0; i < ${arraylength}; i++ ));
    do
      echo "$i : ${xs[$i]}"
    done
    echo "elt of endex 1 : ${xs[1]}"
}
fake $1 $2
###########
def dotest(k, x, exp)
    test1 = (run_shell args: [k, x])
    expect(test1).to eq(exp)
end
describe("consec_kprimes") do
    it("Basic tests") do
        dotest("4", "10175 10185 10180 10197", "3")
    end
end

When I run the test I get:
Shell Output
All args : 4 10175 10185 10180 10197
First arg : 4
2nd arg : /10175/
Array : 10175
Array length : 1
0 : 10175
elt of endex 1 :

"All args" seems correct but "2nd arg" is only the first element of the string passed by Ruby.
The second element of the string will be "$3" for Bash and so on. I must make a mistake somewhere but I don't see it:-(

Closing because this seems to be working as designed. Bash input can only accept strings, when calling run_shell args: [...] is just going to result in this happening args.map(&:to_s) when sending the input.

@g964 that's because you're giving fake 5 numbers:
# fake $1 $2 becomes
fake 4 10175 10185 10180 10197

Try echo $# inside fake, it should output 5.
Do fake $1 "$2" (note the " around $2) instead and you should see:
All args : 4 10175 10185 10180 10197
First arg : 4
2nd arg : /10175 10185 10180 10197/
Array : 10175 10185 10180 10197
Array length : 4
0 : 10175
1 : 10185
2 : 10180
3 : 10197
elt of endex 1 : 10185

@kazk : thanks, now it works!


Allow escaped single quotes in RawParams

If, for instance, your FPGA tools (COUGH iCEcube2 COUGH) happens to be inexplicably sensitive to the particular formatting of parameters, so you couldn't just plop down an IntParam and call it a day, but needed 6'b0110_01. Or if you just wanted to pass through binary parameters from Chisel through FIRRTL without needing to convert them to hex or decimal, since Scala doesn't support binary literals.
The escaping framework isn't completely general (and I don't know if this is the right way), though it seems to be no worse than how \" is handled. (I know, really low bar, suggestions on how to improve are welcome though)
FIRRTL part of the fix for freechipsproject/chisel3#830

Added re-escape in serialize. Derrrrrp. Fixed, with tests.


Introduce sync for non-pyfilesystem locations

Observer should have a sync(directory, target, frequency) method that enables automatic syncing of local file directory to the non-local pyfilesystem under 'storage/$target' of the observer storage. This is useful if you want to sync custom things like tf checkpoints etc to the storage. When the method is called multiple times multiple syncs are setup. If the filesystem is already local, nothing should be done.  We can automatically sync in regular frequency using the heartbeat event, self.events.on('heartbeat', syncer.sync_if_needed)
Ray has sync features that we could potentially reuse.

I believe this is out of scope, as it can be handled by 3rd party tools


Implement Logging for Django Application

Implement a logging system within the Django application to capture and store relevant application events, errors, and debugging information. This logging system will enhance the application's monitoring and troubleshooting capabilities.

Hello @hossainchisty ,
Thanks for your interest in this issue! Your contribution is welcome. Feel free to fork the repo, create a branch, and start working. :-)


Request for an e-mail address

Hello,  I have been reading your papers TTS-GAN and TTS-CGAN recently, and I am very interested in your research. I am trying to run your codes, but I have encountered some small problems and would like to ask you. I tried to send an e-mail to you, but it always fails, so may I have your new e-mail address? It couldn't be better if it is an adress in China, Thank you.

Hi, thanks for being interested in my work. My school email is<EMAIL_ADDRESS>(The third character is lowercase 'L' not digit number 1). And you can try my Gmail account<EMAIL_ADDRESS>


bugs when compile

: warning: expression has no effect

thirdparty/eigen/Eigen/src/Core/Product.h(145): catastrophic error: error while writing generated C file: No space left on device

1 catastrophic error detected in the compilation of "thirdparty/lietorch/lietorch/src/lietorch_gpu.cu".
Compilation terminated.
ninja: build stopped: subcommand failed.
Traceback (most recent call last):
  File "python3.8/site-packages/torch/utils/cpp_extension.py", line 1666, in _run_ninja_build
    subprocess.run(
  File "python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['ninja', '-v']' returned non-zero exit status 1.

The above exception was the direct cause of the following exception:

Hi,
I have encountered the same problem. Have you solved it?

Hi, I have encountered the same problem. Have you solved it?

not yet.


data: num_points

Dear Author,
data: num_points in config.yaml means the maximum number that the network can take as input? or gt?

Hi! During training num_points refers to both the input and the ground truth. We random sample num_points from the ground truth map and add noise to it for the network to learn to denoise it.

Hi, Thank you for the reply. How do you match the input scan (P in the supplementary material Figure 1) and ground truth (gt in Figure 1) if num_points are randomly sampled?

We condition the noise prediction of each noisy point from the ground truth to the closest point in the conditioning point cloud. The match is done by the distance, and we just consider the closest one for the conditioning.

So does that mean, in the training phase, scans from Kitti-semantic are not used, but inputs and their gts are sampled from clean_map.npy generated from map_from_scan.py?

Hi! The kitti scans are used as the conditioning P (in Figure 1 from the supplement) and Gt is the ground truth from map_from_scan.py with added noise.


Update project (fix/improve travis, improve PhpUnit and add CS-Fixer)

I improved the unit tests for it to be done on different versions of php and more coverage.
I also added PHP-CS-Fixer to ckeck the coding style and I executed it.
I also added a new instance MailChimpException
I'm waiting for your comments, because I have other PR to submit that depends on it
Maxime

The readme states:

If you'd like to suggest an improvement, please raise an issue to discuss it before making your pull request.

Did we discuss these changes, because I don't recall doing so. What's the rationale for these proposed changes?

You're welcome 😉
There is no issue for these changes, I decided myself to do a little update to fix travis and increase tests with new assertions and PHP-CS-Fixer.
And improving an open-source project that I like is a good reason, no?

Not when it's to try to steer it to your own preference and not consider the impact on others. What was the reason for cutting off PHP 5.3 users with your changes?

And it's still possible for them to use the tag associate with the compatible version to continue using it

I'd fully agree that people should use newer PHP. Of course. But this is just a tiny library that is used as a dependancy for dozens of other libraries, WordPress and other CMS and framework plugins. I could be easily convinced to raise the minimum PHP requirement for a solid technical reason that enabled us to improve what the library does, but if we don't have a reason make this break on PHP 5.3 installations then we shouldn't.
I'm open to switching from Travis to something better if that makes sense. That should be one PR.
I'm open to introducing custom exceptions if we can do so without making non-composer installs impractical. That should be another PR.
I'm very much in favour of improving tests where we can. That should be another PR.
I'm not interested in raising the minimum requirements unless we have a solid technical reason.
Making all these changes in one PR, without discussing them first is just not good practice. I can't selectively accept parts of it so I'm going to have to sadly reject the entire thing. If you'd like to contribute, I'd very much welcome it and thank you for your effort, but it needs to be done properly.

Alright I understand. I'm going to take care of split all that then in several points


Hide elements in an accessible fashion

A lot of icons (like the menu, the preview, and so on) are hidden and shown based on what the user clicks on. However, this is not reflected to screen reader users.
Here are two things that can be done:

Set the display attribute to none in CSS to hide elements, or
Set the aria-hidden attribute on HTML elements that are hidden to true.

I would really appreciate it if you could pick the easier solution and fix it, as StackEdit is almost 100% accessible to me as a screen reader user, and that's a huge deal.
Thanks.

Hi, can you try with the v5 and open a new bug if it's not fixed?


Remove default ecosystem from sdk and docs

There's a conflict of interests.

Codecov Report
Base: 16.72% // Head: 11.04% // Decreases project coverage by -5.68% :warning:

Coverage data is based on head (886b59b) compared to base (7b6b72d).
Patch has no changes to coverable lines.

:exclamation: Current head 886b59b differs from pull request most recent head 694aa54. Consider uploading reports for the commit 694aa54 to get more accurate results

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #1192      +/-   ##
============================================
- Coverage     16.72%   11.04%   -5.69%
============================================
  Files           314       32     -282
  Lines         48420     6373   -42047
  Branches       5019        0    -5019
============================================
- Hits           8100      704    -7396
+ Misses        39538     5669   -33869
+ Partials        782        0     -782

Impacted Files
Coverage Δ

dart/lib/src/account_service.dart
54.28% <ø> (-1.27%)
:arrow_down:

.../lib/src/proto/services/account/v1/account.pb.dart
13.66% <0.00%> (-0.57%)
:arrow_down:

dotnet/Trinsic/ServiceBase.cs

go/services/account_service.go

...src/main/java/trinsic/services/AccountService.java

python/samples/account_demo.py

python/trinsic/account_service.py

...insic/services/account/v1/LoginConfirmRequest.java

...rvices/provider/v1/PublicEcosystemInformation.java

...templates/v1/CreateCredentialTemplateResponse.java

... and 274 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


feat/operator sdk 1.25

Upgrades operator-sdk all the way up to 1.25 from 1.15.
NOTE: I discovered a bug introduced by a previous PR that I will address in a different PR (see #226).
/kind feature
/priority important-soon
/assign

/approve


Update sql-server-linux-availability-group-configure-rs.md

For Read-Scale Secondaries there is nothing called FAILOVER_MODE=NONE this can have values of AUTOMATIC , MANUAL , EXTERNAL. Please consult with AG Engineering team before making the changes. i found this typo hence raising this change request.

Thank you @pradm - #sign-off


FancyZones not working at all

Microsoft PowerToys version
0.58.0
Running as admin

[X] Yes

Area(s) with issue?
FancyZones
Steps to reproduce
Tried restarting PowerToys, disabling/re-enabling FancyZones, applying different FZ layouts, and restarting PT as Admin - none of it works; FZ remains unusable. (Note: Issue just started today, even though FZ in this version of PT has been working since release.)
PowerToysReport_2022-05-26-08-16-50.zip
✔ Expected Behavior
Windows snap to zones using keyboard shortcuts (Win+Left or Win+Right) or Shift+drag window to a zone
❌ Actual Behavior
Using keyboard shortcuts, windows snap to default Windows zones (not FZ zones); Shift+drag window (or regular drag window) has no effect
Other Software
No response

Update - after thinking through the issue again, I realized I had not started with a clean boot. Issue began when I woke laptop from sleep and connected external display. A reboot fixed the issue and FZ is now working. However, I have never had any issues moving between these configurations before.


Consider using new fetch API in browsers instead of XHR

https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
There are polyfills out there for browsers and Node (but they are third-party dependencies). The main advantage is that fetch is Promise-based, which fits with TypeScript and our Promise-based API better. This would allow us to remove some of our manual callback-based code.
This wouldn't affect public API though, so it can happen after preview 1.

Given that we'd need a polyfill, I say "meh".


Update samples for VS 17.9 GA

Does this mean that the publishing ban has now been lifted, and we can start using the SDK as long as we require VS 17.9 or later from all consumers?

Does this mean that the publishing ban has now been lifted, and we can start using the SDK as long as we require VS 17.9 or later from all consumers?

Yes, starting when VS 17.9 is released.


Remove NetRC dependency as the repo's are public

As the repo's are public now, There is no need of credentials to be used for connecitng to the github api, during go mod download.
@grampelberg
Signed-off-by: Tarun Pothulapati<EMAIL_ADDRESS>

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


Increase x-height of inline code

In this Tufte sample handout PDF, the inline monospace font has the same x-height as its surrounding serif text. So, I’m increasing the code font size from 16px to 18px, which looks right to me.

I’m optimizing for Consolas (18px). But it looks good in Menlo as well—albeit a tad too tall—17px looks best with Menlo (but is too small for Consolas). I don't have “Liberation Mono” for testing. Looks good on both Retina and non-Retina displays.

I think I'm comfortable with the height of inline code spans at the moment. In fact, I don't see any difference between the current repo and your branch when it comes to that issue?

I think this size looks a lot better. What do you mean you don't see a difference? If you click on the "Files changed" tab you should see I increased the the code font size from 1rem to 1.125rem.
I rebased against master to make this branch merge-able. Maybe that was preventing the issue from coming through. Try again?

You're right, I was in the wrong branch. Checking now.


2 bugs : duplicated items + shared folders that disappeared from 'sharing area'

steps:
register user1 , (register user2, user3), login, create folders structure, share all folders to user2, via user1 upload file to folder and share this folder to user3.
In this point - in user3 signing/share areas appear duplicated items (may be because there was sharing of folder, but not file)

Also, all sharing folders for user2 are dissapeared in it's 'sharing area'
After, new sharing and new voting - any of this ^ two bugs don't appeared.
Also, any error messages in docker logs (backend, chaincode, peer) - not appeared

send to fabric  updateVoting 1
2022-05-02T12:04:56.430Z - warn: [TransactionEventHandler]: _strategyFail: strategy fail for transaction "400ca84ee8775b167afe4ee5cbb46f0c52ffbbfbab93c90e02fd380d22ae16d9": TransactionError: Peer <IP_ADDRESS>:7051 has rejected transaction "400ca84ee8775b167afe4ee5cbb46f0c52ffbbfbab93c90e02fd380d22ae16d9" with code "MVCC_READ_CONFLICT"
    at TransactionEventHandler._onEvent (/app/node_modules/fabric-network/lib/impl/event/transactioneventhandler.js:114:23)
    at EventRegistration._onEventFn (/app/node_modules/fabric-network/lib/impl/event/transactioneventhandler.js:88:26)
    at EventRegistration.onEvent (/app/node_modules/fabric-network/node_modules/fabric-client/lib/ChannelEventHub.js:1788:9)
    at Proxy._callTransactionListener (/app/node_modules/fabric-network/node_modules/fabric-client/lib/ChannelEventHub.js:1480:13)
    at Proxy._checkTransactionId (/app/node_modules/fabric-network/node_modules/fabric-client/lib/ChannelEventHub.js:1464:9)
    at Proxy._processTxEvents (/app/node_modules/fabric-network/node_modules/fabric-client/lib/ChannelEventHub.js:1443:11)
    at ClientDuplexStream.<anonymous> (/app/node_modules/fabric-network/node_modules/fabric-client/lib/ChannelEventHub.js:521:11)
    at ClientDuplexStream.emit (events.js:210:5)
    at ClientDuplexStream.EventEmitter.emit (domain.js:475:20)
    at addChunk (_stream_readable.js:309:12) {
  transactionId: '400ca84ee8775b167afe4ee5cbb46f0c52ffbbfbab93c90e02fd380d22ae16d9',
  transactionCode: 'MVCC_READ_CONFLICT',
  name: 'TransactionError'
}
send to fabric  updateVoting 2
send to fabric  updateVoting 1
send to fabric  getFolder 1


mwc-select: Transparent and non-clickable over sticky element

I think I found a bug, when the select menu is inside a sticky element appears over other element with position: sticky; style.
Context: In the page I was trying to make, I have a select and after it there is this purple-border div:

Expected behaviour: When the div has display: block;, it behaves normally:

**Actual behaviour: ** But when I make it sticky, I cannot click the options that are over it:

Details
A simplified version of the code that generates the problem is this:

  <mwc-select outlined label="Arrow style">
    <mwc-list-item value = "arrow"   > Arrows    </mwc-list-item>
    <mwc-list-item value = "triangle"> Triangles </mwc-list-item>
    <mwc-list-item value = "tag"     > Tags      </mwc-list-item>
  </mwc-select>

  text, text,
 text text, text,
 text

.first-div {
  position: -webkit-sticky;
  position: sticky;
  left: 0;
}
.purple-border-div {
  position: -webkit-sticky;
  position: sticky;
  left: 0;
  border: solid #6200EE;
}

I've tested this in Firefox and Opera on Windows 10. I'm using Node.js (v14.16.1) to serve the files.
(The purple border has nothing to do with the problem)

This is a known limitation that we've yet to fix. The typical workaround is to add <mwc-select fixedMenuPosition> does this work in this situation?
Just created a tracking issue: #2577

No, it does not work.
The result is the same, but the menu is thiner.

The root issue #2577 still seems to be the root of the issue.
In the meantime, is it possible to set the z-index of the sticky select above the purple div like so?

Yes, using z-index works fine for me.
Thanks for the workaround, and for the explanation (at root issue).

Surfaced this to the team, for this specific issue, the solution would be to set z-index


Dealloc crash with AFNetworking (With example)

https://github.com/RyanCopley/Realm-AFNetworking-Crash
I'm not sure if this is a problem with how I'm doing things, Realm, or AFNetworking, but I have a proof of concept of the crash. When the Foo object deallocates due to a failed request, it is on a "different" thread. AFNetworking is setting the block to nil. The block is never called (to my knowledge, no breakpoints would catch).
I'm probably doing something naive, but this is very odd. I'm having to create a block that I strongly capture to keep the AFNetworking block alive... which I believe is creating a leak in my project. I've never had to watch my threading as much before Realm... :/

Alternatively,
-(void)auth {
    __weak typeof(self) weakSelf = self;
    AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
    manager.responseSerializer = [AFHTTPResponseSerializer new];
    [manager GET:@"http://reddit.com/" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
        //Weakly referencing `self` doesn't work either.
        weakSelf.bar = [responseObject objectForKey:@"something"];
    } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
        NSLog(@"Error: %@", error);
    }];
}

doesn't work either, as weakSelf becomes nil (because self deallocates)

Running your example, changing self to be weak there fixes the issue for me.

Look closer, self becomes nil, which is still not right

Well, it's "right" in the sense that that is precisely what weak pointers do. There's an impedance mismatch between what you want to do and the approach you're taking -- your best bet is to refetch your objects every time you context switch onto a new queue.

Yes, however, strongly capturing self in the block keeps the object alive, and AFNetworking will release it (eventually), stopping a retain cycle. I'm not suggesting weak references, it isn't what I am wanting to do, but referencing self strongly in the block should keep my object alive until my block deallocates.

Except you’re not allowed to use persisted RLMObjects from a thread other than the one it was obtained on, and strongly referencing it in that block means you are violating Realm’s threading contract.

On May 9, 2015, at 9:26 PM, Ryan Copley<EMAIL_ADDRESS>wrote:
Yes, however, strongly capturing self in the block keeps the object alive, and AFNetworking will release it (eventually), stopping a retain cycle. I'm not suggesting weak references, it isn't what I am wanting to do, but referencing self strongly in the block should keep my object alive until my block deallocates.
—
Reply to this email directly or view it on GitHub https://github.com/realm/realm-cocoa/issues/1893#issuecomment-100581697.

Which I'm not, they're both on the main thread.

Except AFNetworking obviously is retaining and releasing those blocks on a different thread (or at least is capable of doing so).

@RyanCopley I sent you an email just now. Apologies from Realm again. Thanks for taking the time to file a bug + for providing a repro case. If this issue needs to be investigated any further @jpsim, @mrackwitz or @bdash can help.

We are seeing the same crash since upgrading from 0.91.x -> 0.92.2 on a swift project using Realm-ObjC (via cocoapods) and no AFNetworking.

Thanks for sharing your experiences regarding RLMObject deallocation.
As others have said, RLMObject's are only designed to be used from the thread by which they were created or obtained. This design has been the case since Realm was publicly available.
Only recently did we introduce (#1727 / v0.92.0) a check to ensure [RLMObject dealloc] was only ever called from the expected thread. This check is necessary to prevent accessors from being in an undesirable state.
Even though previous versions of Realm wouldn't exhibit any problems if an RLMObject was deallocated from a different thread in 99% of cases, the remaining 1% would yield incorrect results, and we consider this to be unacceptable. (those figures are a rough estimate). So if you care about the integrity of your data, downgrading Realm to avoid this issue is not a viable solution.
However, as the examples you have provided demonstrate, it is often difficult to ensure that 3rd party code won't deallocate an RLMObject on a different thread. Therefore, we'll be investigating ways to make deallocating RLMObjects on any thread succeed.
We consider this a high-priority item that we must do before a 1.0 release.
Until such a mechanism is in place, we recommend that you avoid deallocating an RLMObject from a different thread, which may sometimes involve doing non-obvious things such as weakly capturing self in a block as discussed here.

Thank you @jpsim for looking into this, if I can be of any assistance please feel free to reach out.

@tgoyne did some really good work to fix this issue in realm's core today. It still needs work, some optimization (maybe) and to be reviewed, but you should buy him a beer if you bump into him.

Thank you @jpsim and @tgoyne ! After our discussion about this I had another look, and it was pretty clear what actually caused our issue. The biggest problem for us was the missing stack trace, and since my understanding of the issue was better after the talk I knew where to focus my efforts.

@jpsim @tgoyne Any update on this issue? :) I may end up pulling all my hair out over this :p

Ooh... for people using AFNetworking,
    manager.completionQueue = dispatch_get_current_queue();

helps out a lot. There is a warning because dispatch_get_current_queue() is deprecated, but I'm not in the mood for caring about a deprecation warning right now

It looks like I'm running into this issue as well, want to ensure its related. I'm using SDWebImage to download/cache remote images, and when images are loaded from the cache or downloaded I grab the image and save the NSData to my RLMObject. Every now and then SDWebImage will cancel a download, which triggers to following chunk of code:
cancelled:^{
   SDWebImageDownloader *sself = wself;
   if (!sself) return;
   dispatch_barrier_async(sself.barrierQueue, ^{
      [sself.URLCallbacks removeObjectForKey:url];
   });
}];

Following the stack track, removing that object from the array triggers the dealloc on RLMObjectBase and the subsequent RLMCheckThread(_realm); to fail.
Does this sound like its related to this issue?

yourSDWebImageDownloader.barrierQueue = dispatch_get_current_queue();

Yes it does.

@RyanCopley I believe dispatch_get_main_queue() is the non-deprecated version of that, I'll try that out.

@mamaral I believe I misread your code, but you can try that. dispatch_get_main_queue() is not an equivalent, however, but it may be in your case

Indeed you're right they are not equivalent... I misread yours.

Yeah I'm not sure what the solution is on this one - Every different method I've tried to integrate Realm with SDWebimage to save images downloaded as NSData on RLMObjects results in the threading issue.

Status update: a pull request making it safe to deallocate an RLMObject and RLMResults from any thread was merged into realm's core db engine yesterday and a new version will be released as soon as possible. Thanks for your patience.

That sounds great! Thank you so much for all your hard work

Sweet, thanks guys!

Fixed in #1984. Thanks for your patience. We'll be cutting a new release of Realm Objective-C and Realm Swift shortly.

We just ran across this bug and confirmed fix in v93.1. Thank you, @jpsim - Caylan


Client is prompted "Do you want to save changes" when closing VS Code with dirty files

I started a live session and joined it from another VS Code instance. Then I made some changes on the host (both host and client got dirty file indicators). I tried to close the Client VS Code and it prompted me to Save/Don't Save changes.
Clicking "Don't Save" sounds like your file will be reverted, but of course it's not - it stays open and modified on the host.
What was your system configuration?
Product and Version [VS/VSCode]: 1.44.2
OS Version[macOS/Windows]: macOS Catalina
Live Share Extension Version: 1.0.2000
Target Platform or Language [e.g. Node.js]: Dart
Steps to Reproduce / Scenario:

Share a live session
Modify file (but don't save) in host
Close client VS Code
See prompt

We’re not able to prioritize this issue over the other higher-impact issues we receive every week, based on the votes and comments from others in the community and our understanding of the issue. We understand this may be disappointing; we've all been there, whether in this project or others we've contributed to. However, rest assured that we love your input. If you feel it deserves to stay open, then clarify your use case and contact us to let us know how severe it’s for you.


React 18 Support Enhancement with use client Directive ⚒

Hi, this PR enhances support for React 18-based applications, especially those utilizing server components, by adding the "use client"; directive. This PR was inspired by the following reference: https://github.com/mui/material-ui/pull/37656.
For more information about client components, please refer to: https://nextjs.org/docs/app/building-your-application/rendering/client-components#using-client-components-in-nextjs.
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

Hey, thanks for the PR! While this is something we'd like to support, we'd prefer not to add it to every file manually.
Instead, we'd like to automate this, most likely through a Parcel Optimizer Plugin https://parceljs.org/plugin-system/optimizer/ which would run after all the build processors, making sure that the minifiers etc don't change it.
If this is something you'd be interested in changing your contribution to, let us know. Otherwise, we can open an issue and it'll get prioritized with team work.
Thanks again!

Hey, thanks for the PR! While this is something we'd like to support, we'd prefer not to add it to every file manually.
Instead, we'd like to automate this, most likely through a Parcel Optimizer Plugin https://parceljs.org/plugin-system/optimizer/ which would run after all the build processors, making sure that the minifiers etc don't change it.
If this is something you'd be interested in changing your contribution to, let us know. Otherwise, we can open an issue and it'll get prioritized with team work.
Thanks again!

Hello @snowystinger,
Thank you for the feedback and the suggestion to automate the process through a Parcel Optimizer Plugin. I'd be interested in exploring this approach. Could you please provide some guidance or resources on how to implement this?
I apologize if my previous contribution caused any disruption. Looking forward to your guidance.
Thanks!

No disruption, thank you for starting the PR in the first place.
Our guidance would be to use:

Parcel Optimizer Plugin https://parceljs.org/plugin-system/optimizer/ which would run after all the build processors, making sure that the minifiers etc don't change it.

The Parcel documentation should have the resources needed. However, you can find examples of usage across Github https://github.com/search?q=import+{Optimizer}+from+'%40parcel%2Fplugin'&type=code
And would probably look something like this:
.parcelrc https://github.com/adobe/react-spectrum/blob/0b541f48848eb43f74ae57e8b21dc4455d95040b/.parcelrc#L25
"*.js": ["@parcel/optimizer-terser", "parcel-optimizer-client"]

order matters for the array ^
dev/parcel-optimizer-client
import {Optimizer} from '@parcel/plugin';

export default new Optimizer({
  async optimize({contents, map}) {
    let {code, sourceMap} = optimize(contents, map);
    code = `'use client';\n${code}`;
    return {
      contents: code,
      map: sourceMap
    };
  }
});

I don't know if you'll need to adjust the sourceMap at all, but there is an example on the docs page shared as well as a link to docs on how source maps work.
You can add it here in our codebase, https://github.com/adobe/react-spectrum/tree/main/packages/dev next to our other Parcel plugins
Once you've done this, you can run yarn build to kick off the build and then inspect the dist files created to make sure they include the use client line at the top.

hope you don't mind but I went ahead and did this in #5498

hope you don't mind but I went ahead and did this in #5498

Yes, I'm excited about https://github.com/adobe/react-spectrum/pull/5498! Apologies for the delay in my response.


Add ability to change confirm type

@akuleshov7, will we update confirm type manually or it should be automated?

Hm, interesting. But why does user can select it?

Are you sure, that someone can edit it?

probably. if we allow admins to change all other fields, this could be changed by admins manually too

For admins only?


x/build/maintner: client Corpus is unhelpfully verbose by default

What did you do?
Use a client *maintner.Corpus via the godata package.
See example code that reproduces this issue.
What did you expect to see?
Stdout filled with a reasonable amount of useful information.
What did you see instead?
Repeated mentions of "Unknown JSON in log":
2021/05/14 16:28:43 Loading data from log *maintner.netMutSource ...
2021/05/14 16:28:44 Downloading 1461526 bytes of https://maintner.golang.org/logs/91 ...
2021/05/14 16:28:44 wrote /Users/dmitshur/Library/Caches/golang-maintner/0091.growing.mutlog
2021/05/14 16:28:58 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:28:58 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:58 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:58 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:58 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:58 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"too heated"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"too heated"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:28:59 Unknown JSON in log: {"lock_reason":"too heated"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"too heated"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"too heated"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:00 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:01 Unknown JSON in log: {"lock_reason":"spam"}
2021/05/14 16:29:02 Unknown JSON in log: {"lock_reason":"resolved"}
2021/05/14 16:29:02 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:29:02 Unknown JSON in log: {"lock_reason":"off-topic"}
2021/05/14 16:29:03 Reloaded data from log *maintner.netMutSource.

CC @golang/release, @ianthehat.

Hi @dmitshur, I would like to work on this issue. If it is available.

@Hrtkk Thanks for offering. As you noticed, there are already 2 CLs out that will fix this issue. You're welcome to help with reviewing them. Thanks!


Example doesn't work on deno deploy playground

Issue
Setup:

Deno Version: Deno deploy
v8 Version: Deno deploy
Typescript Version: Deno deploy
Opine HTTP Proxy Version: 3.0.1
Opine Version: 2.0.2

Details
Deno deploy uses port 8000 by default.
The following example works locally,
import { proxy } from<EMAIL_ADDRESS>import { opine } from<EMAIL_ADDRESS>
const app = opine();

app.use(proxy("https://github.com/cmorten/opine-http-proxy"));

app.listen(8000);

but when I deploy it to deno playground, it returns the following error:
BadRequestError: Bad Request
    at decodeContent (https://deno.land/x/opine@2.0.2/src/middleware/bodyParser/read.ts:66:15)
    at read (https://deno.land/x/opine@2.0.2/src/middleware/bodyParser/read.ts:18:21)
    at https://deno.land/x/opineHttpProxy@3.0.1/src/requestOptions.ts:40:35
    at new Promise (<anonymous>)
    at getBody (https://deno.land/x/opineHttpProxy@3.0.1/src/requestOptions.ts:40:12)
    at reqBody (https://deno.land/x/opineHttpProxy@3.0.1/src/requestOptions.ts:50:41)
    at createRequestInit (https://deno.land/x/opineHttpProxy@3.0.1/src/requestOptions.ts:66:24)
    at buildProxyReqInit (https://deno.land/x/opineHttpProxy@3.0.1/src/steps/buildProxyReqInit.ts:6:28)
    at async Layer.handle [as handle_request] (https://deno.land/x/opine@2.0.2/src/router/layer.ts:49:9)

I'm not sure if this is caused by some limitations of deno deploy sandbox.
It would be cool if we can use opine-http-proxy from official deno playground.
I have made it public at https://dash.deno.com/playground/opine-play

same:
BadRequestError: Bad Request
    at decodeContent (https://deno.land/x/opine@2.0.2/src/middleware/bodyParser/read.ts:66:15)
    at read (https://deno.land/x/opine@2.0.2/src/middleware/bodyParser/read.ts:18:21)
    at https://deno.land/x/opineHttpProxy@3.0.1/src/requestOptions.ts:40:35
    at new Promise (<anonymous>)
    at getBody (https://deno.land/x/opineHttpProxy@3.0.1/src/requestOptions.ts:40:12)
    at reqBody (https://deno.land/x/opineHttpProxy@3.0.1/src/requestOptions.ts:50:41)
    at createRequestInit (https://deno.land/x/opineHttpProxy@3.0.1/src/requestOptions.ts:66:24)
    at buildProxyReqInit (https://deno.land/x/opineHttpProxy@3.0.1/src/steps/buildProxyReqInit.ts:6:28)
    at async Layer.handle [as handle_request] (https://deno.land/x/opine@2.0.2/src/router/layer.ts:49:9)

@btwiuse and @reggi, apologies for the slow reply on this one!
I upgraded some deps to improve the error logging so could investigate why the read module was throwing and in doing so it appears to have fixed the issue! (Something changing between 2.0.2 and 2.3.1 in opine it seems).
See https://dash.deno.com/playground/opine-proxy-demo as a working example
Let me know if have more issues, otherwise consider this closed 🎉


[tooling] retire CJS for libraries

It's 2023 and we don't need commonjs anymore.
graphql-js will drop cjs for 16
This PR:

removes all main entrypoints
removes any unneeded commonjs related config and tools for libraries
leaves the build directory as esm for now, for legacy import support? what do we think of this choice? or should we standardize on dist? I only change this for codemirror-graphql, but this keeps monaco-graphql/esm imports intact. if only imports key in package.json accepted * 😢
simplifies the project references build
if you're using graphql-lsp, upgrade

CJS still exists for:

vscode projects because vscode requires commonjs targer -@graphiql/react and graphiql, where legacy consumers may need them
TODO i think we will need it for cm6-graphql still for tests

After this:

turbopack
drop build-bundles?
targeted dev scripts

or should we standardize on dist?
I prefer dist, also you can add type: module in package.json to avoid mjs extensions

@B2o5T it seems to work fine without mjs extensions

@B2o5T I agree with your point that dist makes more sense... and while we are making breaking changes and bumping versions... we might as well document this in the changelog and examples

@acao it’s per this recommendation https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c#how-can-i-move-my-commonjs-project-to-esm
and about monaco-graphql - it's already a major release so we could introduce breaking changes, also I would keep only the following exports:

monaco-graphql with initialize mode, not ugly monaco-graphql/esm/initializeMode
some exports for workers

so it simplifies things without monaco-graphql/{dist,esm}/something
Also, I would setup this rule https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/filename-case.md for consistency kebab-case filenames that we use in supported The Guild projects
and please hold this PR to merge until I approve it

already one step ahead 😆

I will get vitest working again, and make a few more tweaks, this is almost ready for a final review!

adding "type": "module" will take some more time, and will require converting a bunch of scripts and configs from require to import, I will have to come to that later. this will not be merged without much more review don't worry, haha

We will also need to figure out why this effort regressed before this can have the final review

and will require converting a bunch of scripts and configs from require to import

you can temporarily renames their extension to cjs to avoid such as converting

@B2o5T indeed, but the jest side of things will be tricky, I will need to spend a few more days on this to finish the esm conversion

Also tests fail with the following error
AssertionError: expected '✓ 969 modules transformed.' to include '✓ 1092 modules transformed.
nice 👍 we have fewer converted modules 😂

@B2o5T haha nice! thus why i suggest using the "less than" approach suggested in the comment above. it seems github comments are slow for us today 😆
I think this may be caused by a regression where monaco-graphql/dist/typings/monaco-editor.d.ts is not being picked up. the branch in it's current state fails the example builds
Speaking of, I'm considering whether we should make the example monaco build and one of the graphiql examples part of the netlify build again. This allowed us to validate consuming types previously, and then we had a /monaco or /webpack path to demonstrate the example build output on netlify. it's slower but worth it

maybe ensure it has less than n modules?

I guess it is good to keep the exact number of dependencies, I think we'll adjust this number very rarely when vite version changes or such as this migration

I think this may be caused by a regression where

I can take a look later this week, currently on vacation

@B2o5T no worries, I will figure it out! enjoy your holiday

I guess it is good to keep the exact number of dependencies, I think we'll adjust this number very rarely when vite version changes or such as this migration

This is what I'm worried about. This can be caused by either changes to vite or monaco-editor, and as a rule of thumb, I prefer to not write tests that test internal details of third party dependencies. I still think less than n will be more ideal, otherwise this might frustrate contributors as just small patch resolution changes could break this

@B2o5T ah i found the issue, had overlooked your script that patches types in renaming from esm to dist paths

and now yarn 1 hosting is breaking the vite monaco plugin 😢  pnp mode can't come soon enough haha

@B2o5T i think this is good to merge now, and then your  type": "module" effort can be a follow up PR, just to make the effort more manageable

just to clarify @B2o5T, the purpose of this PR is not to move the whole monorepo to type: module. it is just to remove CJS exports for libraries,  but not for consuming packages.
the effort of moving to "type": "module" is much greater and not required for this, as we can see with vite and webpack (including next js) happily consuming the esm only exports
the effort to move the repo to use esm only will require migration away from jest which does not support type: module, and changes to many files and tooling. these tooling changes are not required to only publish esm, despite how nonsensical it seems to use cjs to publish esm only libraries, this is sufficient for our users. the rest of the tooling migration will happen, but it's not the greatest priority right now.
I'm trying to keep these PRs small, towards simplifying the repo tooling so we can make other improvements. As I mention in the last comment, the effort to move monaco-graphql to "type": "modules" can happen seperately, as it is not required anymore by bundlers, unlike when sindre published that gist

I've learned from shipping other libraries to webpack consumers that commonjs exports are still required, so this is probably a bad idea. type: module is one thing, but dropping main and commonjs exports is another.


Disable project id validation when /internal API calls fail

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Assumption: when /internal API calls HTTP5XX/HTTP401/HTTP403/HTTP400 then echo server is down
Requested Behavior
Echo server does not go down
Anything else?
No response

Main issue: https://github.com/WalletConnect/cerberus/issues/21


Show Hilla when standalone

I was looking for the configuration when Hilla is a separate artifact. I made it work, but would like to check if it is correct. It is sadly removed from the Vaadin Starter, so no example of hybrid mode in version 23 can be found.
   <vaadin.version>23.0.0.beta3</vaadin.version>
    <hilla.version>1.0.0.beta3</hilla.version>

I was looking for the configuration when Hilla is a separate artifact. I made it work, but would like to check if it is correct. It is sadly removed from the Vaadin Starter, so no example of hybrid mode in version 23 can be found.
   <vaadin.version>23.0.0.beta3</vaadin.version>
    <hilla.version>1.0.0.beta3</hilla.version>

Last news is that this will be in the Vaadin Starter again, which is a much better solution. If so just forget this issue


Script for parsing USPTO reaction data

The script, intentionally, does not capture everything. The CML is complicated and if we were starting from scratch I would just rewrite the original parsing code to output ORD records rather than trying to parse the CML.

Hi @connorcoley, I made some changes after our discussion yesterday:

Added REACTION_CXSMILES identifier type.
Made analysis_key optional (warning instead of error).

I chose not to try to parse pH or stirring into ReactionConditions: (1) some pH values are ranges and I don't really want to wrangle those right now; (2) ReactionWorkup better captures the CML fields like duration that we don't have in ReactionConditions (and it would be a pain to try to forward that information to the ReactionOutcome).

Hi @connorcoley, I made some changes after our discussion yesterday:

Added REACTION_CXSMILES identifier type.
Made analysis_key optional (warning instead of error).

I chose not to try to parse pH or stirring into ReactionConditions: (1) some pH values are ranges and I don't really want to wrangle those right now; (2) ReactionWorkup better captures the CML fields like duration that we don't have in ReactionConditions (and it would be a pain to try to forward that information to the ReactionOutcome).

PTAL; it's not perfect and the CML doesn't always put the right values first.

Takes reaction_time from STIRRING or WAIT workups.
Takes temperature from STIRRING or TEMPERATURE workups.
Takes stirring from STIRRING workups.

@connorcoley here's the gist I promised: https://gist.github.com/skearnes/c8426fb607eec55892e2508153241961

@connorcoley here's the gist I promised: https://gist.github.com/skearnes/c8426fb607eec55892e2508153241961

Scratch that; here's a zipfile.
test.zip

Looking at more of these examples, the CML parsing is quite imperfect. There are also more "dynamic conditions" than I expected. Nevertheless, this seems like a very good first pass at adapting the CML schema to the ORD schema. We're not trying to improve parsing of the original text paragraph, so I think this looks good for now. We should approach this data with two stages of disclaimers: the text -> CML is imperfect, and the CML -> ORD is also imperfect

I wonder if there would be any value in hand-annotating some of these text paragraphs. It looks like it would be very fast to go from the paragraph to an ORD entry...probably ≤10 minutes per example. Do you think that it's worth trying to train an information extraction pipeline that goes from patent paragraph to ORD schema entry?

I wonder if there would be any value in hand-annotating some of these text paragraphs. It looks like it would be very fast to go from the paragraph to an ORD entry...probably an average of <5 minutes per example. Do you think that it's worth trying to train an information extraction pipeline that goes from patent paragraph to ORD schema entry?

I think that could be a fun side project, but I don't think this is blocking for any short-term downstream uses so I wouldn't want to go too deep down that hole personally...


Hello, I would like to click on a menu list after the jump to a new page,

Hello, I would like to click on a menu list after the jump to a new page, I began to want to use viewpager but get less than FragmenManager, how to achieve my needs
Data is dynamic

Hello, I would like to click on a menu list after a item jump to a new page, I began to want to use viewpager but get less than FragmenManager, how to achieve my needs
Data is dynamic

Solved me using visible and gone methods


⚠ Bofrost.at has degraded performance

In 2a10e3d, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1330 ms

Resolved: Bofrost.at performance has improved in 63d628f after 20 minutes.


Write web-server loop code

Ensuring that handlers run asynchronously

Done, including health-check and static-files server.


No warning for semi-colon after if-condition

if (false);
{
alert('this will execute. The semi-colon after the if-condition is likely a mistake but no warning is given');
}

Thanks for the report. If you enable JSHint's curly option, then you will receive warnings about the use of a "brace-less" if statements. That will catch the type of programming mistakes that your example describes. Does that work for you?

Sure, that would catch this mistake, but sometimes I want to use a braceless if statement so I'll just work without enabling that option. It took me a few minutes to spot the semi-colon. I debugged and couldn't believe my eyes when the condition evaluated to false and my if-block still executed. I guess this is legal JavaScript: a braceless if-statement followed by a block statement. It just seemed to me like this was a perfect spot for jshint to give a warning like "Did you intend to write a braceless if-statement followed by an unlabelled block-statement or is the semi-colon after the if-condition a mistake?" Maybe it is such an edge case though that it's not worth implementing but I just thought I'd pass it along in case. It's my reflex of adding semi-colons at the end of lines that bit me. Thanks for the quick response and congrats on the great tool!


documentation for alternative credential_spec mode

Proposed changes
credential_spec only works in swarm mode, provide documentation to use security_opt when not in swarm mode.
Related issues (optional)
https://github.com/docker/compose/issues/5488

@axeal PTAL, thanks! Or, let me know if someone else should be reviewing.

@darwin-traver, PTAL? thanks.

@ulyssessouza can you PTAL? Thanks!


Improve Website Homepage

This looks like a great library! BUT there is a multiverse of libraries out there and I can't read the details about all of them. I think the website would really benefit from having a "Why Angular-Formly?" section that's up front and center. IMHO this is more useful than summarizing what the library does - at least for me, I am more interested in the problems a library solves before I want to know how it works.

Good suggestion. I'll look into it.

Kent C. Dodds

(Sent from my mobile device, please forgive typos or brevity)
On May 8, 2015 9:16 AM, "Jordan"<EMAIL_ADDRESS>wrote:

This looks like a great library! BUT there is a multiverse of libraries
out there and I can't read the details about all of them. I think the
website would really benefit from having a "Why Angular-Formly?" section
that's up front and center. IMHO this is more useful than summarizing what
the library does - at least for me, I am more interested in the problems a
library solves before I want to know how it works.
—
Reply to this email directly or view it on GitHub
https://github.com/formly-js/angular-formly/issues/277.

Migrating this to the website: https://github.com/formly-js/angular-formly-website/issues/20


Kraken pod scenario is not working for me

I'm currently testing the Kraken tool with the Minishift which is installed on the virtual machine. I was able to test application chaos successfully and can see network policy getting created. That scenario worked perfectly.
After that, I tried to test the Pod scenario where it tries to kill the pod but it looks like the Kraken tool is not able to find the resource.
I'm not able to figure out the issue. Any help would be greatly appreciated.
2022-06-22 02:21:18 ERROR k8s_client (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Cache-Control': 'no-store', 'Content-Type': 'application/json', 'Date': 'Wed, 22 Jun 2022 02:21:18 GMT', 'Content-Length': '174'})
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"the server could not find the requested resource","reason":"NotFound","details":{},"code":404}

Traceback (most recent call last):
  File "/root/krkn/chaos/lib/python3.8/site-packages/powerfulseal/k8s/k8s_client.py", line 231, in get_scenarios
    crds = self.client_extensionsApi.list_custom_resource_definition().to_dict()['items']
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api/apiextensions_v1_api.py", line 613, in list_custom_resource_definition
    return self.list_custom_resource_definition_with_http_info(**kwargs)  # noqa: E501
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api/apiextensions_v1_api.py", line 716, in list_custom_resource_definition_with_http_info
    return self.api_client.call_api(
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api_client.py", line 348, in call_api
    return self.__call_api(resource_path, method,
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api_client.py", line 180, in __call_api
    response_data = self.request(
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api_client.py", line 373, in request
    return self.rest_client.GET(url,
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/rest.py", line 239, in GET
    return self.request("GET", url,
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/rest.py", line 233, in request
    raise ApiException(http_resp=r)
kubernetes.client.exceptions.ApiException: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Cache-Control': 'no-store', 'Content-Type': 'application/json', 'Date': 'Wed, 22 Jun 2022 02:21:18 GMT', 'Content-Length': '174'})
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"the server could not find the requested resource","reason":"NotFound","details":{},"code":404}

Traceback (most recent call last):
  File "/root/krkn/chaos/bin/powerfulseal", line 8, in <module>
    sys.exit(start())
  File "/root/krkn/chaos/lib/python3.8/site-packages/powerfulseal/cli/__main__.py", line 656, in start
    main(sys.argv[1:])
  File "/root/krkn/chaos/lib/python3.8/site-packages/powerfulseal/cli/__main__.py", line 625, in main
    success = runner.run(
  File "/root/krkn/chaos/lib/python3.8/site-packages/powerfulseal/policy/policy_runner.py", line 86, in run
    policy = self.read_policy()
  File "/root/krkn/chaos/lib/python3.8/site-packages/powerfulseal/policy/policy_runner.py", line 52, in read_policy
    scenarios = self.k8s_client.get_scenarios()
  File "/root/krkn/chaos/lib/python3.8/site-packages/powerfulseal/k8s/k8s_client.py", line 231, in get_scenarios
    crds = self.client_extensionsApi.list_custom_resource_definition().to_dict()['items']
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api/apiextensions_v1_api.py", line 613, in list_custom_resource_definition
    return self.list_custom_resource_definition_with_http_info(**kwargs)  # noqa: E501
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api/apiextensions_v1_api.py", line 716, in list_custom_resource_definition_with_http_info
    return self.api_client.call_api(
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api_client.py", line 348, in call_api
    return self.__call_api(resource_path, method,
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api_client.py", line 180, in __call_api
    response_data = self.request(
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/api_client.py", line 373, in request
    return self.rest_client.GET(url,
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/rest.py", line 239, in GET
    return self.request("GET", url,
  File "/root/krkn/chaos/lib/python3.8/site-packages/kubernetes/client/rest.py", line 233, in request
    raise ApiException(http_resp=r)
kubernetes.client.exceptions.ApiException: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Cache-Control': 'no-store', 'Content-Type': 'application/json', 'Date': 'Wed, 22 Jun 2022 02:21:18 GMT', 'Content-Length': '174'})
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"the server could not find the requested resource","reason":"NotFound","details":{},"code":404}

2022-06-22 02:21:19,179 [ERROR] Failed to run powerfulseal autonomous --use-pod-delete-instead-of-ssh-kill --policy-file scenarios/openshift/etcd.yml --kubeconfig /root/.kube/config --no-cloud --inventory-kubernetes --headless, error: Command 'powerfulseal autonomous --use-pod-delete-instead-of-ssh-kill --policy-file scenarios/openshift/etcd.yml --kubeconfig /root/.kube/config --no-cloud --inventory-kubernetes --headless' returned non-zero exit status 1.

Also, Tried injecting chaos using docker images as per the instructions below. But, that is not working as well and failing with the below error.
Instructions for injecting chaos using docker image: https://github.com/chaos-kubox/krkn-hub/blob/main/docs/pod-scenarios.md
root@ocpvm1:~# docker logs krknPodChaos
+ source /root/main_env.sh
++ export CERBERUS_ENABLED=False
++ CERBERUS_ENABLED=False
++ export CERBERUS_URL=http://<IP_ADDRESS>:8080
++ CERBERUS_URL=http://<IP_ADDRESS>:8080
++ export WAIT_DURATION=60
++ WAIT_DURATION=60
++ export ITERATIONS=1
++ ITERATIONS=1
++ export DAEMON_MODE=False
++ DAEMON_MODE=False
++ export RETRY_WAIT=120
++ RETRY_WAIT=120
++ export PUBLISH_KRAKEN_STATUS=False
++ PUBLISH_KRAKEN_STATUS=False
++ export PORT=8081
++ PORT=8081
++ export LITMUS_VERSION=v1.13.8
++ LITMUS_VERSION=v1.13.8
++ export SIGNAL_STATE=RUN
++ SIGNAL_STATE=RUN
++ export DEPLOY_DASHBOARDS=False
++ DEPLOY_DASHBOARDS=False
++ export CAPTURE_METRICS=False
++ CAPTURE_METRICS=False
++ export ENABLE_ALERTS=False
++ ENABLE_ALERTS=False
++ export ES_SERVER=http://<IP_ADDRESS>:9200
++ ES_SERVER=http://<IP_ADDRESS>:9200
+ source /root/env.sh
++ export RUNS=1
++ RUNS=1
++ export SECONDS_BETWEEN_RUNS=30
++ SECONDS_BETWEEN_RUNS=30
++ export NAMESPACE=my-project
++ NAMESPACE=my-project
++ export POD_LABEL=app=django-ex
++ POD_LABEL=app=django-ex
++ export DISRUPTION_COUNT=1
++ DISRUPTION_COUNT=1
++ export EXPECTED_POD_COUNT=3
++ EXPECTED_POD_COUNT=3
++ export TIMEOUT=180
++ TIMEOUT=180
++ export SCENARIO_TYPE=pod_scenarios
++ SCENARIO_TYPE=pod_scenarios
++ export 'SCENARIO_FILE=- scenarios/pod_scenario.yaml'
++ SCENARIO_FILE='- scenarios/pod_scenario.yaml'
++ export SCENARIO_POST_ACTION=
++ SCENARIO_POST_ACTION=
+ ls -la /root/.kube
+ source /root/common_run.sh
total 20
drwxr-xr-x 1 root root 4096 Jun 22 03:52 .
dr-xr-x--- 1 root root 4096 Jun 19 22:55 ..
-rw------- 1 root root 6698 Jun 21 22:18 config
+ checks
+ check_oc
+ log 'Checking if OpenShift client is installed'
++ date +%d-%m-%YT%H:%M:%S
22-06-2022T03:52:30 Checking if OpenShift client is installed
+ echo -e '\033[1m22-06-2022T03:52:30 Checking if OpenShift client is installed\033[0m'
+ which oc
+ [[ 0 != 0 ]]
+ check_kubectl
+ log 'Checking if kubernetes client is installed'
++ date +%d-%m-%YT%H:%M:%S
22-06-2022T03:52:30 Checking if kubernetes client is installed
+ echo -e '\033[1m22-06-2022T03:52:30 Checking if kubernetes client is installed\033[0m'
+ which kubectl
+ [[ 0 != 0 ]]
+ check_cluster_version
+ kubectl get clusterversion
error: the server doesn't have a resource type "clusterversion"

@sinamas1 sorry for the delayed response, we updated the pod scenarios code base to use native support as well as run on Kubernetes. Please feel free to let us know if the issue still persists. Thanks.


Speed up the /plans/provision/container plan

While the rest of the full tmt plans take about 20 minutes, /plans/provision/container takes over an hour to complete. Let's speed up the testing by running the install and ansible tests separately as they take the most time.

For reference, here's a recent plan duration:
1:10:02	/plans/provision/container
0:22:46	/plans/features/steps/discover
0:22:26	/plans/features/core
0:18:27	/plans/features/basic
0:15:57	/plans/features/steps/execute
0:15:09	/plans/features/advanced
0:15:09	/plans/features/advanced
0:08:49	/plans/features/steps/prepare
0:05:01	/plans/features/steps/the\-rest
0:04:13	/plans/install/pip/full
0:03:04	/plans/install/pip/mini
0:02:36	/plans/provision/local
0:02:14	/plans/install/minimal
0:01:41	/plans/integration
0:00:55	/plans/remote/polarion
0:00:23	/plans/sanity/lint

Individual test times:
1103s /tests/prepare/install
752s  /tests/finish/ansible
631s  /tests/prepare/ansible
417s  /tests/execute/duration
159s  /tests/prepare/feature
157s  /tests/test/check/watchdog
121s  /tests/prepare/recommend
70s   /tests/run/worktree
62s   /tests/provision/become
56s   /tests/execute/reboot/out-of-session
49s   /tests/prepare/adjust
49s   /tests/execute/tty
45s   /tests/discover/distgit
43s   /tests/pull/results
42s   /tests/execute/restart/basic
36s   /tests/prepare/multihost
29s   /tests/security/ansible
25s   /tests/provision/reboot
22s   /tests/login/ready
21s   /tests/test/debug
21s   /tests/provision/user
20s   /tests/core/escaping
17s   /tests/provision/facts/guest
14s   /tests/pull/simple
14s   /tests/provision/container/alpine
11s   /tests/test/check/dmesg
11s   /tests/core/spaces

Unrelated failure, looks like a flake. Merging.


Auth towards Function from f.e. Logic App

For a private site I have set up required authentication to a custom role on the whole site via route: *. This leads to the functions under /api/ also being protected by authentication, which is of course a good thing.
However I have a hard time understanding or reproducing in Postman how I can now call the functions under /api/ with for example a StaticWebAppsAuthCookie value. How can I let apps like Logic Apps authenticate with the Functions?

Interesting question, this scenario is designed for web applications on platforms that can leverage cookies. Can you describe your scenario a little bit? Are you trying to use a shared Function backend for both a web application as well as the logic app?

I'm trying to use the Function for both the SWA front-end as well as a Logic App, indeed.


Make side-wide color scheme more consistent

The colors on the side vary a lot between projects and elements. Also, I'm not a fan of some of the unstyled elements' default colors. Lets tidy up the colors on a few elements.
Inconsistent colors on button elements:

Example border (1px solid #dfdfdf) on the quote and promotion panes:

I have played with brightening the colors of the green and blue in the stats pane, and can't determine whether the promote pane (bottom) button looks odd at that color.

I refactored the Sass stylesheets to more closely resemble 7-1 Pattern by Hugo Giraudel. Also brought in the dark chart background from stats.chrisvogt.me.


remove usage of layer 'user_name' options field

Currently, code uses options['user_name'] for schema qualification of queries and the like inside layer data (upon decorating it with the presenters). It also mistakenly uses User.username instead of User.database_schema (only in the old presenter).
By migrating everything to use Layer::Presenter and Carto::LayerPresenter constructor options :viewer_user and :user, we can drop this old usage and clear error-prone code.

There has been no activity on this issue for more several months. We are closing it. If you think this still needs to be addressed please open a new issue.


Files with large extremely long lines cause hangs

May be a known issue, but files with large embedded images such as github's public/enterprise/maintenance.html will often cause Atom to freeze (MacVim actually struggles as well).
Seems some of them (github's public/maintenance.html for instance) work fine when in soft wrap mode, or until you move your cursor to the long line when out of soft wrap.

Via @tdegrunt in #5270

The following file will not open with Atom, but Brackets (and SublimeText, etc) will open the file instantly.
It's likely due to the very long line (with strange characters), but still ...

https://gist.github.com/tdegrunt/1404dc0c35be458bdb59

@benogle even the web editor renders it very quickly.

I have done some investigations on this issue. Below are some details.
The benchmark runs with two test files(test-oneline.js, test-multiple.js), which are the same except line organization. The test-oneline.js is a line containing about 150000 characters.
Environment

Matchine: MacBook Pro on OS X 10.9.4 with 2.4GHz Intel Core i5, 8GB RAM, 256G SSD.
Atom version: 0.179.0

Steps

Open Atom's dev-tools, switch to Profiles tab and click Start button to start profiling.
Open the test file in Atom, wait until finishing.
Click Stop button to stop profiling.

Result

File
Parser Time
Total Time

test-oneline.js
21s
22.7s

test-multiple.js
1.8s
2.7s

I also run the same benchmark in first-mate directly under nodejs v0.11.13, it gave similar results:

Below are the detailed profile charts in dev-tools.
test-oneline.js:

test-multipleline.js

From above charts, we can easily find that the function OnigScanner.findNextMatchSync, a JS wrapper for native C++ _findNextMatchSync function, takes most of time during parsing period.
It’s probably the major reason causing parser slowly with long-line statements since we pass a long string to _findNextMatchSync each time.
BTW, I also find performance issue about joinLine, see #5882.

I replicated tests done by @hokein and I can confirm his findings. So far as I can see, OnigScanner interfaces with the Oniguruma regex library to perform some sort of matching on the input, line by line. The line, however, is very large in this case. And, regular expressions can be quite slow, mostly achieving O(n^2) for backtracking based algorithms which is pretty bad for 150k char line.
Now, the Oniguruma engine seems to be using a backtracking algorithm (Link 1 Link 2) which is the commonly used approach on Ruby, Perl, PHP etc. However, backtracking algorithms can have 'potentially exponential worse cases' as compared to the finite-state automata regex engines.
According to this post by Google, the RE2 engine works under a linear time cap:

we've built a new regular expression engine, called RE2, which is based on automata theory and guarantees that searches complete in linear time with respect to the size of the input and in a fixed amount of stack space

Also, tried and tested programs such as GNU grep and awk also use the FSA based regex engines which can perform much better. See also these results that confirm what I'm saying in favour of RE2.
So, my point is, perhaps we should switch from the Oniguruma engine to the RE2 engine. All evidence points to the fact the even though RE2 can be a tad slower than Oniguruma in a few specific cases, it is still linear in the worst case as compared to Oniguruma which can be exponential in the worst case.

@prasoon2211, Changing to a faster regex engine is one of possible solutions. But as @excaliburHisSheath pointed out, Oniguruma supports more than 30 types of character encodings which is a feature for Atom.
Parsing long line is aslo a performance issue in other editors(Vim, SublimeText). One of the common ways to improve performance is limiting the length of line or disabling parsing long line.

Vim provides a setting synmaxcol allowing user to specify the largest highlight length, see help synmaxcol

synmaxcol' 'smc'       number  (default 3000)
local to buffer
{not in Vi}
{not available when compiled without the +syntax
feature}
Maximum column in which to search for syntax items.  In long lines the
text after this column is not highlighted and following lines may not
be highlighted correctly, because the syntax state is cleared.
This helps to avoid very slow redrawing for an XML file that is one long line.
Set to zero to remove the limit.

Sublime Text 3 disables highlight if the line is too long for performance, see http://www.sublimetext.com/forum/viewtopic.php?f=3&t=15019

So, I think Atom can follow the processing way of Vim/Sublime. Now Atom limits the maximum highlighted tokens to 100 per line for performance. To go further, we might add the maximum highlighted characters per line, by providing a setting option(like {maxCharactersPerline:100}) in node-oniguruma APIs. @kevinsawicki what's your idea here?

Is there a reason why Atom couldn't break parsed lines into smaller chunks for parsing? If the issue is that really long lines cause problems it seems like you could internally represent long lines as several smaller segments for the purposes of parsing and editing. I can see the potential for issues if you were to split a token along segment boundaries, but I think that could be fairly easily avoided for the majority of use cases.

@hokein I checked on emacs - it highlights the whole line, at least without any configuration changes. It does get a little slow, however. So, I suppose it is entirely possible to achieve highlighting long lines. Emacs does it with Elisp/C so atom should be able to do it with JS/C++
@excaliburHisSheath I thought of that but since well established editors like vim and emacs have this same problem with highlighting long lines, I suspect that there might be a deppeer problem with this approach that we're not seeing yet. Otherwise, I'm sure someone would have added this feature to those editors in the last 30 years :smile:

In Atom text are converted to UTF-8 before doing the syntax highlighting, so we are not benefiting from Oniguruma's multiple encoding support, and I don't think we will because JavaScript strings in V8 are represented in UTF-8/UTF-16.
Oniguruma was chosen because we need to be compatible with TextMate syntax bundles, so changing to another regex engine will break most Atom's syntax packages.

Oh, I didn't know that. But it is worth investigating, IMHO, broken syntax packages or no. Right now, the only major problem I can see people having with atom are related to its performance. So, if using re2 does indeed boost up perf significantly, then I believe it should be done, since it will be helpful in the long run. Syntax highlighting can be made to work later. But that's just my opinion :smile:

@prasoon2211, @excaliburHisSheath, @hokein -
Oniguruma may not be as fast as other regexp engines, but I think the root of the problem is the overall tokenization strategy that Atom (and many other text-editors) employ: matching a sequence of regexps to each line, one regexp at a time. This approach will always lead to performance problems for sufficiently long lines.
I think a better solution would be to tokenize buffers using a full-fledged scanner (a program that combines all the token patterns into a single state machine). This would completely eliminate the long lines problem. A flex-style scanner wouldn't be a complete substitute for a TextMate-grammar though, because TextMate grammars also provide some approximate syntactic information (classes, function definitions, function calls, etc). To fill that roll, we would need an actual parser. This parser would need to be able to efficiently re-parse buffers after edits.
I've been working on an experimental C library, tree-sitter for generating these types of incremental parsers and scanners. I have made node bindings for it, and an Atom package that uses it - syntax-tree.
Currently, the Atom package does not do anything about syntax highlighting. It just maintains a syntax tree for the buffer as you edit it, and allows you to quickly select structural units of text. The system is very much a work in progress. If you're interested in this sort of thing though, I'd love to hear your feedback on it.

@maxbrunsfeld What are the implications of combining all the regexps into a single scanner? If I understand correctly the point would be to combine all the regexps from the different plugins and systems interested in parse data, so are you still able to separate the resulting parse data out the interested parties?
Also, I'm guessing there are still other problems with representing long lines as single strings. Beyond slow parsing I'm guessing editing slows down when you have single lines that contain megabytes of text, though I haven't been able to test this yet. It's probably not as pressing an issue as the parsing since parsing is what is causing the hangs immediately.

@excaliburHisSheath all of the tokens for a given language (e.g. javascript, coffee-script, etc) are incorporated into one scanner. Each language has its own scanner. The output of parsing is a syntax tree that can be queried by any package. Are you asking about nested grammars like javascript within HTML, or code within markdown documents? I haven't implemented that capability in my library, but I believe I know how it could be done.

@maxbrunsfeld No, I was just curious how you'd get the parsed information to the packages, creating a syntax tree makes a lot of sense. How does that compare to how the information is being passed currently? Is atom already creating a syntax tree? As for nested grammars, how well does atom's existing parsing handle this? In my experience other editors like sublimetext don't handle it very well, so if you have a way to do that through a scanner then that's another feature that atom can boast.
Personally I think the bigger issue is with how atom represents text internally. Representing each line as a single string works fine for most documents, but when you've got documents with single long lines it's no better than just representing the whole document as single strings. That makes me think that there's a better way of handling the content of the document that scales better with both long lines and long files. Doing something to break up the lines into segments seems like the most obvious thing to do, and I imagine it could be done in a way that's (mostly) transparent to other systems.

Oniguruma may not be as fast as other regexp engines, but I think the root of the problem is the overall tokenization strategy that Atom (and many other text-editors) employ: matching a sequence of regexps  to each line, one regexp at a time. This approach will always lead to performance problems for
sufficiently long lines.

@maxbrunsfeld Agree.  Atom will iterate all the regexps to find a best match token, which will cost a lot of time.

I think a better solution would be to tokenize buffers using a full-fledged scanner (a program that > combines all the token patterns into a single state machine). This would completely eliminate the long lines problem. A flex-style scanner wouldn't be a complete substitute for a TextMate-grammar though, because TextMate grammars also provide some approximate syntactic information (classes, function definitions, function calls, etc). To fill that roll, we would need an actual parser. This parser would need to be able to efficiently re-parse buffers after edits.

I've been working on an experimental C library, tree-sitter for generating these types of incremental parsers and scanners. I have made node bindings for it, and an Atom package that uses it - syntax-tree.

Sounds great. With syntax-tree, we can also support "jump to function" feature without ctags(symbols-view).
In this solution, should we write a grammar manaully for every programming language? If so, it may require a lot of work. Besides, the tree-sitter generates LR(1) parser. But due to LR(1)'s limitation(only looks ahead one token at a time), it cannot handle all kinds of  programming languages(such as C++).

@hokein Yes, we'd have to write a grammar for every programming language. I don't think they're that difficult to write though (see the javascript grammar).
I know that a few languages such as C++ can't be fully described by LR(1) grammars, but remember that our main goal is to allow syntax highlighting; we're not trying to compile or interpret the program, so it's ok if statements are occasionally parsed incorrectly. As long as we fully tokenize the buffer, and the majority of the program is parsed correctly, an LR(1) parser will be a vast improvement over TextMate grammars.
Also, as grammar formalisms go, LR(1) is pretty powerful. Any LR(k) grammar can be converted to LR(1), and most programming languages grammars are designed to be efficiently parseable, usually by a less powerful formalism, like LALR(1).

This sounds like a very good idea. I don't think Textmate compatibility is something important, it was only helpful to get an initial set of language plugins. And since we wouldn't want to break all plugins in on stroke, plugins would probably opt-in to using LR(1) instead of regex parsers. For something like javascript the regexes are an unmaintainable mess with a lot of subtle problems and a proper grammar would help greatly.

Does anyone have a workaround to view large files in Atom until this issue is resolved?

@tribou If your file is "large" (>2MB) you can use @mark-hahn's view-tail-large-files package.  I can't guarantee that will work for the bug described here though.

view-tail-large-files also hangs up on long lines.

view-tail-large-files also hangs up on long lines.

The limit is somewhat artificial.  It is just there because the file read
input buffer has to be that big.  It is currently set at 10 KB.  How long
would you need?
On Wed, Apr 15, 2015 at 7:36 AM, Pine Wu<EMAIL_ADDRESS>wrote:

view-tail-large-files also hangs up on long lines.
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/979#issuecomment-93425482.

@mark-hahn
Do you mean 10MB?
Sorry the culprit turns out to be a small package I wrote myself just for large file testing. Your package works great for long lines.

Do you mean 10MB?

Nope.  I just checked the readme and it is actually 16 KB.  I can bump it
up if anyone has a use case.  Lines that long would be impossible to read.
:-)
On Wed, Apr 15, 2015 at 2:06 PM, Pine Wu<EMAIL_ADDRESS>wrote:

@mark-hahn https://github.com/mark-hahn
Do you mean 10MB?
Sorry the culprit turns out to be a small package I wrote myself just for
large file testing. Your package works great for long lines.
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/979#issuecomment-93569434.

view-tail-large-files worked for me.  Thanks!

issue still exists

have the same issue with latest version on mac

Issue is still there on latest version on Windows 7 64 bit
Even it shows error to close the atom or keep waiting i keep waiting and it shows again and again. Took about 4 minutes to load the file containing just about < 20K lines.
Migrating towards Visual Studio Code  , will shift back once done :-1:

This issue is already on the 1.0 roadmap and currently being addressed.
Many improvements from text-document are making their way into text-buffer, which is the package Atom uses to handle files.  In addition, @as-cii, @nathansobo, and @maxbrunsfeld have been hard at work trying to optimize Atom and decrease its memory usage so that situations like this no longer happen (for example, #5931 aims to partially solve this issue while #6757 reduces memory usage by ~70%).
In the meantime, a package by @mark-hahn is also available (view-tail-large-files) that may act as a temporary workaround to this issue.
In light of all this, I'm going to lock this issue for now.

Related issue #8345
Timeline:

Bump. I'm using a database prefiller skript that uses base64-coded images to store them in the database. It's only 3 images, but Atom editor hangs on loading. Even worse, after "killing" the editor using the "hang" dialog, the tree-view is missing.

Loading a uglified react.js file created by browserify... it hangs. on MacAir, 4Gb RAM.

Same here, long lined "uglified" file makes Atom freeze.

Hi , I would like to contribute to github atom. Please help me how can I join with the discussion groups. It'l be a good experience for me to join with Github also while studying since I have experience in Opensource for some time.

I fully realize that this is not an easy one to fix, but at the same time, it's quite awkward when I convince another colleague to use Atom and then it hangs indefinitely when they open a random file.
From the looks of it, an intermediate solution would be to limit the line length at which the RE parser kicks in. After all, disabling syntax highlighting and linting is a lot better than going completely unresponsive. My gut feeling says that this would be a relatively straightforward patch. Any chance of getting it in for the time being?

I agree with @timdp
I convinced many programmers to atom but really ashamed off when they randomly opened some file and it hanged every single time.
They all moved to visual studio code
I love atom therefore always looking discussion witha hope that they will make it faster else i will move to visual studio code.

A solution I just discovered currently involves adding a .jshintignore to the app root with 'public/jquery.js' (or whatever the file is causing you issues) if you are running the jsHint package. Still a small hint of delay but good to say no more messages asking to close the window or wait.

Also, @hokein did some great work profiling typical invocations earlier in this thread. Below the _findNextMatchSync function that he identified as the culprit, there's a _findNextMatch that is presumably async. Wouldn't it also be possible to use that one?

Works on OSX and in the browser too. I don't know why long lines cause such a problem.

@timdp Yes, I'd also prefer having no linting over having to kill the whole editor...

@derwaldgeist I'd prefer having no listing than having to kill my entire browser... (with not-exactly-restorable data)

:+1: for no linting in this case

I think there should be a disable lint functionality in web Atom; or perhaps a persistent setting in HTML5 web storage.

I don't think 'linting' has anything to do with this. Atom does not provide linting; it is provided by a third party package: https://github.com/atomlinter/linter. If you want to disable syntax highlighting, select Plain Text from the Grammar Selector.

I hope this is fixed soon. I pretty much can't edit HTML files on GitHub. On slow computers, it freezes me for 5 seconds every time I type a character. On my MBA, it freezes when I type a few characters I type, and then I have to close the browser. Is there a way to change atom into a raw text editor?

Just to add,
working with large JSON files this is also causing me issues,
currently cannot open atom at all,
have deleted the file which caused this and still cannot open atom.

I'm already switched to Notepad++ . Didn't see much progression for this commonly required fix. Kinda dissappointed.
Thanks afterall for the Effort of building this editor.

Atom should be able to open files with very large lines starting with Atom 1.16.0.

We decided to backport this fix to the current beta release, so it's available today in Atom 1.15.0-beta3.


Save the information inserted for the user

Save information inserted by the user in the app user data
directory, and every time the application is opened,
insert the saved information in the fields on the screen.
fix: #38

LGTM!


Added method for storing against custom storage

Need this in a current project - works differently to the existing store method.

Thanks, I've merged and pushed this to npm. I also added an example in examples/usage.js

@RexMorgan Awesome, cheers, I was going to add an example but wasn't sure if it would break if I made up a target.

@aaunel no problem, it does break, but I have a custom store with my uploadcare api keys that matches that. Unfortunately the usage.js has turned into my make-shift unit tests, lol.


Add variable-length-quantity exercise.

thanks @ricemery
Let's not forget to review the difficulties of these recently added exercises, too.


python311Packages.karton-core: 5.3.2 -> 5.3.3

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

4 packages failed to build:

python312Packages.karton-autoit-ripper
python312Packages.karton-autoit-ripper.dist
python312Packages.karton-config-extractor
python312Packages.karton-config-extractor.dist

28 packages built:

python311Packages.karton-asciimagic
python311Packages.karton-asciimagic.dist
python311Packages.karton-autoit-ripper
python311Packages.karton-autoit-ripper.dist
python311Packages.karton-classifier
python311Packages.karton-classifier.dist
python311Packages.karton-config-extractor
python311Packages.karton-config-extractor.dist
python311Packages.karton-core
python311Packages.karton-core.dist
python311Packages.karton-dashboard
python311Packages.karton-dashboard.dist
python311Packages.karton-mwdb-reporter
python311Packages.karton-mwdb-reporter.dist
python311Packages.karton-yaramatcher
python311Packages.karton-yaramatcher.dist
python312Packages.karton-asciimagic
python312Packages.karton-asciimagic.dist
python312Packages.karton-classifier
python312Packages.karton-classifier.dist
python312Packages.karton-core
python312Packages.karton-core.dist
python312Packages.karton-dashboard
python312Packages.karton-dashboard.dist
python312Packages.karton-mwdb-reporter
python312Packages.karton-mwdb-reporter.dist
python312Packages.karton-yaramatcher
python312Packages.karton-yaramatcher.dist