Clean up the factory methods in Http{Request,Response}

Motivation:

The following two methods look confusingly similar to each other and
HttpRequest implements Publisher:

HttpRequest.of(RequestHeaders, Publisher)
HttpRequest.of(HttpRequest, RequestHeaders)

Some static factory methods could be just member methods:

HttpRequest.of(HttpRequest, RequestHeaders)
HttpRequest.of(AggregatedHttpRequest)
HttpResponse.of(AggregatedHttpResponse)

Modifications:

Improved HttpRequest.of(RequestHeaders, Publisher) and
HttpResponse.of(Publisher) so that they handle HttpRequest and
HttpResponse specially.
Added HttpRequest.withHeaders(RequestHeaders)
Deprecated HttpRequest.of(HttpRequest, RequestHeaders) in favor of
HttpRequest.withHeaders()
Deprecated HttpRequest.of(AggregatedHttpRequest) and
HttpResponse.of(AggregatedHttpResponse) in favor of
AggregatedHttpRequest.toHttpRequest() and
AggregatedHttpResponse.toHttpResponse().

These methods were removed from AggregatedHttpMessage some time
ago due to ambiguity, but now we are reviving them because we have
separate types for requests and responses.

Result:

Fixes #2278

Thanks, reviewers!


Use bootstrap cache

Clear static contact info from cache when a bootstrap connect fails.
Add new static contact info to cache on calls to Service::connect

r? @vinipsmaker
(maidsafe_highfive has picked a reviewer for you, use r? to override)

This PR is broken. I'm working on some fixes to config_file_handler that will fix it.

This PR is broken. I'm working on some fixes to config_file_handler that will fix it.

Let me know when it's ready.

Hrm, dunno why that test hung on one of the appveyor runs.

Reviewed 1 of 5 files at r1, 2 of 3 files at r2, 5 of 5 files at r3.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

src/config_handler.rs, line 39 [r3] (raw file):
Cool. I didn't know about this trait.

Comments from the review on Reviewable.io

This branch is out-of-date with the base branch

I'll open another PR and merge there based off this one.

This is ready for review now @vinipsmaker


Add tiny-dfr package to support touchbars on 13-inch MBPs

Fedora Asahi Remix ships a package called tiny-dfr that provides a basic function-key row on the MBP touchbar.
For feature parity, this project should ship the same code.
https://github.com/WhatAmISupposedToPutHere/tiny-dfr
https://src.fedoraproject.org/rpms/rust-tiny-dfr

https://github.com/NixOS/nixpkgs/pull/277549
I had to enable CONFIG_INPUT_TOUCHSCREEN for input to work.

I had to enable CONFIG_INPUT_TOUCHSCREEN for input to work.

What an amazing coincidence that someone filed https://github.com/tpwrules/nixos-apple-silicon/pull/134 !
😉

I've enabled that config option for convenience. I'm deferring to upstream on the package itself, partially because I don't have that hardware to test with.

Did you also enable CONFIG_TOUCHSCREEN_APPLE_Z2=m?  That's the actual driver for the touchbar, of which CONFIG_INPUT_TOUCHSCREEN is a prerequisite.

Yes, I did.

This seems better to have and maintain in nixpkgs. I have no way to test the package.


Wildcard on request URL

Useful if you want to just return a canned response regardless of the URL

+1 on this feature. It would be great to have wildcard/pattern (regex maybe?) matching on the URI.
e.g. /jobs/jobsid-*/status will match /jobs/jobsid-1232/status.
By any chance, are you working on this right now?

I'm not, probably wont be able to for at least a week. Feel free to have a crack yourself though :)

On reflection I cant see how this can work very well with the CDC element of mockingjay; what URL can MJ send to the real server to test against?
So Im going to close this for now unless I can think of something elegant


[WIP] subscribers v2

closes #7023
tasks

[X] test later.js for parsing text expressions
[X] integrate mailgun (keep node mailer next to mailgun integration)
[X] wait for kevins UI requirements, then test against RRULE
[x] newsletter limit - how can we force a newsletter limit for Ghost(Pro) users?How can we configure it easily via support?
[ ] implement newsletter limit
[ ] let subscribers confirm their subscription
[x] check if validate subscriber emails good -> we are using schema validators for email
[ ] react on error codes for mailgun (especially domain is down, suspended) - use an alternative domain?(https://documentation.mailgun.com/razor.html#razor-error-codes)
[x] validate rrule on schema level
[ ] look for rrule fork
[x] finish newsletter template and dynamic generate
[x] wait for aileens newsletter template and replace
[x] add example newsletter endpoint (newsletter/test)
[x] offer a way to set a settings entry (to be able to change the 'from' mail address)
[x] return config.mail to ember (/configuration)
[x] spam detection gmail (hmm always lands in spam) - was caused by the test domain i have used
[ ] extend support mail site and optimise config.example.js for mail section

tasks for Ghost(Pro)

[ ] change how we generate config.js: mail.from = '.......' (should be automatically the blog email)
[ ] setup ghost.org domain for ghost pro users (and store domain + apikey in daisy.js)
[ ] test domain is ghost.org with "from" is the domain of the blog

Also some integrations like Zapier and Mailchimp would be great!

@alexbagirov Thanks for your interest and your suggestion. For the first version we will only support mailgun.

If my reading of this is correct you're planning on offering users (specifically ghost pro I'm querying about) the ability to change the from email. Is this correct?

@jloh Yes this is planned. For Ghost(Pro) we will take the blog email as default, but it want to offer the option to override from in the admin section. Non Ghost(Pro) can add a mail.from into the config.js or via the admin.

@kirrg001 It looks like jkbrzt/rrule is still active
any chance this pull will be merged soon? I really look forward to start growing my email-list :)

Closing, but i will keep the branch for reference.
The branch has too many conflicts and the subscribers V2 implementation need's more research and we have to reconsider mailgun as default provider. As soon as we have to time to finish the feature, we will update the related issue with information.


[ENH] Specify default values for C struct declarations

Is your feature request related to a problem? Please describe.
If there is a sturct with many fields, only some of its fields need to be initialized explicitly, and other fields can be implicitly empty-initialized, designators will be useful in c99:
struct MyStruct {
    int a;
    int b;
    int c;
    int d;
    float e;
    float f;
};

int main(void) {
    struct MyStruct s1 = {
        .a = 1,
        .b = 2,
    };
    struct MyStruct s2 = {
        .c = 42,
        .d = 233,
    };
    struct MyStruct s3 = {
        .e = 0.1,
        .f = 0.2,
    };
}

However, cython will leave other fields uninitialized and generate some warnings.
cdef struct MyStruct:
    int a
    int b
    int c
    int d
    float e
    float f

def main():
    cdef MyStruct s1 = MyStruct(
        a = 1,
        b = 2,
    )
    cdef MyStruct s2 = MyStruct(
        c = 42,
        d = 233,
    )
    cdef MyStruct s3 = MyStruct(
        e = 0.1,
        f = 0.2,
    )

warning: test.pyx:10:31: Not all members given for struct 'MyStruct'
warning: test.pyx:10:31: Not all members given for struct 'MyStruct'
warning: test.pyx:14:31: Not all members given for struct 'MyStruct'
warning: test.pyx:14:31: Not all members given for struct 'MyStruct'
warning: test.pyx:18:31: Not all members given for struct 'MyStruct'
warning: test.pyx:18:31: Not all members given for struct 'MyStruct'

The generated C code looks like this:
struct __pyx_t_4test_MyStruct __pyx_v_s2;
struct __pyx_t_4test_MyStruct __pyx_t_1;

/* "test.pyx":14
 *         b = 2,
 *     )
 *     cdef MyStruct s2 = MyStruct(             # <<<<<<<<<<<<<<
 *         c = 42,
 *         d = 233,
 */
__pyx_t_1.c = 42;
__pyx_t_1.d = 0xE9;
__pyx_v_s2 = __pyx_t_1;

Describe the solution you'd like.
It would be helpful if it's possible to specify default values for the fields of C structures.
cdef struct MyStruct:
    int a = 0
    float b = 0
    void *c = NULL
    int d[4] = [0, 0, 0, 0]

# equivalent to above:

@cython.default_to_zero
cdef struct MyStruct:
    int a
    float b
    void *c
    int d[4]

def main():
    cdef int foo = 42
    cdef MyStruct s = MyStruct(
        b = 1.23,
        c = &foo,
    )

This code behaves the same as if specified a = 0 and d = [0, 0, 0, 0]:
def main():
    cdef int foo = 42
    cdef MyStruct s = MyStruct(
        a = 0,
        b = 1.23,
        c = &foo,
        d = [0, 0, 0, 0],
    )

The whole struct can also be empty-initialized:
cdef struct Inner:
    int a = 0
    int b = 0

cdef struct Outer:
    int a = 0
    int b = 0
    Inner c = Inner()

# equivalent to above:

@cython.default_to_zero
cdef struct Inner:
    int a
    int b

@cython.default_to_zero
cdef struct Outer:
    int a
    int b
    Inner c

def main():
    cdef Outer s = Outer()

Describe alternatives you've considered.
No response
Additional context
No response

@cython.dataclass should take care of this request
I don't think that adding more features that do the same thing helps anyone

I know @cython.dataclasses, but it's an extension class, which is a python object. What I described here is for pure C structs. c99's designators are convenient in C programing, it would be great to have this feature in cython.

Definitely not opposed to this if someone does the work. Don't think we can implement it in terms of designated initializers though.

Don't think we can implement it in terms of designated initializers though.

Due to C99 or due to other limitations?
In general (but definitely if it's the latter), I think that after 3.0 it'd be worthwhile to also consider raising the minimal C standard version. CPython already requires C11 as of 3.11, similarly for scipy, the linux kernel, etc...

Due to C99 or due to other limitations?

Partly C++ too, which only as them as a c++20 feature.
But mostly that Cython's code generation puts the declarations at the start of the function and the initialisation a little way in. That's partly for C89 reasons, but mostly just so that variables are function scoped like Python

Another idea: we can always empty-initialize these temporary structs, e.g.:
struct __pyx_t_4test_MyStruct __pyx_v_s1;
struct __pyx_t_4test_MyStruct __pyx_v_s2;
struct __pyx_t_4test_MyStruct __pyx_v_s3;
struct __pyx_t_4test_MyStruct __pyx_t_1 = {0};
struct __pyx_t_4test_MyStruct __pyx_t_2 = {0};
struct __pyx_t_4test_MyStruct __pyx_t_3 = {0};

/* "test.pyx":14
 *         b = 2,
 *     )
 *     cdef MyStruct s2 = MyStruct(             # <<<<<<<<<<<<<<
 *         c = 42,
 *         d = 233,
 */
__pyx_t_2.c = 42;
__pyx_t_2.d = 0xE9;
__pyx_v_s2 = __pyx_t_2;


refactor: migrate models to SQLAlchemy v2

Please review @frostming @greyli
I think we need to set some fields to optional.

Updated, please review @frostming @greyli


Chrome Extension

Made working first draft
Will remove jQuery, was just for POC.

you've got some merge conflicts

Will take a look, sorry!

Right, done.

probably should take out that gif too

Repos diverged weirdly, going again!


how much data needed when training 11B model, Llama-3.2-11B-Vision-Instruct?

Hello, I would like to ask how much data is needed to fine-tune an 11B model, Llama-3.2-11B-Vision-Instruct, using the sft_vlm.py script?

Hi @cutecharmingkid , unfortunately the answer is not trivial. Does the domain of your task match the tasks used to fine-tune the base vision-instruct model? I would imagine 10k-100k example would be enough, but I have not tested extensively.


The Athletic themed icon please

Please create just one issue instead of spamming the repo.

Sorry about that, I had a multiple request one before and it got closed
when one of the apps was done so thought maybe they were supposed to be
separated.
Thanks for the awesome app!
On Fri, Nov 12, 2021, 8:03 PM Suphon T. @.***> wrote:

Please create just one issue instead of spamming the repo.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/LawnchairLauncher/lawnicons/issues/72#issuecomment-967775376,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWK35UNOSZR55FGB72NMYIDULXPRBANCNFSM5H5QF6RQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


[pos_keyboard] Enter key not working (v10)

I just found about the new features pushed by @KolushovAlexandr on this addon, amazing job btw.
What happens,
I've found that the Enter Key is not responding on v10, not the Enter key nor the NumPad one.
I've tested both for this issue (enter key),

Odoo v11 (bc6d051fcab9a6552968683a095b34cb3b937aff) +
pos_keyboard v<IP_ADDRESS>.0 = works!
Odoo v10 (903fec011d64cd50a4e925d4046757afacf1363a) +
pos_keyboard v<IP_ADDRESS>.1 = doesn't work.

Any other key is working as it should.
I looked for a runbot to confirm the behavior but seems they are not available.
Best regards.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Thanks for reporting! Fixed here https://github.com/it-projects-llc/pos-addons/pull/999


fix replication validation for Role ARN

updating replication rule with deprecated Role ARN fails with "invalid destination bucket for this rule"
repro:
{
 "Rules": [
  {
   "ID": "cptjg0rkru7aqane8md0",
   "Status": "Enabled",
   "Priority": 0,
   "DeleteMarkerReplication": {
    "Status": "Enabled"
   },
   "DeleteReplication": {
    "Status": "Enabled"
   },
   "Destination": {
    "Bucket": "arn:aws:s3:::bucket"
   },
   "Filter": {
    "And": {},
    "Tag": {}
   },
   "SourceSelectionCriteria": {
    "ReplicaModifications": {
     "Status": "Enabled"
    }
   },
   "ExistingObjectReplication": {
    "Status": "Disabled"
   }
  }
 ],
 "Role": "arn:minio:replication::090575fd-f689-4cfa-8a5a-5712c55825b2:bucket"
}

mc replicate update sitea/bucket --id cptjg0rkru7aqane8md0 --remote-bucket http://"${remote_access_key}:${remote_secret_key}"@localhost:9000/bucket
mc: <ERROR> unable to modify replication rule: invalid destination bucket for this rule.

=== RUN   TestAddReplicationRule
--- PASS: TestAddReplicationRule (0.00s)
=== RUN   TestEditReplicationRule
Error:     replication_test.go:347: Test 1: Expected invalid destination bucket for this rule, got %!s(<nil>)
--- FAIL: TestEditReplicationRule (0.00s)


Support db replica (read only nodes)

Postgres and typeorm (here) both support db replicas, one primary read/write node and multiple read nodes.
This can improve our performance (we must see) as we have heavy write queries like refreshing materialized views.
@mhmdksh has created a replica node for impact-graph db (both staging and production).
Let's first try this feature  on the staging and then apply on the production

#1014

As mentioned, the read replica for our DBs is created. Please send a DM for connection info

DEVs: It must be noted, we won't get the best out of this upgrade completely since some of our read calls are done with query which will hit the master node

All simple queries performed by find methods or select query builders are using a random slave instance. All queries performed by query method are performed using the master instance.

So we need to modify our queries (e.g. in resolvers) to use the read node instead.

who wants to take this?
@CarlosQ96 @aminlatifi

I added thi to technical debts, is it still valid?

I added thi to technical debts, is it still valid?

Yes

@CarlosQ96 pls take this up once superfluid is done "modify our queries (e.g. in resolvers) to use the read node instead" as amin mentioned above.

https://typeorm.io/multiple-data-sources#using-multiple-data-sources

@jainkrati This is a long running issue, that is very important to follow up on since it is mainly responsible for the performance of our DB queries

This issue should be tested ? how can I test it ? @aminlatifi @CarlosQ96

@maryjaf It's working and most of the read queries are hitting read-only replica. From the user side, there is no way to find it out, you must look at the database monitoring in the digital ocean and we did it.

@maryjaf It's working and most of the read queries are hitting read-only replica. From the user side, there is no way to find it out, you must look at the database monitoring in the digital ocean and we did it.

Thanks @aminlatifi
So this issue could be moved to "close"?

@maryjaf It's working and most of the read queries are hitting read-only replica. From the user side, there is no way to find it out, you must look at the database monitoring in the digital ocean and we did it.

Thanks @aminlatifi So this issue could be moved to "close"?

Yes

Typeorm allows us to define defaultMode as the default replica of read queries. We can set it to master and then manually create queries against read replica using
const slaveQueryRunner = dataSource.createQueryRunner("slave")

It is a way around which allows us to put some loads on read-only replicas manually. We can implement it faster  to fix performance issue.
The other way is one @CarlosQ96 mentioned to change all write/save queries to be sure they are executed to read-write replica.

@RamRamez please continue working on this along with @CarlosQ96

Typeorm allows us to define defaultMode as the default replica of read queries. We can set it to master and then manually create queries against read replica using
const slaveQueryRunner = dataSource.createQueryRunner("slave")

It is a way around which allows us to put some loads on read-only replicas manually. We can implement it faster to fix performance issue.
The other way is one @CarlosQ96 mentioned to change all write/save queries to be sure they are executed to read-write replica.

@CarlosQ96 @RamRamez
https://github.com/Giveth/impact-graph/issues/1016#issuecomment-2100197365

Typeorm allows us to define defaultMode as the default replica of read queries. We can set it to master and then manually create queries against read replica using
const slaveQueryRunner = dataSource.createQueryRunner("slave")

It is a way around which allows us to put some loads on read-only replicas manually. We can implement it faster to fix performance issue.
The other way is one @CarlosQ96 mentioned to change all write/save queries to be sure they are executed to read-write replica.

@CarlosQ96 @RamRamez
https://typeorm.io/multiple-data-sources#adjusting-the-default-destination-for-reads

By default all read connections with be routed to slave and write connections will go to master. By adding defaultMode: master, all read connections will be routed to master, then we have to manually define all read queries one by one to use slave, that's very time consuming, besides that TypeORM doesn't fully support defining read DB manually for all methods that we use like .find and .findOne
So I think adding defaultMode is not a good option.
Since TypeORM doesn't fully support DB replica for all repo methods, I suggest we use load balancing for DB instead of replica with a proxy server to balance DB connections.
cc @jainkrati

@mhmdksh @RamRamez @CarlosQ96 could you pls coordinate for setting up load balancer

@mhmdksh @RamRamez @CarlosQ96 could you pls coordinate for setting up load balancer

Thanks @jainkrati , I've created this issue to explore this and make a setup ready for testing: https://github.com/Giveth/devops/issues/238
Will update you on the same

whats the progress here @RamRamez @MohammadPCh

@maryjaf I will DM you about testing this issue

I haven't seen any problem in verification flow or changing the status from admin bro @RamRamez


New article on Styled Components

My favorite way to style react components

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for correcting the filename, but your commit(s) fails to meet one of the following requirements:

The article must include the title key in the following format as the first 3 lines of the file.

---
title: Your Title
---

Once you have confirmed your changes meet these requirements, please submit the changes on a new PR.
Thank you for understanding.

Hi,
As there has been no response from your end for a while, I am closing this PR.
Feel free to create a new PR if you still wish to make the changes you originally added in this PR.  Also, remember to re-sync your fork, so you have the latest version of master in case it has changed significantly.
Happy Coding!


BitNet (b1.58) support

First of all, thanks. We need more ramps.
I was curious what you think of BitNet, and if llm.c is a place where experimenting with it could be facilitated. The papers were extremely promising and got a lot of traction, but there while there have been a few (small scale) reproductions yet, there isn't a easy ramp to start experimenting with it.
Papers

BitNet: Scaling 1-bit Transformers for Large Language Models
(BitNet b1.58)) The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits
The Era of 1-bit LLMs: Training Tips, Code and FAQ

I don't think we have it on the current roadmap, Andrej can chime in. We have a lot of stuff on the backlog before we get here, including potentially supporting fp8, ZeRO stage 2, etc.

The problem with BitNet (b1.58) training is that is still uses FP16/BF16 for training so the memory consumption does not decrease. Anyways getting support for it would be great! If used with FP8 training it could bring improvement.


[semver:minor]

Background
The current go-mod-ginkgo-v2 test orb can run two types of ginkgo tests, unit and acceptance. Furthermore extending the go-mod-ginkgo-v2 job to support new test types is difficult due the method in which it identifies tests as unit vs. acceptance.
In order to support a more diverse range of test types I would like to propose the following job to detect tests using ginkgo's flag filtering system. This orb is highly coupled to hginkgo

IMO ideally this would live in the hginkgo repo and be imported into the golang orb that way there can be testing to make sure the labels listed in hginkgo stay in synce with this orb. That required more effort than this and since this is an experimentation I think being able to move to verifying this has value is more important.


Update to bevy 0.14

I'm not sure how to fix the "generate_docs" examples, which swaps out and in the App::world, which is now behind getter/setters.

You can do this (wanted to make a suggestion but I can't suggest over non-changed lines):
fn with_main_world_in_render_app<T>(app: &mut App, f: impl Fn(&mut SubApp) -> T) -> T {
    // temporarily add the app world to the render world as a resource
    let inserted_world = std::mem::take(app.world_mut());
    let mut render_main_world = bevy_render::MainWorld::default();
    *render_main_world = inserted_world;

    let render_app = app.sub_app_mut(RenderApp);
    render_app.world_mut().insert_resource(render_main_world);

    let ret = f(render_app);

    // move the app world back, as if nothing happened.
    let mut inserted_world = render_app
        .world_mut()
        .remove_resource::<bevy_render::MainWorld>()
        .unwrap();
    *app.world_mut() = std::mem::take(&mut *inserted_world);

    ret
}


No such operator xformers::efficient_attention_forward_cutlass

How to fix it?
Here is the full code: https://pastebin.com/d3xEGEhC
Running Python 3.10.10 and don't want to re-build and re-push and re-download a docker container just to fix this issue.

This helped:

Uninstalling xformers by pip uninstall xformers
Removing --xformers from the train command

Maybe just removing --xformers from the command could have helped, but i did not test it.
But still need a better fix...

Maybe it really doesn't work for python3.10.10
Re-building image with python3.10.6 -___–

Fuck, i spent so much time rebuilding it with python 3.10.6 instead of 3.10.10 and still getting the same error:
No such operator xformers::efficient_attention_forward_cutlass - did you forget to build xformers with `python setup.py develop`

I also tried:
apt-get install libgl1 -y
apt-get install libglib2.0-0 -y
python setup.py develop
Nothing works

Holly shit.
I just ran pip uninstall xformers and pip install xformers and it worked. Why?
I also see that in ubuntu_setup.sh you do this:
pip install -U -I --no-deps https://github.com/C43H66N12O12S2/stable-diffusion-webui/releases/download/linux/xformers-0.0.14.dev0-cp310-cp310-linux_x86_64.whl
Why do you do this if you already have another version in requirements.txt?

And also why you don't include apt-get install libgl1 -y and apt-get install libglib2.0-0 -y in the ubuntu_setup.sh script if it's required?

I had same issue, seems like it's not possible to run without xformers.
I see you mention also ubuntu_setup.sh so you probably refering to different repo (old version, ubuntu_setup.sh is no longer present) with GUI version:
https://github.com/bmaltais/kohya_ss

@kgonia seems like I am using https://github.com/bmaltais/kohya_ss .
Just checked, they removed ubuntu_setup.sh yesterday for some reason...
@kohya-ss sorry

@kopyl bmaltais/kohya_ss now have new script for installtion setup.sh

@kopyl bmaltais/kohya_ss now have new script for installtion setup.sh

Yeah, but it does not work :(

same issue here, can I really run without xformers?

I also meet this question under ubuntu 20.04, finally I fix it by using the command  pip install xformers==0.0.19


publish under @metamask scope

Fixes #4

Anything else needed here @whymarrh ?

I've added @rekmarks here to also review this, he's done most of these migrations.
I believe we also need a publishConfig to allow the package to be published as public (example).

Superceded by #14 and #15


Bump auth protocol version to pass gaia hub

We need to bump this version to 1.2.0:
https://github.com/blockstack/blockstack.js/blob/master/src/auth/authMessages.js#L20
So that this check passes:
https://github.com/blockstack/blockstack.js/blob/master/src/auth/authApp.js#L177
Which enables the passing in of a user-specified gaia hub URL.

Happy to help here as well.

Thanks @hstove -- this was merged into develop in https://github.com/blockstack/blockstack.js/pull/402 -- so whenever we do the next release, this should be resolved.

This was merged into master in release 17.2.0


Table names on windows need to be lowercase

For compatibility reasons, case in table names is now ignored. Updated docs accordingly.


feat: add documentation and types for unwrapResponseData

Documentation and types for unwrapResponseData
I didn't know there was a unwrapResponseData feature until I randomly came across it in the templates.
This change makes the option easier to discover by adding it to README.md and enables it in TypeScript via index.d.ts

I had the same experience. Thanks for adding this!


Add some of the missing setting to 'page_rule' api

This adds in (I think all) of the missing Page Rule settings.
I got the list of settings from the Create Page UI in my Cloudflare dashboard, so it may differ if some are hidden from there.

All of them? They're available in my UI (or rather, they were when I checked last week).
Is there anywhere with a complete list of available page rule options and I get can working on correcting that!
Thanks!

Thanks, Colin!


Spike: Dependency Management - PDM

Goal
The goal of this task is to test PDM as a dependency manager and identify how it addresses the tests below. Gather notes about ease of setup and how well the package is documented, in addition to testing the items listed below.
Update the doc with your findings.
Tech Stack-Specific
The following are related to our specific tech stack.
Flask Import Error Test

Required: fido2 < 1.0.0
Installed: 0.9.3

Flask raises ImportError with higher versions.  I expect that newer versions of Flask fix this or don't require Fido.

Celery Dependencies

Required: kombu < 5.0
Installed: 4.6.11

Celery depends on this package, and the Docker image build failed with the newest version.  Ignoring security vulnerability 42497 in Makefile.  The vulnerability is fixed in kombu>=5.2.1.

Security Vulnerability Check
How does each handle security vulnerabilities?

Required: click-datetime>=0.2
Installed: 0.2 (newest version)

This package requires click, which has a security vulnerability 47833 ignored in Makefile.  The vulnerability is fixed in click>=8.0.

Installed: click v7.1.2

Updating Pinned Versions
What, if anything does it do with pinned versions? If a pin is removed how does it handle it?

Required:
Flask < 2.0
Flask-Bcrypt==0.7.1
Flask-Cors==3.0.10
Flask-JWT-Extended==4.1.0
flask-marshmallow==0.11.0
Flask-Migrate==2.5.2

Installed Flask: 1.1.4

Newer versions of Flask cause errors, and all of the Flask-* packages are pinned to accommodate this.

Specific Version Commit Test
Specific commit test. How does it handle it?

Required and installed<EMAIL_ADDRESS>
Requiring Flask-SQLAlchemy version 2.3.2, 2.5, or 3.0 causes test failures via database errors about foreign key constraint violations.

Specific Version Tag Test

Required: PyPDF2 < 2.0.0
Installed: 1.28.6

Required and installed<EMAIL_ADDRESS>
Flask raises ImportError with newer versions of PyPDF2.  notification-utils version 1.0.66 also raises import errors with newer versions, but that package can be updated to version 1.1.0 if we upgrade Flask.

Timebox
3 days

Hey team! Please add your planning poker estimate with Zenhub @cris-oddball @EvanParish @ianperera @jakehova @k-macmillan @kalbfled @trevor2718

Reassigned to Lucas due to availability and knowledge. Aiming to discuss dependency learnings/options this Friday at the engineering sync.

Please see the updated doc.  I have a strong distate for pipenv due to its being managed by pip.  For me, Poetry is the obvious winner.  I will now be diving deep into PDM to see how it compares to poetry.  My axiom for choosing a dependency manager is developer autonomy.


feat: Windows fast launch

Add an option for enabling fast launch for Windows AMIs. This should speed up booting up of EC2 Windows runners.
Note that it does come with extra cost.
const ec2WindowsImageBuilder = Ec2RunnerProvider.imageBuilder(stack, 'Windows EC2 Builder', {
  os: Os.WINDOWS,
  vpc,
  awsImageBuilderOptions: {
    fastLaunchOptions: {
      enabled: true,
    },
  },
});
const runners = new GitHubRunners(stack, 'runners', {
  providers: [
    new Ec2RunnerProvider(stack, 'Fast Windows', {
      labels: ['windows'],
      imageBuilder: ec2WindowsImageBuilder,
    }),
  ],
}

Before:

After:

Resolves #466
Closes #514

Tried it out: Works super easy and great.
Only thing I have found - It had listed 6 subnets in the stepfunctions while I only provided 2.

Thanks! Not sure how the subnets can change as nothing was modified on the provider side. Would you mind sharing the code that limits to two subnets?

will check this next week and try it out in another account as well.

@kichik As promised I tried it out in another account with non-default vpc and it works as well in a super nice way. Havent seen any issues yet :) - so heres my approval :D

Thanks @pharindoko!


Plugin breaks zsh vi mode insert

If vi mode is on (bindkey -v), the following happens:

Type some text
Hit escape to enter normal mode
Navigate backwards on the line so your cursor is within that text
Pressing a (append) or i (insert) will cause any text after the cursor to disappear because autosuggestions kicks in with that text after the cursor as the suggestion, and once you diverge from it by inserting text, it's gone.

Contrast this with using the arrow keys to move backwards without ever leaving insert mode and any typed text is inserted in the middle as expected.

just for info: I'm using vi mode, and cannot reproduce your issue.

I'm sorry--I investigated further and the issue is I was doing something like this: http://superuser.com/questions/151803/how-do-i-customize-zshs-vim-mode/#answer-156204 and I think the call to zle reset-prompt inside zle-line-init was causing the issue.
Sorry for the confusion and many thanks for investigating!


"What district am I in"

Jeff expressed a desire to make a page where you can enter your own location, we use a geolocation IP (Google Maps) to get a lat-long pair for your location, then we use our maps to figure out what districts your location was in historically, so you can see who would have represented you through history.
I think this probably goes well with #17.

I wrote some code for address to lat-long lookups, which is stage 1 of this project. Next step is being able to map a lat-long to a district. My understanding is that our current JSON files are just shapefiles with no lat-long info in them.

Jeff has a proof of concept for the back-end lookup that can do a full lookup in about 2.5 seconds. We're going to test some more about the impact on Mongo's RAM use and then eventually build a page.

I have not done any UI work or really any functionality yet [please, no feedback on "can it do this" or "shouldn't it look like this" or "does it prevent against this"], but there is a page that at least is a proof of concept for speed, which is plenty fast.
http://<IP_ADDRESS>/district

Nice!!! With the right UI this is going to be great.
Sent from my iPhone

On Oct 20, 2016, at 5:56 PM, Aaron Rudkin<EMAIL_ADDRESS>wrote:
I have not done any UI work or really any functionality yet [please, no feedback on "can it do this" or "shouldn't it look like this" or "does it prevent against this"], but there is a page that at least is a proof of concept for speed, which is plenty fast.
http://<IP_ADDRESS>/district
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

This seems to be somewhat broken at the moment. Some addresses don't work and I can't get any dropdowns of legislators to appear.

Luke; this was a DB issue that popped up over the holidays. Adam mostly fixed it, but missed something with the district shapefiles. It is fixed now -- I will get back to finishing the UI stuff.

I wired up NOMINATE here, but it doesn't quite work. See #106

I implemented Jeff's line suggestion and tooltips so this function is provisionally "done" and I can mark this as closed.


Struct field conflict on exporting uncorrected maps

@jvelazquez-reyes we also have simulation tests running. It expects outputs to be the same (with what is saved) after modification.
When the default for exporting uncorrected maps is false, expected fields (e.g. T1 and M0) cannot be found in simulations. Please change default to true and see if this issue is resolved. If not, we'll need to find a solution to that.

Thanks for the latest changes @jvelazquez-reyes ! Looks like we have a test assertion failure for the mp2rage:
https://dev.azure.com/neuropoly/qMRLab/_build/results?buildId=1429&view=logs&j=c0e85002-b1bf-5d85-fa22-e1a871bbe3f3&t=428b0824-fd2f-5ea3-6a04-e0b334ebc4e5&l=2533
It complains that there is some change (exceeding 5%) for R1 after the latest changes pushed to the codebase. Can you look into it and see how this happened?

I will take a look.

Here's some tips for you @jvelazquez-reyes
If you do the following (in a directory that is not qMRLab):
setenv('ISCITEST','1');
qMRgenBatch(mp2rage,pwd);
setenv('ISCITEST','');

it will give you the script and data used in CI test. If you run mp2rage_batch, you will get the same error we saw on Azure.
Reason:
In the example dataset we have B1map, so in the previous versions The fields R1 and T1 were corrected maps. Now in the presence of a B1map we named these as R1cor and T1cor. So right now the  mapping is:

Saved results
New results

R1
R1cor

T1
T1cor

N/A
R1

N/A
T1

As you may have realized, we could have run into the same problem with mt_sat if there was a B1map in the example dataset.
Solution:
We need to update the example datasets on OSF. I can show you how to do that in a zoom call, and explain how example dataset versions are associated with qmrlab versions.

@agahkarakuzu thanks for this detailed review. I was suspecting it had to do with those mappings you mentioned.
I think everything is covered from the task list. It would only remain to check the CIs tests after updating the example datasets.
Ah, and please show me how to update those example datasets on OSF.

These issues have been resolved, thanks @jvelazquez-reyes !


Selector hardening: class and ID based selectors break when Google updates GMail

Hi all! Thanks! This extension is quite neat. (I'm using it in Firefox.)
In https://github.com/kallepersson/inboxtheme/blob/master/src/nodes.js & https://github.com/kallepersson/inboxtheme/blob/master/in.css, I see selectors are usually class-based. The obvious problem is that the class and ID names are generated each time GMail is rebuilt.
I suggest using selectors based on the DOM hierarchy instead.
For example, here's one to target the Inbox label:
[role=navigation] /* Source selector container */
> h2              /* Hidden label */
+ div             /* Wrapper */
> div[id]         /* Source selector list */
> div:first-child /* Primary selector list wrapper */
> div:first-child /* Primary selector list */
> div:first-child /* Inbox wrapper */
{
    border: 10px dotted purple;
}

I've formatted it with comments in the selector and broke the selector into newlines — and this is still valid CSS, as the amount of whitespace doesn't matter and comments can be almost anywhere! These two things make it much easier to figure out what's going on, and adapt it in the future, if Google decides to change their widgets.
While it is more generic, it can specifically target parts on the page better, as the widgets do not change every rebuild... and this should therefore make the selectors much more robust.
Obviously, a lot of selectors would use a lot of the same targeting (like everything up to the primary selector list for inbox, starred, snoozed, etc.), so building selector strings from pieces would make sense too.

Anyway, I'm suggesting this to reduce the amount of cat-and-mouse chasing the extension would have to do in the future.

Thanks Garrett, appreciate the feedback! :)
This makes perfect sense. The only thing I'd need to investigate is how likely it is that the DOM structure would change (e.g. as part of the UI is loaded dynamically).


Codebase cleanup with pylint

This change will cleanup the codebase with pylint:

Move pylint configuration to pyproject.toml and only use configurations we really need
Enable all checks and ignore the ones we don't need

Cleanups

Use ABC instead of ABCMeta
use contextlib.suppress
better naming, logging
ignore some pylint issues
Fix comprehensions
Remove useless usage of pass and else

thanks!


Bump path-to-regexp

Fixes a flagged security vulnerability in path-to-regexp

Obsoleted by #1945


Update php client constructor

Merges service address and port settings
Adds serviceScopes field
Simplifies constructor options

Codecov Report

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

@@            Coverage Diff            @@
##             master    #1882   +/-   ##
=========================================
  Coverage     85.32%   85.32%
  Complexity     4737     4737
=========================================
  Files           441      441
  Lines         18692    18692
  Branches       1989     1989
=========================================
  Hits          15949    15949
  Misses         2046     2046
  Partials        697      697

Continue to review full report at Codecov.

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


As a user I want to be able to configure the characters that can be emitted by the generator

Feature Request
Description of Problem:
Different character sets should be supported. Client systems may support different sets of characters, e.g. Unicode, ASCII, etc.
The character set could also describe the requirement over the casing of the emitted characters. Some systems are case insensitive others are not, as such the generator may need to take this into account.

As at 19/12/2018:

Priority: Low - there is no current need for this ability, but it should be considered in the fullness of time
Complexity: Low-Medium - would require:

The ability to provide the character set information by way of a constraint and/or at time of running the tool
Providing this information to the StringValueGenerator types to ensure they behave correctly
Updates to validation and merging to ensure they are correctly merged (i.e. you cannot widen a character set only narrow it (i.e. 👍 UTF-8 -> ASCII where as 👎 ASCII -> UTF-8)
a definition of character sets which are compatible and appropriate for all uses (e.g. more than just ASCII, UTF-8)

Reference: #200 where it has been identified that the generator can only accept plane-0 unicode characters (u0000-uffff).

I'd like to propose that this is raised to medium priority and is looked at quite soon after the beta

I agree, I think the data generator should default to one of the restricted sets, such that by default a String with no constraints won't default to outputting ቴ뱁","蘌ㇻ⑵锱ᖟ","ͭ結 for example but will output only Characters of the Latin alphabet and spaces.  (If the user wishes to specify more they can do).

Potentially solved by #1075

duplicated by ticket #1075

Removed from COntainingRegex-SpecialChars.feature:
Scenario: Running a 'containingRegex' request that includes special characters (emoji) only should be successful
Given foo is containing regex /[😁-😘]{1}/
And foo is of length 1
Then the following data should be generated:
| foo  |
| null |
| "😁" |
| "😂" |
| "😃" |
| "😄" |
| "😅" |
| "😆" |
| "😉" |
| "😊" |
| "😋" |
| "😌" |
| "😍" |
| "😏" |
| "😒" |
| "😓" |
| "😔" |
| "😖" |
| "😘" |


Create mypy cache directory

Proposed changes
MyPy expects the cache directory to be there. We now remove it after each super-linter run to avoid leftovers, so we need to create it before running MyPy.
See https://github.com/python/mypy/issues/10768
and https://github.com/python/mypy/issues/10863
Readiness checklist
In order to have this pull request merged, complete the following tasks.
Pull request author tasks

[x] I included all the needed documentation for this change.
[x] I provided the necessary tests.
[x] I squashed all the commits into a single commit.
[x] I followed the Conventional Commit v1.0.0 spec.
[x] I wrote the necessary upgrade instructions in the upgrade guide.
[x] If this pull request is about and existing issue,
I added the Fix #ISSUE_NUMBER label to the description of the pull request.

Super-linter maintainer tasks

[x] Label as breaking if this change breaks compatibility with the previous released version.
[x] Label as either: automation, bug, documentation, enhancement, infrastructure.

This bug only happens in certain scenarios when multiple Python files are linted but not in all cases that involve multiple Python files. In my case, it all revolved around a single module with utilities in an admittedly pointless subdirectory. I moved the file and gave it a less generic name which got it to work. Still, with super-linter 5.0.0, this did not happen.

Yeah, this was probably caused by #5210


Update license to GPL 3.0 or later

The current one maps to GPL 3 only.
Closes #1553
List of valid license identifier string obtained by
import requests
response = requests.get('https://sandbox.zenodo.org/api/licenses/?size=1000')
print(response.json())

Contributor Checklist:

[x] I have added or updated my entry in the creators.json file
[ ] I have added a changelog entry for my contribution
[ ] I have added/updated documentation for all user-facing changes
[ ] I have added/updated test cases
[ ] I have included the rebuilt production build of the client (only if changes were made to the GUI)

Reviewer Checklist:

[ ] /azp run libertem.libertem-data passed
[x] No import of GPL code from MIT code

#1553 says:

The current template gives GPL-2 only.

Which I agree would be incorrect.
But here:

The current one maps to GPL 3 only.

We actually don't specify the "or later" for the license. For example, from the README:

LiberTEM is licensed under GPLv3. The I/O parts are also available under the MIT license, please see LICENSE files in the subdirectories for details.

And in the setup.py:
    license='GPL v3',
[...]
        'License :: OSI Approved :: GNU General Public License v3 (GPLv3)',

So, I think this change might be incorrect.

Good point! I've updated this PR to 3.0 only. We'll see with the next RC if this is right


Some Hebrew letters appear with a square in JSON

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.86.0
OS Version: Windows 10

Steps to Reproduce:

Paste the following JSON in VS Code:

{
    "a": "אבגדהוזחטיכלמנסעפצקרשת1",
    "b": "סיוט"
}

The letters ו, ט, י and ס are highlighted when the word is followed by a number (with no space between), or when a word consists from these characters alone (e.g. סיוט).

the box is supposed to show when there are potentially confusing unicode characters mixed in with standard ascii characters
I guess it isn't handling Hebrew correctly
prob should have an exception made for it


Send resolved notification only when all alerts are solved

Similar to #1403, however, our use-case is different
What did you do?
Alert is launched as severity: warning, then raised to severity: critical but its lowered back to severity: warning.
What did you expect to see?
A resolved notification only after the entire (grouped) alarm is solved.
What did you see instead? Under which circumstances?
Critical alarm sends a resolved status. Therefore, the entire alarm is marked as solved.
Environment
Running with the kubernetes-mixin set (https://github.com/kubernetes-monitoring/kubernetes-mixin)
System information:
Kubernetes EKS 1.17
Alertmanager version:
Branch: HEAD
BuildDate: 20190708-14:31:49
BuildUser: root@868685ed3ed0
GoVersion: go1.12.6
Revision: 1ace0f76b7101cccc149d7298022df36039858ca
Version: 0.18.0

Prometheus version:
Version: 2.11.0
Revision: 4ef66003d9855ed2b7a41e987b33828ec36db34d
Branch: HEAD
BuildUser: root@0dc27cf95f36
BuildDate: 20190709-09:54:35
GoVersion: go1.12.7

Alertmanager configuration file:
...
global:
  resolve_timeout: 5m
receivers:
  - name: system-x
    webhook_configs:
      - url: [...]
        send_resolved: true

inhibit_rules:
- source_match:
    severity: "critical"
  target_match:
    severity: "warning"
  equal: [ alertname, name, server, common_name ]

route:
  group_by: [cluster, alertname]

  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: system-x

  routes:

  # Alarm for amq monitoring
  - receiver: system-x
    group_wait: 15s
    group_interval: 30s
    match_re:
      job: telegraf-amq-exporter|telegraf-ibm-wmq-exporter
    group_by: [alertname, name]
    repeat_interval: 3m

Timeline of alerts
11:00 -> Alarm 1 with severity: warning
11:00 -> Recieved notification of Alarm 1 with severity: warning
11:05 -> Alarm 1 raised to severity: critical
11:05 -> Recieved notification of Alarm 1 with severity: critical
11:10 -> Alarm 1 lowered to severity: warning
11:10 -> Recieved resolve of Alarm 1 with severity: critical
11:13 -> Recieved notification of Alarm 1 with severity: warning
Expected behaviour
After the entire (grouped) alarm has been cleared, only then the resolve status is being sent.

Any updates here?


ADLS Gen2: Acquire/Break Lease

Yes! This is very much needed. Also, need to fix azure cli to allow for break lease with ADLS Gen2 Hierarchal Namespaces!

Is there anything new on this? I've got a couple files that I can't manage to un-lease?

@SimRinguet How did you establish leases on your blobs? Do you have a workaround?


fix(client): revert "type": "commonjs" addition in generated package.json

Reverts prisma/prisma#25734 as discussed to fix https://github.com/prisma/prisma/issues/25761.

I think specifying type: commonjs is totally valid and helps in environment like deno.
To me it seems like it is an issue with Next.js if packages that correctly specify type: commonjs (prisma is a CJS package) no longer work.

This should have been fixed in Next.js rather than reverting a valid change in prisma.
Reverting this change just supports Next.js and their invalid handling of different package formats.

You both are right and I share the sentiment, but our goal is to not break the majority of our users, and realistically we have significantly more Next.js users. This is absolutely a bug that needs to be fixed upstream and it's unfortunate that we had to revert this to work around it (thus inconveniencing Deno users again), but we have to be pragmatic. If the breakage was introduced by a sudden change in Next.js without any changes on our side, then the considerations could have been different. Sorry for this, I understand that it is frustrating to you. We'll find a way forward.

@dodas @P4sca1 you're absolutely right, I'm pushing the issue forward on with the Next.js team, once it's resolved upstream will ping the Prisma team, even I'll introduce the cjs change again to get this resolved asap!


Surroundings(ds, das, etc.) don't seem to work

In Vim, when you type in ds in "vim/normal" mode, you can delete surroundings by typing in ds.  It seems to not work in vim-mode.

@nabsiddiqui I think you need the surround plugin for vim to get that behavior. There is another atom package that seems to add surround support: https://atom.io/packages/vim-surround

Thanks for the help.  I didn't know that package existed.  It only does some of the things that vim does though.  For instance, in a Markdown document heavy with prose, typing in 'das' would usually delete the current sentence.  The vim-surround package, on the other hand, seems to only delete a couple of markers surrounding quotes, parenthesis, etc.

As stated in the README, this package is no longer maintained and is deprecated. We recommend that people use the vim-mode-plus package instead. Because of this, we are archiving this repository and closing all issues and pull requests. Thanks very much for your support and contributions!


[WIRES] Use wire class in operations

This PR is part of the wire management refactor. It changes the wires attribute of operators to be a Wires instance, but then turns it back into a list wherever the attribute is used. At this stage, we still assume that wires are sequences of consecutive integers.
Changes

Uses a Wires instance for the wires attribute in the Operator class, but converts wires back to lists everywhere the attribute is used.

A lot of tests of the form assert xyz.wires == [1] were updated to assert xyz.wires == Wires([1]).

A few TODO tags where dropped to mark obvious places where future PRs in this series need to check the wire ordering.

The templates can now use Wires objects, and conversions to lists were deleted.

Please ignore the coverage for now, I will fix this before merging.

@josh146 Thanks for your review, you found a couple of things I overlooked.
As mentioned, I think most of your comments may be resolved by noting that an iteration over a Wires object returns Wires objects of length one:

@co9olguy I wonder if you could add your review? The main PR to remove all the tolist() is yet to come :)


Remove old extension from parentElement

Summary
Fixes https://github.com/rancher/dashboard/issues/11559

Occurred changes and/or fixed issues

Technical notes summary

Areas or cases that should be tested

Areas which could experience regressions

Screenshot/Video

Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

In the last commit we are limiting the removeChild for oldPlugins only  https://github.com/rancher/dashboard/blob/d221ed9fd6b3cc4f1222f42dd14b88512d539073/shell/core/plugins.js#L94-L96
thanks for the suggestion @richard-cox


Move src/setup_payload/tests to auto-test-driver generation

Part of a larger cleanup. Replacing folder one by one since mass-replacement seemed to have resulted in some harder to track dependency errors.

This makes the unit tests run on zephyr and qemu/esp32 as well as a sideeffect


1-Overview-Tools-Acquisition - Update the command lines

I had to add/update some of the command lines to be able to run the script for the first part of the workshop.

Duplicated in some other pull requests, but thanks!


implemented dask array indexing for GrB_extract for Vector and Matrix

Hi @eriknw
By mirroring the dask array source code for dask.array.Array.__getitem__(), I've been able to implement dask array indexing for GrB_extract.  🎉
Unit-tests test_extract() in test_matrix.py and test_vector.py in folder from_grblas have passed.
I'm yet to run the slower tests with masking.
Just got out of one rabbit hole.     Diving into the next ... GrB_assign ...

Just implemented masked Grb_extract for Vector.  Tests passed.  🎉
Need to write analogous tests for Matrix.
Oops! It turns out test_extract_row(column) are not yet implemented.

Wait! test_extract_row(column) works.  It's just the transpose part, such as
w << A.T[2, [1, 3, 5]]

that is not yet implemented.  In fact, the transpose part of both extract and assign for Matrix has not been implemented at all.


Cannot install latest amuse. Is it a problem of my setup or the release?

I cannot install amuse via
pip install amuse
in Ubuntu 16.04. I have installed all prerequisites apart from libmpfr6. I use libmpfr4. I do not know if this is the problem. The output is 592 lines. I give the basic errors here:
Installing build dependencies ... error
ERROR: Command errored out with exit status 1:
ERROR: Failed building wheel for amuse-simplex
Running setup.py clean for amuse-simplex
Failed to build amuse-galaxia amuse-simplex
ERROR: Could not build wheels for amuse-galaxia, amuse-simplex which use PEP 517 and cannot be installed directly

Hi,
this is probably a problem with MPI and one of the codes in AMUSE (simplex) which uses deprecated cpp bindings. You can force the install to complete by setting an environment variable:
export AMUSE_ALLOW_BUILD_FAILURES=all

before install. (of course, the failed codes will not work...)

@rieder maybe we should remove simplex from the amuse pip package for now? It can always be added explicitly with pip install amuse-simplex ..

I don't know the reason for the failure of galaxia this was noted before #467

I think the problem with Simplex is both what @ipelupessy mentioned and that it needs hdf5 libraries (at the time amuse-framework is installed). Not sure if we mention this clearly enough.
I don't think we should remove it from the amuse package just now.

hi, I cannot install amuse via
pip install amuse in macOS, because I have this problem:
I tried to use your command (export AMUSE_ALLOW_BUILD_FAILURES=all) but it didn't work
ERROR: Command errored out with exit status 1:
command: /Users/paulo/anaconda2/envs/amuse.2.7py/bin/python /Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/site-packages/pip install --ignore-installed --no-user --prefix /private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-GxVJ2R/overlay --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- 'amuse-framework>=12.1.3[MPI]' 'amuse-athena>=12.1.3' 'amuse-bhtree>=12.1.3' 'amuse-brutus>=12.1.3' 'amuse-bse>=12.1.3' 'amuse-capreole>=12.1.3' 'amuse-evtwin>=12.1.3' 'amuse-fastkick>=12.1.3' 'amuse-fi>=12.1.3' 'amuse-fractalcluster>=12.1.3' 'amuse-gadget2>=12.1.3' 'amuse-galactics>=12.1.3' 'amuse-galaxia>=12.1.3' 'amuse-halogen>=12.1.3' 'amuse-hermite>=12.1.3' 'amuse-hop>=12.1.3' 'amuse-huayno>=12.1.3' 'amuse-kepler>=12.1.3' 'amuse-kepler-orbiters>=12.1.3' 'amuse-mameclot>=12.1.3' 'amuse-mercury>=12.1.3' 'amuse-mmams>=12.1.3' 'amuse-ph4>=12.1.3' 'amuse-seba>=12.1.3' 'amuse-secularmultiple>=12.1.3' 'amuse-smalln>=12.1.3' 'amuse-sphray>=12.1.3' 'amuse-sse>=12.1.3' 'amuse-twobody>=12.1.3'
cwd: None
Complete output (130 lines):
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Collecting amuse-framework>=12.1.3[MPI]
Using cached https://files.pythonhosted.org/packages/6c/bd/08d3db4d89d4419b73f8f9633355b6ac04c6d8f2d8df7ef227ed5e5c573d/amuse-framework-12.1.3.post1.tar.gz
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Preparing wheel metadata: started
Preparing wheel metadata: finished with status 'done'
Collecting amuse-athena>=12.1.3
Using cached https://files.pythonhosted.org/packages/a8/31/1a6a3df93e53a91b9cc3e570a22d0774943b4abc0808f9bfc154a83c94de/amuse-athena-12.1.3.post1.tar.gz
Installing build dependencies: started
Installing build dependencies: finished with status 'error'
ERROR: Command errored out with exit status 1:
command: /Users/paulo/anaconda2/envs/amuse.2.7py/bin/python /Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/site-packages/pip install --ignore-installed --no-user --prefix /private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-eF81TW/overlay --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- setuptools wheel amuse-framework
cwd: None
Complete output (111 lines):
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Collecting setuptools
Using cached https://files.pythonhosted.org/packages/f9/d3/955738b20d3832dfa3cd3d9b07e29a8162edb480bf988332f5e6e48ca444/setuptools-44.0.0-py2.py3-none-any.whl
Collecting wheel
Using cached https://files.pythonhosted.org/packages/00/83/b4a77d044e78ad1a45610eb88f745be2fd2c6d658f9798a15e384b7d57c9/wheel-0.33.6-py2.py3-none-any.whl
Collecting amuse-framework
Using cached https://files.pythonhosted.org/packages/6c/bd/08d3db4d89d4419b73f8f9633355b6ac04c6d8f2d8df7ef227ed5e5c573d/amuse-framework-12.1.3.post1.tar.gz
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Preparing wheel metadata: started
Preparing wheel metadata: finished with status 'done'
Collecting pip>=19.0.0
Using cached https://files.pythonhosted.org/packages/00/b6/9cfa56b4081ad13874b0c6f96af8ce16cfbc1cb06bedf8e9164ce5551ec1/pip-19.3.1-py2.py3-none-any.whl
Collecting h5py>=1.1.0
Using cached https://files.pythonhosted.org/packages/2c/47/e0d58be6f292684a4541d10b1da953542ff679f3ffc6096bee73634832b1/h5py-2.10.0-cp27-cp27m-macosx_10_6_intel.whl
Collecting docutils>=0.6
Using cached https://files.pythonhosted.org/packages/3a/dc/bf2b15d1fa15a6f7a9e77a61b74ecbbae7258558fcda8ffc9a6638a6b327/docutils-0.15.2-py2-none-any.whl
Collecting nose>=0.11.1
Using cached https://files.pythonhosted.org/packages/99/4f/13fb671119e65c4dce97c60e67d3fd9e6f7f809f2b307e2611f4701205cb/nose-1.3.7-py2-none-any.whl
Collecting numpy>=1.2.2
Using cached https://files.pythonhosted.org/packages/09/96/84cf406fe7d589f3dba9fc0f737e65985a3526c6d8c783f02d4b5a10825d/numpy-1.16.6-cp27-cp27m-macosx_10_9_x86_64.whl
Collecting six
Using cached https://files.pythonhosted.org/packages/65/26/32b8464df2a97e6dd1b656ed26b2c194606c16fe163c695a992b36c11cdf/six-1.13.0-py2.py3-none-any.whl
Building wheels for collected packages: amuse-framework
Building wheel for amuse-framework (PEP 517): started
Building wheel for amuse-framework (PEP 517): finished with status 'error'
ERROR: Command errored out with exit status 1:
command: /Users/paulo/anaconda2/envs/amuse.2.7py/bin/python /Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/site-packages/pip/_vendor/pep517/_in_process.py build_wheel /var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/tmpEmZyge
cwd: /private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-install-778VfG/amuse-framework
Complete output (74 lines):
running bdist_wheel
running build
running configure_codes
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules _winreg, win32api or win32con are installed.
get_default_fcompiler: matching types: '['gnu95', 'nag', 'absoft', 'ibm', 'intel', 'gnu', 'g95', 'pg']'
customize Gnu95FCompiler
Could not locate executable gfortran
Could not locate executable f95
customize NAGFCompiler
customize AbsoftFCompiler
Could not locate executable f90
Could not locate executable f77
customize IBMFCompiler
Could not locate executable xlf90
Could not locate executable xlf
customize IntelFCompiler
Could not locate executable ifort
Could not locate executable ifc
customize GnuFCompiler
Could not locate executable g77
customize G95FCompiler
Could not locate executable g95
customize PGroupFCompiler
Could not locate executable pgfortran
don't know how to compile Fortran code on platform 'posix'
Running configure for AMUSE
config.mk not generated; output of configure:
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in /private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-install-778VfG/amuse-framework':       configure: error: C compiler cannot create executables       See config.log' for more details
  Traceback (most recent call last):
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/site-packages/pip/_vendor/pep517/_in_process.py", line 257, in <module>
      main()
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/site-packages/pip/_vendor/pep517/_in_process.py", line 240, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/site-packages/pip/_vendor/pep517/_in_process.py", line 182, in build_wheel
      metadata_directory)
    File "/private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-sdaA9_/overlay/lib/python2.7/site-packages/setuptools/build_meta.py", line 209, in build_wheel
      wheel_directory, config_settings)
    File "/private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-sdaA9_/overlay/lib/python2.7/site-packages/setuptools/build_meta.py", line 194, in _build_with_temp_dir
      self.run_setup()
    File "/private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-sdaA9_/overlay/lib/python2.7/site-packages/setuptools/build_meta.py", line 237, in run_setup
      self).run_setup(setup_script=setup_script)
    File "/private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-sdaA9_/overlay/lib/python2.7/site-packages/setuptools/build_meta.py", line 142, in run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 77, in <module>
      scripts=[ "bin/amusifier" ],
    File "/private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-sdaA9_/overlay/lib/python2.7/site-packages/setuptools/__init__.py", line 145, in setup
      return distutils.core.setup(**attrs)
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/distutils/core.py", line 151, in setup
      dist.run_commands()
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/distutils/dist.py", line 953, in run_commands
      self.run_command(cmd)
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/distutils/dist.py", line 972, in run_command
      cmd_obj.run()
    File "/private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-sdaA9_/overlay/lib/python2.7/site-packages/wheel/bdist_wheel.py", line 192, in run
      self.run_command('build')
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/distutils/cmd.py", line 326, in run_command
      self.distribution.run_command(command)
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/distutils/dist.py", line 972, in run_command
      cmd_obj.run()
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/distutils/command/build.py", line 127, in run
      self.run_command(cmd_name)
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/distutils/cmd.py", line 326, in run_command
      self.distribution.run_command(command)
    File "/Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/distutils/dist.py", line 972, in run_command
      cmd_obj.run()
    File "/private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-install-778VfG/amuse-framework/support/setup_codes.py", line 1169, in run
      raise Exception("configure failed")
  Exception: configure failed
  ----------------------------------------
  ERROR: Failed building wheel for amuse-framework
  Running setup.py clean for amuse-framework
Failed to build amuse-framework
ERROR: Could not build wheels for amuse-framework which use PEP 517 and cannot be installed directly
----------------------------------------

ERROR: Command errored out with exit status 1: /Users/paulo/anaconda2/envs/amuse.2.7py/bin/python /Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/site-packages/pip install --ignore-installed --no-user --prefix /private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-eF81TW/overlay --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- setuptools wheel amuse-framework Check the logs for full command output.
ERROR: Command errored out with exit status 1: /Users/paulo/anaconda2/envs/amuse.2.7py/bin/python /Users/paulo/anaconda2/envs/amuse.2.7py/lib/python2.7/site-packages/pip install --ignore-installed --no-user --prefix /private/var/folders/bn/mj43q7r53tx42h6kx57q2sn80000gn/T/pip-build-env-GxVJ2R/overlay --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- 'amuse-framework>=12.1.3[MPI]' 'amuse-athena>=12.1.3' 'amuse-bhtree>=12.1.3' 'amuse-brutus>=12.1.3' 'amuse-bse>=12.1.3' 'amuse-capreole>=12.1.3' 'amuse-evtwin>=12.1.3' 'amuse-fastkick>=12.1.3' 'amuse-fi>=12.1.3' 'amuse-fractalcluster>=12.1.3' 'amuse-gadget2>=12.1.3' 'amuse-galactics>=12.1.3' 'amuse-galaxia>=12.1.3' 'amuse-halogen>=12.1.3' 'amuse-hermite>=12.1.3' 'amuse-hop>=12.1.3' 'amuse-huayno>=12.1.3' 'amuse-kepler>=12.1.3' 'amuse-kepler-orbiters>=12.1.3' 'amuse-mameclot>=12.1.3' 'amuse-mercury>=12.1.3' 'amuse-mmams>=12.1.3' 'amuse-ph4>=12.1.3' 'amuse-seba>=12.1.3' 'amuse-secularmultiple>=12.1.3' 'amuse-smalln>=12.1.3' 'amuse-sphray>=12.1.3' 'amuse-sse>=12.1.3' 'amuse-twobody>=12.1.3' Check the logs for full command output.

@pasolar I've moved your question to #565 as it is separate from this issue.

@rieder oka thanks


test_comparedb3.py has very few unit tests

It has a few small unit tests, and two integration tests that don't touch all possible cases. Unit tests for all the other functions are needed.
This was discovered when the need for PR #786 was discovered.

We have raised the code coverage from 60% to 83%:
https://coveralls.io/builds/51061594/source?filename=armi%2Fbookkeeping%2Fdb%2FcompareDB3.py
I think most of what is left are exceptions and errors.  Which we have not done a lot of testing for yet in ARMI.  Sadly.

This file is at 85% now, and I think the tests look pretty good. (Obviously, I will want them above 90% one day soon.)
But I am just going to close this ticket.


Arrow not drawn on correct position when moving linked element

Arrow not drawn on correct position when moving linked element

The png export shows the arrow at the correct position.

Example: https://excalidraw.com/#json=6182680924258304,jVToHsvJ6j84aATTIHLeQQ

Interesting. Probably not necessary to fix the bug, but how did you manage to get it to that state? I can't seem to repro with new elements and arrows.

I'm having a hard time trying to reproduce it 😅

Nevertheless, I've opened a PR  https://github.com/excalidraw/excalidraw/pull/3633 that at least normalizes the points on restore (refresh/paste...). Not a true fix, but better than nothing.
In the meantime, you can edit the arrows (doubleclick/enter) which currently normalizes the points as well.


Add stateless_apply

This PR adds a small function, partial_apply, which is needed to implement an extension in Symbolics for LuxCore (see https://github.com/JuliaSymbolics/Symbolics.jl/pull/1054), allowing the registration of the application of the layer as a vectror function. The important aspect here is that we need the size of the return type of the function, which is why we only return the first argument from apply.
Let me know what you think about this approach.
cc @ChrisRackauckas
Edit: renamed to stateless_apply.

If Symbolics is the only place this will be used, doesn't it make more sense to define it there exclusively?
function partial_apply end

in the main package, and then place the code you wrote here in the extension

I was thinking that this could also be used when one does not need st outside of the use with Symbolics.
For example https://docs.sciml.ai/Overview/stable/showcase/missing_physics/#Definition-of-the-Universal-Differential-Equation could change the UDE prediction from
û = U(u, p, _st)[1] # Network prediction

to
û = LuxCore.partial_apply(U, u, p, _st) # Network prediction

This could also be reexported by Lux for discoverability / ease of use.

To be a nice tool for Lux, it would be nice if it varified the network was stateless, since this is useful only for stateless networks but for such a case it's really common

it would be nice if it varified the network was stateless

Would something like this be a good way to check?
out, st = apply(model, x, ps, st)
@assert isempty(st) "The passed model is not stateless, please use `apply` instead."
out

I renamed the function to stateless_apply and I've added error messages for stateful cases. Does this look good now?

Don't worry about the GPU CI for now, it seems to be down due to storage issues

I think I got the AbstractExplicitContainerLayer implementation now 😅

Would it make sense to have a get_state (or a better name) function that constructs the st and implement stateless_apply with the last argument as st=get_state(...)? I was thinking that in performance sensitive scenarios it might make sense to have the st cached instead of re-creating it all the time.

So the st if created correctly is a compile-time constant, so it shouldn't have a performance implication.
But I am still unsure of what we get by having this as part of the API (and just being part of Symbolics), since I have seen very rare instances of anyone directly using apply except when creating custom layers.

This stateless_apply is needed for defining the extension, but it can't be defined in the extension and it doesn't make much sense to define in Symbolics (since it can't be used in Symbolics outside of the extension), which is why I started this PR in the first place 😅
As for usages of apply, I think the UDE tutorial should use this, as mentioned in https://github.com/LuxDL/LuxCore.jl/pull/18#issuecomment-1944417510
I'm not sure how relevant is that for Lux though.

getstate is internal so naming it _getstate. Maybe we should name it _getemptystate instead of _getstate.
Can you take a relatively complex Lux model, and check that _getstate is a compile time constant?

Maybe we should name it _getemptystate instead of _getstate.

I was wondering if _getstate would be useful for stateful cases, where one could add a method for that, but again, I don't know it there are any applications where this would be useful.

Can you take a relatively complex Lux model, and check that _getstate is a compile time constant?

Do you have any suggestions? I tried
model = Lux.Chain(Lux.Dense(3,3), Parallel(+, Lux.Dense(3,3), Lux.Dense(3,3)))

locally, but I'm not sure if that's good enough.

For stateful cases that is just initialstates

use a couple more nesting for chain and turn off optimizations (see the kwarg in https://lux.csail.mit.edu/dev/api/Lux/layers#Lux.Chain)

julia> model = Lux.Chain(Lux.Dense(3,3), Parallel(+, Lux.Dense(3,4), Parallel(+, Lux.Dense(3,4), Parallel(+, Lux.Dense(3,4), Lux.Dense(3,4)), Lux.Dense(3,4)), Lux.Dense(3,4)), disable_optimizations=true)
Chain(
    layer_1 = Dense(3 => 3),            # 12 parameters
    layer_2 = Parallel(
        +
        Dense(3 => 4),                  # 16 parameters
        Parallel(
            +
            Dense(3 => 4),              # 16 parameters
            Parallel(
                +
                Dense(3 => 4),          # 16 parameters
                Dense(3 => 4),          # 16 parameters
            ),
            Dense(3 => 4),              # 16 parameters
        ),
        Dense(3 => 4),                  # 16 parameters
    ),
)         # Total: 108 parameters,
          #        plus 0 states.

julia> x = rand(3)
3-element Vector{Float64}:
 0.5396312192884193
 0.2939048617340425
 0.24219473008713432

julia> ps, st = LuxCore.setup(rng, model)
((layer_1 = (weight = Float32[-0.5638304 0.7064836 -0.68545914; 0.9561393 -0.063563704 -0.115722895; 0.24014795 0.41213036 -0.54157174], bias = Float32[0.0; 0.0; 0.0;;]), layer_2 = (layer_1 = (weight = Float32[0.1435352 0.12118944 0.71831423; 0.038405616 0.57530284 0.88325536; -0.32796544 -0.6643518 0.2772332; 0.818112 -0.06508801 0.00029843062], bias = Float32[0.0; 0.0; 0.0; 0.0;;]), layer_2 = (layer_1 = (weight = Float32[0.0021485018 -0.27785414 0.61988515; 0.39966893 -0.22878593 -0.6069017; 0.78745824 -0.33321932 0.36335143; -0.5742856 0.1219567 -0.31968322], bias = Float32[0.0; 0.0; 0.0; 0.0;;]), layer_2 = (layer_1 = (weight = Float32[0.7534941 -0.603465 0.042327706; 0.24461655 0.42317894 -0.6764314; -0.46775734 -0.21744843 0.7626165; -0.2330453 -0.92067915 0.059065647], bias = Float32[0.0; 0.0; 0.0; 0.0;;]), layer_2 = (weight = Float32[0.16759352 -0.121825255 0.85951114; -0.7903339 0.75350535 -0.24590242; -0.0746273 -0.20504689 -0.61860776; 0.0032513929 -0.70960593 0.7057774], bias = Float32[0.0; 0.0; 0.0; 0.0;;])), layer_3 = (weight = Float32[-0.42817247 -0.8049099 -0.3437964; 0.31827924 0.83317935 -0.28295153; -0.7879606 -0.43561655 0.04584453; -0.037287604 -0.8772459 0.5911436], bias = Float32[0.0; 0.0; 0.0; 0.0;;])), layer_3 = (weight = Float32[0.097560994 -0.7195461 0.3436186; 0.5422182 -0.052859966 0.81801933; 0.25912023 -0.013861904 0.33478278; 0.86514133 -0.56700957 0.31364506], bias = Float32[0.0; 0.0; 0.0; 0.0;;]))), (layer_1 = NamedTuple(), layer_2 = (layer_1 = NamedTuple(), layer_2 = (layer_1 = NamedTuple(), layer_2 = (layer_1 = NamedTuple(), layer_2 = NamedTuple()), layer_3 = NamedTuple()), layer_3 = NamedTuple())))

julia> LuxCore.apply(model, x, ps, st)
([-1.054777648714576, 0.869948369838022, -0.5773222915067829, -1.475737151147033], (layer_1 = NamedTuple(), layer_2 = (layer_1 = NamedTuple(), layer_2 = (layer_1 = NamedTuple(), layer_2 = (layer_1 = NamedTuple(), layer_2 = NamedTuple()), layer_3 = NamedTuple()), layer_3 = NamedTuple())))

julia> LuxCore.stateless_apply(model, x, ps)
4-element Vector{Float64}:
 -1.054777648714576
  0.869948369838022
 -0.5773222915067829
 -1.475737151147033

works after switching the getfield to use names instead of Ints, as that fails on Parallel.

Tested that it infers locally:
julia> @code_typed LuxCore._getemptystate(model)
CodeInfo(
1 ─     return $(QuoteNode((layer_1 = NamedTuple(), layer_2 = (layer_1 = NamedTuple(), layer_2 = (layer_1 = NamedTuple(), layer_2 = (layer_1 = NamedTuple(), layer_2 = NamedTuple()), layer_3 = NamedTuple()), layer_3 = NamedTuple()))))
) => @NamedTuple{layer_1::@NamedTuple{}, layer_2::@NamedTuple{layer_1::@NamedTuple{}, layer_2::@NamedTuple{layer_1::@NamedTuple{}, layer_2::@NamedTuple{layer_1::@NamedTuple{}, layer_2::@NamedTuple{}}, layer_3::@NamedTuple{}}, layer_3::@NamedTuple{}}}

Do you want me to release this or wait till Symbolics Ext is ready?

It would be useful to have this released so that I can check the extension in CI too.


Fix: Dynamic device selection in Chat Templates notebook

Updated the Chat Templates notebook to dynamically select the device
(CUDA, MPS, or CPU) for compatibility across various environments.
Changes:

Replaced the hardcoded "mps" with a dynamic device selection snippet.
Tested on Colab with CPU and locally with MPS.

This change ensures the notebook works seamlessly across different hardware setups.

Thanks for this! It makes the course more accessible!

Of course!


Deploy phase keeps getting stuck at "Updating Edge config"

Our deploys periodically get stuck at "Updating Edge config".
It happened today:
2021-01-15T22:30:18 [INFO]: Starting Deployment
2021-01-15T22:30:19 [INFO]: Updating Edge config

Also happened last week:
2021-01-07T21:24:46 [INFO]: Starting Deployment
2021-01-07T21:24:47 [INFO]: Updating Edge config

Many others have also noted this failure (see #1417 #1387 #1395 #1167 #1313 #1380 #1250).

Can you provide your app Id and region?

Can you provide your app Id and region?

Region: us-east-1
App ID I think: d2lnj6dcs32j7m

Region: us-east-1
App ID I think: d2lnj6dcs32j7m

We are experiencing the same issue, except it always gets stuck at Updating Edge config step whenever we try to deploy a file from S3. Manual deployments when uploading a file directly works without issues. Tried restarting a few times and waiting for a few hours, but nothing happens. Also tried creating new S3 Buckets and new apps but no changes... Had an attempt to wait overnight but then it just failed without any additional logs. Strange that this was working two days ago...

We are experiencing the same issue, except it always gets stuck at Updating Edge config step whenever we try to deploy a file from S3. Manual deployments when uploading a file directly works without issues. Tried restarting a few times and waiting for a few hours, but nothing happens. Also tried creating new S3 Buckets and new apps but no changes... Had an attempt to wait overnight but then it just failed without any additional logs. Strange that this was working two days ago...

@arnaskro Can you provide your app ID and region?
@ryanbagwell We have root caused intermittent issues that may be affecting your deployments and a fix is being pushed shortly. We will continue to monitor, but the reliability of your deployments should be better in the coming days.

@arnaskro Can you provide your app ID and region?
@ryanbagwell We have root caused intermittent issues that may be affecting your deployments and a fix is being pushed shortly. We will continue to monitor, but the reliability of your deployments should be better in the coming days.

@hsspain the issue has went away around 2 days ago... We haven't changed anything, just tried creating a new deployment some time after commenting here.
Since then we already tried creating new apps and there are no issues for now 😄
This was in the eu-north-1region

@hsspain the issue has went away around 2 days ago... We haven't changed anything, just tried creating a new deployment some time after commenting here.
Since then we already tried creating new apps and there are no issues for now 😄
This was in the eu-north-1region

@arnaskro Thank you for the update. We will continue to monitor and the latest update should also increase your reliability in the coming days.

@arnaskro Thank you for the update. We will continue to monitor and the latest update should also increase your reliability in the coming days.

@hsspain still running into errors here.
Stuck in the deploy phase just now:
2021-01-22T20:31:37 [INFO]: Starting Deployment
2021-01-22T20:31:37 [INFO]: Updating Edge config
uildId<PHONE_NUMBER>
2021-01-22T20:31:59 [INFO]: Got archive:<PHONE_NUMBER> bytes
2021-01-22T20:33:04 [INFO]: Deployment complete

@hsspain still running into errors here.
Stuck in the deploy phase just now:
2021-01-22T20:31:37 [INFO]: Starting Deployment
2021-01-22T20:31:37 [INFO]: Updating Edge config
uildId<PHONE_NUMBER>
2021-01-22T20:31:59 [INFO]: Got archive:<PHONE_NUMBER> bytes
2021-01-22T20:33:04 [INFO]: Deployment complete

@ryanbagwell We are looking into this now.

@ryanbagwell We are looking into this now.

@ryanbagwell We are not seeing any issues with that build or the one that happen subsequently. The build and deployment succeeded in both cases which should reflect in the console.  Are you still seeing the job stuck in the deploy phase?

@ryanbagwell We are not seeing any issues with that build or the one that happen subsequently. The build and deployment succeeded in both cases which should reflect in the console.  Are you still seeing the job stuck in the deploy phase?

@hsspain sorry, you're right, I'm not being careful. Something's definitely wonky though. I manually cancelled several builds today but it looks like they were never cancelled as I see them listed as "succeeded."
I'll keep an eye on things and if I can be more precise I'll post back here.

@hsspain sorry, you're right, I'm not being careful. Something's definitely wonky though. I manually cancelled several builds today but it looks like they were never cancelled as I see them listed as "succeeded."
I'll keep an eye on things and if I can be more precise I'll post back here.

Closing this for now.  If anyone is still experiencing issues please re-open and provide your appId and region so we can take a look.

I think i am having similar issue to this one. My appId=dv86zirxr0et3 and region=eu-central-1. Thanks for any help

Facing same issue that nothing gets deployed to the S3 bucket.
Though same thing is working fine if we do amplify publish from cli
appId = d2qksd9d6escp7
resion =  us-east-1

2022-01-24T19:33:30 [INFO]: Starting Deployment
2022-01-24T19:33:30 [INFO]: Updating Edge config
ue, buildId<PHONE_NUMBER>
2022-01-24T19:33:30 [INFO]: Got archive: 4395275 bytes
2022-01-24T19:33:32 [INFO]: Deployment complete


Wrong permissions of .SRCINFO

Hello
I have installed pkgbuild-introspection-git-6.4.ga135f86-1 and mkaurball creates .SRCINFO with wrong permission 0664.
Could you fix it?

No, because I don't know what needs fixing given your sparse bug report. If you're using pacman 4.2.0, then the problem likely isn't in mkaurball, it's in makepkg. If you're using an older version of pacman, what is your umask set to?

My mistake, you were right and I'm using pacman 0.4.2.
So I'll check makepkg and bugtracker.
Best regards.


WSL2 only recognizes L3 cache from 1 chiplet

Version
Microsoft Windows [Version 10.0.22000.708]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
20.04
Other Software
WSL version: <IP_ADDRESS>
WSLg version: 1.0.34
Repro Steps
Have chiplet based processor.
Start WSL2.
Run lscpu
Look at L3 cache. L3 cache is equal to that of only 1 chiplet.
Expected Behavior
Even considering the existing processor group bug in which WSL2 only sees 32 of 64 cores, one should still expect 128MiB of L3 cache out of the 256MiB L3.
5950x should return 64MiB L3.
1950x should return 32MiB L3
Actual Behavior
3990X
L3 cache:                        16 MiB/256MiB  or 16MiB/128MiB after considering the processor group bug.
5950x
L3 cache:                        32 MiB/64MiB
Strangely, 1950x returns the correct amount of L3 cache.
1950x
L3 cache:                        32 MiB/32MiB
This bug is present on 2 of 3 chiplet based CPUs tested.
 It's possible that the NUMA "fix" in Win 11 is the cause of the cache problems.
If someone could chime in with LSCPU from Win10 with these or a related processor that would be appreciated.

@Thernn88  use a live distro, or boot into Linux, and see if lscpu reports the same info as inside WSL. Post the results please. Thx!

ubuntu@ubuntu:~$ lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   48 bits physical, 48 bits virtual
CPU(s):                          1
On-line CPU(s) list:             0
Thread(s) per core:              1
Core(s) per socket:              1
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       AuthenticAMD
CPU family:                      23
Model:                           49
Model name:                      AMD Ryzen Threadripper 3990X 64-Core Processor
Stepping:                        0
CPU MHz:                         2894.576
BogoMIPS:                        5789.15
Hypervisor vendor:               KVM
Virtualization type:             full
L1d cache:                       32 KiB
L1i cache:                       32 KiB
L2 cache:                        512 KiB
L3 cache:                        256 MiB

So, KVM hypervisor gets it right! I suspect Hyper-V is the issue. WSL rides on top of Hyper-V.

Yes, I found it interesting that correct amount of L3 for the 1950x was reported in the Win10 WSL2 instance.
Only the 5950x and 3990x reported lower L3 and these are both on Win 11.
Possibly a Win 11 only Hyper-V bug?
If others chime in with lscpu from these or close models on Win 10 which report correct L3 (or 128mb for 3990x) that would isolate it as a Win 11 bug.  I have no idea where to report those...

Still an issue in current as of below as well as after update to 22.04. WSL only has access to 16MB of L3 Cache instead of the expected 128MB (256MB if CPU Cores > 64 bug is fixed).
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.42
Caches (sum of all):
L1d:                   1 MiB (32 instances)
L1i:                   1 MiB (32 instances)
L2:                    16 MiB (32 instances)
L3:                    16 MiB (1 instance)
This is ignoring the already existing bug where WSL only sees up to 64 cores.

After further investigation it turns out the L3 cache is actually fully detected.
I ran
3990x
$ getconf -a | grep CACHE
LEVEL1_ICACHE_SIZE                 32768
LEVEL1_ICACHE_ASSOC
LEVEL1_ICACHE_LINESIZE             64
LEVEL1_DCACHE_SIZE                 32768
LEVEL1_DCACHE_ASSOC                8
LEVEL1_DCACHE_LINESIZE             64
LEVEL2_CACHE_SIZE                  524288
LEVEL2_CACHE_ASSOC                 8
LEVEL2_CACHE_LINESIZE              64
LEVEL3_CACHE_SIZE                  268435456
LEVEL3_CACHE_ASSOC                 0
LEVEL3_CACHE_LINESIZE              64
LEVEL4_CACHE_SIZE
LEVEL4_CACHE_ASSOC
LEVEL4_CACHE_LINESIZE
268435456 ~= 256MB of L3
5950x
$ getconf -a | grep CACHE
LEVEL1_ICACHE_SIZE                 32768
LEVEL1_ICACHE_ASSOC                8
LEVEL1_ICACHE_LINESIZE             64
LEVEL1_DCACHE_SIZE                 32768
LEVEL1_DCACHE_ASSOC                8
LEVEL1_DCACHE_LINESIZE             64
LEVEL2_CACHE_SIZE                  524288
LEVEL2_CACHE_ASSOC                 8
LEVEL2_CACHE_LINESIZE              64
LEVEL3_CACHE_SIZE                  67108864
LEVEL3_CACHE_ASSOC                 0
LEVEL3_CACHE_LINESIZE              64
LEVEL4_CACHE_SIZE                  0
LEVEL4_CACHE_ASSOC                 0
LEVEL4_CACHE_LINESIZE              0
67108864 ~= 64MB of L3
It is a longstanding problem that LSCPU sometimes has issues with exotic CPU configurations. Now it beats me as to why LSCPU works with KVM but falls on its face for Hyper-V. Thus, it seems there is still a bug although it is most likely visual.
The limitation to 64 cores, however, still appears valid.

I have a 7950X3D. The problem is more severe because this CPU has different cache sizes for each CCX.
In my environment, both CCXs are reported to have 96MiB of L3 cache, but in reality CCX0 has 96MiB of cache and CCX1 has 32MiB of cache.


Can't deplpoy multi-casskop helm chart

Bug Report
What did you do?
helm upgrade -i multi-casskop -n cassandra oci://ghcr.io/cscetbon/multi-casskop-helm
What did you expect to see?
Helm release is installed
What did you see instead? Under which circumstances?
Release "multi-casskop" does not exist. Installing it now. W0811 14:27:06.527598    4079 warnings.go:70] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition Error: failed to install CRD crds/db.orange.com_multicasskops.yaml: CustomResourceDefinition.apiextensions.k8s.io "multicasskops.db.orange.com" is invalid: spec.version: Invalid value: "v2": must match the first version in spec.versions
Environment

casskop version:

2.1.9

Kubernetes version information:

v1.21.4

@Subetov Can you try #60 ?
Clone that repo, checkout branch api-deprecated and install it using something like
helm install multi-casskop  charts/multi-casskop/

@cscetbon It worked.


Seedsigner missing from import list

Seedsigner appears in the "Airgapped Hardware Wallet" list when configuring a keystore manually, but is missing from the import window (File > Import Wallet...)

This was because SeedSigner was originally intended for multisig use. I don't think that's the case any longer though, so I've added it to the wallet import list in ebf7a3f.


excessive options on load file screen

There are buttons without function and other stuff that is not needed

solved via 8e410ec


Long compile time on 100K~ bytes static files

It takes long compile time when one of the front-end files becomes to be around 100K bytes.
A 100K bytes js files are likely such as one it imports babel-polyfill.
After installing dependent libraries,
stack build --flag servant-static-th:buildexample takes

19 seconds on current latest master (7ae9924)
350 seconds with 92K bytes js file

It must be a sort of bottleneck to let people to use this fantastic servant-static-th in real world applications.

I've created a temporary fix for this in #2.
It would be nice to figure out a good way to include files with arbitrary bytes in a Haskell source file.  Is it reasonable to store them in a String?  What's the best way to convert the String back and forth to a ByteString?  Something like Data.ByteString.Char8.pack and Data.ByteString.Char8.unpack?  Or maybe something like the following that doesn't make any assumptions about the current locale:
import Control.Monad.IO.Class (MonadIO(liftIO))
import Data.ByteString (ByteString)
import Data.ByteString.Unsafe (unsafePackMallocCStringLen)
import Foreign.C (newCStringLen)

-- | Convert a 'String' to a 'ByteString' with the encoding for the current
-- locale.
--
-- >>> convertStringToRawByteString "hello"
-- "hello"
convertStringToRawByteString :: MonadIO m => String -> m ByteString
convertStringToRawByteString str = liftIO $ do
  cStringLen <- newCStringLen str
  unsafePackMallocCStringLen cStringLen
{-# INLINABLE convertStringToRawByteString #-}

This should be fixed in #3.

Thanks!


docs: 📚 improve stories by using  generateTemplate method everywhere

Description
Update all stories to use the generateTemplate method in the render call
Rationale
Not using this method in a story means that the property controls are not working for this story (e.g. using the disabled switch will not affect the component with disable status). Therefore we disabled all controls for the non-default stories for the moment.
Also it is nicer for some stories to use the table mechanism of the generateTemplate .
For example this icon-button story would look like this:

instead of this:

Example code for this would be:
export const Sizes: Story = {   parameters: {     controls: { exclude: ['size'] },     docs: {       description: {         story: generateStoryDescription('icon-button', 'sizes'),       },     },   },   render: (args: unknown) => generateTemplate({     args,     axis: {       x: {         name: 'size',         type: 'attribute',         values: ['small', 'medium', 'large'],       },     },   }), };

according to @mariohamann we should have another look at it and do a refinement on that.


Version 1.85 SSL certificate feature breaks all extensions

Does this issue occur when all extensions are disabled?: Yes/No Yes

VS Code Version: 1.85
OS Version: Windows 10 WSL (Ubuntu 22.04)

VSCode 1.85 introduced a SSL certificate load feature for remote development feature. Unfortunately I couldn't get it to work. In fact, it breaks all extensions within WSL remote development, and my dev containers (loaded via WSL) are unable to even open (fails on Downloading VS Code Server... unable to get local issuer certificate).
We use ZScaler services, and I have the certificate copied into WSL and installed via update-ca-certificates. I also have it installed on the Windows side. NODE_EXTRA_CA_CERTS is added to both Windows and WSL (via /etc/environment).

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.85.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

I have since tried out the issue with the Insiders build (1.86), same issue.

How to solve this problem, is there any good solution?

Could you install the Network Proxy Test extension (https://marketplace.visualstudio.com/items?itemName=chrmarti.network-proxy-test) and check the output of F1 > Network Proxy Test: Test Connection in VS Code?
Make sure you are using a local window when doing so. (Not a window connected to WSL or a devcontainer.) This should tell us more about why the server download suddenly is failing.
If you cannot install the extension through the Extensions viewlet in VS Code, you can use the Download Extension link on the above linked page and then install the downloaded VSIX with F1 > Extensions: Install VSIX....

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

@chrmarti sorry for the late reply, I did both google and example.com, both came back 200.
Note: Make sure to replace all sensitive information with dummy values before sharing this output.

VS Code 1.86.0-insider (f87fb292c3af22e51a7f5c628496cd8d6fd9ecd5)
Network Proxy Test 0.0.8
win32 10.0.19045 x64

Settings:
- http.proxy:
- http.proxyAuthorization: null
- http.proxyStrictSSL: false
  - globalValue: false
- http.proxySupport: off
  - globalValue: off
- http.systemCertificates: true

Environment variables:

Sending GET request to https://www.google.com...
Received response:
- Status: 200 OK
Certificate chain:
- Subject: www.google.com
  Subject alt: DNS:www.google.com
  Validity: Nov 20 08:09:47 2023 GMT - Feb 12 08:09:46 2024 GMT
  Fingerprint: 50:3E:DA:12:EC:7F:39:A5:E9:4F:16:D7:D6:AA:BF:45:15:44:7F:E9
- Subject: GTS CA 1C3 (Google Trust Services LLC)
  Validity: Aug 13 00:00:42 2020 GMT - Sep 30 00:00:42 2027 GMT
  Fingerprint: 1E:7E:F6:47:CB:A1:50:28:1C:60:89:72:57:10:28:78:C4:BD:8C:DC
- Subject: GTS Root R1 (Google Trust Services LLC)
  Validity: Jun 19 00:00:42 2020 GMT - Jan 28 00:00:42 2028 GMT
  Fingerprint: 08:74:54:87:E8:91:C1:9E:30:78:C1:F2:A0:7E:45:29:50:EF:36:F6
- Subject: GlobalSign Root CA (GlobalSign nv-sa)
  Validity: Sep  1 12:00:00 1998 GMT - Jan 28 12:00:00 2028 GMT
  Fingerprint: B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
  Self-signed
Local root certificates:
- Subject: C=BE O=GlobalSign nv-sa OU=Root CA CN=GlobalSign Root CA
  Validity: Sep  1 12:00:00 1998 GMT - Jan 28 12:00:00 2028 GMT
  Fingerprint: B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
  Issuer: C=BE O=GlobalSign nv-sa OU=Root CA CN=GlobalSign Root CA

Note: Make sure to replace all sensitive information with dummy values before sharing this output.

VS Code 1.86.0-insider (f87fb292c3af22e51a7f5c628496cd8d6fd9ecd5)
Network Proxy Test 0.0.8
win32 10.0.19045 x64

Settings:
- http.proxy:
- http.proxyAuthorization: null
- http.proxyStrictSSL: false
  - globalValue: false
- http.proxySupport: off
  - globalValue: off
- http.systemCertificates: true

Environment variables:

Sending GET request to https://example.com...
Received response:
- Status: 200 OK
Certificate chain:
- Subject: www.example.org (Internet Corporation for Assigned Names and Numbers)
  Subject alt: DNS:www.example.org, DNS:example.net, DNS:example.edu, DNS:example.com, DNS:example.org, DNS:www.example.com, DNS:www.example.edu, DNS:www.example.net
  Validity: Jan 13 00:00:00 2023 GMT - Feb 13 23:59:59 2024 GMT
  Fingerprint: F2:AA:D7:3D:32:68:3B:71:6D:2A:7D:61:B5:1C:6D:57:64:AB:38:99
- Subject: DigiCert TLS RSA SHA256 2020 CA1 (DigiCert Inc)
  Validity: Apr 14 00:00:00 2021 GMT - Apr 13 23:59:59 2031 GMT
  Fingerprint: 1C:58:A3:A8:51:8E:87:59:BF:07:5B:76:B7:50:D4:F2:DF:26:4F:CD
- Subject: DigiCert Global Root CA (DigiCert Inc)
  Validity: Nov 10 00:00:00 2006 GMT - Nov 10 00:00:00 2031 GMT
  Fingerprint: A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36
  Self-signed
Local root certificates:
- Subject: C=US O=DigiCert Inc OU=www.digicert.com CN=DigiCert Global Root CA
  Validity: Nov 10 00:00:00 2006 GMT - Nov 10 00:00:00 2031 GMT
  Fingerprint: A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36
  Issuer: C=US O=DigiCert Inc OU=www.digicert.com CN=DigiCert Global Root CA


maxpricescale buys too early

The purpose of minpricescale is to raise the expected ticket price for the next window if it looks like it will fall too low. The default is 0.7.  Raising ones default to 0.8 means that you will likely be the only one buying tickets, because the majority will still be using the default value of 0.7 and will not be buying tickets at all because you are the only one holding the price up. This is a disincentive for deviating from the default and from helping to stabilize the price.
A way to fix this would be to make mixpricescale wait till the end of the ticket purchasing window to buy. By calculating the number of tickets purchase slots remaining in a window, the amount of tickets you have funds to purchase, the number of tickets purchases needed to raise the estimate price to the target amount, and the maxperblock setting, it would be possible to wait towards the end of the ticket window to determine that it is time to buy for minpricescale. This would create a group effect where more participants would be helping to raise the ticket price, as well as not buying too early (before other parties make purchases) and causing the ticket price to go too high.

closing because minpricescale is no longer used

I should apply this logic to maxpricescale behavior

closing because this is a dup of https://github.com/decred/dcrticketbuyer/issues/78