Huygensmtf

Proposed change

Type of change

[ ] Example (a notebook demonstrating how to use ZOSPy for a specific application)
[ ] Bugfix (non-breaking change which fixes an issue)
[x] New analysis (a wrapper around an OpticStudio analysis)
[ ] New feature (other than an analysis)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests
[ ] Documentation (improvement of either the docstrings or the documentation website)

Additional information

Python version: 3.11.5
OpticStudio version: 23.2.2

Related issues

Checklist

[x] I have followed the contribution guidelines
[x] The code has been linted, formatted and tested locally using tox.
[x] Local tests pass. Please fix any problems before opening a PR. If this is not possible, specify what doesn't work and why you can't fix it.
[x] I added new tests for any features contributed, or updated existing tests.
[x] I updated CHANGELOG.md with my changes (except for refactorings and changes in the documentation).

If you contributed an analysis:

[x] I did not use AttrDicts for the analysis result data (please use dataclasses instead).

If you contributed an example:

[ ] I contributed my example as a Jupyter notebook.

Hi @noahrbn,
Thank you for contributing to ZOSPy! As it's quite busy on our side, it may take some time before we can review your contribution. Meanwhile, can you lint, format and test your code as indicated in the contribution guidelines? The output of the pull request checks suggests there are some issues related to our coding conventions that can be easily resolved by following the workflow explained in the contribution guidelines. If you are new to this and don't know how to get started, feel free to drop us a message and we're happy to help you!

The lint checks on my end are now passing - I will write unit tests (still familiarizing myself with your unit testing conventions) in another pull request. Please feel free to say anything obvious - I am somewhat unfamiliar with this.
I see when I run tox black lint automatically reformats the code to pass, but ruff lint does not. Is there a flag to pass to tox to automatically reformat to fix any errors?

Nice to hear you got tox running! Black does indeed automatically reformat the code. For ruff, you can pass the --fix argument through tox (note the extra double dashes -- that separate the arguments for ruff from the arguments for tox):
tox run -e lint -- --fix

Note that not all errors can be fixed automatically (errors that can, are marked with [*]). Looking at the output from the GitHub Actions, most of them should already be solved by running black.
As for the unit tests, we'll wait for your 2nd PR. As the huygens_mtf analysis is largely similar to fft_through_focus_mtf, the unit tests will probably similar as well. Please also take a look at the documentation for generating reference data, as you need some data to test against ;).

I decided to include the unit testing as a part of this PR. I have committed it now and the new tests under test_mtf.py seem to pass on my machine. Let me know if anything else is needed to approve the PR.
I have a few questions:

Could you clarify exactly how this unit testing is set up? I don't understand it from your README documents. Basically, what I understand is that the tests.yaml file specifies all the tests that are to be performed, and the generate_test_data_reference script goes through this file and creats .zmx files specific to each test (for most of them it seems to be simple_system, i.e., just a singlet lens). The analysis is run on this file. Then, when pytest is run, we see if the analysis performed with zospy matches the results from the file. Maybe I'm missing something, but isn't this a bit circular? What exactly is being tested here?
How does the communication between pytest/each test_*.py file and the files in tests/data/reference work? For example, in each test_*_returns_correct_results method, it is unclear to me how expected_data is passed in.
Why is it necessary to have both a test_*_returns_correct_results and test_*_matches_reference_data method? If I look at how fft_through_focus_mtf was implemented in tests.yaml, it seems that only the correct_results method is tested against reference data.

Thanks a lot for contributing the unit tests as well, nice work!
Anwers to your questions:

The generate_reference_data script is separated from the unit tests. It is only used to generate the data files that are used by the unit tests to check the output of the analyses. tests.yaml is only used by the generate_reference_data script. It specifies for each analysis on which optical system it should be run, and which arguments should be supplied to the analysis (often there are multiple sets of parameters for a single analysis). For each specified analysis and parameter set, generate_reference_data builds the system in OpticStudio, performs the analysis and saves the analysis output using zospy.analyses.base.AnalysisResult.to_json(). It also saves the system in .zmx format. Only the json files are used; the .zmx files are only saved for reference purposes.
Isn't this a bit circular? Yes, it is: we use ZOSPy to generate the reference analysis output, and then test ZOSPy against this output. This is not really a "unit test", unlike for example test_to_json, which clearly tests a single piece of functionality (the ability to reconstruct an AnalysisResult from its own json serialization). Isn't that useless? No, it isn't: these tests should be seen as regression tests. Although we would like to, we cannot really test the validity of OpticStudio's output, but at least we can check if it stays the same. If we change some functionality used by one or more analyses, these tests help us to make sure the change didn't break the analyses or change their output.

To pass the expected data to the unit tests, we make use of PyTest's fixtures. These fixtures are functions that can perform some setup steps and then return a value; this helps to keep the unit tests modular. As you can see, tests/analyses/testconf.py defines a fixture named expected_data. When PyTest encounters the expected_data parameter in the test definition, it will call the expected_data fixture and pass its returned value as an argument to the unit test. If you check this fixture, you will see that it determines the name of the appropriate reference data file based on the test name and its parameters. If this file is not present, the test will be skipped.
Note that this also means you need  to run the generate_reference_data script when you add new tests; otherwise these tests will still be skipped, because the necessary reference data is missing.

We do not only want to ensure consistent results for a single version of OpticStudio, but also check if results are consistent between different versions. To do this, we defined a reference version (currently OpticStudio 23 R1). If you run the unit tests with a different OpticStudio version (say, 23 R2), test_*_returns_correct_results will check the analysis output against the reference data for that version (OpticStudio 23 R2). test_*_matches_reference_data will check the analysis output against the reference data for the reference version (OpticStudio 23 R1). For this check, the reference data files for OpticStudio 23 R1 are used, so it is not necessary to separately specify these test cases for the test_*_matches_reference_data tests (you can check this if you take a look at the reference_data fixture).

I hope this answers your questions, and let me know if something is still unclear!

Thanks for the clarification - that makes a lot of sense.
Please let me know if any more information is needed to approve the PR.

I see that test_huygens_mtf_returns_correct_result uses assert np.allclose to compare the result and the expected data. We have just released version 1.1.2 and one of the updates is that we changed to pandas.testing.assert_frame_equal for these comparisons as that also checks the columns and indices of the DataFrames (see #56). I think that should also be the way forward in this merge request.

@LucVV I have accepted and committed your suggestions. I will test this branch locally myself to make sure the tests still pass, but other than that I think this is good to go.

I have addressed the above comments with the most recent commits. I have linted the code and all unit tests (including new ones) pass on my machine.

Great to hear! And congratulations indeed @noahrbn!
I'll run the test and add reference data for OpticStudio 20.3.2 today!

The new tests run on my system and the test results of OpticStudio 20.3.2 match those of 23.2.1! I have added the reference data for 20.3.2
I noticed that only test_huygens_mtf_returns_correct_result was implemented. I have also implemented test_huygens_mtf_matches_reference_data to compare different OpticStudio versions. @crnh, can you add the reference files for 23.1.0 (the current reference version)?

Yes, I'll add the reference data today!


configuration method?

hi! i don't understand how to configure the task list, i've added the streamlabs cloudbot to my twitch account, added the extension token (without the "oauth:") and created the "!taskadd" and added the response too, though nothing happens when i use the command, can you help me understand how to configure the bot and how to make the task list work? thanks

@y0ur5h4d0w For sure, i can post a video about it later today, will be unlisted as I didn't "professionally" record it

@y0ur5h4d0w For sure, i can post a video about it later today, will be unlisted as I didn't "professionally" record it

where can i find the video?

Thank you for the kind reminder, here is the video

Thank you for the kind reminder, here is the video

thanks soooooo much! :)

@mohamed-tayeh can i prohibit normal users to use the task list commands and keep only admins able to invoke them? is it sufficient to "ban" the commands using stramlabs/nightbot?

@y0ur5h4d0w Atm there is no configuration to do so, but I can add that fairly easily. I made a new issue to track that feature #20


DNS support for containers on Host network

Today we don't register containers on Host network to Rancher DNS, so DNS resolution won't work for services having networking=host.
Now about possible way to implement it. The idea of host networking is that we don't do anything with networking. So we would not be assigning a 10.42 IP to the host. We could resolve that DNS entry to the IP of server, but that will be the CATTLE_AGENT_IP. From the Rancher perspective we just have that one IP, if your server has different IPs or an externally bound IP (like Amazon EIP), we wouldn't know about it. So the IP we would resolve to might be a little limited in flexibility.
So we'll have to think whether to 1) Simply default container IP to the ip address of the rancher agent. 2_ introduce one extra parameter to addHost API allowing to specify public host ip address, and use this address for DNS resolution
@will-chan

A service with host level network will get registered to rancher dns only when label "io.rancher.network.dns"=true is set for it.

@alena1108 Sounds good, I'll make sure to try this in the next release.

@Kelindar corresponding PR is still in review - https://github.com/rancher/cattle/pull/727, but we do aim to include it to the next release

@alena1108 Cool, no rush.
Just leaving a suggestion here, instead of a simple flag for the label, would it be possible to specify the interface? Something like io.rancher.container.dns="docker0", io.rancher.container.dns="eth0" or even a url, for example io.rancher.container.dns="http://ipv4.icanhazip.com" would simply issue an HTTP GET on the specified url and get the external IP address that way (or any address) and publish this to the DNS. What do you think?

@Kelindar unfortunately its not how its implemented in the first run. The ip address of the instance would always be the host ip specified in "CATTLE_AGENT_IP" during the host registration (as per comments in http://forums.rancher.com/t/service-discovery-of-containers-with-host-networking/155). And today label "io.rancher.container.dns" more stands for "user internal rancher dns", not the ip address that you would want your container to be registered as.
We will def enhance this functionality in the future releases as specifying exact ip is a very valid use case when your host has multiple interfaces + EIP. I'll file a ticket to keep track of it as soon as the initial version gets in.

@sangeethah the fix is in master

Tested with build from master - Aug 13.
DNS support for containers on Host network works when service is deployed with label "io.rancher.container.dns"=true.
There are few issues found when testing different use cases which are tracked as separate issues - #1792 , #1793 and #1794.


Overlay network container to external documentation

The current documentation indicates that:

Not directly supported - requires second container endpoint attached to NAT network on Windows Server 2016 or VFP NAT rule on Windows Server 2019.

But it does not give any instructions about how to configure it. If using Windows Server 2019 is only required a VFP NAT rule?
How can we configure that NAT rule?

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

ID: 556473c3-3630-dc56-caad-a3d72d34e9e1
Version Independent ID: 560ad6ca-e017-db71-4605-a73e9f1b8aed
Content: Windows container network drivers
Content Source: virtualization/windowscontainers/container-networking/network-drivers-topologies.md
Product: windows-server
Technology: windows-containers
GitHub Login: @daschott
Microsoft Alias: daschott

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


Harden check for mixpanel load.

Tested locally with host file blocking of mixpanel.

@ahmelsayed @alrod  Okay to checkin ?

This bug  also affects the main portal , if mixpanel is blocked.


Wordpress integration?

Hello,
I just stumbled upon this amazing tool after searching and learning hours about Cloudinary and IMGIX.
I'm looking for a solution to manipulate images in Wordpress (specific WooCommerce products).
Does Glide have some sort of plugin to use for Wordpress, or can somebody help me how to use this in combination with Wordpress.
Basically want I want to achieve/setup:

upload images to Wordpress
when assign featured image to a product, for that product only, the image needs to be rescaled (FIT) *** without cropping *** to a square size (new canvas) and space around filled with a bg color and saved with the new format.
all assets are offloaded from local server to Amazon S3, so normally this function will re-upload the image to Amazon S3 bucket
all assets are hosted by CDN from the Amazon S3 for fast asset delivery.

Why we want this:
Because often, the image files we receive have a wide variety of dimensions (portrait, landscape, ...) and it looks horrible on the product overview pages. Wordpress has no function to make square images WITHOUT cropping.
So we need an external solution that handles this.
We have tried Cloudinary and IMGIX, all work fine, but they all require to use their CDN which we don't need.
I hope with Glide we can do this?
If you can help me with this, please let me know!
Thanks!

You don't need to use Imgix's CDN.  You can use Cloudflare or any other CDN that can do an origin pull, you then just put that in front of Imgix.
I'm the author of Media Cloud (Imgix plugin for WordPress), but am looking to add glide support in.

Sorry, we don't have any built-in support for WordPress. It's a neat idea though!


Arrows for Ascending/Descending sort are opposite

Using this example:
Clicking at the sort button once triggers an Ascending sort, but the icon points downwards indicating a descending sort
Clicking again switched to descending sort, but now the arrow points up again :)
I have not seen any other software that behaves like this, and for example in Microsoft Excel, an arrow up is used for Ascending sort.

Thanks, I fixed the CSS at source level.
It looks like I cannot deploy the project and update the site at the moment, though, as dependencies are so outdated.


Use memoized parser_enumerator directly instead of assigning to variable

Use memoized parser_enumerator directly instead of assigning to variable

Why?

parser_enumerator is already memoized, so I feel no need to assign parser_enumerator to any variable to use.

I want to avoid method calls as much as possible here.

sure @kou :+1:
I'll close this PR.


NorESM2 model output: Dimensions mismatch between areacello and sea ice fields

Describe the bug
There is a mismatch between between dimensions for the ocean and sea ice components in NorESM2-LM and NorESM2-MM. Ocean fields are defined on a 360x385 grid, whereas sea ice use a 360x384 grid. The background for this difference is explained in the NorESM2 documentation: https://noresm-docs.readthedocs.io/en/noresm2/faq/postp_plotting_faq.html#different-sea-ice-and-ocean-grid
As a result, the areacello variable is not consistent with any of the sea ice fields. To make it consistent, it is necessary to remove the final j-row of areacello.  When loading area data with xarray, I get a consistent area definition by doing the following:
# Ocean Area
Aocn = xarray.open_dataset('<path-to-areacello>')
# Sea ice Area: select coordinate values j = 1..384
Aice = Aocn.sel(j=range(1,385))

Would it be possible to implement a fix in ESMValTool to correct Ofx  datasets when used in combination with sea ice output for NorESM2? Or could there be better ways to handle this issue?

cheers for pointing this out @TomasTorsvik :beer: We should get one such fix in esmvalcore's fixes - can you help by creating one perhaps? Or perhaps a more general approach to de-haloing (this is, in fact, a halo removal type of issue), what say you @ESMValGroup/technical-lead-development-team

@valeriupredoi - Thanks for responding. I'm happy to help in any way I can, but I'm not sure how to implement such a fix. I suppose the fixes should go in the files ESMValCore/esmvalcore/cmor/_fixes/cmip6/noresm2_lm.py and ESMValCore/esmvalcore/cmor/_fixes/cmip6/noresm2_mm.py? As I see it, Ofx datasets should be adjusted to remove the halo, but only when used in combination with SIday or SImon datasets. I see the siage dataset (to take an example file) contains global attributes
    :external_variables = "areacello" ;
    :realm = "seaIce" ;

So I'm thinking the fix could be made conditional on these attributes in some way, either by replacing the external_variables with one where the halo has been removed. Would it be possible to define a new areacello file where the halo has been removed, to be used only for the seaIce realm, or apply a fix on the areacello dataset before it is applied to the seaIce field?

@TomasTorsvik Do you have any connection with the NorESM2 developers? The simplest solution would be if they just uploaded the sea ice areacello file to ESGF as well, e.g. under the SImon table id instead of Ofx. Would that be an option?

@bouweandela - Thanks for your suggestion. I'm involved in NorESM2 development, although not directly with production of CMIP6 data. I will make a request to upload the sea ice areacello file to ESGF.

@bouweandela , @valeriupredoi  - I contacted the people working with CMIP6 for NorESM2, but the response was not very positive regarding the suggestion to include areacello for sea ice under SImon. There is concern that having two different areacello files for the same experiment may cause conflicts and confusion for data users. So it seems that having a second areacello file is not an option.

There is concern that having two different areacello files for the same experiment may cause conflicts and confusion for data users.

Great to hear that they are so considerate about not confusing the users of their data.

I suppose the fixes should go in the files ESMValCore/esmvalcore/cmor/_fixes/cmip6/noresm2_lm.py and ESMValCore/esmvalcore/cmor/_fixes/cmip6/noresm2_mm.py?

yes

As I see it, Ofx datasets should be adjusted to remove the halo, but only when used in combination with SIday or SImon datasets.

Unfortunately, such a conditional removal is not possible in the current framework. Would it be an option to remove the halo for all variables that have it? Or would that cause other problems?

Would it be possible to define a new areacello file where the halo has been removed, to be used only for the seaIce realm, or apply a fix on the areacello dataset before it is applied to the seaIce field?

Yes, but only if such a new file would be uploaded to ESGF.

As I see it, Ofx datasets should be adjusted to remove the halo, but only when used in combination with SIday or SImon datasets.

Unfortunately, such a conditional removal is not possible in the current framework. Would it be an option to remove the halo for all variables that have it? Or would that cause other problems?

All 2D/3D output from the ocean model component includes the halo. It might be possible technically to remove the halo from all ocean variables, but it seems like a massive undertaking to do this for all CMIP6 experiments and upload new files to ESGF (especially since the current files are working just fine for the ocean part).

I meant: write a fix in ESMValCore that removes the halo (unconditionally). That should be fairly straightforward.

@valeriupredoi , @bouweandela - maybe you can say if I'm on the right track on this?
I have done some testing for removing the "halo" column from ocean fields. At the moment I'm using the following function, which works with the 2D/3D/4D variables that I have looked at (specifically areacello, tos, thetao).
def remove_halo(cube):
    num_dim_coords = len(cube.dim_coords)
    # if present, "cell index along second dimension" should be second to last dimension
    if cube.dim_coords[num_dim_coords-2].long_name == 'cell index along second dimension':
        print("found second dimension")
        if cube.dim_coords[num_dim_coords-2].shape[0] == 385:
            print("removing halo cells")
            if num_dim_coords==2:
                cube_no_halo = cube[0:-1, :]
                cube = cube_no_halo
            if num_dim_coords==3:
                cube_no_halo = cube[:, 0:-1, :]
                cube = cube_no_halo
            if num_dim_coords==4:
                cube_no_halo = cube[:, :, 0:-1, :]
                cube = cube_no_halo
    return cube

This solution makes the assumptions that the halo-column is always second to last, has the shape (385, ), and is only 2D/3D/4D dimensions. Would be nice to make something more general, but I haven't figured out how to do this.

You could probably do something like the following to make it a bit more widely applicable:
if cube.coords('latitude'):
    lat = cube.coord('latitude')
    if lat.shape == (385, 360):
        halo_dim = cube.coord_dims(lat)[0]
        slices = tuple(slice(0, -1) if i == halo_dim else slice(None) for i in range(cube.ndim))
        cube = cube[slices]


wasCalled() not give the correct number

My production code goes as - sut invokes dataService.importPortals() inside.
The test fails with Expected: 1, Actual: 0
However, System.debug tells the mocked Integer (100) is corrected returned by the importPortals method.
What do I miss?
         I am not seeing it here

@xixiaofinland I ran some more tests and looks like this is a bug with the library. Since the dependency that is used within an async job is a copy of the original dependency, the call counts are not updated in the state of the original universalmocker instance. I usually test my async code by calling the execute method directly and completely overlooked this. I will convert this to a bug and release a fix soon. Thanks for raising the issue.

@xixiaofinland if you want to take a look at #17 it addresses the issue with async contexts

#17

Thanks for the tip, all clear now


Add Tests for examples

Would be very helpful to provide tests for examples
Relay and GraphQL tests
:smile:

Thanks for the suggestion, @sibelius. What kind of tests do you have in mind?
There is some element of manual testing that needs to happen whenever the dependencies in the examples get updated; we try to keep them pretty tightly locked towards known-working versions, and then update them manually once we've verified that they work. (We slipped up a bit last time we updated, eg  0301254, where we made the dependencies a bit looser.)
Relay itself gets pretty heavily tested in Travis.
If you have anything specific in mind, any interest in submitting a PR? In the meantime, I'll add the "help wanted" label to indicated that we need somebody to define the requirements here.

Closing due to inactivity.


FEATURES - Initial Window Size

Two features on the "Lock Initial Window Pos/Size" would be important:

an option, to lock just the current Pos/Size of the window

value hints: which value is...

top left window corner X position
top left window corner Y position
window width
window height

fixed with 1.3.3


GET /formList from Docker image fails with error from openros

I've built a local Docker image from current master and the latest tag (v0.11.0) with docker build -t omk ., and then run it with:
mkdir -p /tmp/data/submissions /tmp/data/forms /tmp/data/deployments
docker run --rm -p 8080:3210 -v /tmp/data:/app/data --name omk omk

but although I'm able to upload the OMK sample XLS form (https://docs.google.com/spreadsheets/d/11H4-mGYTS61GLjSbVoTbmhoI5DjlF5fcBwNwQcvd2Go/edit?usp=sharing) or start from a fresh data dir mirroring that of data/ from the repo, in all cases I'm getting a 500 for HTTP GET /formList?json=true with the following traceback:
Error: not well-formed (invalid token)
    at /app/api/odk/controllers/get-formlist.js:38:23
    at buildXml (/app/node_modules/openrosa-formlist/index.js:77:21)
    at /app/node_modules/openrosa-formlist/node_modules/async/lib/async.js:251:17
    at done (/app/node_modules/openrosa-formlist/node_modules/async/lib/async.js:126:15)
    at /app/node_modules/openrosa-formlist/node_modules/async/lib/async.js:32:16
    at Parser.<anonymous> (/app/node_modules/openrosa-formlist/node_modules/async/lib/async.js:248:21)
    at emitOne (events.js:101:20)
    at Parser.emit (events.js:188:7)
    at Parser.write (/app/node_modules/node-expat/lib/node-expat.js:68:10)
    at Stream.ondata (internal/streams/legacy.js:16:26)

Is this a version mismatch perhaps with openrosa?
Or, more generally, might you all have any advice on how to proceed? (And sorry to post on issues; couldn't find a mailing list / slack channel / IRC)

Can you paste the output of this (when using the default port):
curl -H "Accept: application/json" http://localhost:3210/omk/data/forms/

(These are the requests made internally to produce the form list.)
It should look like
["buildings_example.xlsx","buildings_example.xml"]

Ditto for
curl http://localhost:3210/omk/data/forms/buildings_example.xml

and
curl http://localhost:3210/omk/odk/manifest/buildings_example.xml

For this reply, the command, run on host leaf, was:
docker run -p 3210:3210 --rm -v /tmp/data:/app/data --name omk omk

GET /omk/data/forms works locally:
omkserver@cadd07fc7452:/app$ curl -H "Accept: application/json" http://localhost:3210/omk/data/forms/
["buildings_example.xlsx","buildings_example.xml"]
omkserver@cadd07fc7452:/app$ exit
$ curl -H "Accept: application/json" http://localhost:3210/omk/data/forms/
["buildings_example.xlsx","buildings_example.xml"]

And remotely, too:
$ curl -H "Accept: application/json" http://leaf:3210/omk/data/forms/
["buildings_example.xlsx","buildings_example.xml"]

So does GET /omk/data/forms/:form_name:
$ curl http://localhost:3210/omk/data/forms/buildings_example.xml -s | head
<?xml version="1.0"?>
<h:html xmlns="http://www.w3.org/2002/xforms" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:jr="http://openrosa.org/javarosa" xmlns:orx="http://openrosa.org/xforms" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <h:head>
    <h:title>buildings_example</h:title>
    <model>
      <instance>
        <buildings_example id="buildings_example">
          <start/>
          <end/>
          <today/>

and GET /omk/odk/manifest/:form_name:
$ curl http://localhost:3210/omk/odk/manifest/buildings_example.xml  -s | head
<?xml version="1.0" encoding="UTF-8"?>
<manifest xmlns="http://openrosa.org/xforms/xformsManifest">
  <#list/>

and indeed, locally, the formlist works!:
curl 'http://localhost:3210/formList?json=true'
{"xforms":{"attributes":{"xmlns":"http://openrosa.org/xforms/xformsList"},"xform":[{"name":"buildings_example","formID":"buildings_example","hash":"md5:53083d7a1356f9903e560006c526c7a2","downloadUrl":"http://localhost:3210/omk/data/forms/buildings_example.xml","totalSubmissions":0}]}}

but, still locally, not with the machine's hostname:
$ curl 'http://leaf:3210/formList?json=true'
{"status":500,"msg":"not well-formed (invalid token)","err":{}}

I did verify that the endpoint is accessible by hostname within the
container:
$ docker exec omk
omkserver@cadd07fc7452:/app$ curl 'http://leaf:3210/formList?json=true'
{"status":500,"msg":"not well-formed (invalid token)","err":{}}

Then, I thought, maybe this has something to do with the HTTP host
header? So I ran:
$ curl -H "Host: localhost" 'http://leaf:3210/formList?json=true'
{"status":500,"msg":"connect ECONNREFUSED <IP_ADDRESS>:80","err":{"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect","address":"<IP_ADDRESS>","port":80}}

and finally got the error you were talking about. But, this doesn't seem
like the issue, since with `Host: localhost:3210" we're back to a
working response:
$ curl -H "Host: localhost:3210" 'http://leaf:3210/formList?json=true'
{"xforms":{"attributes":{"xmlns":"http://openrosa.org/xforms/xformsList"},"xform":[{"name":"buildings_example","formID":"buildings_example","hash":"md5:53083d7a1356f9903e560006c526c7a2","downloadUrl":"http://localhost:3210/omk/data/forms/buildings_example.xml","totalSubmissions":0}]}}

So, this seems to have something to do not with connectivity back to the
server in the container, but with the hostname being different than
expected after the connection's been made. Just my guess, though.


Readd channel Support?

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like this: [x])
Use the Preview tab to see what your issue will actually look like

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2<IP_ADDRESS>. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

[x ] I've verified and I assure that I'm running youtube-dl 2<IP_ADDRESS>

Before submitting an issue make sure you have:

[x ] At least skimmed through the README, most notably the FAQ and BUGS sections
[ x] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[x ] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

Output:
youtube-dl https://vimeo.com/user45333714 --download-archive ~/.ytdlarchive --retries 100 --no-overwrites --call-home --continue --write-info-json --write-description --write-thumbnail --write-annotations  -v
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['https://vimeo.com/user45333714', '--download-archive', '/home/gazlene/.ytdlarchive', '--retries', '100', '--no-overwrites', '--call-home', '--continue', '--write-info-json', '--write-description', '--write-thumbnail', '--write-annotations', '-v']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2<IP_ADDRESS>
[debug] Python version 3.4.5 - Linux-3.10.0-514.26.1.el7.x86_64-x86_64-with-centos-7.3.1611-Core
[debug] exe versions: ffmpeg 2.6.8, ffprobe 2.6.8
[debug] Proxy map: {}
[debug] Public IP address: 2a02:c207:2012:4253::1
[vimeo:user] user45333714: Downloading page 1
[download] Downloading playlist: Adrienne Southey
[vimeo:user] user45333714: Downloading page 2
[vimeo:user] playlist Adrienne Southey: Downloading 15 videos
[download] Downloading video 1 of 15
[vimeo] 227557944: Downloading webpage
[vimeo] 227557944: Extracting information
[vimeo] 227557944: Downloading webpage
[vimeo] 227557944: Downloading JSON metadata
[vimeo] 227557944: Checking Original video URL
[vimeo] 227557944: Downloading fastly_skyfire m3u8 information
[vimeo] 227557944: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 227557944: Downloading fastly_skyfire MPD information
[vimeo] 227557944: Downloading fastly_skyfire MPD information
[vimeo] 227557944: Downloading akfire_interconnect_quic MPD information
[vimeo] 227557944: Downloading akfire_interconnect_quic MPD information
[debug] Default format spec: bestvideo+bestaudio/best
[info] Writing video description to: Karoo winter reflecting-227557944.description
[info] Writing video annotations to: Karoo winter reflecting-227557944.annotations.xml
WARNING: There are no annotations to write.
[info] Writing video description metadata as JSON to: Karoo winter reflecting-227557944.info.json
[vimeo] 227557944: Downloading thumbnail ...
[vimeo] 227557944: Writing thumbnail to: Karoo winter reflecting-227557944.jpg
[debug] Invoking downloader on 'https://skyfire.vimeocdn.com/1501966059-0x5c5eb7e005aaa03d08c33f9b7da00bf1b0a19300/227557944/sep/video/800603750,800603757,800603755,800603749/../'
[dashsegments] Total fragments: 13
[download] Destination: Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-video-800603757.mp4
[download] 100% of 25.09MiB in 00:08
[debug] Invoking downloader on 'https://skyfire.vimeocdn.com/1501966059-0x5c5eb7e005aaa03d08c33f9b7da00bf1b0a19300/227557944/sep/video/800603750,800603757,800603755,800603749/../'
[dashsegments] Total fragments: 13
[download] Destination: Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-audio-800603757.m4a
[download] 100% of 2.17MiB in 00:02
[ffmpeg] Merging formats into "Karoo winter reflecting-227557944.mp4"
[debug] ffmpeg command line: ffmpeg -y -i 'file:Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-video-800603757.mp4' -i 'file:Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-audio-800603757.m4a' -c copy -map 0:v:0 -map 1:a:0 'file:Karoo winter reflecting-227557944.temp.mp4'
Deleting original file Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-video-800603757.mp4 (pass -k to keep)
Deleting original file Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-audio-800603757.m4a (pass -k to keep)

Description:
Hi, youtube-dl seems to no longer support channels now. Does anyone know why? I get this issue with YouTube and vimeo

There is no issue in your log.

@dstftw Theres a problem with vimeos site support where it's hanging or can't process vimeo channels. It's not just him having this problem. When I spit out the IDs and pricess them to add the rest of the URL the channels rip fine.

I've no such problems. If you claim there is an error you must provide a verbose log that clearly demonstrates the problem with latest youtube-dl and ffmpeg.
PS C:\Dev\youtube-dl\master> py -3.6 .\youtube_dl\__main__.py https://vimeo.com/user45333714
[vimeo:user] user45333714: Downloading page 1
[download] Downloading playlist: Adrienne Southey
[vimeo:user] user45333714: Downloading page 2
[vimeo:user] playlist Adrienne Southey: Downloading 15 videos
[download] Downloading video 1 of 15
[vimeo] 227557944: Downloading webpage
[vimeo] 227557944: Extracting information
[vimeo] 227557944: Downloading webpage
[vimeo] 227557944: Downloading JSON metadata
[vimeo] 227557944: Checking Original video URL
[vimeo] 227557944: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 227557944: Downloading fastly_skyfire m3u8 information
[vimeo] 227557944: Downloading akfire_interconnect_quic MPD information
[vimeo] 227557944: Downloading akfire_interconnect_quic MPD information
[vimeo] 227557944: Downloading fastly_skyfire MPD information
[vimeo] 227557944: Downloading fastly_skyfire MPD information
[dashsegments] Total fragments: 13
[download] Destination: Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-video-800603757.mp4
[download] 100% of 25.09MiB in 00:15
[dashsegments] Total fragments: 13
[download] Destination: Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-audio-800603757.m4a
[download] 100% of 2.17MiB in 00:09
[ffmpeg] Merging formats into "Karoo winter reflecting-227557944.mp4"
Deleting original file Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-video-800603757.mp4 (pass -k to keep)
Deleting original file Karoo winter reflecting-227557944.fdash-fastly_skyfire_sep-audio-800603757.m4a (pass -k to keep)
[download] Downloading video 2 of 15
[vimeo] 226441583: Downloading webpage
[vimeo] 226441583: Extracting information
[vimeo] 226441583: Downloading webpage
[vimeo] 226441583: Downloading JSON metadata
[vimeo] 226441583: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 226441583: Downloading fastly_skyfire m3u8 information
[vimeo] 226441583: Downloading akfire_interconnect_quic MPD information
[vimeo] 226441583: Downloading akfire_interconnect_quic MPD information
[vimeo] 226441583: Downloading fastly_skyfire MPD information
[vimeo] 226441583: Downloading fastly_skyfire MPD information
[dashsegments] Total fragments: 10
[download] Destination: Fly Karoo Graaff Reinet-226441583.fdash-fastly_skyfire_sep-video-795719987.mp4
[download] 100% of 19.94MiB in 00:14
[dashsegments] Total fragments: 10
[download] Destination: Fly Karoo Graaff Reinet-226441583.fdash-fastly_skyfire_sep-audio-795719989.m4a
[download] 100% of 1.66MiB in 00:09
[ffmpeg] Merging formats into "Fly Karoo Graaff Reinet-226441583.mp4"
Deleting original file Fly Karoo Graaff Reinet-226441583.fdash-fastly_skyfire_sep-video-795719987.mp4 (pass -k to keep)
Deleting original file Fly Karoo Graaff Reinet-226441583.fdash-fastly_skyfire_sep-audio-795719989.m4a (pass -k to keep)
[download] Downloading video 3 of 15
[vimeo] 224631859: Downloading webpage
[vimeo] 224631859: Extracting information
[vimeo] 224631859: Downloading webpage
[vimeo] 224631859: Downloading JSON metadata
[vimeo] 224631859: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 224631859: Downloading fastly_skyfire m3u8 information
[vimeo] 224631859: Downloading akfire_interconnect_quic MPD information
[vimeo] 224631859: Downloading akfire_interconnect_quic MPD information
[vimeo] 224631859: Downloading fastly_skyfire MPD information
[vimeo] 224631859: Downloading fastly_skyfire MPD information
[dashsegments] Total fragments: 17
[download] Destination: Fly Karoo Air Services Graaff - Reinet-224631859.fdash-fastly_skyfire_sep-video-790806010.mp4
[download] 100% of 40.89MiB in 00:24
[dashsegments] Total fragments: 17
[download] Destination: Fly Karoo Air Services Graaff - Reinet-224631859.fdash-fastly_skyfire_sep-audio-790806010.m4a
[download] 100% of 2.93MiB in 00:13
[ffmpeg] Merging formats into "Fly Karoo Air Services Graaff - Reinet-224631859.mp4"
Deleting original file Fly Karoo Air Services Graaff - Reinet-224631859.fdash-fastly_skyfire_sep-video-790806010.mp4 (pass -k to keep)
Deleting original file Fly Karoo Air Services Graaff - Reinet-224631859.fdash-fastly_skyfire_sep-audio-790806010.m4a (pass -k to keep)
[download] Downloading video 4 of 15
[vimeo] 223992740: Downloading webpage
[vimeo] 223992740: Extracting information
[vimeo] 223992740: Downloading webpage
[vimeo] 223992740: Downloading JSON metadata
[vimeo] 223992740: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 223992740: Downloading fastly_skyfire m3u8 information
[vimeo] 223992740: Downloading akfire_interconnect_quic MPD information
[vimeo] 223992740: Downloading akfire_interconnect_quic MPD information
[vimeo] 223992740: Downloading fastly_skyfire MPD information
[vimeo] 223992740: Downloading fastly_skyfire MPD information
[dashsegments] Total fragments: 31
[download] Destination: Karoo Food Festival-223992740.fdash-fastly_skyfire_sep-video-784427056.mp4
[download] 100% of 91.06MiB in 00:43
[dashsegments] Total fragments: 31
[download] Destination: Karoo Food Festival-223992740.fdash-fastly_skyfire_sep-audio-784427058.m4a
[download] 100% of 5.51MiB in 00:28
[ffmpeg] Merging formats into "Karoo Food Festival-223992740.mp4"
Deleting original file Karoo Food Festival-223992740.fdash-fastly_skyfire_sep-video-784427056.mp4 (pass -k to keep)
Deleting original file Karoo Food Festival-223992740.fdash-fastly_skyfire_sep-audio-784427058.m4a (pass -k to keep)
[download] Downloading video 5 of 15
[vimeo] 220255863: Downloading webpage
[vimeo] 220255863: Extracting information
[vimeo] 220255863: Downloading webpage
[vimeo] 220255863: Downloading JSON metadata
[vimeo] 220255863: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 220255863: Downloading fastly_skyfire m3u8 information
[vimeo] 220255863: Downloading akfire_interconnect_quic MPD information
[vimeo] 220255863: Downloading akfire_interconnect_quic MPD information
[vimeo] 220255863: Downloading fastly_skyfire MPD information
[vimeo] 220255863: Downloading fastly_skyfire MPD information
[dashsegments] Total fragments: 69
[download] Destination: Fly Karoo-220255863.fdash-fastly_skyfire_sep-video-790879098.mp4
[download] 100% of 211.24MiB in 01:47
[dashsegments] Total fragments: 69
[download] Destination: Fly Karoo-220255863.fdash-fastly_skyfire_sep-audio-790879101.m4a
[download] 100% of 12.53MiB in 01:04
[ffmpeg] Merging formats into "Fly Karoo-220255863.mp4"
Deleting original file Fly Karoo-220255863.fdash-fastly_skyfire_sep-video-790879098.mp4 (pass -k to keep)
Deleting original file Fly Karoo-220255863.fdash-fastly_skyfire_sep-audio-790879101.m4a (pass -k to keep)
[download] Downloading video 6 of 15
[vimeo] 218775593: Downloading webpage
[vimeo] 218775593: Extracting information
[vimeo] 218775593: Downloading webpage
[vimeo] 218775593: Downloading JSON metadata
[vimeo] 218775593: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 218775593: Downloading fastly_skyfire m3u8 information
[vimeo] 218775593: Downloading akfire_interconnect_quic MPD information
[vimeo] 218775593: Downloading akfire_interconnect_quic MPD information
[vimeo] 218775593: Downloading fastly_skyfire MPD information
[vimeo] 218775593: Downloading fastly_skyfire MPD information
[dashsegments] Total fragments: 30
[download] Destination: Blaauwater Farms and Guest House-218775593.fdash-fastly_skyfire_sep-video-799147460.mp4
[download] 100% of 105.46MiB in 00:45
[dashsegments] Total fragments: 30
[download] Destination: Blaauwater Farms and Guest House-218775593.fdash-fastly_skyfire_sep-audio-799147461.m4a
[download] 100% of 5.40MiB in 00:26
[ffmpeg] Merging formats into "Blaauwater Farms and Guest House-218775593.mp4"
Deleting original file Blaauwater Farms and Guest House-218775593.fdash-fastly_skyfire_sep-video-799147460.mp4 (pass -k to keep)
Deleting original file Blaauwater Farms and Guest House-218775593.fdash-fastly_skyfire_sep-audio-799147461.m4a (pass -k to keep)
[download] Downloading video 7 of 15
[vimeo] 214231228: Downloading webpage
[vimeo] 214231228: Extracting information
[vimeo] 214231228: Downloading webpage
[vimeo] 214231228: Downloading JSON metadata
[vimeo] 214231228: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 214231228: Downloading fastly_skyfire m3u8 information
[vimeo] 214231228: Downloading akfire_interconnect_quic MPD information
[vimeo] 214231228: Downloading akfire_interconnect_quic MPD information
[vimeo] 214231228: Downloading fastly_skyfire MPD information
[vimeo] 214231228: Downloading fastly_skyfire MPD information
[dashsegments] Total fragments: 28
[download] Destination: Karoo Farm-214231228.fdash-fastly_skyfire_sep-video-737927675.mp4
[download] 100% of 82.13MiB in 00:43
[dashsegments] Total fragments: 28
[download] Destination: Karoo Farm-214231228.fdash-fastly_skyfire_sep-audio-737927676.m4a
[download] 100% of 4.92MiB in 00:27
[ffmpeg] Merging formats into "Karoo Farm-214231228.mp4"
Deleting original file Karoo Farm-214231228.fdash-fastly_skyfire_sep-video-737927675.mp4 (pass -k to keep)
Deleting original file Karoo Farm-214231228.fdash-fastly_skyfire_sep-audio-737927676.m4a (pass -k to keep)
[download] Downloading video 8 of 15
[vimeo] 209879208: Downloading webpage
[vimeo] 209879208: Extracting information
[vimeo] 209879208: Downloading webpage
[vimeo] 209879208: Downloading JSON metadata
[vimeo] 209879208: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 209879208: Downloading fastly_skyfire m3u8 information
[vimeo] 209879208: Downloading akfire_interconnect_quic MPD information
[vimeo] 209879208: Downloading akfire_interconnect_quic MPD information
[vimeo] 209879208: Downloading fastly_skyfire MPD information
[vimeo] 209879208: Downloading fastly_skyfire MPD information
[dashsegments] Total fragments: 14
[download] Destination: Pieter and Jacqueline Baby Shower Invite-209879208.fdash-fastly_skyfire_sep-video-718833565.mp4
[download] 100% of 21.66MiB in 00:24
[dashsegments] Total fragments: 14
[download] Destination: Pieter and Jacqueline Baby Shower Invite-209879208.fdash-fastly_skyfire_sep-audio-718833566.m4a
[download] 100% of 2.40MiB in 00:13
[ffmpeg] Merging formats into "Pieter and Jacqueline Baby Shower Invite-209879208.mp4"
Deleting original file Pieter and Jacqueline Baby Shower Invite-209879208.fdash-fastly_skyfire_sep-video-718833565.mp4 (pass -k to keep)
Deleting original file Pieter and Jacqueline Baby Shower Invite-209879208.fdash-fastly_skyfire_sep-audio-718833566.m4a (pass -k to keep)
[download] Downloading video 9 of 15
[vimeo] 205899376: Downloading webpage
[vimeo] 205899376: Extracting information
[vimeo] 205899376: Downloading webpage
[vimeo] 205899376: Downloading JSON metadata
[vimeo] 205899376: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 205899376: Downloading fastly_skyfire m3u8 information
[vimeo] 205899376: Downloading akfire_interconnect_quic MPD information
[vimeo] 205899376: Downloading akfire_interconnect_quic MPD information
[vimeo] 205899376: Downloading fastly_skyfire MPD information
[vimeo] 205899376: Downloading fastly_skyfire MPD information
[dashsegments] Total fragments: 83
[download] Destination: Stephan en Carmie-205899376.fdash-fastly_skyfire_sep-video-718741282.mp4
[download]  16.9% of ~240.38MiB at  3.24MiB/s ETA 01:50


Typo fix for error message when can't ensure uniqueness of user email addresses

Typo fix for error message when can't ensure uniqueness of user email addresses

[Current coverage][cc-pull] is 75.15% (diff: 100%)

Merging [#2360][cc-pull] into [master][cc-base-branch] will decrease coverage by 16.65%

@@             master      #2360   diff @@
==========================================
  Files            94         94
  Lines         10479      10479
  Methods        1275       1275
  Messages          0          0
  Branches       1713       1713
==========================================
- Hits           9621       7876   -1745
- Misses          858       2603   +1745
  Partials          0          0

Powered by Codecov. Last update [66c4b98...0509468][cc-compare]
[cc-base-branch]: https://codecov.io/gh/ParsePlatform/parse-server/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/ParsePlatform/parse-server/compare/66c4b98b551bc42340582dcd64a2ada2c34983fb...050946881308029537ab9ef98ab7db79fc4f7e7d?src=pr
[cc-pull]: https://codecov.io/gh/ParsePlatform/parse-server/pull/2360?src=pr


modules: SEGGER_RTT: Invalid re-use of RAM memory allocated for SEGGER RTT

Describe the bug
By default the RTT data structures are placed in bss memory region. After an application-triggered reboot, the RAM region used for the RTT data structures may be instantly re-used by the bootloader. The bootloader may use the RAM for completely different purpose, so that reading this region may eventually put the connected RTT host computer into strange state and lead to an unexpected behavior.
On my desk, the host eventually wrote an invalid value to the RdOff (value of 215615629) of terminal’s up buffer after RTT initialization was completed on device’s end. The invalid value caused crash later on when RTT was used by the application (application accessed wrong memory address which triggered fault; the application uses SEGGER RTT for logging).
Expected behavior
There needs to be a way to inform the RTT connected host computer that the RTT data is no longer valid and should not be read (to prevent the RTT host from entering invalid state). Currently there seem to be no SEGGER API that would allow to uninit the RTT terminal so we may need to expand the API.
Alternatively we may provide a separate RAM region which could be used exclusively for the RTT Terminal. The region needs to be known for both application and bootloader (we may place the region at the end of device's RAM to mitigate chance that an incompatible bootloader would accidentally use it for a other purpose).
Impact
Unexpected crash of device working in debug mode. The crash may appear randomly and is hard to investigate.
Additional context
I checked the following with gdb to make sure about the root cause:

If I set breakpoint on main function call, the garbage RdOff is already there (rest of the RTT structure is properly zero-initialized). Setting the RdOff manually to 0 using gdb's set successfully prevents the application's crash.
If I set breakpoint on SEGGER_RTT_Init the spurious set of RdOff seems to happen before the RTT structure initialization. In that case, the SEGGER_RTT_Init properly initializes the structure after the spurious write which prevents the issue from happening.

There is already a PR that fixes this: https://github.com/zephyrproject-rtos/zephyr/pull/53569

Though @MarekPieta if you want this fix in for 3.4, might be worth picking it up and fixing the outstanding issues as the original author has gone silent and there's only a few days to get something merged.

@MarekPieta @nordicjm This issue has been solved by #53569 and can be closed.
It's unfortunate the west.yml was not updated in #53569 to bring in the corresponding Segger repo changes (https://github.com/zephyrproject-rtos/segger/pull/17); it was just missed I believe. I will try to bring in the change in #81425


When atom crashes, ensime keeps running

(this is on linux, if it makes any difference)

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26611303-when-atom-crashes-ensime-keeps-running?utm_campaign=plugin&utm_content=tracker%2F14719420&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F14719420&utm_medium=issues&utm_source=github).

Do you have "Run server detached" enabled?

Nope.
Actually it recovered quite nicely btw: after restarting Atom, 'Start ensime' reconnected to the still-running ensime.

Yeah, that's the idea. It's a lot faster when reloading Atom (which I need to do all the time while developing) and have it just read the port file and connect.
But of course it could be annoying at some point too. I'm going to keep this open and some day I'll sit down and think through how to handle stuff better. That "Run server detached" flag is both used to actually run it as a detached process and also that it isn't terminated when Atom unloads (or ensime package stops). Maybe that can be confusing. Or good. I don't know :)


Fixing behaviour of fallbacks

Revert to use old behaviour for --cminFallbackAlgo.
User can provide Type,Algo,strategy:tolerance or Type,strategy:tolerance. In the latter case, combine will choose the Algo based on the Type chosen by the user.
A check is also made that the type/algo combination makes sense.

:+1: I added one small fix to propagate the "type,algo" string to the MinimizerSentry. Seems to work fine now.


QS Shortcut unresponsive, then opens up about 15 seconds later

The past few days, I've been having an issue with Quicksilver where I push the keyboard shortcut, cmd + space, and nothing happens.
Given about 5-15 seconds, it will eventually open up, and the behavior is very sporadic.
QS v1.3.2 (4014)
Mac OS 10.10.5

This has still be happening, and as I was writing those words, the QS window popped up. I had pushed cmd+space about 90 seconds ago.
So...here's a spindump!!

This looks like the same problem described in #1977, for which there is a fix in the works.
Until then, check your catalog for links or aliases to files on network drives that aren’t available.


(name nil) throws an NPE but LightTable does not print anything

@pawrsccouk I'm not sure if I can reproduce this with your code. When I run your code I see the "Exception on canvas paint." exception logged to the console.
@pawrsccouk @spoon16 I'm going to tentatively consider this to have been resolved. If I'm wrong, add a comment to that effect and I'll re-open this. Build the latest source version of the master branch if you can to test reproducing this.


drivers: add support for virtio

Although the goal of eggos is to run on bare metal, supporting virtio allows us to run eggos on cloud servers.

I just asked some people on Twitter and it looks like they confirmed that virtio won't be helpful for EC2. Newer instances use "Nitro" and older instances used Xen: https://twitter.com/msw/status/1427460582270070786

No but virtio is required/helpful to pretty much any other cloud provider, e.g: DigitalOcean, Vultr, and even on-prem stuff like Proxmox VE, etc.
AWS EC2 is just special 😉

Oh that's good to know! I only have experience with EC2 - it's good that the other clouds have mostly standardised. This makes a lot of sense then.


Improve configure_esbuild script and/or add instructions for manual installation to README

Right now the configure_esbuild module is simply copying over the the files from the assets/copy directory and prompts the user if they want to override the files if it already exists. This works for new projects, but for existing projects with existing files, this is not ideal.
A possible solution could be to improve on the script...

Copy the files if not existing.
If a file already exists, attempt to inject the new code needed into the existing file.
If injecting the code fails, show a message to direct the user to a section in the README showing the necessary code changes.

Another solution could be to not have a script at all and just show the user what code needs to be added in the installation instructions. Not a fan of this, but it works. 🙃
In either case, updating the installation instruction with what code changes are needed would be useful so that if the script fails, at least the user knows what needs to be done manually. I can help add this if you think it'd be helpful :)

An update to the readme would definitely be useful. A section on "manual" installation maybe.
I don't mind the copy functionality that much as I assume if you have a custom setup already, you know what you're doing and you can see in git if it overrides your previous config. You can then manually fix it.
But a manual setup guide might be handy!

Cool. I'll take a look at adding a "manual" installation when I get the chance :)


Add Edgeware EdgeEVM Mainnet

Network information

Name: Edgeware EdgeEVM Mainnet
ChainId: 2021
RPC http/s address: https://edgeware-evm.jelliedowl.net
Link to https://chainlist.org/: https://chainlist.org/chain/2021
Blockexplorer: https://edgscan.live/

Thanks @Uxio0


Question about the relationship between iPerf and Sage Client/Server

In Sage.cc, Line 237 and 238,
sprintf(tmp_cmd,"%s sudo -u `echo $USER` iperf3 -c $MAHIMAHI_BASE -p %d -R -i 0 -t %d &",tmp_cmd,client_port+i,duration);
sprintf(pre_cmd,"%s sudo -u `echo $USER` iperf3 -s -p %d -i 0 &",pre_cmd,client_port+i);

These lines create an iperf client and server for each flow (there will be serveral iperf) to measure bandwidth and network performance (is this correct?). They are then added to the container_cmd and final_cmd. Thus, when starting the Sage client and server (which sending and receiving "1"), iperf is also started for each flow.
What is the meaning and relationship between iPerf and the Sage Client/Server? From my understanding, iPerf is used for network performance benchmarking (e.g., bandwidth usage and latency), while the Sage Client/Server is responsible for the actual data transmission using Sage's congestion control. Is this correct? Additionally, will iperf and the Sage Client/Server influence each other, e.g., Bandwidth Occupation and compete?
Thank you for your help!

I ignore the start of the loop is not 0 but 1. When flow_num > 1, the first flow will be sage flow, and other flows generated by iperf is working as background flow that compete with sage flows.


Not working on Lumen 6.3.5

What did you do?
Upgraded to Lumen ^6.0
What did you expect to happen?
Everything still works
What actually happened?
It simply stopped working
What versions of PHP, Lumen and this module are you using?
PHP 7.2
Lumen 6.3.5
lumen-cors 3.2.0
I have done everything stated in the readme. I have verified that this is working on Lumen 5.8 but NOT on Lumen 6.3.5
I have no idea why.

Hard to tell without more information. You can add a die("foo") statement to the middleware to see if it's being run at all. If you have a debugger you can just set a breakpoint instead.

Can you not reproduce the issue that i describe above ? It seems that i'm doing everything on my end correctly if it appears to work on Lumen 5.8 but not Lumen 6.3.5 ?
If you can not reproduce the issue I have not problems digging deeper into my setup and trying to figure out why my setup is different than yours.

For what it's worth, I just triggered a new CI build, and that passed with Lumen 6.3.5:

https://travis-ci.org/github/digiaonline/lumen-cors/jobs/666313236#L353

The previous build was with 6.2.0 and passed:

https://travis-ci.org/github/digiaonline/lumen-cors/jobs/626661470#L332

(I've turned on a monthly cron for the CI to help catch any failures from new releases.)

@hugovk Thanks for that. We at least know that the tests are passing and looks like code coverage is good on the methods.
I can try and figure out what the deal is with my particular setup then and will report back of anything that is note worthy.

@poppabear8883 is this still an issue?

This appears to have been an issue on my end. I'll close this issue.

This appears to have been an issue on my end. I'll close this issue.


[primitives,sse] fix a bug in sse4.1 primitives copy

@jackyzy823 I was able to reproduce this with 3.8.0, but after applying this fix I could no longer do so.
can you confirm?


Major changes in duplicate key handling

Since it’s perfectly fine to have two keys with the same timeline
position and MathHelper’s GetFactor method does not check
a and b values not to be equal, special handling of double key
with the same timeline position is added. This resulted in UnityEngine
errors when assigning local position with coordinate values equal NaN.
Reproduction case is having animation with first key at timeline position
zero and last two keys at timeline position of animation end. When trying
to get FrameData for time equal to animation end, factor calculation would
return NaN.
Maximum duplicate key which can appear in a row is two, for more info see
https://brashmonkey.com/forum/index.php?/topic/4083-multiple-keys-with-the-same-timestamp-in-timeline/
One thing I'm not sure about:

Change in GetMainlineKeys. If having key with id 1 and key with id 2 as duplicates with timeline position 200 and key with id 3 at position 300, GetMainlineKeys now returns key with id 1 and key with id 3, maybe it should return id 2 and id 3 instead? Not clear from Spriter forum message mentioned above.

Example Spriter project to reproduce issue this pull request fixes:
DuplicateKeyRepro.zip
Closes #98

Thanks!


Add a finer grained per-node lock

It may be operationally interesting to have a finer grained lock than the global lock on the DaemonSet in case a specific node needs to stay up for a reason or another.

A similar use case: it would be nice to be able to pick which node may reboot.
Currently we want to be careful which nodes are rebooted, it'd be nice to be able to use the kured lock to allow a specific node to reboot, but no subsequent nodes.

Actually, on reflection, I really want a blacklist so that I can say which nodes should not be rebooted, and let the others update normally.

Would it be possible to use node labels (or, pod labels) to select nodes before reboot logic? So that if any critical pod / thing is underway on the node we can have some degree of control.

ISTM this could be accomplished using a NodeSelector on the kured pod template to stop the DaemonSet scheduling us on nodes that we don't want rebooted; is that sufficient?

Thanks @awh. Haven't tried NodeSelector/Affinity yet because I was under the impression that after node selection pod won't evict even if the condition changes. I'll try NodeSelector with DaemonSet.

@awh slightly different question, maybe I am missing something - we are looking to the ability to run kured on all nodes, but to be able to have some control over the order of reboot, or just to say "reboot this node(s) last".
Use cases are, for example, stateful sets, Prometheus, ... - we can be fine with moving it from node to node, but would like to do this once during the restarts on the cluster.
My understanding is saying, that having restarting their node last, we'll move it to already patched node, so no future updates will be done.

This is an Oct 2018 issue, should we close it, and move to new issues for extra questions instead?

That might make sense, yes. Please reopen if you feel this is still necessary. A clear update would be welcome in this case too.


docs: CMake build-system related -- Use FetchContent()

Description
The cmake build-system support is described in doc/markdown/build-systems.md.
It is much simpler to use the cmake FetchContent() mechanism in another cmake project instead to use ExternalProject mechanism.
EXAMPLE:
# -- FILE: CMakeLists.txt
...
include(FetchContent)

FetchContent_Declare(doctest
    GIT_REPOSITORY https://github.com/doctest/doctest.git
    GIT_TAG        v2.4.11
)
FetchContent_MakeAvailable(doctest)

Additional Point
The usage example for cmake can be improved, too:
add_executable(my_tests src_1.cpp src_2.cpp ...)
target_link_libraries(my_tests doctest)

BETTER (using Modern CMake like in other parts):
add_executable(my_tests)
target_sources(my_tests PRIVATE src_1.cpp src_2.cpp ...)
target_link_libraries(my_tests PRIVATE doctest::doctest)

Extra information

doctest version: v2.4.11 (repository state)
RELATED: Catch2 cmake description: Catch2: docs/cmake-integration.md

Duplicate of https://github.com/doctest/doctest/issues/698


feat: reload and reconnect the app process after updating files

Type of change

[ ] New sample
[x] New feature
[ ] Bug fix
[ ] Documentation

Summary
This PR automatically reloads the process and reconnects the Socket Mode connection after a file is changed. All in hopes of improving the development experience.
Reviewers
$ slack create asdf -t slack-samples/bolt-js-custom-function-template -b zimeg/feat-start-reload
$ cd asdf
$ slack run           # Run the app in some separate window
$ vim app.js          # Make a change to the app and watch a reload
$ vim manifest.json   # Update the manifest and notice the app is reinstalled
$ slack delete
$ cd .. && rm -rf asdf

Notes

https://github.com/remy/nodemon

Requirements

[x] I’ve checked my submission against the Samples Checklist to ensure it complies with all standards
[x] I have ensured the changes I am contributing align with existing patterns and have tested and linted my code
[x] I've read and agree to the Code of Conduct

@seratch appreciate the approval for this! From some discussion it sounds like documenting this as a possibility is the approach we're going with for now. I like the idea from @WilliamBergamin in slack-samples/bolt-python-custom-functions#19 of including this in hooks, but see how that comes with maintenance burden...
Hoping to have this documented somewhere sometime soon, but will close this PR for the time being.


add pre-check for csvinput and rtp input

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


Approval should pass U64 in callback to external contract

This fixes a breaking implementation where u64 was passed instead of U64.
There are already marketplaces and NFT contracts that routinely pass U64 for nft_on_approve so this must be fixed in the standard implementation.
While the initial intent was to have approval IDs always be numbers/u64 because
they're never expected to exceed the JSON limit of 2^53 and
we may as well therefore save some (minimal?) serialization/deserialization costs,
at this point many applications in the wild expect to receive approval_id: U64 [also, please link to such deployed apps]. Rather than attempting to change all of these deployed contracts, we believe we should instead update the standard because:
it is the more backward-compatible change – it is possible to go from strings to numbers but not numbers to strings;
it is more consistent – in general, we could always suggest using U64/U128 for arguments, even if they theoretically will never be that large, so that developers don't have to think about which one to use;
the gas savings [can we quantify this?] do not justify the costs mentioned in points 1-2 above.
TODO please test.
TODO might want to check nft_is_approved as well, consider U64. Not sure.

Now that Mintbase doesn't care about migrations I'm fine with the current standard. We'll have to talk to other partners like Collab.Land and have them redeploy all NFT contracts to work with current market implementations.
Pluminite will also need everything redeployed.

Now that Mintbase doesn't care about migrations I'm fine with the current standard. We'll have to talk to other partners like Collab.Land and have them redeploy all NFT contracts to work with current market implementations.
Pluminite will also need everything redeployed.

Thanks for the update. Yes, all projects that implemented the standard incorrectly will have fix their mistake, unfortunately.
We can consider a major version release of a standard, but I do not see any evidence of that approach, so will have to assume there are reasons not to do that. Seeing as this thread may become lengthy, there is a special link in Discord where we can have a more free-form conversation about this.

I'm seeing some promising results for redeployment here: https://github.com/near-apps/nft-market/commit/2814e5f5d899006471abc2c1aa12fa63b09ef07e
With this diff, I've tested re-deploying both NFT and Market contracts to the same accounts and running my test suite on testnet (many approvals and sales). There appears to not be any adverse behaviour.
I'll do a deeper dive tomorow.

Issue moved here: https://github.com/near/NEPs/pull/257


Carla 0.9.14 image aspect ratio has to be fixed value?

Discussed in https://github.com/carla-simulator/carla/discussions/6451

Originally posted by ZijianHan May  7, 2023
Hi, I'm wondeing does the camer image size has to follow a specific aspect ratio of 16:9 or 4:3 in carla?
I'm trying to set some non-regular to the image size, for exaple 3832*2134, or some smaller value that is not exactly 16:9, then I got some strange image output as seen in the attachment.
Here is part of my code for setting up the camera
         camera_bp = bp_lib.find('sensor.camera.rgb')           camera_bp.set_attribute("image_size_x",str(3832))           camera_bp.set_attribute("image_size_y",str(2134))           camera_bp.set_attribute("fov",str(105))           camera_init_trans = carla.Transform(carla.Location(z=2))           camera = world.spawn_actor(camera_bp, camera_init_trans, attach_to=vehicle)
Is there any way I can make the image output with any aspect ratio?

If you are modifying one of the examples, you can try to modify the image size through
    argparser.add_argument(         '--res',         metavar='WIDTHxHEIGHT',         default='1280x720',         help='window resolution (default: 1280x720)')
It works for me with a resolution of '5760x1080'. You may need to change the FOV for a suitable view.

If you are modifying one of the examples, you can try to modify the image size through  argparser.add_argument( '--res', metavar='WIDTHxHEIGHT', default='1280x720', help='window resolution (default: 1280x720)') It works for me with a resolution of '5760x1080'. You may need to change the FOV for a suitable view.

Hi, thanks for the reply! Did you mean to modify the simulator window size (in that case the camera is the whole window)?
what if I have multiple cameras atached to ego vehicle with different image size, in that case I think I need to change the camera attribute right? Or did I misunderstand here, as I do not know if camera has an attribute for "--res"?

this look like the stride problem that's currently present for Windows in the 0.9.14 release. See #6085 and cba2231977d24ee78dfc8b28a77fb4528d9559b3 for the fix

Thanks a lot! I've confimed it's a bug on 0.9.14 on Windows. Works for me on Linux.


Japanese version

Include Japanese translation in codebase
Build & push script
Relax landing page style so that it also works for Japanese version

Deployed to: https://ja.cofacts.tw/

Seems that there are missing kanji font in our current font selection


Docs: batch limit of azure.storage.blob.ContainerClient.delete_blobs() is poorly documented

I wanted to move an entire "folder" within a storage account and for unrelated reasons I had to use this python sdk for that. I did this in basically a 3-step action:

List all blobs that match this "folder" in the pseudo-hierarchy
Copy those blobs individually to the new destination
Delete the source blobs, for which I was happy to see that there already was a batched method: azure.storage.blob.ContainerClient.delete_blobs() so I didn't have to individually delete each blob one by one.

Or so I thought ... the batch failed with a PartialBatchErrorException and when I analyzed the parts, I noticed that a request failed with error code ExceedsMaxBatchRequestCount. The thing is: this "max batch request count" was nowhere to be found - neither in the code documentation, nor anywhere on the azure limits documentation page. The only thing I found was this test case from the .NET SDK:
https://github.com/Azure/azure-sdk-for-net/blob/402b7b71c310bbe0cb1c49862ba33c19a026f97d/sdk/storage/Azure.Storage.Blobs.Batch/tests/BlobBatchClientTests.cs#L64-L70
The 257 there seemed a bit suspicious so I experimented a bit with chunking and indeed 256 seems to be the maximum number of blobs that can be passed to delete_blobs(). However, 256 as a number is nowhere to be found in the storage section of the python sdk. Why did it have to be so difficult to find anything about this limit?
Once you decide if and where this should be documented, I'd of course offer my help in contributing this documentation.

@jalauzon-msft can you take a look?

Hi @Gerrit-K, thanks for bringing this up and your investigation!
You are correct. The batch size for delete_blobs(), as well as the other batch APIs we support, is limited to 256 by the service.
https://docs.microsoft.com/en-us/rest/api/storageservices/blob-batch#request-body
I will create a PR to add this limit to the code documentation for all of our batch APIs. Once updated and release, the documentation will also be pushed to our online docs.

In the future, we may want to consider having these APIs support looping through batches if the user specifies more than 256 items. Or at the very least, raising a helpful exception if more than 256 items are specified.

Oof ... yeah I apparently didn't check the API docs 😓 And also sorry if I sounded a bit grumpy there. Thank's for picking this up and responding so quickly, much appreciated! I agree that automatically looping through the batches would be the most ideal solution, but the PR you've submitted is already really helpful!

I had a bit of a mishap with the previous PR. I've created another one combined with another doc update.


[py-updates] Update Python dependencies

@wlonk is there still a blocker for updating to Django 3? Or is that just happening elsewhere?

@davisagli Yeah, waiting on an update to django-parler. The fixes have been merged, but no updated version released yet. See https://github.com/oddbird/MetaShare/pull/100


Inline ASM Packing

Trying to understand why this code fails:
import torch

import triton
import triton.language as tl

def test_inline_asm_packed():

    @triton.jit(debug=True)
    def kernel(X, Y, BLOCK: tl.constexpr):
        x = tl.load(X + tl.arange(0, BLOCK))
        # shift 4x8bits values together.
        y = tl.inline_asm_elementwise(
            "and.b32 $0, $1, 0x1F1F1F1F; \
                                       shl.b32 $0, $0, 3;",
            "=r,r",
            [
                x,
            ],
            dtype=tl.int8,
            is_pure=True,
            pack=4,
        )
        tl.store(Y + tl.arange(0, BLOCK), y)

    device = "cuda"
    shape = (256,)
    x = torch.randint(0, 255, size=shape, device=device, dtype=torch.uint8)
    x_tri = torch.tensor(x, device=device)
    y_tri = torch.empty_like(x_tri)
    kernel[(1,)](x_tri, y_tri, BLOCK=shape[0])
    y_ref = x << 3
    return y_tri, y_ref

y_tri, y_ref = test_inline_asm_packed()

print("max delta:", torch.max(torch.abs(y_tri - y_ref)))

The error message I get is:
python: ../../../lib/Conversion/TritonGPUToLLVM/ElementwiseOpToLLVM.cpp:1259: virtual mlir::LogicalResult {anonymous}::ElementwiseInlineAsmOpConversion::matchAndRewrite(mlir::triton::ElementwiseInlineAsmOp, {anonymous}::ElementwiseInlineAsmOpConversion::OpAdaptor, mlir::ConversionPatternRewriter&) const: Assertion `numInputElems % op.getPackedElement() == 0' failed.
Aborted

Tried to debug this by adding LLVM_DEBUG statements to the conversion pass (TritonGPUToLLVM/ElementwiseOpToLLVM).
After building triton from this modified source and running the above with TRITON_ENABLE_LLVM_DEBUG=1 does not print the debug statements that I inserted.
The default build type for triton is TritonRelBuildWithAsserts, which should be sufficient for enabling the LLVM macro.
A few questions:

Are there other compilation options I need to set to enable LLVM_DEBUG statements?
Comparing the packed inline_asm unittests:

@pytest.mark.parametrize("num_ctas", num_ctas_list)
def test_inline_asm_packed(num_ctas, device):
   check_cuda_only(device)

   if is_hip():
       pytest.skip("test_inline_asm is not supported in HIP")

   @triton.jit
   def kernel(X, Y, BLOCK: tl.constexpr):
       x = tl.load(X + tl.arange(0, BLOCK))
       # shift 4x8bits values together.
       y = tl.inline_asm_elementwise(
           "and.b32 $0, $1, 0x1F1F1F1F; \
                                      shl.b32 $0, $0, 3;", "=r,r", [
               x,
           ], dtype=tl.int8, is_pure=True, pack=4)
       tl.store(Y + tl.arange(0, BLOCK), y)

   shape = (512, )
   rs = RandomState(17)
   x = numpy_random(shape, dtype_str='uint8', rs=rs)
   x_tri = to_triton(x, device=device)
   y_tri = to_triton(numpy_random(shape, dtype_str='uint8', rs=rs), device=device)
   kernel[(1, )](x_tri, y_tri, BLOCK=shape[0], num_ctas=num_ctas)
   y_ref = x << 3
   # compare
   np.testing.assert_equal(y_ref, to_numpy(y_tri))

and

def test_inline_asm_packed_multiple_outputs(device):
    check_cuda_only(device)
    if is_hip():
        pytest.skip('This test uses PTX inline assembly, so is not compatible with AMD')

    @triton.jit
    def kernel(A, B, C, D, BLOCK: tl.constexpr):
        a = tl.load(A + tl.arange(0, BLOCK))
        b = tl.load(B + tl.arange(0, BLOCK))

        # For each (a,b) in zip(a,b), perform the following:
        # - Let ai be `a` converted to int32.
        # - Let af be `a` converted to float.
        # - Let m be the max of ai and b.
        # - Return ai and mi.
        # Do the above 4 elements at a time.
        (c, d) = tl.inline_asm_elementwise(
            asm="""
            {
                // Unpack `a` into `ai`.
                .reg .b8 tmp<4>;
                mov.b32 {tmp0, tmp1, tmp2, tmp3}, $8;
                cvt.u32.u8 $0, tmp0;
                cvt.u32.u8 $1, tmp1;
                cvt.u32.u8 $2, tmp2;
                cvt.u32.u8 $3, tmp3;
            }
            // Convert `ai` to float.
            cvt.rn.f32.s32 $4, $0;
            cvt.rn.f32.s32 $5, $1;
            cvt.rn.f32.s32 $6, $2;
            cvt.rn.f32.s32 $7, $3;
            // Take max of `ai` and `b`.
            max.f32 $4, $4, $9;
            max.f32 $5, $5, $10;
            max.f32 $6, $6, $11;
            max.f32 $7, $7, $12;
            """,
            constraints=(
                # 8 output registers, namely
                #   $0=ai0, $1=ai1, $2=ai2, $3=ai3,
                #   $4=m0,  $5=m1,  $6=m2,  $7=m3.
                "=r,=r,=r,=r,=r,=r,=r,=r,"
                # 5 input registers, namely
                #   $8=ai,
                #   $9=b0, $10=b1, $11=b2, $12=b3.
                # The four elements from `a` are all packed into one register.
                "r,r,r,r,r"),
            args=[a, b],
            dtype=(tl.int32, tl.float32),
            is_pure=True,
            pack=4,
        )
        tl.store(C + tl.arange(0, BLOCK), c)
        tl.store(D + tl.arange(0, BLOCK), d)

    shape = (512, )
    rs = RandomState(17)
    A = numpy_random(shape, dtype_str='uint8', rs=rs)
    B = numpy_random(shape, dtype_str='float32', rs=rs)
    A_tri = to_triton(A, device=device)
    B_tri = to_triton(B, device=device)
    C_tri = to_triton(numpy_random(shape, dtype_str='int32', rs=rs), device=device)
    D_tri = to_triton(numpy_random(shape, dtype_str='float32', rs=rs), device=device)
    kernel[(1, )](A_tri, B_tri, C_tri, D_tri, BLOCK=shape[0])

    C_ref = A.astype(np.int32)
    D_ref = np.maximum(A.astype(np.float32), B)

    np.testing.assert_equal(C_ref, to_numpy(C_tri))
    np.testing.assert_equal(D_ref, to_numpy(D_tri))

Why is the dtype in the first case tl.int8 and tl.int32 in the second, even though both have pack=4?

Are there other compilation options I need to set to enable LLVM_DEBUG statements?

The purpose of LLVM_DEBUG is that it only gets executed if you pass -debug passname when running triton-opt.  I don't even know if it's possible to do the equivalent of -debug when running Python.  As a quick-and-dirty printf debugging technique, I would recommend printing using printf or llvm::errs() without any LLVM_DEBUG.

Why is the dtype in the first case tl.int8 and tl.int32 in the second, even though both have pack=4?

dtype is the return type of the inline asm.  In the first case, the inline asm block returns 4 int8's, and in the second, it returns 4 int32's.

Going to close this because it's not a bug.  There is a "discussions" tab, although you can also try the Triton Slack.  (Or you can keep posting here, although I don't have a lot of cycles to help people debug their Triton programs, sorry.)

(Triton slack: https://github.com/openai/triton/discussions/2329)

@jlebar
Thanks -- quick question:
I tried adding printf first for quick and dirty debugging:  i.e., print numInputElems and op.getPackedElement() here and rebuilt / installed from source.   Didn't see anything when re-running, which is why I used tried LLVM_DEBUG.

I would recommend applying "usual debugging techniques".  Add a crash and
see if it gets hit.  If not then maybe you're not picking up your rebuild.
On Fri, Mar 22, 2024 at 3:31 PM jeromeku @.***> wrote:

@jlebar https://github.com/jlebar
Thanks -- quick question:
I tried adding printf first for quick and dirty debugging: i.e., print
numInputElems and op.getPackedElement() here
https://github.com/openai/triton/blob/dca2d07c4c2bb0344f3ee8aeebd9fe6882b2f266/lib/Conversion/TritonGPUToLLVM/ElementwiseOpToLLVM.cpp#L445-L448
and rebuilt / installed from source. Didn't see anything when re-running,
which is why I used tried LLVM_DEBUG.
—
Reply to this email directly, view it on GitHub
https://github.com/openai/triton/issues/3439#issuecomment-2016029668,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABEZB25NWTW4ROSCQEZMS3YZSWL7AVCNFSM6AAAAABFEA7XV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGAZDSNRWHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Also maybe you're running your program using pytest?  If so
https://www.google.com/search?q=pytest+doesn't+print+output
On Fri, Mar 22, 2024 at 3:33 PM Justin Lebar @.***> wrote:

I would recommend applying "usual debugging techniques".  Add a crash and
see if it gets hit.  If not then maybe you're not picking up your rebuild.
On Fri, Mar 22, 2024 at 3:31 PM jeromeku @.***> wrote:

@jlebar https://github.com/jlebar
Thanks -- quick question:
I tried adding printf first for quick and dirty debugging: i.e., print
numInputElems and op.getPackedElement() here
https://github.com/openai/triton/blob/dca2d07c4c2bb0344f3ee8aeebd9fe6882b2f266/lib/Conversion/TritonGPUToLLVM/ElementwiseOpToLLVM.cpp#L445-L448
and rebuilt / installed from source. Didn't see anything when re-running,
which is why I used tried LLVM_DEBUG.
—
Reply to this email directly, view it on GitHub
https://github.com/openai/triton/issues/3439#issuecomment-2016029668,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABEZB25NWTW4ROSCQEZMS3YZSWL7AVCNFSM6AAAAABFEA7XV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGAZDSNRWHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Nope, am running as normal python program.  Fwiw, the example is adapted from triton unittests, the primary difference is that I changed shape from 512 to 256.


Install google fonts on  instead of @import

Use a <link rel="stylesheet"> on index.html instead of this
https://github.com/vmarcosp/minimalist-profile/blob/3dd569e2844c932f6b8a26d4411fc60d2376cedd/scss/all.scss#L1
CSS @import inside an file imported with a <link rel="stylesheet"> cause browsers to download each file in sequence. Download font and style as <link rel="stylesheet"> cause browsers to download files in parallel which is much better!
Source

Yes I did it temporarily :smile: . That was already on my list of improvements.

Fix in this changes.


refactor: Reduce zli binary size

What type of PR is this?

Which issue does this PR fix:
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs showing the issue:
Testing done on this change:

Automation added to e2e:

Will this break upgrades or downgrades?
Does this PR introduce any user-facing change?:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

rebase and re-push?


Unable to build private project with gold subscription

Steps

Import new private project
Go to settings -> Gold
Adopt the project.
Go to builds page and trigger a new build

The cloning step fails with:
Failed to import project: Failed to get code from 'https://github.com/SpamExperts/xxxx' (git clone): 128 git clone error output: fatal: could not read Username for 'https://github.com': No such device or address

This is not what Gold projects are for. They support Read the Docs -- if you want private projects you can use http://readthedocs.com -- Do we have it documented somewhere that Gold lets you do private projects on readthedocs.org?

I did a quick look into our docs and I don't find anything saying that Gold subscription supports private repos.
Private repos are mentioned in a section that says that it works for .com, http://docs.readthedocs.io/en/latest/business/index.html
I'm closing this issue.


Items actiosn and features appearing twice on chracter sheet

Describe the bug
Not sure what is happenign seeign attacks features and actions appearigt wice on soe monsters after importing them, however not on all of them.
To Reproduce
Steps to reproduce the behavior:
Unsure .. tried importin twice. evend eleted compendium after first try
Expected behavior
would exect them to only appear once
Screenshots
see screenshot atached of 1 monster as example
Environment:

Edge
Foundry Version 10.291
5e System Version [e.g 2.1.4]
Module Version [e.g 3.3.10
Does this behaviour occur with other modules disabled: Yes/No (Find The Culprit module can help with this)
unsure did not try yet

Additional context
Add any other context about the problem here.

A Character URL, if the problem is a character import.
Details of any errors in the browser console (press F12).

If you had tried disabling other modules, as asked, you would have discovered this is The Tagger module. You can track this issue here https://github.com/fantasycalendar/FoundryVTT-Tagger/issues/26

thnx for the speedy reply.. saved me tiem diabling all other modules tommorrow


[@shopify/react-network] Get rid of unused function

Description
This PR gets rid of an unused/unexported function hasDocumentCookie (there seems to be an identical function in @shopify/react-cookie, but the one in this package isn't being used anywhere).
Type of change

[x] @shopify/react-network Patch: Bug/ Documentation fix (non-breaking change which fixes an issue or adds documentation)

Checklist

[x] I have added a changelog entry, prefixed by the type of change noted above

Are you sure this isn't used anywhere ourside of this repo? Seems tough to verify. It would probably need to be a major bump because we are removing an API entirely.

Are you sure this isn't used anywhere ourside of this repo? Seems tough to verify. It would probably need to be a major bump because we are removing an API entirely.

Oh I kinda just assumed that since it wasn't exported through index.ts consumers wouldn't really be using it. I can just close this PR if that's not the case.


Rework addBehavior to take any function, and addBehavior should pass in the global time.

I need more context for this. Why do you want addBehavior to take any function?

If people want to add application logic that updates on every tick. For example, I wanted to use an audio visualization library and have it update application-level data about the spectrum and frequencies.
var spectrum = [];
sceneEl.addBehavior(function (t) {
  audio = audio.getSpectrum();
});

And it's a bit awkward for a public API to have to take functions through an object shaped like {update: func}.


Running programs in subshells

I just recently switched my project jumper from using tcell to bubbletea but I have run into some issues with ioctl.
Previously i was able to run my script in a sub command like cd $(jumper to). Now when i try that same command with bubbletea i get the the following error:
inappropriate ioctl for device
cd: string not in pwd: ^[[?25l^[[?1049h^[[0;0H^[[?1002l^[[?1003l^[[1;m❯^[[0m

Some searching in tcell led me to this https://github.com/gdamore/tcell/blob/7946eb8e8d8303b1ee1da909dcdebf448f0b5cb7/nonblock_unix.go#L25-L40
Seems as though bubbletea isn't waiting for the output to drain properly (if im understanding the tcell code correctly.)

Good catch and thanks for the report. I can reproduce this on my end. This absolutely something we'll need to fix. We'll keep this thread updated with progress.

I started digging into it to see if i could figure out how tcell is doing it. Can't promise I can figure out a fix since I don't have much free time anymore but if I can figure out a fix from tinkering around I'll open a PR.

@M-Porter thanks for that info. This is definitely something that's not resolved yet and we're very keen to sort this one out. We'll keep this issue updated with progress.

for sure. i just figured any info along the way would help!

I'm very interested in this as well, and have been doing a bit of exploration with muesli's help. I wrote up a few proposals: https://gist.github.com/wesen/045b8ef7227ddd8a6951cd308e5d4634
This seems like a separate issue (that I didn't run into yet), but I might take a closer look, to see if it impacts my use case too.

@wesen I tested proposal 1 and i can use the program in a subshell now but there are still no colors output.

Hey @M-Porter, if I'm understanding your issue correctly you want to do something similar to https://github.com/charmbracelet/gum (running Bubble Tea programs and using their output) but running the program separately. They way that we got around this was by running the program on os.Stderr and setting the Lip Gloss profile manually lipgloss.SetProfile(...) which allows us to do things like:
vim $(gum filter)


Documentation consistency for appgatesdp_policy

Terraform CLI, Terraform appgatesdp Provider Version, and Appgate Appliance version(s)
Terraform v1.3.7
on darwin_arm64
provider registry.terraform.io/appgate/appgatesdp v1.1.1
provider registry.terraform.io/hashicorp/aws v4.60.0
appgate appliance version: 6.1.2

Affected Resource(s)

appgatesdp_policy
Documentation?

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.
resource "appgatesdp_policy" "this" {
  for_each = { for ap in var.access_policies : ap.name => ap }

  name      = each.value.name
  notes     = each.value.notes
  disabled  = !each.value.enabled

  type      = each.value.type

  entitlements = [ for e in each.value.entitlements : appgatesdp_entitlement.this[e].id ]

  expression = file("./policy_conditions/${each.value.condition_file}")

  tags      = each.value.tags
}

Debug Output

Panic Output

Expected Behavior
Creating a policy with no type creates a “Mixed” policy.  This option is not available in the ui and I had to go digging through the API documentation to figure out why this was showing up.  type="" is marked optional/informational in the terraform provider documentation, but has actual effect.
[type](https://registry.terraform.io/providers/appgate/appgatesdp/latest/docs/resources/policy#type): (Optional) Type of the Policy. It is informational and not enforced.

Actual Behavior
Documentation should reflect that not including the type param will create a mixed policy.

Steps to Reproduce

terraform apply

Important Factoids

References

#0000

Hi @jered-miller
The policy attribute type is a new attribute. The reason it's Optional is for backwards compatibility, and generated a value of Mixed if omitted.
Certain policy attributes are only applicable for certain types, for example:

access policy (type = "Access") is based on Entitlements association
admin policy  (type = "Admin")  is based on admin role association
device policy  (type = "Device")  is based on ringfence rule
DNS policy  (type = "Dns")  is based on DNS configuration or DNS entitlements.

so for example,
resource "appgatesdp_administrative_role" "test_administrative_role" {
  name  = "tf-admin"
  privileges {
    type         = "Create"
    target       = "Entitlement"
    default_tags = ["api-created"]
  }
}

resource "appgatesdp_policy" "bad_example" {
  name = "Test policy"
  type = "Dns" # explicit set DNS type
  # DNS Type can't use administrative_roles
  administrative_roles = [
    appgatesdp_administrative_role.test_administrative_role.id
  ]
  tamper_proofing = false
  disabled        = false

  expression = <<-EOF
	var result = false;
	return result;
	EOF
}

this example would output validation error, administrativeRoles may not be used on this Policy type.
but if you would omit type = "Dns" it would become a mixed type.
What we could do that may improve the user experience and make it more clear is to add additional terraform resources where the  type  is predefined, for  example:
resource "appgatesdp_access_policy" "policy" {}   Policy type = Access
resource "appgatesdp_admin_policy" "policy" {}    Policy type = Admin
resource "appgatesdp_device_policy" "policy" {}   Policy type = Device
resource "appgatesdp_dns_policy" "policy" {}       Policy type = DNS
this would then be the same as shown in the admin UI when creating a policy

I think breaking this into different resources would be a good idea.  Will close.

@jered-miller  in v1.4.0 includes new resources

appgatesdp_device_policy - https://registry.terraform.io/providers/appgate/appgatesdp/latest/docs/resources/device_policy
appgatesdp_dns_policy - https://registry.terraform.io/providers/appgate/appgatesdp/latest/docs/resources/dns_policy
appgatesdp_access_policy-  https://registry.terraform.io/providers/appgate/appgatesdp/latest/docs/resources/access_policy
appgatesdp_admin_policy - https://registry.terraform.io/providers/appgate/appgatesdp/latest/docs/resources/admin_policy

hopefully this will make it somewhat more clear to use.


Fix local inlining error

inline=['remote'] is failing when a local file is missing despite the fact that local imports should not be inlined

Looks good @sannysoft, thanks for the fix :+1:

Released in clean-css 5.1.4.


Update alibaba-cloud-function-compute logo

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

[x] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[x] Is your project closed source or, if it is open source, does your project have at least 300 GitHub stars?
[x] Have you picked the single best (existing) category for your project?
[x] Does it follow the other guidelines from the new entries section?
[x] Have you included a URL for your SVG or added it to hosted_logos and referenced it there?
[x] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[x] Does your project/product name match the text on the logo?
[x] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[ ] ~15 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

Deploy preview for landscape ready!
Built with commit 3c100e64b6be7c93e584d1047b93a14dbfecbc50
https://deploy-preview-1914--landscape.netlify.app

LSTM

@alexcontini can you update the logo here with the new proper color?

fixed with https://github.com/cncf/landscape/pull/1918


Add Hashable instance for Data.Version.Version

the subject says it all :-)
See Data.Version

Fixed by 4b50676149374a2429a9a80d70bc79266a9a9949.


Slow Registration Issue

Registration of new accounts is very, very slow. It's slow enough that some users cannot register accounts, because their browser returns a "Service Unavailable" error prematurely.
Here's the technical problem:

We store usernames as salted bcrypt hashes, with a different salt for each username
Checking whether a username exists therefore requires calculating a hash for each existing user to compare usernames (An O(n) comparison)
Registering a new user therefore requires calculating 2300+ bcrypt hashes, which is exceedingly slow

We can avoid the problem by using the same salt for all future accounts, reducing lookup times from O(n) to O(1). This technically sacrifices some anonymity, in that it will now be easier for an attacker that's stolen our login database to brute force usernames.
My questions:

Do we find this degree of anonymity loss acceptable?
If using the same salt is acceptable, how do we transition the database so registration is snappy?

Feedback from the community would be greatly appreciated.

Fixed on the 1.4 branch, and pushed to the live server.
I switched to using salted SHA256 hashes for the usernames, reducing lookup to O(1), and fall back to the legacy login database if a username isn't present in the new login table.
I also removed the requirement that usernames be unique, so looking in the legacy database is not required for new user registration. This means user lookups are only extremely slow if a non-existent user attempts to mark or unmark a camera, which is acceptable behavior.


Added jsoncafe.com (online template driven model class generator) to …

…JSON section

Project URL

http://www.jsoncafe.com/
Category

JSON
Description

jsoncafe.com  is template driven source code generator for Model Class Generator.
Why it should be included to awesome-ios (optional)
Quickest way to generate model class
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 4 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Warning

:warning:
Found 4 link issues, a project collaborator will take care of these, thanks :)

Link issues by awesome_bot

Line
Status
Link

491
301
https://github.com/carambalabs/SugarRecord redirects tohttps://github.com/modo-studio/SugarRecord

1507
301
https://github.com/carambalabs/UnsplashKit redirects tohttps://github.com/modo-studio/UnsplashKit

1580
301
https://github.com/kylef/Curassow redirects tohttps://github.com/kylef-archive/Curassow

1589
301
https://github.com/kylef/Frank redirects tohttps://github.com/kylef-archive/Frank

  Generated by :no_entry_sign: Danger


Remove circular references when stringifying an object

Remove circular references when stringifying an object because otherwise, the JSON.stringify throws an error.

Thanks!
This seems to be working fine when testing on Binder:

Using a snippet like in: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#issue_with_json.stringify_when_serializing_circular_references

Binder link working https://mybinder.org/v2/gh/QuantStack/jupyterlab-js-logs/circular-references

Nice!

Let's wait for CI and a quick check on Binder and this should be good to go.

Binder seems to be having issues right now.
Just pulled locally and it looks good :+1: