parameters method in RotationTransform should be removed

This is due to the fact that a Rotation could have been created from a Rotation space around any given center, it does not make sense to return parameters as one would not know on which Rotation Space to use them.

solved with PR #123. We are now exposing the center, which is sufficient to interpret the parameters.


is here a simple example for seq2seq?

Hello
Is there a simple example (not from pretrained models) that shows how to just define enc and dec for seq2seq learning in the longformer?
The inputs can be also just synthetic and random like x=torch.rand(1,128,100)?
I am specifically looking for an example like the one that pytorch has for its transformers encoder decoder, to show me how can I separately define encoder and decoder.
thanks

Hello, we have a complete working end-to-end example of training a summarization model included as part of our recent NAACL 2021 tutorial on long document NLP:  https://github.com/allenai/naacl2021-longdoc-tutorial


Fix writing of cargo-dist-json-schema.json

Currently, this is writing the schema file without first truncating. That means if this writes fewer bytes than currently exist in the file, whatever extra bytes were at the end of the file remain. Thiss is probably not a valid JSON file.
You can reproduce the problem by doing roughly:
cargo test
echo test >> cargo-dist-schema/cargo-dist-json-schema.json
cargo test

Expected: the file is overwritten with the new schema.
Actual: the file still contains the extra "test" at the end.

Ah good catch! I think I misread the docs for write!


#3 Setup CI

Resolves #3

@fedorpashin thank you for your Pull Request. I'll assign someone to review it soon.


mapping type decoder

[ ] performance: after 400 items in storage, it become quite unusable https://github.com/ethereum/remix/pull/512
[x] warn user if storage is not complete
[ ] check geth preimage is working
[ ] does not work now if the client does not return the key.
[ ] issue https://github.com/ethereum/remix/issues/510
[ ] instead of requesting preimage(key) , we should be able to request for an array of key
[ ] the storage retrieve only the first 100 items (for geth/eth). we should change the API so the user can load more keys if she wants to. or maybe have an option in the ui to force to load the entire storage.

We will try to use a different solution for that instead of using preimage.


Update DMS limit from 2 to 10.

DMS limit has changed from 2 to 10 per subscription per region. The change is already live.

Hi @tfitzmac - Do you cover this area? Could you review the PR?
It looks like the metadata for the include file needs to be updated.
Thanks.

I am not the right person to review it. I own an article that probably has this include file, but I don't know anything about the specific services.

I am not the right person to review it. I own an article that probably has this include file, but I don't know anything about the specific services.

Thanks @tfitzmac

@CarlRabeler Would you be able to review this pull request? Thanks.

#reassign: @MashaMSFT

#sign-off

@MashaMSFT: I'm sorry - only the author of this article, @douglaslMS, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Thanks, all


RPC

Contains RPC: estimate VM functions, gas related functions, and some bug fixes.

Depends on https://github.com/pontem-network/sp-move-vm/pull/30


pip freeze command as an option for pip list

(Since discussion isn't enabled for this repo, I created issue.)
Now https://github.com/astral-sh/uv/pull/1662 merged, IMO we can consider pip list --freeze instead of independent command.

We should add --format=freeze, probably, to make it compatible with pip.


Techdebt - Simplify some exceptions

Simplifies and streamlines some exceptions by extending our custom Exception-object, instead of werkzeug's HttpException.
The format that AWS uses for it's exceptions, "{'__type': .., 'message': ..}" should now only be present in our overarching JsonRestError.

Codecov Report

Merging #5567 (320e9df) into master (8e9f12b) will increase coverage by 0.01%.
The diff coverage is 77.90%.

@@            Coverage Diff             @@
##           master    #5567      +/-   ##
==========================================
+ Coverage   96.14%   96.15%   +0.01%
==========================================
  Files         742      742
  Lines       72622    72591      -31
==========================================
- Hits        69822    69802      -20
+ Misses       2800     2789      -11

Flag
Coverage Δ

servertests
37.01% <41.86%> (+<0.01%)
:arrow_up:

unittests
96.09% <77.90%> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

moto/athena/exceptions.py
0.00% <0.00%> (ø)

moto/meteringmarketplace/exceptions.py
0.00% <0.00%> (ø)

moto/kinesis/exceptions.py
98.07% <95.00%> (+1.52%)
:arrow_up:

moto/cloudformation/exceptions.py
100.00% <100.00%> (ø)

moto/cognitoidentity/exceptions.py
100.00% <100.00%> (ø)

moto/cognitoidp/exceptions.py
100.00% <100.00%> (ø)

moto/managedblockchain/exceptions.py
97.43% <100.00%> (+2.19%)
:arrow_up:

moto/opsworks/exceptions.py
100.00% <100.00%> (ø)

moto/rds/exceptions.py
97.18% <100.00%> (ø)

moto/redshift/exceptions.py
94.20% <100.00%> (ø)

... and 2 more

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


Triggered "FIX ME! variant { ok; err : text } <: opt principal via special opt rule."

I was upgrading a canister and ran into this issue.
% dfx deploy cycleops
Deploying: cycleops
All canisters have already been created.
Building canisters...
Shrink WASM module size.
Installing canisters...
FIX ME! variant { ok; err : text } <: opt principal via special opt rule.
This means the sender and receiver type has diverged, and can cause data loss.
Upgrading code for canister cycleops, with canister ID sp3hj-caaaa-aaaaa-aaajq-cai
Deployed canisters.

Prior to the upgrade, this is the code that was changed.
  public shared ({ caller }) func stopTopupTimerCanister() : async ?Principal {
    if (not Admins.isAdmin(admins, caller)) return null

    switch (topupTimerActor) {
      case (?timer) {
        let principal = Principal.fromActor(timer);
        await ManagementCanisterActions.stopCanister(principal);
        ?principal
      };
      case null { null };
    };
  };

Became
  public shared ({ caller }) func stopTopupTimerCanister() : async Result.Result<(), Text> {
    if (not Admins.isAdmin(admins, caller)) return #err("Not authorized");

    switch (topupTimerActor) {
      case (?timer) {
        let principal = Principal.fromActor(timer);
        await ManagementCanisterActions.stopCanister(principal);
        #ok
      };
      case null { #err("No TopupTimer canister exists") };
    };
  };

Note that this bug was found in the context of trying to solve https://github.com/dfinity/motoko/issues/3857 🙂

I don't see a problem here. You are changing the return type, which is a breaking change. Maybe we should error out in install instead of a warning?

I don't argue that the change is breaking, but "FIX ME!" feels like a todo.
Instead I'd expect this to show up as dfx telling me that I'm making a breaking change, and prompt me enter "yes" to force through the upgrade

Yeah, I agree. FIX ME is a warning to the user to fix the "almost" breaking change. Because you are returning an option type, result from the old version always becomes null with the new client, so it's technically not a breaking change, but nice to fix. I will file a ticket to promote this warning to error in dfx, so that users can enter "yes".


SnackBar container blocks clicks

When a snackbar is up, the topmost snackbar container block click events from happening underneath.
This happens even for the blank space to the right and left of the snackbar.
I've got a PR coming in a minute to fix this.

Oh. Merged! Thanks!


Better conditional information for responses

First: thanks for the hard work! Second: I just started using the addon so perhaps I'm missing something obvious or using it the wrong way.
Is your feature request related to a problem? Please describe.
The manager doesn't feel very transparent regarding responses at the moment. It seems like disallowed responses are hidden from the user.
If I understand this correctly, DialogueLine has an array of DialogueResponse, and each response has an is_allowed field. I'm unsure if that field works, because the manager simply discards the responses with failed conditions.
I feel like the most transparent way to handle this would be to pass all the responses to the user, allowed or not, so the user can decide what to do with them for their particular project (hide them, gray them out, etc).
Describe the solution you'd like
Ideally, the dialogue would output all the responses, both allowed and not.
It would also be great if DialogueResponse included its condition(s) as an aditional field, both failed and passed. This would allow you to parse the response and inform the player why a certain response is enabled or disabled. This is very common in interactive fiction and CRPGs, where the actions of each choice are made explicit, for example it's common to see choices like: "- Tell me about your past. (Requires relationship 5+)" or "- Pick the lock (Requires picklock)".
Hopefully this sounds reasonable. Thanks again!

You might be looking for this setting:


Sloping roller shutters inverted positions

Describe you new feature you'd like
First of all, thank you - mega project!
I have a sloping roller shutter which is controlled by the buttons on the controller.
Means button up - the shutter goes up (extends) and covers the window.
Pressing the down button lowers the shutter (retracts) and opens the window again.
This means that the status must be calculated in reverse.
At the beginning I thought that the inversion of the position was intended for this. But unfortunately it did not work.
Enclosed you can see a warless picture from the WWW where such a sloping roller shutter setup combined with normal roller shutters is visible. Link
Perhaps there is an easy way to implement this. At the moment, the shutter status display is very confusing (open = closed and vice versa)
Thanks a lot.

Try using invert the commands checkbox.

I have also tested this variant. In this case, the display is correct.
However, this means that the buttons are no longer correct.
On the remote control, pressing the top button extends the roller shutter upwards and closes the window.
Pressing the down button does exactly the opposite.
Unusual at first - but totally logical as the button follows the direction of the shutter.
Comparable to roller shutters and awnings. - A retracted awning is closed - a retracted roller shutter is open.
I hope you can follow me and understand my problem ?

I get it.  These change the definition of open and closed.  I'll have to look and see if there is a short direction to making it happen.
Out of curiosity is the motor mounted to the bottom or top?

it is indeed mounted at the bottom and closes by pushing the lamellas upwards.
It is also exciting to see how the status is received by the Home assistant.


Fix mismatched type error on aarch64

This fixes that type error occurs when build on aarch64.
It is caused from c compiler difference between x86 and aarch64. When aarch64, char is unsigned int.
https://developer.arm.com/documentation/den0013/d/Porting/Miscellaneous-C-porting-issues/unsigned-char-and-signed-char
error[E0308]: mismatched types
    --> /home/.../membrane/src/lib.rs:1087:41
     |
1087 |   let _ = ::std::ffi::CString::from_raw(ptr);
     |                                         ^^^ expected `u8`, found `i8`
     |
     = note: expected raw pointer `*mut u8`
                found raw pointer `*mut i8`

Thanks so much for this fix and pull request!


Option for private class level variables with getters/setters.

It would be great if we could have the option to make all variables private, and generate getters/setters for them. Great tool either way!

To be honest, I'm some kind of a noob here. I've been playing around with Dart for a week or two, so I'm not exactly sure what are the convention regarding Dart classes.
In Java I would have created private instance variables and have their getters and setters generated, but for Dart I decided to go for the flutter approach which uses public instance vars.
I'll leave this issue open for a while and if more developers agree that this is the way to go, I'll implement it as a gift for the community.
Thanks for your comment!

Sounds like a plan. I'll fork the repo and play around a bit. Normally how I handle data classes is everything is private, with getters. And only things that I know will need to change later get setters.

Probably I will be addressing this issue shortly while making this change

Fixed with this PR. Will update the official page shortly

Fantastic! Will be using this at work tomorrow!


Rely on "bootstrap" to configure MGR module (and more...)

After https://github.com/ceph/ceph/pull/35195
After https://github.com/ceph/ceph/pull/35347

This PR contains two commits, each commit fixes a different issue.
1. Need to invoke ceph orch apply crash (https://github.com/ceph/ceph-salt/issues/236)
We will now rely on cephadm bootstrap to configure cephadm MGR module, which will guarantee that all initializations are properly done (including the execution of ceph orch apply crash)
2. Make bootstrap_mon optional (https://github.com/ceph/ceph-salt/issues/265)
It's now possible to explicitly say that we don't want ceph-salt to run cephadm bootstrap by setting ceph-salt config /cephadm_bootstrap disable, so the new behavior is:

bootstrap_minion is required for initial ceph-salt apply execution but can be removed latter if needed/wanted.
If bootstrap is enabled, then /cephadm_bootstrap/* options are required (including mon_ip). In this scenario cephadm bootstrap will be executed on the bootstrap_minion.
If bootstrap is disabled, then /cephadm_bootstrap/* options will be ignored and ceph-salt will assume that bootstrap_minion has access to a running cluster (e.g. an upgrade from Nautilus to Octopus). In this scenario ceph-salt will simply configure/enable cephadm MGR module.

Signed-off-by: Ricardo Marques<EMAIL_ADDRESS>

Codecov Report

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

@@           Coverage Diff           @@
##           master     #250   +/-   ##
=======================================
  Coverage   76.57%   76.57%
=======================================
  Files          11       11
  Lines        2596     2596
=======================================
  Hits         1988     1988
  Misses        608      608

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 643c4db...7aa32e8. Read the comment docs.

I've now pushed a new commit and updated PR description accordingly.
@tserong please check if this PR fixes  https://github.com/ceph/ceph-salt/issues/236 and https://github.com/ceph/ceph-salt/pull/267
@swiftgist please check if this PR is sufficient to fix https://github.com/ceph/ceph-salt/issues/265

Without a boostrap mon, should ceph-salt run the related module and backend commands?  For an upgrade scenario, this would mean that the mon/mgr need to be upgraded prior to running ceph-salt.  Considering that ceph-salt is primarily for ensuring prerequisites, I do not think this is obvious.

Without a boostrap mon, should ceph-salt run the related module and backend commands? For an upgrade scenario, this would mean that the mon/mgr need to be upgraded prior to running ceph-salt. Considering that ceph-salt is primarily for ensuring prerequisites, I do not think this is obvious.

My understanding from https://github.com/ceph/ceph-salt/pull/267 was that, for an upgrade scenario, we should do everything except the cephadm bootstrap part. Let's wait for @tserong take on this so we can adapt ceph-salt to behave in a way that makes upgrades easier.

@tserong please check if this PR fixes #236 and #267

From reviewing the code, it looks like this'll do the right thing (I'd still like to try running it to test).

Without a boostrap mon, should ceph-salt run the related module and backend commands? For an upgrade scenario, this would mean that the mon/mgr need to be upgraded prior to running ceph-salt. Considering that ceph-salt is primarily for ensuring prerequisites, I do not think this is obvious.

I agree, it's not obvious - the upgrade scenario is irritatingly chicken-and-eggy. Maybe there's a better approach to clear this up somehow, but IMO it's OK to take this PR as-is, and consider further upgrade-related reworking as a separate issue.

If we want to support re-applying config as describes in https://github.com/ceph/ceph-salt/issues/173 then we should not rely on cephadm bootstrap to configure keys because if the user changes those keys we need them to be updated next time ceph-salt apply is executed.
So I'm closing this PR for now and will open a new one.

Excellent point... Although maybe it makes sense to still rely on cephadm bootstrap to initially configure keys (because it's easy, and also because bootstrap sets up the crash service), and we only need to add an extra step to re-apply keys to a running system?

Excellent point... Although maybe it makes sense to still rely on cephadm bootstrap to initially configure keys (because it's easy, and also because bootstrap sets up the crash service), and we only need to add an extra step to re-apply keys to a running system?

Yes, I'll consider that in my new PR, thanks.


Jessica/wind plugin port

Still a work in progress (needs refactoring and confirmation that the vector math in the world frame is working as intended) but the code runs and the wind force is applied to the WAM-V:
ros2 launch vrx_gz competition.launch.py world:=test_wind_world

@j-herman Thanks! When it is ready for testing, could we swap out test_wind_world with the 3 versions of practice_2023_stationkeeping#_task.sdf configured to restore the original wind settings for those worlds (found here)? I think this would help us get an intuitive sense of whether things are working as expected. Once it's set, we'll eventually update all the tasks with these settings.

[like]  Herman, Jessica (CIV) reacted to your message:

From: M1chaelM @.>
Sent: Tuesday, May 9, 2023 1:26:07 PM
To: osrf/vrx @.>
Cc: Herman, Jessica (CIV) @.>; Mention @.>
Subject: Re: [osrf/vrx] Jessica/wind plugin port (PR #637)
NPS WARNING: external sender verify before acting.
@M1chaelMhttps://github.com/M1chaelM I don't see any 2023 practice worlds
Sorry, typo. I should have said 2022 practice worlds. We ported the 2022 practice worlds to VRX 2.0, but the ported versions are all using the gazebo wind plugin. The versions from Gazebo classic still have the settings for our custom wind plugin, so I was trying to suggest that you could copy those settings to the ported 2022 practice worlds for stationkeeping (as a simple example) and it would help us check that the wind is functioning the way it used to.
—
Reply to this email directly, view it on GitHubhttps://github.com/osrf/vrx/pull/637#issuecomment-1540123171, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AORRLBT6ASGXGDWAYMYMMZTXFJAW7ANCNFSM6AAAAAAXXUYTIA.
You are receiving this because you were mentioned.Message ID: @.***>

@j-herman Thanks! When it is ready for testing, could we swap out test_wind_world with the 3 versions of practice_2023_stationkeeping#_task.sdf configured to restore the original wind settings for those worlds (found here)? I think this would help us get an intuitive sense of whether things are working as expected. Once it's set, we'll eventually update all the tasks with these settings.

Three stationkeeping 2022 practice worlds updated as requested.  They all run but I haven't verified the behavior matches expectations yet.

@j-herman Thanks! When it is ready for testing, could we swap out test_wind_world with the 3 versions of practice_2023_stationkeeping#_task.sdf configured to restore the original wind settings for those worlds (found here)? I think this would help us get an intuitive sense of whether things are working as expected. Once it's set, we'll eventually update all the tasks with these settings.

Three stationkeeping 2022 practice worlds updated as requested.  They all run but I haven't verified the behavior matches expectations yet.

There is a potential discrepancy between the legacy code implementation and the desired (published) behavior, unless I'm misunderstanding something.  In lines 254-260 of usv_gazebo_wind_plugin.cc an apparent wind value is calculated (subtracting the vehicle's velocity from the wind vector), but the uncorrected wind is used in the force calculations.  I have included that correction in the new version.
Overall the ported plugin seems to be working as desired.  In comparison to the gazebo classic version, an equivalent force seems to produce less drift in the WAM-V.  I don't know whether other parameters may have changed in the model or in the port of the physics engines, or if there is something going on with how I am applying the force to the link.  There are a few more things I can troubleshoot in the implementation, but I do think this may be close enough to include in the next release even if we need to make tweaks later.  Qualitatively the behavior looks good and the interfaces are set.
Wind speed trace for stationkeeping1 world in gazebo classic:

Wind speed trace for stationkeeping1 world in gazebosim (note that the timescale is not in seconds - I haven't figured out how to fix that, so this graph represents more than 30 seconds):

Wind speed trace for stationkeeping2 world in gazebo classic:

Wind speed trace for stationkeeping2 world in gazebosim (same timescale issue):

In both worlds, the wind direction and the general behavior of the WAM-V were consistent - that is, the vehicle runs into the docks in stationkeeping1, and into the shore by the tent in stationkeeping2.

To test:
ros2 launch vrx_gz competition.launch.py world:=practice_2022_stationkeepingX_task
You should see no movement due to wind in stationkeeping0, a slow drift towards the docks in stationkeeping1, and a faster drift towards the shore in stationkeeping2.
Wind speed and direction are published on /vrx/debug/wind/speed and /vrx/debug/wind/direction.  As in gazebo classic, they're referenced to the Gazebo world frame.  A potential enhancement could be to also publish this information in the format that would be received from a weather station (ie, in knots and with the direction specified as the compass point from which the wind is blowing).

@j-herman Thanks! Should we mark this ready for review? If so I can test it.

Ah, I forgot about the ROS bridge!  I'll knock that out today.  The blank output is odd and I'll see what's causing that.


Resize mode based on bounding boxes

you may be interested by https://github.com/rom1504/img2dataset/pull/241

@rom1504 w.r.t your below comment

I think it's clear the resizing should happen after the cutting in boxes

The way one can prepare bbox metadata is to have existing data, that is possibly downloaded using this library. In which case images are already resized using existing modes and bounding boxes are computed based on the resized images.
So, when distributing the new dataset with bounding boxes, it is expected that the bounding box is done after the resizing.
It appears that laion400m, laion5b had some resize mode used.
Existing blur implementation is doing bounding box before resizing..

I advise you preprocess the dataset you have to make the boxes fit the
original images
On Sat, Jan 14, 2023, 02:52 Pradeep @.***> wrote:

@rom1504 https://github.com/rom1504 w.r.t your below comment
I think it's clear the resizing should happen after the cutting in boxes
The way one can prepare bbox metadata is to have existing data, that is
possibly downloaded using this library. In which case images are already
resized using existing modes and bounding boxes are computed based on the
resized images.
So, when distributing the new dataset with bounding boxes, it is expected
that the bounding box is done after the resizing.
It appears that laion400m, laion5b had some resize mode used.
Existing blur implementation is doing bounding box before resizing..
—
Reply to this email directly, view it on GitHub
https://github.com/rom1504/img2dataset/pull/233#issuecomment-1382629534,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAR437T7R7BLN6YSAV446CLWSIBEFANCNFSM6AAAAAASOREARQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


[Bug] pyobis.occurrences: all records not being returned by search()

Overview
The occurrences.search() function returns only the first set of records (limited to 10 rows) from OBIS. But, we need to fetch all occurrence records from the API.
Steps to reproduce this bug

Install pyobis
Runres = occurrence.search() # we can also query for any particular scientificname but we get the same issue
df = pandas.DataFrame(res["results"])
print(len(df)) # it will show only 10, however the total number of records can be determined by executing res["total"]

I am working on this issue. My initial plan of action would be to implement a looping construct that fetches occurrence records for a maximum of 5000 rows per API call, we can do this by passing the size=5000 parameter in the request itself.
To fetch subsequent records after the first request, we need to add after={{occurence_id}} parameter to fetch all records following this occurrence record. I am thinking of looping these requests for 5000 rows each time until the next batch returns empty i.e. with 0 results. We break this loop at that point of time. And finally, we return the total result by joining them into one JSON object.

My hack from this notebook. You can probably make this much more efficient.
Keep in mind, the max is 10,000 records.
base = 'https://api.obis.org/v3/'

occurrence_id = 'occurrence?taxonid={}&startdepth={}&enddepth={}&geometry={}&size={}'.format(aphiaID,startdepth,enddepth,geometry,size)

# build the api query and print out the number of records found
url = '{}{}'.format(base,occurrence_id)
response= urlopen(url)
data_json = json.loads(response.read())

# The API limits responses to 10,000 entries, so we need to iterate by 10k and use the last occurrence
# uuid to set after "Occurrence UUID up to which to skip."
size = data_json['total']
for i in range(10000,size,10000):
    if i == 10000:
        # build url for first call
        occurrence_id = 'occurrence?taxonid={}&startdepth={}&enddepth={}&geometry={}&fields={}&size=10000'.format(aphiaID,startdepth,enddepth,geometry,f)
    else:
        # build url for remaining calls
        uuid = data.iloc[-1]['id']
        occurrence_id = 'occurrence?taxonid={}&startdepth={}&enddepth={}&geometry={}&fields={}&after={}&size=10000'.format(aphiaID,startdepth,enddepth,geometry,f,uuid)

    url = '{}{}'.format(base,occurrence_id)
    # open the api call
    response= urlopen(url)
    # read in the json
    data_json = json.loads(response.read())
    # build a mongo dataframe with all results
    data = pd.concat([data, pd.DataFrame(data_json['results'])])

    print('Data shape:',len(data_json['results']),data.shape)

    # kick out of loop at the end
    if len(data_json['results']) < 10000:
        break
# Need to grab from last iteration to expected size.
uuid = data.iloc[-1]['id']
occurrence_id = 'occurrence?taxonid={}&startdepth={}&enddepth={}&geometry={}&fields={}&after={}&size=10000'.format(aphiaID,startdepth,enddepth,geometry,f,uuid)
url = '{}{}'.format(base,occurrence_id)
response= urlopen(url)
data_json = json.loads(response.read())
data = pd.concat([data, pd.DataFrame(data_json['results'])])

My hack from this notebook. You can probably make this much more efficient.

Thanks a ton @MathewBiddle for your solution to this issue. I did something similar and integrated the pagination process to the existing output handling implementation in the search().
Here's what I did. I am using a while loop maybe because I am a fan of it, and personally use it much more often than for. I am also utilizing try catch expressions to determine whether we have reached the end of records.
# the arguments are comming straight from the function input paramaters,
# clipping the declaration and stuff to limit space

    args = {
            'taxonid': taxonid,'obisid': obisid,'datasetid': datasetid,
            'scientificname': scientificname,'startdate': startdate,
            'enddate': enddate,'startdepth': startdepth,'enddepth': enddepth,
            'geometry': geometry,'year': year,'fields': fields,
            'flags': flags,'offset': offset,'mof': mof,'size':0,
            'hasextensions': hasextensions
        }
    out  = obis_GET(url,args,'application/json; charset=utf-8', **kwargs)
    while (True):
        if args["size"]!=0:
            try:
                res["results"][4999]
            except:
                break
            args['after'] = res["results"][4999]['id']
        args['size'] = size
        res=obis_GET(url, args, 'application/json; charset=utf-8', **kwargs)
        out["results"].append(res["results"])

# and then we return out, please note that out is still being returned as JSON object


JavaScript property color mismatch

I noticed there is a difference in color of property in javascript, like the image below

Hey mate! That was a good catch.
I had a cursory look over the issue and apparently VS Code's JavaScript language grammar fails to pick up DOM properties in a consistent manner.
I'll investigate further and see how can I fix it.

I have released a fix for this issue in v3.19.2
I would appreciate if you woud try it and let me know how it works for you.

Hmm.... 🤔 I just updated the theme and have a look at my js source code.
The issue is partial fixed, but it seems inconsistent, some properties still doesn't have same color,
Don't know this is by the theme or vscode itself 🤔, I have tested with other theme but doesn't see this issue. 🤨

Thanks for your feedback, mate.
I had a proper look into the matter and the conclusion is that VS Codes's JavaScript language grammar is broken when it comes to properly highlight DOM properties.
Because I wanted DOM objects like document, screen, window and DOM properties like height, backgroundPosition, backgroundImage, name, location, etc. to stand out I decided to highlight them with the Desert Sand color. I'm using this color exclusively to for DOM highlighting.
I would have liked that all the DOM properties in the screenshot you provided to be highlighted in Desert Sand color. Unfortunately, as I said, right now VS Code JS grammar picks up only partially DOM object properties. That's why backgroundSize and backgroundPosition were not properly highlighted and that’s why you noticed the highlighting inconsistencies.
Having said that I still want that DOM object related syntax to be highlighted with Desert Sand color, but to get rid of the blatant mismatches I narrowed down the scope selectors that are being picked up by VS Code’s highlighter.
As an example, the highlighting of location.pathname , document.title and name is intentional.

I hope this sheds some light on this topic if not please feel free to ask or add any thoughts you might have.
Cheers!


Migrate to python 3.10

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

I had to update the sha256 hash to make this work.  I do not know what upstream has changed to make this necessary, and would like to at least have some idea of that before this can be merged.  But otherwise, the py310 migration should be good to go.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Build Failure of frida-go When Cross-Compiling to Linux

I encountered a build failure when trying to cross-compile the frida-go library from macOS to Linux. The following errors occur during the build process:
../frida.go:21:25: undefined: frida.DeviceInt
../frida.go:49:21: undefined: frida.NewDeviceManager
../frida.go:50:46: undefined: frida.DeviceTypeUsb
../frida.go:64:57: too many errors

Here are relevant sections of the code that are causing the issue:
import (
	"fmt"
	"github.com/frida/frida-go/frida"
)
func GetDevice() (*frida.DeviceInt, error) {
       manager := frida.NewDeviceManager()
       device, err := manager.DeviceByType(frida.DeviceTypeUsb)
       if err != nil {
		return nil, fmt.Errorf("could not get USB device: %v", err)
       }
       return &device, nil
}

Environment:
•	frida-go Version: v0.10.3
•	Go Version: 1.23.1
•	Operating System: macOS (using cross-compilation settings GOARCH=amd64)
Steps to Reproduce:
1.	Run the build command: GOOS=linux GOARCH=amd64 go build -o test cmd/main.go
2.	Observe the build errors that occur.
Attempts to Resolve:
•	Ensured that the frida-go version is correct.
•	Cleared Go cache and re-downloaded dependencies.
Please take a look at this issue and provide assistance. Thank you!

I did not plan to support cross-compilation but as a workaround you can use docker containers and build it that way.


ethernet example fails on address and ethernet diff

I installed fedora 30 server and tried your example but it doesn't work. Am I doing something wrong or is it a bug in nmstate 0.0.8? Thanks.
root@localhost ~]# cat /etc/redhat-release
Fedora release 30 (Thirty)
[root@localhost ~]# rpm -qi nmstate
Name        : nmstate
Version     : 0.0.8
Release     : 1.fc30
Architecture: noarch
Install Date: Fri 30 Aug 2019 04:40:12 PM CEST
Group       : Unspecified
Size        : 27617
License     : LGPLv2+
Signature   : RSA/SHA256, Fri 26 Jul 2019 07:50:21 PM CEST, Key ID ef3c111fcfc659b9
Source RPM  : nmstate-0.0.8-1.fc30.src.rpm
Build Date  : Fri 26 Jul 2019 02:42:56 PM CEST
Build Host  : buildhw-07.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://github.com/nmstate/nmstate
Bug URL     : https://bugz.fedoraproject.org/nmstate
Summary     : Declarative network manager API
Description :
NMState is a library with an accompanying command line tool that manages host
networking settings in a declarative manner and aimed to satisfy enterprise
needs to manage host networking through a northbound declarative API and multi
provider support on the southbound.
[root@localhost ~]# cat set.yaml
interfaces:
- name: enp7s0
  type: ethernet
  state: up
  ipv4:
    address:
    - ip: <IP_ADDRESS>
      prefix-length: 24
    enabled: true
  ipv6:
    address:
    - ip: 2001:db8::1:1
      prefix-length: 64
    enabled: true
[root@localhost ~]# nmstatectl set set.yaml
2019-08-30 16:48:50,114 root         DEBUG    Checkpoint /org/freedesktop/NetworkManager/Checkpoint/7 created for all devices: 60
2019-08-30 16:48:50,115 root         DEBUG    Adding new interfaces: []
2019-08-30 16:48:50,115 root         DEBUG    Editing interfaces: ['enp7s0']
2019-08-30 16:48:50,117 root         DEBUG    Connection settings for ConnectionSetting.import_by_profile:
id: Wired connection 1
iface: None
uuid: 1a7e1072-3203-3a22-9f50-33d36c2ab0db
type: 802-3-ethernet
autoconnect: True
autoconnect_slaves: <enum NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_DEFAULT of type NM.SettingConnectionAutoconnectSlaves>
2019-08-30 16:48:50,120 root         DEBUG    Executing NM action: func=commit_changes_async
2019-08-30 16:48:50,126 root         DEBUG    Connection update succeeded: dev=enp7s0
2019-08-30 16:48:50,126 root         DEBUG    Executing NM action: func=_safe_modify_async
2019-08-30 16:48:50,129 root         DEBUG    Device reapply failed on enp7s0: error=nm-device-error-quark: Can't reapply changes to '802-3-ethernet.cloned-mac-address' setting (3)
Fallback to device activation
2019-08-30 16:48:50,194 root         DEBUG    Connection activation initiated: dev=enp7s0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATING of type NM.ActiveConnectionState>
2019-08-30 16:48:50,269 root         DEBUG    Connection activation succeeded: dev=enp7s0, con-state=<enum NM_ACTIVE_CONNECTION_STATE_ACTIVATED of type NM.ActiveConnectionState>
2019-08-30 16:48:50,269 root         DEBUG    NM action queue exhausted, quiting mainloop
2019-08-30 16:48:50,355 root         DEBUG    Checkpoint /org/freedesktop/NetworkManager/Checkpoint/7 rollback executed: dbus.Dictionary({dbus.String('/org/freedesktop/NetworkManager/Devices/1'): dbus.UInt32(0), dbus.String('/org/freedesktop/NetworkManager/Devices/3'): dbus.UInt32(0), dbus.String('/org/freedesktop/NetworkManager/Devices/2'): dbus.UInt32(0)}, signature=dbus.Signature('su'))
Traceback (most recent call last):
  File "/usr/bin/nmstatectl", line 11, in <module>
    load_entry_point('nmstate==0.0.8', 'console_scripts', 'nmstatectl')()
  File "/usr/lib/python3.7/site-packages/nmstatectl/nmstatectl.py", line 62, in main
    return args.func(args)
  File "/usr/lib/python3.7/site-packages/nmstatectl/nmstatectl.py", line 220, in apply
    statedata, args.verify, args.commit, args.timeout
  File "/usr/lib/python3.7/site-packages/nmstatectl/nmstatectl.py", line 240, in apply_state
    checkpoint = libnmstate.apply(state, verify_change, commit, timeout)
  File "/usr/lib/python3.7/site-packages/libnmstate/netapplier.py", line 62, in apply
    state.State(desired_state), verify_change, commit, rollback_timeout
  File "/usr/lib/python3.7/site-packages/libnmstate/netapplier.py", line 146, in _apply_ifaces_state
    _verify_change(desired_state)
  File "/usr/lib/python3.7/site-packages/libnmstate/netapplier.py", line 184, in _verify_change
    desired_state.verify_interfaces(current_state)
  File "/usr/lib/python3.7/site-packages/libnmstate/state.py", line 257, in verify_interfaces
    self._assert_interfaces_equal(other_state)
  File "/usr/lib/python3.7/site-packages/libnmstate/state.py", line 485, in _assert_interfaces_equal
    current_state.interfaces[ifname],
libnmstate.error.NmstateVerificationError:
desired
=======
---
name: enp7s0
type: ethernet
state: up
ipv4:
  address:
  - ip: <IP_ADDRESS>
    prefix-length: 24
  auto-dns: true
  auto-gateway: true
  auto-routes: true
  dhcp: true
  enabled: true
ipv6:
  address:
  - ip: 2001:db8::1:1
    prefix-length: 64
  auto-dns: true
  auto-gateway: true
  auto-routes: true
  autoconf: true
  dhcp: true
  enabled: true
mac-address: 52:54:00:47:2F:24
mtu: 1500

current
=======
---
name: enp7s0
type: ethernet
state: up
ethernet:
  auto-negotiation: true
  duplex: full
  speed: 1000
ipv4:
  address: []
  auto-dns: true
  auto-gateway: true
  auto-routes: true
  dhcp: true
  enabled: true
ipv6:
  address: []
  auto-dns: true
  auto-gateway: true
  auto-routes: true
  autoconf: true
  dhcp: true
  enabled: true
mac-address: 52:54:00:47:2F:24
mtu: 1500

difference
==========
--- desired
+++ current
@@ -2,19 +2,19 @@
 name: enp7s0
 type: ethernet
 state: up
+ethernet:
+  auto-negotiation: true
+  duplex: full
+  speed: 1000
 ipv4:
-  address:
-  - ip: <IP_ADDRESS>
-    prefix-length: 24
+  address: []
   auto-dns: true
   auto-gateway: true
   auto-routes: true
   dhcp: true
   enabled: true
 ipv6:
-  address:
-  - ip: 2001:db8::1:1
-    prefix-length: 64
+  address: []
   auto-dns: true
   auto-gateway: true
   auto-routes: true

Looks like the interface enp7s0 is already managed by NM and is set with IP method auto. Therefore, dhcp=true and you have not specified to disable it. Nmstate tries to keep it and ignores the mentioned static address (dhcp+static is not supported).
Try setting dhcp: false on both IPv4 and IPv6 and autoconf: false for IPv6.
We should probably provide a better error/warning to this scenario.
But the logic seems right.

Thanks. Disabling dhcp solved the problem.


Update to Rails 5.0.1.rc1

This will allow the use of the new Ruby 2.4.0 that is being released in December (currently Ruby 2.4.0-preview3)

Addressed in commit f84727e5eb8fc80560c7089c67279c22026828fa


Allow customers to configure use of their own NTP servers in metavisor.

Adding ntp-server, a brkt-cli option to allow customers to override
the default NTP server in ntp configuration of metavisor.
This option is supported for both encryption and update process.
ntp-server is provided as user-data to the encryptor/updater instance.
Error out if ntp-server is not a valid host name or ipv4 address.
Finally, handle errors reported by the Bracket Updater instance.

I disagree with Boris on this one. I think we can, and should do some error checking here
or the end result will be a failed launch on the resulting instance with little to go on.
For instance, I asked Approva to make sure the argument being passed wasn't IPv6
for instance. We should try to catch obvious typo's.
Using ntplib might not be a good answer here either. You might not be able to contact
the NTP servers specified as part of the encryption process for instance.

Ok.  Apoorva, if you want to keep the hostname checking code, please add a unit test.


fix: typo in default values recipe

Coverage remained the same at 97.061% when pulling bfc96edd256e38ae91777b6634c0499b305e7848 on shawncarr:patch-1 into ea6f65260c490c2f8f5e60e5499e1713f1248e39 on Vincit:master.

Thanks!


IndexError: single positional indexer is out-of-bounds

When trying to run your code I got the above error in this line:
backtest.start(data, kernel='rbf', C=1, gamma=10)
any idea why?

What does it show when you do data.head()?


discordoauth2

No module named 'discordoauth2'

pip install -r requirements.txt

i tried to do "pip install discordoauth2" sorry.
But if i start main.py i just get
Getting discord build number...

Serving Flask app 'modules.oauth'
Debug mode: off

and then it closes

did you follow the readme?

yea

you have a data/tokens.txt file and you have tokens inside of there

yep


interfaces_assign.php UI speedup as requested on forum bounty board

Improves significantly and hopefully fixes bug#6400
Refactored interfaces_assign.php to to benefit people with large numbers of VLANs, as requested on the forum at https://forum.pfsense.org/index.php?topic=137391.0. Also contains a minor speedup for interfaces_vlan.php. Modified functions are contained in interfaces_fast.inc. Profiling code is still present but commented out, as is replaced code.

New commit also removes some commented code, some of which appeared to be slowing down page load significantly. Page load times are now much closer to generation times than previously.

Incorrect license text in new file

licence text changed as requested

changes made, the long comments were intended to explain my reasoning behind some of the more significant changes or changes that appeared to possibly conflict with the coding style guide (in the case of the indent removals)

Thanks. - Merged.
Those comments are better here than in the source I think :)

Appears to be causing nnumerous issues: https://redmine.pfsense.org/issues/8223

PR was reverted due to errors introduced.

Both bugs should be fixed now. I reverted back to stock pfSense code for naming OPT interfaces since the improvement wasn't huge anyway, which should take care of bug #8222 and I corrected the broken reference causing bug #8223


Caver-js transaction sample

Proposed changes
Removed "Sending KLAY at a glance" from Getting Started
Added a simple tutorial for caver-js
Gitbook link:
https://app.gitbook.com/o/-LZ3M2TduHoL5IluFRpr/s/2zebjlN2CCetZOGScXQP/dapp/sdk/caver-js/sending-transaction
Types of changes
Please put an x in the boxes related to your change.

[ ] Minor Issues and Typos
[ ] Major Content Contribution
[ ] Others

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to reach out. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ ] I have read the CONTRIBUTING GUIDELINES
[ ] I have signed the CLA
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Related issues

Please leave the issue numbers or links related to this PR here.

Further comments
If this is a relatively large content contribution, kick off the discussion by explaining why you would suggest the content contribution, etc...

@terrikwak You don't need to add .DS_Store files.

@kjhman21 Could you take another look?

I can also see .DS_Store files in your commit.


[PyTorch] torch.compile causes _default_get_amax to produce wrong results

Hello,
we noticed training instabilities in some of our FP8 trainings that use transformer_engine.pytorch.Linear to build a custom transformer stack. Looking into the checkpoints, we noticed that scaling_bwd deviates between tensor parallel ranks. We managed to build a minimal example that shows how the scaling factor starts to deviate:

Script that shows how scaling_bwd deviates between tensor parallel ranks
import os
import torch
import transformer_engine as te

world_size = int(os.environ["WORLD_SIZE"])
rank = int(os.environ["RANK"])

torch.cuda.set_device(rank)
torch.distributed.init_process_group(backend="nccl", world_size=world_size, rank=rank)
tp_group = torch.distributed.new_group(ranks=range(world_size))

fp8_recipe = te.common.recipe.DelayedScaling(
    margin=0,
    interval=1,
    fp8_format=te.common.recipe.Format.HYBRID,
    amax_history_len=1024,
    amax_compute_algo="max",
)

hidden_size = 2048
sequence_length = 2048

linear_1 = te.pytorch.Linear(hidden_size, hidden_size,
                            parallel_mode="column",
                            tp_group=tp_group)

linear_2 = te.pytorch.Linear(hidden_size, hidden_size,
                             parallel_mode="row",
                             tp_group=tp_group)

torch.manual_seed(32)
x = torch.randn(sequence_length, hidden_size).cuda()

for i in range(100):
    with te.pytorch.fp8_autocast(fp8_recipe=fp8_recipe, fp8_group=tp_group):
        output = linear_2(linear_1(x))

    output_grad = torch.randn_like(output)
    output.backward(output_grad)

    print(f"rank={rank}-i={i}: linear_1 scaling_bwd={linear_1.fp8_meta['scaling_bwd'].scale[0].item()}, "
          f"linear_2 scaling_bwd={linear_2.fp8_meta['scaling_bwd'].scale[0].item()}")

When running this script (torchrun --nproc-per-node 2 script.py) we see deviations for scaling_bwd on the second linear:
rank=1-i=99: linear_1 scaling_bwd=8756.66796875, linear_2 scaling_bwd=8896.1728515625
rank=0-i=99: linear_1 scaling_bwd=8756.66796875, linear_2 scaling_bwd=10947.583984375

Digging deeper we figured that this issue might arise from torch.compile which is applied inside amax_and_scale_update(). Specifically roll() and fill_() inside _update_amax_history() seem to be problematic. Here is another minimal example that shows the issue:
import torch
import transformer_engine as te

#amax_history = torch.ones(1024, 3, device="cuda")
#amax_history, _ = te.pytorch.fp8._default_get_amax(amax_history, "max")

amax_history = torch.ones(1024, 2, device="cuda")
amax_history, _ = te.pytorch.fp8._default_get_amax(amax_history, "max")
print(amax_history)
assert torch.all(amax_history[0, :] == 0.0)
assert torch.all(amax_history[1:, :] == 1.0)

The script has to be executed multiple times. On the first pass the assert usually passes. If torch.jit.script is used instead of torch.compile (NVTE_TORCH_COMPILE=0) everything seems to be fine. Looking at the triton code (TORCH_COMPILE_DEBUG=1) my assumption is that the mask is missing during load and store, but I did not validate this assumption. This would make it an issue with PyTorch. But still I would kindly ask you to try to reproduce my findings first before reporting this. Overall I am very puzzled how this became a problem for our current training and was fine in many other scenarios. But it seems that torch.compile produces a generalized kernel if it approaches different column sizes of amax_history. If you uncomment the two lines in the example above everything is fine as well.
As a quick fix I found that replacing amax_history[0].fill_(0.0) with amax_history = torch.cat([torch.zeros_like(amax_history[:1]), amax_history[1:]]) works but prodces an additional kernel launch.
I ran everyhing on a H100 DGX inside the official NVCR PyTorch Container (nvcr.io/nvidia/pytorch:23.12-py3).

Thanks for the detailed comment. I haven't been able to repro it on my end so far, will investigate! @Marks101

@ptrblck FYI, we may need some help from your side after Kirthi's initial investigation.

Thank you for the quick replies!
I have been digging deeper and reduced the issue to this piece of code (now independent of transformer-engine):
import torch

def roll_and_zero_first_row(x):
    x = torch.roll(x, -1, 0)
    x[0].fill_(0.0)
    return x

inp = torch.ones(1024, 2, device="cuda")
compiled = torch.compile(roll_and_zero_first_row)

out_eager = roll_and_zero_first_row(inp)
out_compiled = compiled(inp)

print("compiled", out_compiled)
print("eager", out_eager)
assert torch.all(out_eager == out_compiled)

I run the script as follows:
docker run --gpus all --rm -v /tmp/test.py:/tmp/test.py nvcr.io/nvidia/pytorch:23.12-py3 python /tmp/test.py

The assertion fails non-deterministically. This issue is not reproducable in each run.
One thing I noticed after setting TORCH_COMPILE_DEBUG=1 is that the problem seems to occur if XBLOCK=256 is the fastest kernel in the triton heuristics. XBLOCK=128 seems to run properly. This is the log output I am refering to:
[2024-01-15 09:49:27,109] torch._inductor.triton_heuristics: [DEBUG] XBLOCK: 256, num_warps: 4, num_ctas: 1, num_stages: 1, enable_warp_specialization: False, enable_persistent: False: 0.005248, nreg 12, nspill 0, #shared-mem 0
[2024-01-15 09:49:27,109] torch._inductor.triton_heuristics: [DEBUG] XBLOCK: 128, num_warps: 4, num_ctas: 1, num_stages: 1, enable_warp_specialization: False, enable_persistent: False: 0.005344, nreg 10, nspill 0, #shared-mem 0

It would be really great if you could try to reproduce these findings. Thank you!

I'm able to reproduce this as well. @ptrblck Could someone from the PyTorch team take a look?

By now I am pretty sure that this issue might arise from triton. I opend an issue there https://github.com/openai/triton/issues/2941

@Marks101 I'm observing a reliably reproducible failure associated specifically with the input size of 1024. The generated triton kernel omits the mask for checking bounds during the triton.language.load instruction resulting in the observed difference in amaxes. This is not the case for any other inputs size I've looked at thus far

@ksivaman yes, this is in accordance with my findings. It is specifically with the input shape (1024, 2) that the mask is omitted. But from my understanding it should be fine to omit it because the the element count of 2048 is evenly divisible by the block sizes 128 or 256.

I haven't done a fully exhaustive search but (1024, 2), (2048, 1), (2048, 2), (4096, 1), (4096, 2), (8192, 1), (8192, 2) are some of the other sizes that fail.

@ksivaman thanks for bringing up this PR. This looks like a decent fix that should do it for the moment


API for getting a .NET Stream from the virtual file system.

It would be pretty useful to have a method or whatever return a System.IO.Stream into Godot's file system. Stuff from the .pck file can't be gotten as a Stream otherwise.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


Update index.html

Created a new PR due to a typo didn't add .js to the file name
sorry for the inconvenience
the issue at hand remains peer not found

Actually i'm busy sir... will check tomorrow


How to test / develop wechaty-puppet-hostie locally?

I am wondering what's the best way to test and develop wechaty-puppet-hostie locally? Currently I have to start a server in cloud and connect it from local, then modify each part of the code and test, which is pretty complex. Is there any better way to do this? If not, shall we think about designing a local dev script or something that help us develop wechaty-puppet-hostie locally?

Could you please describe what you want to test in details for better understanding your requirement?

I am considering design a message buffer

the client is offline, the buffer save the emitted messages
the client reconnected to the server, emit these messages

This will eliminate the risk of missing messages during the offline.
So if I can run the hostie client and server together, it would be much more convenient for me.


Make more portable, enhance README

What

Make this test more portable by
allowing for different directory setups for cpu and cpuacct
allowing for possibly missing scaling_governor and/or energy_performance_preference
fail if unable to create cgroup
Enhance README to explain what but is being tested and how, and explain limitations of the test.

@chiluk wrote

This patch breaks throttled metrics on Cent 7. That's why I haven't approved it yet. Throttled periods should be 50+ for both good and bad kernels but it ends up being 0.

I would be happy to fix this if I knew how. I don't have Cent 7 on hand and am not familiar with Centos at all. Are you sure it is the patch that broke Cent 7 and not the original test? My guess would be that Cent 7 has disabled CFS in a way that this test does not take into account.
If you know how to fix this, feel free to make the change. If not, I will look into it when I have time.

Yeah time is not something I have right now with daycares being closed.  Additionally this project was never intended to grow into a living project.  I'll try to look at it if I ever find that elusive time.


Vendor (Item without Value)

If item in sell list of vendor has no price. (It is a mistake in the default scripts)
price set as<PHONE_NUMBER>
and the order of the goods list is also broken

I haven't got the issue, if you think there is a missing code in scripts, you need to open this issue in Scripts-X. If you give an example of the issue, we can take a look.

On my side I removed the value of an item

I use Orion. Value is set to 43 by default.. I don't know why. But its not<PHONE_NUMBER>

c_scribe - price of books

Maybe there is a misunderstanding, {5 10} is not a price, it's an amount of item can be sold by vendor, in this example {5 10} means it will sell random value from 5 to 10. Like it can sell 7 i_book_sm or next time it restocked it can be 6, 9, 10 etc. Prices comes from VALUE if TAG.OVERRIDE.VALUE isn't set for item.

I KNOW WHAT IT IS. {5 10}
[ITEMDEF 0ff1]
DEFNAME=i_book_sm
TYPE=t_book
CATEGORY=Items by Professions
SUBSECTION=Scribe
DESCRIPTION=Dark Brown Book

I didn't do anything. I just downloaded the scripts
c_scribe_f

This was always the case with the X1 version, but an item that was not previously entered would not appear in the vendor and would give a console warning “ non-vendable items”

There is a vendable item class but could you give me an example, because I haven't got what you mean with "item that was not previously entered" while you have to set sell and buy menus statically in script.

Normalde bir eşyaya hiç value değeri verilmemiş (value=0 girilmesi hariç) bir itemin altında hiç bir şekilde value yazmıyor ise o eşya vendorda listelenmeye çalıştığında (tam emin değilim, satış layerine eklendiğinde de olabilir) “bu eşya satılabilen bir eşya değil” gibi bir uyarı verip satış listesine hiç eklemiyordu ama şu an bir eşyaya hiç bir value değeri belirtmediği zaman yukardakş görselde belirtildiği üzere vendor listesine eklediği gibi bir de anlamsız satış fiyatı set ediyor.

On my side I removed the value of an item
I use Orion. Value is set to 43 by default.. I don't know why. But its not<PHONE_NUMBER>

Could be that price taken from tiledata?

The problem is exactly this,
[ITEMDEF i_zero_valued_item]
DEFNAME=i_zero_valued_item
ID=i_katana
NAME=zero valued
TYPE=t_script
Let's think of an item like this, no VALUE= value is entered in the burqa, if we create this item directly without calling the vendor list and look at its value with .xshow value, it appears as 0 (it should actually appear empty) then when we call the sell menu after adding it to a vendor's sell list, that is, when we say buy, the value of all these i_zero_valued_item items is equal to INT_MIN. I looked at the old versions but I couldn't see the difference. Whatever happens, it happens after the sell list is brought, I think the problem is exactly here.

The problem is exactly vendorItem->Item_GetDef()->ResetMakeValue(); I think there is a data type mismatch m_iLo and m_iHi are int64 but under CItemBase::GetMakeValue GetLinear is int

Okay the issue is exactly mismatch of default values

The issue, as you said, is a mismatch problem, but it's just a simple faulty if statement. Instead of the default INT32_MIN, INT64_MIN was used in the if statement, which caused the mismatch for items without prices.


Recurring event no longer works.

When an event is made and the box is checked to make it recurring and it is saved, it displays an error.

Issue was resolved, there was an error when passing in a date in the event creator so we had to reformat it.


Puppeteer issue on Docker MacOs M1

Hi, I saw the similar issue has already been there, however it was directly for NPM.
Can you build special Docker image for Docker engine on MacOs M1 architecture?
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested Logging in with profile 'XXX'... Using AWS SAML endpoint https://signin.aws.amazon.com/saml Error: Protocol error (Target.setDiscoverTargets): Target closed.     at /aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/common/Connection.js:71:63     at new Promise (<anonymous>)     at Connection.send (/aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/common/Connection.js:70:16)     at Function.create (/aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/common/Browser.js:117:26)     at ChromeLauncher.launch (/aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/node/Launcher.js:103:56)     at processTicksAndRejections (internal/process/task_queues.js:95:5)     at async Object._performLoginAsync (/aws-azure-login/lib/login.js:461:23)     at async Object.loginAsync (/aws-azure-login/lib/login.js:324:30)

Hi, Do we have any solutions in place towards solving this mentioned issue?

I'm also on a mac m1 (uname -m # => arm64).  I tried specifying the am64 architecture when I ran docker (docker -v# => Docker version 20.10.12, build e91ed5707e), and it also did not work:
docker run --platform linux/amd64 --rm -it -v ~/.aws:/root/.aws sportradar/aws-azure-login
Logging in with profile 'default'...
Using AWS SAML endpoint https://signin.aws.amazon.com/saml
Error: Protocol error (Target.setDiscoverTargets): Target closed.
    at /aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/common/Connection.js:71:63
    at new Promise (<anonymous>)
    at Connection.send (/aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/common/Connection.js:70:16)
    at Function.create (/aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/common/Browser.js:117:26)
    at ChromeLauncher.launch (/aws-azure-login/node_modules/puppeteer/lib/cjs/puppeteer/node/Launcher.js:103:56)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async Object._performLoginAsync (/aws-azure-login/lib/login.js:461:23)
    at async Object.loginAsync (/aws-azure-login/lib/login.js:324:30)

I am also having the exact same error as above. Is there some workaround?

Hi, workaround for this issue is as follows,

npm install -g aws-azure-login
aws-azure-login --configure
aws-azure-login --profile profile_name
docker run --rm -it -v ~/.aws:/root/.aws sportradar/aws-azure-login --configure --profile profile_name

I second @vignesh1992 and using the npm installed one solves this problem.

I'm also having the same problem. I'm not sure if it's related to the architecture though.
It looks to me it's a connectivity problem due to the fact Docker is running in a VM and not in the host as in Linux.
That said, I tried running with --privileged --network host and still got a similar error.


Remove 'prerender' from document VisibilityState

Resolves https://github.com/microsoft/TypeScript/issues/31957

npm run build && npm run baseline-accept should be done to fix the test.

npm run build && npm run baseline-accept should be done to fix the test.

Unfortunately, I get the following issues when running those commands:
> npm run build && npm run baseline-accept

> tsjs-lib-generator@ build D:\Development\Projects\TSJS-lib-generator
> tsc --p ./tsconfig.json && node ./lib/index.js

node_modules/@types/node/index.d.ts:74:11 - error TS2300: Duplicate identifier 'IteratorResult'.

74 interface IteratorResult<T> { }
             ~~~~~~~~~~~~~~

  node_modules/typescript/lib/lib.es2015.iterable.d.ts:41:6
    41 type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;
            ~~~~~~~~~~~~~~
    'IteratorResult' was also declared here.

node_modules/typescript/lib/lib.es2015.iterable.d.ts:41:6 - error TS2300: Duplicate identifier 'IteratorResult'.

41 type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;
        ~~~~~~~~~~~~~~

  node_modules/@types/node/index.d.ts:74:11
    74 interface IteratorResult<T> { }
                 ~~~~~~~~~~~~~~
    'IteratorResult' was also declared here.

@saschanaz Unfortunately, I get the following issues when running those commands:
> npm run build && npm run baseline-accept

> tsjs-lib-generator@ build D:\Development\Projects\TSJS-lib-generator
> tsc --p ./tsconfig.json && node ./lib/index.js

node_modules/@types/node/index.d.ts:74:11 - error TS2300: Duplicate identifier 'IteratorResult'.

74 interface IteratorResult<T> { }
             ~~~~~~~~~~~~~~

  node_modules/typescript/lib/lib.es2015.iterable.d.ts:41:6
    41 type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;
            ~~~~~~~~~~~~~~
    'IteratorResult' was also declared here.

node_modules/typescript/lib/lib.es2015.iterable.d.ts:41:6 - error TS2300: Duplicate identifier 'IteratorResult'.

41 type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;
        ~~~~~~~~~~~~~~

  node_modules/@types/node/index.d.ts:74:11
    74 interface IteratorResult<T> { }
                 ~~~~~~~~~~~~~~
    'IteratorResult' was also declared here.

Try rebasing + npm i and do it again, as it's fixed in https://github.com/microsoft/TSJS-lib-generator/pull/737.

@saschanaz Thanks for the tip, everything seems to work now.

@saschanaz I just recreated the entire PR with a force push to avoid issues.

@saschanaz Sorry for interrupting, but may I ask if there is anything I may help with to get this PR merged?

Pinging @sandersn

@saschanaz @sandersn I'm sorry to disturb again, but may I ask if there are any blocking factors to resolve regarding this PR?

Pinging @orta this time ..
From: Kristóf<EMAIL_ADDRESS>Sent: Thursday, September 19, 2019 7:22 PM
To<EMAIL_ADDRESS>Cc: Kagami Sascha<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [microsoft/TSJS-lib-generator] Remove 'prerender' from document VisibilityState (#732)
@saschanazhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsaschanaz&data=02|01||5ab3ee57910443aa023c08d73ceb37a5|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637044853250098160&sdata=rGrAmyrIxiTshU2CZoaPZ%2FL4kGyaCTS5maZf1WHgl7w%3D&reserved=0 @sandersnhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsandersn&data=02|01||5ab3ee57910443aa023c08d73ceb37a5|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637044853250108165&sdata=ObVlEjl46bCs0zKLBNGT4qt6cCiqrCVw6o0MmPYfggU%3D&reserved=0 I'm sorry to disturb again, but may I ask if there are any blocking factors to resolve regarding this PR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FTSJS-lib-generator%2Fpull%2F732%3Femail_source%3Dnotifications%26email_token%3DAAZ5ITVITGYLFZMRPGJCFBDQKNHEXA5CNFSM4HY5PHA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7C7MZI%23issuecomment-533067365&data=02|01||5ab3ee57910443aa023c08d73ceb37a5|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637044853250108165&sdata=1aEW065oQBE%2Fl46VM41VJDytCrL27SCm0v0WaHoeOeg%3D&reserved=0, or mute the threadhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAZ5ITQ4L3QMEUUOFNJZGP3QKNHEXANCNFSM4HY5PHAQ&data=02|01||5ab3ee57910443aa023c08d73ceb37a5|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637044853250118170&sdata=XQSHu3lk4%2B8Q4FMHNjwtpO5We%2BJERF4crclCcic%2BGNE%3D&reserved=0.

Thanks for your patience! It's been a busy release.

I'm sorry but I failed to see why U remove prerender, It's still on in MDN https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilityState

@qinyuhang It’s marked as deprecated and has already been removed from the corresponding spec.

I marked it as deprecated in MDN.


Improve code coverage

Since code coverage has been enabled, it's time to clean up a bit to get us up to a reasonable standard of 80% code coverage.

Codecov Report
Base: 67.48% // Head: 68.98% // Increases project coverage by +1.49% :tada:

Coverage data is based on head (94bd01a) compared to base (86c1719).
Patch coverage: 69.23% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop      #44      +/-   ##
===========================================
+ Coverage    67.48%   68.98%   +1.49%
===========================================
  Files           52       53       +1
  Lines          895      877      -18
  Branches         0       77      +77
===========================================
+ Hits           604      605       +1
+ Misses         291      246      -45
- Partials         0       26      +26

Impacted Files
Coverage Δ

...s/Patches/CreatureEquipmentMakeInfoPatchGetProb.cs
50.00% <0.00%> (-9.10%)
:arrow_down:

...fts/Patches/UseSkillPatchFinishWorkSuccessfully.cs
50.00% <0.00%> (-12.50%)
:arrow_down:

...Implementations/Adapters/AnimationScriptAdapter.cs
0.00% <0.00%> (ø)

...porationMods.Common/Implementations/FileManager.cs
0.00% <0.00%> (-2.05%)
:arrow_down:

...myCorporationMods.Common/Implementations/Logger.cs
0.00% <0.00%> (-3.85%)
:arrow_down:

...mization/Extensions/CustomizingWindowExtensions.cs
62.06% <0.00%> (-3.45%)
:arrow_down:

...n/Patches/AgentInfoWindowPatchEnforcementWindow.cs
69.23% <0.00%> (-7.70%)
:arrow_down:

...llDieFromWorking/Extensions/AgentSlotExtensions.cs
75.00% <0.00%> (-6.25%)
:arrow_down:

...ions/CreatureEvaluators/HappyTeddyBearEvaluator.cs
90.90% <0.00%> (-9.10%)
:arrow_down:

...lDieFromWorking/Patches/AgentSlotPatchSetFilter.cs
85.71% <0.00%> (-4.77%)
:arrow_down:

... and 24 more

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

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


Bug: MAX_PRES_VALUE and MIN_PRES_VALUE is not working

Hi guys,
The MAX_PRES_VALUE and MIN_PRES_VALUE variables in objects in is not working.
Do you think it will possible for you to fix it if you have time ^^ ?
I don't know if this data is used very much :)
Sincerly,
Simon

Hi @debraysimon - could you elaborate a bit more ? How are you using these variables ? This is not really a property we have used much with the bacnet server, so its likely that we havent handled the functionality

I don't use this property at the moment, but as it is displayed on YABE I think we should either integrate the function or remove these two properties for users... 😅


Open event fires twice

select2:open event firing twice when I open the select element. Select2:opening event have the same problem.
It seems like previous issue #3503 but it still remaining on 4.0.1.

I am not able to reproduce this on the documentation website.

Can you expand upon the issue you are facing by adding a few more pieces of information to your bug report?

What steps can be used to reproduce the issue?
What is the bug and what is the expected outcome?
What browser(s) and Operating System have you tested with?
Does the bug happen consistently across all tested browsers?
What version of jQuery are you using? And what version of Select2?
Are you using Select2 with other plugins?

The contributing guide contains a useful section with a few questions which can help us track down the bug and speed up the process of finding a fix for it.  The creation of an isolated test case would also be useful.

Sorry for the inconvenience, i found an error in my code which disturb select2:open event.
I'll close the ticket.


list available versions for update

Is there a way to list out the available versions of a tool for update?
e.g. dotnet tool update dotnet-ef -g --version 3.0.0
works, but I would like to know if there is a version 3.1.0.
What is the download endpoint of all the tools that could be queried with this command:
e.g.
dotnet tool info dotnet-ef --versions

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6a8171f4-8466-98ed-acb8-49563b864d16
Version Independent ID: a1b7af2d-e2ba-bc4b-4d35-a8edbaa1249f
Content: dotnet tool update command - .NET Core CLI
Content Source: docs/core/tools/dotnet-tool-update.md
Product: dotnet-core
Technology: dotnet-cli
GitHub Login: @mairaw
Microsoft Alias: mairaw

@OzBob Hello.
I don't believe so. You would want something that looks at the NuGet package feed, such as the standalone nuget cli

Powershell magic to the rescue:
Find-Package "dotnet-ef" -AllVersions -IncludePrerelease -ExactMatch | % {$.Versions | % {$.Version}}


[AR] Texture/Material Fails to Load in AR

Hello,
I'm trying to diagnose an issue where a texture fails to load in AR, but appears perfectly fine on the mesh when in the model viewer. The problem seems to be only happening on Android devices.
You can preview the model here.
The affected area is the front face of the cabinet doors. They will simply fail to draw and disappear in AR, while the rest of the mesh loads clearly.
I've looked at the .gltf in VS-Code with no sign or warning of blatant issues (just some 'unused object' notifications). What I'm trying to determine is if I'm not following some sort of rule for the image formats that the .gltf loads. The textures are in JPG format. There's a plywood edge texture at 512x4096 resolution, and the problematic one at a resolution of 4096x2048.
I've tested these at lower resolutions and the same problem persists for the affected material. It does not make sense to me however that model displays correctly in the viewer, but not in AR.
Would greatly appreciate any insights on the matter.

Which AR mode are you referring to? I would imagine this is SceneViewer, as webXR uses the same renderer as in non-AR. If you're not sure, you can set a single ar-modes value. A screenshot would also help. Also, can you fill in the rest of the issue template regarding OS and browser versions?

OS is Windows 10. But AR experience is on Android.
Browser is Chrome on Android (Version 85.0.4183.81)
Here the model loads without an issue in the viewer, then in AR.

I'm not 100% sure what version of model viewer (I did not implement/create the site where we host our files), but yes pretty sure it's scene viewer.

I brought the .gltf into Blender and re-exported. Issue has been resolved.
Appreciate your time.


Math operators (attempt 2)

Closes #2 and supersedes #8
Most code is still automatically generated, this time with proper xAssign support for mutable types (Except Vec3i subclasses, which I've treated as immutable due to it not having a way to directly mutate it) and documentation.

Seems like we only have vec * scalar, and not scalar * vec?

Seems like we only have vec * scalar, and not scalar * vec?

Yep, that seems like a really weird operator to me though? Something about it just doesnt make much sense to me with the order.
Its also somewhat incompatible with the mutable types, because xAssign wouldn't work for them.

Seems like we only have vec * scalar, and not scalar * vec?

Yep, that seems like a really weird operator to me though? Something about it just doesnt make much sense to me with the order.

What do you mean? Just like with scalars, for vectors you have: x * 2 = 2 * x = x + x

Its also somewhat incompatible with the mutable types, because xAssign wouldn't work for them.
I don't see why it's an issue you can't use xAssign? If I have a mutable vector and an integer, I'm gonna do the xAssign on the vector and not on the integer.

Seems like we only have vec * scalar, and not scalar * vec?

Yep, that seems like a really weird operator to me though? Something about it just doesnt make much sense to me with the order.

What do you mean? Just like with scalars, for vectors you have: x * 2 = 2 * x = x + x

Its also somewhat incompatible with the mutable types, because xAssign wouldn't work for them.
I don't see why it's an issue you can't use xAssign? If I have a mutable vector and an integer, I'm gonna do the xAssign on the vector and not on the integer.

Wow apparently I never replied here, whoops!
Working on this now in a new PR thats also going to tackle matrix math, wanted to get the basics in first 😅


CosmosException: Object contains header information from request and response

We are continuously addressing and improving the SDK, if possible, make sure the problem persist in the latest SDK version.

Describe the bug
Right now, CosmosException is having Request and Response Object, due to which if this object is getting serialized, it would print all the details in the logger, including headers.
To Reproduce
Serialize CosmosException
Expected behavior
It should not have any sensitive information
Actual behavior
Current, it prints, all the information, including headers.
Environment summary
SDK Version: All
OS Version (e.g. Windows, Linux, MacOSX): Any
Additional context
Add any other context about the problem here (for example, complete stack traces or logs).

The CosmosException is not printing the request and response headers ever - only customers would be if they serialize the exception to json and log it - that is something the application code would do - not the SDK. And CosmosException.toString as all the info needed. So the fix here is simple - do not serialize the exception to json - Exceptions are serializable for the purpose of being able to use the across AppDomains - not to log them. The .Net API contract is that Exception.Message ro Exception.ToString (including callstack) have the relevant info to log. Serializing a CosmosException to json will result in inefficiency and there are no guraantees to avoid any headers.


Added multiPickSprites and WithRay

as requested at https://forum.babylonjs.com/t/multipick-sprites/4963
Test results in console
Basic test https://tender-murdock-275855.netlify.com/sprites/test8.html
WithRay test https://tender-murdock-275855.netlify.com/sprites/test9.html
Two managers https://tender-murdock-275855.netlify.com/sprites/test10.html

Please check my amendments are as you suggested, changed in Intersects as well

Double double check final result as I was rushing to get them done.

I will not merge. I prefer waiting for you to make sure everything is fine

(linting has some issues by the way)
this can wait until next week

I am now happy with the changes I made in line with your suggestions to avoid instantiating vector3s.


test_rate_limiter: Make test_add_remove_rule clean up its rules.

This test was polluting the rules for other tests, due to adding rate
limiting rules and not removing them.
Discovered thanks to a test failure that shouldn't have been happening in https://github.com/zulip/zulip/pull/22647#discussion_r941840435

Merged, thanks @mateuszmandera!


Flutter application missing framework dSYMs

I've had a production crash reported by Crashlytics but it's not able to show me any details as there's a required dSYM missing with UUID 1F29F0F6-7F1B-3049-A2C2-B0101BD2AB95
Checking all the dSYMs in the build output folder does not show any dSYMs with that UUID. Doing a quick google of the UUID shows a couple of posts https://community.flutterflow.io/c/discuss-and-get-help/unable-to-deploy-to-app-store and https://community.flutterflow.io/c/discuss-and-get-help/failed-logs-can-someone-help that have the same UUID - so I'm guessing this dSYM is a framework or other library dSYM and not something specific to my code.
I noticed there's another 5 missing dSYMs in the Crashlytics dSYMs page as well, but those are showing as optional so I'm not sure how important those ones are. For completeness though they are as follows:

7626834B-C95E-307C-B8F1-04EB0824D2FE
0C071349-588B-309E-924B-6AF69FA560D7
71D7C146-9E6E-33A6-BB0D-3CF4763607F3
4106CC2E-94B4-3219-8B86-8FEA05CABB7D
45A0FAD5-4B81-32BF-A24E-76708AA387DF

I've had a number of crashes in the past (even on that same build) that haven't reported issues with missing dSYMs so I'm guessing most of the dSYMs are getting included in the build output fine without issues.

flutter doctor -v (version used to build production release that experienced crash)
[✓] Flutter (Channel stable, 3.3.1, on macOS 12.3.1 21E258 darwin-arm, locale en-AU)
    • Flutter version 3.3.1 on channel stable at /Users/nvx/flutter-331/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 4f9d92fbbd (3 months ago), 2022-09-06 17:54:53 -0700
    • Engine revision 3efdf03e73
    • Dart version 2.18.0
    • DevTools version 2.15.0
[✓] Xcode - develop for iOS and macOS (Xcode 13.4.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Build 13F100
• CocoaPods version 1.11.3
[!] Flutter IDE Support (No supported IDEs installed)
• IntelliJ - https://www.jetbrains.com/idea/
• Android Studio - https://developer.android.com/studio/
• VS Code - https://code.visualstudio.com/
[!] Connected device
! No devices available
[✓] HTTP Host Availability
• All required HTTP hosts are available
! Doctor found issues in 2 categories.

I've managed to find the missing dSYM, looks like flutter build ios does not create it, but flutter build ipa does?
UUID: 1F29F0F6-7F1B-3049-A2C2-B0101BD2AB95 (arm64) /Users/nvx/app/build/ios/archive/Runner.xcarchive/dSYMs/FBLPromises.framework.dSYM/Contents/Resources/DWARF/FBLPromises

yep, it's super annoying!
here is a workaround used in codemagic
      name: Upload dsym artifacts to Firebase Crashlytics
      script: |
        find . -name "*.dSYM*"
        dSymZipPath=$(find . -name "*.dSYM.zip" | head -1)
        echo "dSymZipPath: $dSymZipPath"
        dSymPath="$(dirname "${dSymZipPath}")"
        googleServicesPath="$FCI_BUILD_DIR/build/ios/archive/Runner.xcarchive/Products/Applications/Runner.app/GoogleService-Info.plist"
        crashlyticsScriptPath="$FCI_BUILD_DIR/ios/Pods/FirebaseCrashlytics/upload-symbols"
        echo "Publishing debug symbols from $dSymPath to Firebase Crashlytics"
        $crashlyticsScriptPath -gsp $googleServicesPath -p ios $dSymPath

I stress the word workaround, if isn't a dupe
this situation should be addressed

Thanks for the report and update. Keeping this issue open for team's attention and insights.

I've managed to find the missing dSYM, looks like flutter build ios does not create it, but flutter build ipa does?

This behavior is controlled by the DEBUG_INFORMATION_FORMAT build setting for the native code built, like plugins.  By default for a brand new Xcode iOS  app (and Flutter app) this is set to DWARF in debug mode (symbols are contained in the binary) and DWARF with dSYM file in release (a separate dSYM file is created to reduce binary size).  So it's expected that in debug mode there is no dSYM file.

I've had a production crash reported by Crashlytics but it's not able to show me any details as there's a required dSYM missing with UUID 1F29F0F6-7F1B-3049-A2C2-B0101BD2AB95

These UUIDs in a vaccuum aren't helpful, would need to see a crash log to know what framework this is even referencing--is it Flutter, is it a plugin, is it something else you added.  If it's Flutter.framework symbols can be symbolicated if you know the version of Flutter you shipped: https://github.com/flutter/flutter/wiki/Crashes#ios

I've managed to find the missing dSYM, looks like flutter build ios does not create it, but flutter build ipa does?

This behavior is controlled by the DEBUG_INFORMATION_FORMAT build setting for the native code built, like plugins. By default for a brand new Xcode iOS app (and Flutter app) this is set to DWARF in debug mode (symbols are contained in the binary) and DWARF with dSYM file in release (a separate dSYM file is created to reduce binary size). So it's expected that in debug mode there is no dSYM file.

Sorry I should have given the full command line for each, --release was specified in both cases - both of which generated some dSYMs, but the ios command was missing some while the ipa command created more (including the missing ones reported in crashlytics):
flutter build ipa --release --obfuscate --split-debug-info=build/symbols --extra-gen-snapshot-options=--save-obfuscation-map=build/symbols/ios.mapping.json
and
flutter build ios --release --obfuscate --split-debug-info=build/symbols --extra-gen-snapshot-options=--save-obfuscation-map=build/symbols/ios.mapping.json

I've had a production crash reported by Crashlytics but it's not able to show me any details as there's a required dSYM missing with UUID 1F29F0F6-7F1B-3049-A2C2-B0101BD2AB95

These UUIDs in a vaccuum aren't helpful, would need to see a crash log to know what framework this is even referencing--is it Flutter, is it a plugin, is it something else you added. If it's Flutter.framework symbols can be symbolicated if you know the version of Flutter you shipped: https://github.com/flutter/flutter/wiki/Crashes#ios

That particular build was made with flutter 3.3.1 (latest at the time that build was made). Unfortunately Crashlytics doesn't appear to show any information other than the version of my app that experienced the crash and the dSYM UUID (unless I'm missing something).
In the end it appears that the UUID belonged to FBLPromises as mentioned in the second post. So the question at this point is why the build process is only generating those dSYMs sometimes (ipa --release and not ios --release build command- in fact the differences between these two commands in general is a bit confusing), and why it wasn't uploaded to crashlytics automatically like the other symbols (the CI pipeline to build the app initially had used ipa --release, it was only later on trying to reproduce the build to find the dSYM that I'd mistakenly used ios --release without realising I was using the wrong command)

flutter build ios doesn't create an xcarchive, you need to either run flutter build ipa or ship from Xcode, which starts by making the archive.  Comparing flutter build ios to ipa output doesn't necessarily make sense in this context; instead it does make sense to compare flutter build ipa to archiving through Xcode.  You could compare flutter build ios to just building in Xcode, and the build products directory should look the same (flutter is running xcodebuild under the covers).
cc @vaind re https://github.com/flutter/flutter/pull/101586

Unfortunately Crashlytics doesn't appear to show any information other than the version of my app that experienced the crash and the dSYM UUID (unless I'm missing something).

I'm not sure what Crashlytics is doing, but a normal iOS/macOS crash log at the bottom shows all the loaded frameworks and their UUIDs, which should include plugin frameworks like FBLPromises.  At the least sharing what you're getting from Crashlytics would be helpful to understand which UUID is missing symbolication that you're talking about.

I'm not sure what Crashlytics is doing, but a normal iOS/macOS crash log at the bottom shows all the loaded frameworks and their UUIDs, which should include plugin frameworks like FBLPromises. At the least sharing what you're getting from Crashlytics would be helpful to understand which UUID is missing symbolication that you're talking about.

Since I've identified and uploaded the dSYM the missing dSYM error has disappeared (and there is now a new visible crash report instead) so I can't take a screenshot - but literally the only thing visible in Crashlytics is an error saying that  crash reports are not visible due to missing dSYMs and the missing UUID along with a link how to upload them.

I agree that flutter build ios may be confusing. Even though the release docs say to use flutter build ipa, just plain intuition & naming convention when building for multiple platforms (android, windows, etc) it's pretty easy to arrive at "flutter build ios". Why it produces different set of dSYMs and whether it should do so, that's probably the real issue here.

Indeed - after getting the error, I thought "I'll rebuild that version of the app manually using that version of flutter and see if I can find the dSYMs in the build folder" and mistakenly defaulted to using ios instead of ipa (even though the CI scripts used to build the real release used ipa).
Considering after doing the right build command (ipa) did make some of the dSYMs appear, what remains is really likely the following:

A bug in the crashlytics uploader (why did most of the symbols get uploaded fine but not these couple) - which is out of scope for this repo
Why there are some "optional" dSYMs that crashlytics reports are relevant to this particular build that are still not in the build directory when building with either ios or ipa (I'm not sure how Crashlytics determines what dSYMs are optional vs required).

For the latter I can at least share what that looks like in Crashlytics for those missing dSYMs. Note that required dSYMs appear in the exact same format except with the "Type" column showing required instead of optional (and while there are missing "required" dSYMs crashes are missing from the main dashboard page). Also note that the rows are not clickable and no additional information is available.

Hello, an offtopic question.
Why is not documented anywhere? Or maybe it is?
flutter build ipa --release --obfuscate --split-debug-info=build/symbols --extra-gen-snapshot-options=--save-obfuscation-map=build/symbols/ios.mapping.json

If you obfuscate the app, sometimes you need to deobfuscate class / fields name.

This is still an issue. I've created & archived a buid of my flutter ios app, yet the uuid of the dsym crashlytics wants me to upload is completely missing from my archived build

Now this is happening for 3.19.2 And XCode 16 beta

Its happening also on 3.22.2
Flutter (Channel stable, 3.22.2, on macOS 15.0 24A5264n darwin-arm64, locale en-US) (Also flutter doctor is showing wrong data about xcode and os).
After building achieve and doing validation I'm getting this error
The archive did not include a dSYM for the Flutter.framework with the UUIDs [4C4C44CE-5555-3144-A1C1-C6EFF75C53E3]. Ensure that the archive's dSYM folder includes a DWARF file for Flutter.framework with the expected UUIDs.

@Mistic92 confirmed on my machine also:
Flutter (Channel stable, 3.22.2, on macOS 15.0 24A5264n darwin-arm64, locale en-PT).
Any updates on your end?

Tried on my second machine:
Flutter (Channel stable, 3.22.1, on macOS 14.5 23F79 darwin-x64, locale en-US)
Confirmed - built with no issues.

@Mistic92 and @danfq
You're saying this is actually has an archive validation error with the Xcode betas, so blocking App Store submission?

Yes, @jmagman , that's it.
I checked the folder and the file is in fact not there.

This will involve:

Move the dSYM into the Flutter.framework and FlutterMacOS.framework engine artifacts so they are downloaded together.  We should probably keep uploading the dSYM to its own zip for niw
In the tool, copy the dSYM from the artifacts to the right place in the build products directory around here:
https://github.com/flutter/flutter/blob/3bd29677b910ac6893883e73e58da6363a47f42c/packages/flutter_tools/lib/src/build_system/targets/ios.dart#L302
Update docs https://github.com/flutter/flutter/blob/master/docs/engine/Crashes.md#ios

On archive, there's already a dSYM folder with App and Runner dSYMs.  After this work, there should also be a Flutter.framework.dSYM or FlutterMacOS.framework.dSYM.
See also https://github.com/flutter/flutter/pull/101586 (App dSYM) for all the places that PR touched and tested.
cc @cbracken

https://github.com/flutter/engine/pull/54414 has rolled to master, I now see:
bin/cache/artifacts/engine/ios-release/extension_safe/Flutter.xcframework/ios-arm64_x86_64-simulator/dSYMs/Flutter.dSYM
bin/cache/artifacts/engine/ios-release/extension_safe/Flutter.xcframework/ios-arm64/dSYMs/Flutter.dSYM
bin/cache/artifacts/engine/ios-release/Flutter.xcframework/ios-arm64_x86_64-simulator/dSYMs/Flutter.dSYM
bin/cache/artifacts/engine/ios-release/Flutter.xcframework/ios-arm64/dSYMs/Flutter.dSYM

🎉

This is fixed on master branch as of https://github.com/flutter/flutter/pull/153215 (commit c375dd8d72ce41316ad39e568254d16c6462e6fe).
Please give it a try and let us know if you're still running into issues.

I can confirm that there are no issues.
Thanks for fixing this! 😃

@nvx can you (or anyone hitting this) also confirm this is fixed on the master channel? We'd like to get this hotfixed ASAP given the likely September timeline of Xcode 16/iOS 18.
Thanks!


[silx view] Custom NXdata view is not updated when axis are updated

No problem with PyQt4
PyQt5 5.3.2, the view is only updated when the mouse is over the widget
PyQt5 5.10.1, the behaviour is worst

It looks like when the header uses ResizeToContents, the view is not anymore updated. No idea why.


Add GitHub Actions to run tests on every push

As mentioned in the Perl Weekly as well, I think it can be really valuable to enable Continuous Integration (CI) and improve testing on all the CPAN modules where the author is interested in it. Having CI configured will provide fast feedback to the author(s) and will reduce the chances of releasing a module that only works on the computer of the developer. Reducing the manual work-load for the CPAN Tester. Currently GitHub Actions is the most natural CI system for GitHub-based projects. That's why I am sending this PR.
I've enabled several versions of Perl on 3 different platforms. Except 5.36 on Windows as it does not seem to exist.
I have written several blog posts and recorded videos on the subject. You can find them here: https://perlmaven.com/os
If you need further help with the CI system, check out my posts https://perlmaven.com/ci and feel free to ask me.
If you'd like to support my efforts there are several ways to do so https://szabgab.com/support.html

I merged this but unfortunately I don't know how to fix this upstream issue with MacOS and List::MoreUtils.
==> Found dependencies: List::MoreUtils
--> Working on List::MoreUtils
Fetching http://www.cpan.org/authors/id/R/RE/REHSACK/List-MoreUtils-0.430.tar.gz ... OK
! Timed out (> 60s). Use --verbose to retry.
! No MYMETA file is found after configure. Your toolchain is too old?
! Configure failed for List-MoreUtils-0.430. See /Users/runner/.cpanm/work/1667764896.[20](https://github.com/mrdvt92/perl-List-NSect/actions/runs/3405794887/jobs/5664025988#step:5:21)35/build.log for details.
! Installing the dependencies failed: Module 'List::MoreUtils' is not installed
! Bailing out the installation for List-NSect-0.07.
Configuring List-MoreUtils-0.430 ... FAIL
Error: The operation was canceled.

This did not happen when I ran the CI a few hours ago. It might be a temporary issue somewhere.
Try re-running the same CI (you can do that on the web interface) or let's see the results when you push out some new changes.


Autocrafting of chance-based processing recipes

Some processing recipes have outputs which are not guaranteed.
For example, the Ender IO SAG Mill can grind Sand into Silicon, but with a 50% chance of producing output:

Another example, the SAG Mill can grind Coal into Coal Powder with a 10% chance of producing some extra IC2 Sulfur Dust:

Is there a way to define this in Processing Patterns? In the specific case of Silicon I would like Refined Storage to keep sending Sand to my SAG Mills until enough Silicon is produced to complete the crafting job.
For more expensive recipes I can imagine the player might want to set some sort of limit to make sure they don't burn through all their resources trying to complete a crafting job.

Defining it in a processing pattern is kinda hard. You could do like 3 or 4 sand for 1 silicon. Which will stop inserting sand once it gets the required silicon. But might get stuck at some point. You could hope the rescheduling kicks in but that chance is rather small since it will have started a task and be waiting for it to finish. Or you could setup an exporter with a detector to keep a certain amount of silicon stocked.
Adding something that can handle percentage based stuff would need a lot of work on how processing patterns get written. And how they get processed while autocrafting.

I don't think this is worth it

I would just ignore the extra goodies and only put down the things I know i will get 100% of the time.


fix: fix units for correct WellPlatePlan iteration

I think we needed to fix the unit of few methods of the WellPlatePlan since the well_points_plan and the stage coordinates are expressed in µm and the WellPlate in mm.

good one,  i think i'm gonna play around with using pint here in another PR... should help us avoid this stuff a bit


Any plans to support new OAUTH flow for zoom client?

PRs welcome 😁

https://github.com/gomodules/zoom-lib-golang/commit/92156e0a6cc9f7c6a9ba2378f2fff149c0142558
This change was enough to get everything to work.

Great! Will you please submit a pull request so the rest of the community can benefit from your change?


pressing the Create New World hotkey while typing in chat activates it

idk if it's intentional but it's annoying me and i don't remember it happening in 2.0

This is intentional, however there is an idea to create SeedQueue keybindings that basically wrap the atum one and could provide more functionality. Those could potentially not trigger in textfields

Just came across this issue and it reminded me of something I thought of while working on Jingle (Julti replacement for single instance)
A macro could check state output for inworld without gamescreenopen and press then press the actual reset key (which would be set to some bs like F13)
I will add a "Safe Reset" key to the default Misc script in Jingle
I don't think extra SQ keybindings make too much sense for this, I think a "Safe Reset" key in atum itself would be better suited

I already have a feature branch for this for atum v1, after vdpineapple asked for it in discussioncord


Use a different Message-ID for the smuggled message

to avoid tripping duplicate message-id checks.

Thanks, good catch!