async and sync in the same program

I maintain some libraries that have sync and async users. The async users wrap calls in spawn_blocking, which works, but isn't ergonomic and may be suboptimal. maybe_async looks like it could potentially be (part of) an alternative approach.
If I read the docs right, maybe_async can support both sync and async users, but by using a cargo feature, it can't support both in the same program. If the library gets used in multiple places in the same program, and one of them enables is_sync, it would break the other places that need async.
It seems like it would be useful to have a macro that expands to both sync and async, using different names, so that they can coexist. For example,
#[maybe_async::both]
async fn foo() -> bool {
    true
}

might expand to:
#[cfg(feature = "async")]
async fn async_foo() -> bool {
    true
}
#[cfg(feature = "sync")]
fn sync_foo() -> bool {
    true
}

so that users can call whichever form they need by name (though I'm not attached to the particular naming convention here).

I highly support that, arangors has that issue, and my own crate aragog too.
is_sync/is_blocking should be additive

Ruyt 1.51 introduce a new resolver in cargo, which will compile crate for each set of different feature gates on dependencies.
With this v2 resolver, this issue is automatically solved. Just add the following lines in your Cargo.toml:
[package]
resolver = "2"
# Or if you're using a workspace
[workspace]
resolver = "2"

Plus, it doesn't make sense to compile both async and sync in the same program. Why use a blocking code when you can use async version?

Building on what @sunfishcode wrote, I have a trait in one of my crates (sorry, source is not public at this time) that is used in another of my programs in both sync (local file system) and async (contacting a remote service) contexts. For the local file system part of my program, I'd really rather not take on the complexity of async.
Please reopen and reconsider.

I think the new resolver can help when one of dependencies use a different feature(blocking or async). I haven't tested it yet, but I think it should work.
And regarding the case of providing async and blocking at the same time, I don't really get it. When the program is able to run async code, it is natural to stick with async implementation. And when async executor is not available, it's ok to use blocking version as a fallback.
I have actually tried writing a [new procedural macro]
(https://github.com/fMeow/amphi) to duplicate the code turned the copied ones to blocking code on another module. But my implementation make it really hard to maintain and debug. It deprives compiler from the ability to tell us which lines goes wrong.

Unfortunately no. The recommendation in the documentation is wrong:

RECOMMENDATION: Enable resolver ver2 in your crate, which is introduced in Rust 1.51. If not, two crates in dependency with conflict version (one async and another blocking) can fail complilation.

Because the resolver v2 only fixes the conflicts in very specific cases (https://doc.rust-lang.org/cargo/reference/resolver.html#feature-resolver-version-2), none of which match this one:

Features for target-specific dependencies are not enabled if the target is not currently being built.
Features enabled on build-dependencies or proc-macros will not be unified when those same dependencies are used as a normal dependency.
Features enabled on dev-dependencies will not be unified when those same dependencies are used as a normal dependency, unless those dev-dependencies are currently being built.

I've also made a repo to try it myself: https://github.com/marioortizmanero/resolver-v2-conflict

Also, I think it might be best to expand with modules:
#[maybe_async::both]
async fn foo() -> bool {
    true
}

to this:
#[cfg(feature = "async")]
mod impl_async {
    pub async fn foo() -> bool {
        true
    }
}

#[cfg(feature = "sync")]
mod impl_sync {
    pub fn foo() -> bool {
        true
    }
}

So that it's just easier to use and more flexible overall

It should also be the default behavior because the current one is just wrong; no need to use maybe_async::both. I will try to see if I can implement this myself (but I don't promise anything, I'll be leaving in a couple days)

After attempting to implement this I've come to the conclusion that it's far from trivial (I kinda saw it coming).

maybe_async should work for structs as well. Sometimes you can't just add _sync/_async to every single method in your struct for usability reasons. It might be wiser to just have ThingSync::method over Thing::method_sync at some point.

Two traits would be generated now, like TraitSync and TraitAsync, which means errors about duplicate trait methods available, because both of them expose the same function names:
error[E0034]: multiple applicable items in scope
  --> examples/service_client.rs:55:15
   |
55 |         Self::post("http://correct_url4create", String::from("my_bucket")).await
   |               ^^^^ multiple `post` found
   |
note: candidate #1 is defined in an impl of the trait `InnerClientSync` for the type `ServiceClient`
  --> examples/service_client.rs:16:11
   |
16 |     async fn post(url: Url, data: String) -> Response {
   |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: candidate #2 is defined in an impl of the trait `InnerClientAsync` for the type `ServiceClient`
  --> examples/service_client.rs:16:5
   |
16 |     async fn post(url: Url, data: String) -> Response {
   |     ^^^^^^^^^^^^^
help: disambiguate the associated function for candidate #1
   |
55 |         InnerClientSync::post("http://correct_url4create", String::from("my_bucket")).await
   |         ^^^^^^^^^^^^^^^^^^^^^
help: disambiguate the associated function for candidate #2
   |
55 |         InnerClientAsync::post("http://correct_url4create", String::from("my_bucket")).await
   |         ^^^^^^^^^^^^^^^^^^^^^^

The only solution I can come up with is to have the macro replace Self, StructName and TraitName for TraitNameSync/TraitNameAsync. Same for self, but it would have to be treated differently and converted to TraitNameSync::method(self, ...), for example.

@fMeow, can you add a warning about this library to the docs until this is worked on?

Sure, I will update the doc in both readme and documentation in crate.io in the next minor release.

Update: we can actually do the duplicate traits thing if we also duplicate the struct that implements it. So instead of having a single struct that implements both the async and the sync traits, which is ambiguous, we have two structs, one for each trait.
I've got it working more or less in my fork, but I only modified the both macro (previously maybe_async) and it's not complete. It's enough to get these examples to compile:

This is how maybe_async would be used: https://github.com/marioortizmanero/maybe-async-rs/blob/main/examples/service_client.rs
What it would expand to when the user enables both sync and async: https://github.com/marioortizmanero/maybe-async-rs/blob/main/examples/service_client_both.rs (You can see what's actually automatically generated by running cargo expand --example service_client --all-features > expanded.rs)

So basically, maybe_async::both will now work for:

Functions: appending _sync/_async
Structs and enums: appending Sync/Async
Traits: appending Sync/Async
Structs and enums impl blocks: appending Sync/Async
Trait impl blocks: appending Sync/Async to the trait name, to the self type (the implementor), or to both. This could be configured with parameters.

We could later add parameters to configure the suffix (suffix = "_Async"), or to configure the entire name (async_name = "Stream", sync_name = "Iter").
What do you think? Do you like it? Is it enough for everyone's use cases? I know it would for rspotify myself.

Thanks a lot for this library. Quite cool idea!

Plus, it doesn't make sense to compile both async and sync in the same program. Why use a blocking code when you can use async version?

imo that is too broad: there are valid use-cases to offer both versions.
E.g. 1: a user of a library may need to consume data from two databases on which one offers a native async API while the other offers a sync version. E.g. the async is a remote db (e.g. postgres) while the sync is a local one (e.g. sqllite). The fs may be sufficiently fast for a Read to be ok.
E.g. 2: when loading data from large files that still fit in memory, it is almost always faster to download the file async to Vec<u8> and then parse it sync, than to read and parse it async. This is because many encoding that read byte by byte (such as zigzag) are faster in their sync versions.
Imo these decisions could be left to the users of this library.

I think it would be fine to append _async and _sync: we can always keep them private and wrap the functions on public versions with the namings we want. The hard part is still valuable because of the DRY of the code inside the body; the API is just one-liners :P

This is super interesting and might actually fix our issue! https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics.html

I have a experimental inplementation to enable both async and sync, where I try to add a proc macro on a rust module to compile the underlying module to two modules, one for synchronous code and another for async. I have got an working implementation a long time ago, but I never publish it because error messages from rustc is quite messy. I wonder there is some new feature in rust that can tackle the messy error message issue. Might look into it  this week.

Is there an update on this? :)
It would be really useful to have both versions in one crate..

Going back to the other suggestion, why not use the is_sync/is_async module?
I think that would be more in the direction of the common pattern of having a blocking module. E.g. reqwest.

FWIW I wrote a crate that does exactly (and only) this problem: https://crates.io/crates/async-generic

@scouten-adobe That looks really cool!
But it does not solve the problem of having a single implementation, right?
I mean, I think the ideal solution would be implement once and generate a sync and an async version. Also, your crate seems to be incompatible with maybe_async, is that right?

@janosimas the intent of async-generic is exactly what you stated: You write one function definition and the macro expands that into two functions: one sync and one async. I'm a little surprised to see that this intent wasn't communicated clearly and I'd welcome suggestions or edits to the readme that would make that intent more obvious.
There's no intentional incompatibility with maybe_async, but I'm attempting to solve a different problem.

(Note: @scouten-adobe and I are the same person, just writing from work or personal computers.)

@scouten maybe I was not clear with what I meant.
Seems to me that to use async-generic, I have to "tag" async or sync parts of the code. From what I understood, you still have to write what should be sync or async.
The incompatibility is that if I mark a function with maybe_async, your crate is still restricted by the maybe_async version that was compiled. It cannot use maybe_async to generate the a/sync functions with async-generic.
I can open a discussion in async-generic if you prefer to continue the discussion there.

@janosimas I'd welcome any suggestions on how to address/resolve if you have any. (Maybe those should be filed as an issue over in async-generic so we don't spam this issue.)

@scouten Sorry, I got busy and didn't follow up.
A colleague came with a solution using the duplicate crate:
#[duplicate_item(
  module_type           maybe_async_attr   some_other_type;
  [ non_blocking ]     [ must_be_async ]    [ AsyncType ];
  [ blocking ]             [ must_be_sync ]      [ Blockingtype ];
)]
mod module_type {
    #[maybe_async_attr]
    pub async fn foo(input: some_other_type) -> ... {
    ...
    }
}


JWT decoding

Perhaps this would be considered out of scope for the project, if so, please feel free to ignore. I'm not entirely sure where the best place to add/expose this functionality would be, but given the base64url decoding in Utils, it would be pretty trivial to add a utility function to decode the claims of a JWT. I have a use case where the client receives a JWT signed by a server, and it is expected to return said JWT on successive API requests. The client doesn't necessarily have to verify the signature on the JWT (although there are certainly situations where it would want to). It does need to unpack it and see what's inside, however. I had previously been using auth0/jwt-decode for this, but was thinking that if this functionality was rolled into js-jose, I could drop a dependency.
It should be as simple (error-checking aside) as something like:
decodeJwt(jwt:string):string {
  let parts = jwt.split('.');
  let json = Jose.Utils.Base64Url.decode(parts[1]);
  let rv = JSON.parse(json);
  return rv;
}

I would prefer not to implement jwt in this library. I don't see what's wrong with having a dependency on auth0/jwt-decode and/or just writing you example code (calling into Jose.Utils.Base64Url). I could be wrong, can you explain the pros of supporting JWT?

JWS/JWE/JWT strikes me as a combined ecosystem, and it's nice to have a single, consistent API for dealing with all aspects of it. js-jose has its object hierarchy of signers, verifiers, encrypters, and decrypters. When I'm in the mode of thinking of dealing with it, I have one set of API documentation and source code to keep up-to-date and look at. It feels unnatural to then have to call a function like window.jwt_decode that follows none of the naming or scoping conventions of js-jose (and this would become exacerbated if there is a TypeScript rewrite, as all the js-jose calls will be nicely type-checked and easily imported, with no munging around with globals, making jwt_decode stick out like even more of a sore thumb).
Beginners to the whole JSON encryption standards world (well, me at least) tend to get confused about what the difference between JWE and JWS and JWT are and when they should use which and to what degree they are interchangeable. If they can think to themselves "here is this opaque object I have gotten from somewhere that I want to verify and decrypt" or "here is this thing I want to sign and encrypt and pass it to a server that is expecting a JSON web thingy", and the answer is "go to the js-jose library and make a verifier and a decrypter and give them the object" or "go to the js-jose library and make a signer and a decrypter and give them the secret data", it maps directly to their goal. They don't have to take the intermediate step of thinking "now does this action require a JWE or a JWS or a JWT, and which RFC documents which one of those, and which library do I need to call to handle that?".

ok, would you like to send me a PR? Ideally, it would be nice to have some kind of sub-package/conditional build system. Any suggestions how to get there?

I support this effort, and second rapropos' thinking. It's better for beginners, and in the future, people could just use JS modules to do: import { jwt_decode } from 'js-jose'.

We recently added jwt support to our go library (see https://github.com/square/go-jose/commit/6e3cf7d768dd5a249c7461f58bc08d7e3c3bb493). Might be helpful to look at for anyone wanting to take a stab at adding support to this library.

Believed addressed by #48.


[INFRA] Host Client to Heroku

Development Task 🔧
What? ❓
Host the client in a Heroku Dyno using the team's Gmail.

Completed!
https://hireflow-client.herokuapp.com/
Docs have been updated with Heroku credentials if anyone on the team needs to change anything.


not open checkout ⚠

does not load payment by yape, and since yesterday the checkout no longer opens, I have tried https://github.com/klujanrosas/react-culqi (somewhat deprecated) and if it opens normally

I'm sorry for any trouble you're having with payment loading via Yape. To help you better, could you share more details about the error? Have you checked the browser console logs for possible insights?
I'll do my best to assist you in resolving this quickly.


Add Clace in category Application Definition & Image Build

Pre-submission checklist:
Please check each of these after submitting your pull request:

[X] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[X] Is your project closed source or, if it is open source, does your project have at least 300 GitHub stars?
[X] Have you picked the single best (existing) category for your project?
[X] Does it follow the other guidelines from the new entries section?
[X] Have you added your SVG to hosted_logos and referenced it there?
[X] Does your logo clearly state the name of the project/product and follow the other guidelines?
[X] Does your project/product name match the text on the logo?
[X] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?

LGTM

LGTM


Consider avoiding creating a new app context when using json argument in test client

At this moment, when a Flask test client method uses the json argument, a new application context is created in the line below.
https://github.com/pallets/flask/blob/b9b88b0cdf70190dee5c7d31a83efb1cae888a63/flask/testing.py#L82
The problem is that when the above created context goes out of scope, anything registered to teardown_appcontext is called. This is the case of Flask-SQLAlchemy, which remove the current session when that happens.
This is problematic is some tests scenarios.
I am using PostgreSQL SAVEPOINT to rollback any changes made by a test case. My approach is similar to this example provided by SQLAlchemy here, so I'm not going to put all my code here, just a shallow example.
I have a class that creates a nested transaction and rollback everything when needed.
client = app.test_client()
trn = TransactionManager(database)

with app.app_context():
    trn.start() # start a new nested transaction

    client.post('/products', data=json.dumps({'name': 'Cake'}))
    client.get('/products')

    trn.end() # Rollback before the session is removed.

The above works well because everything happens inside the same transaction and each test client interaction can see changes made to the database by previous client calls.
But using the json argument, the POST call will first create an application context, which immediately will go out of scope making Flask-SQLAlchemy's teardown_appcontext registered function remove the current session before the next client call, making each database interaction in a different transaction.
Why do we need an application context to dump the JSON string?
https://github.com/pallets/flask/blob/b9b88b0cdf70190dee5c7d31a83efb1cae888a63/flask/testing.py#L83
I don't understand, but if the the above logic is necessary I think the code should check first if there is an application context pushed already using has_app_context.
Am I doing something wrong or I am missing something?

Hi, I passed hours trying to find why my blended objects were detached from the session just after using get() function. I finally reached to the same problematic line. Removing the context creation or replacing it with test_request_context fixed my problem.
What do Flask guru think about this part of code?
https://github.com/pallets/flask/blob/c92001d2fbaf4d5aa43bd44e56416ed27313377c/flask/testing.py#L81-L86

I think this may be better than using test_request_context:
from flask import current_app

try:
    push_ctx = not current_app or current_app != app
    if push_ctx:
        ctx = app.app_context()
        ctx.push()

    kwargs['data'] = json_dumps(kwargs.pop('json'))
finally:
    if push_ctx:
        ctx.pop()

@kumy Did you test your code?.
The Flask test client and test_request_context use make_test_environ_builder under the hood. So, probably your code is going to end up in a recursive call.

@mbarakaja Yes, it is currently deployed in my dev environment and it works.
I also just tested code from @garenchan and it's also working in my use case.

I’m in the exact same situation. The double app context teardown is making it difficult to roll back sessions in test environments. Once for jsonify and once again for the actual request.


Actor Reminder Partition No Longer Preview Feature

The purpose of this issue is to gather supporting evidence of Actor Reminder Partitioning no longer needing to be a preview feature.
Release version: 1.3
Supported SDKs: Java, Python, PHP, .NET
Missing SDKs: JS

@artursouza - Can you triage this so it doesn't go stale?

Notice I triaged to 1.6.

Let's make this Stable for 1.8. We are also enabling this in Container Apps!

We need more E2E test scenarios for this to happen. Volunteers?

Enabled this by default in 1.8.


context \ sequence length

Hi there!
I couldn't find details about it in the paper nor README,
what is the maximum content length of your inputs? I mean, disassmbled files are pretty long, around ~300K tokens, how did you handle it? what was the tokens distribution of your inputs?
Thank you :)

As for large files, we'll break it into function-level pieces before using LLM4Decompile, which can be done either using Ghidra or regular expressions.
And this initial version of LLM4Decompile is limited to decompilation of individual functions. We're working on integration with Ghidra and gathering our own datasets to support practical use!


Add renovate config for earthfile and script

No need to wait on build for this one

Codecov Report

Merging #401 (81953a7) into main (9b13f06) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main     #401   +/-   ##
=======================================
  Coverage   12.32%   12.32%
=======================================
  Files          17       17
  Lines        1071     1071
=======================================
  Hits          132      132
  Misses        912      912
  Partials       27       27

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Fixed a typo

Queues -> Cues

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


handle trailing slash on endpoint

based on https://github.com/nodevault/node-vault/pull/176
fixes https://github.com/nodevault/node-vault/issues/175
Co-authored-by: Jason Nguyen<EMAIL_ADDRESS>Co-authored-by: Bret Hubbard<EMAIL_ADDRESS>

replaced by https://github.com/vaultaire/vaultaire/pull/23


Activate Spell Checking

By default, CodeMirror disables spellchecking. For a blog editor, I think it could be nice to enable it:
From http://codemirror.net/1/manual.html
Should the editor disable spell-checking on browsers that support it (Firefox 2+).
Default is true, since for most code spell-checking is useless. Can be changed with the setSpellCheck(on) method.

#9311 should solve this.


Update HandleVsOn.md

Update HandleVsOn.md on the handler name.

Codecov Report

Merging #3720 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #3720   +/-   ##
======================================
  Coverage     100%    100%
======================================
  Files          70      70
  Lines        1578    1578
======================================
  Hits         1578    1578

Continue to review full report at Codecov.

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


No completion in function-local impl blocks

Completion of struct members inside an impl block inside a function does not work.

It also does not work if the struct definition is moved out of main(). Completes fine if both definition and impl block are outside main. This feels kinda related to #4438 and maybe even is a dupe of that one, so feel free to mark as such. Then again, it might have a different cause so reporting that here nonetheless.
Environment:

rust-analyzer d54e115
GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0) of 2021-02-09, modified by Debian
lsp-mode-20210311.814

Duplicate of https://github.com/rust-analyzer/rust-analyzer/issues/7633


Adding one more API to find matches which ignores statSync erros.

It is my attempt to solve the issue #317. Please suggest any design feedback or any other methods for solving it.

Added new API to task lib tryFindMatch which ignores errors during while following the symlinks.
Returns the list of matches found and the list of errors if any.

Looks like this is going to be a no-op, so I'm going to close here, feel free to reopen if appropriate.


Correct claims about how Jammit works

While Jammit can use the filesystem as a build cache at runtime (much
like the asset pipeline), the official recommendation from the Jammit
documentation is to build the assets at build-time. In fact, that's
exactly what the 'jammit' command is for.
http://documentcloud.github.io/jammit/#precaching

We dropped the ball here - sorry! Rebased here.


Move to GitHub Actions for CI

Pull Request Test Coverage Report for Build b37c485e2f5f47bbec3e590f1b0c6f36ed136f6a-PR-705

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 97.178%

Totals

Change from base Build 3241:
0.0%

Covered Lines:
1481

Relevant Lines:
1524

💛  - Coveralls

Pull Request Test Coverage Report for Build b37c485e2f5f47bbec3e590f1b0c6f36ed136f6a-PR-705

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 97.178%

Totals

Change from base Build 3241:
0.0%

Covered Lines:
1481

Relevant Lines:
1524

💛  - Coveralls


GPU activity not detected for GTX 1060

GPU activity is always reported as 0.0%. Other things like RAM usage and fan speed work fine.
[ PCI Express 2.0 x16: nVIDIA GeForce GTX 1060 6GB ]
Graphics Processor Properties:
  Video Adapter                                     nVIDIA GeForce GTX 1060 6GB
  BIOS Version                                      86.06.0E.00.99
  BIOS Date                                         2016-07-28
  GPU Code Name                                     GP106-400
  PCI Device                                        10DE-1C03 / 0000-0000  (Rev A1)
  Transistors                                       4400 million
  Process Technology                                16 nm
  Die Size                                          200 mm2
  Bus Type                                          PCI Express 2.0 x16 @ 2.0 x16
  Memory Size                                       6 GB
  GPU Clock                                         1556 MHz
  RAMDAC Clock                                      400 MHz
  Pixel Pipelines                                   48
  Texture Mapping Units                             80
  Unified Shaders                                   1280  (v5.0)
  DirectX Hardware Support                          DirectX v12
  WDDM Version                                      Unknown (ID = 2700)

Memory Bus Properties:
  Bus Type                                          GDDR5 (Samsung)
  Bus Width                                         192-bit
  Real Clock                                        2003 MHz (QDR)
  Effective Clock                                   8012 MHz
  Bandwidth                                         187.8 GB/s

Edit: I can't get "GPU 0", which is the only GPU in my system, to replace the default "GPU". The GPU column in the Processes view never displays any activity

After going to Settings -> Advanced and setting ProcessHacker.ExtendedTools.EnableGpuPerformanceCounters to 1, I had to restart System Informer, then it showed 😅
Don't know why it was disabled.
Sorry, wish I could delete this issue. I guess this might be useful for others, so up it stays 🤷♂

I guess this might be useful for others

can confirm


profiles/hardened: setting environment.memoryAllocator.providerto scudo occasionally breaks sshd

Describe the bug
After importing profiles/hardened.nix, I noticed that logging into my host via SSH would occasionally fail with one of the following errors:
client_loop: send disconnect: Broken pipe

Connection closed by <host IP> port 22

Connection reset by <host IP> port 22

journalctl -u sshd on the remote host showed the following error:
fatal: privsep_preauth: preauth child terminated by signal 31

I was able to reduce this to the allocator change. Setting environment.memoryAllocator.provider = "scudo"; is enough to cause these occasional sshd crashes.
Steps To Reproduce
Steps to reproduce the behavior:

Add  environment.memoryAllocator.provider = "scudo"; to configuration.nix and switch to the new configuration on the remote host.
Try to repeatedly connect to the host with while true; do ssh <host> true; done.
Observe one of the error messages shown above.

Expected behavior
SSH connections work as expected.
Additional context
Here's the backtrace from a coredump:
(gdb) bt
#0  0x0000de92f957e828 in syscall () from /nix/store/5z7rlpz6dsnp5fgivz24kkc19va507h7-glibc-2.33-62/lib/libc.so.6
#1  0x0000de92f9b68554 in gwp_asan::AllocationMetadata::RecordAllocation(unsigned long, unsigned long) () from /nix/store/hkvgl5ka064a0c55vfwcc20li06jqg2s-malloc-provider-scudo/lib/libclang_rt.scudo-aarch64.so
#2  0x0000de92f9b69150 in gwp_asan::GuardedPoolAllocator::allocate(unsigned long, unsigned long) () from /nix/store/hkvgl5ka064a0c55vfwcc20li06jqg2s-malloc-provider-scudo/lib/libclang_rt.scudo-aarch64.so
#3  0x0000de92f9b56df0 in __scudo::Allocator::allocate(unsigned long, unsigned long, __scudo::AllocType, bool) () from /nix/store/hkvgl5ka064a0c55vfwcc20li06jqg2s-malloc-provider-scudo/lib/libclang_rt.scudo-aarch64.so
#4  0x0000de92f9b5337c in __scudo::scudoAllocate(unsigned long, unsigned long, __scudo::AllocType) () from /nix/store/hkvgl5ka064a0c55vfwcc20li06jqg2s-malloc-provider-scudo/lib/libclang_rt.scudo-aarch64.so
#5  0x0000de92f99d90ac in CRYPTO_zalloc () from /nix/store/qqk9kv2kma1iy9h8cipfhk8g5widswic-openssl-1.1.1m/lib/libcrypto.so.1.1
#6  0x0000de92f99c8530 in EVP_CipherInit_ex () from /nix/store/qqk9kv2kma1iy9h8cipfhk8g5widswic-openssl-1.1.1m/lib/libcrypto.so.1.1
#7  0x00000f5c1335a954 in chachapoly_new ()
#8  0x00000f5c1333eb48 in cipher_init ()
#9  0x00000f5c1334580c in ssh_set_newkeys ()
#10 0x00000f5c1335c110 in kex_input_newkeys ()
#11 0x00000f5c1334e3a4 in ssh_dispatch_run ()
#12 0x00000f5c1334e47c in ssh_dispatch_run_fatal ()
#13 0x00000f5c132f08a4 in main ()

And some output from strace:
[pid  3544] gettid()                    = ?
[pid  3544] +++ killed by SIGSYS (core dumped) +++

As shown in the backtrace, this gettid call is coming from gwp_asan::AllocationMetadata::RecordAllocation (getThreadID is a simple wrapper around gettid).
gettid is not included in OpenSSH's seccomp whitelist: https://github.com/openssh/openssh-portable/blob/V_8_8_P1/sandbox-seccomp-filter.c#L133. So this should probably be fixed upstream.
Notify maintainers
@joachifm
@emilazy
Metadata

system: "aarch64-linux"
host os: Linux 5.10.94, NixOS, 22.05 (Quokka)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.5.1
channels(root): "nixos-21.11.334797.6979c0e49bb"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

This should be fixed by #161569.

reopen if it happens again


Signature help shows incorrect info in a code block

This might be a dupe of https://github.com/dotnet/razor/issues/6335 but this happens on first request of sig help, and is not a re-request issue like comments there suggest, so logging it separately.
Inside a code block, as soon as I type the ( in the new string() bit of code pictured, I get the sig help for the AddAttribute runtime method that the whole thing is inside.

Also happens when just typing @if ( when inside a component

Closing as dupe of https://github.com/dotnet/razor/issues/9722


Real example with dependency loading

It would be good to have an example where the js dependencies are also loaded via systemjs (or better a jspm example).
In the current example (color-slider) the js libs are loaded through script tags.
I have problems to get a  test app running when I try to load the libs via SystemJs

agreed. I'm working on a jspm example. It should be up some time next week. I'll keep you posted.

I added an example project that uses jspm. https://github.com/robianmcd/angular-next/tree/gh-pages/examples/hello-jspm

Thank you for providing jspm support (looks good - would only suggest to load angular also via import)
I would be curious  how you use it with e.g. traceur and offline compilation (the example uses on the fly transpilation) Do you have any idea?
BTW, do you use angular-next in real projects? I would like write future projects as compatible as possible with Angular2 and your project looks very promising...

jspm has a bundle command you can use to compile everything offline and bundel it into one file: https://github.com/jspm/jspm-cli/wiki/Getting-Started#6-bundle-for-production
I'll modify the example to incorporate bundling and requiring angular 1 from jspm.
I wouldn't recommend using angular-next in production yet. Mainly because Angular 2 is still pretty undocumented and volatile so angular-next will need to change every time something changes in Angular 2.

Great, thank you


Credentials not found issue.

I have added the node to my chatwoot, I am using https://app.chatwoot.com/api/v1 this url as chatwoot api url and the access token from my profile setting, but when I save, it says not found, Please solve the issue.

try https://app.chatwoot.com (no api/v1)

Done, thanks for the help.


fix: downloading playbook is fixed by using correct api-client function

This fixes the download feature on 'View logs' modal.
To test:

Visit the 'Remote host configuration' app.
open 'View log' modal on the top right'
click on the 'Download' button on the table.
Observe a playbook is downloaded.

Codecov Report
Base: 47.50% // Head: 47.50% // No change to project coverage :thumbsup:

Coverage data is based on head (3847c6c) compared to base (b560247).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #109   +/-   ##
=======================================
  Coverage   47.50%   47.50%
=======================================
  Files          68       68
  Lines         840      840
  Branches      180      180
=======================================
  Hits          399      399
  Misses        414      414
  Partials       27       27

Impacted Files
Coverage Δ

src/Components/ConnectLog/LogsTable.js
0.00% <0.00%> (ø)

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.

@gkarat thank you for the quick review :1st_place_medal: !


DayViewFacade.setSelectionDrawable and DayViewFacade.setBackgroundDrawable cannot work at the same time

public class SetBackgroundDrawableDecorator implements DayViewDecorator {

    private final Drawable drawable;

    public SetBackgroundDrawableDecorator(Context context) {
        drawable = context.getResources().getDrawable(R.drawable.bg_cus);
    }

    @Override
    public boolean shouldDecorate(CalendarDay day) {
        return true;
    }

    @Override
    public void decorate(DayViewFacade view) {
        view.setBackgroundDrawable(drawable);
    }
}

public class SetSelectionDrawableDecorator implements DayViewDecorator {

    private final Drawable drawable;

    public SetSelectionDrawableDecorator(Context context) {
        drawable = context.getResources().getDrawable(R.drawable.my_selector);
    }

    @Override
    public boolean shouldDecorate(CalendarDay day) {
        return true ;
    }

    @Override
    public void decorate(DayViewFacade view) {
        view.setSelectionDrawable(drawable);
    }
}

R.drawable.bg_cus is a shape.xml and R.drawable.my_selector is a selector.xml.
if i use
（1）widget.addDecorators(new SetSelectionDrawableDecorator(this));
or
（2）widget.addDecorators(new SetBackgroundDrawableDecorator(this));
works fine；
but
widget.addDecorators(new SetSelectionDrawableDecorator(this),new SetBackgroundDrawableDecorator(this));
works just like (2);
it seems that setSelectionDrawable() will be invalid while using setBackgroundDrawable().
It is a bug?
Android version : 5.11LMY47V.
Library version:com.prolificinteractive:material-calendarview:1.2.1

@wangzhuangzhuang I was able to reproduce it. To fix it, your bg_cus needs to have some transparency.
For example:
This bg_cus will hide my_selector:
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
  <item android:drawable="#006BBA"/>
</selector>

This bg_cus will show the other selector background:
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
  <item android:drawable="#22006BBA"/>
</selector>

This bg_cus will show the background on all the tile. If you want bg_cus to be applied only on selected date, you need to do the same as my_selector:
Final bg_cus:
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android"
    android:exitFadeDuration="@android:integer/config_shortAnimTime">

  <item android:state_checked="true"
      android:drawable="#22006BBA" />

  <item android:state_pressed="true"
      android:drawable="#22006BBA" />

  <item android:drawable="@android:color/transparent" />

</selector>

Let me know if this works or not.

@quentin41500 Thanks for your answer!I seems that you can not use color value in  directly,so I use
<item android:drawable="@drawable/show_other"/>

instead.And all of them works just as you said.


Sample usage error in IE9

I'm trying this sample usage in IE9: http://jsfiddle.net/danialfarid/s8kc7wg0/219/
And I'm getting this error:
ngFileUpload: Circular reference in config.data. Make sure specified data for Upload.upload() has no circular reference: file[blob][files][0]
I have to set file.blob.files = [] for it to work.  But still, the file size will be 0 so the progress bar won't work correctly.

I am running into the same issue when trying to upload a file in IE9.  I am not bothering with progress but it still doesn't work.  Is there a workaround?

That was a bug introduced recently for fixing accessibility warning. Fixed at version 10.1.14.

I have the same issue, now on version 11.0.0.

@IsraelSouza Have you tried with the latest version? Post your code here. Does the demo page work?

Hi!! I have tried with the version 11.0.0, downloaded by bower.. As i have to solve this with certainly urgency, i opted to use angular-file-upload, thanks a lot for fast response, and sorry by poor english.

I am getting this issue on and off (which is really weird) on IE9 with 11.1.1

I have the same issue in 11.0.0

@thilakWD What issue do you have and is the demo page and the jsfiddle mentioned above working?

I am getting this error in ie9 ngFileUpload: Circular reference in config.data. Make sure specified data for Upload.upload() has no circular reference: file[blob][files][0] . it is working in ie10 and above. but it is not working in ie9. i have used 11.0.0 version

and the jsfiddle mentioned above working?

In ie10 and above, that above jsfiddle as well as my project is working. but in ie9 the js fiddle shows this error in console SCRIPT5007: Unable to get property 'id' of undefined or null reference .
and in my project it shows ngFileUpload: Circular reference in config.data. Make sure specified data for Upload.upload() has no circular reference: file[blob][files][0] as i have used file api and flash  which was in your post.

If you could help, can you please tell me how to write, if it is ie9--> it should take normal upload, other wise it should take ng-file-upload. Please

This will be the problem when i use this code for preview on my page. '` if i comment or remove this line ,i can upload but not able to preview it. is there any fix for it.

I have included html5shiv script. it solves me the problem. thank you

Hello, I'm having the same problem on IE9 with 11.1.1.
When I use Chrome or Firefox everything works fine, but using IE 9 appears the message :
ngFileUpload: Circular reference in config.data. Make sure specified data for Upload.upload() has no circular reference: file[blob][files][0]
I'm calling on page

//MODAL TO INPUT THE FILE

×
A3 Attachments

*File size cannot exceed 15 MB
{{message}}

//THIS IS MY ANGULAR FUNCTION
$scope.onFileSelect = function(file) {
$scope.upload = Upload.upload({
url: './model/uploadA3.php',
method: 'POST',
data: {file: file, id_plan: $scope.plan.cod}
}).success(function(data, status, headers, config) {
if(data == '1'){
$scope.message = "Error to send file, verify the type or size!";
}else if(data == '2'){
$scope.message = "Please don't use on the file name characters like % or #";
}else{
$http.get('./model/atachA3/'+$scope.cod)
.success(function(data) {
$scope.atachInfo = data;
$(data).each(function( i ) {
$scope.attachCount = i+1;
});
});
$('#addAtach').modal('hide');
$scope.message = "";
$scope.file='';
}
});
};
Thank you in advanced!!!

@StephanieOSZ What version of the plugin? Can you create a reproducible jsfiddle?

getting the same error using version 12.0.3

I am having exact same issue. I am using version 12.2.5. Only happens in IE9

make sure you include the shim file

This is what I have. Is there any other Shim I need to include?

make sure 'FileAPI.*' files are loaded. They should be placed at the same server location. Checkout the section for Old Browsers in the docs.

Thanks. I will check and make sure it is getting loaded.
-------- Original message --------From: Danial Farid<EMAIL_ADDRESS>Date: 9/6/16  2:38 AM  (GMT-06:00) To: danialfarid/ng-file-upload<EMAIL_ADDRESS>Cc: bartonsprings<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [danialfarid/ng-file-upload] Sample usage error in IE9 (#1199)
make sure 'FileAPI.*' files are loaded. They should be placed at the same server location. Checkout the section for Old Browsers in the docs.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/danialfarid/ng-file-upload","title":"danialfarid/ng-file-upload","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/danialfarid/ng-file-upload"}},"updates":{"snippets":[{"icon":"PERSON","message":"@danialfarid in #1199: make sure 'FileAPI.*' files are loaded. They should be placed at the same server location. Checkout the section for Old Browsers in the docs."}],"action":{"name":"View Issue","url":"https://github.com/danialfarid/ng-file-upload/issues/1199#issuecomment-244872911"}}}

Ok. I added the FileAPI.* shims also in my paths (I thought earlier that they will be downloaded on demand) but I included them in my index.html. But same errors. Here is the image of IE9 network loads:

Also, here are the error messages I am getting:
ngFileUpload: Circular reference in config.data. Make sure specified data for Upload.upload() has no circular reference: file[blob][files][0]
TypeError: Unable to get value of the property 'ignoreAuthModule': object is null or undefined

You can check if you are loading it properly by right clicking on the button and it should show the flash context menu.

It does not show the Flash context menu so something is wrong on my side. I am using a virtualbox VM (Win7/IE9). Don't know if that could be creating an issue. But I checked that Flash is loaded on my system.

Use the demo page as the guide, copy the code to your page and try from a simple example. Also the order of loading the scripts are important.

I know how it happened
When the content is too long to appear scroll bar
If the upload button is outside the screen
The flash control does not cover the button correctly

Same happening here. I am using version 12.2.12. Only happens in IE9


MWDI sliding window priority function causing uneven distribution of requests resulitng in heavy load on Mediators

Problem Background:
MWDI caching all devices as per the list of connected devices updated to the sliding window.
When a set of devices are disconnected due to maintenance window - During the realignment process, the list of connected devices are updated and the disconnected devices are dropped.
Once the maintenance window is completed and all device connections are restored. MWDI will know the list of connected devices using NP or during the realignment process.
During the realigment process, MWDI is prioritizing the devices which are restored after mainteance. These devices are sequenced in the sliding window with priority. Thousands of Requests are addressed to the devices on the same mediator causing heavy load to Mediator.
Secondly, the priority sequence is not changed in MWDI during every subsequent realignment process.
So every day Thousands of Requests are addressed to the devices on the same mediator causing heavy load to Mediator.
We expect the same problem once Notification proxy is enabled in production due to  the DCN fluctuations (repeatedly receiving coneecting/disconnecting notifications).
Current Work around:
We are forced to restart MWDI application after every maintenance activity on the underlying components.

Hi Katharina and Thorsten,
Today we discussed the issue in the OPS call.
A method of procedure shall be defined to build redundancy for component under maintenance.  We will prepare  a desing.
Open Point: Incase of Incident (Mediator crashed), MWDI will have result in the same problem.  Not sure how we can handle this problem.
For repeated notifications from DCN flapping devices  Needs resolution.


issues entering the TARDIS crashing the game

This happens when I enter the Tardis, basically only when entering and leaving it crashes, but it doesn't corrupt anything it just crashes, I think it must be due to some incompatibility with one of the mods that I have installed, I will pass the last log in case it helps in any way.
crash-2023-11-30_13.10.37-server.txt
last log.txt

It seems like the doctor who mod makes the player capabilities unavailable.
Same as TeamLapen/Vampirism#1342


[BUG] JsonRpc服务无法捕获到异常

Execute the command and paste the result below.
Command: uname -a && php -v && composer info | grep hyperf && php --ri swoole
Linux 98f28c3d34e8 4.9.184-linuxkit #1 SMP Tue Jul 2 22:58:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
PHP 7.2.20-2+ubuntu16.04.1+deb.sury.org+1 (cli) (built: Jul 25 2019 11:42:36) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.20-2+ubuntu16.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
Do not run Composer as root/super user! See https://getcomposer.org/root for details
hyperf/amqp                          v2.0.0      A amqplib for hyperf.
hyperf/cache                         v2.0.0      A cache component for hyperf.
hyperf/circuit-breaker               v2.0.0      A circuit breaker component for hyperf.
hyperf/command                       v2.0.0      Command for hyperf
hyperf/config                        v2.0.0      An independent component that provides configuration container.
hyperf/config-aliyun-acm             v2.0.0      An aliyun acm adapter for Hyperf config component.
hyperf/constants                     v2.0.0      A constants component for hyperf.
hyperf/consul                        v2.0.0      A Consul Client for Hyperf.
hyperf/contract                      v2.0.0      The contracts of Hyperf.
hyperf/database                      v2.0.0      A flexible database library.
hyperf/db-connection                 v2.0.0      A hyperf db connection handler for hyperf/database.
hyperf/devtool                       v2.0.0      A Devtool for Hyperf.
hyperf/di                            v2.0.0      A DI for Hyperf.
hyperf/dispatcher                    v2.0.0      A HTTP Server for Hyperf.
hyperf/event                         v2.0.0      an event manager that implements PSR-14.
hyperf/exception-handler             v2.0.0      Exception handler for hyperf
hyperf/framework                     v2.0.0      A coroutine framework that focuses on hyperspeed and flexible, specifically use for build microservices and middlewares.
hyperf/guzzle                        v2.0.0      Swoole coroutine handler for guzzle
hyperf/http-message                  v2.0.0      microservice framework base on swoole
hyperf/http-server                   v2.0.0      A HTTP Server for Hyperf.
hyperf/json-rpc                      v2.0.0      A JSON RPC component for Hyperf RPC Server or Client.
hyperf/load-balancer                 v2.0.0      A load balancer library for Hyperf.
hyperf/logger                        v2.0.0      A logger component for hyperf.
hyperf/memory                        v2.0.0      An independent component that use to operate and manage memory.
hyperf/model-listener                v2.0.0      A model listener for Hyperf.
hyperf/paginator                     v2.0.0      A paginator component for hyperf.
hyperf/pool                          v2.0.0      An independent universal connection pool component.
hyperf/process                       v2.0.0      A process component for hyperf.
hyperf/rate-limit                    v2.0.0      A rate limiter implemented for Hyperf or other coroutine framework
hyperf/redis                         v2.0.0      A redis component for hyperf.
hyperf/retry                         v2.0.0      A retry component for hyperf.
hyperf/rpc                           v2.0.0      A rpc basic library for Hyperf.
hyperf/rpc-client                    v2.0.0      An abstract rpc server component for Hyperf.
hyperf/rpc-server                    v2.0.0      An abstract rpc server component for Hyperf.
hyperf/server                        v2.0.0      A base server library for Hyperf.
hyperf/service-governance            v2.0.0      A service governance component for Hyperf.
hyperf/testing                       v2.0.0      Testing for hyperf
hyperf/tracer                        v2.0.0      A open tracing system implemented for Hyperf or other coroutine framework
hyperf/utils                         v2.0.0      A tools package that could help developer solved the problem quickly.

swoole

Swoole => enabled
Author => Swoole Team<EMAIL_ADDRESS>Version => 4.5.2
Built => Jul  2 2020 01:59:24
coroutine => enabled
epoll => enabled
eventfd => enabled
signalfd => enabled
cpu_affinity => enabled
spinlock => enabled
rwlock => enabled
sockets => enabled
openssl => OpenSSL 1.1.1b  26 Feb 2019
http2 => enabled
pcre => enabled
zlib => 1.2.8
mutex_timedlock => enabled
pthread_barrier => enabled
futex => enabled
mysqlnd => enabled
async_redis => enabled

Directive => Local Value => Master Value
swoole.enable_coroutine => On => On
swoole.enable_library => On => On
swoole.enable_preemptive_scheduler => Off => Off
swoole.display_errors => On => On
swoole.use_shortname => Off => Off
swoole.unixsock_buffer_size => 8388608 => 8388608

Description:
同时运行JsonRpc服务端 和 客户端的时候，JsonRpc的异常无法被捕获。
exceptions.php

RateLimitExceptionHandler.php

CalculatorService.php

IndexController.php

OutPut

Steps To Reproduce:

你这个错误是客户端的，而 ExceptionHandler 是面向服务端的，当然捕获不到了


Remove references to archived

Now that we are no longer moving editions into an archived state and we
have updated all archived editions to be in a withdrawn state we should
remove references to archived.

This shouldn't be merged until after the data migration in https://github.com/alphagov/whitehall/pull/2210 has been run.

:+1:


Todoist integration no longer working

OS version: Windows 10 (not relevant I'd say)
Browser version: Chrome 83.0.4103.97
Extension version: 1.60.13

Relevant integration (if any):
https://todoist.com/app
🐛 Describe the bug
The button is no longer appearing in Todoist. They made recent changes, you can find details here 🔗.
If we fix this we should also fix the fact that it was not appearing in the "upcoming" view before, issue #1726

User ID: 5675119
I am also able to reproduce, I can's see it in the task list hovering over tasks, only when I open a specific task view
It's not here:

It is here:

user report


[stable/pgadmin] new helm chart for pgAdmin

What this PR does / why we need it:
Was missing a decent pgadmin helm chart
Special notes for your reviewer:
Created a simple pgadmin helm chart, colleague suggested perhaps get it added to incubator. Apologies if something is incorrect.
Checklist

[x] DCO signed
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/ok-to-test

/retest

please move to stable folder

Done, and updated the appVersion cause it was the default one rather then the version of pgadmin.

@cpanato Is there perhaps something missing, or should something be different?

@cpanato sorry about those commits, need to get used to the signoff.

@rowanruseler no problem you can rebase if you want


added polarhive.ml

Added my website & it's RSS feed to the webring.
The link to the icon is at the <footer> of every page. Let me know if I missed any page.

I'm trying to find your works, but I can't find a single project page on your site, you have a couple of pages on something called codeberg which requires javascript, pictures on pixelfed, which ALSO require javascript, and same for video. The website is lacking documentation that is onsite.


Increasing the connection pool size in case we're using gitlab-ci build

Status
Ready
Related Issues
fixes: https://github.com/demisto/etc/issues/36886
Description
Support a fixed higher number of connections in parallel in case this is a gitlab-ci build.

@avidan-H let's do the change in demisto_client/__init__.py. If we can avoid using the gen-code modifications it is preferred. You will need to update the configure and login methods. You can see there how we use other env vars for configuration.

@glicht is it ok now?


Webpack 2 entry doesn't allow array of object?

I used this and it work in webpack 1
entry: {
	vendor 	: ['react', 'react-dom', 'react-router', 'classnames', 'lodash', 'alt'],
	app 	: ['webpack-dev-server/client?http://localhost:8080',
                'webpack/hot/only-dev-server',
                path.resolve(__dirname, PATHS.app, 'entries', 'app.js')],
         otherFile : ['webpack-dev-server/client?http://localhost:8080',
                'webpack/hot/only-dev-server',
                path.resolve(__dirname, PATHS.app, 'entries', 'otherFile.js')]
}

But this won't work in webpack 2, it worked when I removed the otherFile` property. How do I use HMR and multiple entires? in this guide https://webpack.js.org/guides/hmr-react/ it used array but in my case I'm also using multiple entries.

Hi,
I don't see the landing property you mentioned in your example. How does it fail exactly? Please see the issue template for the information that's needed.

@bebraw updated my question

Ah, I understand better now. Maybe you could drop the HMR related entries altogether and use webpack-dev-server inline mode instead? There are some limitations to that so I guess that's why you avoided it.
It's hard for me to say anything more without extra information. Maybe someone else has more ideas.

@bebraw, I just want to verify webpack 2 has dropped the support for array of object? Because it used to worked in webpack 1.

Any ideas @SpaceK33z? Should the array of objects format work with webpack 2 still?

Yes the format @eldyvoon is using should still work. What exactly do you see / is not working?

@SpaceK33z  I think it's caused by loader issue. I really need need help on this https://github.com/webpack-contrib/extract-text-webpack-plugin/issues/412#issuecomment-280606217


feat(@embark/test-runner): expose evmClientVersion for conditional tests

This commit introduces a new global.evmClientVersion that can be used to
conditionally run tests, such as when tests rely on RPC APIs that are only
available in specific evm nodes.

Thanks for the feedback @jrainville and @michaelsbradleyjr !
I've updated the PR to comply with Jo's comments, in which he made a good point that the connection could change at runtime and therefore needs to be evaluated lazily.

Also CI seems to be failing.

It would be useful to also update the test app tests (or any builtin tests) that specifically use ganache features (like evm_mine) to ensure the tests don't fail unexpectedly

Good point! Updated the PR


Add a -emit-dead-strippable-symbols flag that emits functions/variable/metadata in a dead_strip-friendly way.

Add a -emit-dead-strippable-symbols flag that emits functions/variable/metadata in a dead_strip-friendly way. This enables static linking to remove unused functions and classes even across modules. For now, I'm adding the flag as an opt-in experimental mode, but the goal is to eventually be able to emit symbols this way for everything. This way we could see nice code size savings when e.g. including a lot of package dependencies where not everything is actually used.

What happens if we remove even the llvm.compiler.used annotation?

Updated the PR, added more tests.

What happens if we remove even the llvm.compiler.used annotation?

Good point. I realized it's not needed for this purpose. I originally thought that it might be needed for LTO/ThinLTO, but it turns out it's not needed for that either. I dropped those changes.

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 30fa52b3ab634eb6d6aafb5c93d4e04503caa1ef

@swift-ci please test

@jckarter @airspeedswift any more feedback or this good to go in?

LGTM Kuba.

Hi @kubamracek, thanks for putting up this patch!
We tried building a small swift app with this patch, but it crashed at launch. We then tried building it with both -emit-dead-strippable-symbols and full LTO, the app launched fine. (And it showed a significant size reduction!)
We suspect that at IR level, some symbols/metadata needed across swift modules may have been stripped due to the optimization does not have a link-unit scope view. So what do you think of adding a requirement that only use this flag when full/thin LTO is enabled?

Hi @kubamracek, thanks for putting up this patch!
We tried building a small swift app with this patch, but it crashed at launch. We then tried building it with both -emit-dead-strippable-symbols and full LTO, the app launched fine. (And it showed a significant size reduction!)
We suspect that at IR level, some symbols/metadata needed across swift modules may have been stripped due to the optimization does not have a link-unit scope view. So what do you think of adding a requirement that only use this flag when full/thin LTO is enabled?

@SharonXSharon Do you know what symbols are getting incorrectly stripped? Can we mark them used? Ideally we should always emit code this way and it wouldn't need to be a distinct mode.

@SharonXSharon Do you know what symbols are getting incorrectly stripped? Can we mark them used? Ideally we should always emit code this way and it wouldn't need to be a distinct mode.

@jckarter It looks some function static _DictionaryStorage.resize in libswiftCore.dylib though, according to the crash trace,
Thread 2 Crashed:
0   libswiftCore.dylib            	0x00000001952d24f0 static _DictionaryStorage.resize+ 828656 (original:capacity:move:) + 4
1   theSmallApp        	0x000000010117d940 0x10095c000 + 8526144
2   theSmallApp        	0x000000010117d80c 0x10095c000 + 8525836
3   theSmallApp        	0x000000010117d718 0x10095c000 + 8525592
4   theSmallApp        	0x000000010117b374 0x10095c000 + 8516468
5   theSmallApp        	0x000000010117b290 0x10095c000 + 8516240
6   theSmallApp        	0x0000000100aed770 0x10095c000 + 1644400
7   libdispatch.dylib             	0x0000000191316fd0 _dispatch_call_block_and_release + 32
8   libdispatch.dylib             	0x0000000191318ac8 _dispatch_client_callout + 20
9   libdispatch.dylib             	0x00000001913280d4 _dispatch_lane_concurrent_drain + 892
10  libdispatch.dylib             	0x00000001913207a4 _dispatch_lane_invoke + 520
11  libdispatch.dylib             	0x0000000191329104 _dispatch_root_queue_drain + 356
12  libdispatch.dylib             	0x00000001913298e8 _dispatch_worker_thread2 + 116
13  libsystem_pthread.dylib       	0x00000001d8c748cc _pthread_wqthread + 216
14  libsystem_pthread.dylib       	0x00000001d8c7b77c start_wqthread + 8

@jckarter It looks some function static _DictionaryStorage.resize in libswiftCore.dylib though, according to the crash trace,
Thread 2 Crashed:
0   libswiftCore.dylib            	0x00000001952d24f0 static _DictionaryStorage.resize+ 828656 (original:capacity:move:) + 4
1   theSmallApp        	0x000000010117d940 0x10095c000 + 8526144
2   theSmallApp        	0x000000010117d80c 0x10095c000 + 8525836
3   theSmallApp        	0x000000010117d718 0x10095c000 + 8525592
4   theSmallApp        	0x000000010117b374 0x10095c000 + 8516468
5   theSmallApp        	0x000000010117b290 0x10095c000 + 8516240
6   theSmallApp        	0x0000000100aed770 0x10095c000 + 1644400
7   libdispatch.dylib             	0x0000000191316fd0 _dispatch_call_block_and_release + 32
8   libdispatch.dylib             	0x0000000191318ac8 _dispatch_client_callout + 20
9   libdispatch.dylib             	0x00000001913280d4 _dispatch_lane_concurrent_drain + 892
10  libdispatch.dylib             	0x00000001913207a4 _dispatch_lane_invoke + 520
11  libdispatch.dylib             	0x0000000191329104 _dispatch_root_queue_drain + 356
12  libdispatch.dylib             	0x00000001913298e8 _dispatch_worker_thread2 + 116
13  libsystem_pthread.dylib       	0x00000001d8c748cc _pthread_wqthread + 216
14  libsystem_pthread.dylib       	0x00000001d8c7b77c start_wqthread + 8

@SharonXSharon One debugging option is to dump out the symbols that get changed by this flag, and compare the existence of this set between no fullLTO vs fullLTO.
@jckarter I thought we can't always mark these symbols as unused. These symbols can be unused in this swift module but used in other swift module. If we mark them as unused, the symbols will be stripped off, while they are needed by other swift modules. In the case of fullLTO, we have all the swift modules during fullLTO, so the right set of symbols are kept. This may need Swift LTO or llvm LTO to work?

@SharonXSharon One debugging option is to dump out the symbols that get changed by this flag, and compare the existence of this set between no fullLTO vs fullLTO.
@jckarter I thought we can't always mark these symbols as unused. These symbols can be unused in this swift module but used in other swift module. If we mark them as unused, the symbols will be stripped off, while they are needed by other swift modules. In the case of fullLTO, we have all the swift modules during fullLTO, so the right set of symbols are kept. This may need Swift LTO or llvm LTO to work?

I thought marking things public or open means they will be used across swift modules, does this patch not honor that and it requires extra annotation for symbols used across modules?

I thought marking things public or open means they will be used across swift modules, does this patch not honor that and it requires extra annotation for symbols used across modules?

I am aware of a few problems with this change, and I don't plan on landing this as it is. I think the only way to get this dead-stripping to work correctly is by requiring LTO/ThinLTO and acknowledging that there cannot be any non-visible Swift code using any of the classes/structs/protocols defined in the module.

I am aware of a few problems with this change, and I don't plan on landing this as it is. I think the only way to get this dead-stripping to work correctly is by requiring LTO/ThinLTO and acknowledging that there cannot be any non-visible Swift code using any of the classes/structs/protocols defined in the module.

@kubamracek

I am aware of a few problems with this change

What are the other problems? Do you mean they can all be solved by bundling this flag with LTO/thinLTO?
And is the plan to update this patch by adding some flags configuration to require LTO/thinLTO when -emit-dead-strippable-symbols is present?

@kubamracek

I am aware of a few problems with this change

What are the other problems? Do you mean they can all be solved by bundling this flag with LTO/thinLTO?
And is the plan to update this patch by adding some flags configuration to require LTO/thinLTO when -emit-dead-strippable-symbols is present?

@jckarter I thought we can't always mark these symbols as unused. These symbols can be unused in this swift module but used in other swift module. If we mark them as unused, the symbols will be stripped off, while they are needed by other swift modules. In the case of fullLTO, we have all the swift modules during fullLTO, so the right set of symbols are kept. This may need Swift LTO or llvm LTO to work?

Uses between images should be limited to public and @usableFromInline interfaces. If we're linking a dylib, we'd have to give all those symbols default visibility and assume they're used. We don't want to do that for static libraries, but we ought to be able to dead-strip after a static library is linked into its consuming executable, AFAICS.

@jckarter I thought we can't always mark these symbols as unused. These symbols can be unused in this swift module but used in other swift module. If we mark them as unused, the symbols will be stripped off, while they are needed by other swift modules. In the case of fullLTO, we have all the swift modules during fullLTO, so the right set of symbols are kept. This may need Swift LTO or llvm LTO to work?

Uses between images should be limited to public and @usableFromInline interfaces. If we're linking a dylib, we'd have to give all those symbols default visibility and assume they're used. We don't want to do that for static libraries, but we ought to be able to dead-strip after a static library is linked into its consuming executable, AFAICS.

What are the other problems?

The "live_support" flag is 1) only supported by ld64, so it won't work on Linux, and 2) limited and won't allow dead_stripping of protocol conformances because ld64's behavior treats multiple references from a live_support atom as a "keep live if any reference is alive", but we really want a "keep live if all references are alive" behavior.
My plan is to emit slightly different IR and rely on LTO/ThinLTO and the compiler to do the dead-stripping (in GlobalDCE) instead of the linker.

What are the other problems?

The "live_support" flag is 1) only supported by ld64, so it won't work on Linux, and 2) limited and won't allow dead_stripping of protocol conformances because ld64's behavior treats multiple references from a live_support atom as a "keep live if any reference is alive", but we really want a "keep live if all references are alive" behavior.
My plan is to emit slightly different IR and rely on LTO/ThinLTO and the compiler to do the dead-stripping (in GlobalDCE) instead of the linker.

This change is really desirable for us, are there any updates on next steps or blockers to helping this land?

Abandoning in favor of VFE/WME/CRR/internalization which is now implemented under -experimental-hermetic-seal-at-link flag:

https://github.com/apple/swift/pull/39128
https://github.com/apple/swift/pull/39287
https://github.com/apple/swift/pull/39313
https://github.com/apple/swift/pull/39793


Increase reference count of the stored streams in the IOStream when s…

…ubclassing
We return it transfer-none to the caller so our reference would be
dropped at the end of the scope, and then a second time when the
IOStream is finalized. As such we have to increase the reference count
once to prevent a double-free.

CC @GuillaumeGomez @EPashkin

@sdroege Good catch, thanks, 👍


[Use Case]: JDQL fragments

As a ...

[ ] Application user/user of the configuration itself
[X] API user (application developer)
[ ] SPI user (container or runtime developer)
[ ] Specification implementer

I need to be able to ...
specify JDQL expressions or fragments of JDQL in annotations.
Which enables me to ...
reduce the cognitive dissonance in moving between @Find and @Query.
Additional information
So in thinking through:

the nature of the@By annotation,
the potential for us to grow a whole zoo of similar animals in future (@Like, @IgnoreCase, @In, etc), and
also about my unexpected happiness with how well @OrderBy("name") works, and unhappiness with how ugly @OrderBy(vale="name",descending=true,ignoreCase=true) looks.

I came to the realization that there's a general approach that makes @Find much more flexible, reduces the conceptual gap between @Find and @Query, solves the problem with @OrderBy, and makes the trip to the zoo unnecessary.
[Don't get scared. I'm not proposing to do any of this today, I'm just trying to understand what the future might look like.]
The idea is to have a smaller set of annotations which accept fragments of JDQL. So, for example:
@Find
@OrderBy("lower(title) desc")
@OrderBy("isbn")
List<Book> booksByTitle(Type type, @Where("title like :pattern") String pattern);

which would be assembled to:
@Query("where title like :pattern and type = :type order by lower(title) desc, isbn")
List<Book> booksByTitle(Type type, String pattern);

You might even be able subsume @Where into @By, since it's pretty easy to distinguish a scalar expression with no parameters from a conditional expression with a parameter. And you might allow @OrderBy to accept a list. So:
@Find
@OrderBy("lower(title) desc, isbn")
List<Book> booksByTitle(Type type, @By("title like :pattern") String pattern);

Now, one might look at this particular example, and think "but the @Query version is shorter and perhaps even more readable", and that's true because this is a sort-of "extreme" case in the sense that I have three annotations and only two parameters. But if I had four parameters and just one or two annotations, it would look more attractive.
But that's anyway not the point. The point is to reduce the pressure to add lots of special-purpose annotations, and save the developer from getting into the sort of edit war where they find themselves switching back and forth between @Find and @Query.
To reiterate: @Where("title like :pattern") is more verbose than @Like. But it covers many more cases and is somehow, at least to my way of thinking, a much more elegant approach.
Note that the content of these annotations can still be checked at compile time. JDQL has a very a simple expression language that's easy to parse in an annotation processor.
So we would have:

@By accepting scalar_expression,
@OrderBy accepting orderby_item or perhaps a whole list of them,
@Where accepting conditional_expression except for logical operators, and
possibly @Select accepting select_list or perhaps just a single select item.

By side effect, @By("id(this)") becomes the much more elegant way to write @By(ID).
Everything here looks backward-compatible with what we have today! That said, we could consider adopting this approach for @OrderBy in this release, if we have time.  But it's definitely not critical.

JDQL query fragments are something we can consider in the future. They address a very different use case than,

the potential for us to grow a whole zoo of similar animals in future (@Like, @IgnoreCase, @In, etc), and

The use case for query fragments is similar to @Query where the user is willing to trade off the risk of errors in string values and the need to learn query language for the benefit of being able to write more complex queries.
The use case for making parameter-based automatic query methods on par with Query by Method Name trades off the ability to have more complex queries for the ability to perform basic operations relying purely on API and API JavaDoc without needing to learn any query language or needing to specify string values that are vulnerable to spelling and other errors.
Another way of having JDQL query fragments might be to include then in the @Query annotation itself rather than introducing new annotations for them,
@Query(where = "title like :pattern and type = :type",
              orderBy = "lower(title) desc, isbn")
List<Book> booksByTitle(Type type, String pattern);

Similarly, having what you refer to as an annotation zoo isn't the only option for the annotative pattern.  Another option is for a single annotation, such as @Is, with an enum value to cover everything.  For example,
@By(_Product.name) @Is(Like) String pattern,
@By(_Product.category) @Is(In) List<Category>,

The use case for query fragments is similar to @Query where the user is willing to trade off the risk of errors in string values and the need to learn query language for the benefit of being able to write more complex queries.
[snip] .... without needing to learn any query language or needing to specify string values that are vulnerable to spelling and other errors.

I mean, that really depends.
In my implementation the tradeoff between @Query and @Find is only a matter of verbosity. Errors in JDQL and JPQL query strings are detected at compilation time, including spelling and even typing errors in field names!
Now, OK, that requires some fairly serious machinery, which I spent some time developing a few years ago, and so I just happened to have it lying around when Jakarta Data came along. And so not all implementations are going to have that.   Fine.
But for simpler cases like @By("title like :pattern"), which is really what we're talking about here, any annotation processor should be capable of easily validating that. You don't need my fancy machinery. The expression language of Jakarta Data is really, really simple! You could hand-write a parser for it from scratch in a couple of hours, maybe an hour if you already know what you're doing.
That is to say, @By("title like :pattern") is not much more difficult to validate than  @By("title").
Now, I'm not suggesting we can't have @Like, since that's a really super-common one, and @Like is still less verbose than @By("title like :pattern"), I'm just saying it takes away the pressure for this to grow into a whole zoo of these things.

Another way of having JDQL query fragments might be to include then in the @Query annotation itself rather than introducing new annotations for them

Well that wouldn't let me mix JDQL fragments into a @Find method, which is the essential point of this proposal. And it would leave me stuck with @OrderBy(vale="name",descending=true,ignoreCase=true) when I'm writing a @Find method.
What I'm looking for is the ability to mix bits of JDQL into a @Find method. When I'm using @Query, I don't need to break up the query into fragments, and, in fact, it's less readable that way.

Another option is for a single annotation, such as @Is, with an enum value to cover everything. For example,
@By(_Product.name) @Is(Like) String pattern,
@By(_Product.category) @Is(In) List<Category> categories,

This isn't awful; I quite like it, actually. Nice idea!
But on the other hand it sorta undermines the main value of @Find from my point of view which is: (a) its extreme simplicity and (b) its lack of verbosity—and (c) the fact that in the upcoming release of IntelliJ, the IDE will autocomplete it for me. In fact, it's actually slightly more verbose, and a bit harder to type than:
@By("name like :pattern") String pattern,
@By("category in :categories") List<Category> categories,

So, y'know, I'm just not sure I'm sold on the idea of implementing an expression language in annotations.

So I've spent some more time reflecting on this last night and this morning, going back to first principles of what I originally liked about the @Find approach, and what I think is its sweet spot is compared to JDQL.
When I first implemented @Find methods in Hibernate, it was pretty clear that you might want to have some way to "adjust" the matching on a per-parameter basis, but that immediately opened up the question of where to draw the line.
I was pretty sure I didn't want to try implementing a whole expression language in annotations. I didn't and still don't want to open the door to the whole open-ended hog of @Contains, @StartsWith, @EndsWith, @LessThan, @LessThanEqual, @GreaterThan, @GreaterThanEqual, @Like, @In, @IgnoreCase, @MemberOf, etc, etc. You might wonder why not, and I guess the answer is simply that I don't think Java Annotations are a good language for writing expressions in. Even the above list of ten (!) annotations still covers only a tiny fraction of what's possible in JDQL, let alone JPQL.
On the other hand, it was also pretty clear early on that there was going to be lots of pressure to handle pattern matching (i.e. @Like) and probably also some sort of in condition (i.e. @In). Those things are just really common. But I held off on adding them because it just seemed to open a door I didn't want to open.
But now after a lot of reflection on this, I've realized that there's a perfectly reasonable "ideology" which lets me address those two cases without opening any doors I don't want to open. It's this:
@Find
Book[] booksByIsbn(String[] isbn);

@Find
List<Book> booksByTitle(@Pattern String title);

Notice that there are no "operators" here. In the first case, the type alone requires that this be interpreted as an in condition, and in the second case, an annotation describing the semantics of the string itself, @Pattern, requires that matching is via like. From the right perspective, you can view @Pattern as part of the type declaration.
And that's consistent with the original philosophy that @Find methods are interpreted on the basis of the names and types of their parameters. No need to introduce the notion of an "operator annotation". That's exactly what I was looking for!
So what happens if I do need >? Well, then use JDQL, because it's actually good at expressing these sorts of things via a much more natural syntax than @GreaterThan. And so we arrive at the idea to allow fragments of JDQL to be combined with @Find. I really think that this is the right way forward. With just one or two (rather than ten) new annotations,  we can let you easily express stuff as complicated as or even more complicated than:
@Find @Where("deleted = false")
Book[] booksByIsbn(String[] isbn);

@Find @Where("deleted = false")
@OrderBy("title, isbn desc")
List<Book> longBooks(@By("pages > ?1") int minPages,
                     @By("left(locale, 2) = lower(?2)") String language
                     @Pattern String topic)

That is to say, we can express things which will just never be elegant or even possible using "operator annotations". Now, are these examples obviously better than just writing:
@Query("where deleted = false and isbn in ?1")
Book[] booksByIsbn(String[] isbn);

@Query("where "pages > ?1 and left(locale, 2) = lower(?2) and topic like ?3"
       + " and deleted = false"
       + " order by title, isbn desc")
List<Book> longBooks(int minPages,
                     String language
                     String topic)

I dunno, I think you could argue that they are slight better, though it's clearly a matter of taste. But what I like above all else is that it unifies @Query and @Find in a pleasing way.
I understand that this looks superficially less typesafe than the "operator annotations". But what I've seen is that it really doesn't need to be. It really is quite straightforward to typecheck these kinds of fragments in an annotation processor. I have been taken a bit by surprise by how well this approach works in practice.
On the other hand, if you're lucky enough to have IntelliJ Ultimate, IntelliJ now does a fantastic job of highlighting/validating/autocompleting JPQL embedded in annotations. Of course, IntelliJ doesn't understand the Jakarta Data annotations yet, it only understands the similar annotations in Hibernate. But the guys working on this stuff have been extremely responsive to my requests in this area, so I expect they'll jump on Jakarta Data. They already have the machinery they need.
I also understand that the reasoning here is maybe a bit hard to digest at first. I'm not suggesting that there's something deeply broken about @GreaterThan. What I'm saying is that it's a sort of dead end that takes you much less interesting places.


pygit2 LFSFilter not working

Hi, I have a simple python project which depends on
pygit2==1.15.0
scmrepo==3.3.5

import pygit2
import scmrepo.git.backend.pygit2.filter

# The default priority is GIT_FILTER_DRIVER_PRIORITY=200
# https://github.com/libgit2/libgit2/blob/main/include/git2/sys/filter.h#L42-L47
pygit2.filter_register('lfs', scmrepo.git.backend.pygit2.filter.LFSFilter)

# Do the pygit2 clone job
# repo_url = '...' # This is a repository with LFS
# repo_dir = '...'
# repo = pygit2.clone_repository(repo_url, repo_dir)

But after I cloned the git repo, I found those git LFS files are still plain git LFS object text files.
Just like:
version https://git-lfs.github.com/spec/v1
oid sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
size 119954

It indicates that the git LFS filters are not working or effective, does anyone can help with this?
cc @pmrowla
FYI, the git repo is a private git repository from github.com, cloned using the ssh protocol.

AFAIK, you have to call fetch() yourself.
https://github.com/iterative/scmrepo/blob/f9bb897ba5b9aff8aa5bd480c72f7d1cef0561b1/src/scmrepo/git/lfs/fetch.py#L18
Also, note that the scmrepo is a lower-level library for dvc. The purpose of this library was to abstract different git implementations so that we can use different features that are not implemented in one library vs other (and, improve performance).
We do not support the use of internals, however you may use at your own risk.

The LFS filter only implements the low level LFS smudge behavior. It is not a complete LFS client, and does not add anything to the pygit2/libgit2 clone/fetch/pull behavior. The pygit2 LFS filter will only work as expected when the required LFS objects are available in LFS storage (meaning they need to be explicitly fetched before doing a pygit2/libgit2 checkout). You are not seeing the LFS files in your cloned repo because the LFS objects have not been fetched into LFS storage.
If you are trying to use pygit2 directly (without anything else from scmrepo) you can re-use this LFS filter for handling the smudge behavior upon libgit2 checkout or when reading from the ODB. However, you will still need to implement the LFS client + fetch logic yourself.

scmrepo includes parts of what you are looking for, but as @skshetry noted, scmrepo is mainly intended to be used in DVC. As a result, the LFS client behavior for modifying your working directory is mostly not implemented here (since DVC reads directly from the git index when dealing with LFS files and does not care about the working directory at all). You can approximate what you are looking for with scmrepo and pygit2, but it will be somewhat convoluted for these reasons.
I think something along these lines would work, but this is not tested and you will probably need to tweak things
from scmrepo.git import git
from scmrepo.git.lfs import fetch as lfs_fetch

# clone the repo
scm = Git.clone(repo_url, repo_dir)

# fetch LFS objects for HEAD (and only HEAD), if you need LFS objects for other commits
# you need to explicitly fetch them (see the docstrings for `scmrepo.git.lfs.fetch`)
lfs_fetch(scm)

# remove old checkout of LFS pointer files, you will need to do this for all of your LFS files
os.remove("some_file")

# re-run pygit2 checkout to use the correct fetched LFS objects instead of pointer files
#
# note that scm.checkout() is insufficient here because it may opt for using a non-pygit2
# git backend
scm.pygit2.repo.checkout("HEAD")


Ambiguous Handling of Duplicate Properties

Issue Overview
for Langium version: 0.3.0 dev (post named cross-ref fix, #485 )
While looking into another Langium issue about duplicate properties in a hierarchy, I came across some strange behavior with duplicate properties. Take for the example the following rule:
X: prop=ID prop=ID

This shows no diagnostic, and successfully produces the following interface.
export interface X extends AstNode {
    prop: string
}

It appears that duplicate properties in a rule are implicitly rolled together into a single property of that type. That then begs the question, what about different types?
X: prop=ID prop=NUMBER;

generates...
export interface X extends AstNode {
    prop: number | string
}

Which seems to support the prior observation. And upon further checking it can be seen that something like X: prop=(ID | NUMBER) generates the equivalent interface in the AST.
However, this implicit unioning breaks down in special cases, such as for named cross refs. Consider the following recursive definition.
X: name=[X];

This can't be resolved as expected, and neither can an explicit union of this with a terminal of another type.
X: name=(ID | [X]);

Based on our observations before, we should expect that at least the implicit type unioning performed for duplicate properties should behave similarly. However, in practice, it does not.
X: name=ID name=[X]

generates...
export interface X extends AstNode {
    name: Reference<X> | number
}

Order matters in this context, as writing X: name=[X] name=ID will not work, same as the previously observed behavior.
Lastly, in the case of any other property name, cross-references to the the same rule do not work, even when unioned (explicitly or in this implicit case).
I suspect this is due to some special handling with the name property, and the way that inferred types are constructed.
The expected behavior
Ideally, this behavior should be consistent regardless of the property name. Whether implicit unioning of duplicate types is desired, or not, it would be nice to enforce this. Additionally, order of special duplicate properties (like name) should not impact whether a type can be generated or not.
We could potentially resolve this by dropping named cross refs as a supported feature. In the current 0.3.0 release named cross refs don't work anyways, so perhaps this is a good way to proceed.
Also, we could disallow duplicate properties from being allowed, instead suggesting they be written as unions. But I'm not sure whether there is an established usage of this in any prior work.

There are separate issues here:

Multiple assignments to the same property (prop=ID prop=ID) should be marked with a warning because the value of the first assignment would be overwritten. This does not apply in alternatives (prop=ID ... | prop=ID ...), so we need to check every possible path inside a rule.
I'd vote for disallowing the assignment of incompatible types to the same property when the type is inferred. This means we should never generate alternatives in property types (prop: number | string). Rationale: In most cases, I'd expect this to be unintended and thus an error. If you really want alternative types, either infer separate properties (propA=ID propB=NUMBER) or declare the type explicitly.

I think we should disallow multiple assignments to the same property. We should have a clear and focused interface for the user. Adding to many options or sugar complicates the project.

On that issue, for now it is also possible to assign a cross-reference and a DataType string rule to the same property. It results in an unexpected type in the AST:
A: value=([B:ID] | C)

B: name=ID;

C returns string: 'valueC' | 'otherValueC';

It generates:
interface C {
    value: Reference<B | string>
}

As mentioned by others, it should be forbidden to assign a cross-reference and a string to the same property

I believe we can close this. We have added a lot of validations in the meantime that solve a lot of these issues. If specific problem are still relevant, we should create more specific, new issues for those.


Small fixes: Remove empty files, fix comment, update footer to 2017

Remove api/api.php (empty file)
Remove api/config.php (empty file)
Fix comment in src/routes/asset.php#L287 to say "Undelete" instead of "Delete"
Upate footer to 2017 :)

Looks good, merging...


Update codecov and CI status badge

Codecov and CI status badge on README.md links to the AddressBook Level 3's repository.
Updated both badges to link to Harmonia's repository.

Codecov Report

Merging #89 (ed36399) into master (791c439) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #89   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

Continue to review full report at Codecov.

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


Fix #370 - implement proper ER-mode comparison for floating point types

Fixes #370. Root cause was that GenericComparisonFast did not have an accurate implementation of ER-mode floating point comparison.  Testing showed that nonstructural compare had the same issue.
The added compre tests here should cover the code well enough, but I'm also planning to add some actual floating-point sorting tests to the core unittests.

I merged you changes into #372 and our sorting tests become green ;-)

:+1: This is fantastic!  I had no clue how to get around NaNs when doing the SortBy, turns out I was only about 2 levels of abstractions away from enlightenment.

Nice work - great fix, great testing.

Looks great


ipfs mount not working

ipfs version 0.4.17
01:03:34.453 ERROR       node: error mounting: fusermount: exit status 1 mount_unix.go:89
01:03:34.454 ERROR       node: error mounting: root can't be a file (unixfs type: File) mount_unix.go:93

Hey thank you for reporting this, but  this is not a correct repository :)
The error is already tracked in https://github.com/ipfs/go-ipfs/issues/3772

Thanks Marcin, will followup sorry about confusion.
On Sun, Oct 28, 2018 at 9:36 AM Marcin Rataj<EMAIL_ADDRESS>wrote:

Hey thank you for reporting this, but this is not a correct repository :)
The error is already tracked in ipfs/go-ipfs#3772
https://github.com/ipfs/go-ipfs/issues/3772
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ipfs-shipyard/ipfs-webui/issues/873#issuecomment-433720933,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGvTDQwmlbxFFovDDp9DGJoMjT1N9bPnks5upd0VgaJpZM4X91uI
.

--
CONFIDENTIALITY NOTICE:   This communication constitutes an electronic
communication within the meaning of the Electronic Communications Act, 18
USC 2510 and any files transmitted with it may contain PRIVILEGED or
CONFIDENTIAL information and may be read or used only by the intended
recipient named above, snooping while an email is in "real-time"
transmission between sender  and receiver is a federal crime under the
Electronic Communications Protection Act (ECPA), 18 U.S.C.A § 2517 (4)-18
U.S.C.A 27 Chapter 121 (2701-2712) and U.S. Code § 2511 - Interception and
disclosure of wire,oral, or electronic communications prohibited. The
contents may contain Technical Data that is controlled by the ITAR, 22CFR
parts 120 to 130, or EAR, 15CFR parts 730 to 772, and therefore should not
be disclosed to a non-U.S. person, or entity, in the U.S. or abroad. If you
are not the intended recipient of the email or any of its attachments,
please be advised  that you have received this email in error and that any
use, dissemination, distribution, forwarding, printing, reverse
engineering, editing or copying of this email or any attached files is
strictly prohibited. If you have received this email in error, please
immediately purge, delete, erase it and all attachments and notify the
sender by reply email or contact the sender at the number listed above if
one is provided. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. This email has been scanned for
virus,trojans and malicious software for safety using Google virus scanner
and security scanner before it was sent, and are not the responsiblity of
the sender of this email.


[Microsoft Graph Toolkit playground]: Ensures ARIA attributes are allowed for an element role.

Test Environment:
OS version: 22H2 (Build 25309.1000)
Browser: Edge Dev (Version 111.0.1661.27 (Official build) dev (64-bit))
URL: https://developer.microsoft.com/en-us/graph/graph-explorer
Tool: Accessibility Insights for web.
Repro Steps:

Open the above URL in edge dev browser.
Run the fast pass of Accessibility Insights for web.
Observe the issue.

Actual Result:
ARIA attribute is not allowedi.e aria-expanded="true". ARIA attributes are not allowed for an element (Get started button.) role.
Expected Result:
Ensures ARIA attributes are allowed for an element (Get started button.) role.
How to fix:
Fix the following:
ARIA attribute is not allowed: aria-expanded="true"
Notes:
Same issue is repro'ing throughout the webpage.
User Impact:
Screen reader user will get impacted as user will not be able to know the purpose which create difficulty in interacting with the content.
MAS Reference link:
https://microsoft.sharepoint.com/:w:/s/accessibility/EZBde1C58eFKkdEvHy1sfB0BbfrE-sgqsVO5g2zVY6wbDA?e=jEWXd4
“Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com) “

@adhiambovivian adding this accessibility issue to the current milestone

The fluent team provides an explanation for this here https://github.com/microsoft/fluentui/issues/26694

@vaishali1397 Graph Explorer team is closing this ticket because it's a dependency with fluent-ui and fluent-ui board as per https://github.com/microsoft/fluentui/issues/26694 will not be resolving this issue.


Custom tridents in minecraft 1.15+

Currently, custom tridents are unavailable for minecraft 1.15 and later minecraft versions due to a resourcepack bug introduced in the minecraft 1.15 client. I don't think there is a way around this.
See: https://bugs.mojang.com/browse/MC-166072

This will be fixed in KCI 13.6


Add community post

The post explains OAuth 2.0 & OpenID Connect basic concepts and how IdentityServer can be used to integrate them in .NET Core applications. It has also an associated GitHub repository.
Thanks!

Thanks!


[Bug] Ensure remote codec used for all payloads in and out

Describe the bug
When setting --codec-endpoint it appears to set a custom data converter globally for a few uses, but we need to make sure it's used for all input and ouput payloads (that are not search attributes)

Also related: https://github.com/temporalio/cli/issues/22

User reports JSON not getting decoded in:
temporal workflow show --codec-endpoint=[endpoint] --output=json

(will also be implicitly solved by #415 and CLI rework btw)


what is iceworm?

The README is lacking, but I'm amused that there are so many implementations and backends. What is this?

I've just taken a look at it and too am amused and at the same time intrigued to find out.

I've just taken a look at it and too am amused and at the same time intrigued to find out.


Create Button Component

Use #7 to create a reusable button component with at least 2 types, round and square.

Button is done!


LUCENE-9869 allow for configuring a custom cache purge scheduler in Monitor (aka Luwak)

Description
By default org.apache.lucene.monitor.Monitor will create a new thread per instance
in order to schedule its cache purge periodic task. This is not always the desired
behaviour as for example one could create a large number of Monitor instances in a
single JVM to separate business domains. In such case it would be counterproductive
to create a new thread for each instance of Monitor. Instead through introduction
of PurgeScheduler interface one can now implement its own scheduling strategy.
Solution
Introduced a new method to MonitorConfiguration that allows to provide a custom
implementation of PurgeScheduler.
Tests
Used this new API in an external codebase to confirm its proper behaviour and usefulness.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Lucene maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[x] I have run ./gradlew check.
[x] I have added tests for my changes.

@romseygeek @uschindler can you have a look at this PR. Do you think it is a move in a right direction? How can I improve it so it can be merged?

This sounds reasonable to me @pawel-bugalski-dynatrace but I'm not familiar with Monitor/Luwak's code.  It looks like there are conflicts -- is this PR still relevant?  Thanks @pawel-bugalski-dynatrace!


Show inlay hints on current line, or selection

Inlay hints are awesome, and have lots of settings aready, but need more control over which ones are shown.
I would like to be able use a command to toggle inlay hints for the current line, or selection.
Somewhat related:
vscode-twoslash extension allows you to create inlay hints with a // ^? comment. I've asked for an inline option:  https://github.com/orta/vscode-twoslash-queries/issues/8
Toggle inlay hints on/off key - https://github.com/microsoft/vscode/issues/149019

In the case of parameters, it would be amazing if there an option to show only when the cursor is within the funcion name or parameters, otherwise it is hidden.