[Incomplete] Break long words

Reference #1185
@larsiusprime, if you don't need multiple formats, I think it's good/only has minor issues
HTML5/Flash results so far:

Test string 1-4: これがうまくいけば、日本語を使用することができることを強調するためにいくつかのテストテキストです。 left, center, right, justify
Test string 5: これがうまくいけば、日\n本語を使用するこ\nとができ\nることを強調するためにいくつ\nかのテストテキストです。 left
They are different, but HTML5's text is ever so slightly thinner than Flash's for whatever reason, which is causing a few characters to stay on the line when in Flash they would be bumped down. I tried a bunch of English test cases in every text align, but I wouldn't call it thorough.
Issues:

RIGHT align does not give the text a 2px buffer. Hard to see with Japanese, but it was obvious in English (existing issue)
I haven't tried multiple formats
Selecting text barely works (existing issue)
I can't run cpp (still), so I couldn't test there
I haven't tested this fully when wordWrap is false

So those issues seem to be of general concern before merging, but are probably not an issue for me. To my knowledge multiple formats was already broken (I use a hack to enable it in DQ, and it only supports multiple colors, not multiple true formats). I don't care about pixel-perfect fidelity to flash, either, and I don't think I use right-aligning too extensively, and I have no selectable text.
So this is almost certainly enough to monkey patch straight into DQ, and an excellent start for a general solution for OpenFL in general.
Well done!

Hmmm, I'm getting what feels like infinite loops on certain screens of DQ, I wonder if we need to look more closely at some of those while() functions.

Wonder if this has something to do with it -- Here's HTML5, looks right:

And here's neko:

So it looks like it's working correctly on html5, but not yet on native, and this missing text might cause some infinite loops on complex edge cases?

Ya know, I bet it's the fact that we're using a naive char.indexOf() test for finding the line breaks. That'll work when transpiled to Javascript as it's natively UTF-16, but it won't work in C++/Neko as it'll assume the encoding is ASCII or whatever rather than UTF-8.

Okay, figured it out, two things are necessary!
First, you have to fix rendering to be UTF-8 aware.
https://github.com/openfl/openfl/blob/develop/openfl/_internal/renderer/cairo/CairoTextField.hx#L321
cairo.showText (text.substring (selectionStart, selectionEnd));

should be:
cairo.showText (Unifill.uSubstring(text, group.startIndex, group.endIndex));

That gets you this: the text renders, but the logic isn't quite right.

@MSGhero's basic logic is right. You just need to make it UTF-8 aware on all platforms. I did this locally with unifill, you just have to replace very charAt(), substr(), substring(), length, etc, any function that will slice & dice a string or return internal information about character positioning, with UTF8-aware versions.
Doing that gets you this:

Which appears to be the correct result!
NOTE: for this particular test I had removed the original "\n" line break in the japanese text, it's all just one big string.

Final result:

Heads up -- I'm getting some infinite loops in battles if I try to use this in production (ie, Defender's Quest). I bet it's from a change to one of the many while loops, let's see if I can pinpoint it.

I'll do the infinite loop when I get home, but bigger question:
@Jgranick Lars is using unifill library to deal with all of text engine's length, substring, charAt, indexOf, etc calls which mess up with multibyte Japanese text. Haxe 3.4 iirc is the big utf string/bytes redo and is slated for late November. Should we wait till then or add the dependency now?

FWIW, my hideous monkey-patch can be found at:
https://github.com/larsiusprime/openfl/tree/allfixes
This is based on a slightly older version of OpenFL, so it will have some noise in the diff that is just because it's a bit behind in various areas.

I personally vote for including Unifill as a dependency so long as we can make sure to properly version guard it so that we don't get hit with a surprise regression or whatever if they update their library unexpectedly. I'm very impressed with it and so far, and it has done much better than trying to write my own unicode-aware functions.
For me the question is simply whether to link it as a haxelib or do something else that's less "fragile" or whatever.

I have noticed that there is that line that I suggested changing in issue #1093 so multiple Japanese text formats should also work as well with these changes in place.

@tienery Yeah that still hasn't been merged :) My concern was that I did something incorrectly here (when creating a new layout group) that causes your/my fix to incorrectly handle multiple formats

Fixed the infinite loop, but not how flash does it. For "aa" and tf.width = 5, flash displays nothing while this will show the left bit of the a's on separate lines. But for the Japanese test text, flash was showing what I assume are the left edges of characters. ¯\_(ツ)_/¯

Wasn't test cases for TextField's supposed to be implemented at some point? I remember one conversation we had (can't find it) related to the Improvements to TextField milestone where someone said (possibly @ibilon if I remember correctly) that we needed test cases before continuing to merging current issues. And apparently until those test cases have been completed for current implementations will we then move forward onto the milestone.
Has that been done yet? Because it's been several months now.

It hasn't, not sure if it's in development. It's just really hard because there are so many weird little things that have gone wrong in textfields, lots of issues we haven't discovered yet, plus the output doesn't perfectly match flash's.
I don't think it's possible to get a comprehensive test suite, just a collection of issues that have broken in the past perhaps.

What I might do is re-implement the entire TextField and get an idea on which part of the code is doing what, split it up, add comments identifying where things are and what they're doing, and then copy-paste into their appropriate places. At least that way when we return to editing the source, we know what's causing what.

Found a few more edge cases, will be testing those.
I'm also gonna comment this section for the next poor soul who needs to make changes here (probably will be me). I don't know what advances are, but the rest makes sense.

Moved to #1661


--onefile experimental feature feedback

On lastest nuitka factory 0.6.10rc8:
C:\GIT\ONEFILETEST\PythonSRC>c:\Python38-64\python.exe -m nuitka --standalone --enable-plugin=multiprocessing --include-package=urllib3 --windows-product-version=<IP_ADDRESS> --windows-company-name="Zoidberg Inc" --onefile SomeProject.py
Nuitka:INFO: Starting Python compilation.
Nuitka-Plugins:INFO: multiprocessing: Injecting pre-module load code for module 'multiprocessing':
Nuitka-Plugins:INFO: multiprocessing:     Monkey patching "multiprocessing" load environment.
Nuitka-Plugins:INFO: multiprocessing: Injecting post-module load code for module 'multiprocessing':
Nuitka-Plugins:INFO: multiprocessing:     Monkey patching "multiprocessing" for compiled methods.
Nuitka-Plugins:WARNING: Use '--plugin-enable=pylint-warnings' for: Understand PyLint/PyDev annotations for warnings.
Nuitka:INFO: Completed Python level compilation and optimization.
Nuitka:INFO: Generating C source code for backend compiler.
Nuitka:INFO: Running data composer tool for optimal constant value handling.
Nuitka:INFO: Running C level backend compilation via Scons.
Nuitka-Scons:INFO: Backend C compiler: cl (cl).
Nuitka-Scons:INFO: Compiled 351 C files using clcache.
Nuitka-Scons:INFO: Cached C files (using clcache) with result 'cache hit': 350
Nuitka-Scons:INFO: Cached C files (using clcache) with result 'cache miss': 1
Nuitka:WARNING: Onefile mode is experimental on 'Windows'.
Nuitka-Postprocessing:INFO: Creating single file from dist folder, this may take a while.
Traceback (most recent call last):
  File "c:\Python38-64\lib\site-packages\nuitka\__main__.py", line 196, in <module>
    main()
  File "c:\Python38-64\lib\site-packages\nuitka\__main__.py", line 189, in main
    MainControl.main()
  File "c:\Python38-64\lib\site-packages\nuitka\MainControl.py", line 776, in main
    packDistFolderToOnefile(dist_dir, binary_filename)
  File "c:\Python38-64\lib\site-packages\nuitka\freezer\Onefile.py", line 56, in packDistFolderToOnefile
    packDistFolderToOnefileWindows(dist_dir)
  File "c:\Python38-64\lib\site-packages\nuitka\freezer\Onefile.py", line 295, in packDistFolderToOnefileWindows
    _runOnefileScons(quiet=not Options.isShowScons())
  File "c:\Python38-64\lib\site-packages\nuitka\freezer\Onefile.py", line 262, in _runOnefileScons
    result = SconsInterface.runScons(
  File "c:\Python38-64\lib\site-packages\nuitka\build\SconsInterface.py", line 275, in runScons
    scons_command = _buildSconsCommand(
  File "c:\Python38-64\lib\site-packages\nuitka\build\SconsInterface.py", line 223, in _buildSconsCommand
    getExternalUsePath(os.path.join(getSconsDataPath(), scons_filename)),
  File "c:\Python38-64\lib\site-packages\nuitka\utils\FileOperations.py", line 490, in getExternalUsePath
    filename = getWindowsShortPathName(filename)
  File "c:\Python38-64\lib\site-packages\nuitka\utils\FileOperations.py", line 460, in getWindowsShortPathName
    raise WindowsError(
FileNotFoundError: [Errno 2] Le fichier spécifié est introuvable.

Yup, it's missing from installation, going to fix that up.

Please retry.

Retried:
C:\GIT\ONEFILETEST\PythonSRC>c:\Python38-64\python.exe -m nuitka --standalone --enable-plugin=multiprocessing --include-package=urllib3 --windows-product-version=<IP_ADDRESS> --windows-company-name="Zoidberg Inc" --onefile SomeProject.py
Nuitka:INFO: Starting Python compilation.
Nuitka-Plugins:INFO: multiprocessing: Injecting pre-module load code for module 'multiprocessing':
Nuitka-Plugins:INFO: multiprocessing:     Monkey patching "multiprocessing" load environment.
Nuitka-Plugins:INFO: multiprocessing: Injecting post-module load code for module 'multiprocessing':
Nuitka-Plugins:INFO: multiprocessing:     Monkey patching "multiprocessing" for compiled methods.
Nuitka-Plugins:WARNING: Use '--plugin-enable=pylint-warnings' for: Understand PyLint/PyDev annotations for warnings.
Nuitka:INFO: Completed Python level compilation and optimization.
Nuitka:INFO: Generating C source code for backend compiler.
Nuitka:INFO: Running data composer tool for optimal constant value handling.
Nuitka:INFO: Running C level backend compilation via Scons.
Nuitka-Scons:INFO: Backend C compiler: cl (cl).
Nuitka-Scons:INFO: Compiled 351 C files using clcache.
Nuitka-Scons:INFO: Cached C files (using clcache) with result 'cache hit': 349
Nuitka-Scons:INFO: Cached C files (using clcache) with result 'cache miss': 2
Nuitka:WARNING: Onefile mode is experimental on 'Windows'.
Nuitka-Postprocessing:INFO: Creating single file from dist folder, this may take a while.
Nuitka-Scons:INFO: Backend C compiler: cl (cl).
clÿ: Ligne de commande warning D9002ÿ: option '/ML' inconnue ignor‚e
Nuitka-Scons:INFO: Compiled 1 C files using clcache.
Nuitka-Scons:INFO: Cached C files (using clcache) with result 'cache miss': 1
Nuitka:INFO: Sucessfully created 'SomeProject.exe'

Got some strange error about unknown /ML option.
My compiler is VC 2015.
When executing the compiled executable, I get
Assertion failed: target_file != INVALID_HANDLE_VALUE, file static_src\WindowsOnefile.cpp, line 253

Hm, probably a CreateDirectory missing there, no subfolders will work yet.

I added the directory stuff, also changed filename encoding to UTF16 while doing, thinking that would be it, it but didn't push yet, because I am having all sorts of funny things happening now, on Python2 I have e.g. observed things that were reported, namely that the created file wasn't possible to open for assertions, that it opened for appending with a file position of 0, and other ugly stuff. With 3.8 it mostly works. But with 2.7, if I seek to end of file, and write there, I end up with a file end where my offset is not correct.
Not sure if that's scons, virus checkers, or what. But when scons finishes, it seems the binary might not yet really be there, but the linker writes are still being performed or what. Occasionally people report that attaching the constants resource fails with that kind of error.
It's funny though, since for 3.8 and 2.7, the onefile binary doesn't care, so the Python version is only different for Scons, the scons code is identical right now for these. So something about subprocess or scons might be at fault.

Ok, adding resources after adding the payload was maybe a bad idea. With 2.7 there is a manifest resource, that will be copied, however, me was thinking there would be a version resource for both, and there is, but it wasn't causing any (obvious) issue with 3.8 at least, which is strange. So I now reverted the order of adding them, and that seems to help.

Ok, pushed an update, that seems to work for Python2 as well. Still need to seek after open, which is strange, but maybe it's just a platform difference, and not indicative of a bug. The smaller binary might show a race condition that needs to be dealt with, but for now it's at least better, and the Qt test case worked, creating subfolders correctly it seems, so your case might work now.


Fix metadata.avdl dateOfBirth format

Fixed the dateOfBirth attribute to now ISO8601.

This seems sensible @mbaudis. There's a couple of things that are iffy about this from a git perspective though:

I think we should be making pull requests from personal forks for this sort of minor change, and not creating branches within the central schemas repo. There's quite a few stale branches lying around now that need clean up I think.
There seems to be some extra commits in here.

@jeromekelleher Not sure about the first point; isn't it better to do it this way, to avoid stale / conflicting branches? I'm not the only one doing it like that (lame excuse, and I'm habby for procedural advice).
Re 2.: I don't understand them showing up, since IMHO I did fork this off master. But there is another oddity (for me); https://github.com/ga4gh/schemas/pull/319 was merged after lengthy arguments and back-and-forth commits, but the changes have disappeared from master.
Do we have somebody with the job to clean up/help out with Github problems?

@mbaudis --- no, I think we should avoid writing directly to the central repo unless absolutely necessary, as having lots of people making un-audited changes to the central repo will lead to a major mess. Which has (given your disappearing changes) probably happened already. I don't think there's anyone responsible for maintaining the git repo.
The CONTRIBUTING.md file is clear on the recommended process: create a fork, and make a PR from this fork. I think the second issue will probably resolve itself if you close this PR, create a fork, and make a PR from this.

I am +1 to @jeromekelleher's suggested approach (fork and pull request).

There is now a "metadata" branch for consistent handling of metadata.avdl & related modifications.

Thanks @mbaudis :)


Add support for Participants

https://www.twilio.com/docs/api/rest/participant

Started in 1b3cf2b26029c3753026729cff500ba50c114326


The loopEnabled configuration doesn't loop a video.

What happened?
I might be missing something, but it appears evident that enabling the loopEnabled feature should make a video repeat continuously. However, for some reason, the video doesn't repeat and just ends.
What are the steps to reproduce?
func setupYouTubeView() {
    let configuration = YouTubePlayer.Configuration(
        automaticallyAdjustsContentInsets: true,
        fullscreenMode: .system,
        showControls: true,
        loopEnabled: true,
        useModestBranding: true
    )

    youTubePlayer = YouTubePlayer(
        source: .url("https://youtube.com/watch?v=YE7VzlLtp-4"),
        configuration: configuration
    )

    youTubeView = YouTubePlayerHostingView(player: youTubePlayer!)
    youTubeView?.autoresizingMask = [.flexibleHeight, .flexibleWidth]

    containerView.addSubview(youTubeView!)
}

What is the expected behavior?
I had the expectation that the video would repeat in a continuous loop.

Hi @EvgenyKarkan,
Please check out the develop branch which contains a fix for the loop parameter.

Thank you very much, I trust you the issue is fixed.
Please feel free to close the current ticket as you see fit.
I am not blocked at all and can wait until the new release is available, so I can pull the updated SPM package.

Thanks!
I will let you know when a new release is available ✌

The fix is now available with the latest version 1.5.1


Docker container exits on start while yarn build:client

Current behavior
The app docker container won't start anymore. It exits after the image build, during the start, while running yarn build:client.
Error message:
@ ./core/app.ts 17:0-44 95:56-66
@ ./core/client-entry.ts
@ multi @babel/polyfill ./core/client-entry.ts

ERROR in /var/www/core/lib/multistore.ts
./core/lib/multistore.ts
[tsl] ERROR in /var/www/core/lib/multistore.ts(137,41)
      TS2345: Argument of type 'object' is not assignable to parameter of type '{ [key: string]: unknown; }'.
  Index signature is missing in type '{}'.

ERROR in /var/www/core/lib/search/adapter/api/searchAdapter.ts
[tsl] ERROR in /var/www/core/lib/search/adapter/api/searchAdapter.ts(74,45)
      TS2345: Argument of type 'HttpQuery' is not assignable to parameter of type '{ [key: string]: unknown; }'.
  Index signature is missing in type 'HttpQuery'.
Child html-webpack-plugin for "index.amp.html":
     1 asset
    Entrypoint undefined = index.amp.html
Child html-webpack-plugin for "index.basic.html":
     1 asset
    Entrypoint undefined = index.basic.html
Child html-webpack-plugin for "index.html":
     1 asset
    Entrypoint undefined = index.html
Child html-webpack-plugin for "index.minimal.html":
     1 asset
    Entrypoint undefined = index.minimal.html
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

It works without this error if started via yarn outside docker.
Expected behavior
Just build and start the container to run the app in a container.
Steps to reproduce the issue
docker-compose --force-recreate --build up

Repository

develop
Can you handle fixing this bug by yourself?

[ ] YES
[x] NO  (But I'll try)

Which Release Cycle state this refers to? Info for developer.
Pick one option.

[x] This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
[ ] This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
[ ] This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

Browser: any
OS: Ubuntu 18 & OSX with latest docker
Node: v10.15.3 like in Docker image node:10-alpine
Code Version: develop 8bdb09b33ce7aeb24af21a799bf3460391a653a6

Hi! Thanks for Your input. Could You please provide us with a Pull Request?

After some research this morning, I noticed it's caused by the missing yarn.lock file in the Docker image. If i add it like COPY yarn.lock ./ in docker/vue-storefront/Dockerfile, it works.
Is I saw in the opened PR's, @Flyingmana already made an PR for this: #3006
So, if this goes through, this can be considered as done.


Question about Belfast

In the Northern Ireland register I would expect that either there would be be a row NIR-Z, Belfast, Belfast City Council, 2015-03-31 in the file or the start date for BFS would be earlier than 2015-04-01 (or at least blank, like the other 'old' NI council records).

Is this a mistake and NIR-Z should exist?

Is this because BFS describes an organisation (Belfast City Council) which has had more than one administrative boundary associated with it (i.e: both https://mapit.mysociety.org/area/145955.html and https://mapit.mysociety.org/area/14333.html are both boundaries which have been associated with the organisation described by the id BFS) but all the other 2015 NI boundary changes actually created new/different administrative organisations?

If its the first one, can I submit a PR to add NIR-Z?
If it is the second one, presumably this means the start date on https://github.com/openregister/local-authority-data/blob/master/data/local-authority-nir/local-authorities.tsv#L34 is incorrect as it implies that BFS came into existence on 2015-04-01?

Thanks @chris48s, that is a good question.  I will put it to the custodian.
Out of interest, which of the two options do you prefer?  Ultimately it's the custodian's call, but it's useful to us to understand how people interpret the information in registers so that we can create better documentation.

it's useful to us to understand how people interpret the information in registers

Hi @nacnudus  - allow me to answer that with a giant wall of text ;)
First of all, I guess it depends on the intended relationship between your IDs and boundary changes/organisational changes. I'm making some assumptions here - please correct me if I'm wrong, but presumably the point of inventing a new coding scheme for local authorities (instead of just calling them N09000003, or whatever) is that you are assigning an identifier to an administrative body rather than a boundary. Then you can maintain a stable ID across boundary iterations which describe the same organisation (which in principle may have N geographic boundaries associated with it at various points in time) - right?
So lets, for a moment, look at some different (clearer) examples:
If we take the identifier STV (Stevenage), in 2013 it had a minor boundary change - it used to be E07000101 and now it is E07000243. The ONS coding system is about describing a boundary - so when this change happens, the area gets a new ID because E07000101 describes a different geographic area to E07000243 but this minor boundary tweak hasn't meaningfully changed Stevenage Borough Council - its still fundamentally the same organisation, so you still call it STV (right?). If you change that identifier every time the boundary changes then a) your nice human-readable codes won't stay human-readable for very long and b) your codes just duplicate another id schema which already exists. Hopefully that is all right?
Conversely, lets consider at a situation where 2 district councils merge into a new unitary authority (say Mid Bedfordshire and South Bedfordshire merging to become Central Bedfordshire in 2009). If something like that happens in future, it isn't just a trivial boundary change that has happened - the actual nature of the organisation(s) the identifiers describe has changed so presumably in that case you would retire the old IDs and create an ID to describe the describe the new body which has been legislated into existance. Again, hopefully that is correct?
So, under those assumptions, lets move back to Northern Ireland:

which of the two options do you prefer?

I guess it depends on whether the legislation that changed the boundaries changed the organisation or just changing the boundary - i.e: If Belfast City Council pre-2015 and post-2015 is fundamentally the same organisation but covering a different geographical area then it should maintain a stable identifier across that boundary change. If Belfast City Council pre-2015 and post-2015 are 2 meaningfully different organisations, then they should have 2 different ids (assuming all of the above assumptions ar right). Either way, I think the current register content implies that up until 2015-03-31, there was no Belfast City Council and that should be corrected one way or the other.
In terms of reading the actual details of the legislation (which I haven't done) and defining the term "meaningful", I'll leave that to the custodian but I guess fundamentally my ask would be: pick a rule, apply it consistently moving forward and document clearly what the rule is.

Thanks!  This is really useful.
You're absolutely right that we separate the concepts of 'boundary' and 'administrative body', and this register is about the administrative body.  Whether or not Belfast City Council is the same pre-2015 and post-2015 is the question I'll put to the custodian, but the keys used (at least to begin with) will be from the ISO 3166-2:GB standard, which didn't change the code for Belfast in 2015.  So we'll probably do something more like your second option.
Having said that, something we haven't decided yet is whether to include historic changes in the register, so when the final version is made ready to use, it might only have the most recent versions.


refactor benchmarks

moves linear regression and random forest benchmarks to separate files.
standardizes on BenchmarkRunner and BenchmarkBase, with the following updates:

infers command line arguments from class under test, with separate params for Spark and cuML (or both).
adds standardized support for a reporting dictionary (w/ persistence).
adds support for multiple iterations.

updates ./run_benchmarks.sh to run either "all" tests, or a single test.

defaults to single-node, single-gpu confs for testing in dev and CI/CD envs.

Note: I tried to leave the core benchmarking code as similar as possible, so there is likely still room for more refactoring.  That said, this puts all of the existing benchmarks on the same base framework, so future cleanup should hopefully be easier and less disruptive.

Looks Good!


Round trip of SBOLTestSuite/SBOL2/test_source_location.xml fails

The round trip test for SBOLTestSuite/SBOL2/test_source_location.xml fails with a KeyError when serializing the document:
KeyError: 'http://partsregistry.org/cd/cd_comp/base1/seq_base1'

The problem is that Component.sourceLocation has RDF type "http://sbols.org/v2#location" instead of "http://sbols.org/v2#sourceLocation". Thus when a sourceLocation is encountered in an SBOL file, it is thought to be an extension and stored in the Component.properties instead of in the Component.owned_objects.


Commands in ScriptRunConfig

ScriptRunConfig can accept a command argument. Example and some real-world use cases
e.g. some simplified version of the following
target = ws.compute_targets["gpu-nc24-ssh"]

env = Environment.from_pip_requirements('elr2-classification', '../requirements.txt')
env.docker.enabled = True
env.docker.base_image = 'mcr.microsoft.com/azureml/openmpi3.1.2-cuda10.1-cudnn7-ubuntu18.04'

mpi_config = MpiConfiguration(process_count_per_node=4, node_count=2)

command = "export PYTHONPATH=$PWD/ELR2 && cd ELR2-Scenarios/classification/elr2_version && python test_distributed_training.py".split()

src = ScriptRunConfig(
    source_directory='../../..',
    command=command,
    compute_target=target,
    distributed_job_config=mpi_config,
    environment=env,
)

run = Experiment(ws, "elr2-ddp-test").submit(src)

I did not try exhaustively at all, but did run into some initial issues getting my dask-mpi example to work with command - let's also add some new examples or modify existing to use command in azureml-examples

I did not try exhaustively at all, but did run into some initial issues getting my dask-mpi example to work with command - let's also add some new examples or modify existing to use command in azureml-examples

Testing Teams connector. Please ignore 😴

Testing Teams connector. Please ignore 😴


Terragrunt run-all terragrunt-info does not receive --terraform-plan-flags

If I pass --terragrunt-exclude-dir in --terraform-plan-flags agains the terragrunt example in the infracost repo, I get this error:
~/src/infracost/infracost/examples/terragrunt(master)$ infracost breakdown --path . --terraform-plan-flags "--terragrunt-exclude-dir ./prod"

Detected Terragrunt directory at .
  ✔ Running terragrunt run-all terragrunt-info
  ✔ Running terragrunt run-all plan
  ✔ Running terragrunt show for each project

  Terragrunt command failed with:
    Terraform couldn't read the given file as a state or plan file.
    The errors while attempting to read the file as each format are
    shown below.
    State read error: Error loading statefile: open /Users/tim/src/infracost/infracost/examples/terragrunt/prod/.terragrunt-cache/O0YQQk6I7evoBoxn0T-w3l60CCQ/--MlH-MC2An3bk6sQJ14E5NuivU/modules/example/.tfplan-56e981bc-c191-45a0-ad67-26739b15a554: no such file or directory
    Plan read error: open /Users/tim/src/infracost/infracost/examples/terragrunt/prod/.terragrunt-cache/O0YQQk6I7evoBoxn0T-w3l60CCQ/--MlH-MC2An3bk6sQJ14E5NuivU/modules/example/.tfplan-56e981bc-c191-45a0-ad67-26739b15a554: no such file or directory
    time=2021-11-30T07:01:12-05:00 level=error msg=1 error occurred:
    * exit status 1

@jrmash we've added a INFRACOST_TERRAGRUNT_FLAGS env variable in https://github.com/infracost/infracost/pull/1172 and released it in the latest version v0.9.15.
You can check out the docs for it here https://www.infracost.io/docs/iac_tools/terragrunt/#terragrunt-cli-options. This now gives a way of passing the --terragrunt-exclude-dir option through to Infracost.


/pkg/ is broken on new GAE

https://www.gorillatoolkit.org/pkg/
HTTP 500's. Need to investigate.

Interim fix will be to redirect to pkg.go.dev/gorilla/

I'm still getting internal server errors instead of redirects

(I haven't fixed it. I have had zero time to do so)

Ah, then I misunderstood your comment of Aug 27.

@elithrar I think something like this?
https://pkg.go.dev/mod/github.com/gorilla/context
istead of /pkg/context in the home template will do?
gorilla/context stores global request variables.

Addressed in 16b4009.
It's likely we will lean on GitHub more going forward - the original site was not authored by anyone here, and does a lot of magic to build package indexes that are high-cost vs. the value they provide to maintain going forward.


3.9+ PEP 585 - type hints for builtin types

In case you haven't seen this:
https://www.python.org/dev/peps/pep-0585/
Relevant:
>>> isinstance([1, 2, 3], list[str])
TypeError: isinstance() arg 2 cannot be a parameterized generic

Fantastic. I hadn't seen that, as ill-gotten fate would have it. If a typing-related PEP isn't explicitly listed in the "PEP 484 & Friends" subsection of README.rst, it's a safe bet that I'm shamefully clueless and desperately require your personal guidance.
So, thanks a bunch for giving it. I'll promptly add a reference to PEP 585 -- Type Hinting Generics In Standard Collections to that list of everything else we currently don't support.
I should also note that, unlike PEP 563 -- Postponed Evaluation of Annotations which I loathe with all my autoimmune-ridden being, I surprisingly like PEP 585. Clearly, this is how they should have implemented generics from the get-go. Creating a parallel typing hierarchy for concrete types (e.g., List for list, Tuple for tuple) never made the slightest sense, given that those types already exist and should have just been reused as is – which PEP 585 now enables.
Sadly, since most existing type annotations leverage the now-obsolete typing.List[str] style rather than the now-sensible list[str] style, we'll (of course) have to support both. Cue xkcd standards.

:boom:

Yikes. Despite deprecating most of the existing public API of the typing module by 2025, PEP 585 is officially unimplemented under all existing Python versions as of this writing – meaning Python 3.5—3.8.
That means it's currently unusable, despite advertising itself as usable under Python 3.7 and 3.8 via the standard from __future__ import annotations pragma. Someone sure dropped the ball on this one, folks.
I don't know why there's effectively no peer review, quality assurance, or stress testing for Python Enhancement Proposals (PEPs). Clearly, something is fundamentally awry with the existing process by which PEPs are submitted, reviewed, and accepted. Whatever's wrong, it's probably long been institutionalized and hard-baked into the cultural climate within the cadre of core Python developers. Good luck changing that, ever.
That isn't to say that we won't eventually support PEP 585. We absolutely will. But we'll need to wait for a usable, working implementation to drop before we can even begin toying around with ideas, implementations, and optimizations. Let's see what fallacious wonders Python 3.9 brings! :sparkler:
Until then, this remains open.

Oh, and the long-awaited beartype 0.2.0 stable release is officially out. We now support most typing attributes of interest except the stupidly hard ones like typing.Generic and typing.TypeVar. Ain't nobody got spare volunteer time for that kinda non-triviality (at the moment, of course).
Up next: deep type-checking of typing.List and typing.Sequence containers in the upcoming beartype 0.2.1, which will probably drop sometime towards the end of September. Let's do this! :bear:

So excited for this.

28 days ago, I promised I would do a thing. Today, I complete that promise by doing a thing. Introducing...
Beartype 0.3.0, dangerously released into the radioactive GitHub and PyPI badlands but moments ago. This release reveals the pure win of O(1) runtime type-checking through on onslaught of quasi-religious revelations, including...
Deep Type-checking of Nested Sequences in O(1) Time: Oh, It's Deep
@beartype now type-checks both the shallow types and deep contents of parameters and return values annotated with typing-based sequences in guaranteed constant time. To do so, we exploit a variant of the well-known coupon collector's problem by randomly type-checking one item at each nesting level of each sequence on each call of each decorated callable. This then enables us to statistically predict the number of calls required to fully type-check all items of an arbitrary container on average. Math spoiler alert: it's O(nlogn) calls.
Currently supported typing-based sequences include:

typing.List.
typing.MutableSequence.
typing.Sequence.

Since beartype 0.2.0 previously implemented deep type-checking for typing.Optional and typing.Union, we now deeply type-check all possible permutations of these type hints: e.g.,
from beartype import beartype
from typing import List, MutableSequence, Sequence, Union

@beartype
def hissing_nest_of_vipers(scary_vipers: Union[bool, str, Sequence[List[MutableSequence[float]]]) -> float:
     return my_floaty_tuple[0]

# These all totally work. Would beartype lie?
hissing_nest_of_vipers(True)
hissing_nest_of_vipers('They really taste great.')
hissing_nest_of_vipers(([[10.23, 9.24,], [8.25, 43.62,],], [[42.63,], [41.18,],]))

# This raises an exception. Beartype never lies! Never!
hissing_nest_of_vipers(([['Like, maybe don't put in your hand in there.'],],))

typing.Tuple and typing.NamedTuple are conspicuously absent with respect to deep type-checking, as their cray-cray syntax requires special-purposed handling that merits its own stable release (e.g., typing.Tuple[wut, even, is, happening, here, bruh]). More on that later.
Of course, tuples and named tuples are both immutable sequences. This means that you can already deeply type-check tuples and named tuples in beartype 0.3.0 by simply annotating parameters and return values as typing.Sequence instead: e.g.,
from beartype import beartype
from typing import Sequence

@beartype
def accept_my_floaty_tuple(my_floaty_tuple: Sequence[float]) -> float:
     return my_floaty_tuple[0]

# This totally works -- even without suspicious squinting, though that helps.
accept_my_floaty_tuple((0.1, 3.6, 2.7, 13.20, 12.21, 11.22,))

Optimized for His and Her Computational Pleasure under Python ≥ 3.8
Let's talk about speed, 'cause everyone likes it fast.
Under Python ≥ 3.8, @beartype generates optimal code when deeply type-checking items contained in nested subsequences (e.g., List[List[List[str]]]). Of course, we use the unclean dirty magic of PEP 572-style assignment expressions to do so. Yes, that's right, friends! PEP 572, the controversial syntactic change that prompted Guido to voluntarily abdicate his ancestral leadership role as BDFL, viciously lashes out again. Thanks to beartype 0.3.0, assignment expressions have finally proven their real-world utility.
I've profiled this eye-, soul-, and career-destroying optimization to yield speedups of at least 200% as the equivalent unoptimized code generated under Python < 3.8. For doubly- and triply-nested sequences (e.g., List[List[str]] and List[List[List[str]), it's about 200% – but the performance gap only increases as the nesting level increases. A doubling in performance is only the minimum improvement under Python ≥ 3.8. Sequences more than triply-nested (e.g., List[List[List[List[List[str]]]]) should expect a comparably dramatic speedup, though it does seem a tad doubtful that anyone in the history of our plucky species would ever commit that kind of anarchic typing monstrosity. Still, it's there. That's nice.
Deep Human-readable Exception Messages: They're Super-deep
@beartype now raises human-readable exceptions exhibiting the exact cause(s) of deep type-checking failures, including failures deeply nested in subcontainers: e.g.,

@beartyped pep_hinted() parameter pep_hinted_param=[([37],)] violates PEP type hint typing.List[typing.Sequence[typing.MutableSequence[str]]], as list item 0 tuple item 0 list item 0 value "37" not str.

Yeah. That's deep like my old soul. Currently supported typing type hints that now generate deep exception messages include:

typing.List.
typing.MutableSequence.
typing.Optional.
typing.Sequence.
typing.Union.

A win for readable typing is a win for all mankind.
The Dark Road Ahead
As America stands on the precipice of a renewed national unity and good tidings of brotherly love, so too do we chart the unmarked trail forwards to a brighter beartyped future:
Beartype 0.4.0: It's Tuples All the Way Down
To maybe be released by late October, Beartype 0.4.0 will probably implement support for deeply type-checking typing.Tuple and typing.NamedTuple, mostly because that's the minimal effort feature request that everyone (...which basically just means me and you, @albanie) wants.
A sample size of 2 is still a sample size. ...what?
Beartype 0.5.0: NumPy Arrays, Eh?
To maybe be released by late November, Beartype 0.5.0 will probably implement support for shallowly type-checking NumPy arrays via a newly introduced beartype.cave.NumpyArrayType thingy, because we desperately need this in both BETSE and our data science and machine learning consultancy. Of course, NumPy arrays deeply type-check themselves by definition. So, there's no need for that here. What is there a need for then?
NumPy array metadata, including:

Dtype. Some dtypes like structured dtypes and the object dtype dramatically alter usage patterns. So, it only makes sense for callables to want to constrain the dtypes of the arrays they accept as parameters and/or return.
Shape. While real-world usage patterns typically treat the size of each dimension of a NumPy array (i.e., the number of items in that dimension) as unconstrained free variables, the number of these dimensions is typically constrained at callable definition time. For example, a callable expecting a two-dimensional NumPy array usually doesn't particularly care how many rows or columns that array has – but it really, really, *really cares that that array has exactly two dimensions and no more or less.

So, I'm thinking preliminary syntax like this:
from beartype import beartype
from beartype.cave import NumpyArrayType

# This constrains the passed "funbag_of_fun" parameter to be a two-dimensional
# NumPy array with any float dtype (e.g., "np.float32", "np.float64").
@beartype
def catch_the_funbag(funbag_of_fun: NumpyArrayType[float, 2]) -> float:
     return funbag_of_fun[0, 0]

Of course, there currently exists no typing standard for annotating NumPy arrays – but since when did a lack of accepted standards, community debate, or common sense ever stop us? Never, of course! Those things, we need them not. Since NumPy is a third-party package (albeit a third-party package that's basically mandatory with all Python installs in 2020), it kinda seems doubtful there ever will exist a typing standard for annotating NumPy arrays.
That's where we come in. Like, us. You and me. It's kinda lonely in here, but a sample size of 2 is still a sample size. ...what?
Beartype 0.6.0: The Mappings Are Not the Territory
To maybe be released by late December, Beartype 0.6.0 will probably implement support for deeply type-checking typing.Dict, typing.Mapping, and typing.MutableMapping. Those are the last big-ticket items we need, but they're also the least trivial. Although the C-based CPython implementation almost certainly stores dictionary keys and values as hash bucket sequences, it doesn't expose those sequences to the Python layer. That means we have no efficient random access to arbitrary dictionary keys or values from within @beartype.
Does that complicate O(1) runtime type-checking of dictionaries? Yes. Yes, it does. Which is why we're saving dictionaries for last. I do have a number of risky ideas here, most of which revolve around internal caches of key and value iterators (i.e., the memory views returned by the dict.keys() and dict.values() methods). I don't want to blow anything up, so this requires care, forethought, and a rusty blood-flecked scalpel.
Beartype 0.7.0: Who Can Tell the Future, Controls the Future
Beartype 0.7.0 is currently open to creative interpretation. Whatever else BETSE needs, beartype 0.7.0 gets.
Beyond that, the future is a smoking ruin of lost causes, dead dreams, and misspent middle-aged-hood. If you have any typing requests, *please not TypeVar, please not TypeVar speak now or forever hold your beartype feature list. :speaking_head:

This is great.
I particularly like the idea for future NumPy validation. I face essentially the same use-case in PyTorch.  Even simple dimension checking to prevent (to catch broadcasting errors) could save buckets of tears for future generations.
As an almost relevant aside, there have been some attempts to transition to "NamedTensors" (originally discussed here http://nlp.seas.harvard.edu/NamedTensor, and later introduced experimentally here https://pytorch.org/docs/stable/named_tensor.html). If they can iron out the implementation issues, in the long term these could lead to a significant improvement in readability and would be well-suited to type/shape-annotations.

Even simple dimension checking to prevent (to catch broadcasting errors) could save buckets of tears for future generations.

Right? There's nothing worse than obscure non-human-readable exceptions arising like rancid burps from the bowels of higher-level APIs like SciPy or TensorFlow just because somewhere down the line some lower-level API accidentally generated a NumPy array with horrifying structure, which nobody bothered to check... because they currently can't.
I'm still not wedded on the syntax, but – after some calculated reflection and pensive soul-searching – I'm unconvinced that typing-style array subscription (e.g., NumpyArrayType[float, 2]) is the RightWay™ to declare array metadata. I mean, sure, it sorta works if you squint at it. But it's also non-human-readable. I can only envision endless discussions like:

2? For the love of Guido, what in the five hells of PEP 8 does 2 mean, Jim?

...search me, Bob. Thought you knew. Must be a typo. I'll just remove that.

It's also fragile and non-forward compatible. What if we want to add yet another type of array metadata whose value can also be an integer? Then... we're boned, in the bad way! That's bad.
I'm considering standard instantiation syntax with human-readable keywords instead ala:
from beartype import beartype
from beartype.cave import NumpyArrayType

# This constrains the passed "funbag_of_fun" parameter to be a two-dimensional
# NumPy array with any float dtype (e.g., "np.float32", "np.float64").
@beartype
def catch_the_funbag(funbag_of_fun: NumpyArrayType(dtype=float, ndim=2)) -> float:
     return funbag_of_fun[0, 0]

NumpyArrayType(dtype=float, ndim=2) instead of NumpyArrayType[float, 2] seems sane and sensible to me, but I also like obscure Japanese visual novels and obscure technical death metal albums from Quebec literally named Obscura. My opinion may not be representative of mainstream consensus. :man_singer:

As an almost relevant aside, there have been some attempts to transition to "NamedTensors"...

You have my attention. I like what I read and read what I like, especially:

In addition, named tensors use names to automatically check that APIs are being used correctly at runtime, providing extra safety.

The Name propagation semantics section is especially exciting, suggesting it wouldn't be hard to also add support for PyTorch named tensors in a future beartype release – but probably not before beartype 0.7.0, unless someone who is not me would care to contribute a pull request. Any takers? Anyone? Helloooooooo?
BETSE currently only leverages NumPy arrays rather than PyTorch tensors – which, in hindsight, might have been a mistake. Who can argue with GPU acceleration? Let's put those shader units to good use, boys!

Fire it up! Beartype 0.3.2 featuring Python 3.9 support is now out. This is just a point compatibility release (with not much else to show for it), but at least we continue to uphold the golden future of Python.
Let us also express our gratitude to the Universe for Python 3.5's official death several weeks ago. Long live Python 3.6 f-strings, which we can now finally use. It's been a long road we've walked together, str.format(), but the bell tolls at long last for thee. :bell:

Mondo hype generator: the next stable release of beartype is but a few days away, stalwart typing heroes! Beartype 0.4.0 celebrates a partial return to democratic sanity in Canada's southern neighbour by bringing:

Deep type-checking of:

typing.Tuple, typing.Annotated, typing.NewType, and typing.NoReturn.
Forward references (i.e., unqualified relative classnames typically referring to user-defined classes that have yet to be defined).
Generics (i.e., classes subclassing one or more typing pseudo-superclasses), including both user-defined generics and standard typing generics such as:

typing.IO.
typing.BinaryIO.
typing.TextIO.

Protocols (i.e., classes directly subclassing the typing.Protocol abstract base class (ABC) and zero or more typing non-class objects), including both user-defined generics and standard typing protocols such as:

typing.SupportsAbs.
typing.SupportsBytes.
typing.SupportsComplex.
typing.SupportsInt.
typing.SupportsFloat.
typing.SupportsRound.

Full compliance with:

PEP 483 -- The Theory of Type Hints.
PEP 484 -- Type Hints.
PEP 544 -- Protocols: Structural subtyping (static duck typing).
PEP 560 -- Core support for typing module and generic types.
PEP 563 -- Postponed Evaluation of Annotations.
PEP 593 -- Flexible function and variable annotations.

With respect to PEP 484, "full compliance" means "We deeply type-check a lot and at least shallowly type-check the remainder, yo." With respect to all of the other PEPs listed above, "full compliance" means "We deeply type-check everything, bro."
Notably, this means that beartype should no longer raise exceptions when decorating callables annotated by type hints compliant with any of the above PEPs. Beartype will still raise exceptions when decorating callables annotated by PEP 585-compliant type hints (e.g., def uhoh(lawks: list[str]): pass), but we hope to trivially resolve that as well by fully supporting PEP 585 with the next major beartype release: beartype 0.5.0, expected to be released at the end of this month.
We're on the cusp of full, really full compliance, folks. Once PEP 585 support lands, beartype will be both the most compliant and stupidly fastest Python runtime type checker in existence. The only substantial feature beartype lacks going forward is support for type-checking type variables (i.e., typing.TypeVar instances), which we currently silently ignore because we're not actually convinced anyone cares about type variables, they're fairly troublesome to support, and we don't actually require them ourselves. Fight me.
I'm painfully tired tonight and tomorrow's a family day. So, I hope to push beartype 0.4.0 out this Wednesday. The commits are in and all's passing. I mostly just need to sanity-check everything and cobble together the release notes. Thanks for everything, Pythonistas! Everyone here rocks it.
Disgustingly patriotic American icons for all: :us: :eagle: :us:

"This is my boomstick." Beartype 0.4.0 is now officially out on all the standard channels.
tl;dr
This stable release significantly improves beartype's compliance with Python Enhancement Proposals (PEPs), including full compliance with:

PEP 483 -- The Theory of Type Hints.
PEP 484 -- Type Hints.
PEP 544 -- Protocols: Structural subtyping (static duck typing).
PEP 560 -- Core support for typing module and generic types.
PEP 563 -- Postponed Evaluation of Annotations.
PEP 593 -- Flexible function and variable annotations.

With respect to PEPs 483 and 484, "full compliance" means "beartype deeply type-checks a lot and at least shallowly type-checks the remainder." With respect to the remaining PEPs, "full compliance" means "beartype deeply type-checks everything."
This sort of accidentally became a doctoral thesis-like monstrosity at some point. I'm unconvinced anyone actually wants to read this minutiae, but... for those with the patience of an Ecuadorian three-toed sloth, ...hi! here's the slo-mo low-down.
Compatibility Broken

Call-time type hint exception classes renamed. For orthogonality with decoration-time type hint exception classes, all call-time type hint exception classes have been renamed from beartype.roar.BeartypeCallCheck*Exception to beartype.roar.BeartypeCallHint*Exception (e.g., from beartype.roar.BeartypeCallCheckPepParamException to beartype.roar.BeartypeCallHintPepParamException).

Features Added

Deep typing.Annotated type-checking. Under Python ≥ 3.9, the @beartype decorator now deeply type-checks parameters and return values annotated by PEP 593 (i.e., "Flexible function and variable annotations")-compliant typing.Annotated type hints in guaranteed constant time.
Deep typing.Generic type-checking. The @beartype decorator now type-checks both the shallow types and deep contents of parameters and return values annotated by PEP 484-compliant generics (i.e., type hints subclassing a combination of one or more of the typing.Generic superclass and/or other typing non-class pseudo-superclasses) in guaranteed constant time. Specifically, beartype iteratively walks up the superclass hierarchy of each generic and deeply type-checks that the current parameter or return value satisfies all constraints implied by that superclass. This includes:

typing.IO. This was no small feat, as this abstract base class (ABC) fails to leverage structural subtyping (e.g., via the PEP 544-compliant typing.Protocol ABC) and is thus unusable at runtime... like most typing objects, sadly. Our solution is to ignore the existing implementation of these classes, declare our own internal typing.Protocol-based variants of these classes, and implicitly substitute all instances of these classes with our own variants during our breadth-first traversal (BFS) over PEP-compliant type hints.
typing.BinaryIO.
typing.TextIO.

Deep typing.NewType support. The @beartype decorator now deeply type-checks parameters and return values annotated by PEP 484-compliant new types (i.e., closures generated by the typing.NewType closure factory) in guaranteed constant time.
Deep typing.NoReturn support. The @beartype decorator now fully type-checks that callables annotated by the typing.NoReturn singleton return no values (i.e., either halt the active Python process or raise an exception) in guaranteed constant time.
Deep typing.Protocol type-checking. Under Python ≥ 3.8, the @beartype decorator now type-checks both the shallow types and deep contents of parameters and return values annotated by PEP 544 (i.e., "Protocols: Structural subtyping (static duck typing)")-compliant protocols (i.e., type hints subclassing a combination of one or more of the typing.Protocol superclass and/or other typing non-class pseudo-superclasses) in guaranteed constant time, similarly to how beartype type-checks generics. This includes:

typing.SupportsAbs.
typing.SupportsBytes.
typing.SupportsComplex.
typing.SupportsIndex.
typing.SupportsInt.
typing.SupportsFloat.
typing.SupportsRound.

Deep typing.Tuple type-checking. The @beartype decorator now type-checks both the shallow types and deep contents of parameters and return values annotated by PEP 484-compliant typing.Tuple type hints in guaranteed constant time. The three syntactic variants standardized by PEP 484 are all supported, including:

typing.Tuple[()], type-checking empty tuples.
typing.Tuple[{typename}, ...], type-checking tuples containing arbitrarily many items all satisfying the PEP-compliant child hint {typename} (e.g., typing.Tuple[str, ...], a tuple of strings).
typing.Tuple[{typename1}, ..., {typenameN}], type-checking tuples containing exactly N items each satisfying a unique PEP-compliant child hint {typenameI} (e.g., typing.Tuple[str, int, float], a tuple containing exactly one string, one integer, and one floating-point number in that order).

Shallow typing.AsyncContextManager, typing.ContextManager, typing.Match, and typing.Pattern support. The @beartype decorator now type-checks the shallow types (but not deep contents) of parameters and return values annotated by the PEP 484-compliant typing.AsyncContextManager, typing.ContextManager, typing.Match, and typing.Pattern objects. This was no small feat, as the implementations of:

typing.AsyncContextManager and typing.ContextManager define __repr__() dunder methods returning erroneous machine-readable representations obstructing proper support under prior releases.
typing.Match and typing.Pattern under Python 3.6 are non-trivially obtuse and basically broken at runtime.

Shallow type variable support. The @beartype decorator now shallowly type-checks all otherwise supported PEP-compliant type hints parametrized by one or more type variables (e.g., List[T], where T = TypeVar('T')). Previously, this decorator raised exceptions when decorating callables with such hints. This decorator does not yet deeply type-check type variables to be constrained across callable parameters and return values or class methods. For def muh_func(muh_param: List[T]) -> T: return muh_param[0], as example, this decorator now shallowly type-checks the passed parameter muh_param to be a list but does not yet deeply type-check that this function returns values of the same types as items of this list.

Features Optimized

Nested PEP-compliant type hint type-checking. Under Python ≥ 3.8, the @beartype decorator now generates optimized code when deeply type-checking items contained in arbitrarily nested PEP-compliant type hints (e.g., typing.List[typing.Union[bool, str, typing.List[int]]]) with PEP 572-style assignment expressions, generalizing similar sequence-specific optimizations introduced with beartype 0.3.0.
PEP-compliant type hint breadth-first search (BFS). The @beartype decorator now internally catalogues PEP-compliant type hints during the breadth-first search (BFS) it performs over these hints as simple tuples rather than fixed lists, as the former are both mildly faster than the latter and significantly more maintainable (which is the main gain here).

Issues Resolved

PEP-compliant type hint code generation memoization. The @beartype decorator now properly memoizes the type-checking code it generates for PEP-compliant type hints. Prior beartype releases silently failed to memoize this code across different callables annotated by the same hints.

API Changed

In the beartype.cave submodule, added:

A new public beartype.cave.HintPep585Type attribute, defined as the C-based type of all PEP 585-compliant type hints (i.e., C-based type hint instantiated by subscripting either a concrete builtin container class like list or tuple or an abstract base class (ABC) declared by the collections.abc submodule like collections.abc.Iterable or collections.abc.Sequence) if the active Python interpreter targets at least Python 3.9.0 or beartype.cave.UnavailableType otherwise. This is a prerequisite for PEP 585 support in a subsequent stable release.

In the beartype.roar submodule, renamed:

BeartypeCallCheckException to BeartypeCallHintException.
BeartypeCallCheckPepException to BeartypeCallHintPepException.
BeartypeCallCheckPepParamException to
BeartypeCallHintPepParamException.
BeartypeCallCheckPepReturnException to
BeartypeCallHintPepReturnException.
BeartypeCallCheckNonPepException to
BeartypeCallHintNonPepException.
BeartypeCallCheckNonPepParamException to
BeartypeCallHintNonPepParamException.
BeartypeCallCheckNonPepReturnException to
BeartypeCallHintNonPepReturnException.

Phew. :sweat_smile:

Glorious. Lots of useful stuff in here for me 😄 .
At the risk of potentially adding further workload, perhaps at some point in future (no rush, obviously), you could add a short technical report so that the beartype enthusiasts among us can cite/credit the library.

That... would be useful. My wife and I currently lack University affiliation, which complicates publication just a tad. We've both walked the independent scholar route before, but that's neither a fun nor easy journey. Without affiliation, getting even simple letters to the editor or literature reviews past journal editors out for peer review is (perhaps justifiably) an uphill journey of gatekeeping and rejection and dejection and really non-happy feelings.
That said, you're right – as always, eh? beartype has a few novel theoretical aspects that would warrant publication. It'd be especially nice to see if there isn't a tighter bound than O(n log n) for the expected number of calls required to deeply type-check an arbitrary container of n items, though I sorta doubt I still have the statistical R chops to get that properly done. </sigh>
We're both contemplating a change of occupational scenery next year. A furious global pandemic isn't exactly the optimal job market, but what can you do? With any luck (and more than a little hand-wringing), one or both of us will reignite our collaborative passion for theoretical research and hook back up with that whole academia scene!

Boom-shaka! beartype 0.5.0 just mic-dropped. Full support for PEP 585 along with a host of ancillary compatibility improvements and optimizations is in. Since this finally resolves this long-standing issue, this is all she wrote for issue #4, folks. Let's do this!
Changelog for Great Glory
Beartype 0.5.0 released.
This stable release implements full compliance for PEP 585 -- Type Hinting Generics in Standard Collections, where "full compliance" means "@beartype deeply type-checks all categories of type hints deeply type-checked by prior stable releases and shallowly type-checks the remainder." See our compliance list and feature matrix for deeply exhausting, enervating, and deenergizing details.
Specific changes include:
Compatibility Improved

PEP 585. @beartype is now fully compliant with PEP 585 -- Type Hinting Generics in Standard Collections. Since that PEP supercedes and largely obsoletes the overwhelming majority of PEP 484, compliance with PEP 585 is critical for all static and runtime type checkers to guarantee forward compatibility with Python's type-checking ecosystem. Notably, @beartype now provides deep type-checking support for all PEP 585-compliant type hints that had comparable deep type-checking support under prior @beartype releases, including:

Subscriptions of these C-based builtin types and pure-Python abstract base classes (ABCs) declared by the stdlib:

list.
tuple.
collections.abc.ByteString.
collections.abc.MutableSequence.
collections.abc.Sequence.

User-defined PEP 585-compliant generics (e.g., class ListOfInts(list[int]): pass), which were implemented in a completely non-orthogonal manner to both PEP 484-compliant generics and PEP 544-compliant protocols and thus required "extreme" handling for PEP 585-specific edge cases.

Unhashable PEP-compliant type hints. @beartype now supports PEP-compliant type hints not hashable by the hash() builtin and thus impermissible for use as dictionary keys, set members, and memoized callable parameters. While all PEP 484-compliant type hints are hashable, many such hints  (e.g., typing.Callable[[], str]) are unhashable when converted into equivalent PEP 585-compliant type hints (e.g., collections.abc.Callable[[], str]), necessitating that @beartype now permissively accept both hashable and unhashable type hints. The disadvantage of the latter is that the private @beartype._util.cache.utilcachecall.callable_cached decorator underlying internal decoration-time memoization performed by @beartype cannot, by definition, memoize calls passed one or more unhashable objects. Ergo, callables accepting one or more unhashable PEP-compliant type hints incur a performance penalty versus hashable PEP-compliant type hints. Note this penalty is only paid at decoration rather than call time and should thus be entirely negligible. Unhashable PEP-compliant type hints include:

PEP 585-compliant type hints subscripted by one or more unhashable objects (e.g., `collections.abc.Callable[[], str]).
PEP 586-compliant type hints subscripted by an unhashable object (e.g., typing.Literal[[]], a literal empty list).
PEP 593-compliant type hints subscripted by one or more unhashable objects (e.g., typing.Annotated[typing.Any, []], the typing.Any singleton annotated by an empty list).

@typing.no_type_check. @beartype now supports the PEP 484-compliant @typing.no_type_check decorator by silently ignoring (and thus reducing to a noop for) all callables decorated by that decorator.
typing.TYPE_CHECKING. @beartype now supports the PEP 484-compliant typing.TYPE_CHECKING boolean constant by silently reducing to the identity decorator when this boolean is True (i.e., during external static type checking).

Compatibility Broken

Call-time PEP-noncompliant type hint exception classes removed. Since all PEP-noncompliant type hints supported by @beartype (e.g., tuple unions) are now internally coerced into equivalent PEP-compliant type hints, PEP-noncompliant type hint exception classes are now obsolete and have been summarily removed. These include:

beartype.roar.BeartypeCallHintNonPepException.
beartype.roar.BeartypeCallHintNonPepParamException.
beartype.roar.BeartypeCallHintNonPepReturnException.

Features Deprecated

PEP 484-compliant type hints deprecated by PEP 585. @beartype now emits non-fatal warnings of class beartype.roar.BeartypeDecorHintPepDeprecatedWarning under Python >= 3.9 for each PEP 484-compliant type hint deprecated by PEP 585 annotating each decorated callables. Critically, note that this deprecates most PEP 484-compliant type hints accepted without warning by prior stable releases and, indeed, most of the existing typing stdlib module. Affected type hints include subscriptions of any of the following objects:

typing.AbstractSet.
typing.AsyncGenerator.
typing.AsyncIterable.
typing.AsyncIterator.
typing.Awaitable.
typing.ByteString.
typing.Callable.
typing.ChainMap.
typing.Collection.
typing.Container.
typing.ContextManager.
typing.Coroutine.
typing.Counter.
typing.DefaultDict.
typing.Deque.
typing.Dict.
typing.FrozenSet.
typing.Generator.
typing.ItemsView.
typing.Iterable.
typing.Iterator.
typing.KeysView.
typing.List.
typing.MappingView.
typing.Mapping.
typing.Match.
typing.MutableMapping.
typing.MutableSequence.
typing.MutableSet.
typing.Pattern.
typing.Reversible.
typing.Sequence.
typing.Set.
typing.Tuple.
typing.Type.
typing.ValuesView.

Features Optimized

Standard PEP-noncompliant class type hints. @beartype now efficiently registers type hints that are standard classes not explicitly compliant with any existing PEP at decoration time and accesses these hints at call time via the standard beartypistry singleton used to resolve all other type hints rather than inefficiently accessing these hints at call time via dictionary lookup into the __annotations__ dunder attribute of the decorated callable, eliminating one dictionary lookup for each such hint for each call to each callable annotated by one or more such hints.
Beartype-specific tuple unions < PEP 484 unions. Beartype-specific tuple unions are now a strict semantic subset of PEP 484 unions. Previously, tuple unions and PEP 484 unions were implemented in disparate subpackages -- and the subpackage implementing tuple unions has become poorly documented, maintained, and tested. To reduce bit-rot across the codebase and unify the implementation of tuple and PEP 484 unions, @beartype now silently coerces all tuple unions into the equivalent PEP 484 unions at decoration time. Doing so resolves all outstanding performance and usability issues with tuple unions, including:

Tuple unions are now efficiently registered at decoration time and accessed at call time via the standard beartypistry singleton used to resolve all other type hints rather than inefficiently accessed at call time via dictionary lookup on the __annotations__ dunder attribute of the decorated callable, eliminating one dictionary lookup for each such hint for each call to each callable annotated by one or more such hints.
Duplicate types in tuple unions are now silently ignored rather than type-checked (e.g., (bool, str, bool) is now type-checked as (bool, str)).
Forward references in tuple unions (e.g., ('muh.TypeName', str)) are now efficiently resolved at call time via the standard beartypistry singleton used to resolve all other forward references rather than inefficiently resolved at call time via non-standard iteration hard-coded into all wrapper functions generated by @beartype for callables annotated by these tuple unions.
Registration and optimized access of types in tuple unions via our internal beartypistry type registrar.

Decoration-time memoization, particularly with respect to PEP 484 union type hints. All internal callables decorated by the private @beartype._util.cache.utilcachecall.callable_cached decorator are now efficiently called with positional arguments rather than inefficiently called with equivalent keyword arguments. Memoizing keyword arguments is substantially more space- and time-intensive than memoizing the equivalent positional arguments, partially defeating the purpose of memoization in the first place. To enforce this, these internal callables now emit new non-fatal private beartype.roar._BeartypeUtilCallableCachedKwargsWarning warnings when passed one or more keyword arguments.

Issues Resolved

"3.9+ PEP 585 - type hints for builtin types." This release resolves longstanding issue #4 by adding full support for PEP 585. Thanks for prodding us to jump onto this critical feature, @terrdavis!

Tests Improved

Third-party package tests restored. Unit tests conditionally depending upon the importability of third-party packages have been restored to their prior working state after an embarassingly elongated period of being ignored. These include:

The test_api_cave_lib_numpy() unit test exercising NumPy integration in the beartype.cave submodule.
The test_api_cave_lib_setuptools() unit test exercising setuptools integration in the beartype.cave submodule.

API Changed

In the beartype.roar submodule:

Added:

BeartypeDecorHintPepDeprecatedWarning.

Removed:

BeartypeCallHintNonPepException.
BeartypeCallHintNonPepParamException.
BeartypeCallHintNonPepReturnException.

Peace out. Have a hopefully COVID-free Holidays, everyone! :christmas_tree: :santa: :snowman_with_snow:

In https://github.com/amogorkon/justuse we came up with a different solution that should be future-proof and doesn't require renaming all those names everywhere if you ever wanted to switch to "real generics".
If you put
from gc import getreferents
from typing import _GenericAlias as GenericAlias
for t in (list, dict, set, tuple, frozenset):
    r = get_referents(t.__dict__)[0]
    r.update({
        "__class_getitem__": classmethod(GenericAlias),
    })

in your __init__.py or some other location that's called very early on, it should patch the built-in generic types from python versions down to 3.7 where __class_getitem__ was introduced formally (but for some reason never added to the generics..), thus basically "backporting" the feature.
Since this approach makes use of the gc, it's CPython-specific, so you might have to tweak it a little if you want to make it work for other interpreters.
A fair warning: When we added this to our code, it interacted unpredictably and hard to debug with some other non-standard code that was lurking in some dark corner. So, at least expect the unexpected when trying this approach, but nothing bad happens, you won't have fear or even care about the deprecation of typing anymore.

Give @amogorkon a lever and he will move the Python world. Never would I even consider dangerously monkey-patching a GenericAlias-based __class_getitem__() implementation into Python's core C types. You've just shown me a darkness beyond all prior conception of darkness – and I love it.
Does that cauldron of insanity generalize to everything else deprecated by PEP 585 too, like:

Abstract base classes published by collections.abc and contextlib?
Concrete classes published by collections and re?

If so, I'm all in and will gleefully add this eldritch horror "clean resolution" to our public knowledge base on circumventing PEP 585 deprecations.
Unrelatedly, justuse looks amazing. Between one-off imports (e.g., use("pprint").pprint(some_dict) ← wut) and auto-installing imports (e.g., np = use("numpy", version="1.21.0rc2", hashes={"3c90b0bb77615bda5e007cfa4c53eb6097ecc82e247726e0eb138fcda769b45d"}, modes=use.auto_install) ← wtf is even happening there), I'm both disturbed and impressed – and that's hard to accomplish these days. Like most wilderness cabin-dwellers, I thrive on a daily diet of being jaded, bitter, and oppressively cynical.
Have you considered posting justuse to /r/Python? Actually, I'm considering doing that for you. All your sweet Reddit karma will be mine. Oh, yes. :+1:

Since I'm not very active on Reddit and do love beartype, I will gladly relinquish the Reddit karma to you ;-)
Regarding your questions, I'm not entirely sure since we haven't actually tried to generalize it. Given that __class_getitem__ is a general protocol, I wouldn't be surprised if you could probably put it everywhere and things would "just work".. or maybe it'll open a portal to another plane and release unspeakable horrors - we will only know for sure when we try it! For Science!

The classes in collections.abc and contextlib are just pure-Python classes, so you can set attributes normally. __class_getitem__ is just an attribute lookup triggered when a regular __getitem__ lookup on the metaclass fails, so it should just work fine if you can get an object into the dict.


Use real_t and double where appropriate in Particles

This PR fixes some places that I missed in Particles classes. Lots of this code looks familiar to me, some code was probably missed during a rebase. This fixes #51570 and also fixes another problem that caused the Mono build to be not working.

Thanks!


Language specific date formats

Hello,
In swedish there are 2 specific ways that dates are written very commonly that I have not seen support for. Specifically dates can be written like "den 24:e December" and "201226" (2020-12-26). The first one is not recognised due to the ":e" which is a very common way of writing dates in sweden and the second returns the wrong date datetime.datetime(2022, 2, 1, 6, 0). I am assuming the second can be rectified with some setting but short of removing the ":e" I cannot see a way of tackling the first one.
Any help is appreciated.
Thank you.

Hi @mnikolop
You can add additional/custom formats by using the date_formats parameters. For example:
>>> dateparser.parse('201226', date_formats=['%y%m%d'])
datetime.datetime(2020, 12, 26, 0, 0)

This approach could be used for the other date format, but it will only work if the configured locale in your computer is sv_SE:
>>> dateparser.parse('den 24:e Januari', date_formats=['den %d:e %B'])
datetime.datetime(2020, 1, 24, 0, 0)

(I changed to "Januari" to check that it works as expected because "December" is the same word in English).
If it doesn't work for you, you can change temporarily the locale by doing:
>>> import locale
>>> locale.setlocale(locale.LC_TIME, "sv_SE")
'sv_SE'
>>> dateparser.parse('den 24:e Januari', date_formats=['den %d:e %B'])
datetime.datetime(2020, 1, 24, 0, 0)

I hope this will work for you. I'm not going to close this issue as I think that we could think about it and see if we should add these formats with ":e", or try the date_formats with different locales.
Let me know if you find any issues!

How could this be applied in the search_dates function without is raising a SettingValidationError?

Hi @mnikolop the search_dates() function does not support date_formats. I have just opened a new issue to discuss this: https://github.com/scrapinghub/dateparser/issues/846
As stated in the docs, the support for searching dates needs a lot of improvement, so I really encourage you to add your ideas and PRs :)


Checkout 2.0 branch rather than a specific rc

In this way, we can backport patches without immediately providing a new rc, and people using the nightly can already use it.

:+1:


bf2path

Adds yet another step to the process of generating hello_world.c
Once again gonna wait for review from someone else who contributed here (@zxcv05),
a) because.. idk
b) because I wanna make sure I didn't forget anything...
Anyway hope this makes the build time longer (which it should, but you never know with these :sparkles:magic machines:sparkles:)

Gimme a bit to make the changes, still working on school stuff


Tera Term lexer text analysis

This PR ports pygments Tera Term text analysis to chroma/go. Original code can be found at: https://github.com/pygments/pygments/blob/master/pygments/lexers/teraterm.py#L333
Out of curiosity here this lexer uses a long list of possible commands into analyse text.

@dron22 fixes applied.


Plan to drop supports for Node 0.10 and 0.12

https://github.com/nodejs/LTS#readme
I will drop supports for both 0.10 and 0.12 at the end of 2016.

I'm considering to change the path of npm that npm-run-all is using to run tasks.
Currently, npm-run-all is using the result of which npm command (via cross-spawn module).
The new behavior is that npm-run-all uses npm that NPM_EXECPATH environment variable specified. This environment variable is made by npm automatically in npm run. This implies that npm-run-all uses npm which runs itself. As a side-effect, if it run npm-run-all in yarn run command, npm-run-all run tasks with yarn.
If the NPM_EXECPATH environment variable did not find, npm-run-all keeps the current behavior.
One concern, someone has a local-installed npm then npm-run-all is using it to run tasks. In this case, probably this change effects negatively.

It would seem to be expected behavior, that if I installed a local npm, that said npm is what I would want to npm-run-all anyway.

I dropped supports for Node 0.x: https://github.com/mysticatea/npm-run-all/releases/tag/v4.0.0


Requests for non-existent pages should trigger a 404 response

Backtrace
View full backtrace and more info at honeybadger.io

Closed as duplicate of #1200


Why is included section an array instead of an object?

It seems a search through an array could be avoided by having the included section like so,
"included" : {
 "MY_TYPE":{
   "MY_ID": {} // your object
 }
}

or
"included" : {
 "MYTYPE_MYID":{} // your object
}

accidental duplicate


Add relationship between thread and any contract

Change-type: minor
Signed-off-by: Lucian Buzzo<EMAIL_ADDRESS>

@balena-ci I self-certify!


Add a six.moves for collections and collections.abc in preparation fo…

…r Python 3.7+ (Closes #155)

This would be very helpful to use six for compatibility with the upcoming Python 3.7

Since six deals with the Python 2/3 boundary, this request seems misplaced, unless the project seeks to expand its scope for general cross-version compatibility.

Python 3.8 is slated to remove support for ABCs in the collections module.
On Tue, Jul 3, 2018, 3:37 PM Jason R. Coombs<EMAIL_ADDRESS>wrote:

Since six deals with the Python 2/3 boundary, this request seems
misplaced, unless the project seeks to expand its scope for general
cross-version compatibility.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/benjaminp/six/pull/241#issuecomment-402270045, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AExYE9xgP2PYQBSdKkAZnc6ujjiGm5_Wks5uC8gDgaJpZM4T6v3a
.

@timhoffm I decided to use your suggestion of adding a "since" version variable.

Suggested changes have been made, I also decided to future proof MovedAttribute incase it ever becomes required.

This looks ready to go, and I would appreciate avoiding the deprecation warning with Python 3.7.
Waiting for this!

This looks ready to go, and I would appreciate avoiding the deprecation warning with Python 3.7.

Related CPython PR : https://github.com/python/cpython/pull/10596

Can we push this through?   This would help with other projects.

Any way to help move this along?

My initial reaction is similar to jaraco's. The planned release date for Python 3.8 is two months before Python 2's EoL.
Note the CPython PR to actually remove collections.abc, python/cpython#10596, is stuck due to the small part of the external Python universe that is vendorized into CPython.

@benjaminp What is the compatibility library for changes between Python versions 3.x and 3.y?  There needs to be one for the same reason that six was needed.  Why not have six do this?

For compatibility between Python 3 versions you have to just import from collections.abc. six.moves is not needed for this.

@serhiy-storchaka Unfortunately, many projects need to support multiple versions of Python 3, including ones that have no collections.abc.

Is there a compatibility library for changes between Python versions 3.x and 3.y?

There isn't, probably because many of the compatibility issues are selective (only between particular versions of Python), such as packages in the backports namespace or projects like configparser or importlib_resources that provide backports but following another pattern. It doesn't necessarily make sense to have one library to collect all compatibility modules and in fact such an approach has the unfortunate downside of having to drag along lots of historically compatibility that a given project may not need (and to eventually deprecate that in the project as versions become unsupported). Instead, I think it's better for each compatibility layer to have its own library. It might make sense to have a suite of compatibility libraries that cover specific compatibility concerns, such as this one which is a moved import between Python 3.3 and 3.4, might go in a "python_33_compat" package (or similar), and relied upon by projects requiring Python 3.3 or older.

Back in the Python 2 days, I used to maintain a project called jaraco.compat that would provide forward-compatibility (backports) of various language features. Perhaps that project could be revived to support small compatibilities like this one.

I'm rolling out jaraco.compat 2.2 with py33compat.collections.abc.

Is there anything blocking this? Was surprised to find that there was no option in six to avoid:
if six.PY3:
  from collections.abc import Iterable, Sequence
else:
  from collections import Iterable, Sequence

If you want a one-liner, use from py33compat.collections.abc import Iterable, Sequence:
~ $ python2.7 -m pip-run -q jaraco.compat>=3.1 -- -c "from py33compat.collections.abc import Iterable, Sequence" && echo done
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
done
~ $ python3.7 -m pip-run -q jaraco.compat>=3.1 -- -c "from py33compat.collections.abc import Iterable, Sequence" && echo done
done

@jaraco The problem is that a lot of projects don't want to add another dependency.  I don't see why this isn't in six.


Data Editor Improvements for v1.3.1

Comparmentalized the dataEditor.svelte into Svelte components.
Implemented byte edits via the Data View.
Revised file retention methods.
Byte editing mode now determined by selection data.
Implemented overwrite only editing restriction.
Allow multi instances of the data editor to run at once.
Implemented basic data profiling panel.
Transitioned byte display from textarea to byte components.
Implement scalable search and replace

Closes #715
Closes #714
Closes #668
Closes #657
Closes #654
Closes #631
Closes #576
Closes #568
Closes #518
Closes #516
Closes #572

Other than the two items commented, everything else looks good. After those two things are resolved I will approve.

@shanedell Can you double check my ci.yaml section removal is correct? I've never configured the CI workflows and want to be sure it's as intended.


Enhance cgroup reader to handle disabled cgroups

Added ErrCgroupsMissing to indicate that /proc/cgroups is missing which is an indicator that cgroups were disabled at compile time. #64
Changed cgroup.SupportedSubsystems() to honor the "enabled" column in the /proc/cgroups file. #64
Prepare 0.2.0 release notes.

Codecov Report

Merging #64 into master will increase coverage by 0.2%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master      #64     +/-   ##
=========================================
+ Coverage   61.94%   62.15%   +0.2%
=========================================
  Files          27       27
  Lines        2465     2473      +8
=========================================
+ Hits         1527     1537     +10
+ Misses        715      714      -1
+ Partials      223      222      -1

Impacted Files
Coverage Δ

cgroup/util.go
61.43% <100%> (+3.5%)
:white_check_mark:

Continue to review full report at Codecov.

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

@andrewkroh I saw there is a docker.zip file in the commit but I couldn't find where it is used. Is it needed?

The zip file is used in the tests. This was originally requested to reduce the footprint of the testdata in the repo. The downside of having the zip is that we lose the ability to diff the contents. I'm also not sure if Git has to store a whole new copy of the binary file or if it can just store the bits that changed.

LGTM. Waiting for green.


ERROR: Could not build wheels for commonroad-drivability-checker, which is required to install pyproject.toml-based projects

System description

OS: Ubuntu 22.04 LTS, 64bit
CPU: Intel i5

Conda environment description

pip: 24.0
python: 3.12
cmake: 3.22.1
gcc/g++: 11.4

Other common road package installed

commonroad.io
commonroad.sumocr

Error description
Running "pip install commonroad-drivability-checker" gets the error (error report.txt):
(...log skipped...)
Building wheel for commonroad-drivability-checker (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> [1112 lines of output]
(...log skipped...)
File "/tmp/pip-install-n6fix6ja/commonroad-drivability-checker_83373c1d04214c9a93b644f29613054d/setup.py", line 44, in run
self.build_extension(ext)
File "/tmp/pip-install-n6fix6ja/commonroad-drivability-checker_83373c1d04214c9a93b644f29613054d/setup.py", line 140, in build_extension
subprocess.check_call(['cmake', '--build', '.'] + build_args, cwd=build_dir)
File "/home/ron/miniconda3/envs/commonroad/lib/python3.12/subprocess.py", line 413, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '--config', 'Release', '--target', 'install']' returned non-zero exit status 2.
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for commonroad-drivability-checker
Running setup.py clean for commonroad-drivability-checker
Failed to build commonroad-drivability-checker
ERROR: Could not build wheels for commonroad-drivability-checker, which is required to install pyproject.toml-based projects

We currently only support Python 3.8-3.10. We will provide Python wheels for newer version with the next release of the tool.


Revamp HKT kernel

Depends on #13

Rename as_member to reify in accordance with clippy complaint about as_ name.
Rename Of type constructor to K

yeah, this naming is much better 👍


No compatible version found mp4box.js when trying to install npm webtorrent with meteor

Hi,
Im trying to use webtorrent with meteorhack:npm.
packages.json :
{
"webtorrent":"0.55.0"
}
server.js
if (Meteor.isServer) {
Meteor.startup(function () {
var Webtorrent = Meteor.require('webtorrent');
});
}

I believe that Windows can't handle git+ssh:// urls in npm dependencies. I fixed this in videostream (see https://github.com/jhiesey/videostream/pull/14).
@zakaria340 Can you try installing again and let me know if it works now?


App is crashing when I scroll vertically

When I change the textviews in the sampleApp to editTexts the app crashes when I scroll vertically.

#154


High level note on current state of memory

Type of Issue
Select the type of issue:

[ ] Bug report (to report a bug)
[ ] Feature request (to request an additional feature)
[ ] Tracker (I am just using this as a tracker)
[ ] Refactor request
[x] Documentation Ask

Description
We need a high level diagram for the current state of memory, the schema, the architecture, the base class and children
We need two things:

high-level understanding,
Something on low level details for each agent.

Pointers from Soumith:
Example diagram from graphviz: https://github.com/facebookresearch/droidlet/issues/337
Generated with: https://gist.github.com/soumith/9c6a9a21e426423f55207d2d291c7f7a
and the command neato -T png architecture.dot -o out.png

Added in : https://github.com/facebookresearch/droidlet/issues/351 closing this


Make 'installcosmo' compatible with '--show-log-on-error'

spack installcosmo --show-log-on-error cosmo... produces errors unrecognized arguments: --show-log-on-error. It would be nice to have that compatibility. But it's not urgent.

I investigated this issue a bit before but didn't really know how to solve it. Here is what I found out so far, in case it is helpful in any way.
When trying to run spack installcosmo --show-log-on-error (...), the function main.py throws the error unrecognized arguments: --show-log-on-error in the function _invoke_command.
In the install.py function, the argument  --show-log-on-erroris added to a cd_group and is not an argument of do_install.

spack installcosmo -v gives the desired output.
Won't fix!


Remove the list of queue families from buffers and images creation

I think it's too cumbersome to have to do that. Buffers and images should probably default to shared sharing mode for all the queue families of the device.
Of course you could still customize the sharing mode to use, but with another constructor.
And after this change is made, I think the API for the sharing mode should be more explicit instead of just an iterator to a list of queue families. I went with the iterator approach because it is less cumbersome, but I think that it feels too magic.

As a quick background, this is what the specs say: when you create a buffer or an image, you have to choose between SHARING_MODE_EXCLUSIVE and SHARING_MODE_CONCURRENT. If you use exclusive, then the resource will belong to a certain queue family (the first one that uses it). Using an exclusive resource in queue family B after using it previously in queue family A requires a pipeline barrier in A and another one in B. On the other hand, with concurrent everything is automatic. But concurrent may be slower.
Following a quick discussion on IRC, I think that under the hood when you use SHARING_MODE_EXCLUSIVE then implementations can keep resources in a queue family's local cache. But if you use SHARING_MODE_CONCURRENT, then it will flush caches to the main memory after you modify the resource.
With this in mind I think it's fine to default to CONCURRENT for immutable buffers and images.
CpuBufferPool should default to EXCLUSIVE, since it's supposed to be either read or written once per frame.
AttachmentImage, SwapchainImage, StorageImage and StorageBuffer are more debatable. One has to keep in mind that in the future users will probably be required to manually handle queue family ownership transitions by explicitly calling a function (right now vulkano doesn't care about this, which is technically undefined behavior by the way).
This is only required for exclusive resources, and means that exclusive resources may be more confusing/difficult to use. On the other hand they are faster.
I think that AttachmentImage and SwapchainImage should be exclusive by default, but have convenient constructors for when you want concurrent.
StorageImage and StorageBuffer are meant to be used for compute-related work, which might switch queue. I'm really not sure what to do with them.

I forgot to mention that you can transition an exclusive between families without using a barrier, but then the content becomes undefined.
It is important to have that in mind when it comes to CpuBufferPool, otherwise it would be too inconvenient to reuse buffers.

I think StorageImage and StorageBuffer should simply stay as they are, ie. the user has to explicitly choose.


E2E testing of revisions

Need
Confidence that the revision feature works as expected
Approach

FE moved to a separate ticket

Backend testing via functional tests of APIs in staging

[ ] Updating a dataset in a revision does not effect the published dataset
[ ] Publishing a revised dataset replaces the original dataset

Check the metadata api to ensure the s3_uri has changed
Check the the explorer/schema endpoint to ensure the explorer is accessing the correct dataset

[ ] Deleting a dataset does not effect the published dataset
[ ] Publishing a revision that deletes a dataset removes it from the data portal (And the explorer url redirects appropriately)
[ ] Adding a dataset to a revision does not impact public datasets in that collection
[ ] Publishing a revision that contains a new dataset updates the collections page for the data portal (with the new dataset)

Potentially split into two. @seve , @MDunitz

I added a few cases to the work items above.
Are you confident about the UX for updating datasets and adding datasets on the FE - labels for example? And variations like add-then delete?

blocked by BE ticket #2234


Test godot+thorvg git tip

For svg testing
Issue: https://github.com/godotengine/godot/issues/72478
Also needs PR https://github.com/godotengine/godot/pull/75034

What's the goal here? Do you want to bump the version of thorvg used by the engine?

This is exactly the version I used to test the svg images in Godot.
If someone can find other issues, they could fix it before making the next thorvg release :)

I believe this is to help @mgrudzinska (who is a ThorVG developer) test ThorVG/master in Godot to help solve #72478.

Obsolete, the ThorVG GitHub tip has been fixed.


Add reduced test flakiness to Canary

Merge in reduced test flakiness to Canary branch

This appears to need rebasing?

reopen

/test sagemaker-kind-e2e

/test sagemaker-kind-e2e

/approve
/lgtm

/test sagemaker-kind-e2e

/test sagemaker-kind-e2e


fix: When click on "View all" from favorite tab, get error

SUMMARY
Fixes https://github.com/apache/superset/issues/16983
@jinghua-qa @rosemarie-chiu @stephenLYZ
AFTER SCREENSHOTS OR ANIMATED GIF
https://user-images.githubusercontent.com/70410625/136188811-05f2e88e-b08e-47da-b98c-fc2510308cb1.mov
TESTING INSTRUCTIONS
Check the original issue for instructions.
ADDITIONAL INFORMATION

[x] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

🏷 2021.40


Allow message on custom validators to be set via options

For all the validators, except ones that are custom, the message is set on the options object. It would be handy if this was available for custom validators as well:
var Validations = buildValidations({
  hello: [
    validator(function(value) {
      return false;
    }, { message: 'Sorry, this greeting will never pass' }),

    validator('length', {
      is: 25,
      message: 'The greeting should be 25 characters long'
    })
  ]
});

The function passed could return true or false, with the message still passed in via the options and used when the case is false. This would help where people use quick boolean helpers for the function.

Im not sure I follow. Could you not do something like this
var Validations = buildValidations({
  hello: [
    validator(function(value, options) {
      return options.message;
    }, { message: 'Sorry, this greeting will never pass' }),
  ]
});

or even
var Validations = buildValidations({
  hello: [
    validator(function(value) {
      return 'Sorry, this greeting will never pass';
    }),
  ]
});

You're absolutely right, that's the way you can pass things from the options, or just return the string directly. What I was thinking that you could use a utility function, maybe something you've used elsewhere that relates to the property that you're validating. As an example I'll say isValidSkuFormat, that returns a boolean.
The validation would look something like this:
import SkuHelpers from '../utils/sku-helpers';

var Validations = buildValidations({
  sku: validator(SkuHelpers.isValidSkuFormat, { message: 'Please use a valid sku' })
});

This keeps the re-usability of the helper concise in implementation without having to wrap it in a function to set things up. The true/false logic is kept separate from the message, with a similar style as the other validators. I could see enough people possibly having these single parameter helpers, with a true/false return, that could be usable in this case. You're right though, you can access the options argument and pull this through in a way that is organized, with only a few more lines.
Just a suggestion, in any case thanks for this project. Everything has been really a pleasure to use, and is versatile in combining with custom functions.

I think you might want to try creating a custom validator. That should solve your use-case while also giving you the ability to inject services like an ember-data store.

Sounds good, thanks for the feedback.


"cordova.js" was not generated in Android

Hi.
I am getting this error and my application is not running.
CordovaDeviceRouter.js:14 GET http://<IP_ADDRESS>:8081/platform_cordova_files/android/cordova.js net::ERR_ABORTED

[Vue warn]: Error in mounted hook: "ReferenceError: cordova is not defined"

Refused to execute script from 'http://<IP_ADDRESS>:8081/platform_cordova_files/android/cordova.js' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

Has anyone had a similar problem?

Did you check if you have Cordova installed on your machine?
Cordova: https://cordova.apache.org/

Yes, @caiobiodere.
This error is in Chrome inspector, after I compiled my app w/ cordova run android -- --lr.

Thanks

@caiobiodere, I realized that the cordova.js file was not generated on Android, even using cordova run android -- --lr command.
Can you tell me why?

Could you check your npm, node and cordova versions?
Please start a new project from scratch using cordova:
cordova create <project_create_dir> [com.example.projectname] [ProjectClassName] --template cordova-template-framework7-vue-webpack
Npm version: 5.6.0
Node version: 8.9.4
Cordova version: 8.0.0
cordova-android version: 7.0.0
cordova-browser version: 5.0.3

Does testing on a remote device and not the emulator might be the cause of the problem?
$ cordova -v
8.0.0

$ node -v
v9.5.0

$ npm -v
5.6.0

The cordova-android version is 7.0.0.
I will try to create a new project from scratch soon.

Yes mate, that's really the cause of your problem and there has been explained in another task : https://github.com/caiobiodere/cordova-template-framework7-vue-webpack/issues/62. Could you use with the native emulator?

Got it.

Is there anything that can be done? Something like a port forward?
Why the Android "cordova.js" file was not generated and the iOS was?

On remote iOS it works without problems.

I will check your problem when I get some time for free, Just to I know are you using this command to test on other devices?
 cordova run browser -- --lr

No, I am using cordova run android -- -lr to test on Android and cordova run ios -- -lr to test on iOS.
Ok, thank you, xará. 👍

@caiobiodere, sure... I didn't use the browser (just to check if the file cordova.js exists on the local server).

when I first time run cordova.js loaded after than cordova.js not found

@caiotarifa  I think that's because of hooks problems. see https://github.com/caiobiodere/cordova-template-framework7-vue-webpack/blob/master/template_src/hooks/beforedep.js#L14. In<EMAIL_ADDRESS>there is no assets/www in android dir, so I change it to platform_www,  and run cordova run android -- --device --lr, everything is ok. Don't dig too much about beforedep.js, can u fix this? @caiobiodere

yes @catalsdevelop I'm going to see that

@catalsdevelop @hastom @tartinesKiller Thank you guys a lot, everything is working now 👍


Lint logging

Codecov Report

Merging #185 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #185   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          11     11
  Lines        1303   1306    +3
=====================================
+ Hits         1303   1306    +3

Impacted Files
Coverage Δ

ldap2pg/role.py
100% <ø> (ø)
:arrow_up:

ldap2pg/psql.py
100% <100%> (ø)
:arrow_up:

ldap2pg/manager.py
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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