text:
[red-knot] Improve validation for search paths

Summary
This PR cleans up the settings validation and types in the module resolver. Namely:

Currently we validate that a ModuleResolutionPathBuf has either no extension, a .pyi extension or a .py extension. But for search paths specifically (which are the only module-resolution paths that are ever directly constructed), that's the wrong kind of validation for us to do: we should just validate that the path points to a directory.
For custom typeshed directories, validate that a <typeshed>/stdlib/ directory exists, that a <typeshed>/stdlib/VERSIONS file exists, and that the VERSIONS file parses.

Test Plan
cargo test -p red-knot_module_resolver. I haven't added any new tests specifically as part of this PR, but I'm happy to if you'd find them useful, either as this PR or as a followup.

I think it would ease reviewing if the validation change and the structure change aren't in the same PR. Or is there a specific reason why you put both changes into one PR?

I think it would ease reviewing if the validation change and the structure change aren't in the same PR. Or is there a specific reason why you put both changes into one PR?

I started off only doing the validation changes, but then I realised that really there were different invariants for module-search paths as opposed to module-resolution paths in general, and so improving the validation didn't really make sense while they were still being represented by one type. But I can certainly split it into two PRs.

I've extracted the structure change into its own PR: https://github.com/astral-sh/ruff/pull/12379.

Following the changes made in https://github.com/astral-sh/ruff/commit/2a8f95c437d64fdd9b2d512ac065288d775aabfb, this PR is now solely focussed on improving validation for search-path settings.

I like the validation code but I don't think the "all settings must be valid or we don't use any of the provided settings" provides the best user experience. It means the CLI will fail to start and so will the LSP.

I think this is somewhere where we might want different behaviour depending on whether redknot is being run as a CLI tool or as an LSP server.
As an LSP server, I can see that it makes sense to try to recover as much as possible, as the user may be in the middle of editing their workspace settings -- and even if they're not, it's annoying if redknot completely gives up from linting all your code because of a small typo in your workspace settings.
As a CLI tool, I think the tradeoff is pretty different. Something I've really liked about Ruff in the past is how strictly it validates the settings passed to it. It means that there's no ambiguity, and no chance of Ruff silently doing the wrong thing. This is especially important, in my view, for a tool that applies autofixes to your code -- moreover, it's a tool that many people have installed as a pre-commit hook, which means it'll automatically apply autofixes as part of every commit.

I agree on that assessment. But that still means that the infrastructure has to handle it gracefully for the LSP case. The CLI will want to call some function that tells it if the settings are correct.

I agree there's lots of design work still to be done here regarding error handling and settings resolution. It wasn't really my intent to solve that problem in this PR; I just really wanted to make the validation we were already doing make some kind of sense, and to add some proper error messages for it rather than simply having the module resolver call .unwrap() on an Option value.
@MichaReiser, what's your specific concern with the changes this PR is making? It's already the case on main that we panic in the module resolver as soon as we find a single search path that we consider to be invalid; this PR doesn't change anything in that regard. Should I add some more TODOs around the system calls in path.rs saying that we'll need to revisit them if we end up deciding to do settings resolution inside Salsa?
I can think of lots of possible ideas for solving the bigger questions you're posing here, but I'm not sure any of them are in the scope of this PR.

authors: AlexWaygood MichaReiser


text:
[ruff] Unformatted special comments (RUF037)

Summary
Resolves #10160.
Test Plan
cargo nextest run and cargo insta test.

@AlexWaygood do you have any recommendations on the rule's scope?

I agree that we're getting into very hairy territory if we start formatting other tools' pragma comments by default. However, it does seem useful to have a rule that does generalised formatting of pragma comments.
I like @MichaReiser's second suggestion in https://github.com/astral-sh/ruff/pull/14111#pullrequestreview-2427244566 -- I would suggest a rule

That is not in the RUF1XX category (which as @MichaReiser says is a category specifically for Ruff pragma comments)
That by default, only formats Ruff pragma comments. (And maybe also type: ignore comments, since they are standardised across tools according to a specification?)
That can be configured so that it also includes other tool-specific pragma comments such as pyright: ignore, isort: skip_file and pragma: nocover

Currently the rule is handling (aside from # type) # noqa, # ruff: noqa, # flake8: noqa, # isort, # ruff: isort and # fmt. Aren't these all comments that Ruff reads?

They are! I wasn't necessarily criticising anything you were doing -- was just giving my response to Micha's request in https://github.com/astral-sh/ruff/pull/14111#issuecomment-2470227442 on what the scope of the rule should be :-)

I'm in favor of limiting this rule to just Ruff comments, as I have already rewritten this PR a couple of times and I don't feel like redoing it all over again. I'll give custom comments their own rule in another PR.

Feel free to keep this PR small and not implement any configurability now. Small, incremental PRs are definitely encouraged! However, if you want to open a followup PR, please make this rule configurable in the followup PR rather than creating a separate rule just for custom comments. I think Micha and I are aligned that a single, configurable rule would be preferable to two rules that do very similar things.

I do think that we can drastically simplify the implementation because we no longer need to special case different comments. All we need is to match for # (fmt|noqa|...) and then see if it has an optional : following it.

The problem I see with special casing is that it isn't a good fit for a general-purpose, extensible rule; it should instead be a specific rule for noqa.
The question is if we can come up with some general rules that work for all suppression comments without being specific to any pragma comment and that allows easy configuration:

Require a space between # and name in # `
Require no space left of a : but require a space right of it: # name: ignore ok, # name:ignore not-ok
Require no a space left of a , but require a space right of it: # type: ignore[a, b] is ok, type: ignore[a,b] isn't
Require no space around [ but require a space right of ] if it isn't the end of the comment.

The rule doesn't require that any suppression comment is valid. E.g. it accepts #type: ignore, a, b, cd t
Note: What's interesting is that e.g. pyright's documentation uses a space before [: # pyright: ignore [reportPrivateUsage, reportGeneralTypeIssues] whereas mypy recommends using no-space # type: ignore[<code>] (which I prefer)

A general purpose rule that handles all kinds of pragma comments. It only enforces a single space between # and the keyword and, optionally, that the colon is followed by a space. We can add a configuration option to support custom pragma codes.

Making this rule extensible is also what I've suggesting in https://github.com/astral-sh/ruff/issues/10160#issuecomment-1971452721 . Even if it comes as a follow-up PR, I'd like if it could handle comments that Ruff doesn't need to be aware of (like pyright)

source: gharchive/pull-request

authors: AlexWaygood Avasam InSyncWithFoo MichaReiser

repo: astral-sh/ruff

license: MIT

license_type: permissive

license_source: github-api


text:
[red-knot] Rename and rework the CoreStdlibModule enum

Summary
This PR does several things:

Renames the CoreStdlibModule enum to KnownModule, since it is a parallel enum to KnownClass, KnownFunction and KnownInstanceType
Moves the enum from stdlib.rs to module_resolver::module.rs. This allows it to be stored as a field on ModuleInner objects, and retrieved using a getter method from Module objects. This in turn means that we can then add known() and is_known() methods to the Module struct, which allows us to query whether a given Module represents a known module in much the same way we already do using FunctionType::is_known and Class::is_known.

These changes have several goals:

Unify the API of the various Known* enums
Put in one place the code required to check whether a Module really represents a specific module from the standard library. We had the same checks written out in several places, which was error-prone, since there are several things that needed to be checked and some are quite subtle. (One recent example: https://github.com/astral-sh/ruff/pull/15019#discussion_r1892793699.)
Make our API less stringly typed, and therefore less error-prone (the changes in definition.rs are an example)
Exploit some micro-optimisation opportunities in a few places

Test Plan
cargo test -p red_knot_python_semantic. No new tests added -- this should be a pure refactor.

1% speedup on the incremental benchmark... who knows if that's real, but certainly better than a slowdown whatever the case 😆 https://codspeed.io/astral-sh/ruff/branches/alex%2Fknown-module


text:
feat(sequencer): update sequencer API to contain methods required by conductor/relayer

Summary
update sequencer API to contain methods required by conductor/relayer
Background
ideally conductor/relayer only need the sequencer gRPC API endpoint, not the cometbft one as well. this also allows us to eventually have the sequencer API be a full proxy of all the cometbft endpoints.
Changes

implement get_chain_id, get_abci_info, get_commit and get_validators in the sequencer gRPC service
update sequencer to know the cometbft rpc addr, as it uses the cometbft JSON-RPC API to fetch commit/validators for get_commit and get_validators respectively. it needs this as it doesn't store the commit or full validator info in its own state

Testing
manual testing so far - unit tests/blackbox tests would require a cometbft endpoint or mock cometbft JSON-RPC server
Related Issues
closes #957

High level feedback on the quasi-cometbft RPCs here (namely get_chain_id, get_abci_info, get_commit and get_validators): I think we should have a distinct gRPC services that resemble those provided by cometbft. For example, for ABCI they are defined here: https://github.com/cometbft/cometbft/blob/main/proto/cometbft/abci/v1/service.proto
We don't need to support all of them for now, only the subset needed. But because we are in that ecosystem (and following the principle of least surprise), it makes sense to just follow their example.

closing due to staleness, but we should probably do this

authors: SuperFluffy noot

repo: astriaorg/astria


text:
feat(proto, core, sequencer)!: permit bech32 compatible addresses

Summary
Enables bech32 compatible addresses when necessary.
Background
Some IBC enabled chains enforce that ics20 transfer packets must contain bech32 compatible only (see https://github.com/astriaorg/astria/issues/1407 for more background). This patch adds a ibc_compat prefix to sequencer's genesis and a new field bool Ics20Withdrawal.use_compat_address to the withdrawal action to request a bech32 compatible address format when interacting with such chains.
Changes

Add field astria.protocol.transactions.v1alpha1.Ics20Withdrawal.use_compat_address
Add field astria.protocol.genesis.v1alpha1.AddressPrefixes.ibc_compat
Rewrite the Address domain type to be generic over the format; this allows bech32 and bech32m addresses when parsing and formatting

Note that all Astria domain types containing addresses now require Address<Bech32m> with Bech32m also being set as the default type is the parameter is absent

this now enforces that all Astria addresses in Astria's domain types must be bech32m compatible (this was not enforced before because bech32::decode does not enforce either checksum as of bech32@v0.11).
When executing an astria.protocol.transactions.v1alpha1.Ics20Withdrawal with field use_compat_address == true, sequencer will now construct a bech32 compatible address using the value stored at prefixes/ibc-compat in its state.
When refunding a rollup due to a failed withdrawal, sequencer will now attempt to parse the sender as either a standard (non-compat) bech32m address, or a compat bech32 address.
If a compat bech32 address was found during a refund, sequencer will convert it to a bech32m address with its base prefix for further processing. This ensures that the compat addresses are only ever constructed for outgoing and incoming fungible token packets.

Testing

Updated sequencer tests for ics20 refunds for both compat and base/non-compat senders.
Updated all snapshot tests
Added a snapshot test for Address<Bech32>
Added unit tests for address parsing (to ensure that bech32 addresses cannot be parsaed as bech32m and vice versa)
Updated chart sequencer genesis to run smoke tests
IBC tests for noble are still work in progress and outside the scope of this PR.

Breaking Changelist

Sequencer gained a new genesis value (the ibc compat prefix), changing the app hash

Related Issues
Closes https://github.com/astriaorg/astria/issues/1407

Squashed and rebased ontop of recent main because of merge conflicts.


text:
Update lib_statistics.f90

function mean: When mask'ed, divide by count(mask) instead of size(x)
function variance: When mask'ed, divide by count(mask) instead of size(x). Also a bug: variance = sum((x-mean(x))**2), was sum(x-mean(x)**2).

@eev2 - thanks for the fixes! Will try and review and test this this week :)

repo: astrofrog/fortranlib

license_source: bigquery


text:
Set producer compression type to zstd

Zstd compression adds minimal CPU overhead but saves bandwidth. It's a win-win. GCN is experimenting with adopting zstd compression.

I think this is a good default (I'm a big fan of Zstd myself), but if we're going to touch this we should probably make it configurable in case power users need to change it?

Good idea. Please take a look.

authors: cnweaver lpsinger

repo: astronomy-commons/adc-streaming


text:
Update changelog and whats new for v0.8.2

Update docs for the 0.8.2 release

This PR also modifies wheels.yml to verify successful generation of a pre-release build wheel.

repo: astropy/halotools


text:
Typo in match for websocket protocol

The match arms appear to be reversed in this code:
https://github.com/async-graphql/async-graphql/blob/906499b9089b4732af62e272847bff6cff6cc945/src/http/websocket.rs#L322-L328
Presumably, the header-value graphql-ws should be parsed as Protocols::GraphQLWS.

Nevermind, apparently the projects subprotocol names are just super confusing...
The older subscriptions-transport-ws project appears to use graphql-ws as its subprotocol header: https://github.com/apollographql/subscriptions-transport-ws/issues/647#issuecomment-570255976
And the newer graphql-ws project does indeed appear to use graphql-transport-ws as its subprotocol/header value: https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md#communication
Why they ended up picking names that seem to match the competitor repo more than their own repo is beyond me, but it looks like that's how things are.

haha, indeed!

source: gharchive/issue

repo: async-graphql/async-graphql


text:
Accessing context within subscriptions

Thanks again for the great library and the fast response to my question yesterday! I now have a similar question around subscriptions. How do we pass data into the GraphQL resolver for a subscription? Here is pseudocode for what I would like to do:
pub async fn index_ws(
    schema: web::Data<MySchema>,
    req: HttpRequest,
    payload: web::Payload,
    session: Session,
    db: web::Data<database::Database>
) -> Result<HttpResponse> {
    let user: Option<User> = user_from_session(db.users.clone(), db.sessions.clone(), session).await;
    // something like ".data(...)" to extend context does not seem to exist
    ws::start_with_protocols(WSSubscription::new(&schema).data(user), &["graphql-ws"], &req, payload)
}

And then:
#[async_graphql::Subscription]
impl SubscriptionRoot {
    #[field]
    async fn mydata(&self, ctx: &Context<'_>, mutation_type: Option<MutationType>) -> impl Stream<Item = DataChanged> {
        let current_user = ctx.data::<Option<User>>();
        // logic here, for example use current_user.id to filter a stream ...
    }
}

Is this possible? I reviewed the subscription example and didn't see anything. Looking over the implementation of the library, I also didn't see any way to add additional data to a subscription context, or access the context.

I'm adding this feature.😃

Adding this feature took a little longer than I expected. 😁
async-graphql upgrade to  1.9.16.
async-graphql-actix-web upgrade to 1.1.5 if you use actix-web.
async-graphql-warp upgrade to 1.1.5 if you use warp.
Example: https://github.com/sunli829/async-graphql-examples/blob/2337bcbbcb5bedb3cc2f3ebdb8f71cb6ba88f768/actix-web/token-from-header/src/main.rs#L57
You can test it in GraphQL playground.
The token for the GraphQL subscription is sent by payload of the websocket protocol
Set the following values into GraphQL playground HTTP Headers.
{
  "token": "123456"
}

This is the actual subscription request sent through the websocket.
{"type":"connection_init","payload":{"token":"123456"}}

Just in case anyone scratches their head like I did while trying to figure out how to embed the ctx into the stream.
Here is how I solved it using zip and repeat:
#[field]
async fn my_handler(&self, ctx: &Context<'_>) -> impl Stream<Item = MyEvent> {
    let repo = ctx.data::<BoxedRepository>();
    self.channel
        .subscribe()
        .zip(futures::stream::repeat(repo.clone()))
        .filter_map(|(_evt, _repo)| async move {
            //do something with repo like fetching data per event...
            None
        })
}

Maybe you can try ‘Async-stream’.

It does not seem to fix the problem that I cannot prove that the stream does not outlive the Context because the returned stream has a 'static lifetime and &Context does not.

Awesome work with the fast update! Just to give my current status, I also ran into an issue using my async DB representation within the stream:
#[async_graphql::Subscription]
impl SubscriptionRoot {
    #[field]
    async fn messages(&self, ctx: &Context<'_>, mutation_type: Option<MutationType>) -> impl Stream<Item = MessageChanged> {
        let convo_db = ctx.data::<Database>().conversations.clone();
        SimpleBroker::<MessageChanged>::subscribe().filter(move |event| {
            let convos = convo_db.get_all().await;
            // logic here...
            async move { res }
        })
    }
}

And await is not allowed, as it is not an async block.
Will see if this can be solved with async-stream. I imagine that many people would be interacting with context that presents async APIs, so maybe SimpleBroker should produce an async-compatible stream by default?

I think this boils down to the same issue I was having.
What do you mean by async-compatible?
I think it would be nice to be able to get a clone of the context with every event. Something like this:
SimpleBroker::<MyEvent>::subscribe_with_ctx().map(|(evt, ctx)| async move { evt })

Should be easy to implement and simplify client code. Are there better solutions? What do you think?

@nicolaiunrein my Rust is not super strong, but I think there are two different problems here. One is the lifetime issue, giving whatever you want to pass into the stream a 'static lifetime. I also ran into this issue but in my case was able to solve it by wrapping the data I wanted to share in Arc.
let current_user = ctx.data::<Option<User>>();
let user_for_stream = Arc::new(current_user);
// then can use any data from the user inside the .filter(|x| ...) block because the lifetime is okay

But there is also the fact that the stream itself does not allow for calling async functions within the body of the filter (e.g., compiler error on any .await), which it looks like something like async-stream might solve.
Does that make sense to you? In your case, would wrapping repo in an Arc also solve your problem? Or is this undesirable for other reasons?

It does not seem to fix the problem that I cannot prove that the stream does not outlive the Context because the returned stream has a 'static lifetime and &Context does not.

Yes, this does not solve the lifetime problem.😄

I think this boils down to the same issue I was having.
What do you mean by async-compatible?
I think it would be nice to be able to get a clone of the context with every event. Something like this:
SimpleBroker::<MyEvent>::subscribe_with_ctx().map(|(evt, ctx)| async move { evt })

Should be easy to implement and simplify client code. Are there better solutions? What do you think?

@nicolaiunrein This is hard to implement, because the context borrows some data that can't be cloned, I think solve this problem by appending Arc to the context data.

@Ejhfast
'StreamExt::map' can only accept one synchronous closure, you should use StreamExt::then replace StreamExt::map.
fn map<T, F>(self, f: F) -> Map<Self, F>
where
    F: FnMut(Self::Item) -> T

fn then<Fut, F>(self, f: F) -> Then<Self, Fut, F>
where
    F: FnMut(Self::Item) -> Fut,
    Fut: Future

StreamExt::filter does not have this problem
fn filter<Fut, F>(self, f: F) -> Filter<Self, Fut, F>
where
    F: FnMut(&Self::Item) -> Fut,
    Fut: Future<Output = bool>,

Your code above should be changed like this
#[async_graphql::Subscription]
impl SubscriptionRoot {
    #[field]
    async fn messages(&self, ctx: &Context<'_>, mutation_type: Option<MutationType>) -> impl Stream<Item = MessageChanged> {
        let convo_db = ctx.data::<Database>().conversations.clone();
        SimpleBroker::<MessageChanged>::subscribe().filter(move |event| {
            async move {
               let convos = convo_db.get_all().await;
               // logic here...
               res
            }
        })
    }
}

To recap: I guess the trick is to move your data into the closure, clone it and move the clone into the async block. This seems to work with or without Arc but for performance reasons this should of course be an Arc on most types to avoid expensive clones.  My problem was that I always moved the data straight to the async block and tried to clone there.

This should be the best solution.

Is this still working? Because I tried it and getting the following error:
hidden type for impl Stream<Item = BookChanged> captures lifetime that does not appear in bounds

authors: Dindaleon Ejhfast nicolaiunrein sunli829


text:
Schema<Query, Mutation, Subscription>::builder() support

Description of the feature
Currently SchemaBuilder is constructed via Schema::build(Query, Mutation, Subscription) method. However, this would require developer to keep track of the Q, M, S types in multiple places and result in 500 internal server errors if they mismatch. Given that types are available, it would be nice to add a constructor that takes no argument.
Code example (if possible)
Current:
Schema::build(QueryRoot, MutationRoot, SubscriptionRoot)

Proposed:
Schema<QueryRoot, MutationRoot, SubscriptionRoot>::builder()

If the Q, M, and S types are missing, they will not compile without a runtime error.

If the Q, M, and S types are missing, they will not compile without a runtime error.

I do not understand this. Isn't this a good thing? The new API should catch a schema mismatch on compile time.


text:
Validate command output is polluted by noisy messages

Describe the bug
Validate command supports multiple diagnostics formats.
I assume that formats like json or junit are intended to be processed by machines.
However, validate command standard output is a mix of the selected diagnostics format and informational messages.
User must parse / filter standard output to end up with the expected file.
How to Reproduce
docker run -it --rm     -v ${PWD}:/spec test asyncapi validate /spec/docs/events/asyncapi.yaml --diagnostics-format=junit  > asyncapi.xml

cat asyncapi.xml
(node:1) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)

File /spec/docs/events/asyncapi.yaml and/or referenced documents have governance issues.
<?xml version="1.0" encoding="utf-8"?>
<testsuites>
<testsuite package="org.spectral" time="0" tests="1" errors="0" failures="1" name="/spec/docs/events/asyncapi.yaml">
<testcase time="0" name="org.spectral.asyncapi-document-resolved(#/channels/hems-site-events/messages/GatewayConnectionMqttDisconnected/payloa)" classname="/spec/docs/events/asyncapi"><failure message="Property "payloa" is not expected to be here"><![CDATA[line 94, col 16, Property "payloa" is not expected to be here (asyncapi-document-resolved) at path #/channels/site-events/messages/GatewayConnectionMqttDisconnected/payloa]]></failure></testcase>
</testsuite>
</testsuites>

Expected behavior
It would be nice to separate command logs from actual output.
Those options could work:

Add an optional outputFile parameter
Add an optional silent parameter

Regarding silent parameter the current validate command already has a boolean flag log-diagnostics. The output file is a valid addition. Thanks for giving this idea 🤗

still relevant

Currently, it's printing the XML in the command line. XML file should contain the following that is printed in the terminal right? It should only contain pure XML and not the diagnostics logs, right?

Yeah, output-file param will become more and more necessary as we do more UI/UX improvements.
WDYT @Amzani ?

@Souvikns Could you please assign this issue to me? Thank you!

authors: Amzani Shurtu-gal cykl dhruvilmehta sushilpandeyy

repo: asyncapi/cli


text:
[FEATURE REQUEST] Support OAS tags structure

Is your feature request related to a problem? Please describe.
Tags definitions are not compatible with OAS tags. When you are building tools to parse both specifications this is a problem
Can't it be tackled using specification extensions?
Nope
Describe the solution you'd like
Either apply the same structure (i.e. define top level tags and then use them as a simple array of tags names in the messages) or remove them.

I am confused about this feature request @germanschnyder, do you mind clarifying exactly what is wrong?
As I can see OpenAPI Tags and AsyncAPI Tags are exactly the same 🤔

authors: germanschnyder jonaslagoni

repo: asyncapi/spec


text:
Shouldn't listeners() include the any event listeners?

Currently the listeners() function doesn't include the listeners from the _all array.
Wouldn't it make sense to include the any listeners?

The any listeners can't be removed with removeListener and they're fairly different from regular listeners, I think it makes more sense to separate them, tbh.
What would be the main reason for including them?

Yeah, I guess it would depend on the use case.
I was expecting listeners to give me the list of every function that would receive a certain event when triggered. It's because I basically proxy events from a third-party API in my node app. And as soon as someone subscribes to one event from a certain set of events, it should subscribe for the event with the third-party API. When connection is lost and restored with the third party API I have to resubscribe and I was using the listeners method for that.
Anyway, I guess it makes sense not to include it, since it's impossible to trigger correct 'newListener' events for any listeners, so that makes them special indeed.

authors: RangerMauve sebakerckhof

license: mit


text:
🛑 Wedding HTTPS is down

In 82532bb, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in a806f76.

repo: atatkin/milos-uptime


text:
🛑 Wedding HTTPS is down

In ccc673c, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in d180a7a.


text:
🛑 Wedding HTTPS is down

In 99d388a, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in 69c78b6.


text:
Fix ? dates for github issues

In many cases where the scanners don't provide a published date, we can find that date from another source -- for instance the github page .  eg. https://github.com/advisories/GHSA-9vm7-v8wj-3fqw

Fixed

repo: atgreen/scandy


text:
Harden types

There are currently a few any types being used in the babel plugin, we should fix these

Situation has improved since. Type coverage is good.

authors: albertogasparin rohan-deshpande

repo: atlassian-labs/react-loosely-lazy


text:
Set up an empty Express Boilerplate with dotenv

What does this PR do?
This PR aims at setting up express and server project
Description of Task to be completed?

Set up an empty Node.js - express application.

By this We mean a full directory with all folders that you think developer will need. this might include but not limited to
src/ controllers, models, routes helpers,validations, etc
3.Test

feel free to contact the rest of the team and get ideas from them because this is the first skeleton of the application.

Install and setup dotenv for the API to manage environment variables. Ensure packages like sequelize and passport among the rest can fetch data about the current environment correctly via dotenv. Add documentation on how to utilize dotenv in the API.

Set the server and make sure it is running

How should this be manually tested?

Clone the repo
Cd into that repo
run  npm install
After that run npm run dev

What are the relevant pivotal tracker/Trello stories?

#184752075
#184752076
#184752078

The setup is great for me.

authors: frankflej nishimweprince

repo: atlp-rwanda/e-comm-team-techsmith-bn


text:
#184752079 Ch integrate coveralls

What does this PR do?

It set an environment in which  test will be run and  Coveralls code coverage service will be used

Description of Task to be completed?
This is to ensure we are properly informed just how well our code base is tested which in turn provides quality assurance for the product
How should this be manually tested?

Edit config.yml in the folder .circleci

Any background context you want to provide?
Units tests will be run on Circleci
What are the relevant pivotal tracker stories?

#184752079

this is on circleci but even in local I had issues with module not found when running the tests
Note: I checked the path is correct in the allroutes.js file and server.js file


text:
chore: upgrade dependencies ui-parts core, ui-proto core divider

Апгрейд зависимостей @atls-ui-parts и @atls-ui-proto у компонентов divider и core

пакеты @emotion оставила на версии 11.9.х,
только жесткие версии,
yarn check проходит без ошибок,
версии обновлены до максимально последних,
истории design с компонентом работают.

Все ок, принимаю.
Сделай пожалуйста еще одно маленькое дело - чтобы версии твоих обновленных пакетов повысились автоматом и запаблились в npmjs, сделай какие то минорные правки в коде обновленных пакетов. Например, можешь поменять местам строки или интерфейсы переформатировать.

Хорошо, вечером, когда буду дома, сделаю.

конфликт

конфликт

Исправлю

authors: TorinAsakura aliceinapple

repo: atls/hyperion


text:
⚠ AtmoLive02 Server has degraded performance

In d1e89e8, AtmoLive02 Server ($ATMOLIVE02) experienced degraded performance:

HTTP code: 200
Response time: 12385 ms

Resolved: AtmoLive02 Server performance has improved in 85baff1.

repo: atmovantage/atmostatus


text:
Bundling autocomplete-plus in core

My goal is only to bundle autocomplete-plus when it gets a lot of little details right. It's pretty close.
For the blog post, I want it to be super user focused, with only a couple pointers to API related things. My goal is to make this a little splashy: "Here are the things showing how much better autocomplete is!". Here's what I want to showcase:

SymbolProvider showing good suggestion type inference for a couple common languages as the default

We can explain how the provider uses the language packages, and point to a docs to make them better

Working with css, snippets, html and atom APIs is really good
One or more community providers that work and look awesome
Pointer to the provider API, and a couple examples

We will bundle

autocomplete-plus
autocomplete-snippets
autocomplete-css
autocomplete-html
autocomplete-atom-api
autocomplete-emoji (if it exists!)

Must haves
This is roughly the order I planned to do them in.

[ ] Get one or two (or all?!?) community providers using the suggestion types and left labels

cc @basarat @tinloaf @tststs Halp?

[ ] Get all the bundled syntax themes to implement the color vars cc @simurai
[ ] Fix suggestionListFollows == Word to align the prefix with the suggestion text https://github.com/atom-community/autocomplete-plus/pull/362
[ ] Get SymbolProvider ready for prime time; it should be close, just need to do some more eval

Do some performance eval + fixing
Implement changes API that uses includes builtins
Add specific support to languages, improve in common languages: js, python, rb
I'd like to make this the default very close to when we bundle autocomplete-plus so it's a bit of a nice surprise.

[ ] Explore using core:move-up / down to cycle through suggestions. cc @nathansobo and @maxbrunsfeld
[ ] Cannot expand snippet on tab in this situation: autocomplete open, no autocomplete-snippets, tab to complete
[ ] Make sure autocomplete-css is at its best

Make it trigger on space or automatically after prop name
It currently triggers in comments and generally after any space or dot
Works well in CSS, LESS, and SCSS

[ ] Make sure autocomplete-html is at its best
[ ] Make autocomplete-atom-api better

Use snippet, leftLabel, and type

[ ] Update defaults

confirmCompletion -> 'tab and enter'
minimumWordLength -> 3
backspaceTriggersAutocomplete -> false
suggestionListFollows -> Word

[ ] Figure out how best get this into core and move people using autocomplete-plus to the new bundled autocomplete

Nice to haves

[ ] Unicode support
[ ] Emoji provider for use in markdown + text we can bundle

Help!
Help is welcome! If you would like to take any of the above tasks, let me know!
Big helps would be:

Updating your provider to use API 2.0 and all the shiny new features helpful in your situation.
Making the language packages better

Better symbol scopes

e.g. js language doesnt tag functions as functions.
e.g. coffee language doesnt tag function arguments of function definitions as variables.

Defining all the builtins in your fav language

We may be able to specify them in a richer manner than just strings. Talk to me if you want to do this.

Adding the config for the SymbolProvider to your language once the API is nailed down.

Add unicode support
OMG write autocomplete-emoji @lee-dohm :rocket: :heart:

On the topic of emojis: https://atom.io/packages/autocomplete-emojis / https://github.com/eqot/autocomplete-emojis (hi @eqot!).

using the suggestion types and left labels

I don't know what is suggestionType or leftLabel : https://github.com/atom-community/autocomplete-plus/wiki/Provider-API#suggestions

@basarat that wiki page needs to be updated. @benogle made significant changes in #334 that introduced new properties.

Updated :+1: https://github.com/atom-community/autocomplete-plus/wiki/Provider-API#suggestions

After much headbanging, I realize type and leftLabel is not shipped yet :) Is it?

Not yet, but it's an apm publish minor away from being released: https://github.com/atom-community/autocomplete-plus/commits/master (it's merged to master).

@joefitzgerald cool. Ping me when done :heart:

Also I provide autocomplete for path as well, doesn't have a default mapping : https://github.com/atom-community/autocomplete-plus/pull/334#issuecomment-85697409

Update defaults
backspaceTriggersAutocomplete -> false

:-1: because backspacing can be seen as a way to "un-refine" the suggestion list. In the current bundled autocomplete, backspacing un-refines the suggestion list but it's done in the built-in input - which isn't present anymore here.
If backspacing isn't enabled by default, a single mistaken keystroke will then result in two more actions (backspace, then trigger autocomplete). If it is enabled, there is a frictionless interaction.
Providers can choose to suppress autocomplete on backspace, and you could also choose to suppress a suggestion request if the entire line is whitespace as a result of the backspace.

Can you provide documentation on how to use the suggestion types and left labels? As soon as an API is defined and stable, I'm happy to adapt my python-plugin to it ;)

Give me a day.

wait for it to be published before you start the work :+1:

Figure out how best get this into core and move people using autocomplete-plus to the new bundled autocomplete

As far as I can tell there are two distinct paths (replace autocomplete-plus with autocomplete-snippets or autocomplete-paths, as necessary):

Transfer autocomplete-plus to the https://github.com/atom organization

[ ] :phone: @thedaniel and get him to do his fun little database hack that fixes the registration for https://atom.io/packages/autocomplete-plus
[ ] Deprecate / remove https://github.com/atom/autocomplete
[ ] Done

Create a PR from autocomplete-plus back to https://github.com/atom/autocomplete

[ ] Determine if you want to actually create a clean PR or one that clobbers history
[ ] Create feature branch
[ ] Resolve all merge conflicts, verify the integrity of autocomplete-plus, tests
[ ] Create PR to https://github.com/atom/autocomplete
[ ] Merge PR
[ ] Create feature branch to remove all autocomplete-plus code and logic, leaving an 'empty' package with package.json so that it can be released
[ ] Merge feature branch for emptying autocomplete-plus
[ ] Release "emptied" autocomplete-plus
[ ] Release autocomplete
[ ] :arrow_up: autocomplete at https://github.com/atom/autocomplete
[ ] Release atom
[ ] Optionally include code for atom that disables / uninstalls autocomplete-plus
[ ] Done

get [me] to do his fun little database hack that fixes the registration for

We store numeric repo IDs now so it will probably Just Work. Don't quote me on that though, it's been a minute since I looked at that code ;)

wait for it to be published before you start the work :+1:

Nah. Let's get this done. It's kinda hard to map what Jedi is giving me to the predefined classes though.

@benogle are we effectively suggesting that most providers should use leftLabel to represent one of:

information about the type of the suggestion (i.e. an elaboration of the type / icon to the left)
information about what the suggestion "returns" (this would be used instead of the former)

If so, what should we advise people is the purpose of rightLabel? I'd like to communicate contextual intent of each on the wiki page to ensure provider authors understand how to decide when to use each, and what to include in each.
In converting go-plus to use the type correctly, I've identified a potential optimization, which is best illustrated by an example:

gocode (a go autocomplete engine) emits suggestions whose types can be func, package, var, type, const, PANIC
all map cleanly to existing syntax-color variables (panic is discarded), however package maps to import or require
if I map package to import, the icon is i, and is colored correctly - but in leftLabel I have package, which is weird looking ("why does that icon say i"?)
if I map package to require, the icon is r, and is colored correctly - but in leftLabel I have package, which is weird looking ("why does that icon say r"?)
if I don't map package, the icon is p, and is colored incorrectly
if I add  .make-type-icon(package, @syntax-color-import); to autocomplete.less, everything is hunky-dory

It sure would be nice to be able to achieve p as the icon, with a mapping of package to import. Or to be able to achieve the make-type-icon mapping without having to modify a stylesheet.
Thoughts?

For what it's worth, it was the right decision to go with the type icon and leftLabel - it's nice and clean (ignoring my theme for a moment):

@basarat @tinloaf icon/leftLabel is published in v2.8.0. I've also released go-plus v3.3.4 making use of it.

slick. I love you guys :rose: atom-typescript :ship:ed.

@basarat try moving your rightLabel content to leftLabel. And surrender styling of it to autocomplete-plus, just as an experiment. I think you'll find it cleaner.

Oh one other thing @basarat you can easily turn importScripts into an anonymous snippet. In this scenario, you'd have void in leftLabel, and emit a snippet that looks something like: importScripts(${1:...urls: string[]}). It'll be much shorter to display.

Just catching up. This is indeed a great news. :clap:
If possible, I would like to see in the :ship:ed documentation a working example of how to test a provider in real conditions (with editor and all).
I was using autocomplete-snippets specs as working sample, but v2.8.0 broke something and my specs no longer passes. It seems the autocomplete list no longer append returned suggestions when displaySuggestions have been called (in test mode).

@abe33 I'd help if you included a link to a branch or some commits.

It's kinda hard to map what Jedi is giving me to the predefined classes though.

@tinloaf what is it giving you that is difficult to map? To all y'all mapping items to these types, please list the ones you are having trouble with. The list is definitely not set in stone.

re: leftLabel ... information about what the suggestion "returns" (this would be used instead of the former)

Yes. It is for return values. Anything else should be in the rightLabel.

On the topic of emojis: https://atom.io/packages/autocomplete-emojis / https://github.com/eqot/autocomplete-emojis (hi @eqot!).

Yeah, but it doesnt inject actual emojis. I want to use something like this DB to insert actual emojis

if I add .make-type-icon(package, @syntax-color-import); to autocomplete.less, everything is hunky-dory

This is probably fine in the autocomplete less. We should use the package icon for these types. It should just be a few entries in this dict to add the icon.

@basarat Echoing @joefitzgerald, I would do a few things here:

Remove the snippet completion, and leave it to autocomplete-snippets
For importScripts, use {type: 'function', leftLabel: 'void', snippet: 'importScripts(${1:urls...:string[]})'}
For the interfaces, use {type: 'type'}
Dont use any right labels in this case.

If possible, I would like to see in the shipped documentation a working example of how to test a provider in real conditions (with editor and all).

Noted. This can definitely be cleaned up in our current tests.
Thanks guys for digging in. I'm out til monday, so I cant do any real work until then.

Yes. It is for return values. Anything else should be in the rightLabel.

I would expand that statement slightly:

leftLabel:

If a suggestion has a type of function (or a conceptual equivalent, like method), leftLabel should be used to describe the return value of the text or snippet that the suggestion pertains to
For any other suggestion type, leftLabel can be used to further describe the type (e.g. if type is constant, leftLabel might be const)

[...] so it will probably Just Work. Don't quote me on that though [...]

Well I've quoted you now, so I expect it to work :laughing:.

@joefitzgerald Solved, it was because the tests were relying on removed classnames to retrieve the test elements.

I didn't know about autocomplete-snippets, so thanks! . However it does not work with atom-typescript : https://github.com/atom-community/autocomplete-snippets/issues/46

Also:

For importScripts, use {type: 'function', leftLabel: 'void', snippet: 'importScripts(${1:urls...:string[]})'}

It gets hairy, functions have overloads, (some have 105 e.g. the on handler). We don't list them all, The process is two step, complete function by name, Second step: we provide the signatures for completion:

For the interfaces, use {type: 'type'}

Done :)

Dont use any right labels in this case.

No, because I'd like to like to show interface type differently (all map to type). The right label shows that difference.

But the stuff in rightLabel in leftLabel instead.

Put the stuff in rightLabel in leftLabel instead.

I've moved some of it (e.g. function / method is only on the left). But still left some of it duplicated (class / interface)  since I like to have these colors on the right (sorry):

This could come off the wrong way, but you should embrace the convention and avoid doing styling that is custom for your provider. In this particular case, the styling doesn't seem to add value
We should let theme authors handle styling of the suggestion list.

I suppose another way to state what I'm trying to convey is:
If the user cannot (visually) tell the difference between different providers' suggestions (because they are visually consistent), then we've all collectively done the right thing.
Colorization of each 'type' of suggestion is driven by syntax themes; styling of the suggestion list can be modified by theme authors. Provider authors should try to refrain from "theming" the list, and instead should ensure that their suggestions are semantically and contextually correct.

@basarat please place the return type in the left label. As joe said, the
suggestion type is handled by the little icon. If you'd like, we can add an
'interface' type so you are not using 'type'.
Echoing joe, provider uniformity is important because the user does not
know where one provider ends and the other starts.
On Friday, April 3, 2015, Basarat Ali Syed notifications@github.com wrote:

Put the stuff in rightLabel in leftLabel instead.
I've moved some of it (e.g. function / method is only on the left). But
still left some of it duplicated (class / interface) since I like to have
these colors on the right (sorry):
[image: image]
https://cloud.githubusercontent.com/assets/874898/6991344/7bd42472-dada-11e4-93e6-7a0c484462e2.png
—
Reply to this email directly or view it on GitHub
https://github.com/atom-community/autocomplete-plus/issues/351#issuecomment-89497063
.

@benogle, do you mean autocomplete-unicode-emojis?

This package is just quickly developed and has not been published as an atom package yet.

@benogle My python-jedi provider does now support the type icons. I'm not sure if I will support the left label, since return types can most of the time not be inferred in a dynamically typed language like python, and so 90% of the time this will just read "value"...

@benogle By the way - when bundling ACP in core, will the providers just magically work? What about the "old" autocomplete providers, do they stop working? Or do I have to move my autocomplete-plus provider to an autocomplete provider? Or will both be working in tandem? So many questions...

Looking good so far.

But it is pretty hard to determine the (icon)-type of every suggestion with tern, cause only isKeywordis passed. fn(..) resolves to function and all the rest at the moment is just variable :)
Keep up the good work! :rocket:

@benogle, do you mean autocomplete-unicode-emojis?

Awesome. I have some suggestions, will make issues!

I'm not sure if I will support the left label

That's ok, no prob. It's definitely going to be better on statically typed languages.

when bundling ACP in core, will the providers just magically work? What about the "old" autocomplete providers, do they stop working? Or do I have to move my autocomplete-plus provider to an autocomplete provider? Or will both be working in tandem? So many questions...

Yes, they should just magically work. All the providers provide a autocomplete.provider service, which the new bundled autocomplete will consume, so everything should Just Work.

Are you guys(@tststs, @basarat) super against using the snippet field instead of the huge right label with all the types? That right label is invisible immediately when the user selects a suggestion, and the arg types might be hard to remember after the list goes away. If you use the snippet, they can tab between the arguments.

As far as I can tell there are two distinct paths (replace autocomplete-plus with autocomplete-snippets or autocomplete-paths, as necessary):

@joefitzgerald, I like option 2 you outlined for upgrading. The empty autocomplete-plus could even disable or remove itself. Not sure.

Are you guys(@tststs, @basarat) super against using the snippet field instead of the huge right label with all the types? That right label is invisible immediately when the user selects a suggestion, and the arg types might be hard to remember after the list goes away. If you use the snippet, they can tab between the arguments.

@benogle, not against the snippet field, but just not ready yet. :)
And for myself i don't like snippets that being passed to the editor. In most cases, i don't need all the params provided (optional params).
So i made this:

@benogle, thank you very much for the clarification and the issues.
I wanted to check if it is exactly what you mean before polishing its usability. I will fix the issues shortly.

minimumWordLength -> 3

@benogle, this default would be a problem in autocomplete-unicode-emojis to show :+1: by typing ':+', for example. 2 is better, hopefully.
Or, is it possible to overwrite minimumWordLength in each autocomplete package?

Or, is it possible to overwrite minimumWordLength in each autocomplete package?

Each provider should be adhering to this option, so the emoji provider can simply ignore it.

Ok, removed rightLabel and using snippet from now on :)

Nice :+1: Do you know the return values of the functions?

yes. just a bad screenshot-example here :)

Amaze

Each provider should be adhering to this option, so the emoji provider can simply ignore it.

Glad to hear that. Thank you for the information!

The empty autocomplete-plus could even disable or remove itself. Not sure.

@benogle I'd prefer to find a way to 'clean up' autocomplete-plus by having it remove itself once it's in that state. I'm unsure as to how atom feels about a package removing itself. Will bad things happen, as files are in use, and those files are being deleted?

Just wanted to ask if disabling autocomplete while in a comment (perhaps on a provider by provider basis) was on the immediate roadmap? Just something that can be frustrating at the moment.

@mehcode, you can set the Scope blacklist setting in the autocomplete-plus settings to .comment to disable in comments.

Awesome! That works nicely.
Some providers might want to work inside comments (perhaps emoji?). Just a thought to consider.
Also can we make that setting default somewhere along the way to 1.0?

Also can we make that setting default somewhere along the way to 1.0?

I also think this is a great idea.

Also can we make that setting default somewhere along the way to 1.0?

I agree. I would add that strings should be added too if possible.

I disagree. The moment you disable comments by default in the package is the moment you effectively make any provider that does want to work and do something novel in comments infeasible.
Each provider can choose to suppress a suggestion request to themselves, and each should do so in comments (like go-plus does) if autocomplete doesn't make sense in comments for that grammar / context.

The moment you disable comments by default in the package is the moment you effectively make any provider that does want to work and do something novel in comments infeasible.

This is pretty dramatic considering the setting can be changed.

What I'm suggesting @thedaniel is that the settings for this package should be as open and permissive to other providers as possible. Adding stuff to the blacklist default suppresses unforeseen ideas that you and I cannot conceive right now.
The right thing to do is - prior to 1.0 - ensure that all the bundled providers and also all of the community providers (where it makes sense) don't provide suggestions in comments - this has the same net effect, but preserves the possibility for future innovation inside comments (or other selector(s) - this is a slippery slope).

@joefitzgerald but whether to provide completions in comments can't just be up to the package. The user needs a way to configure it. Are you saying that each provider should have a separate setting for disabling completions in particular scopes?
This seems like a worse user experience than disabling it for comments globally.

@maxbrunsfeld: the user can always suppress selector(s) globally in the blacklist setting.
I'm suggesting that our collective desire to suppress autocomplete in comments by default is more an expression that we don't wish to see suggestions in comments when there is no contextual benefit from it. Most providers (e.g. mine, go-plus) don't provide useful information in comments so I've disabled it in that scope.
Other providers should choose to do the same. They can choose to do so in a way that is or is not configurable, depending on the context. If you don't make defaults decisions at the provider level you will inevitably get into debates over defaults (e.g. Imagine someone writes a provider for JavaDoc autocomplete in Java files - they will naturally lobby for the default to change. Their users will also scream out for all the providers to suppress suggestion requests except for their beloved JavaDoc provider).
We've done multiple things recently to remove the governor on when autocomplete requests are dispatched, to preserve the ability of providers to make sensible decisions about when they should provide suggestions. Changing the default to suppress in comments walks that backwards, and I think it introduces a number of challenges that you're not considering yet.

That seems reasonable to me. I think I'd be satisfied as long as the built-in completion provider didn't provide completions in comments (or strings, ideally) by default.

I think I'd be satisfied as long as the built-in completion provider didn't provide completions in comments (or strings, ideally) by default.

:+1: on that.

Lets move the discussion about this to https://github.com/atom-community/autocomplete-plus/issues/377

Instead of publishing autocomplete-unicode-emojis as a package, I have updated autocomplete-emojis which now supports unicode emojis as well as markdown emojis.

Tricky thing is that there are a lot of suggestions for unicode and markdown emojis, like :sm shows 49 unicode emojis and 48 markdown emojis. This is quite frustrated if you want to choose markdown emojis from the suggestions.
So,  autocomplete-emojis also supports :: prefix to show markdown emojis only.

Lookin good @eqot :+1:

Thanks! :smile:

If people are looking to help, improving the language packages would be a big help. Here are two issues for coffee and javascript.

https://github.com/atom/language-javascript/issues/137
https://github.com/atom/language-coffee-script/issues/53

Feel free to go deep on your favorite language too. Properly detecting and scoping variables, functions, classes, mixins, etc will make the symbol provider much better.

@benogle What say you on backspaceTriggersAutocomplete -> false.
I've disagreed with this on the basis that we should allow any single keystroke to trigger autocomplete (by default), and let the user (via configuration) or the providers (via configuration or not) determine keystrokes for which suggestions should be not provided (e.g. see: https://github.com/joefitzgerald/go-plus/pull/180). Doing otherwise hinders novel use cases that we cannot foresee.
I don't think we're in agreement yet, so what are the arguments for this change?

I strongly feel that we should have it disabled by default. I'd like to argue about this in another thread.

In omnisharp-atom (handling C# autocompletion). We have some styling issues with C# when the description needs to overflow, things aren't floating correctly:

@ctolkien: might want to weigh in on #405.

:fireworks:

@nathansobo is this going to be shipped with Atom by default now?

@ilanbiala It's shipping with Atom now as of 0.199.0

Is there anything we need to specifically handle to migrate? Or can we just yank out the  package dependency and things will "just work".
Ref: https://github.com/OmniSharp/omnisharp-atom/pull/277

authors: abe33 basarat benogle ctolkien eqot ilanbiala joefitzgerald maxbrunsfeld mehcode mnquintana nathansobo thedaniel tinloaf tststs

repo: atom-community/autocomplete-plus


text:
Default backspaceTriggersAutocomplete To False

Fixes #419
Makes @benogle's day

:+1:

authors: benogle joefitzgerald


text:
Atom update doesn't reload unsaved file progress and chokes on manually opening editor JSON from ~/.atom/storage

Description
I noticed that I was still on Atom version 1.6, so I checked to see what version is current and tried to use the built-in updater. After the updater failed to work (still/again) I manually downloaded and installed Atom using this process:

Download from atom.io
unzip
close Atom
drag new Atom to Applications, replace existing Atom with new
relaunch Atom

When I relaunched Atom the unsaved files I was working on were gone replaced with two blank files, and the saved file I had open was replaced with a blank file. I tried to look in the editor cached files to recover what I had been working on. Unfortunately one of those files is a little more than 1.6 MB, which when I try to load it and scan through in Atom, it chokes. It doesn't seem to be able to handle the very file that it created -- making recovering from the failed update process all the more painful.
Steps to Reproduce

Try to update
Manually update when first step fails
Open newly updated Atom
Try to review cache since previously opened files were blown away
Cry because one of the files is too big to deal with in Atom
File issue on Github

Expected behavior: [What you expected to happen]
One of two things...maybe three:

Atom actually updates itself like the menu option suggests is possible (despite it never working)
Atom would recover from cache files
Atom could actually handle a file that it generates so a user can manually recover from problems

Actual behavior: [What actually happened]

Updater failed
Manual install blew away open files from previous session
Can't manually retrieve prior work because .atom/storage editor cache file is larger than what Atom can handle (my file is 1621797, not sure what the limit is for Atom stability).

Versions
I am on OS X version 10.11.4. I started with Atom version 1.6, and updated to 1.7 (1.7.1 to be exact).

Not sure how typical or useful this is, but I used less to go through the file and it looked like a lot of it was the contents of the tree-view pane. I guess that is what caused that single editor backup file to be so massive.
Maybe it would be a good idea to only have a limit on the levels of recursion cached in that file or something? Might help keep the file size more manageable.

This PR fixed the bug https://github.com/atom/atom/pull/12486

repo: atom/atom


text:
Makefile Box in Markdown not highlighted.

If you have a markdown file (.md) with this content:
```makefile
# Compiler flag, 4M flash chip, SS on PB7 (original MP)
C_FLAGS += -DFLASH_CHIP_4M
C_FLAGS += -DFLASH_BIT_SS=PB7 -DFLASH_PORT_SS=PORTB -DFLASH_DDR_SS=DDRB
```.

The content is not highlighted, its just green. For example a cpp instead of makefile highlights the code inside the editor. If you press ctrl + m the markdown preview is shown, where the code is highlighted. This means markdown is actually supported but for some reason not highlighted in the markdown editor.
Using atom 1.10.2 on archlinux.

Please open this on the language-gfm repository.  In addition, next time when filing an issue on atom/atom be sure to completely fill out the provided issue template or your issue may be closed without further triage.


text:
Atom opens chrome developer tools on startup (unless it is run as root) [issue is different from issue #9220]

Prerequisites

[X ] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
When running atom as normal user (not root), then atom only opens chrome dev tools. Note, that there is no error displayed on the dev tools window.
Steps to Reproduce

Download latest atom .deb package .
$ wget -O atom-amd64.deb https://atom.io/download/deb
Install atom using gdebi.
$ sudo gdebi atom-amd64.deb
Run atom as user.

Expected behavior: [What you expect to happen]
Expect atom to open normally when ran.
Actual behavior: [What actually happens]
If atom is ran as:
$ sudo atom
Then atom runs normally; no problems there.
BUT if atom is not ran as root:
$ atom
Then atom opens chrome developer tools
Reproduces how often: [What percentage of the time does it reproduce?]
Always.
SOLUTION
-DO NOT install atom using gdebi. Install with dpkg fixes the issue.
(Replace {step 2} from steps to reproduce, with the following command to fix:
$ sudo dpkg -i atom-amd64.deb
Versions
1.34 (latest as of today)
Additional Information
Operating System: Ubuntu 18.04 LTS

Could you elaborate on why this is an Atom issue? gdebi is not our recommended way of installing Atom, and since it is working with how we recommend you install it this sounds like gdebi is doing something incorrect when installing it.

My mistake then. I assumed that you'd like to know about this issue with gdebi. Closing this issue now.

authors: Arcanemagus soutzis


text:
Uncaught Error: Module did not self-register.

[Enter steps to reproduce:]

...
...

Atom: 1.40.1 x64
Electron: 3.1.10
OS: Unknown macOS version
Thrown From: Atom Core
Stack Trace
Uncaught Error: Module did not self-register.
At ELECTRON_ASAR.js:166

Error: Module did not self-register.
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:166:20)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:740:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:180:18)
    at Module.load (internal/modules/cjs/loader.js:620:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:559:12)
    at Function.Module._load (internal/modules/cjs/loader.js:551:3)
    at Module.require (/app.asar/static/index.js:72:46)
    at require (internal/modules/cjs/helpers.js:20:18)
    at customRequire (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:1:688158)
    at get_KeyboardLayoutManager (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:14:2744622)
    at get_manager (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:14:2744724)
    at Object.getCurrentKeyboardLayout (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:14:2744850)
    at e.keystrokeForKeyboardEvent (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:14:1087821)
    at KeymapManager.keystrokeForKeyboardEvent (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:1246932)
    at KeymapManager.handleKeyboardEvent (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:1244917)
    at WindowEventHandler.handleDocumentKeyEvent (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:284329)

Commands
     -1:04.3.0 tree-view:show-in-file-manager (span.name.icon.icon-file-directory)
  2x -0:18.3.0 window:decrease-font-size (input.hidden-input)

Non-Core Packages
atom-html-preview 0.2.6
atom-material-ui 2.1.3
autocomplete 0.47.0
autocomplete-html-entities 0.2.0
browser-plus-open-new-window 0.0.1
css-in-js 1.4.0
css-snippets 1.1.0
css-specificity 0.2.2
css-spy 0.6.0
css-triggers 1.0.2
export-html 3.1.0
html-includes 0.3.0
html-tab 1.0.2
html-tag-auto-complete 0.1.1
html-template-generator 0.3.0
html-to-css 0.2.2
ide-css 0.3.3
ide-html 0.6.0
java-class-complete 0.0.6
make-html-code 1.4.0
markdown-preview-enhanced 0.17.7
markdown-to-html 0.5.0
open-in-browsers 0.0.30
teletype 0.13.4

Thanks for taking the time to contribute!
We noticed that this is a duplicate of https://github.com/atom/atom/issues/20222. You may want to subscribe there for updates.
Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


text:
Uncaught Error: Module did not self-register.

[Enter steps to reproduce:]

...
...

Atom: 1.46.0 x64
Electron: 4.2.7
OS: Mac OS X 10.14.6
Thrown From: Atom Core
Stack Trace
Uncaught Error: Module did not self-register.
At ELECTRON_ASAR.js:160

Error: Module did not self-register.
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:160:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:722:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:169:18)
    at Module.load (internal/modules/cjs/loader.js:602:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:541:12)
    at Function.Module._load (internal/modules/cjs/loader.js:533:3)
    at Module.require (/app.asar/static/index.js:72:46)
    at require (internal/modules/cjs/helpers.js:20:18)
    at customRequire (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:1:695134)
    at get_KeyboardLayoutManager (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:14:2778162)
    at get_manager (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:14:2778264)
    at Object.getCurrentKeyboardLayout (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:14:2778390)
    at e.keystrokeForKeyboardEvent (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:14:1081110)
    at KeymapManager.keystrokeForKeyboardEvent (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:1253631)
    at KeymapManager.handleKeyboardEvent (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:1251616)
    at WindowEventHandler.handleDocumentKeyEvent (/Applications/Atom.app/Contents/Resources/app/static/<embedded>:11:284744)

Commands
     -0:29.8.0 core:close (input.hidden-input)
  8x -0:10.9.0 core:copy (input.hidden-input)

Non-Core Packages
atom-material-syntax 1.0.8
autocomplete-python 1.16.0
busy-signal 2.0.1
intentions 1.1.5
language-latex 1.2.0
latex 0.50.2
lines 0.13.1
linter 2.3.1
linter-flake8 2.4.0
linter-ui-default 1.8.0
pretty-json 2.1.2

Thanks for contributing!
We noticed that this looks like a duplicate of https://github.com/atom/atom/issues/20049 so you can subscribe there for updates if you'd like.
As mentioned in https://github.com/atom/atom/issues/20049#issuecomment-546646559, it would be helpful to know if you still see the error after quitting/restarting Atom.

Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.

authors: lkashef nitishgupta


text:
After Updating to 1.0.15, Won't Update Packages

Fetching outdated packages and themes failed.Hide output…
Request for package information failed:

Application Error

Application Error

Currently on 1.0.16 and this just happened to me.
Fetching outdated packages and themes failed.Hide output…
Request for package information failed: <!DOCTYPE html>

      <meta name="viewport" content="width=device-width, initial-scale=1">

    <title>Application Error</title>

Application Error

These types of errors are caused by service outages in the package infrastructure. Please open such issues on the atom.io repo. Thanks!

authors: ainstushar ghost thomasjo


text:
When disconnecting a non-retina external monitor, Atom doesn't switch state while full screen

I have a retina MacBook Pro running El Capitan with two non-retina external monitors. If I have an Atom window full screen on a non-retina display and then disconnect my laptop, Atom will continue to be in low-resolution mode on the Retina display. Sizing is correct, but text is blurry.

Thanks for the report, @will-in-wi. This sounds similar to https://github.com/atom/atom/issues/9226 so I'm going to close this in favor of that. Could you add a comment there so that everything is in one place? And please let me know if I misunderstood your report. :v:

This is indeed a duplicate of the listed bug. Thanks!

authors: izuzak will-in-wi


text:
process.chdir should support asar paths

the following code does not work in asar archives
process.chdir(__dirname)
But it could be useful to set current directory to __dirname as explained here #447

The __dirname in asar archive does not exist on filesystem, and operating systems do not allow setting current working to somewhere does not exist, so I'm afraid this is technically impossible.

authors: felicienfrancois zcbenz

repo: atom/electron


text:
How can I tell ide-java to ignore specific warnings?

Ide-java is showing a warning on every single one of my HttpServlet classes: The serializable class <MyClass> does not declare a static final serialVersionUID field of type long. Is there currently a way to ignore this warning?

The Eclipse language server doesn't allow for customization of error reporting. You would probably be best off using the @SuppressWarning annotation instead.

repo: atom/ide-java


text:
atoma-vllm: allow distributed GPU compute compatibility with vllm

Distributed GPU compute, using Tensor parallelism, for now.

Addressed in atoma-infer: https://github.com/atoma-network/atoma-infer

repo: atoma-network/atoma-node


text:
Adding experimental touch

Hi Chris,
started a fork here: https://github.com/martinberlin/diy-esp32-epub-reader-touch
with the mission to add touch (If I can, really experimental)
And I wanted to leave this topic to ask you about building an ESP-IDF project with Platformio since it's my first time and for sure I will make lot's of mistakes.
For example in this commit just added my touch component in lib folder.
But I'm still trying to guess how I tell Platformio to include this in the build process. In IDF I do that using CMakeLists in the component folder but here I'm a bit lost. Can you share your knowledge with me?
Thanks in advance

With the lib folder, platformio automatically includes it as a dependency so you don't need to do anything.
With the current version of platformio, you can also just create a components folder and use it just as you would with the esp-idf - it should work out what to do with it.
If you want I can make you a contributor to this repo.

I think since your touch libary is already an idf component then going the components folder route might be easier. This will also wire up any menuconfig settings you have as well. You can launch menu config with
platformio run -t menuconfig

I tried with the touch library adding it on the lib folder but it does not include it automatically as a dependance for me. I wanted to follow your path and leave all the libs on the same folder but if I cannot get it to work I will do as you suggest. Thanks anyways!
I would like to discover why other libraries are added automatically but mine not ;)
Let's see if I can really collaborate with something first, then I can accept your invitation!

authors: cgreening martinberlin


text:
Does this project have an active maintainer?

I see that there are no changes merged for like half a year. I would like to use this package but it seems that it does not have an active maintainer?

How about using the Amazon Kinesis Firehose instead?
I have stopped using this plugin and started using it and https://github.com/awslabs/aws-fluent-plugin-kinesis because I had trouble as #25 and it seems there is no future to resolve it.
However, the Firehose outputs to the ES domains only same region, then this idea can apply in us-east-1, us-west-2, eu-west-1 regions :(
Although I always use ap-northeast-1, I created ES domains in us-west-2.

I am also running into issues using this plugin. Any good recommendation as an alternative? I looked at putting the logs in S3 and stream to ES. But this is a very costly approach.

There are 2 approaches:

someone becomes new maintainer if @atomita is ok
-- option is fluent-plugin-nursery for temporal place
fork plugin (I don't want to do)

@repeatedly - what would you think of extending uken/fluent-plugin-elasticsearch to support Amazon signing?  Amazon signing seems to be the biggest (only?) feature lacking in uken/fluent-plugin-elasticsearch?

This plugin is small enough that rolling functionality into fluent-plugin-elasticsearch makes a lot of sense. On the other hand that plugin is not well-maintained either these days.

I'm not sure because I'm not a maintainer of elasticsearch plugin.
If the maintainer and contributor is okay, it is good idea.

On the other hand that plugin is not well-maintained either these days.

@yissachar - yeah, I thought this was being resolved in https://github.com/uken/fluent-plugin-elasticsearch/pull/240, in particular that @repeatedly was being given access.  I just re-read that PR now and it still seems unresolved.  This is a real bummer because for many people, myself included, Fluentd loses a lot of value without a good well maintained Elasticsearch plugin.

I'd became an active maintainer. (But still @atomita wants to publish this plugin by his own.)
So, we can close this issue.

authors: aibou cosmo0920 dwoo4dwoo mariusgrigaitis mpas repeatedly yissachar


text:
Update documentation build system to reflect main branch rename

Updates the workflows and navigation menu to reflect the recent rename of the master branch to main.
These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).
SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

Superseded by #1050.

repo: atomvm/AtomVM


text:
support image form clipboard?

support image form clipboard?
Can you give a thought

That's interesting, but I have no idea how to implement it..

for mac: https://github.com/jcsalterego/pngpaste

Hey, @atotto thanks for this awesome library is this feature being worked on and to be expected?

any update?

Bump

authors: Chyroc atotto benjamin-daniel dwSun wael444 windhc

repo: atotto/clipboard


text:
feat: add isEncrypted if set to false or true in notify command

Fixes  https://github.com/atsign-foundation/at_libraries/issues/650
- What I did

Set isEncrypted flag in notify command whether it is true or false
- How I did it
Temporarily introduce a private method _toAtProtocolFragment(duplicate of AtKey-->Metadata --> toAtProtocolFragment). Set isEncrypted whether it is true or false. Remove this private method and reuse AtKey method once update verb isEncrypted changes are done.
- How to verify it
tests in dependent repos should pass

https://github.com/atsign-foundation/at_libraries/pull/646
https://github.com/atsign-foundation/at_server/pull/2087
https://github.com/atsign-foundation/at_client_sdk/pull/1393
https://github.com/atsign-foundation/at_libraries/pull/647
https://github.com/atsign-foundation/noports/pull/1344

This is fine as a stopgap. As a precaution, please add some unit tests re isEncrypted when using an UpdateVerbBuilder

https://github.com/atsign-foundation/at_libraries/pull/649/commits/141716aa9586faf49cdc04f2c18ad5a5695e4c8c
Are these tests fine ?

I will rerun the tests once below PR is merged and then merge at_commons PR
https://github.com/atsign-foundation/at_client_sdk/pull/1391


text:
Extract print functionality from Diff function.

The Diff function now returns Difference objects that can be
used in different contexts (e.g. print_diff)

Current coverage is 87.40% (diff: 35.54%)

Merging #2722 into master will decrease coverage by 0.49%

@@             master      #2722   diff @@
==========================================
  Files           243        244     +1
  Lines         18229      18292    +63
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits          16025      15989    -36
- Misses         1941       2040    +99
  Partials        263        263

Diff Coverage
File Path

0%
new cmd/noms/diff/print_diff.go

•••        36%
go/types/path.go

••••••••   84%
cmd/noms/diff/diff.go

•••••••••• 100%
cmd/noms/noms_log.go

•••••••••• 100%
cmd/noms/noms_diff.go

Powered by Codecov. Last update 4b843b8...69bdc5b

fyi @aboodman

@kalman PTAL

authors: codecov-io willhite

repo: attic-labs/noms


text:
Adding Testing in Safari Tech Preview

travis multirunner now supports it

Argh

repo: aullman/opentok-test-scripts


text:
isExplicitNavigationBack is always false

I just recently discovered this very useful property, however when trying to use it it's always false - regardless if I use the browser's back button (not sure if that's even supported?) or Router.navigateBack().
I'm currently scrolling to the top of the page on the router:navigation:complete event from my main App class, but I would like to not do that if isExplicitNavigationBack:
import {inject} from 'aurelia-framework';
import {EventAggregator} from 'aurelia-event-aggregator';

@inject(EventAggregator)
export class App {
	constructor (ea) {
		this.ea = ea;

		this.ea.subscribe('router:navigation:complete', e => {
			// isExplicitNavigationBack is always false - whether using back button or Router.navigateBack()
			if (!e.instruction.router.isExplicitNavigationBack) {
				document.body.scrollTop = document.documentElement.scrollTop = 0;
			}
		});
	}
}

Is this a bug, or am I doing something wrong here?

Oh, I noticed that inside router:navigation:processing it is in fact true after using navigateBack(). That solves my issue as I can store the value of it and use it later on inside complete. I'm curious why it would be reset to false inside complete though? I still feel that's undesirable behaviour but I might be missing something?

Also, the fact that it's false when you use the normal back button inside the browser makes it much less useful. It would be awesome if it could be merged with the work done by @jwx for this very similar issue: https://github.com/aurelia/router/issues/436

I see that PR https://github.com/aurelia/router/pull/459 is just waiting to be merged, and that would solve everything as we'd have proper back/forward button support and more so I'll close this issue for now and hope to see that PR in the next release.

repo: aurelia/router


text:
How to use Webpack with plugins?

I've got the skeleton-esnext-webpack setup, and now trying to incorporate some third party plugins, for example  aurelia-grid.
However, getting errors on the line in main.js that attempts to use the plugin:
aurelia.use
    .standardConfiguration()
    .developmentLogging()
    .plugin('corneliutusnea/aurelia-grid');

The error is:
app.bundle.js:14024 Uncaught (in promise) Error: Cannot find module './corneliutusnea/aurelia-grid'.
    at webpackContextResolve (http://localhost:9000/app.bundle.js:14024:9)
    at webpackContext (http://localhost:9000/app.bundle.js:14019:29)
    at http://localhost:9000/aurelia.bundle.js:15001:50

I had tried a few changes to webpack.config.js to try and make sure that plugin is available, but it seems no matter what I do, it's always trying to load the plugin code from ./....
Does anyone know how to use 3rd party plugins with webpack?
Ultimately what  I really want to do is write my own plugin that exposes a  custom element, and use that, and during development, using npm link to make it available, but ran into the Cannot find module error, so decided to try with a published plugin to rule out any issues with my plugin or npm linking.

@danielabar The README you linked to yourself contains a section about using resources which will solve your issue.

Couldn't get it working following steps in the readme, but this works, now it loads "my-component" from node_modules:
plugins: [
    new AureliaWebpackPlugin({
      includeSubModules: [
        { moduleId: '@my-scope/my-component' }
      ]
    })
  ]

includeSubModules has been deprecated for over a month, if you have a recent version that setting won't do anything at all.

@niieani, it would be nice if the newer version would detect usages of old conf and guide how to configure same feature with current version.

@atsu85 I've thought of that and that's already in :) New version should be released today.

authors: atsu85 danielabar niieani

repo: aurelia/skeleton-navigation


text:
Testing script

This script automatically compile compiler, then compile test contracts, deploy them in testchain, call some functions and check that they return correct results.
New tests can be added very easy, just add following string in All() function:
TestOne(File.sol, method, args, expected_result)

TODO : link this script to github actions (a bit difficult because it need some setup script)

@birchmd WDYT ?

@birchmd

I think it would be nice to submit these to a localnet instead.

Do you mean we should run wasi or make analogue of testnet in localhost ?

Do you mean we should run wasi or make analogue of testnet in localhost ?

I meant running a NEAR node on the local machine and deploying to it instead of deploying to the testnet.

For example, workspaces-rs could be useful here: https://github.com/near/workspaces-rs

I recommend trying workspaces-rs posted above instead of using nearup directly.


text:
make_metadata.py logic puzzle

https://github.com/auspicious3000/SpeechSplit/blob/10ed8b9e25cce6c9a077e27ca175ba696b7df597/make_metadata.py#L17-L25
Hi,
I don't understand the code logic of this paragraph.
Shouldn't everyone's id be different? Why are there only two?
If I want to use VCTK 20 speakers to train, does this paragraph have to be modified?
Could you explain a bit of it to me?

How to generate file like demo.pkl to inference? I generate train.pkl by make_metadata.py is wrong to inference. The two files are stored in different formats.
How to generate *-P.ckpt model?

@leijue222

Hi,
I don't understand the code logic of this paragraph.
Shouldn't everyone's id be different? Why are there only two?
If I want to use VCTK 20 speakers to train, does this paragraph have to be modified?
Could you explain a bit of it to me?

I guess that is only for demo.
If you just only have 20 speakers, then you can just imitate things like:
if(speaker == 'p226'):
    spkid[0] = 1.0
else if(speaker == 'p227'):
    spkid[1] = 1.0
else if(speaker == 'p228'):
    spkid[2] = 1.0
etc

Author use one-hot embedding as the speaker id
if you wanna change to zero-shot learning, you may need to change the one-hot vector to speaker embedding vector.
I still got some problem, however.  lol
I'm still working on how to make my own demo.pkl, which I consider is used to validate.

@CYT823
Yes, I wanted to do zero-shot   unsee(little dataset) to seen(mang great dataset) before.
I don't know how effective this project is. The demo provided by the author can't evaluate the cost.

ha. I don't know either, but the results on the demo web page sound great.
I'm still trying to make it to zero-shot.
Hope the result can be as great as the demo page result when I use speaker embedding instead of one-hot.(crossing fingers)

Please leave a message here if you have good results. I am currently scheduled to do other tasks.
Good luck!

@CYT823 did you manage to create pkl file for inference?

Hi @skol101,
I am sorry, but I'm no longer working on this project.
Besides, I don't think you really need  a pkl file during the inference mode.
The pkl file, which is for validation, is using in training mode.
During inference, you just need to put two voices as input and get the result.


text:
Array error

What does this mean?

make_spect_f0.py:15: FutureWarning: Pass sr=16000, n_fft=1024 as keyword args. From version 0.10 passing these as positional arguments will result in an error
mel_basis = mel(16000, 1024, fmin=90, fmax=7600, n_mels=80).T
Found directory: assets/wavs
p226
Traceback (most recent call last):
File "make_spect_f0.py", line 53, in
x = np.concatenate((x, np.array([1e-06])), axis=0)
File "<array_function internals>", line 6, in concatenate
ValueError: all the input arrays must have same number of dimensions, but the array at index 0 has 2 dimension(s) and the array at index 1 has 1 dimension(s)

Nevermind I think it means they have to be mono


text:
added: subgraph explorer: uniswap, compound, synthetix, balancer etc

subgraph explorer: uniswap, compound, synthetix, balancer, aave, dydx, kyber and curve.

closed, creating a separate subgraph view

repo: austintgriffith/scaffold-eth


text:
Fixing dashboard admin login

This fixes a few problems with the extension.
Fixes dashboard admin's ability to view the history UI.
For the development server added disabledHostCheck so it can be run locally
Fixed the UI templates so assets can be found (needed /app/ path).

MD5: c4103f122d27677c9db144cae1394a66
NSP - Security Report
This is an automated security audit of this project. Please do not modify its contents
Vulnerabilities found: 2
Affected Modules: uglify-js, uglify-js
Summary:

Regular Expression Denial of Service
Incorrect Handling of Non-Boolean Comparisons During Minification

Detailed report
Regular Expression Denial of Service
Affected Module: uglify-js
Installed version: 2.2.5
Patched versions: >=2.6.0
Advisory: https://nodesecurity.io/advisories/48
Path: auth0-logs-to-application-insights@2.0.3 > auth0-oauth2-express@1.3.0 > jade@1.11.0 > transformers@2.1.0 > uglify-js@2.2.5

Incorrect Handling of Non-Boolean Comparisons During Minification
Affected Module: uglify-js
Installed version: 2.2.5
Patched versions: >= 2.4.24
Advisory: https://nodesecurity.io/advisories/39
Path: auth0-logs-to-application-insights@2.0.3 > auth0-oauth2-express@1.3.0 > jade@1.11.0 > transformers@2.1.0 > uglify-js@2.2.5

authors: Verlic sgmeyer


text:
Integration Test Error

Checklist

[X] I have looked into the README and have not found a suitable solution or answer.
[X] I have looked into the documentation and have not found a suitable solution or answer.
[X] I have searched the issues and have not found a suitable solution or answer.
[X] I have upgraded to the latest version of this project and the issue still persists.
[X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
[X] I agree to the terms within the Auth0 Code of Conduct.

Description
I ran across this error while running make test:
make test
# ...
#  ::  Running integration tests
# Error: AUTH0_CLI_CLIENT_DOMAIN, AUTH0_CLI_CLIENT_ID and AUTH0_CLI_CLIENT_SECRET environment variables need to be set

Setup
OS: MacOS 13.6.1
Go: 1.20.3
Notes: I don't have the cli installed and was testing the steps through the CONTRIBUTING doc.
Expectation
I expected all tests to pass.
Reproduction
Given I do not have the auth0-cli installed
And I haven't authenticated
When I run make test
Then I see the integration error
Auth0 CLI version
main

The error is spawned from the suite run script.
This may be able to be fixed by exporting those variables in the makefile before running the script.

I appreciate the sensitivity of these env variables. Perhaps we could change the CONTRIBUTING doc to reflect steps on setting them personally, avoiding the need to generate them.

Hey @m3talsmith 👋🏻
Thanks for taking the time to raise this! We can definitely improve the contributing guidelines and the test setup. One important thing we're missing there is the fact that we require a machine to machine application already created on the test tenant that has been authorized to request access tokens for the Management API and has all the required permissions. Only then we can leverage the client's credentials to authenticate through the Auth0 CLI.
We could also take this opportunity to uniform the env var naming to AUTH0_DOMAIN, AUTH0_CLIENT_ID and AUTH0_CLIENT_SECRET so it's aligned with some of our other repos, for example: https://github.com/auth0/terraform-provider-auth0/blob/main/CONTRIBUTING.md#running-the-tests. This would make switching projects and running tests easier.
A further improvement would be the addition of another make command that would only run a single/subset of the integration tests, for example: commander test --verbose --filter "016" test/integration/users-test-cases.yaml, commander being the utility we use for our integration tests.
These combined would make for a much more improved CONTRIBUTING guidelines. Happy to know your thoughts on this and discuss further.

Thanks @sergiught ! I think we are both on the same page here. There were some minor Makefile changes made to pass the auth0 variables to the script. I'm looking for a better way to do that: definitely open to suggestions.
I'll keep PR #902  open to have code specific comments there.
I especially like the idea of having a filter on commander as that would allow us to have a minimum set of integration tests for a quick pass, and still allow us to run the full suite at a future time.

Closing this down now that we have https://github.com/auth0/auth0-cli/pull/902 merged in 💪🏻


text:
Auth0Provider not sending client_id

Description

I'm using auth0/auth0-react and trying to follow Complete Guide to React User Authentication With Auth0.  When I try to implement the LoginButton component and test, I get an error that the client_id is missing.

Reproduction

Steps taken are as close as possible to your tutorial with the exception that this is not a "from scratch" project.  I am trying to modify ArchitectUI, a popular dashboard React template project.  I am following the tutorial up to the point of creating a Login/Logout Button component and testing that the user is forwarded to Auth0 for authentication.  I also made sure to configure the domain, client_id, and audience properties for the Auth0Provider component.

Log entry from dashboard
{
"date": "2020-07-14T22:55:59.867Z",
"type": "f",
"description": "Missing required parameter: client_id",
"connection_id": "",
"ip": "",
"user_agent": "Chrome 83.0.4103 / Windows 10.0.0",
"details": {
"body": {},
"qs": {
"audience": "",
"scope": "openid profile email",
"response_type": "code",
"response_mode": "query",
"state": "",
"nonce": "",
"code_challenge": "",
"code_challenge_method": "S256",
"auth0Client": ""
},
"error": {
"message": "Missing required parameter: client_id",
"oauthError": "invalid_request",
"type": "request-error"
},
"session_id": "****************"
},
"hostname": "",
"auth0_client": {
"name": "auth0-react",
"version": "1.0.0"
},
"log_id": "**********************",
"_id": "**********************************************************",
"isMobile": false
}
Error

Environment

auth0/auth0-react 1.0
React 16.12.0
react-router-dom 5.1
ArchitectUI React template project Project link
Win10, VS Code

Hi @jdsilva-scopesec
Couple of things to check:
Make sure your clientId is being loaded from the environment variables, so after assigning clientId log it to the console and check it is defined.
const clientId = process.env.REACT_APP_AUTH0_CLIENT_ID;
console.log('clientId', clientId)

Make sure you're passing clientId to the provider (not client_id)
<Auth0Provider
      clientId={clientId} <==
      ...
    >
    {children}
</Auth0Provider>

If you're still getting Missing required parameter: client_id please share your code or a running link to your app

Thanks @adamjmcgrath.  It seems I had incorrect parameter names in setting up the provider component.  I have also followed the recommendations for HashRouter in the examples as my project uses that type of router.

Great - glad it's working for you now

authors: adamjmcgrath jdsilva-scopesec


text:
Support multiple providers

Description
This adds support for multiple instances of Auth0Provider being used within an application, this is achieved by providing a context parameter (created using React.createContext) to the Auth0Provider, this same context can then be provided to useAuth0, withAuth0, and withAuthenticationRequired in order to access the authentication state and methods associated with that instance of Auth0Provider.
The choice to accept the context in the helpers was made to avoid users having to maintain their own versions of these that may deviate from the internal version. Whilst for useAuth0 and withAuth0 this was unlikely due to their simple-ness, withAuthenticationRequired is more complex so I figured that it was worth it.
References
#290
Testing

Describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this library has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.
Please include any manual steps for testing end-to-end or functionality not covered by unit/integration tests.
Also include details of the environment this PR was developed in (language/platform/browser version).

[x] This change adds test coverage for new/changed/fixed functionality

Alongside this I've also produced a React version of the account linking sample to demonstrate/test this work. In order to run it check out this branch, build the repo and run npm link in this repo, and then npm link @auth0/auth0-react in the sample.
Checklist

[x] I have added documentation for new/changed functionality in this PR or in auth0.com/docs
[] All active GitHub checks for tests, formatting, and security are passing
[x] The correct base branch is being used, if not the default branch

(optional) also might be nice to do the nested Auth0Provider test in  auth-provider.test.tsx

authors: adamjmcgrath ewanharris


text:
wip: Add AWS S3 region option

WIP
If the region option of the AWS S3 Client is missing and the bucket isn't on the default region you get this error:
Unable to sync: PermanentRedirect: The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.

The solution is setting the correct S3 region. More info: http://stackoverflow.com/a/26725760/4709891

Define a env var AWS_REGION='<region>' is more simpler.


text:
Make types in init.py and init.pyi agree

This was introduced by #193 and noted in https://github.com/authzed/authzed-py/issues/89#issuecomment-2349135562.

I wonder if it's possible to improve the CI job to catch these errors? https://github.com/authzed/authzed-py/blob/main/.github/workflows/lint.yaml#L81

repo: authzed/authzed-py


text:
🛑 FlareDrive is down

In 26531c9, FlareDrive (https://flaredrive.lirtual.cloudns.org/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: FlareDrive is back up in 0ed365c after 31 minutes.

repo: autoactions/upptime